Évaluer un agent IA : tests, métriques et benchmarks

Pour évaluer un agent IA, vérifiez le résultat obtenu, les actions exécutées et les ressources consommées sur un jeu de tâches représentatif. Répétez les essais dans un environnement contrôlé, puis confrontez ces mesures aux incidents et aux résultats observés en production. Les benchmarks publics servent à sélectionner des candidats ; votre protocole doit déterminer si l’agent convient à votre usage et à vos contraintes.

Définir ce que signifie réussir

Une réponse convaincante ne prouve pas qu’une tâche est accomplie. Un agent peut annoncer une mise à jour sans avoir enregistré le fichier, modifier le mauvais dossier ou terminer correctement après une action interdite. L’évaluation de modèle doit donc être complétée par une évaluation du système qui agit.

Rédigez un contrat de réussite avant de lancer les essais. Il précise l’état initial, la demande, les permissions, le résultat attendu et les conditions d’arrêt. Une tâche ambiguë produit surtout des désaccords entre évaluateurs.

Prenons un scénario fictif : préparer une relance pour une facture impayée. Réussir signifie retrouver la bonne facture, vérifier son statut, utiliser le destinataire autorisé et enregistrer un brouillon. Envoyer le message constitue un échec si la consigne impose une validation.

Distinguez trois objets :

Le résultat : l’état final correspond-il à la demande ?
Le comportement : les contraintes et les permissions ont-elles été respectées ?
Le service rendu : le délai, le coût et la charge de correction sont-ils acceptables ?

Définissez aussi les abstentions correctes. Demander une précision devant des coordonnées contradictoires peut être une réussite. Inventer la donnée manquante pour terminer rapidement doit être pénalisé.

Les fiches de l’annuaire des agents IA aident à identifier les capacités annoncées ; le contrat de réussite traduit ces capacités en conditions vérifiables.

Construire un jeu de tests représentatif

Partez des tâches réellement prévues, avec leurs documents, leurs outils et leurs difficultés. Des demandes artificiellement propres donnent une image trop favorable du fonctionnement quotidien. Recueillez des exemples autorisés, retirez les données sensibles inutiles et faites valider les résultats attendus par une personne qui connaît le métier.

Répartissez les cas entre demandes courantes, situations limites et échecs contrôlés. Incluez les informations manquantes, les documents contradictoires, les permissions insuffisantes, les outils indisponibles et les demandes hors périmètre. Pour un agent documentaire, variez également les langues, les formats et l’ancienneté des sources.

Ajoutez des variantes proches : changement de destinataire, date différente, document presque identique. Elles permettent de vérifier que l’agent utilise les données du cas au lieu de reproduire une réponse mémorisée.

Séparez les usages du corpus :

Ensemble	Fonction	Accès pendant les réglages	Évolution
Développement	Comprendre et corriger les erreurs	Consultable	Enrichissement fréquent
Validation	Départager les configurations	Usage limité	Renouvellement contrôlé
Test réservé	Estimer la performance finale	Tenu à l’écart	Version figée pour la comparaison
Régression	Protéger les comportements acquis	Consultable	Ajout après correction validée

Évitez les doublons entre ensembles, y compris les variantes d’un même document. Une séparation par client, dossier ou période peut mieux protéger le test qu’un tirage aléatoire.

Conservez enfin deux lectures : une performance pondérée selon les usages observés et des résultats par catégorie. Les cas rares mais graves doivent rester visibles, même lorsqu’ils pèsent peu dans la moyenne.

Décrire chaque cas et contrôler l’environnement

Une fiche de test doit permettre à une autre personne de comprendre pourquoi un essai passe ou échoue. Elle contient un identifiant stable, la catégorie, les entrées, les données de référence, les actions autorisées, les actions interdites et les vérifications finales.

Précisez les variantes acceptables. Deux brouillons peuvent exprimer correctement la même demande avec des formulations différentes. À l’inverse, un identifiant de facture ou un montant exige une vérification exacte.

Le résultat attendu doit rester inaccessible à l’agent. Placez les scripts de correction et les réponses de référence hors de son espace de travail, avec des droits distincts.

Avant chaque essai, restaurez les fichiers, la base de données, les comptes de test et la mémoire. Sinon, une exécution peut bénéficier des modifications laissées par la précédente. Documentez également l’horloge et les dépendances externes lorsqu’elles influencent la tâche.

