Qui évalue l’évaluateur ? Validation des suites d’évaluation d’agents avant de leur faire confiance.

En 2026, presque toutes les équipes qui déployent des agents IA mettent également en place un ensemble d’outils d’évaluation, comprenant des tableaux de bord, des taux de réussite, des points de contrôle en intégration continue ainsi que des juges basés sur des modèles de langage grand public qui évaluent les performances selon des critères prédéfinis. Tout cela témoigne d’une rigueur certaine et semble marquer la différence entre un système en production et une démonstration qui a simplement fonctionné deux fois.

Cependant, si l’on pose la question suivante, tout devient plus silencieux : qui a vérifié que cet ensemble d’outils mesure bien ce qu’il faut, le mesure correctement et reste fiable six mois après sa création ? Presque personne. L’industrie a passé deux ans à développer des outils pour évaluer les agents, mais elle n’a à peine commencé à créer des outils pour évaluer ces outils eux-mêmes. Ce déficit se fait déjà sentir en production, de plusieurs manières prévisibles.

L’hypothèse que personne ne formule

Derrière la plupart des systèmes d’évaluation des agents se cache une hypothèse non exprimée : un résultat positif signifie que l’agent s’est comporté correctement, tandis qu’un résultat négatif indique le contraire. En acceptant cela, l’ensemble devient une boîte noire en laquelle les gens ont confiance automatiquement. Le tableau de bord affiche une couleur verte, les modifications sont fusionnées et l’équipe passe à autre chose.

Les recherches sur les traces d’activité des agents commencent à remettre en question cette prémisse. Une étude a examiné 58 traces qualifiées de réussies selon le système de notation des résultats et a constaté que 83 % de ces exécutions cachaient des violations procédurales ou de sécurité qui n’avaient jamais été détectées par ce système de notation. L’agent a fourni la bonne réponse et a obtenu une note parfaite, mais la méthode qu’il a utilisée était en réalité incorrecte. La distance entre le résultat final et le processus suivi est précisément ce que les systèmes d’évaluation sont conçus pour détecter, et c’est aussi précisément ce que la plupart de ces systèmes ne peuvent pas voir par conception.

Quatre modèles d’échec méritent des noms distincts. Chacun nécessite une solution propre, et les équipes ne remarquent généralement que celui qui les a affectées.

Dérive du juge. Tout ce qui est sémantique est souvent évalué par un LLM, car une vérification basée sur des règles ne peut pas déterminer si « vendredi prochain » a été converti en la bonne date. Mais le juge est lui aussi un modèle, et les modèles évoluent. Les équipes utilisant des suites de tests sur le long terme constatent souvent que l’ensemble du tableau de bord de régression se dégrade du jour au lendemain, perdent une journée à enquêter, avant de découvrir que les scores ont changé parce que le modèle du juge a été mis à jour et non parce que l’agent est devenu moins performant. Fixer une version du modèle du juge ainsi qu’un hash de la grille d’évaluation réduit le problème sans pour autant l’éliminer, car les points d’accès au juge hébergés continuent de changer.

L’erreur du résultat final. Se baser uniquement sur l’état final efface la partie intéressante d’un processus. Un agent peut utiliser l’outil incorrect, envoyer quatre fois le même argument erroné et parvenir malgré tout à la bonne réponse par chance ou persévérance, et un outil qui ne lit que le message final le considérera comme réussi.

Modèles d’échec internes. Des benchmarks publics tels que BFCL ou tau-bench aident à comparer les modèles, mais ils ne peuvent pas détecter les échecs survenant au sein du registre d’outils d’une équipe : une valeur nulle dans un champ optionnel, une erreur de fuseau horaire dans un argument de date, un déséquilibre monétaire dans un champ financier. De tels échecs relèvent des outils de l’équipe et ne figurent jamais sur un classement général. Si la couverture de test provient entièrement de benchmarks publics, le validateur reste aveugle justement là où cela compte, c’est-à-dire pour les parties du système que personne d’autre n’a testées.

Le point aveugle des coûts. Le moins abordé, et peut-être le plus crucial. Un système d’évaluation peut qualifier un agent comme précis dans chaque dimension qu’il prend en compte, sans jamais se demander si cet agent se rembourse lui-même. Un cas bien connu concernait un agent qui répondait aux douze critères de qualité, mais qui a été retiré du service en production, car chaque résolution réussie coûtait plus cher que le processus humain qu’il était censé remplacer. Les scores de qualité étaient exacts. Aucun indicateur n’existait pour répondre à la question qui a scellé son destin.

Un agent de réservation qui a obtenu la note parfaite mais a échoué

Imaginez qu’un agent de réservation soit chargé de trouver des vols pour « vendredi prochain ». Parmi une liste de dizaines d’outils, il en choisit le bon, ce qui lui vaut une note parfaite de 1,0 pour le choix de l’outil. Ensuite, il envoie la date sous forme de chaîne littérale sans d’abord interpréter l’expression relative. L’API répond par une erreur de validation, et l’agent envoie à nouveau cette même chaîne défectueuse quatre fois avant de s’excuser et de quitter.

Cette trace fournit deux valeurs : une note parfaite de 1,0 pour le choix de l’outil et une note de 0 pour l’achèvement de la tâche. Aucune de ces valeurs ne permet de déterminer ce qui a mal fonctionné : une extraction erronée des arguments, une réponse d’erreur que l’agent n’a jamais lue, ou une logique de tentative qui se répète avec des données inchangées. Une analyse approfondie de l’évaluation des appels aux outils a montré que se contenter de vérifier si le bon outil a été utilisé évalue l’intention plutôt que l’exécution, or c’est bien l’exécution qui a échoué.

