« Mon application a cassé après une modification » : pourquoi l'IA casse ce qui marchait

Pourquoi ça arrive

Un outil d'IA ne « connaît » pas votre application comme un développeur qui l'a construite. À chaque demande, il relit une partie du code, celle qu'il juge utile, et réécrit ce qu'il pense devoir changer. Trois mécanismes expliquent les régressions :

• il ne voit pas tout : une fonction utilisée à trois endroits est modifiée pour le premier, et les deux autres cassent ;
• il réécrit plus que nécessaire : pour ajouter un bouton, il régénère tout le fichier, et une règle discrète disparaît au passage (une vérification, une limite, un cas particulier) ;
• rien ne vérifie le résultat : sans tests, la seule vérification est votre regard, sur l'écran que vous regardiez, pas sur les autres.

Le résultat est souvent invisible sur le moment. Le paiement fonctionne encore dans votre test, mais le remboursement ne marche plus, et vous l'apprendrez par un client.

Protection 1 : pouvoir revenir en arrière

Avant tout, assurez-vous de pouvoir revenir à la version d'hier en quelques minutes :

• activez la synchronisation avec un dépôt Git (GitHub, le plus souvent) dont vous êtes propriétaire : chaque modification y laisse une trace, et l'on peut revenir à n'importe quel état ;
• apprenez où se trouve l'historique des versions dans votre outil, et faites l'essai de restaurer une version une fois, à froid.

Protection 2 : essayer avant vos clients

Une modification ne devrait jamais arriver directement chez vos clients. Il vous faut un endroit pour essayer : une préproduction, une branche de test, une copie de l'application avec des données fictives. Ce que vous y vérifiez, ce n'est pas seulement l'écran modifié, mais les parcours qui comptent : s'inscrire, payer, annuler, se faire rembourser, et ce que fait l'administrateur.

Protection 3 : des tests sur les parcours critiques

C'est la protection la plus efficace, et la plus souvent absente. Un test automatique rejoue un parcours (« un client réserve et paie ») et échoue si le résultat change. Pas besoin de tout tester : cinq à dix tests sur les parcours qui portent l'argent et les données suffisent à attraper l'essentiel des régressions.

Branchés sur votre déploiement, ils bloquent une mise en ligne qui casserait l'un de ces parcours. Vous pouvez même demander à votre outil d'IA d'écrire ces tests ; c'est l'un des usages où il est le plus utile, à condition que quelqu'un relise ce qu'ils vérifient vraiment.

Protection 4 : des règles écrites pour l'outil

La plupart des outils acceptent des instructions permanentes pour le projet (connaissances du projet, fichier de règles, consignes) qu'ils relisent à chaque demande. Écrivez-y ce qui ne doit jamais changer :

• « ne jamais modifier les règles d'accès de la base sans le signaler » ;
• « ne jamais mettre de clé secrète dans le code du navigateur » ;
• « tout paiement est confirmé par le webhook signé, jamais par la page de retour » ;
• « ne modifier que les fichiers nécessaires à la demande ».

L'outil ne les respectera pas parfaitement, mais beaucoup mieux que sans.

Protection 5 : des demandes petites et précises

Une demande vague (« améliore la page de paiement ») autorise l'outil à tout réécrire. Une demande précise (« ajoute un champ code promo sous le total, sans toucher au calcul du prix ») limite les dégâts. Après chaque modification, regardez quels fichiers ont changé : si l'outil a touché à un fichier qui n'a rien à voir avec votre demande, vérifiez pourquoi.

Ce que ce guide ne couvre pas

Les défauts déjà présents dans l'application, introduits par les modifications précédentes, et que personne n'a remarqués. Les protections ci-dessus empêchent d'en ajouter de nouveaux ; pour faire l'inventaire de ceux qui existent, voir notre liste de contrôle avant la mise en production, ou notre diagnostic. Installer ces protections est aussi ce que nous faisons dans le cadre de la garde, notre maintenance au mois.