Évaluer un agent IA : construire les preuves avant de généraliser son usage

Une démonstration réussie donne envie de déployer un agent. Elle ne permet pas encore de décider à quelles tâches lui faire confiance. Pour un dirigeant ou un CTO, la question devient rapidement concrète : quelles demandes peut-il traiter, à quel coût, avec quels défauts acceptables et quel recours humain ?

L'évaluation sert à rendre ces décisions explicites. Dans mon approche, elle commence pendant le cadrage et accompagne les évolutions du système. Elle donne à l'équipe des critères pour choisir un modèle, modifier un prompt ou ouvrir l'outil à davantage d'utilisateurs.

Définir la réussite avec les personnes qui connaissent le métier

« Donner une bonne réponse » est un objectif trop vague pour piloter un développement. Un agent d'assistance interne doit-il retrouver la procédure, citer sa source, demander une précision, ou réaliser une opération ? Chaque fonction appelle une définition différente du succès.

Je commence par décrire les résultats attendus, les erreurs tolérables et les situations qui exigent un relais humain. Prenons un exemple fictif dans le support logiciel : lorsqu'une version du produit n'est pas précisée, l'agent doit demander cette information avant de proposer une manipulation incompatible.

Le critère est alors observable. La fluidité du texte compte, mais le choix de demander une précision compte davantage. Un expert métier peut expliquer cette distinction ; le développeur peut ensuite l'intégrer au protocole d'évaluation.

Le temps des experts constitue souvent la ressource la plus difficile à mobiliser. Je recommande des séances courtes autour de cas concrets, avec un responsable identifié pour arbitrer les désaccords. Une grille que personne n'a le temps d'utiliser n'aide pas à fiabiliser un produit.

Constituer un jeu de référence représentatif

Le jeu de référence, souvent appelé golden set, rassemble des demandes et leurs critères de réussite validés. Une réponse idéale peut être utile, mais elle ne doit pas obliger l'agent à reproduire une formulation unique.

Pour chaque cas, je propose de conserver la demande, le contexte disponible, les éléments indispensables, les erreurs interdites et le comportement attendu en cas d'incertitude. Les sources métier doivent être datées ou versionnées pour éviter qu'une évolution documentaire invalide silencieusement le test.

Un corpus utile couvre plusieurs situations :

• les demandes fréquentes qui concentrent la valeur du service ;
• les formulations ambiguës et les informations manquantes ;
• les cas rares dont l'échec aurait un impact élevé ;
• les questions hors périmètre et les demandes non autorisées ;
• les conversations où une information change en cours d'échange.

Je sépare les exemples utilisés pour améliorer le système de ceux réservés à sa validation. Sinon, l'équipe risque de perfectionner les réponses à un échantillon connu sans améliorer le comportement général. Le corpus doit ensuite évoluer à partir des difficultés rencontrées sur le terrain.

Combiner trois méthodes de contrôle

Les tests déterministes gardent toute leur place. Le format d'une sortie structurée, le calcul d'un montant, les permissions d'un outil ou l'absence d'une action interdite se vérifient par du code. Il serait coûteux et moins fiable de demander à un LLM de contrôler ce que l'application peut établir directement.

Une deuxième couche évalue la qualité sémantique : pertinence, complétude, fidélité aux documents, traitement de l'incertitude. Un modèle utilisé comme juge peut noter ces dimensions selon une grille explicite. Il n'a pas nécessairement besoin d'être spécialisé : son aptitude à votre tâche doit être mesurée.

La troisième couche est la revue humaine, indispensable pour qualifier les références, interpréter les désaccords et examiner les erreurs importantes. Langfuse permet d'articuler ces méthodes avec des jeux de données, des expériences et des scores, avant déploiement comme sur les traces de production. La documentation d'évaluation décrit cette articulation.

Évaluer aussi celui qui évalue

Un juge LLM peut se tromper, préférer un texte plus long ou être influencé par l'ordre de présentation des réponses. Ces biais sont notamment étudiés dans les travaux Judging LLM-as-a-Judge. Un score automatique doit donc être traité comme une mesure à calibrer.

Je recommande de comparer ses verdicts à des annotations humaines sur un échantillon représentatif. Les désaccords permettent d'affiner les critères, de repérer un manque de contexte ou de changer de juge. Pour les comparaisons entre réponses, varier leur ordre aide à détecter un effet de position.

La grille et la version du juge doivent être conservées avec les résultats. Modifier l'évaluateur en même temps que l'agent peut rendre deux campagnes difficilement comparables. Il faut aussi éviter de confondre une justification convaincante du juge avec la preuve que sa note est correcte.

Tester le parcours de l'agent, au-delà de son texte

Un agent peut produire une excellente réponse après avoir effectué une mauvaise action. L'évaluation doit donc examiner les outils choisis, leurs paramètres, les validations demandées et l'état final du système.

Dans un scénario fictif de gestion de rendez-vous, l'agent doit préserver le rendez-vous initial tant que le nouveau créneau n'est pas confirmé. Évaluer seulement la phrase « votre rendez-vous a été déplacé » masquerait une partie essentielle du risque.

Ces essais s'exécutent sur des environnements isolés ou avec des outils simulés lorsque les actions auraient des effets réels. Les campagnes comparent ensuite la version candidate à une référence sur le même corpus. Pour les cas sensibles à la variabilité du modèle, plusieurs exécutions éclairent mieux la stabilité qu'un seul passage.

Utiliser les résultats pour décider

Je recommande des critères distincts par famille d'usage. Une moyenne générale peut cacher une régression sur les cas difficiles ou sensibles. Les seuils de validation doivent tenir compte de leur impact, du budget et du temps de réponse attendu.

Après déploiement, l'observabilité permet de sélectionner des traces à évaluer, d'analyser les retours utilisateurs et d'enrichir le corpus. Cette surveillance complète les campagnes précédentes ; elle ne transforme pas un échantillon de bons résultats en garantie universelle.

Avec LeoWeb, je vous aide à transformer vos attentes métier en protocole de validation, puis à l'intégrer au développement. Vous disposez de critères pour accepter une version, demander une correction ou limiter son périmètre. Parlons de votre agent et des décisions que vous devez sécuriser.