---
title: "Évaluation des agents IA : quelles métriques comptent"
description: "L'évaluation des agents IA vérifie si un agent IA fonctionne de manière fiable : taux de réussite des tâches, exactitude des appels d'outils, ancrage factuel, latence, coût et taux d'escalade."
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/construire-une-infrastructure-dagents-ia/evaluation-des-agents-ia-quelles-metriques-comptent"
category: "Agents IA"
topic: "Construire une infrastructure d'agents IA"
updated: "2026-10-28T13:27:08.506Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Évaluation des agents IA : quelles métriques comptent

L'évaluation des agents IA mesure si un agent IA accomplit de manière fiable la tâche prévue. Les métriques clés sont le taux de réussite des tâches, l'exactitude de la trajectoire et des appels d'outils, l'ancrage factuel (groundedness) ou le taux d'hallucination, la latence, le coût et le taux d'escalade HITL. La mesure se fait hors ligne, sur un jeu de données d'évaluation, et en ligne, en production.

## L’essentiel

- Un seul chiffre comme le taux de réussite des tâches ne suffit pas : qualité, exactitude des appels d'outils, ancrage factuel, latence, coût et taux d'escalade doivent être examinés ensemble.
- La fiabilité (pass^k, constance sur plusieurs exécutions) compte souvent davantage que la précision sur une seule exécution. Un agent qui réussit à 90 % mais échoue de façon imprévisible est moins bon qu'un agent à 80 % dont les défaillances sont prévisibles.
- Les évaluations hors ligne sur un golden set figé fournissent des preuves en amont, la surveillance en ligne détecte la dérive et les erreurs réelles. Les deux sont nécessaires et ne se remplacent pas l'une l'autre.
- LLM-as-Judge permet d'évaluer à grande échelle, mais ne remplace pas l'analyse des erreurs. Un pass/fail binaire avec justification l'emporte sur les échelles 1-5 ; les juges doivent être calibrés sur des annotateurs humains.
- Les benchmarks d'agents comme SWE-bench ou GAIA attestent des capacités, pas de l'adéquation à un cas d'usage concret. La preuve pour la mise en production, c'est un jeu de données d'évaluation propre, dans ta langue.
- Un golden set de 200-500 exemples par cas d'usage est le levier le plus puissant de tout le programme d'évaluation et, pour les systèmes d'IA à haut risque, la base de la surveillance après commercialisation exercée par le fournisseur au titre de l'article 72 du règlement européen sur l'IA.

