Évaluations continues : le système d’exploitation des agents de codage

L’ancien pacte avec les assistants de codage était simple : ils suggéraient une ligne, vous plissiez les yeux, et peut-être que personne ne se blessait. Aujourd’hui, les agents de codage peuvent appeler des outils, modifier l’état du système et traverser un dépôt comme un stagiaire très sûr de lui avec un accès root. Les impressions ne sont plus une stratégie d’assurance qualité. Ce sont une bougie parfumée dans une soufflerie.

Le cadrage utile proposé par LetsLearnGenAI est que les évaluations sont en train de devenir le système d’exploitation du codage assisté par l’IA. Pas la couche applicative brillante, pas le papier peint de classement, mais la surface de contrôle qui indique aux équipes ce qui a changé, ce qui s’est cassé, et si l’agent doit continuer à travailler ou recevoir une petite brique de jus et être raccompagné hors du pipeline de build.

Anthropic donne la définition ennuyeuse dont nous avons besoin

Anthropic définit une évaluation comme un test pour un système d’IA : fournir une entrée, puis appliquer une logique de notation à la sortie afin de mesurer la réussite. Dans son article d’ingénierie du 09 janvier 2026, Anthropic explique que de bonnes évaluations aident les équipes à livrer des agents avec plus de confiance en rendant les échecs et les changements de comportement visibles avant qu’ils n’atteignent les utilisateurs. L’entreprise souligne aussi pourquoi les agents sont plus difficiles à mesurer que les chatbots : ils fonctionnent sur de nombreux tours, appellent des outils, modifient l’état du système et s’adaptent en fonction des résultats intermédiaires.

@title Structure d’évaluation
@source Demystifying evals for AI agents

  Input
    │
    ▼
  AI system
    │
    ▼
  Output
    │
    ▼
  Grading logic
    │
    ▼
  Success measure

@caption Anthropic décrit les évaluations comme une entrée, une sortie, une logique de notation et une mesure de réussite.

Cette définition semble presque offensivement simple, et c’est précisément pour cela qu’elle compte. Les agents travaillant sur des dépôts ne se contentent pas de prédire le prochain token : ils entreprennent des actions dans des environnements remplis de tests fragiles, de dépendances inquiétantes et d’un fichier nommé final_final_really.py. Si vous ne pouvez pas rejouer une tâche et noter le résultat de manière cohérente, vous n’adoptez pas un agent. Vous en invoquez un.

Le type de tâche est la variable sournoise

Une étude arXiv stratifiée par type de tâche a comparé OpenAI Codex, GitHub Copilot, Devin, Cursor et Claude Code sur 7 156 pull requests issues du jeu de données AIDev. L’article a montré que le type de tâche avait un effet important : les tâches de documentation atteignaient 82,1 % d’acceptation, tandis que les nouvelles fonctionnalités atteignaient 66,1 %, soit un écart de 16 points de pourcentage qui dépassait la variance habituelle entre agents pour la plupart des tâches. Il indiquait aussi que Devin présentait la seule tendance positive constante du taux d’acceptation, à 0,77 % par semaine sur 32 semaines, tandis que les autres agents restaient globalement stables.

C’est la partie que les équipes devraient se faire tatouer à l’intérieur de leur tableau de bord CI. Choisir un agent de codage selon son score moyen à un benchmark, c’est comme choisir un restaurant selon le nombre de fourchettes dans le tiroir. Votre suite d’évaluations locale devrait séparer les tâches selon le travail que vous faites réellement : documentation, corrections de bugs, refactorisations, migrations, tests et nouvelles fonctionnalités. Sinon, l’agent qui semble brillant sur de petites tâches de maintenance faciles risque de grignoter discrètement votre architecture comme un raton laveur dans une salle serveur.

Les évaluations en production ont besoin de tâches à la forme de la production

L’article REAP soutient que le déploiement en production d’agents de codage IA nécessite des signaux d’évaluation rapides et reproductibles. Il explique que les tests A/B en ligne peuvent prendre des semaines et mettre en risque l’expérience utilisateur, que le déploiement en mode shadow ne produit pas de signaux reproductibles d’une exécution à l’autre, et que les benchmarks publics peuvent s’écarter des charges de travail réelles en matière de distribution des langages, de style de prompt et de structure de base de code. REAP propose de constituer automatiquement des benchmarks dérivés de la production à partir de vraies sessions développeur-agent, sans étiquetage manuel.

C’est le pont entre les évaluations de recherche et une discipline opérationnelle. Une évaluation d’équipe utile n’est pas un musée de problèmes casse-tête : c’est une suite de régression vivante construite à partir du désordre que votre base de code produit réellement. L’article REAP signale aussi des pièges pratiques : prompts impossibles à tester, tests mal alignés et tests instables peuvent compromettre la fiabilité. Traduction : si votre évaluation ne peut pas distinguer un mauvais agent d’un mauvais test, félicitations, vous avez construit une machine à brouillard avec du YAML.

Les benchmarks sont nécessaires, mais insuffisants

ProjDevBench insiste sur une autre faiblesse : le développement de projet de bout en bout. Selon son résumé arXiv, le benchmark fournit des exigences de projet à des agents de codage et évalue les dépôts obtenus à l’aide de tests de type Online Judge et d’une revue de code assistée par LLM. Il couvre 20 problèmes de programmation dans 8 catégories, évalue six agents de codage et rapporte un taux d’acceptation global de 27,38 %.

Ce faible taux d’acceptation n’est pas une raison de paniquer, mais une raison de définir le périmètre avec responsabilité. L’article indique que les agents gèrent les fonctionnalités de base et les structures de données, mais rencontrent des difficultés avec la conception de systèmes complexes, l’optimisation de la complexité temporelle et la gestion des ressources. Pour les bâtisseurs, l’action pratique est évidente : commencez par des tâches étroites, à signal fort, dont la correction peut être vérifiée, puis élargissez seulement lorsque vos évaluations montrent que l’agent s’améliore. L’autonomie sans mesure, c’est juste de l’autocomplétion portant un trench-coat.

Garder l’humain dans la boucle, idéalement éveillé

L’article Agents That Teach ajoute un mode d’échec plus subtil mais important : l’apprentissage des développeurs. Il soutient qu’à mesure que les développeurs délèguent des tâches de codage substantielles à des agents autonomes, l’apprentissage incident peut être court-circuité, créant ce que les auteurs appellent une dette de connaissances. L’article propose six principes de conception et présente SHIELD, un système multi-agent conçu pour faire émerger un apprentissage contextuel, en dehors du flux principal, à partir du raisonnement propre de l’agent de codage.

C’est important, car les évaluations devraient mesurer plus que le fait que les tests soient au vert. Les équipes doivent aussi se demander si les développeurs peuvent expliquer le changement, le maintenir, et remarquer quand l’agent invente avec assurance une minuscule cathédrale d’absurdités. La prochaine étape pratique n’est pas de bâtir un immense empire d’évaluations. Construisez une petite suite locale, exécutez-la sur de vraies tâches, stratifiez par type de tâche, suivez les régressions et continuez à ajouter des cas issus des ratés en production.

Si l’agent doit conduire, les évaluations sont le volant, pas les dés en peluche.