Les agents supplantent le relecteur, pas la relecture

En juin 2026, Martin Monperrus, chercheur en génie logiciel connu pour ses travaux sur la réparation automatique de programmes, a publié un article intitulé The End of Code Review: Coding Agents Supersede Human Inspection. L’argument est que les agents de codage ont franchi un seuil de capacité où faire examiner un diff par un humain avant la fusion n’est plus une étape de contrôle qualité nécessaire, et que la configuration courante où les agents écrivent le code tandis que les humains restent les relecteurs obligatoires est une impasse.¹

L’article a raison sur bien plus de points que ses détracteurs ne l’admettront, et il se trompe sur un point précis qui compte. Les agents ont supplanté le relecteur : l’humain qui lit un diff ligne par ligne à la recherche de défauts fait un travail qu’un ensemble d’agents accomplit désormais mieux et à chaque commit. Mais l’article confond ce rôle avec la relecture elle-même. Lorsque vous exécutez réellement le pipeline d’agents qu’il préconise, le travail humain ne disparaît pas. Il se déplace, de l’inspection du code vers la responsabilité de l’intention que le code était censé satisfaire. J’exécute ce pipeline. Le relecteur se meurt. La relecture remonte dans la pile.

Je veux prendre cet article au sérieux, parce que la plupart des réponses qui lui seront faites ne le feront pas. La réplique réflexe est « mais les agents hallucinent », et Monperrus le concède déjà. L’engagement honnête commence par reconnaître ce qu’il a raison de dire.

En bref

• Monperrus soutient que les agents de codage ont mis fin au besoin de relecture humaine de code, parce que chaque objectif de la relecture (détection des défauts, style, sécurité, transfert de connaissances) est mieux et plus économiquement servi par les agents, et que la capacité de relecture humaine ne peut pas évoluer au rythme du débit que permettent les agents.¹
• Il a raison de dire que la case à cocher de l’approbation humaine obligatoire est révolue, et raison de dire que les agents font une inspection systématique mieux qu’un humain fatigué survolant un gros diff.
• Il n’est pas naïf à ce sujet : l’article concède l’hallucination, l’injection de prompt, la corrélation des angles morts en sécurité, et réserve les humains aux changements à haut risque, inédits, réglementés et éthiques.¹
• La lacune tient à ce qu’il traite le rôle humain résiduel comme un petit ensemble d’escalades. En production, c’est le centre porteur : l’agent optimise la spécification qu’on lui a donnée, et rédiger cette spécification et en assumer la responsabilité est l’acte humain irréductible.
• Le rôle de relecteur est en cours d’automatisation. La relecture, entendue comme le jugement sur la justesse du logiciel au regard de sa finalité, se déplace là où l’agent ne peut pas suivre.

Ce que l’article a raison de dire

Monperrus s’appuie sur l’énumération, par Bacchelli et Bird, des raisons pour lesquelles les équipes relisent le code : détection des défauts, application du style et des normes, transfert de connaissances et sensibilisation de l’équipe, la sécurité venant comme cinquième dimension.¹² Sa démarche consiste à reprendre chaque objectif et à soutenir qu’un agent le sert mieux. Les agents inspectent chaque commit sans fatigue ni décalage horaire. Ils énumèrent les classes de vulnérabilités de façon plus systématique qu’un humain procédant à une passe improvisée. Ils génèrent des résumés architecturaux et une documentation mise à jour au moment de la fusion. L’article mobilise la courbe de capacité de SWE-bench pour étayer la thèse du seuil, depuis le meilleur modèle résolvant moins de 2 pour cent des vrais tickets GitHub au lancement du benchmark en 2023, jusqu’aux meilleurs agents dépassant 70 pour cent fin 2025.¹³

Je n’ai aucune querelle avec cette partie, parce que je la regarde fonctionner au quotidien. Ma boucle de build autonome exécute un contrôle à trois relecteurs : des agents distincts vérifient la justesse, les conventions et la sécurité avant la fusion du code, et une seconde boucle envoie l’implémentation à un modèle indépendant pour une passe contradictoire. Ces agents attrapent de vrais défauts, et ils les attrapent à chaque changement, pas seulement sur les changements pour lesquels un humain avait le temps. Les deux articles qui ont précédé celui-ci sur ce site ont chacun passé un évaluateur agent qui les a notés selon une grille et a signalé des problèmes factuels précis que j’ai ensuite dû corriger. L’affirmation de l’article selon laquelle les agents produisent une sortie de relecture exploitable et structurée, comparable à celle d’un relecteur formé, n’a rien de spéculatif pour moi. C’est mon ordinaire.

L’argument du débit est lui aussi juste, et c’est la partie que l’on sous-estime. Un développeur assisté par agent produit plus de pull requests par jour que la capacité de relecture humaine ne peut en absorber. Lorsque l’auteur est rapide et que le relecteur est un humain, la file d’attente de relecture devient la contrainte limitante, et la relecture se dégrade en formalité exécutée sous la pression du temps.¹ Monperrus a raison de dire que l’arrangement naïf, les agents écrivent et un humain tamponne, n’apporte aucune assurance réelle. Un humain qui approuve parce que le code a l’air correct et que les tests passent ne fait pas de relecture. Il signe.