L'évaluation des agents IA mesure si un [agent IA](https://blckalpaca.at/fr/glossaire/agent-ia-ai-agent) accomplit de manière fiable la tâche prévue. Les métriques clés sont le taux de réussite des tâches, l'exactitude de la trajectoire et des appels d'outils, l'ancrage factuel (groundedness) ou le taux d'hallucination, la latence, le coût et le taux d'escalade HITL. La mesure se fait hors ligne, sur un jeu de données d'évaluation, et en ligne, en production. L'évaluation est la discipline qui décide si un [agent](https://blckalpaca.at/fr/glossaire/agent) peut quitter le laboratoire et, depuis le [règlement européen sur l'IA](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), la norme ISO/IEC 42001 et les attentes de la BaFin et de la FINMA en matière de risque de modèle, elle est passée du statut de pratique de recherche à celui d'artefact de conformité.

L'essentiel d'abord : un indicateur unique dans un leaderboard ne prouve plus qu'un agent fonctionne. L'équipe de Princeton à l'origine du [Holistic Agent Leaderboard](https://hal.cs.princeton.edu/) (HAL) montre que 18 mois de progrès en capacités n'ont apporté que de faibles gains de fiabilité, alors que la précision pure n'a cessé d'augmenter. Si tu veux exploiter des agents en production et en conformité avec la réglementation, il te faut un ensemble de métriques multidimensionnel.

**Réponses rapides :**

- Le taux de réussite des tâches est l'indicateur isolé le plus important, mais il ne suffit jamais : qualité, exactitude des appels d'outils, coût et fiabilité en font aussi partie.
- Les évaluations hors ligne (jeu de données fixe, [LLM](https://blckalpaca.at/fr/glossaire/llm)-as-Judge) fournissent des preuves en amont ; la surveillance en ligne détecte la dérive et les erreurs réelles. Les deux sont nécessaires.
- Les benchmarks d'agents attestent des capacités, pas de l'adéquation à ton cas d'usage : la preuve, c'est un jeu de données d'évaluation propre, dans ta langue.

## Les six familles de métriques pour les agents IA

Un programme d'évaluation complet produit à chaque version au moins un chiffre par catégorie pertinente et place le triangle de tension entre coût, qualité et sécurité sur une frontière de Pareto, au lieu de le réduire à un score unique.

| Métrique | Ce qu'elle montre | Méthode |
| --- | --- | --- |
| Taux de réussite des tâches (binaire) | Part des tâches correctement accomplies selon le résultat réel, le chiffre phare | Scorer de résultat : exact match, vérification par exécution ou juge LLM par rapport à une référence |
| Exactitude de la trajectoire / des étapes | Si chaque étape du processus en plusieurs étapes était correcte, pas seulement le résultat final | Notation par étape (style PRM), comparaison de la trajectoire avec le chemin de solution canonique |
| Exactitude des appels d'outils | Si le bon outil a été appelé avec les bons arguments, dans le bon ordre | Correspondance AST/schéma JSON (approche BFCL) ou comparaison par exécution ; plus le taux de récupération en cas d'erreur d'outil |
| Ancrage factuel (groundedness) / taux d'hallucination | Part des affirmations étayées par le contexte récupéré ou par les connaissances générales | Extraction des affirmations et vérification une par une (RAGAS Faithfulness, MiniCheck, Vectara HHEM) |
| Latence (P50/P95/P99) | Temps de réponse par tâche, y compris la latence de queue pour les agents en contact avec les utilisateurs | Mesure du temps réel (wall-clock) par tâche ; percentiles de queue plutôt que moyenne |
| Coût | Tokens d'entrée, de sortie et de raisonnement, et € par tâche ou € pour 1 000 tâches | Comptage des tokens par span ; tokens de raisonnement à part (ils peuvent dominer avec les modèles de raisonnement) |
| Taux HITL / d'escalade | Part des tâches pour lesquelles l'agent passe la main à un humain | Comptage des transferts human-in-the-loop par tâche |
| Constance / pass^k | Si N exécutions répétées avec la même entrée donnent le même résultat | pass^k (les k exécutions réussies), écart type sur 3-5 exécutions |

Deux points méritent d'être soulignés. Premièrement, le **taux d'escalade n'est pas un signal purement négatif** : une escalade vers un humain bien calibrée est une fonctionnalité, pas un défaut ; l'essentiel est que l'agent transmette les bons cas. Deuxièmement, la **fiabilité compte souvent davantage que la précision**. Un agent qui réussit à 90 % mais échoue de façon imprévisible dans les 10 % restants est souvent moins bon en production qu'un agent à 80 % de réussite dont les défaillances sont prévisibles et rattrapables. Le [τ-bench de Sierra](https://arxiv.org/abs/2406.12045) montre que pass^k (les k exécutions réussies) chute nettement pour de nombreux modèles jusqu'à k=8 : même agent, même tâche, résultats sensiblement différents d'une exécution à l'autre. Publier une seule exécution avec une seule seed revient à masquer cette variance. Standard minimal : moyenne plus erreur type sur 3-5 exécutions.

## Évaluations hors ligne vs surveillance en ligne

La dichotomie fondamentale de la discipline oppose hors ligne et en ligne, et les programmes matures exploitent les deux.

L'**évaluation hors ligne** s'exécute par lots sur un jeu de données fixe et versionné. Elle est déterministe, reproductible et fournit les preuves en amont que l'[article 15 du règlement européen sur l'IA](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) exige pour les systèmes à haut risque : l'exactitude doit être mesurée et déclarée, pas affichée comme une ambition. Les évaluations hors ligne sont le bon endroit pour LLM-as-Judge face à des réponses de référence et pour passer systématiquement en revue les cas limites connus.

L'**évaluation en ligne** note le trafic de production réel. Elle fait le lien entre « nous avons déployé » et « nous pouvons prouver que le système fonctionne toujours dans les tolérances ». Pour les systèmes d'[IA à haut risque](https://blckalpaca.at/fr/glossaire/ia-a-haut-risque), l'[article 72 du règlement européen sur l'IA](https://artificialintelligenceact.eu/de/article/72/) impose précisément au fournisseur cette surveillance continue après la mise sur le marché (surveillance après commercialisation). Schémas de déploiement éprouvés :

- **Shadow mode** : le nouveau système tourne en parallèle avec les mêmes entrées, mais ses sorties ne sont pas servies ; elles sont journalisées et comparées. C'est le standard de facto avant tout déploiement à haut risque.
- **Canary deployment** : 1-5 % du trafic va vers le nouveau système, la suite du déploiement dépend de métriques en temps réel. Important : les métriques de gate doivent inclure des scores d'évaluation, pas seulement la latence et le taux d'erreur.
- **Eval gates** : des seuils automatiques qui stoppent le déploiement (par ex. « suspendre la promotion si la faithfulness passe sous 0,85 sur une fenêtre de 4 heures »).

Comme faire passer chaque trace par des juges LLM coûterait beaucoup trop cher, on échantillonne. Une configuration de départ raisonnable pour les PME : 1-5 % d'échantillonnage aléatoire stratifié plus 100 % d'échantillonnage déclenché par les anomalies (sessions longues, nombreuses relances, feedback négatif explicite). Les heuristiques bon marché (contrôle des PII, vérification du format, détection des refus) tournent de façon synchrone, dans le flux ; les évaluations coûteuses par juge tournent de façon asynchrone sur l'échantillon. Cette séparation synchrone/asynchrone est le principal levier de coût : sans elle, l'effort d'évaluation peut dépasser de 2 à 5 fois les coûts d'inférence.

En ligne, il faut en outre s'appuyer sur le **comportement réel des utilisateurs**, pas seulement sur les scores des juges : taux de copier-coller, modifications après collage, taux de relance et taux d'abandon sont des signaux de vérité terrain lents mais fiables. Dans la région DACH (Allemagne, Autriche, Suisse), le taux de clic sur pouce levé/baissé est culturellement plus faible qu'aux États-Unis, ce qui atténue la valeur informative des signaux de feedback explicite.

## LLM-as-Judge : utile, mais pas autonome

La référence canonique (Zheng et al., 2023) montre que les modèles juges performants atteignent plus de 80 % de concordance avec des évaluations humaines contrôlées, soit le même niveau que la concordance entre humains. Cela vaut toutefois pour les tâches d'opinion ; pour les contenus dans ta langue où l'exactitude factuelle est critique (droit, médecine, finance), la référence humaine reste la norme.

Lignes directrices tirées de la pratique :

- **Binaire plutôt que Likert.** Un pass/fail accompagné d'une critique rédigée l'emporte sur les échelles 1-5, car la frontière entre 3 et 4 est instable d'un juge et d'une exécution à l'autre.
- **Atténuer les biais connus.** Le biais de position, en inversant l'ordre et en faisant la moyenne des deux ; le biais de verbosité, par un contrôle de la longueur ; le biais d'autopréférence, avec des juges d'une autre famille de modèles ou un ensemble de juges.
- **Calibrer.** Rapporter la concordance juge-humain sous forme de kappa de Cohen ou d'alpha de Krippendorff avant de faire confiance à un juge en production.
- **Limiter les coûts.** Règle empirique : prévoir 10-30 % des coûts d'inférence pour l'évaluation ; avec des juges de raisonnement, cela peut dépasser 50 %. Schéma type : juges de raisonnement pour le jeu de validation, juges spécialisés bon marché (par exemple des modèles de type MiniCheck) pour l'échantillonnage en production.

Point décisif : LLM-as-Judge **ne remplace pas l'analyse des erreurs**. Le consensus des praticiens veut que 60-80 % de l'effort d'évaluation reste consacré à regarder les données, à identifier les modes de défaillance et à les traduire en assertions pass/fail.

## Comment construire le jeu de données et la boucle d'évaluation

Un golden set solide a une provenance documentée, une grille d'annotation, un accord inter-annotateurs et une couverture explicite des cas d'usage réels. Recette pratique :

1. Échantillonner 200-500 traces utilisateurs réelles ; masquer les PII conformément à l'article 32 du [RGPD](https://blckalpaca.at/fr/glossaire/rgpd).
2. Deux experts métier étiquettent chaque trace avec un résultat et une critique ; calculer le kappa de Cohen, résoudre les désaccords.
3. Ajouter 50-100 cas limites adversariaux rédigés par des experts, aux frontières des politiques.
4. Ajouter 100-200 cas synthétiques selon des dimensions documentées (fonctionnalités × scénarios × personas).
5. Isoler 30 % comme jeu de test figé, jamais utilisé pour l'ajustement ; 70 % pour l'itération.
6. Versionner, documenter la dataset card, rafraîchir chaque trimestre.

Pour un pilote en PME, un golden set de 500 éléments demande au départ environ 3-6 semaines de temps d'expert, puis à peu près une semaine par trimestre. C'est le levier le plus puissant de tout le programme d'évaluation.

La **boucle d'évaluation continue** relie les deux mondes : requête utilisateur → exécution de l'agent → émission de spans de trace (OpenTelemetry) → couche d'échantillonnage → couche d'évaluation (juges LLM plus heuristiques plus juges à petits modèles) → stockage des évaluations → [dashboard](https://blckalpaca.at/fr/glossaire/dashboard) → alerte en cas de dépassement de seuil → retour dans le golden set. Les programmes matures en font un **gate CI/CD** : chaque pull request qui modifie le [prompt](https://blckalpaca.at/fr/glossaire/prompt), le choix du modèle, la configuration du retrieval ou la définition des outils déclenche la suite d'évaluation ; le merge échoue si le taux de réussite passe sous le seuil. Un changement de version du modèle chez le fournisseur devrait lui aussi déclencher une réévaluation automatique avant que le nouveau modèle n'entre dans le routage de production. Un golden set figé devrait être réévalué sur le système en production au moins chaque semaine, et chaque jour pour les agents critiques, afin de distinguer une régression du modèle ou du prompt d'une simple dérive de l'environnement.

Pour une résidence des données conforme au RGPD, des outils auto-hébergeables conviennent, comme **Langfuse**, fondé en Allemagne (auto-hébergement sur ClickHouse et Postgres), ou **Arize Phoenix**, natif OTel ; **RAGAS** est la bibliothèque de référence de facto pour les métriques [RAG](https://blckalpaca.at/fr/glossaire/rag) (Faithfulness, Context Precision, Answer Relevancy), tandis que **DeepEval** et **Inspect AI** couvrent les évaluations proches du CI/CD et celles liées à la sécurité. (Situation en 2026 ; le marché des outils d'évaluation se consolide actuellement par des opérations de M&A comme Cisco/Galileo.)

## Différence avec les benchmarks de modèles

Une erreur de raisonnement fréquente et coûteuse consiste à confondre scores de benchmark et preuve d'adéquation. Une **évaluation de model card** est l'artefact marketing ou de recherche du fournisseur du modèle : un instantané des capacités sur des benchmarks publics. Une **évaluation de conformité** est l'artefact réglementaire de l'entreprise qui développe ou déploie l'agent : mesure préalable et continue par rapport au cas d'usage réel, au jeu de données et au profil de risque, avec méthodologie documentée, scorers versionnés et piste d'audit. Ce sont des artefacts différents, aux destinataires différents, et la plupart des régulateurs n'acceptent pas une model card comme substitut.

Trois raisons pour lesquelles les scores de benchmark n'apportent que du contexte :

- **Contamination.** Tout benchmark dont le jeu de données était public avant 2024 figure vraisemblablement dans les données d'entraînement. Exemple : selon [Anthropic](https://www.anthropic.com/news/claude-opus-4-5), Claude Opus 4.5 atteint 80,9 % sur SWE-bench Verified, un [sous-ensemble constitué en 2024](https://openai.com/index/introducing-swe-bench-verified/) du [SWE-bench publié en 2023](https://arxiv.org/abs/2310.06770). Sur SWE-bench Pro, plus résistant à la contamination, il obtient en revanche 45,9 % dans le [leaderboard public de Scale AI](https://labs.scale.com/leaderboard/swe_bench_pro_public) (état en octobre 2026). L'écart ne s'explique pas uniquement par la contamination : SWE-bench Pro est aussi conçu pour être plus difficile (les solutions de référence modifient en moyenne 107 lignes de code dans 4,1 fichiers), et les deux valeurs proviennent de protocoles de mesure différents (donnée du fabricant contre leaderboard). Il montre néanmoins à quel point les scores dépendent de la conception du benchmark et d'une éventuelle contamination.
- **Dépendance au scaffold.** « Leader du classement GAIA » ne veut rien dire sans mention du scaffold : entre les scores avec scaffold (Princeton HAL avec Claude Sonnet 4.5 : 74,6 %) et les scores bruts (bare), il y a environ 30 points de pourcentage.
- **Reward hacking.** Des travaux du RDI de l'UC Berkeley (avril 2026) ont montré qu'un agent de scan automatisé pouvait pirater les huit grands benchmarks d'agents jusqu'à des scores quasi parfaits, sans résoudre une seule tâche.

La position défendable pour un dossier de conformité : citer plusieurs benchmarks de familles différentes, rapporter coûts et variance, compléter par des golden sets privés propres au client et reconnaître les limites par écrit. Les benchmarks d'agents en anglais (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) servent à établir une base de référence des capacités ; la véritable preuve reste le jeu de données d'évaluation dans ta langue, idéalement mis en correspondance avec les catalogues de critères du BSI.

## Pour les agences et les décideurs B2B

Si tu conçois ou exploites des agents [IA](https://blckalpaca.at/fr/glossaire/ia) pour des clients en Europe, considère l'évaluation non comme un test en fin de parcours, mais comme une discipline continue : un golden set dans la langue de tes clients comme fondation, des gates hors ligne avant la mise en production, une [surveillance en ligne](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/construire-une-infrastructure-dagents-ia/observabilite-des-agents-ia-tracing-metriques-logs-et-evals) avec détection de dérive ensuite, et un ensemble de métriques qui prend la fiabilité et le coût aussi au sérieux que le simple taux de réussite. Pour les systèmes d'IA à haut risque, ce socle d'évaluation sert aussi de base à la surveillance après commercialisation. L'[article 15](https://artificialintelligenceact.eu/de/article/15/) et l'[article 72](https://artificialintelligenceact.eu/de/article/72/) du règlement européen sur l'IA ne s'imposent toutefois qu'aux fournisseurs de tels systèmes. Pour la plupart des agents marketing, un programme d'évaluation rigoureux relève de la bonne pratique, pas de l'obligation légale. Depuis Vienne, Blck Alpaca aide les agences et les entreprises B2B à mettre en place un tel programme d'évaluation, du golden set au choix des outils jusqu'au dossier de conformité prêt pour l'audit. Écris-nous si tu veux que tes agents passent en production de manière mesurable et conforme.

## Questions fréquentes

### Quelle est la métrique la plus importante pour l'évaluation des agents IA ?

Le taux de réussite des tâches, c'est-à-dire la part des tâches correctement accomplies mesurée sur le résultat réel, est l'indicateur isolé le plus important. Mais il ne suffit jamais : sans exactitude des appels d'outils, ancrage factuel, latence, coût et fiabilité (constance sur plusieurs exécutions), un taux de réussite élevé masque souvent des défaillances imprévisibles.
### Quelle est la différence entre évaluation hors ligne et évaluation en ligne ?

L'évaluation hors ligne s'exécute par lots sur un jeu de données d'évaluation fixe et figé, et fournit les preuves en amont, avant la mise en production. L'évaluation en ligne note par échantillonnage le trafic de production réel et détecte la dérive ainsi que les erreurs réelles en exploitation. Les programmes matures utilisent les deux. Pour les systèmes d'IA à haut risque, elles fournissent en outre des éléments de preuve pour l'exigence d'exactitude de l'article 15 et pour la surveillance après commercialisation exercée par le fournisseur au titre de l'article 72 du règlement européen sur l'IA.
### Les scores de benchmarks comme SWE-bench ou GAIA suffisent-ils à prouver la qualité ?

Non. Les benchmarks d'agents attestent des capacités en conditions de laboratoire, pas de l'adéquation à un cas d'usage concret. Ils sont sujets à la contamination et dépendent du scaffold : sur GAIA, l'écart entre les scores avec scaffold et les scores bruts (bare) atteint environ 30 points de pourcentage. La preuve solide pour la mise en production, c'est un golden set propre, dans ta langue.
### Quelle est la fiabilité de LLM-as-Judge ?

Selon Zheng et al. (2023), les modèles juges performants atteignent plus de 80 % de concordance avec les évaluations humaines sur des tâches d'opinion, soit le niveau de concordance entre humains. Ils présentent toutefois des biais connus (position, longueur, autopréférence) et doivent être calibrés sur des annotateurs humains. Pour les contenus où l'exactitude factuelle est critique, l'évaluation humaine reste la référence absolue.
### Comment construire un jeu de données d'évaluation pour des agents IA ?

Recette pratique : échantillonner 200-500 traces utilisateurs réelles et masquer les données personnelles (PII), les faire étiqueter par deux experts métier avec un résultat et une critique, vérifier le kappa de Cohen, ajouter 50-100 cas limites adversariaux et 100-200 cas synthétiques, puis isoler 30 % comme jeu de test figé, le versionner et le rafraîchir chaque trimestre.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/construire-une-infrastructure-dagents-ia/evaluation-des-agents-ia-quelles-metriques-comptent). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.