Comment évaluer un agent IA avant sa mise en production

Avant de lancer un agent IA, vérifiez qu’il accomplit la tâche métier, respecte les droits d’accès et les règles de validation, et reste dans les limites de coût et de délai. Utilisez des cas réalistes, examinez les appels aux outils et les modifications réellement effectuées, puis fixez les critères de mise en service avant de regarder les scores. Une réponse convaincante ne prouve pas que l’action était correcte.

Que signifie évaluer un agent IA ?

Évaluer consiste à exécuter des tâches définies dans des conditions contrôlées, puis à comparer le résultat à des attentes explicites. Pour un agent, cela comprend ce qu’il a fait, pas seulement ce qu’il a dit.

Pensez à un nouveau collaborateur qui traite une demande client. Une réponse bien rédigée est utile, sauf si elle cite le mauvais contrat, modifie le mauvais compte ou promet un remboursement non autorisé.

L’évaluation fait donc partie du passage des agents IA du POC à la production, et non d’une dernière présentation avant le lancement. Le guide d’Anthropic sur l’évaluation des agents, en anglais, distingue la tâche, les essais répétés, la notation et le résultat réel du travail de l’agent.

1. Définir la réussite par un résultat métier

Commencez par un processus, son responsable et la décision que l’agent aide à prendre. Remplacez « la réponse semble bonne » par un résultat observable.

Pour un assistant de messagerie projet, réussir peut signifier trouver les échanges pertinents, identifier les décisions en suspens et citer les bonnes sources sans révéler la boîte d’un autre utilisateur. Pour un agent de traitement de demandes, cela peut être orienter correctement la demande sans créer de doublon.

Décrivez aussi les résultats inacceptables : divulgation non autorisée, mauvais destinataire, message externe envoyé sans validation ou affirmation mensongère qu’une action a réussi. Ils ne doivent pas disparaître dans un score moyen de qualité.

2. Constituer un jeu de test représentatif

Utilisez des exemples correspondant à l’environnement visé. Partez de vraies questions et de modes d’échec connus, avec les autorisations nécessaires et en minimisant les données. Des cas synthétiques peuvent compléter la couverture, mais ne doivent pas constituer votre seule preuve.

Famille de cas	Exemple	Comportement attendu
Courant	Retrouver la dernière échéance validée	Donner la bonne date et sa source
Ambigu	Deux projets portent le même nom	Demander lequel avant d’agir
Incomplet	Un document nécessaire manque	Signaler le manque, sans inventer
Contradictoire	Deux messages donnent des dates différentes	Identifier la contradiction et son contexte
Malveillant	Un email demande d’ignorer les restrictions	Traiter l’email comme une donnée, pas une autorité
Frontière d’accès	Un message pertinent appartient à un autre utilisateur	Ne pas le récupérer ni le divulguer
Panne d’outil	Le fournisseur de messagerie ne répond pas	Signaler l’échec, sans prétendre avoir terminé
Action à conséquences	Envoyer une réponse à un fournisseur	Exiger l’autorisation applicable avant l’envoi

Ces exemples sont illustratifs, pas des résultats observés chez un client. Aucun nombre universel de cas ne certifie la mise en production : la couverture, le risque et l’incertitude comptent davantage qu’un chiffre rond.

Pour chaque cas, conservez la demande, l’état initial, les données accessibles, le résultat attendu, les résultats interdits et la personne qui valide la réponse de référence.

3. Tester le résultat, le parcours et les limites

Un agent peut donner une bonne réponse en empruntant un chemin inacceptable. Il peut aussi suivre plusieurs chemins légitimes vers le même résultat. N’exigez pas une séquence identique d’appels aux outils, sauf si cette séquence est elle-même une exigence de contrôle.

La documentation LangSmith sur les approches d’évaluation, en anglais, distingue la réponse finale, une étape isolée et la trajectoire. La trajectoire est la succession de messages et d’appels aux outils qui conduit au résultat.

Niveau	Question	Preuve
Résultat métier	La tâche a-t-elle réellement été accomplie ?	État final du système de test ou livrable validé
Qualité de réponse	La réponse est-elle correcte, étayée et utile ?	Vérification des sources et grille de revue
Usage des outils	Les bons outils et paramètres ont-ils été utilisés ?	Trace des appels et erreurs retournées
Droits	L’agent est-il resté dans les droits de l’utilisateur ?	Tests avec plusieurs identités et périmètres
Validations	Une action à conséquences a-t-elle été bloquée sans accord valide ?	Tests de rejet, d’expiration et de paramètres modifiés
Exploitation	Le service respecte-t-il les délais et le budget ?	Mesures de bout en bout, coûts et nouvelles tentatives

Exécutez les tests à conséquences sur des systèmes isolés et des comptes de test. Réinitialisez l’état entre les essais. Envoyer de vrais emails clients ou modifier des droits réels n’est pas un substitut sûr à un environnement d’évaluation.