C’est là tout le problème en miniature. Le jeu de tests a généré deux chiffres, aucun n’étant strictement faux, mais tous deux inutiles pour la seule question qui comptait : qu’est-ce qui doit être corrigé ?

Pratiques utiles

Lorsque le jeu de tests d’évaluation est considéré comme un système méritant ses propres contrôles de qualité, une configuration mature se distingue. Quelques habitudes permettent de distinguer les équipes qui détectent les problèmes tôt de celles qui les découvrent trop tard, à leurs dépens :

• Une couche de méta-évaluation propre à ce système. Dans les déploiements sérieux, le travail se divise désormais en évaluation des résultats, en évaluation de chaque étape du processus, ainsi qu’en une couche qui compare les évaluateurs entre eux, afin que la note d’un seul juge ne soit pas acceptée à la légère.
• Vérification basée sur l’exécution plutôt que sur la correspondance de texte. Les benchmarks les plus fiables analysent ce qui a réellement changé dans le monde. tau-bench lit l’état de la base de données, SWE-Bench exécute les vrais tests, et tau2-bench’s pass-at-k vérifie si un agent réussit de manière cohérente à travers plusieurs tentatives. Les suites développées localement devraient en faire de même et confirmer les changements réels, quel que soit le rapport de l’agent.
• Le coût à côté de la qualité. Le cas financier plaide pour suivre le coût par résultat réussi en tant que métrique clé, aux côtés de la précision, en le calculant dès le début plutôt que plus tard, lorsque le responsable du budget commence à poser des questions.
• Évaluation en plusieurs niveaux. Les évaluations complètes de bout en bout sont coûteuses car chaque tâche nécessite deux appels de modèles, celui de l’agent et celui du juge, et un ensemble de cent tâches avec cinq essais chacune double à peu près le coût total. Les équipes qui maîtrisent cette situation séparent les vérifications rapides, gratuites et déterministes qui s’exécutent à chaque mise à jour de celles, lentes et coûteuses, basées sur les juges et qui ne sont lancées que lorsque des modifications affectent l’agent.
• Un ensemble qui reste actif. Dans une enquête récente du secteur, la plupart des répondants ont indiqué que leurs évaluations ne donnaient pas les résultats escomptés parce que le trafic réel s’éloignait du jeu de test initial, rendant difficile son suivi. Un ensemble laissé inchangé depuis son lancement n’est pas inoffensif : il mesure un système qui a cessé d’exister.

Quatre actions à entreprendre pour un ensemble que vous possédez déjà

Pour une équipe disposant d’un ensemble d’outils d’évaluation qui souhaite les valider plutôt que de s’y fier simplement, quatre étapes permettent de combler la majeure partie des lacunes :

1. Prenez dix à vingt traces de production que l’outil a marquées comme réussies et lisez manuellement chaque trajectoire dans son intégralité, et non seulement la réponse. Le nombre de ces réussites cachant une faille procédurale constitue une mesure fiable de la confiance que l’on peut accorder au tableau de bord affichant des résultats positifs.
2. Identifiez précisément la version du modèle d’évaluation ainsi que le texte des critères d’évaluation, et enregistrez-les avec chaque score, afin qu’une mise à jour silencieuse du modèle d’évaluation apparaisse comme un événement clairement identifié plutôt que comme une régression mystérieuse.
3. Suivez le coût par résultat réussi dès le premier jour, même avant que quiconque ne le demande.
4. Créez un petit ensemble de cas de régression à partir de véritables pannes en production et non seulement de cas synthétiques. Les benchmarks publics fixent une base de référence, tandis que l’historique des incidents propre à l’équipe permet de prédire la prochaine panne embarrassante.

Rien de tout cela ne remplace le jeu de tests complet. Il s’agit simplement de cesser à traiter ce jeu de tests comme une composante trop importante pour être vérifiée.

Réponses rapides

Qu’est-ce que la validation du jeu de tests par eval signifie pour les agents ? Elle applique au système d’évaluation la même rigueur que celle que le système applique à l’agent, en se demandant si le juge, la grille d’évaluation et le processus de notation mesurent bien ce qu’ils prétendent mesurer.

Pourquoi les scores attribués par un LLM en tant que juge varient-ils ? Le juge est un modèle. Lorsque son fournisseur le met à jour ou le remplace par une version plus récente, les scores peuvent changer même si l’agent évalué n’a pas changé.

Les benchmarks publics peuvent-ils remplacer un jeu de tests personnalisé ? Non. Ils aident à comparer les modèles sur des tâches courantes, mais ils ne permettent pas de détecter les défauts liés aux outils, aux données ou aux cas particuliers d’une équipe donnée.

Un taux élevé de réussite suffit-il à maintenir un agent en production ? Pas à lui seul. Un agent peut obtenir de bons résultats en termes de précision et de qualité de trajectoire, mais il peut néanmoins être retiré si le coût par résultat réussi ne justifie pas la valeur qu’il apporte.

À quelle fréquence le logiciel doit-il être révisé ou reconstruit ? Continuellement, au fur et à mesure que le trafic de production évolue. L’utilisation s’éloigne du jeu de tests initial, il est donc nécessaire que des cas issus de défaillances réelles soient intégrés régulièrement, et non seulement au moment du lancement.

La justification derrière le tableau de bord

Une suite d’évaluations n’est pas une preuve que l’agent fonctionne. C’est une affirmation sur ce que signifie « fonctionner », écrite par celui qui l’a conçue, notée par un juge dont les critères peuvent évoluer, sur un ensemble de tests qui commence à vieillir dès sa création. Considérer cette affirmation comme évidemment vraie explique pourquoi des agents qui réussissent tous les tableaux de bord échouent encore à la question vraiment importante. Une revue manuelle de dix traces, comme décrit ci-dessus, montre rapidement à quel point les tableaux de bord ont dissimulé des informations.