Évaluer un agent IA : benchmarks et tests maison

Évaluer un agent IA, c’est vérifier qu’il mène réellement une tâche à bien, de façon régulière, et pas seulement qu’il produit une réponse convaincante. Les benchmarks publics donnent un premier repère, mais la décision se prend sur vos propres tests, construits à partir de vos cas d’usage.

Pourquoi un agent ne s’évalue pas comme un chatbot

Un benchmark classique pose une question et compare la réponse à une solution. Un agent IA, lui, enchaîne des actions : il cherche une information, appelle des outils, modifie un fichier, envoie un message. L’évaluation d’agents doit donc regarder plusieurs choses à la fois :

• le résultat : l’état final est-il le bon (le ticket est fermé, la facture existe, le test passe) ?
• le chemin : l’agent a-t-il utilisé les bons outils, sans détour coûteux ni action risquée ?
• la régularité : réussit-il à chaque fois, ou seulement de temps en temps ?
• le coût et la durée : combien de tokens et de minutes pour y arriver ?

Deux agents peuvent atteindre le même résultat par des chemins très différents, et un même agent peut réussir puis échouer sur une tâche identique. C’est ce qui rend l’exercice plus exigeant qu’un simple jeu de questions.

Ce que disent (et ne disent pas) les benchmarks publics

Les benchmarks publics servent de langage commun. Les plus cités pour les agents :

• SWE-bench, créé à Princeton en octobre 2023, demande de corriger de vrais problèmes tirés de projets Python open source ; sa version Verified compte 500 tâches revérifiées par des humains.
• Terminal-Bench, lancé le 19 mai 2025 par Stanford et le Laude Institute, évalue le travail en ligne de commande ; sa version 2.0 date de novembre 2025.
• GPQA teste le raisonnement scientifique de haut niveau, utile pour juger le « cerveau » du modèle plutôt que l’agent complet.

Notre classement des modèles agrège ce type d’épreuves. Au 22 octobre 2026, l’indice publié par Epoch AI est la moyenne de sept tests, dont SWE-bench et Terminal-Bench. Voici le haut du tableau :

Rang	Modèle	Organisation	Indice
1	Claude Sonnet 5.5	Anthropic	95,9
2	Claude Opus 5.5	Anthropic	95,9
3	Gemini 4 Argon	Google DeepMind	95,3
4	GPT-6 Astra	OpenAI	94,7
5	Claude Opus 5	Anthropic	92,7

Et l’écart entre quelques modèles phares, sur ce même indice :

Indice de capacité (sur 100)

• Claude Sonnet 5.595,9
• Gemini 4 Argon95,3
• GPT-6 Astra94,7
• Claude Haiku 5.584
• GPT-6 Luna80,3

Les cinq premiers tiennent en un peu plus de trois points. À ce niveau, la différence se joue moins sur le modèle que sur ce que vous construisez autour : le prompt, les outils, la mémoire, les garde-fous. Notre méthodologie précise comment ces scores sont collectés et affichés.

Trois limites sont à garder en tête. Un benchmark mesure une situation précise, souvent du code. Ses tâches peuvent avoir fuité dans les données d’entraînement. Et le score dépend autant de l’environnement d’exécution que du modèle : deux équipes qui testent le même modèle avec des outils différents n’obtiennent pas le même chiffre.

Construire ses propres tests : le vocabulaire utile

Dans son guide « Demystifying evals for AI agents », publié le 9 janvier 2026 et consulté le 22 octobre 2026, Anthropic propose un vocabulaire devenu courant :

• Tâche : un test avec des entrées et un critère de réussite.
• Essai : une tentative. On en lance plusieurs par tâche, car les résultats varient d’une exécution à l’autre.
• Correcteur : la logique qui note un aspect du travail. Une tâche peut en avoir plusieurs.
• Transcription : l’enregistrement complet d’un essai, appels d’outils et étapes intermédiaires compris.
• Résultat : l’état final de l’environnement à la fin de l’essai.

Le même guide distingue deux mesures. La première est la probabilité de réussir au moins une fois sur plusieurs essais, qui monte quand on multiplie les tentatives. La seconde est la probabilité de réussir à tous les essais, qui baisse au contraire. La première dit ce que l’agent sait faire ; la seconde, ce que vous pouvez lui confier sans surveillance.

Méthode en cinq étapes

1. Partez des échecs réels. Le guide d’Anthropic estime qu’une vingtaine à une cinquantaine de tâches simples tirées d’échecs réels constituent un excellent départ. Recensez ce que vous vérifiez déjà à la main et ce que les utilisateurs signalent.