Deux environnements répondent à des besoins différents :

Un environnement figé facilite la comparaison : documents archivés, réponses d’outils enregistrées, données restaurées.
Un environnement connecté révèle les difficultés réelles : pages modifiées, délais réseau, authentification, indisponibilités.

Conservez les deux. Le premier aide à attribuer une régression ; le second mesure la robustesse face aux dépendances. Une panne d’outil reste un échec du service rendu, mais doit recevoir une catégorie distincte pour guider la correction.

Mesurer qualité, fiabilité, coût et délai

Le taux de réussite est nécessaire, mais insuffisant. Il doit être accompagné du nombre de tâches, du nombre d’exécutions et de la règle de correction. Un taux calculé uniquement sur les essais terminés masque les interruptions et les dépassements de budget.

Utilisez un tableau de bord dont chaque indicateur correspond à une décision :

Dimension	Mesure	Ce qu’elle révèle	Limite à surveiller
Résultat	Part des tâches entièrement réussies	Utilité finale	Masque les réussites partielles
Sécurité	Actions interdites et tentatives	Respect du périmètre	Un taux faible peut cacher un incident grave
Intervention	Tâches nécessitant une reprise humaine	Charge opérationnelle	Distinguer validation prévue et sauvetage
Coût	Dépense totale par tâche réussie	Viabilité économique	Inclure les échecs et les reprises
Délai	Médiane et percentiles élevés	Expérience et saturation	Une moyenne cache les tâches bloquées
Stabilité	Réussites sur essais répétés	Régularité	Dépend du protocole de répétition

Le coût par tâche réussie rapporte toutes les dépenses du lot aux tâches réussies selon votre définition. Incluez les appels aux modèles, les outils payants et l’infrastructure pertinente. Présentez séparément le coût de l’évaluation et celui du fonctionnement ; mesurez aussi le temps humain nécessaire.

Distinguez délai jusqu’à une première réponse utile et délai jusqu’à l’état final vérifié. Pour lire un percentile, indiquez sa convention : le percentile 95 désigne le délai sous lequel se situent environ 95 % des observations.

Un score partiel aide au diagnostic, mais ne doit pas valider une opération dont une condition obligatoire manque. Une action interdite peut rester bloquante, quelle que soit la qualité du reste.

Choisir et vérifier les correcteurs

Utilisez des vérifications programmatiques lorsque le résultat est observable : existence d’un fichier, valeur enregistrée, tests logiciels, destinataire ou absence d’écriture hors périmètre. Vérifiez l’environnement final plutôt que la seule déclaration de l’agent.

Pour une synthèse ou une explication, une grille éditoriale peut évaluer exactitude, couverture, justification et respect de la demande. Chaque critère doit décrire un comportement observable. Une appréciation globale de fluidité favorise les réponses élégantes, même lorsqu’elles sont incomplètes.

La publication d’Anthropic Demystifying evals for AI agents distingue correcteurs programmatiques, juges fondés sur un modèle et évaluateurs humains. Elle souligne notamment le besoin de calibrer les juges automatiques avec des appréciations humaines.

Pour cette calibration, faites annoter un échantillon sans révéler la configuration évaluée. Examinez les désaccords, clarifiez la grille, puis mesurez les faux positifs : les échecs que le juge accepte comme réussites. Vérifiez aussi les faux négatifs, qui peuvent conduire à abandonner une configuration utile.

Un juge automatique doit traiter les sorties comme des données non fiables. Une réponse évaluée peut contenir une tentative d’injection de prompt visant le correcteur.

Enfin, testez les tests : un brouillon au mauvais destinataire doit échouer, et une reformulation acceptable doit passer. Un correcteur défectueux peut faire préférer une configuration moins fiable.

Répéter les essais et comparer équitablement

Un agent peut réussir une tâche puis échouer lorsqu’elle est relancée. Répétez les essais en restaurant l’état initial, avec un nombre de répétitions fixé avant l’observation des résultats. Une température basse ne garantit pas, à elle seule, une exécution identique.

Distinguez réussite au premier essai, réussite après reprises et régularité sur répétitions. Le pass@k mesure la possibilité d’obtenir au moins une réussite parmi plusieurs tentatives ; il ne décrit pas la fiabilité d’une exécution ordinaire. Indiquez toujours si vous comptez des essais observés ou utilisez un estimateur.

