Le code écrit par un agent : qui vérifie son travail ?

On peut confier une tâche à un agent, attendre qu’il apporte des modifications au dépôt et recevoir une ébauche de pull request à examiner. Mais le code soulève aussi une question : le résultat correspond-il à la tâche, et les tests ont-ils laissé passer un problème important ?

Le 4 février 2026, GitHub a annoncé la préversion publique de Claude et Codex comme agents de programmation. L’entreprise a indiqué qu’on pouvait leur attribuer des tâches à partir d’issues et de pull requests, puis examiner l’ébauche de PR qu’ils préparent. Cela confirme que ce scénario est désormais intégré à l’interface de développement, mais ne prouve ni un gain de temps ni une amélioration de la qualité du code.

La question n’est donc pas seulement de savoir si un agent est capable d’écrire du code. Il faut aussi se demander quel travail la personne doit accomplir autour de la tâche déléguée : fixer des limites, suivre le déroulement et évaluer le résultat.

La supervision ne se limite pas à la vérification finale

Dans un prépublication mis en ligne sur arXiv le 21 septembre 2026, des chercheurs proposent d’envisager la supervision d’un agent de programmation comme un processus séquentiel. L’étude The Work Behind Delegation s’appuie sur des observations et des schémas de processus de travail recueillis auprès de 19 développeurs expérimentés. Les auteurs décrivent sept étapes de supervision et appliquent ce cadre à des discussions publiques de développeurs sur Reddit.

Parmi les approches décrites par les auteurs figurent le fait d’accorder davantage d’importance à la planification, de confier certaines tâches de supervision à d’autres agents et de transformer des consignes récurrentes en ressources réutilisables. Il s’agit d’un cadre d’analyse, et non d’une mesure du temps consacré : l’étude ne détermine pas combien de temps les développeurs passent à superviser, ni si ce processus est plus rapide qu’un travail manuel. La page arXiv indique que le prépublication est en cours d’évaluation par les pairs ; ses conclusions doivent donc être considérées comme préliminaires.

Pour la pratique, il est utile de distinguer trois actions. La définition de la tâche fixe l’objectif et les contraintes. Le suivi permet de repérer si l’agent s’écarte de l’intention. La vérification sert à évaluer si le résultat peut être accepté au regard des exigences, du code et des tests. Réussir une étape ne garantit pas la réussite de la suivante : un correctif peut sembler plausible tout en répondant à la mauvaise tâche ou en nécessitant d’importantes retouches.

Les expériences de la communauté ne sont pas des statistiques

Dans une discussion sur r/LocalLLaMA, un participant a écrit que son expérience des modèles locaux et des agents avait été décevante : selon lui, il fallait corriger les résultats et rappeler les consignes aux agents. D’autres participants du même fil ont décrit une méthode qui leur convenait davantage : limiter la portée des tâches, avancer par étapes et vérifier attentivement le code. Ce sont des témoignages individuels, et non un test comparatif de modèles ou une mesure de la productivité des équipes.

Ces avis divergents montrent que l’expérience peut varier selon la tâche, le modèle, l’environnement et la méthode de travail. Mais une seule discussion ne permet pas de déterminer quelles pratiques sont les plus efficaces en moyenne ni à quelle fréquence des problèmes surviennent. Le fil porte sur les modèles locaux ; ses observations ne doivent donc pas être automatiquement généralisées à tous les outils agentiques.

La participation humaine ne signifie pas en soi que la délégation est inutile. Un développeur peut décomposer une tâche, vérifier les modifications et préciser les exigences, tout en restant responsable du résultat final. Mais sans tenir compte du temps consacré à définir la tâche, aux corrections et à la revue, impossible de dire si la charge de travail totale a diminué.

Une ébauche de PR n’est pas encore une PR acceptée

Dans le scénario décrit par GitHub, on peut attribuer une issue à un agent et obtenir une ébauche de pull request. Entre sa création et son acceptation, plusieurs questions restent à régler : la modification répond-elle aux exigences, les cas limites ont-ils été pris en compte, les tests sont-ils suffisants et la solution est-elle adaptée à l’architecture du projet ?

Ces critères ne peuvent pas être réduits à une seule mesure. Le nombre de modifications créées n’est pas le nombre de modifications utilisables, et des tests réussis ne confirment pas nécessairement toutes les propriétés importantes d’un correctif. Même un résultat qui semble de qualité ne permet pas, à lui seul, de savoir combien de travail a été nécessaire pour le préparer et le vérifier.

Pour évaluer l’effet global, il faut prendre en compte tout le cycle : définition de la tâche, attente du résultat, revue, corrections et maintenance ultérieure du code. Les sources examinées ne fournissent pas de comparaison globale de ce type.

Ce qu’on peut en conclure

Le prépublication propose un cadre pour parler de supervision, et GitHub a annoncé un scénario dans lequel on attribue une tâche à un agent puis on examine la PR préparée. La discussion sur Reddit montre que certains utilisateurs font état à la fois de difficultés et de méthodes de travail qui leur sont utiles avec les modèles locaux. Ensemble, ces éléments permettent de se demander comment organiser la vérification du code délégué, mais ils ne répondent pas à la question de la productivité nette.

On ne peut pas en conclure que les développeurs, dans leur ensemble, sont déjà passés de l’écriture de code à la supervision, que les agents ajoutent systématiquement du travail ou qu’ils accroissent la productivité du secteur. Pour étayer de telles conclusions, il faudrait des mesures comparables du temps et de la qualité, pour différentes tâches et différentes équipes.

Pour une équipe, la question pratique est plus précise : quelles modifications un agent peut-il préparer de manière autonome, que faut-il vérifier avant la fusion et qui est responsable de s’assurer que le résultat répond à la tâche initiale ? La délégation ne supprime pas ce travail d’ingénierie ; elle change le moment où il commence et les aspects sur lesquels il se concentre.