L’IA casse votre code à chaque correction ? Sortir de la boucle

Vous demandez à l’IA de corriger un bouton. Elle le corrige. Mais maintenant, la connexion ne marche plus. Vous lui demandez de réparer la connexion : c’est fait, sauf que le tableau de bord est vide. Trois heures et une bonne poignée de crédits plus tard, vous êtes revenu au point de départ, avec un peu moins de patience.

Si ce scénario vous parle, rassurez-vous : vous n’êtes ni seul, ni mauvais utilisateur. C’est le passage quasi obligé des projets qui grandissent avec Lovable, Bolt, v0, Cursor ou ChatGPT. La bonne nouvelle, c’est qu’on peut en sortir, et que ça ne passe pas forcément par l’abandon de l’IA.

Pourquoi l’IA casse ce qui marchait

Comprendre le mécanisme aide beaucoup à choisir la bonne réponse. Cinq causes reviennent presque à chaque fois.

Elle ne voit pas tout votre projet

Au début, le projet tient en quelques fichiers et l’IA en a une vue complète. Passé une certaine taille, elle n’en lit qu’une partie à chaque demande. Elle modifie donc un morceau sans voir ce qui en dépend ailleurs, un peu comme un électricien qui refait une prise sans avoir le plan de la maison.

Rien ne signale la casse

Dans un projet professionnel, des tests automatiques vérifient à chaque modification que les fonctions essentielles marchent toujours. Un prototype généré par IA n’en a généralement aucun. La casse passe donc inaperçue jusqu’à ce que vous (ou un utilisateur) tombiez dessus.

Le code s’est empilé par couches

Chaque demande ajoute du code sans toujours nettoyer l’ancien. On se retrouve avec trois versions de la même fonction, dont une seule est réellement utilisée. L’IA corrige l’une, l’application continue d’appeler l’autre, et le bug « corrigé » est toujours là.

Elle réécrit au lieu de retoucher

Pour changer une ligne, l’IA régénère volontiers un fichier entier. Au passage, elle « simplifie » un détail qu’elle jugeait inutile et qui ne l’était pas.

Elle soigne le symptôme

Face à une erreur, la réponse la plus rapide est souvent de la faire taire : masquer le message, contourner une vérification, voire désactiver une règle de sécurité « pour que ça marche ». Le problème disparaît de l’écran, pas du projet. Ce dernier point mérite d’ailleurs un coup d’œil à la checklist sécurité, car c’est ainsi que naissent beaucoup de failles.

Six réflexes pour sortir de la boucle

Ces habitudes ne demandent aucune compétence technique particulière, et elles changent réellement la donne.

1. Revenir en arrière plutôt que corriger la correction

Quand une modification casse quelque chose, le réflexe est de demander à l’IA de réparer. Mauvaise idée : vous empilez une rustine sur une rustine. Revenez plutôt à la dernière version qui fonctionnait (historique de Lovable ou Bolt, ou Git) et reformulez la demande initiale.

2. Une demande, un changement

« Corrige le formulaire, ajoute un filtre et change les couleurs » multiplie les risques. Une demande par changement, petite et précise, se vérifie facilement et se défait tout aussi facilement.

3. Délimiter le terrain

Dites explicitement ce qui ne doit pas bouger : « modifie uniquement le composant du formulaire de contact, ne touche à rien d’autre ». Ça paraît évident, mais sans cette consigne l’IA se sent libre d’« améliorer » ce qu’elle croise.

4. Décrire le problème, pas la solution

Donnez le comportement attendu, le comportement observé, et le message d’erreur exact (copié, pas résumé). « Quand je clique sur Valider, rien ne se passe et la console affiche telle erreur » vaut bien mieux que « répare le bouton ».

5. Écrire les règles du projet une fois pour toutes

La plupart des outils permettent de fournir un document de référence que l’IA relit à chaque demande (la « Knowledge » de Lovable, les règles de Cursor, etc.). Décrivez-y les choix structurants : où sont les données, comment fonctionne la connexion, ce qu’il ne faut jamais modifier. L’IA arrête de réinventer ce qui existe déjà.

6. Vérifier vos parcours clés après chaque changement

Listez les trois à cinq actions vitales de votre application (s’inscrire, se connecter, payer, créer un élément…) et refaites-les après chaque modification. Deux minutes de vérification manuelle évitent des heures de recherche le lendemain.

Quand ces réflexes ne suffisent plus

Ces habitudes règlent beaucoup de situations. Mais certains signes montrent que le problème n’est plus dans la façon de demander, il est dans la structure du projet lui-même :

• le même bug revient, sous une forme ou une autre, après chaque correction ;
• vous ne savez plus quelle partie du code est réellement utilisée ;
• vous n’osez plus ajouter de fonctionnalité de peur de tout casser ;
• le projet a de vrais utilisateurs, et chaque régression vous coûte leur confiance.

À ce stade, continuer à prompter revient à repeindre un mur qui s’effrite. Ce qu’il faut, c’est un assainissement : cartographier ce qui existe, supprimer les doublons, remettre de l’ordre dans les données et poser des tests sur les parcours critiques. C’est le cœur de la fiabilisation d’un projet créé avec l’IA.

Et c’est là que l’histoire devient intéressante : sur une base saine, l’IA redevient l’outil formidable qu’elle était au début. Les demandes aboutissent du premier coup, parce qu’elle travaille enfin sur un projet qu’elle peut comprendre.