Évaluer un agent IA : la méthode complète

Évaluer un agent IA consiste à lui faire exécuter un jeu de missions représentatives plusieurs fois, puis à mesurer le résultat final, les étapes suivies, les outils appelés, le coût, la sécurité et le besoin de correction humaine Un bon test ne demande pas seulement si la réponse semble correcte Il vérifie si l'agent a réellement produit le bon état dans le système concerné

Ce sujet devient critique à mesure que les agents travaillent plus longtemps et utilisent davantage d'outils Une réponse élégante peut masquer un fichier absent, un mauvais destinataire, une source inventée ou une action non autorisée Anthropic rappelle dans son guide Demystifying evals for AI agents que l'évaluation structurée permet de détecter les problèmes avant le déploiement au lieu de réagir à chaque incident

L'objectif n'est pas de fabriquer un score parfait L'objectif est de savoir quelles missions l'agent peut exécuter, où il échoue et quelles actions peuvent devenir autonomes sans diluer la responsabilité

Pourquoi un benchmark de modèle ne suffit pas

Un benchmark de modèle mesure une capacité dans un cadre défini Il peut comparer le raisonnement, le code ou la factualité Mais ton agent ajoute des instructions, un contexte, une mémoire, des outils, des permissions, une interface et parfois plusieurs modèles

Deux agents construits sur le même modèle peuvent donc produire des résultats opposés

• le premier dispose du bon outil et d'une Definition of Done précise

• le second utilise une fonction trop large et s'arrête après un message rassurant

• le premier cite les sources réellement ouvertes

• le second répond de mémoire sans le signaler

• le premier travaille dans un dossier isolé

• le second peut modifier toute la production

Notre guide évaluer la fiabilité d'un modèle IA couvre le niveau modèle Ici, l'objet évalué est le système agentique complet et son comportement sur une mission réelle

Les cinq briques d'une évaluation utile

Anthropic décrit une évaluation avec des tâches, des essais, des graders, des transcripts et des outcomes Cette structure donne un vocabulaire simple pour sortir du test improvisé

Une tâche représentative

La tâche contient une entrée, un environnement et des critères de réussite Elle doit ressembler au travail réel, avec ses formats sales et ses exceptions

Mauvais test

Résume ce document

Meilleur test

Lis ce dossier de trois contrats, construis un tableau des dates de renouvellement, cite le fichier et la clause pour chaque ligne, signale les pièces manquantes et n'écris rien dans les documents sources

Le deuxième test nomme un résultat, une preuve et une limite

Plusieurs essais

Un agent peut réussir une fois par chance ou échouer sur une variation mineure Répète les cas importants et varie les formulations, l'ordre des fichiers et les données manquantes

Trois à cinq essais par tâche critique donnent déjà plus d'information qu'une seule démonstration Le but n'est pas une règle statistique universelle mais la détection de variance

Des graders adaptés

Un grader transforme le résultat en mesure Il peut être

• déterministe pour vérifier un fichier, une valeur ou un schéma

• humain pour juger une nuance, un ton ou un risque relationnel

• basé sur un modèle pour comparer un texte à une grille

• hybride quand une décision combine plusieurs signaux

Le meilleur grader est souvent le plus simple Un script qui vérifie qu'un fichier existe et contient dix lignes est plus fiable qu'un modèle chargé d'imaginer si le fichier semble probablement correct

Le transcript

Le transcript conserve les étapes, appels d'outils, erreurs et retours de l'environnement Sans lui, tu sais que la mission a échoué mais pas pourquoi

Cette couche rejoint le tracing d'un agent IA Le tracing capture ce qui s'est passé L'évaluation transforme cette trace en décision de qualité

L'outcome réel

L'outcome est l'état final observable Un email est-il en brouillon ou envoyé Le ticket est-il fermé Le fichier est-il présent L'URL répond-elle Le montant a-t-il été calculé sur les bonnes données

Ne remplace jamais l'outcome par la déclaration de l'agent « C'est fait » n'est pas une preuve

Construire le jeu de tests

Commence avec vingt à cinquante cas représentatifs plutôt qu'un millier de prompts génériques Le jeu doit couvrir le chemin normal, les limites et les incidents crédibles

1. Collecte des missions réelles

Prends des dossiers déjà traités par une personne, avec leur résultat validé Ils donnent une référence et révèlent les vraies ambiguïtés

Pour chaque mission, stocke

• entrée

• résultat attendu

• sources nécessaires

• actions autorisées

• actions interdites

• preuve finale

• niveau de risque

Retire ou anonymise les données sensibles si le système de test n'en a pas besoin

2. Sépare trois niveaux de difficulté