Le pipeline qu’il décrit est celui que j’exécute

Ce que l’article propose pour remplacer la relecture humaine n’est pas « faire confiance à un seul modèle ». C’est un pipeline de vérification avec agents dans la boucle : plusieurs agents indépendants, idéalement des modèles différents, produisant une validation calibrée et structurée (couverture de tests, analyses de sécurité, traces de raisonnement au format JSON ou SARIF, le format d’échange standard pour les résultats d’analyse statique) plutôt que des fils de commentaires informels, les agents étant chargés de s’abstenir en cas d’incertitude et les humains réservés aux cas difficiles.¹

C’est, sous d’autres noms, l’architecture que je construis et au sujet de laquelle j’écris depuis un an. J’ai soutenu que les pull requests d’agents ont besoin de surfaces de relecture plus petites, que la relecture automatisée a besoin de dissension plutôt que d’un juge unique et assuré, et que des paquets de relecture de preuves structurées remplacent le commentaire de diff informel. Je ne m’oppose donc pas au pipeline. J’ai contribué à le défendre. Je discute de ce qu’il reste à faire pour l’humain une fois le pipeline en place, parce que j’ai vécu dans la réponse, et ce n’est pas la réponse que donne l’article.

Là où l’argument se brise : la relecture n’a jamais été seulement de l’inspection

Monperrus réserve l’humain aux changements à haut risque, à l’architecture inédite, aux chemins de code réglementés et au jugement éthique, et il présente cela comme une escalade : des exceptions acheminées vers une personne lorsque les agents les signalent.¹ Cette présentation fait paraître le rôle humain comme une interruption rare sur une chaîne par ailleurs automatisée.

Faire tourner la chaîne enseigne le contraire. L’agent ne génère pas sa propre finalité. Il optimise la spécification qu’on lui remet, et à chaque changement qui compte, quelqu’un doit décider ce que signifie « correct » avant que les agents puissent vérifier quoi que ce soit par rapport à cela. L’article lui-même admet la frontière dans sa partie discussion : les agents optimisent des métriques de qualité technique et ne sont pas en mesure de remarquer de façon fiable qu’un changement de télémétrie viole l’attente raisonnable de confidentialité d’un utilisateur, ou qu’un ajustement de classement amplifie un biais.¹ Cela est présenté comme une limite à la marge. Ce n’est pas à la marge. La question « ce changement est-il correct au regard de ce que nous voulons vraiment » se trouve au cœur de chaque fusion non triviale, et c’est précisément la question qu’un agent calibré sur une spécification ne peut pas poser au sujet de la spécification.

J’ai ressenti cela concrètement sur les deux articles que j’ai publiés avant celui-ci. Le relecteur agent les a notés et a attrapé un excès factuel dans chacun : une affirmation institutionnelle non vérifiée dans l’un, une statistique mal attribuée dans l’autre. La détection revenait à l’agent. La correction, non. Décider comment corriger un excès de façon véridique, quelle source soutenait réellement l’affirmation, quelle était la version honnête de la phrase, exigeait un jugement sur l’intention que la grille pouvait signaler mais non résoudre. L’agent a trouvé que quelque chose n’allait pas. Un humain a décidé à quoi ressemblait le « juste ». Cette répartition du travail est le déplacement, et il s’est produit sur du contenu courant, non sur un cas limite réglementé.

L’humain ne quitte donc pas la boucle. L’humain passe de la fin au début. La relecture était autrefois le dernier point de contrôle, une personne inspectant du code achevé. Dans un pipeline d’agents, l’inspection est automatisée et le travail humain irréductible se déplace vers l’amont : spécifier l’intention assez précisément pour que les agents aient quelque chose de vrai à vérifier, et assumer les conséquences lorsque le résultat livré respecte la spécification mais manque l’essentiel. La responsabilité ne peut pas être déléguée à un système qui optimise des métriques, parce que la responsabilité est la volonté de se tromper délibérément et d’en répondre.

La version honnête de l’affirmation

Retirez la provocation du titre et l’affirmation défendable est plus étroite que « la fin de la relecture de code ». L’affirmation défendable, c’est la fin de l’humain comme inspecteur de diff et case à cocher d’approbation obligatoire. Ce rôle est réellement révolu, et prétendre le contraire pour protéger un rituel confortable est en soi une malhonnêteté. Les équipes qui maintiennent un humain au poste d’inspection comme un simulacre, approuvant du code d’agent qu’elles ne peuvent pas réellement scruter, ont déjà perdu l’assurance qu’elles croient avoir.

