Dette technique du code généré par IA : votre app n'est pas fragile, elle est rigide

La dette technique du code généré par IA se voit rarement sous la forme d'un crash. Elle se voit sous la forme d'une rigidité : chaque nouvelle feature prend plus de temps que la précédente, jusqu'au jour où vous avez peur de toucher votre propre code. Ça se mesure tôt, directement dans l'historique git, et ça se corrige sans réécriture.

Fragile ou rigide

Quand un fondateur nous parle des risques de son app codée avec Claude Code, il pense presque toujours au crash. La faille de sécurité. La base qui saute. Le paiement qui ne passe plus.

Ces problèmes existent. Mais ils sont visibles. Un utilisateur se plaint, une alerte tombe, quelqu'un corrige. Le visible se répare.

La rigidité ne prévient personne. Rien ne plante. Vos utilisateurs ne voient rien. Vous seul le sentez, et vous le sentez tard.

La feature #3 vous a pris une journée. La #15 en a pris trois. La #30 a pris trois semaines et a cassé deux choses au passage. Aucun de ces moments n'a ressemblé à un incident. La structure s'est juste érodée, une PR après l'autre.

Pourquoi l'IA produit de la rigidité

Le code généré par IA n'est pas mauvais. Il est local. Claude résout très bien le problème que vous lui posez, dans les fichiers qu'il a sous les yeux. Il ne sait pas qu'une fonction presque identique existe déjà trois dossiers plus loin. Il ne sait pas que ce module n'était pas censé parler à celui-là.

Résultat : chaque PR est défendable prise seule. C'est la somme qui pose problème.

Dans les repos qu'on ouvre, la rigidité prend presque toujours les mêmes formes.

La logique dupliquée. La même règle métier écrite quatre fois avec de légères variations. Le jour où elle change, vous en corrigez trois. La quatrième continue de tourner.

L'absence de frontières. Les composants d'interface appellent la base directement. Le module de facturation importe des fonctions du module d'onboarding. Tout dépend de tout, donc toute modification se propage.

Le schéma qui pousse tout seul. Une colonne ajoutée par feature, sans que personne ne se demande si elle a sa place dans cette table. Au bout de six mois, la table users porte aussi le statut de paiement. Plus quelques champs de test qu'on n'ose plus supprimer.

Le mesurer dans votre repo

Le symptôme le plus fiable est humain : vous hésitez avant d'ouvrir certains fichiers. Mais il existe aussi des signaux qu'on peut lire dans git en dix minutes.

Le premier, ce sont les fichiers qui changent tout le temps. Cette commande les liste :

git log --since="3 months ago" --format= --name-only | sort | uniq -c | sort -rn | head -20

Un fichier de feature en haut de la liste, c'est normal. Un fichier de configuration, un modèle de données ou un helper partagé en haut de la liste, c'est un point de couplage. Tout le monde passe par lui, donc tout le monde le modifie.

Le deuxième, c'est le nombre de fichiers touchés par feature. Regardez vos dix dernières PR de feature. Si la taille moyenne monte au fil des mois alors que les features ne sont pas plus grosses, votre code est en train de se rigidifier. Une feature simple qui touche quinze fichiers, c'est une structure qui oblige à passer partout.

Le troisième, c'est la question qu'on pose dans chaque audit : combien de fichiers faut-il ouvrir pour changer une règle de prix ? Dans un repo sain, la réponse est un.

Le corriger sans réécrire

La tentation, quand on découvre le problème, c'est de tout reprendre. C'est presque toujours une erreur. Une réécriture fige le produit pendant des semaines et reproduit les mêmes défauts si rien ne change dans la façon de travailler.

On procède autrement.

D'abord, on décide ce qui doit rester solide. C'est ce qu'on appelle l'Expandable Core : le modèle de données, l'authentification, les contrats d'API, les intégrations, le déploiement. On l'écrit dans un registre versionné dans le repo. Le code de feature peut rester imparfait, il sera remplacé. Le core ne peut pas l'être, parce que tout le reste s'appuie dessus.

Ensuite, on traite les points de couplage un par un, en commençant par ceux qui touchent le core. Une règle dupliquée devient une fonction pure, testée une fois, appelée partout. Un composant qui interroge la base passe par une couche dédiée. Chaque correction est une PR normale, livrable en une journée, qui ne bloque pas les features en cours.

Enfin, on empêche la rigidité de revenir. C'est le rôle de la review en deux passes. Un agent relit d'abord chaque PR et repère quand elle touche une surface du core. Si c'est le cas, il la tague pour qu'un architecte la regarde. Un ingénieur senior relit ensuite tout le reste. La duplication et les dépendances qui traversent les modules se voient beaucoup mieux au moment de la PR qu'au bout de six mois.

Ce n'est pas une question de talent

Les fondateurs qui découvrent ce problème pensent souvent qu'ils ont mal fait. Ce n'est pas le cas. La rigidité est la conséquence normale d'un code écrit vite, par petits morceaux, sans personne pour regarder l'ensemble. C'est un problème de structure, et la structure se reprend.

Plus on la reprend tôt, moins elle coûte. À la feature #10, c'est une semaine de travail répartie dans le flux normal. À la feature #50, c'est un chantier.

---

Le Bunker Test, gratuit. Vous nous donnez un accès en lecture seule à votre repo. On revient sous 5 jours ouvrés avec un score de Solidité et de Structure sur 100, vos 3 risques principaux et un correctif que vous pouvez livrer le jour même. Walkthrough de 15 minutes inclus, aucun engagement.

Demander votre Bunker Test →