Quatre-vingt-quatorze pour cent des responsables jugent le code produit par IA de meilleure qualité que le code écrit par des humains au moment de la revue, et pourtant 82 % d’entre eux subissent au moins une panne en production liée à ce code 1. Tout se joue dans cet écart, et je pense que la plupart des équipes le lisent à l’envers. Le réflexe consiste à traiter la dette d’agent comme un problème de qualité de code et à y répondre par une revue plus stricte, ou par un relecteur IA greffé sur le diff. D’expérience, c’est le mauvais levier : la qualité perçue en revue est découplée de la fiabilité en production, donc la dette d’agent relève du placement de la vérification. La bonne réponse est de déplacer la frontière de confiance de la revue vers l’exécution.
La revue note le mauvais examen
Une revue mesure une seule chose : si un diff paraît correct à quelqu’un qui ne peut pas l’exécuter face à la production. Sur du code produit par IA, cette mesure est flatteuse. Les responsables le jugent de meilleure qualité que ce qu’écrivent leurs propres ingénieurs, et 62 % l’expédient sans vérification manuelle ligne à ligne 1. On est tenté de ranger ces 62 % au rayon du laxisme, des équipes qui coupent les coins, et d’en conclure qu’elles devraient simplement relire plus sévèrement.
Lisons-le autrement. Ces 62 % qui sautent la vérification relèvent moins de la négligence que d’une préférence révélée : les équipes font déjà assez confiance au signal de la revue pour agir dessus. Le signal semble fort, le diff paraît propre, donc la passe manuelle paraît redondante. L’effort est bien là ; il vise un signal qui ne l’a pas mérité. La vraie question n’est pas de savoir si les équipes relisent assez. C’est de savoir si ce que la revue mesure prédit ce qui leur importe réellement, or les chiffres de production disent que non.
Pourquoi la qualité en revue ne prédit pas la fiabilité en production
Un diff statique expose un ensemble borné de propriétés : lisibilité, structure plausible, respect d’un style, compilation et passage des tests existants. Ces propriétés sont réelles, et pour du code écrit par un humain elles corrèlent assez bien avec son comportement, parce que l’auteur porte un modèle implicite du système en fonctionnement jusque dans le diff. Le code produit par un agent casse cette corrélation. L’agent optimise pour un artefact d’apparence plausible, et la plausibilité est exactement l’axe que la revue évalue.
Ce que la revue ne voit pas, c’est ce que la production met à l’épreuve : un état qui ne s’accumule que sous trafic réel, une charge qui modifie les temps de réponse, l’intégration avec des services que le diff ne mentionne jamais, et un comportement qui dérive avec le temps. Prenons un mode de défaillance concret. Un agent écrit une routine de préchauffage de cache qui passe la revue sans accroc : elle se lit bien, elle a des tests, sa structure est saine. Elle suppose aussi que le service en aval renvoie les résultats dans l’ordre d’insertion, un invariant qui tient dans la fixture de test, tient sous faible charge, et se rompt silencieusement sous la concurrence de production. Fixer le diff des yeux ne révèle jamais ce défaut, parce que l’information qui le trahirait, la garantie d’ordre réelle du service en aval sous charge, n’est pas dans l’artefact relu. On ne peut pas extraire par inspection d’un diff une défaillance que le diff ne contient pas.
L’addition tombe à l’exécution
Voici le chiffre qui sépare la sévérité de la revue du résultat. Lightrun, en interrogeant une population différente de 200 SRE et responsables DevOps, a constaté que 43 % du code produit par IA nécessite encore un débogage manuel en production après avoir passé la QA ou la préproduction 2. Ce code a franchi une porte, exécuté les tests, traversé la préproduction, et cassé malgré tout.
Cela recadre tout le débat. Si les défaillances se limitaient au code ayant sauté la revue, la lecture pro-revue l’emporterait : appliquez la porte que vous sautiez. Mais le défaut surgit de l’autre côté d’une porte franchie, ce qui signifie que la porte ne mesurait jamais la propriété qui a lâché. Et c’est à l’exécution que la vérification coûte vraiment. Confirmer un seul correctif suggéré par l’IA demande en moyenne trois cycles de redéploiement manuel, et 88 % des entreprises ont besoin de deux à trois cycles rien que pour établir qu’un correctif fonctionne 2. La vérification n’a pas disparu quand la revue a laissé passer le code ; elle s’est déplacée en production et y est devenue plus chère.
« Relisez plus sévèrement, ou ajoutez un relecteur IA »
L’objection la plus forte ne concède rien de tout cela et pointe le chiffre des 62 %. Si la plupart des équipes expédient sans vérification ligne à ligne, alors la revue est simplement sous-appliquée. Les pannes de production pourraient n’être que le résultat prévisible d’une revue laxiste, et l’inférence honnête serait la banale : ceux qui bâclent la relecture se brûlent, donc relisez davantage. Les chiffres de perception semblent renforcer l’argument, puisque les 94 % de satisfaction et les 82 % de panne sont des pourcentages de population, pas des mesures appariées sur le même code relu, si bien qu’à eux seuls ils ne prouvent pas le découplage. Énoncée à pleine force, c’est la lecture vers laquelle un sceptique rigoureux devrait se tourner d’abord.
Elle succombe à un seul chiffre. Les 43 % qui exigent encore un débogage en production l’exigent après avoir passé la QA ou la préproduction 2. Voilà justement la preuve appariée qui manquait à l’objection : du code qui a démontrablement franchi une porte, sur la population même où la revue a été appliquée, échoue quand même à l’exécution. Une seconde passe statique, relecteur humain plus strict ou relecteur IA, remesure le même signal découplé sur le même artefact. Elle ne peut pas récupérer une information que l’artefact ne porte pas. Le mode de défaillance tient au placement, pas à la rigueur, et davantage de rigueur au mauvais endroit ne rapporte qu’un gain borné, souvent dérisoire.
Déplacer la frontière de confiance de la revue vers l’exécution
Si la revue ne peut pas certifier le comportement en production, cessons de le lui demander. La vraie porte est là où le comportement défaillant devient observable : à l’exécution. Cela veut dire des déploiements canari qui exposent le changement au trafic réel avant qu’il n’en devienne responsable, une observabilité qui surveille les points d’intégration qu’un diff n’a jamais montrés, et des boucles de redéploiement et vérification traitées comme l’étape de certification plutôt que comme un coût à réduire. Ces trois cycles de redéploiement ne sont pas du gaspillage à éliminer ; ils sont la vérification qui a enfin lieu là où se trouve la preuve.
New Relic fournit le mécanisme sous son propre nom. La firme appelle cette accumulation « dette d’agent », l’entassement d’une logique architecturale non vérifiée que la revue félicite pour sa vélocité 1. Prenez cette définition au pied de la lettre : la thèse du placement s’y trouve déjà. La logique est non vérifiée non parce que personne n’a regardé, mais parce que la surface regardée, le diff, n’expose pas le comportement architectural et d’intégration. La dette est une vérification pointée sur le mauvais artefact.
De meilleurs modèles et de meilleurs relecteurs continueront d’arriver, et ils valent la peine. Mais aucun ne comble un écart qui tient à l’endroit où vous placez le contrôle plutôt qu’à la force avec laquelle vous l’appuyez. Déplacez la frontière vers l’exécution, et la revue à laquelle vous faites déjà confiance pourra revenir à la tâche bornée qu’elle sait réellement bien faire.