Mais « relecture de code » a toujours été un mot de substitution. Il nommait un point de contrôle et signifiait un jugement : ce changement fait-il ce dont nous avons besoin, en toute sécurité, d’une manière que nous pouvons assumer. Automatisez le point de contrôle et le jugement ne s’évapore pas. Il se déplace vers la spécification de l’intention à l’entrée et la responsabilité à la sortie, et dans une équipe avançant à la vitesse des agents, il devient plus important, non moins, parce que les agents construiront fidèlement et rapidement tout ce que dit la spécification, y compris la mauvaise chose. Plus l’auteur est rapide, plus le goulot d’étranglement devient le fait de savoir quoi demander. Monperrus a raison de dire que le relecteur est en train d’être supplanté. Il a tort de dire que la relecture prend fin. Elle se déplace vers le seul siège que l’agent ne peut pas occuper.

Points clés à retenir

Pour les responsables ingénierie : - Cessez d’affecter de la relecture humaine à l’inspection de diff. Les agents le font mieux et en continu ; une case d’approbation humaine sur du code d’agent est un simulacre d’assurance. - Réaffectez cette capacité humaine à la spécification de l’intention et à la responsabilité, les parties de la relecture qui déterminent si « correct au regard de la spécification » est « correct en fait ».

Pour les concepteurs d’outils de développement : - Construisez le pipeline de relecture par ensemble que l’article décrit : plusieurs modèles, abstention calibrée, validation structurée. La dissension entre relecteurs est le signal. - Concevez l’amont du pipeline, pas seulement le contrôle. La surface à plus forte valeur est celle où un humain transforme l’intention en une spécification que les agents peuvent vérifier.

Pour les ingénieurs : - Votre compétence en relecture ne devient pas inutile ; elle change d’adresse. La valeur passe du repérage du bug dans le diff à la définition de ce que le code était censé faire et à la responsabilité du résultat.

FAQ

Cet article signifie-t-il que la relecture humaine de code est finie ?

L’humain comme inspecteur de diff ligne par ligne et approbateur obligatoire, c’est fini, ce qui est le point le plus fort de l’article : les agents font l’inspection systématique mieux et à chaque commit. Ce qui ne finit pas, c’est le jugement dont la relecture de code était un substitut, à savoir la justesse d’un changement au regard de sa finalité réelle. Ce jugement se déplace vers la spécification de l’intention et la responsabilité des conséquences, plutôt que de disparaître.

Que soutient réellement Monperrus ?

Que les agents de codage servent désormais chaque objectif déclaré de la relecture de code (détection des défauts, style, transfert de connaissances, sécurité) à moindre coût et avec un débit plus élevé, et que maintenir les humains comme relecteurs obligatoires du code écrit par des agents est une impasse, parce que cela n’apporte aucune assurance réelle et ne peut pas passer à l’échelle. Il propose un ensemble d’agents produisant une validation structurée, les humains étant réservés aux cas à haut risque et éthiques. C’est un article de position, non une étude empirique.¹

Où l’argument est-il le plus faible ?

Dans le fait de traiter le rôle humain résiduel comme une escalade rare. En pratique, le rôle humain est porteur à chaque changement non trivial, parce que l’agent optimise une spécification qu’il ne peut ni rédiger ni questionner. Définir la spécification et répondre du résultat est un travail central, non un cas limite.

Les équipes doivent-elles maintenir une étape d’approbation humaine sur les pull requests des agents ?

Pas en tant que simulacre d’inspection. Si l’humain ne peut pas réellement scruter le changement, l’approbation est une signature, non une relecture. Mieux vaut investir l’effort humain en amont, dans la spécification précise de l’intention, et en aval, dans la responsabilité du résultat livré, tout en laissant un ensemble d’agents faire l’inspection.

Sources

• Martin Monperrus, « The End of Code Review: Coding Agents Supersede Human Inspection », arXiv, 11 juin 2026 : arxiv.org/abs/2606.13175. Un article de position synthétisant les preuves de capacité existantes ; il énumère les objectifs de la relecture de code d’après Bacchelli et Bird, cite la courbe de capacité de SWE-bench, et discute des limites, notamment l’hallucination, l’injection de prompt et la responsabilité éthique.
• Alberto Bacchelli et Christian Bird, « Expectations, Outcomes, and Challenges of Modern Code Review », ICSE 2013, la source empirique de la taxonomie des objectifs de relecture sur laquelle l’article s’appuie : Microsoft Research
• Carlos E. Jimenez et al., « SWE-bench: Can Language Models Resolve Real-World GitHub Issues? », ICLR 2024, le benchmark à l’origine de la courbe de capacité (le meilleur modèle résolvait 1,96 % au lancement) : arxiv.org/abs/2310.06770
• Écrits connexes sur la relecture par agents tirés de l’expérience en production : surfaces de relecture plus petites, la relecture a besoin de dissension, paquets de relecture, et la boucle de build autonome dont le contrôle à trois relecteurs est le pipeline dont cet article décrit l’exécution.