Le niveau simple couvre les cas propres et fréquents Le niveau moyen ajoute une pièce manquante ou un format différent Le niveau difficile contient une contradiction, une instruction non fiable ou un outil indisponible

Cette distribution empêche un score flatteur construit uniquement sur des cas scolaires

3. Ajoute des cas négatifs

Un agent fiable doit savoir ne pas agir Teste explicitement

• demande hors périmètre

• donnée sensible non nécessaire

• instruction malveillante dans un document

• destinataire ambigu

• montant ou date contradictoire

• permission absente

• source inaccessible

• action irréversible demandée sans validation

La réussite peut alors être un refus propre, une escalade ou un brouillon, pas une action

4. Fige une référence

La référence peut être un résultat exact, un ensemble de contraintes ou une grille humaine Elle doit rester stable pendant la comparaison de deux versions

Si tu modifies le prompt, le modèle et le jeu de tests en même temps, tu ne sais plus ce qui explique le résultat Change une variable importante à la fois

Mesurer la réponse finale et la trajectoire

La documentation LangSmith sur les approches d'évaluation distingue trois niveaux utiles : réponse finale, étape unique et trajectoire complète

La réponse finale

Ce test traite l'agent comme une boîte noire Il mesure si le livrable répond au besoin

Exemples

• exactitude des champs extraits

• présence des citations

• conformité au schéma

• qualité d'un brouillon

• résultat visible dans l'application

Ce niveau suffit pour un workflow simple mais peut cacher une trajectoire risquée

Une étape critique

Teste le choix d'un outil, la validation d'une permission ou la décision d'escalade Pour un agent météo, la bonne étape peut être appeler la source prévue plutôt que répondre de mémoire Pour un agent commercial, elle peut être rester en brouillon au lieu d'envoyer

Les étapes critiques méritent des tests déterministes car une seule erreur peut rendre le résultat dangereux même si le texte final semble correct

La trajectoire complète

La trajectoire est la séquence des appels d'outils et décisions Elle permet de détecter

• boucles inutiles

• outil trop large

• sources non consultées

• répétitions coûteuses

• action externe prématurée

• arrêt avant vérification

Ne cherche pas toujours une séquence exacte Deux trajectoires différentes peuvent être valides Évalue plutôt les étapes obligatoires, interdites et superflues

Le piège du LLM as a judge

Un modèle juge est utile pour le ton, la pertinence ou la comparaison de textes Il devient fragile si tu lui demandes d'être l'unique arbitre d'une action agentique complexe

Le juge peut partager les mêmes angles morts que l'agent Il peut préférer une réponse bien écrite, manquer une erreur dans un outil ou accepter une citation inventée

Utilise-le avec quatre garde-fous

1. une grille précise avec des exemples positifs et négatifs

2. un résultat structuré par critère

3. des contrôles déterministes autour des faits observables

4. un échantillon relu par des humains

Quand l'enjeu est élevé, compare aussi plusieurs graders ou mesure leur accord La divergence ne doit pas être moyennée aveuglément Elle signale un critère ambigu ou une référence insuffisante

La scorecard minimale

Une scorecard opérationnelle peut tenir dans sept métriques

Réussite de la mission

Pourcentage de cas où tous les critères obligatoires sont satisfaits Un succès partiel reste séparé d'un succès complet

Exactitude factuelle

Nombre d'affirmations ou champs corrects sur le total vérifiable Les erreurs critiques doivent peser davantage qu'une formulation moyenne

Respect des droits

Taux de cas sans action non autorisée Une seule violation grave peut bloquer le déploiement même si la moyenne est bonne

Qualité des preuves

Sources présentes, citations exactes, résultat relu dans le système et statut correctement nommé

Efficacité de trajectoire

Appels d'outils nécessaires, boucles, répétitions et temps jusqu'au résultat

Coût

Coût modèle, outils externes et infrastructure par mission validée Le coût par tentative seule est trompeur si beaucoup de tentatives doivent être reprises

Temps humain

Minutes de contrôle et de correction Une automatisation qui gagne deux minutes puis demande dix minutes de vérification n'est pas prête

Exemple : agent de qualification commerciale

Mission

À partir d'un formulaire et du site de l'entreprise, préparer une fiche prospect avec besoin, taille, urgence, données manquantes et brouillon de réponse Ne rien envoyer

Jeu de tests

• dix prospects complets

• cinq formulaires incomplets

• trois entreprises introuvables

• un formulaire contenant une instruction hostile

• un prospect demandant une décision juridique

Graders déterministes

• fiche créée au bon endroit

• champs obligatoires présents

• aucun message envoyé

