Quand les agents écrivent le code, le bouton d'approbation ne veut plus rien dire

L'hypothèse qui s'est brisée en silence

La revue de code repose sur une prémisse si ancienne que personne ne la formule à voix haute : un autre ingénieur a écrit le code. Un essai publié sur DEV.to soutient que cette prémisse n'est plus fiable. Un agent de codage peut désormais implémenter une fonctionnalité, exécuter les tests, corriger les échecs, remanier le résultat et préparer la pull request. L'humain qui ouvre cette PR a peut-être passé son temps à diriger et à relire l'agent plutôt qu'à taper quoi que ce soit.

La conclusion de l'auteur n'est pas que la revue est obsolète. C'est l'inverse : la vérification compte plus que jamais. Ce qui s'est brisé, c'est la comptabilité. Dans l'ancien flux, l'ingénieur A écrit, l'ingénieur B relit, la modification est fusionnée. Dans le flux agentique, l'agent écrit, l'ingénieur A relit, l'ingénieur A ouvre la PR. Si l'ingénieur A a réellement examiné la modification et accepte d'en répondre, l'essai demande ce qu'une seconde approbation humaine générique apporte vraiment. Ouvrir une PR ne rend pas le code plus digne de confiance. L'événement significatif s'est produit avant que le bouton n'existe.

Ce que la revue apportait réellement

La revue a toujours rempli deux fonctions à la fois. La première est la détection de défauts : une seconde personne repère un bug, une mauvaise abstraction, remet en question un choix d'architecture. La seconde est sociale : la responsabilité partagée et la diffusion des connaissances, pour que le code n'appartienne pas à une seule personne. L'essai reconnaît que les deux restent précieuses. Mais il soutient qu'elles ne sont pas servies de la même façon quand l'auteur est une machine.

Le modèle mental qu'il propose est celui du pair faillible : imaginez un collègue extrêmement rapide, qui connaît énormément de choses en matière de logiciel, mais qui est novice dans votre système particulier et commet parfois des erreurs qui paraissent évidentes après coup. Vous ne fusionneriez pas son travail à l'aveugle. Vous fixeriez des contraintes, lanceriez des vérifications automatisées, et feriez appel à un spécialiste pour les changements qui comptent. C'est déjà, note l'auteur, ce à quoi ressemblent les flux de travail agentiques.

D'où cette phrase qui devrait mettre mal à l'aise les responsables d'ingénierie : le nombre de boutons d'approbation pressés n'est pas la même chose que la quantité de vérification effectuée. Les équipes qui exigeaient une revue pourraient raisonnablement considérer qu'une modification d'agent soigneusement relue est complète. Celles qui en exigeaient deux pourraient conserver un relecteur après la PR. La politique devrait suivre le risque : une migration de base de données, une modification d'authentification ou un flux de paiement ne se résument pas à l'intitulé d'un bouton.

Le goulot d'étranglement se déplace, il ne disparaît pas

L'enjeu plus large est le volume. Générer du code est devenu considérablement moins cher. Le relire, non. Si un agent produit dix fois plus de code et que la réponse consiste à faire inspecter dix fois plus de code par des humains, la contrainte se déplace simplement de l'écriture du logiciel vers sa vérification. L'attention humaine est la ressource rare, et elle ne s'achète pas aux prix des agents.

La réponse de l'essai consiste à réduire ce qui nécessite des yeux humains. Certaines classes de bugs ne devraient pas dépendre d'un relecteur qui les remarque : elles devraient être impossibles à exprimer. Une contrainte de base de données impose une règle pour qu'aucun développeur n'ait à s'en souvenir. Un flux de travail qui ne peut passer que de En attente à Approuvé ou Rejeté devrait être modélisé par des états explicites, et non par des chaînes arbitraires que chaque chemin de code espère gérer. Les machines à états finis, les types, les contrats, les frontières d'API, l'analyse statique et le code généré font tous le même travail : le but n'est pas de rendre les développeurs plus attentifs, mais de rendre certaines erreurs impossibles.

Par-dessus viennent la vérification automatisée, puis l'ingénieur qui prend la responsabilité, puis une couche facultative que l'auteur appelle les agents adversariaux : des spécialistes dont le rôle n'est pas de dire « LGTM » mais d'attaquer. Un agent de sécurité qui traque les contournements d'autorisation et les chemins d'injection. Un agent de performance qui cherche les requêtes N+1, les contentions et les appels réseau excessifs. D'autres pour la fiabilité, la rétrocompatibilité, la conception d'API, les tests, l'accessibilité. Ils ne prouvent rien ; ce sont aussi des pairs faillibles. Ce qu'ils offrent, c'est une autre tentative indépendante de trouver un problème, assemblée pour chaque modification plutôt qu'appliquée uniformément. La vérification devient composable : plus de contrôle sans cycle de livraison plus long ni davantage d'humains dans la file d'attente.

Qui est exposé par cette évolution ? Toute équipe dont le discours sur la qualité est en réalité un discours de conformité : deux approbations sur chaque PR, quel que soit le risque. Cette politique continuera de produire des coches vertes tandis que le volume de code non examiné qui se trouve dessous grandit. Et la fonction sociale de la revue, la partie de diffusion des connaissances dont l'essai dit explicitement qu'elle reste importante, n'a pas de remplaçant évident si l'on supprime le second relecteur par souci d'efficacité sans rien mettre à la place.

Les questions à vous poser

• Quand votre ingénieur ouvre une PR pour du code écrit par un agent, peut-il expliquer pourquoi l'implémentation a cette forme, ou seulement que les tests sont passés ?
• Parmi vos règles de revue actuelles, lesquelles existent parce qu'elles détectent des défauts, et lesquelles existent parce qu'un auditeur ou un rapport d'incident a exigé un chiffre ?
• Quelle part de ce que vos relecteurs vérifient à l'œil pourrait être imposée par une contrainte de schéma, un type ou une machine à états explicite, et qui en est responsable ?
• Si vous supprimez le second relecteur humain, qu'est-ce qui remplace le partage de connaissances que la revue assurait discrètement pour votre équipe ?
• Quand un agent adversarial de sécurité ou de performance dit que tout va bien, que croit votre équipe que cela signifie, et cette croyance est-elle consignée quelque part ?

Ce qu'il faut surveiller ensuite

Surveillez si les équipes commencent à différencier leur politique de revue selon le type de modification plutôt que d'appliquer le même nombre d'approbations à tout. Le signe révélateur, c'est une migration, une modification d'authentification ou un chemin de paiement qui bénéficie d'un pipeline de vérification visiblement plus lourd qu'un ajustement d'interface. Si le nombre d'approbations reste stable alors que le volume de fusions grimpe, la politique est devenue du théâtre, et le premier incident imputable à du code que personne n'a réellement lu sera celui qui le prouvera.