Les tests de performance ne valent pas une preuve
Les agents de codage IA peuvent écrire du code, mais une équipe de développement a tout de même besoin d’une preuve que ce code a été produit dans le respect des contraintes appropriées, dans un environnement adapté et avec un niveau adéquat de supervision humaine. Cette preuve n’est pas une simple consigne. Il s’agit d’un harnais d’évaluation. L’explication d’Anthropic concernant les évaluations des agents IA est utile car elle met le doigt sur ce que les équipes ont souvent tendance à ignorer : un cadre d’évaluation est l’infrastructure qui exécute une évaluation de bout en bout. Il fournit des instructions et des outils, exécute des tâches en parallèle, enregistre les étapes, note les résultats et agrège les données. Une fois cette définition comprise, il devient difficile de prétendre qu’un score de benchmark à lui seul est très révélateur. Un score n’a d’importance que si le harnais correspond au type de travail que l’agent est censé effectuer. Pour les équipes logicielles, cela signifie généralement de véritables dépôts de code, de véritables appels d’outils, de véritables tests et de véritables modes de défaillance. Si l’environnement est synthétique ou indulgent, l’agent peut paraître plus intelligent qu’il ne l’est réellement. Si l’environnement est bruyant ou insuffisamment spécifié, il est impossible de déterminer si c’est le modèle qui s’est amélioré ou si la configuration a changé. Le but n’est pas de faire paraître les agents sous leur meilleur jour. Le but est de rendre leur comportement suffisamment lisible pour qu’un humain puisse garder le contrôle.
L’erreur que commettent de nombreuses équipes est de considérer le modèle comme le produit et le harnais comme un détail de mise en œuvre. Cela fonctionne pour des démonstrations ludiques. Mais cela s’effondre dès que l’agent est appelé à effectuer un véritable travail d’ingénierie. Un agent de codage n’est pas seulement un modèle qui écrit du texte ; c’est un système qui planifie, agit, observe, réessaie et finit par renvoyer un résultat que l’équipe peut accepter ou rejeter. La décision de confiance dépend de la qualité de l’appareil qui l’entoure. Si le harnais ne conserve pas les étapes, l’équipe ne peut pas rejouer la session. Si le harnais ne fixe pas l’environnement, l’équipe ne peut pas comparer les exécutions. Si le harnais n’encode pas clairement la tâche, l’agent s’optimisera en fonction du signal visible le plus facile plutôt que de l’objectif réel. C’est pourquoi le harnais doit être abordé dans le même contexte que le modèle. Le modèle est l’acteur. Le harnais est la scène, la caméra, la feuille de score et les règles du jeu.
Un bon harnais commence par un oracle explicite
Le travail logiciel est attrayant pour les agents car certaines de ses parties sont vérifiables. Une suite de tests peut indiquer si un correctif est validé. Un linter peut indiquer si le code enfreint les conventions. Un exécuteur de tâches peut indiquer si la commande s’est exécutée. Mais « vérifiable » ne signifie pas « évident en soi ». Quelqu’un doit encore décider à quoi ressemble la réussite. Cette décision constitue l’oracle. L’oracle est la réponse définie par l’humain que le harnais utilise pour noter l’exécution. Si l’oracle est faible, l’agent peut s’y surajuster. Si l’oracle est large mais vague, l’agent peut respecter la lettre de la tâche tout en passant à côté de l’essentiel. Un bon oracle est suffisamment précis pour être testable et suffisamment large pour couvrir ce qui importe réellement à l’équipe. C’est pourquoi un harnais sérieux comprend généralement non seulement des tests unitaires, mais aussi des contrôles d’acceptation, des contrôles de régression et une forme d’examen des transcriptions.
Voici le changement concret à opérer : ne demandez pas si l’agent « semble correct ». Demandez si la tâche peut être formulée de manière à ce qu’un autre ingénieur puisse la vérifier de manière indépendante. Si ce n’est pas le cas, le travail n’est pas prêt pour l’autonomie. Un réviseur humain devrait être capable de répondre à des questions telles que : quel comportement a changé, qu’est-ce qui est resté identique, quelles hypothèses ont été formulées, quelles données d’entrée ont été considérées comme fiables, et quel mode de défaillance entraînerait une annulation. Si l’on ne peut répondre à ces questions, l’agent n’a pas réellement accompli une tâche. Il n’a produit qu’un artefact plausible. La plausibilité n’est pas synonyme d’exactitude. En production, c’est l’exactitude qui importe, et celle-ci n’est réelle que lorsque l’oracle le confirme.
Si la tâche ne peut pas être testée, elle ne peut pas être déléguée à l’aveugle.
Séparer le créateur du juge
Les travaux de longue haleine d’Anthropic sur les harnais soulèvent un deuxième point que les équipes logicielles devraient prendre au sérieux : le modèle qui génère le travail et le modèle, l’outil ou le processus qui l’évalue ne doivent pas être identiques au même moment. Le générateur et l’évaluateur jouent des rôles différents. Le générateur excelle à produire des options, à mettre en place l’ossature et à faire avancer les choses. L’évaluateur excelle dans le scepticisme, la vérification des limites et la détection du genre de bug qui semble correct quand c’est vous qui l’avez écrit. Cette séparation est précieuse car les agents peuvent se montrer étonnamment indulgents envers leur propre production. Ils se convainquent qu’un test insuffisant suffit, qu’un raccourci risqué est acceptable ou qu’une imperfection n’est pas vraiment un bug. Les humains font de même, mais un évaluateur dédié peut être configuré pour résister à cette pression mieux que ne le peut l’auteur.
Ce n’est pas de la théorie. Les équipes qui développent des workflows d’agents s’exécutant sur le long terme ne cessent de constater que les progrès sont fragiles lorsqu’une seule session est chargée de tout faire. La meilleure approche consiste à décomposer le travail en parties gérables et à transférer des artefacts structurés d’une session à l’autre. Cela peut sembler plus lent, mais ce n’est généralement pas le cas. Cela réduit les retouches, facilite le débogage et empêche l’agent de se retrouver dans un état à moitié achevé qui semble productif mais dont il est difficile de se remettre. Pour les équipes de développement logiciel, l’équivalent consiste à séparer la mise en œuvre de la vérification. Laissez l’agent rédiger le code, mais confiez à un vérificateur la tâche de valider les propriétés importantes : le code passe-t-il les tests, enfreint-il la politique, étend-il les autorisations, modifie-t-il les limites du réseau, préserve-t-il la possibilité de retour en arrière ? L’humain évalue alors le risque réel, et non l’illusion de progrès.
Les récentes recommandations de GitHub concernant l’examen des pull requests générées par les agents vont dans le même sens. De plus en plus de pull requests générées par des agents sont validées plus rapidement que ne le permettent les capacités des réviseurs, ce qui signifie que les équipes doivent se montrer plus strictes quant à ce qui mérite leur attention. Le réviseur ne doit pas gaspiller son énergie à admirer la surface du patch. Il doit concentrer son énergie sur les endroits où un agent est le plus susceptible de dissimuler un risque : manipulation de l’intégration continue (CI), aides redondantes, extension insidieuse des autorisations, limites de portée inadéquates et chemins de retour en arrière incomplets. Cela n’est possible que si le harnais a déjà effectué un premier tri. L’automatisation effectue d’abord l’analyse. Les humains jugent le chemin critique.
Les tâches de longue durée nécessitent un artefact de transfert
L’une des leçons les plus importantes du codage agentique de longue durée est que le contexte est une ressource. Une tâche s’étendant sur des heures ou des jours ne peut pas reposer sur une seule invite gigantesque et une seule session ininterrompue. Elle nécessite un artefact de transfert : un résumé clair et structuré de ce qui s’est passé, de ce qui a échoué, de ce qui reste à faire et de ce que le successeur doit faire ensuite. Les articles d’Anthropic sur le « harness » insistent sur ce point, car l’agent ne dispose pas de mémoire au sens humain du terme. Chaque nouvelle fenêtre contextuelle risque de repartir de zéro, à moins que le flux de travail ne laisse derrière lui quelque chose de concret. En termes d’ingénierie, cela signifie des notes d’avancement, des points de contrôle, des résultats de tests et un état du dépôt pouvant être repris sans avoir à deviner.
Cela s’applique même à des tâches plus modestes qu’une compilation de plusieurs jours. Sans artefact de transfert, la personne ou l’agent suivant doit reconstituer le raisonnement précédent à partir de fragments : différences, journaux et peut-être une transcription de discussion. Ce processus est lent et source d’erreurs. Avec un artefact de transfert, l’équipe peut reprendre à partir d’un état connu. L’artefact doit indiquer ce qui a été tenté, pourquoi certaines voies ont été écartées, quel est le mode d’échec actuel et quelles preuves étayent le plan actuel. L’humain reste aux commandes, car il peut inspecter le travail sans avoir à le reconstituer à partir de zéro. La délégation devient durable lorsque le système conserve suffisamment d’état pour que les transferts de tâches soient peu coûteux.
Le bruit de l’infrastructure peut vous induire en erreur
Une autre leçon tirée des travaux d’évaluation d’Anthropic est que de faibles écarts de score méritent d’être considérés avec scepticisme, à moins que l’environnement ne soit soigneusement contrôlé. Leur analyse du bruit de l’infrastructure montre que la configuration des ressources à elle seule peut modifier les résultats du codage agentique de manière suffisamment significative pour avoir de l’importance. C’est un point crucial, car les équipes interprètent souvent un écart de benchmark comme s’il s’agissait d’une pure amélioration du modèle. Ce n’est parfois pas le cas. Il s’agit parfois simplement de marge de mémoire, d’allocation de CPU, de politique de sandbox ou d’une exécution chanceuse avec moins de défaillances d’infrastructure. Si vous modifiez le harnais, vous pouvez modifier le score sans changer la capacité sous-jacente. Si vous ne mesurez pas l’échafaudage, vous ne mesurez pas réellement l’agent.
Cela devrait changer la façon dont les équipes interprètent aussi bien les évaluations internes que les affirmations des fournisseurs. Un meilleur score est intéressant, mais seulement si vous pouvez expliquer les conditions dans lesquelles il a été obtenu. Quelles ressources étaient disponibles ? Quels éléments étaient verrouillés ? Qu’est-ce qui était autorisé à échouer et à réessayer ? Qu’est-ce qui était considéré comme une erreur d’infrastructure par opposition à une erreur de l’agent ? Si ces réponses ne sont pas claires, alors le score est trop flou pour servir de base à une politique. Le principe de l’intervention humaine s’applique ici également : on ne devrait pas obliger l’humain à se fier à un chiffre que l’équipe ne peut pas justifier. L’équipe doit être capable d’expliquer non seulement le résultat, mais aussi le système de mesure qui l’a produit.
Le contrôle humain est le dernier point de vérification
Rien de tout cela n’est anti-agent. C’est au contraire en faveur de la responsabilité. De bons cadres de contrôle rendent les agents plus utiles en leur donnant une voie à suivre. Ils permettent également à un humain de dire oui, non ou pas encore, avec des justifications qui seront visibles par la suite. C’est là la véritable valeur de la supervision humaine dans le développement assisté par l’IA. L’humain n’a pas besoin d’inspecter chaque ligne de sortie. Il doit maîtriser les limites, les critères d’acceptation et la décision de revenir en arrière. Si la tâche touche à des informations confidentielles, à l’environnement de production, aux autorisations ou à un comportement visible de l’extérieur, l’humain doit pouvoir intervenir. Si la tâche est ambiguë, l’humain doit pouvoir la préciser avant que l’agent ne s’oriente vers un objectif erroné. Si la tâche est terminée, l’humain doit tout de même examiner les preuves, car ce sont elles qui transforment une correction plausible en une modification déployée.
C’est pourquoi la bonne question n’est jamais « Le modèle peut-il faire cela ? », mais « Pouvons-nous vérifier cela suffisamment bien pour déléguer cette tâche ? ». Si la réponse est non, l’équipe ne doit pas rejeter la faute sur le modèle. Elle doit renforcer le dispositif de contrôle. Rédiger l’oracle. Enregistrer la transcription. Séparer le créateur du juge. Verrouiller l’environnement. Exigez un transfert de responsabilité clair. Puis maintenez un humain aux commandes au point de contrôle où le jugement est le plus crucial. L’autonomie ne s’obtient pas par l’enthousiasme. Elle se mérite par la vérification.
Liste de contrôle pratique
1. Define the oracle before the agent starts.
2. Freeze the environment and record resource limits.
3. Log every tool call, approval, and rollback decision.
4. Separate the agent that builds from the process that judges.
5. Require a human for secrets, production, permissions, and ambiguity.
6. Preserve a handoff artifact so the next session can resume safely.
7. Review the process, not only the final diff.Cette liste est volontairement simple. Ce sont les parties les plus rébarbatives qui garantissent l’intégrité du flux de travail. Un harnais facile à expliquer inspire généralement davantage confiance. Un flux de travail facile à reproduire est généralement plus facile à améliorer. Et un système qui rend explicite le rôle de l’humain a bien plus de chances d’évoluer en toute sécurité qu’un système qui prétend que le modèle a remplacé le jugement. Les meilleures équipes logicielles ne seront pas celles qui accordent le plus de liberté aux agents. Ce seront celles qui leur accordent suffisamment de liberté pour être productifs, tout en laissant l’humain fermement aux commandes des règles du jeu.
Sources
- Anthropic — Démystifier les évaluations des agents IA
- Anthropic — Des harnais efficaces pour les agents fonctionnant sur le long terme
- Anthropic — Quantifier le bruit de l’infrastructure dans les évaluations de codage des agents
- GitHub — Les pull requests des agents sont partout. Voici comment les examiner.