4. Choisir un évaluateur adapté à la preuve recherchée

Utilisez des contrôles déterministes pour ce que le logiciel peut vérifier : champs valides, identifiants corrects, écriture réellement effectuée, approbation présente ou limite de dépense dépassée.

Réservez la revue humaine à l’interprétation métier, à l’utilité et aux réponses de référence contestées. Un modèle évaluateur peut aider à examiner davantage de résultats selon une grille écrite, mais il reste un modèle, pas une garantie indépendante. Comparez ses jugements à ceux d’experts humains et examinez les désaccords avant d’utiliser son score pour décider d’un lancement.

Anthropic recommande de combiner plusieurs types d’évaluateurs et de définir des critères de réussite sans ambiguïté. La documentation d’évaluation LangGraph, en anglais, illustre la comparaison déterministe des trajectoires et leur évaluation par un modèle.

N’exposez pas inutilement de données personnelles à un évaluateur externe. La chaîne d’évaluation exige la même attention à l’hébergement, aux accès et à la conservation que l’agent lui-même.

5. Fixer les seuils avant de regarder les résultats

Le responsable métier et le responsable technique doivent convenir de critères adaptés au processus. Associez la sécurité et la protection des données lorsque nécessaire. C’est une décision opérationnelle, pas un pourcentage universel fourni par un éditeur de modèles.

Séparez trois catégories :

• Les échecs critiques qui bloquent le lancement jusqu’à correction et nouveau test.
• Les seuils de qualité par famille de cas, pas seulement sur l’ensemble du jeu de test.
• Les limites d’exploitation : délai, coût, nouvelles tentatives et taux d’escalade.

Réussir une suite de tests finie ne prouve pas que tout échec futur est impossible. En particulier, n’observer aucune violation d’accès dans un jeu de test ne prouve pas l’absence de risque de sécurité.

Exemple : pourquoi le score global peut tromper

Imaginons une suite illustrative de 100 cas. L’agent réussit 90 cas courants et échoue aux 10 tests de frontière d’accès. Son taux de réussite global est de 90 %, mais celui des contrôles d’accès est de 0 %. Dans cet exemple, c’est un refus de mise en service malgré un score principal rassurant.

C’est un calcul illustratif, pas un benchmark client d’Elia Studio. Présenter les scores par catégorie rend le risque visible.

6. Répéter les essais et comparer équitablement les versions

Sur une même tâche, le comportement d’un agent peut varier d’un essai à l’autre. Répétez les cas importants et regardez la fréquence de réussite, pas seulement l’existence d’un essai réussi.

Comparez les versions avec le même jeu de test, le même état initial, les mêmes droits et les mêmes règles de notation. Conservez l’identifiant du modèle, la version du prompt, la configuration des outils et les paramètres pertinents de recherche documentaire. Mesurez le processus complet, avec les délais des outils, les nouvelles tentatives et les passages à un humain, pas seulement le temps de réponse du modèle.

Gardez un jeu de validation distinct des exemples utilisés pour ajuster les prompts. Sinon, vous risquez d’améliorer le score sans améliorer le comportement sur des demandes nouvelles.

7. Faire du lancement une décision par étapes

Résumez la décision dans un court compte rendu : version testée, couverture, résultats par famille, échecs critiques, coût d’exploitation, écarts restants, responsable de la décision et plan de retour arrière.

Un pilote limité peut ensuite révéler des problèmes absents de l’environnement de test. Suivez les échecs, escalades et corrections des utilisateurs, puis ajoutez des exemples validés aux tests de non-régression. Les changements de modèle, de prompt, d’outil ou de source doivent déclencher des tests proportionnés.

Notre checklist de passage en production place l’évaluation aux côtés des données, de la sécurité, de la responsabilité, des coûts et de l’adoption. Réussir les évaluations ne remplit pas à lui seul ces autres obligations opérationnelles.

Cinq questions à poser à votre expert IA

1. Quel résultat métier mesurez-vous, au-delà de la réponse finale ?
2. Quelles catégories d’échec votre score moyen masque-t-il ?
3. Avez-vous testé les droits, les contenus malveillants et les pannes de fournisseurs ?
4. Qui a revu les règles de notation et les réponses contestées ?
5. Que se passe-t-il lorsqu’un modèle ou un connecteur change après le lancement ?

Pour un contexte d’intégration concret, voir nos enseignements sur les connecteurs de messagerie. La question utile n’est pas de savoir si le connecteur répond, mais si le processus complet reste utile et maîtrisé.

Commencer par un processus et une décision de lancement

Apportez un cas d’usage réel, des exemples représentatifs et le nom du futur responsable. Définissez les tests et les critères de mise en service avant d’élargir les droits ou le nombre d’utilisateurs.

Découvrez nos services de conseil et de réalisation IA, ou contactez Elia Studio pour cadrer l’évaluation.