L'évaluation d'un agent IA vérifie si l'agent a atteint le résultat attendu et si les appels d'outils et les recherches qui l'ont produit étaient appropriés. Une équipe qui n'évalue que le résultat final risque de ne jamais vérifier comment l'agent y est parvenu, car un agent peut renvoyer un résultat en apparence correct au terme d'une séquence d'appels d'outils défaillante.
Ce guide détaille ce qu'il faut mesurer à chaque couche d'une exécution d'agent et en quoi cinq méthodes d'évaluation diffèrent par ce qu'elles détectent et ce qu'elles laissent passer.
Pour le volet traçage en production du même problème, découvrez l'observabilité des agents IA, qui répond à la question de ce qui se passe pendant une exécution en direct.
Qu'est-ce que l'évaluation des agents IA ?
L'évaluation des agents IA note un agent sur vos propres tâches, avec vos propres outils et vos propres données. Elle vérifie si l'agent a produit le résultat attendu en suivant les étapes que vous avez définies. L'évaluation des agents IA mesure le système que vous avez déployé, et non un modèle abstrait.
Il existe aussi un test de benchmarking de modèle, qui note un modèle sur un ensemble de tâches publiques fixe, identique pour tout le monde. L'évaluation d'agent note votre agent sur vos propres workflows : un appel de recouvrement qui met à jour votre CRM, ou une reréservation qui respecte vos règles tarifaires.
Un benchmark public ne peut pas détecter les défaillances qui comptent dans vos propres workflows, car il ne teste jamais vos outils internes ni vos règles de conformité. L'évaluation d'agent détecte l'agent qui appelle le mauvais outil interne et celui qui enfreint une règle de divulgation définie par votre équipe conformité.
Pourquoi l'exactitude du résultat est le mauvais indicateur
L'exactitude du résultat est le mauvais indicateur principal pour un agent IA, car deux défaillances différentes sont toutes deux jugées correctes par un contrôle portant uniquement sur la réponse. Un agent peut aboutir à la bonne réponse via un processus défaillant, ou exécuter correctement chaque étape sans pour autant terminer la tâche.
L'agent ne suit pas les étapes prédéfinies
L'agent accomplit la tâche par le mauvais chemin, car le contrôle ne porte que sur la réponse finale, et non sur le chemin qui l'a produite. Si l'agent saute une étape obligatoire, lit le mauvais enregistrement ou appelle le mauvais outil, il peut malgré tout produire un résultat qui paraît correct sur cette exécution.
Par exemple, un agent de support peut demander le solde du compte courant d'un client et consulter le compte épargne à la place. Les deux soldes peuvent coïncider ce jour-là, mais la mauvaise consultation renvoie un chiffre qui semble juste.
Raisons fréquentes :
- Mauvaise source de données : La consultation récupère le mauvais enregistrement, le mauvais compte ou le mauvais champ, et non celui que la tâche spécifiait.
- Mauvais appel d'outil : L'agent appelle un outil qui ne correspond pas à l'étape en cours, ou lui transmet un argument erroné.
- Étape sautée : Le workflow passe à l'étape suivante avant qu'une vérification obligatoire, comme un contrôle d'identité ou de conformité, ne soit terminée.
- Perte de contexte : Une valeur antérieure de la conversation est reprise à la place de celle corrigée dans un tour ultérieur.
L'agent suit chaque étape mais ne produit jamais de résultat
Il s'agit d'un autre scénario, dans lequel un agent peut réussir chaque contrôle au niveau des étapes tout en échouant à terminer la tâche. Un agent de remboursement choisirait le bon outil, transmettrait des arguments valides, recevrait une réponse valide à chaque étape, et s'arrêterait malgré tout avant l'écriture finale dans le système de paiement.
Chaque score au niveau des étapes est jugé correct. Le remboursement n'est jamais enregistré et le dossier de paiement du client n'est jamais mis à jour.
Voici pourquoi cela se produit :
- Échec d'écriture silencieux : L'appel de mise à jour se termine sans confirmer que l'écriture a abouti, et l'agent ne le vérifie jamais.
- Confirmation prise pour un achèvement : L'agent interprète une réponse valide d'une étape intermédiaire comme la fin de la tâche.
- Étape finale manquante : Le workflow s'arrête une étape avant l'action qui valide la modification, comme l'écriture dans le système de paiement ou le CRM.
- Limite de tours ou de coût atteinte : L'agent atteint son plafond de tours ou de coût avant l'exécution de la dernière étape, et renvoie ce dont il dispose.
Que faut-il réellement mesurer ?
L'évaluation d'agent opère sur trois couches, et chaque couche note une partie différente de l'exécution. La couche « étape » note une action isolée, la couche « trace » évalue si l'exécution a atteint son objectif, et la couche « résultat » mesure l'impact métier produit par l'exécution.
Une équipe qui ne mesure qu'une seule de ces couches ne peut pas voir ce qui s'est passé dans les deux autres. Voici ce qu'il faut mesurer à chaque couche.
Le niveau étape note chaque action
L'évaluation au niveau des étapes note chaque action au sein d'une exécution, avant que celle-ci ne soit terminée. Une action erronée peut tout de même produire un résultat qui paraît juste : une entreprise qui ne vérifie que la réponse finale ne voit jamais l'étape qui a failli échouer.
Les étapes suivantes sont effectuées pour vérifier l'exactitude de cette étape.
- Sélection de l'outil : Vérifie si l'agent appelle bien l'outil explicitement demandé, conçu pour cette étape, plutôt qu'un outil similaire qui renvoie un résultat incorrect.
- Arguments de l'outil : Vérifie si l'agent transmet le bon identifiant de compte, de commande ou d'enregistrement à l'outil qu'il a appelé.
- Qualité de la recherche : Confirme si le document, la politique ou l'enregistrement récupéré par l'agent correspond effectivement à la question à laquelle il répondait.
- Cohérence du raisonnement : Effectue un contrôle pour s'assurer que chaque étape découle logiquement de la précédente, sans contredire une décision prise plus tôt dans la même exécution.
Le niveau de la trace note l'exécution complète
L'évaluation au niveau de la trace note l'ensemble de l'exécution réalisée par un agent au regard de l'objectif qui lui a été fixé, et pas seulement chaque action prise isolément.
Une entreprise a besoin de cette couche, car une exécution peut réussir chaque étape et malgré tout échouer sur la tâche : un agent de remboursement peut appeler tous les bons outils et s'arrêter avant la mise à jour de l'enregistrement de paiement. La notation au niveau de la trace met en évidence cet écart entre des étapes correctes et une tâche réellement achevée. C'est également la couche que consulte une équipe conformité pour son reporting.
Elle suppose d'aligner ces facteurs dans un test :
- Achèvement de la tâche : Pour vérifier si l'exécution a atteint l'état requis par la tâche, par exemple un remboursement comptabilisé ou une réservation confirmée.
- Respect des politiques : Vérifier s'ils respectent les règles qu'ils ont été conçus pour suivre, comme les informations obligatoires à communiquer ou les déclencheurs d'escalade.
- Conservation du contexte : Déterminer si un agent a conservé une valeur ou une instruction d'un tour à l'autre, au lieu de la perdre en cours de route.
- Tours et coût : Combien de tours l'exécution a-t-elle nécessités, et combien a-t-elle coûté, par rapport à la même tâche réalisée de façon plus courte ?
Le niveau du résultat note le résultat métier
L'évaluation au niveau du résultat mesure le résultat métier que l'exécution devait produire, généralement représenté par un chiffre que la direction peut lire sur un tableau de bord. Elle vérifie si le travail de l'agent a fait évoluer un indicateur suivi par l'entreprise, et non si telle étape ou la trace sous-jacente était correcte.
Les contrôles suivants sont effectués à ce niveau :
- Taux de résolution : La part des exécutions qui ont clôturé la tâche sans intervention humaine.
- Taux d'escalade : La part des exécutions transmises à une personne, et pour quelles raisons.
- Taux de correction humaine : La fréquence à laquelle une personne a dû corriger après coup ce que l'agent a produit.
- Indicateur métier en aval : Représente le chiffre que le workflow devait faire évoluer : montants recouvrés, réservations finalisées ou tickets clôturés.
La plupart des équipes s'arrêtent à la couche du résultat, car ce sont les chiffres qu'un tableau de bord présente déjà à l'entreprise. L'enquête State of Agent Engineering de LangChain, menée auprès de 1 340 équipes développant des agents en production, révèle que 89 % ont ajouté une forme d'observabilité à leurs agents. Pourtant, seules 62 % peuvent tracer une étape ou un appel d'outil individuel, et à peine 37,3 % exécutent des évaluations sur le trafic de production réel.
Comparaison des méthodes d'évaluation
Un LLM-as-judge mal aligné produirait des scores sûrs de lui mais incorrects : c'est l'échec d'évaluation le plus courant en pratique. Avant de faire confiance à un modèle juge, une équipe doit confronter ses scores à des annotations humaines sur un échantillon, et répéter ce contrôle chaque fois que le modèle juge change.
| Method | What it catches | What it misses | Cost | When to use it |
|---|---|---|---|---|
| Human review | Nuance and judgment on open-ended output | Scale, since a person reviews only a few runs | High | Calibration and hard edge cases |
| Rule-based assertions | Known hard constraints, like a forbidden action or a bad format | Anything the rules don't encode | Low | Policy and safety gates |
| LLM-as-judge | Open-ended quality at scale | Whatever an unaligned judge scores as wrong | Medium | High volume, once the judge is checked against human labels |
| Regression suites from production failures | A repeat of a failure that already happened | A failure mode nobody has seen yet | Low to maintain | Stopping a known bug from returning |
| Simulation | Behavior across many generated cases before launch | The real distribution of live traffic | Medium | Pre-deployment coverage |
Évaluation hors ligne contre évaluation continue
Un jeu d'évaluation avant déploiement est testé avant la mise en production d'un agent afin de détecter les modes de défaillance déjà connus de l'équipe. L'évaluation continue, elle, est destinée à s'exécuter sur le trafic de production réel après le lancement, pour détecter les modes de défaillance que personne n'avait pensé à tester.
Voici toute la différence entre l'évaluation et l'évaluation continue.
| Process Aspect | Offline evaluation | Continuous evaluation |
|---|---|---|
| When it runs | Before the agent goes live | After launch, on live production traffic |
| What it catches | Failure modes a team already knows about | Failure modes nobody thought to test for |
| Test cases come from | A curated eval set built ahead of time | Real runs the agent that is currently handling |
| Role in the loop | Blocks a known failure from reaching production again | Adds the next production failure to the eval set |
| Risk if left unmaintained | Reports passing scores against tasks the agent no longer runs | Has no risk of going stale, since it always tests current traffic |
Ce qui relie ces deux évaluations, c'est une boucle unique déclenchée par une défaillance en production. Par exemple, un compte mal interprété lors d'une exécution réelle devient un nouveau cas d'évaluation, et ce cas devient un test de non-régression qui empêche la même défaillance de se reproduire. Cette boucle permet aussi à une suite de tests pré-déploiement de rester utile après le lancement, au lieu de devenir obsolète dès la mise en production de l'agent.
Un jeu d'évaluation devient obsolète dès qu'une équipe modifie les workflows, les outils et les règles de l'agent. Une suite que l'équipe cesse de mettre à jour est pire que pas de suite du tout, car elle affiche des scores positifs sur des tâches que l'agent n'exécute plus. Cette suite simule une confiance factice au lieu d'une couverture réelle. Une équipe qui pratique l'évaluation continue et les tests A/B sur le trafic réel maintient sa suite alignée sur les workflows actuels de l'agent.
Choisir ses outils d'évaluation
Pour une entreprise, choisir des outils d'évaluation revient à décider où résident les traces et les données des agents, pas à comparer des fonctionnalités. Une banque ou une compagnie aérienne doit savoir qui peut consulter la transcription d'un appel avant de choisir un fournisseur.
Catégories
Le marché se divise en quatre catégories, selon l'endroit où réside la suite et selon qui l'exécute.
Les plateformes centrées sur l'évaluation font de la suite d'évaluation elle-même le produit central et ajoutent le tracing autour.
- Braintrust
- Galileo
- Maxim
- Comet
Les bibliothèques open source s'exécutent dans votre propre code et votre CI : aucun fournisseur ne stocke vos traces.
- DeepEval
- Outils d'évaluation MLflow
Les plateformes de tracing dotées d'une couche d'évaluation capturent d'abord la trace, puis la notent.
- Langfuse
- Arize Phoenix
L'évaluation intégrée à une plateforme d'agents signifie que la plateforme qui exécute les agents les évalue elle-même : l'acheteur n'a donc pas à assembler une stack distincte.
La résidence des données, la possibilité pour les traces de sortir de votre environnement et la personne qui maintient la suite déterminent le choix, pas le nombre de fonctionnalités.
HappyRobot relève de cette quatrième catégorie, avec sa couche de gouvernance capable d'évaluer chaque agent de la plateforme : l'entreprise achète l'évaluation au lieu de la construire.
