Le moment où ton app se retourne contre toi
Au début, le vibe coding, c'est magique. Tu demandes une feature, elle apparaît en cinq minutes. Tu en demandes une autre, pareil. Tu as l'impression d'avoir une équipe entière dans ta poche.
Et puis, vers le sixième mois, quelque chose change. Tu demandes un petit changement, et il casse trois trucs ailleurs. Tu corriges ces trois trucs, ça en casse deux autres. L'IA, qui pondait des features d'un claquement de doigts, se met à tourner en rond, à proposer des solutions qui ne marchent pas, à oublier ce qu'elle a écrit la veille.
Ton app ne va pas mieux ni moins bien qu'avant. C'est juste qu'elle est devenue ingérable. Et ce n'est pas un accident. C'est la conséquence directe de la façon dont elle a été construite.
On va voir pourquoi ça arrive, et surtout comment l'éviter, sans jargon.
Pourquoi l'IA écrit du code que l'IA finit par ne plus comprendre
Voilà le truc contre-intuitif. Le code généré à l'IA est, par nature, optimisé pour être compris... par une IA, sur le moment. Pas pour durer, pas pour être repris par un humain, pas même pour être relu par l'IA elle-même six mois plus tard.
Pourquoi ? Parce que quand tu demandes une feature, l'IA cherche le chemin le plus court pour que ça marche maintenant. Elle ne se demande pas "est-ce que dans six mois, avec cinquante features de plus, quelqu'un s'y retrouvera ?". Cette question, personne ne la lui pose. Alors elle empile.
Imagine une maison où, à chaque fois que tu veux une pièce en plus, on l'accole n'importe où, sans plan d'ensemble. La première fois, ça va. Au bout de trente pièces, tu as un labyrinthe sans couloirs, où la cuisine donne sur la salle de bain qui donne sur le garage. Chaque pièce, prise seule, est correcte. L'ensemble est inhabitable.
C'est exactement ce qui arrive à ton code. Pas des erreurs individuelles. Une absence de plan d'ensemble qui devient écrasante avec la taille.
Les trois symptômes que je retrouve à chaque fois
Quand j'audite une app vibe codée qui a "grandi", je vois presque toujours les trois mêmes signes. Tu n'as pas besoin de lire le code pour les reconnaître, tu les ressens déjà au quotidien.
Les fichiers fourre-tout. Au lieu d'avoir chaque morceau de logique rangé à sa place, tout s'entasse dans quelques fichiers géants qui font tout. Dans une app que j'ai auditée, une poignée de fichiers concentraient l'essentiel de la logique. Toucher l'un d'eux, c'était jouer à la roulette : tu ne sais jamais ce que ça va casser ailleurs, parce que tout est mélangé dedans.
La même chose faite à dix endroits différents. Sans plan, l'IA réinvente la roue à chaque feature. La règle "un utilisateur peut faire ça si...", au lieu d'être écrite une fois et réutilisée, est recopiée partout, avec des variantes. Le jour où cette règle change, il faut la modifier à dix endroits, et tu en oublies forcément deux. C'est là que naissent les bugs fantômes.
Le code mort. Des morceaux entiers qui ne servent plus à rien mais que personne n'ose supprimer, parce que personne ne sait s'ils sont vraiment inutiles. Ça encombre, ça déroute l'IA quand elle relit, ça ralentit tout le monde. Sur certaines apps, c'est des milliers de lignes de pur poids mort.
Le point commun des trois : plus l'app grossit, plus chaque changement coûte cher. Ta vélocité, qui était ton super-pouvoir au début, s'effondre.
Le vrai mur : le jour où tu veux faire entrer un humain
Tant que tu es seul avec ton IA, tu peux tenir un moment. Tu connais les recoins, tu sais quels fichiers sont piégés, tu contournes.
Le mur arrive quand tu veux faire entrer quelqu'un. Recruter un dev. Prendre un associé technique. Te faire racheter (l'acheteur mettra forcément un humain dans le code). Ou même, plus simplement, quand l'app devient trop grosse pour que l'IA la tienne entière "dans sa tête" et qu'il faut un cerveau humain pour reprendre la barre.
Et là, le code qui était "digeste pour une IA" se révèle indigeste pour une équipe humaine. Le nouveau dev ouvre le projet, tombe sur les fichiers fourre-tout, la logique dupliquée, le code mort, et il te dit ce que tous disent dans ce cas : "il va falloir tout reprendre". Pas parce qu'il est de mauvaise foi. Parce qu'il n'a aucun point d'entrée clair.
C'est le coût caché du vibe coding sans garde-fous : tu n'as pas construit une app, tu as construit une app dont tu es le seul à pouvoir t'occuper, et seulement avec l'IA qui l'a écrite. C'est une dépendance, pas un actif.
La bonne nouvelle : ça se rattrape par étapes, sans tout réécrire
Si tu te reconnais, respire. Voilà ce que je constate à chaque audit : cette dette est diffuse mais concentrée. Diffuse parce qu'elle est partout. Concentrée parce que l'essentiel tient dans une poignée de fichiers fourre-tout.
Concrètement, ça veut dire que tu n'as pas besoin de réécrire ton app. Tu as besoin de démanteler les quelques gros points noirs, un par un, dans le bon ordre. Souvent, traiter quatre ou cinq fichiers règle la majorité du problème.
Quelques principes simples, que tu peux demander à ton IA de respecter dès maintenant :
- Une chose, un endroit. Chaque règle, chaque morceau de logique, écrit une seule fois, rangé à un endroit clair. Quand ça change, ça change à un seul endroit.
- Des fichiers courts. Si un fichier devient un monstre, c'est le signal qu'il fait trop de choses. On le découpe.
- On supprime le mort. Régulièrement, on enlève ce qui ne sert plus. Un code plus léger, c'est un code que l'IA (et l'humain) relisent mieux.
- On sépare les couches. Ce qui s'affiche à l'écran ne doit pas être mélangé avec les règles métier ni avec l'accès aux données. Trois étages distincts, pas une seule grosse pièce.
Aucun de ces principes ne ralentit ton vibe coding. Au contraire : une app bien rangée, l'IA la fait évoluer plus vite, plus longtemps. Tu prolonges la magie au lieu de la cramer.
La règle à retenir
Si tu ne dois garder qu'une chose :
Le code qui "marche" et le code "qu'une équipe peut reprendre", ce sont deux choses différentes. L'IA te donne le premier gratuitement. Le second se décide.
La vélocité du vibe coding est réelle, mais elle a une date de péremption si tu ne mets aucun garde-fou. Le but, ce n'est pas de coder comme un ingénieur senior dès le premier jour. C'est de ne pas te construire une prison dont tu seras le seul gardien.
Pour creuser ce qui se passe quand on ouvre vraiment le capot d'une app comme ça, j'ai raconté un cas concret dans cet article sur une app que j'ai auditée.
Tu sens que ton app commence à se gripper ?
Si chaque changement devient plus pénible, si l'IA tourne en rond, ou si tu veux faire entrer un dev sans qu'il te dise "on reprend tout", c'est exactement le moment d'un audit. Je lis ton code, je repère les quelques points noirs qui plombent ta vélocité, et je te donne un plan de démantèlement par étapes, sans réécriture. Découvre l'offre Audit.
Et pour garder ton app sous contrôle au fil du temps, inscris-toi à la newsletter. Du concret, à un rythme tranquille, sans spam.