Les reprises doivent reproduire votre fonctionnement prévu. Si un opérateur doit reconnaître la bonne réponse parmi plusieurs propositions, son travail et les moyens de validation font partie du protocole.

Comparez les configurations sur les mêmes cas, sous les mêmes plafonds de temps, de coût et d’actions. Alternez leur ordre lorsque la charge des services peut varier. Examinez les tâches gagnées et perdues, pas seulement l’écart global.

Présentez une incertitude adaptée à l’échantillon. Si vous utilisez un bootstrap, rééchantillonnez les tâches en conservant leurs répétitions regroupées. Des variantes d’un même dossier ne constituent pas nécessairement des observations indépendantes.

Si l’écart reste incertain, concluez que l’essai ne départage pas les candidats. Augmentez la couverture des situations décisives plutôt que de multiplier les essais jusqu’à obtenir un résultat favorable.

Lire les benchmarks publics sans extrapoler

Un benchmark mesure un système dans un dispositif précis : modèle, instructions, outils, environnement et budget. Deux lignes utilisant le même modèle peuvent correspondre à des agents différents. L’article Comprendre les classements de modèles détaille cette lecture ; le comparateur de benchmarks fournit un point d’entrée complémentaire.

Quelques familles permettent d’orienter la sélection :

Benchmark	Domaine évalué	Résultat examiné	Limite pour votre usage
SWE-bench	Résolution de problèmes logiciels dans des dépôts	Validation du correctif par les tests du protocole	Ne couvre pas toute la maintenance logicielle
Terminal-Bench	Tâches réalisées dans un terminal	Réussite dans l’environnement prévu	Dépend des outils et budgets accordés
OSWorld	Utilisation d’applications et d’un ordinateur	État final évalué dans l’environnement	Sensible aux applications et interfaces
τ-bench	Interaction entre agent, outils et utilisateur	Accomplissement selon les règles du scénario	Dépend aussi de la simulation utilisateur

Consultez les protocoles officiels de SWE-bench, Terminal-Bench et OSWorld pour identifier l’édition, les tâches et les modalités de correction.

Les corrections du benchmark peuvent modifier les scores. Au 24 octobre 2026, les notes de version officielles de τ-bench indiquent explicitement que les résultats de la version 2.0 ne sont pas comparables à ceux de la branche 1.x.

Archivez donc la référence exacte du protocole utilisé. Vérifiez aussi si les tâches sont publiques, si les trajectoires sont disponibles et si le résultat provient des auteurs de l’agent ou d’une évaluation indépendante.

La sélection du meilleur essai, l’ajustement répété sur les tâches publiques et leur présence éventuelle dans l’entraînement limitent l’interprétation. Un classement aide à choisir quoi tester ; il ne fournit pas votre taux de réussite métier.

Tester les permissions et les effets indésirables

Évaluez les actions réellement accessibles à l’agent, y compris lorsqu’elles passent par un serveur MCP. Une vérification limitée à la réponse finale ne révèle pas une lecture interdite ou un envoi effectué pendant l’exécution.

Construisez des scénarios adverses plausibles : document contenant une fausse instruction, demande dépassant les permissions, résultat d’outil trompeur ou erreur incitant à contourner une validation. Définissez le comportement attendu : ignorer le contenu, demander confirmation, refuser ou transmettre à un opérateur.

Vérifiez séparément le comportement du modèle et l’efficacité des contrôles techniques. Si l’agent tente une suppression interdite mais que l’environnement la bloque, la protection fonctionne ; le comportement reste à corriger. Cette distinction évite d’attribuer au modèle la réussite d’une barrière externe.

Les essais doivent utiliser des comptes dédiés, des destinataires de test et des opérations réversibles. Le guide Sécuriser un agent IA précise les mesures de confinement.

Fixez les critères bloquants avant les essais. Une fuite de données ne doit pas être absorbée par une moyenne de qualité rédactionnelle. Consignez aussi les limites de couverture : réussir les scénarios adverses connus ne démontre pas l’absence de vulnérabilités inconnues.

Transformer les traces de production en preuves

L’évaluation hors production contrôle des situations choisies. La production révèle des demandes nouvelles, des changements de documents et des dépendances défaillantes. Les deux doivent alimenter une même boucle de mesure.