2. Écrivez un critère de réussite sans ambiguïté. Bon test : deux experts lisant le même résultat tomberaient d’accord. « La réponse est utile » ne suffit pas ; « le remboursement est enregistré au bon montant et le client reçoit un message de confirmation » fonctionne.

3. Équilibrez les cas. Ajoutez des tâches où l’agent doit refuser, demander une précision ou passer la main à un humain. Sinon, vous optimisez un agent qui agit toujours, même quand il ne devrait pas.

4. Séparez deux familles de tests. Les tests de capacité visent ce que l’agent ne sait pas encore bien faire : un taux de réussite bas au départ est normal. Les tests de non-régression vérifient qu’il fait toujours ce qu’il savait faire : ils doivent rester proches de 100 %.

5. Rejouez à chaque changement. Nouveau prompt, nouvel outil, nouveau modèle : tout passe par la série de tests. Le travail sur les consignes, détaillé dans notre guide de prompt engineering, devient alors mesurable au lieu d’être une affaire d’impression.

Choisir ses correcteurs

Le guide d’Anthropic décrit trois types de correcteurs, à combiner plutôt qu’à opposer :

Correcteur	Points forts	Points faibles	Exemple d’usage
Code	Rapide, bon marché, objectif, reproductible	Rigide face à une solution valable mais inattendue	Vérifier qu’un fichier existe ou qu’un test passe
Modèle	Souple, gère les réponses ouvertes et les nuances	Non déterministe, coûteux, à calibrer	Juger le ton ou la complétude d’une réponse
Humain	Référence de qualité, jugement d’expert	Lent et cher à grande échelle	Relire un échantillon, calibrer le juge

Le correcteur par modèle porte un nom : le LLM comme juge. L’article fondateur de Zheng et ses coauteurs (juin 2023) rapporte plus de 80 % d’accord entre GPT-4 et les préférences humaines, mais décrit aussi des biais : préférence pour la première réponse, pour la plus longue, ou pour celle de son propre modèle. D’où trois réflexes : inverser l’ordre des réponses comparées, demander une justification avant la note, et vérifier régulièrement le juge sur un échantillon noté par des personnes.

Vérifiez-vous Votre agent rédige des réponses aux clients et met à jour leur fiche dans un CRM. Quel correcteur pour chaque partie ?

Un script pour la mise à jour du CRM, car l’état final se vérifie objectivement (le bon champ a-t-il la bonne valeur ?). Un modèle juge, calibré sur des notes humaines, pour la qualité et le ton du message. Et une relecture humaine d’un échantillon à intervalle régulier.

Lire les transcriptions, pas seulement le score

Un score global cache l’essentiel. Quand une tâche échoue, la transcription dit si l’agent s’est vraiment trompé ou si c’est votre correcteur qui a refusé une solution valable. Anthropic raconte, dans le même guide, qu’un score sur le benchmark CORE-Bench est passé de 42 % à 95 % une fois corrigés des défauts de l’évaluation elle-même, et non du modèle.

La leçon vaut pour vos tests maison : un taux d’échec soudain mérite une lecture des traces avant toute conclusion. Les erreurs typiques d’un correcteur sont un format trop strict, une solution de référence fausse ou un environnement mal réinitialisé entre deux essais.

Tester la sécurité et le jugement

Une évaluation sérieuse ne mesure pas seulement la réussite. Elle cherche aussi ce qui peut mal tourner. Le red teaming consiste à attaquer volontairement l’agent : documents piégés, demandes ambiguës, tentatives de lui faire divulguer des données. Ajoutez des tâches où la bonne réponse est de s’arrêter et de solliciter un humain dans la boucle avant une action irréversible. Notre guide sur la sécurité des agents IA détaille ces scénarios.

Outillage : du framework à la production

Inutile de tout coder vous-même. Plusieurs frameworks intègrent des briques d’évaluation : Pydantic AI inclut Pydantic Evals pour noter les réponses et les enchaînements d’outils, et Google ADK propose un cadre d’évaluation avec simulation d’utilisateur et métriques personnalisées. Notre comparatif des frameworks d’agents aide à choisir selon vos besoins.

En production, le relais est pris par l’observabilité des LLM : chaque appel est tracé (modèle, tokens consommés, outils appelés, durée), ce qui permet de repérer les dérives et de transformer les échecs réels en nouvelles tâches de test. Les conventions OpenTelemetry pour l’IA générative, avec des attributs comme gen_ai.request.model ou gen_ai.usage.input_tokens, cherchent à standardiser ces traces.

Pour situer l’évaluation dans l’ensemble du projet, de la définition de la tâche au déploiement, reportez-vous à notre guide pour créer un agent IA.