L'IA casse mon application à chaque modification : pourquoi une méthode bat un meilleur modèle

Vous demandez une correction, vous en récoltez trois pannes. Le réflexe est de changer d'outil, puis de modèle, puis d'outil encore. Ce que racontent ceux qui sont sortis de la boucle tient dans une habitude d'écriture qui coûte une ligne par demande.

Un utilisateur écrit sur Reddit (r/lovable, juin 2026) que sa consommation de crédits a baissé de moitié environ le jour où il a ajouté « ne touche à rien d'autre » à chacune de ses demandes. Quand l'IA casse votre application à chaque modification, le périmètre de la demande est le premier endroit à regarder, avant le choix du modèle.

La boucle que tout le monde décrit

Le récit type circule dans un récit repris à l'identique dans plusieurs fils le même jour (août 2026) : on demande de réparer la connexion, la connexion est réparée et les données ont disparu ; on demande de réparer les données, trois fichiers apparaissent avec une dépendance dont personne n'a entendu parler, et rien ne fonctionne plus. Son auteur dit avoir traversé huit outils avant de s'arrêter. Un développeur français décrit la même mécanique vue de l'autre côté (r/developpeurs, mai 2026) : son responsable intervient en vibe coding sur les projets dont il a la charge, les projets se retrouvent sans structure, et la maintenance devient un enfer. Les deux décrivent un produit dont le périmètre n'a jamais été écrit nulle part.

Ce qu'une IA fait quand personne ne borne la demande

L'auteur du premier témoignage sur les crédits l'écrit avec précision : l'IA aime rendre service, donc vous demandez une modification et elle en améliore quatre autres que vous n'aviez pas mentionnées, dont la moitié cassent, après quoi vous dépensez des crédits à défaire sa générosité. Une IA à qui on donne une phrase et un projet entier prend le projet entier pour terrain de jeu. Elle ne dispose d'aucune frontière écrite : rien ne lui dit que l'écran de connexion, la table des clients et le calcul des remises devaient rester intacts. Chaque tour de boucle agrandit la surface qu'elle croit devoir améliorer, et vous découvrez la casse plusieurs jours plus tard, sur un écran que vous n'aviez pas rouvert depuis la modification. Retrouver quelle demande a produit quelle panne coûte alors plus cher que la panne.

Le périmètre, la parade la moins chère

Borner la demande coûte une ligne et se pratique dans n'importe quel outil, y compris ceux que nous recommandons pour les maquettes rapides. Nommez le fichier ou l'écran concerné, dites ce qui doit rester identique, demandez la liste de ce qui a été touché avant d'accepter. Sur une application de trois écrans, cette discipline suffit souvent, et l'outil de chat reste le chemin le plus rapide. Elle atteint sa limite le jour où votre produit a quinze écrans, des droits d'accès différents selon les comptes et des règles de calcul que vous êtes seul à connaître : vous ne pouvez plus tenir de tête la liste de ce qui doit rester intact.

Ce qu'un test écrit avant le code verrouille

Un test écrit avant la construction est une phrase vérifiable : « un client supprimé disparaît de la liste mais ses factures restent consultables ». Une fois cette phrase posée, elle vaut pour toutes les modifications suivantes, y compris celles que vous demanderez dans six mois. Chez Maestro, Félix écrit les tests d'une étape avant qu'Amélie n'écrive la moindre ligne, et une modification qui casse une phrase déjà posée s'arrête là, avec le nom de ce qu'elle a cassé. La mémoire de ce que le produit doit faire vit dans le cahier des charges et dans ces tests, pas dans votre souvenir de la conversation d'avant-hier.

Le filet en dessous : revenir à la version d'avant

Il reste que des choses passeront. Le second garde-fou consiste à pouvoir revenir en arrière sans négocier avec l'outil : Maestro garde une version de votre produit à chaque jalon et la timeline permet de retrouver l'état d'hier soir, documents compris, en un clic. Une modification devient alors un pari dont vous connaissez le coût maximal. Cette capacité manque à plusieurs générateurs à prompt, où le retour en arrière dépend de ce que la plateforme a bien voulu garder, et c'est l'un des cinq pièges documentés de la construction par IA.

En pratique

Ce soir, prenez la dernière modification qui a cassé quelque chose et écrivez en une phrase ce qui aurait dû rester intact. Vous venez d'écrire votre premier test. Faites-en autant pour les trois comportements dont dépend votre activité (l'inscription, le paiement, l'export de vos données) et gardez ces phrases dans un document que vous relisez avant chaque demande. Un meilleur modèle raccourcira la boucle ; il ne l'ouvrira pas à votre place.