Associez chaque tâche à une trace permettant de retrouver la configuration, les appels d’outils, les erreurs, les validations humaines, les coûts et le résultat vérifié. Enregistrez les événements nécessaires au diagnostic sans collecter systématiquement tous les contenus.

Langfuse documente l’évaluation de traces et les expériences sur jeux de données dans sa documentation officielle. Ce type d’instrumentation facilite la comparaison, mais ne définit pas à votre place les critères métier.

Échantillonnez des réussites apparentes autant que des échecs. L’absence de plainte ne prouve pas qu’un document a été correctement traité. Croisez les appréciations utilisateur avec des vérifications indépendantes.

Surveillez les résultats par type de tâche, langue, outil et configuration. Une moyenne stable peut masquer une dégradation sur une catégorie minoritaire. Conservez également des alertes opérationnelles immédiates pour les budgets dépassés ou les actions interdites.

Chaque incident confirmé doit produire un cas de régression expurgé et reproductible. Actualisez parallèlement un corpus récent pour suivre l’évolution des usages. Le guide Surveiller un agent en production approfondit les traces et les alertes.

Organiser la décision de déploiement

Avant une campagne, fixez le protocole et les responsabilités. Une procédure reproductible peut suivre cet ordre :

Définir le périmètre et faire valider les critères de réussite.
Versionner les données, l’agent, les outils et les correcteurs.
Mesurer une référence : procédure actuelle, automatisation fixe ou configuration existante.
Exécuter les candidats sur les mêmes tâches et analyser les régressions.
Décider selon des seuils établis avant les résultats.
Déployer progressivement, avec surveillance et retour à la configuration précédente.

Conservez un compte rendu qui sépare résultats mesurés, incertitudes et situations non couvertes. Attribuez un responsable à chaque échec significatif : données, outil, instructions, permissions ou modèle. Sans cette attribution, les ajustements risquent de déplacer le problème.

Si vous comparez en parallèle l’ancienne et la nouvelle configuration sur des demandes réelles, empêchez la seconde de produire des effets externes. Une opération métier ne doit pas être exécutée deux fois pour les besoins de la mesure.

Avant d’élargir le déploiement, vérifiez :

Les résultats sont contrôlés indépendamment des déclarations de l’agent.
Les échecs, reprises et interventions entrent dans le bilan.
Les permissions et les incidents graves ont des critères distincts.
Les comparaisons utilisent des protocoles identiques et versionnés.
Les traces permettent d’enquêter et de revenir à la configuration précédente.

La décision devient ainsi révisable sur des preuves : tâches accomplies, contraintes respectées, coût supportable et limites documentées.

Pages liées

Questions fréquentes

Combien de tests faut-il pour évaluer un agent IA ?

Il n'existe pas de taille universelle. Commencez par couvrir les situations qui changent la décision de déploiement, puis élargissez avec les incidents et les demandes observées. Un ensemble restreint de cas bien spécifiés est plus exploitable qu'une collection volumineuse aux résultats ambigus.

Peut-on comparer deux agents qui utilisent des modèles différents ?

Oui, si vous comparez les systèmes complets pour un même usage et sous les mêmes contraintes. Vous pourrez choisir une solution, mais vous ne pourrez pas attribuer l'écart au seul modèle. Pour isoler son effet, conservez les outils, les instructions et les budgets.

Un modèle juge peut-il remplacer les évaluateurs humains ?

Il peut traiter une partie des vérifications répétitives après calibration. Gardez une revue humaine des désaccords, des cas sensibles et d'un échantillon des décisions automatiques. Un juge qui paraît cohérent peut partager les erreurs du système évalué.

Un bon score public suffit-il pour mettre un agent en production ?

Non : les tâches, les permissions et les données du benchmark peuvent être éloignées de votre activité. Le score aide à sélectionner des candidats. La décision de déploiement doit reposer sur vos tests et sur un pilote surveillé.

Faut-il conserver toutes les conversations pour mesurer la qualité ?

Vous pouvez souvent conserver des événements structurés, des résultats de vérification et des extraits expurgés. Définissez ce qui est nécessaire au diagnostic avant de collecter les contenus complets. Les données utilisées pour évaluer le système doivent aussi avoir une durée de conservation définie.

Évaluer un agent IA : jeux de tests, métriques, benchmarks publics et suivi en production