Quand le code écrit par IA casse la production : le schéma des post-mortems

Quand du code écrit par un agent IA casse la production, le post-mortem raconte presque toujours la même histoire. Le code était plausible et les tests passaient. La revue a été rapide parce que le diff était gros et propre. L’hypothèse fausse portait sur un comportement que personne ne testait. Et au moment de l’incident, personne ne pouvait expliquer le code. Nous avons relu assez de ces post-mortems chez nos clients pour décrire le schéma de mémoire, et pour en tirer la conclusion qui dérange : l’agent a écrit le bug, et le processus l’a approuvé.

Un incident de ce type signifie que le changement a suivi le même chemin que tout ce que vous livrez, et qu’un maillon a dit oui. La question intéressante est lequel, et pourquoi.

Le code était plausible et les tests étaient verts

La scène type : un traitement nocturne réécrit par un agent, quelques centaines de lignes nettes, nommage impeccable, commentaires à jour, tests au vert. Le code généré ressemble à du bon code, parce que le modèle a appris sur une quantité immense de bon code, et la forme ne dit rien de la justesse. Des tests verts ne disent rien non plus des comportements que la suite ne couvre pas : l’agent a itéré jusqu’au vert, et le vert ne contenait pas le cas qui a cassé.

La revue a approuvé un diff qu’elle n’a pas lu

Un diff de plusieurs centaines de lignes, cohérent, bien découpé en commits, arrive en fin de journée chez un relecteur qui en a quatre autres en attente. Il lit le début avec attention, survole le reste, voit la CI verte, approuve. La revue de code est devenue le goulot d’étranglement des équipes outillées, et ce goulot se débouche de la pire façon : l’approbation est réelle, la lecture ne l’est pas. La propreté du diff a joué contre lui ; un diff brouillon aurait été relu de près.

L’hypothèse fausse portait sur ce que personne ne testait

Quand on remonte à la cause, elle tient en une ligne et se trouve toujours à une frontière du système. Un calcul de date qui supposait l’heure locale alors que le serveur tourne en UTC, découvert au changement d’heure. Une boucle qui gérait bien dix éléments et mal zéro. Un appel vers une API tierce dont la limite de débit n’existe dans aucun environnement de test. Une migration qui passait sur une base vide et verrouillait une table volumineuse en production.

Dans chaque cas, l’agent a fait une hypothèse raisonnable et l’a implémentée avec soin. Dans chaque cas, personne ne l’avait énoncée dans la tâche, et aucun test ne la vérifiait. Les tests sont la première chose à déléguer à un agent, à condition qu’ils décrivent un comportement attendu plutôt qu’une ligne à couvrir.

Personne ne pouvait expliquer le code pendant l’astreinte

Le moment le plus coûteux se joue à deux heures du matin. L’ingénieur de garde ouvre le module, et personne ne sait lui dire pourquoi il est écrit ainsi : l’auteur du ticket a délégué, relu en diagonale, mergé. Le diagnostic traîne parce que le code est à la fois étranger et récent. C’est la forme la plus directe de la dette que le code généré fabrique quand le processus ne suit pas : du code que l’équipe possède sans le comprendre.

Ce que ces post-mortems changent dans la pratique

Les équipes qui en sortent renforcées font six choses, et aucune ne consiste à bannir l’outil. Des tâches plus petites, pour qu’un diff se relise en une seule séance. Des tests qui couvrent le comportement et non la ligne, avec les invariants énoncés dans la tâche confiée à l’agent (le fuseau, le cas vide, la limite, le volume). Une revue qui lit l’intention : le relecteur demande ce que le changement est censé faire avant de regarder comment il le fait, et la profondeur de relecture suit le risque du chemin modifié. Un auteur humain qui répond de chaque diff, la mention "généré par l’agent" aidant le relecteur sans rien transférer. Des guardrails en CI que ni un développeur pressé ni un agent ne contournent : couverture sur les lignes modifiées, taille de diff, scans, déploiements progressifs. Et un post-mortem sans blâme qui traite l’agent comme n’importe quel outil : "l’agent a écrit un bug" vaut comme cause racine ce que vaut "le stagiaire a écrit un bug", c’est-à-dire rien, et la question reste quel garde-fou aurait dû attraper cette classe d’erreur.

Deux réactions aggravent la situation. L’interdiction déplace l’usage vers des comptes personnels, hors de vue, sans aucun garde-fou. La règle "double revue pour tout code généré" regarde le mauvais axe : le risque doit décider de la profondeur de la revue, et non l’auteur, dont la part est de toute façon mixte dans un workflow agentique.

Les équipes qui mènent bien ce post-mortem en sortent avec un pipeline plus solide et, contre l’intuition, plus de délégation, parce que la confiance dans les garde-fous la rend sûre. Rien n’oblige à attendre l’incident : ce travail tient dans la méthode de déploiement que nous déroulons en six à huit semaines, et c’est la première brique de notre accompagnement des équipes, celle qu’on préfère poser avant que l’astreinte ne la réclame.