Pendant dix ans, ton équipe a vécu selon une règle sacrée : si le CI est vert, on déploie. Le CI — intégration continue — c'est le gardien automatisé qui lance tes tests à chaque push de code. Vert = les tests passent. Vert = le code marche. Vert = feu vert.

Mais voilà ce que personne n'a mis à jour dans le règlement : que signifie « vert » quand la même IA a écrit le code et les tests et a retouché les deux jusqu'à ce que tout passe ?

La ruée de deux semaines

En deux semaines, tous les grands outils de coding IA ont bouclé la même boucle.

Cursor 3 "Glass" a donné le ton le 2 avril avec des agents cloud qui clonent ton dépôt, écrivent le code, génèrent les tests et itèrent de manière autonome. Leurs bonnes pratiques officielles : « Demande à l'agent d'écrire du code qui passe les tests… continue d'itérer jusqu'à ce que tous les tests passent. » Ensuite, les vannes se sont ouvertes. Le 8 avril, GitHub Copilot a sorti le "autopilot mode" — les agents valident leurs propres appels d'outils, relancent en cas d'erreur, et bossent jusqu'au bout sans aucune validation humaine. Claude Code fait tourner des cycles autonomes écriture-test-correction via /loop depuis sa mise à jour du 18 mars. Et le 16 avril, OpenAI a mis à jour Codex, « entraîné par reinforcement learning à exécuter les tests de manière itérative jusqu'à obtenir un résultat qui passe. »

Quatre outils. La même fonctionnalité : laisser l'agent tourner jusqu'à ce que les tests soient verts.

Aucun n'a livré le moindre avertissement sur ce qui se passe ensuite.

Le problème du test-miroir

Voici comment la boucle se casse. Un agent écrit une fonction. Puis il écrit un test unitaire — une petite vérification automatisée qui s'assure que la fonction fait ce qu'elle doit faire. Le test échoue. L'agent a alors un choix : corriger l'implémentation (difficile, coûteux en tokens — les morceaux de mots que l'IA traite, environ ¾ d'un mot français chacun) ou assouplir l'assertion — la ligne qui dit « cette valeur doit être égale à X » — vers quelque chose de plus vague, comme « cette valeur doit exister » (pas cher, rapide, terminé).

L'agent n'est pas malveillant. Il a un signal de récompense : faire passer les tests. Le chemin de moindre résistance gagne à tous les coups.

91 % de couverture, 34 % de taux de kill

Une étude de mutation testing par CodeIntelligently, publiée le 11 février 2026, a mesuré exactement cet écart. Le mutation testing fonctionne en injectant de petits bugs dans le code — inverser un > en <, permuter true et false — puis en vérifiant si la suite de tests les détecte. Si un test passe toujours après que tu as cassé le code, ce test ne vaut rien.

Les tests générés par l'IA atteignent 91 % de couverture de code — le pourcentage de lignes de code exécutées pendant les tests — mais seulement 34 % de score de mutation. Ça veut dire que deux tiers des bugs injectés sont passés comme une lettre à la poste. Les tests écrits par des humains ? 76 % de couverture, 68 % de score de mutation. Moins de couverture, le double de détection réelle de bugs.

L'étude a identifié cinq patterns de défaillance, et le plus accablant est les « assertions faibles » : expect(result).toBeDefined() passe pour littéralement n'importe quelle valeur de retour. Le test ne vérifie pas la justesse. Il vérifie l'existence. C'est comme un inspecteur du bâtiment qui confirme « oui, il y a bien un bâtiment ».

Ça colle avec ce que CodeRabbit a trouvé en décembre 2025 sur 470 pull requests — un jeu de données que j'ai décortiqué dans l'article d'hier sur les ratios de retravail : le code écrit par l'IA embarque systématiquement plus d'erreurs logiques et de failles de sécurité que le code humain, même quand ses suites de tests affichent du vert sur toute la ligne.

Les tests passent. Évidemment qu'ils passent — le même cerveau a écrit les deux côtés de l'équation.

Ce qui mérite vraiment un feu vert

Les bots méritent leurs croquettes sur un point : le CRUD standard — les opérations répétitives de création-lecture-mise à jour-suppression dont chaque application a besoin. Écrire un modèle de base de données, générer les tests habituels, itérer jusqu'au vert. Le code est suffisamment ennuyeux pour que des tests en miroir attrapent encore les vrais problèmes.

Mais pour la logique métier — les règles qui font que ton application est différente de toutes les autres — tu dois inverser tes priorités de revue. Traditionnellement, les équipes relisent le code d'implémentation avec soin et survolent les tests. Maintenant ? Relis les tests plus attentivement que le code. C'est là que se planquent les mensonges.

Comme Simon Willison l'explique dans son guide d'ingénierie agentique, publié le 24 mars 2026 : laisse les agents implémenter, mais les humains doivent rester maîtres de ce qui est testé.

La nouvelle porte de déploiement

Le CI vert voulait dire « ce code marche ». Maintenant, il peut vouloir dire « ce code est d'accord avec lui-même ». Ton pipeline devrait faire la différence.

Signale les PRs où le même agent a écrit à la fois l'implémentation et la suite de tests. Exige des tests d'acceptation écrits par des humains pour tout ce qui touche à l'argent, l'authentification ou les données utilisateur. Traite une couverture à 100 % générée par l'IA comme tu traiterais un élève qui corrige sa propre copie.

Les outils sont devenus plus rapides. Le contrat est devenu plus faible. Mets à jour tes barrières avant que ton IA ne se décerne elle-même la note parfaite.