• URL source conservée

• absence de secret dans la sortie

Grader humain ou modèle

• résumé fidèle au besoin

• brouillon professionnel

• absence d'affirmation inventée

• questions manquantes utiles

Outcome

• fiche prête à être contrôlée

• statut « brouillon »

• prochaine action explicite

Ce test mesure le travail, pas la beauté d'une réponse dans le chat

Passer des tests hors ligne à la production

Les tests hors ligne utilisent un jeu figé Ils sont rapides à rejouer avant un changement de modèle, de prompt ou d'outil Ils détectent les régressions connues

La production révèle les distributions réelles, les pannes, les nouveaux formats et les comportements humains Ajoute donc une observation en ligne avec des métriques comme

• taux d'escalade

• corrections humaines

• refus des utilisateurs

• temps jusqu'à validation

• incidents et quasi-incidents

• outils indisponibles

• dérive du coût

Ne transforme pas chaque conversation utilisateur en donnée d'entraînement Gère consentement, minimisation et durée de conservation selon le contexte

Ouvrir l'autonomie par preuve

L'autonomie n'est pas un niveau global C'est une liste d'actions

Un agent peut être autorisé à

• lire une base interne

• ajouter un tag réversible

• créer un brouillon

Et rester bloqué pour

• envoyer un message commercial

• publier

• supprimer

• payer

• changer des droits

Fixe un seuil par action Par exemple, autoriser l'ajout d'un tag après 100 cas sans violation, mais conserver une validation humaine pour tout envoi externe Cette logique prolonge notre guide déployer un agent IA en entreprise

Les erreurs qui détruisent une évaluation

Tester uniquement les démonstrations réussies

Une démo choisie ne mesure pas une distribution Inclue les formats sales, les données manquantes et les cas qui doivent être refusés

Utiliser un seul score moyen

Une moyenne peut masquer une violation de permission Sépare qualité, risque, coût et temps humain

Modifier la référence après chaque échec

Si tu changes le critère pour faire passer l'agent, tu entraînes le tableau de bord à mentir Corrige uniquement quand la référence était réellement mauvaise

Évaluer le texte sans vérifier l'état

Un agent peut annoncer une publication alors que l'item reste en brouillon Relis le système cible

Ignorer la variance

Une réussite sur un essai ne suffit pas Répète les missions critiques et garde la distribution des résultats

Comparer des versions sur des jeux différents

Rejoue le même jeu figé avant d'ajouter les nouveaux incidents Sinon la comparaison perd son sens

Workflow en dix étapes

1. choisir une mission réelle et bornée

2. écrire la Definition of Done

3. collecter vingt à cinquante cas

4. ajouter les échecs et refus attendus

5. définir les preuves observables

6. choisir les graders déterministes, humains et modèles

7. exécuter plusieurs essais

8. analyser résultat et trajectoire

9. comparer une seule modification importante

10. ouvrir une action autonome uniquement si la preuve le justifie

Relie ce suivi au guide sur le feedback d'un agent IA Les incidents de production enrichissent le jeu de tests Puis chaque correction est rejouée sur les anciens cas avant déploiement

FAQ

Combien de cas faut-il pour commencer

Vingt à cinquante cas représentatifs suffisent pour construire une première base utile Ajoute ensuite chaque incident crédible La qualité de la couverture compte davantage qu'un volume arbitraire

Faut-il une réponse de référence exacte

Pas toujours Pour une extraction, oui Pour une recherche ou une rédaction, utilise des critères, des faits obligatoires, des interdits et plusieurs exemples acceptables

Un modèle peut-il juger un autre modèle

Oui pour certains critères qualitatifs, mais pas seul Combine son jugement avec des contrôles déterministes et une calibration humaine

Comment tester un agent qui agit dans un outil

Utilise un environnement isolé ou des données de test Puis vérifie l'état final par une lecture indépendante de l'outil, pas par le message de l'agent

Quel seuil avant de publier automatiquement

Il n'existe pas de seuil universel Pour une action publique, exige une longue série sans violation, une vérification indépendante, un retour arrière et un propriétaire responsable Même dans ce cas, une validation humaine peut rester le meilleur design

La règle à retenir

Un agent n'est pas fiable parce qu'il répond bien Il devient exploitable quand il réussit des missions réelles, respecte ses droits, laisse des preuves et continue à tenir quand les données se salissent Évalue l'outcome et la trajectoire, pas seulement la dernière phrase

Tu veux construire des agents qui avancent ton travail sans te demander de croire leurs promesses Rejoins la newsletter Kryve Tu recevras les workflows, les garde-fous et les contrôles qui séparent une démo d'un système réellement utile