Évaluation d’un agent IA : recetter avant la production
Évaluez un agent IA avec une méthode concrète : jeu d’essai, résultat, trajectoire, outils, effets, coût, incidents et suivi en production.
Évaluer un agent IA ne consiste pas à relire seulement sa réponse finale. Il faut vérifier la tâche accomplie, le chemin suivi, les outils appelés, les effets produits dans les systèmes, le coût, le délai et la manière dont l’agent réagit lorsque les données manquent ou qu’un service tombe en panne. Cette recette commence avant la production et continue après le lancement.
La bonne unité de mesure n’est donc ni le nombre de messages, ni une note d’éloquence. C’est le résultat métier accepté, obtenu sans action interdite et avec une trajectoire explicable. Une matrice en sept preuves — tâche, jeu d’essai, résultat, trajectoire, effet, coût et décision — permet de passer du « cela semble fonctionner » à une décision : déployer, corriger, limiter ou arrêter.
Pourquoi la réponse finale ne suffit pas
Un assistant conversationnel peut produire un texte. Un agent peut aussi rechercher un dossier, choisir un outil, modifier un champ, créer une tâche, préparer un envoi ou demander une validation. Sa sortie réelle se trouve parfois dans le CRM, la messagerie ou le logiciel métier, pas dans la phrase affichée à l’écran.
Une réponse « la demande a été traitée » peut ainsi masquer plusieurs réalités :
- le bon dossier a été lu et la tâche correcte a été créée ;
- le résultat est juste, mais trois outils inutiles ont doublé le coût et le délai ;
- le brouillon est convaincant, mais il repose sur une ancienne version du document ;
- l’agent a appelé le bon outil avec le mauvais identifiant ;
- l’action a échoué, alors que le message final annonce une réussite ;
- l’agent a terminé la tâche en utilisant un droit qu’il ne devait pas posséder.
Le livre blanc du Hub France IA sur l’évaluation de l’IA agentique, publié en septembre 2026, recommande précisément d’observer les résultats, les trajectoires, le choix des outils, les coûts, la latence et la résilience. Il distingue aussi plusieurs moments : évaluation sur un jeu fixe, simulation, tests adverses et suivi en production.
Cette intention est différente du cadrage d’un agent IA en entreprise, qui reste propriétaire de la mission, des données, des permissions, de la validation humaine et du retrait. Elle arrive également après le guide pour choisir une solution IA en PME, centré sur la comparaison des fournisseurs. Ici, l’agent existe déjà sous forme de prototype ou de pilote : il faut prouver son travail, puis détecter ses régressions.
Écrire le contrat de recette avant de choisir les métriques
Une métrique n’a de sens que si elle protège une décision. Commencez par écrire le contrat de la tâche en langage métier :
- Décrire l’événement qui déclenche le travail.
- Nommer le résultat observable attendu.
- Séparer les actions autorisées, soumises à validation et interdites.
- Définir les erreurs acceptables, coûteuses et critiques.
- Fixer le délai et le coût compatibles avec le processus.
- Prévoir le comportement attendu lorsque l’agent ne sait pas ou qu’un outil échoue.
- Attribuer la décision finale à un propriétaire métier et l’exploitation à un propriétaire technique.
« Traiter les demandes clients » ne constitue pas un contrat. « Classer une demande entrante dans six catégories, retrouver la procédure en vigueur, créer un brouillon et une tâche à vérifier sans envoyer ni modifier le client » peut être testé. Il possède un début, une fin, des droits et une personne capable de juger le résultat.
Cette précision protège aussi contre une mauvaise comparaison. Un agent peut améliorer sa note en refusant davantage, en allongeant ses réponses ou en multipliant les recherches. Le contrat indique si ce comportement aide réellement la tâche ou déplace seulement le travail vers l’humain.
La matrice Anakyos des sept preuves d’évaluation
Remplissez une ligne par tâche complète, pas par prompt. Une même architecture peut être acceptable pour préparer un brouillon et insuffisante pour déclencher un remboursement.
| Preuve | Question à trancher | Artefact attendu | Signal d’arrêt |
|---|---|---|---|
| Tâche | quel état métier doit changer, pour qui et dans quelles limites ? | entrée, sortie, responsable, actions autorisées et interdites | le succès dépend d’une impression générale |
| Jeu d’essai | quels cas représentent le travail réel et ses exceptions ? | cas nominaux, limites, incidents, attaques et vérité de référence | les exemples sont choisis après avoir vu les résultats |
| Résultat | la tâche est-elle complète, exacte et utilisable ? | critères observables, tolérances et erreurs critiques | une moyenne masque une erreur interdite |
| Trajectoire | l’agent a-t-il suivi un chemin acceptable ? | étapes, sources, choix, boucles, reprises et motif d’arrêt | aucune trace ne permet de comprendre l’exécution |
| Effet | les bons outils ont-ils modifié le bon état ? | appel, arguments, réponse, état avant/après et annulation | le texte final sert de seule preuve d’action |
| Coût | le service reste-t-il soutenable avec la revue humaine ? | latence, consommation, appels, correction et coût par résultat accepté | le gain dépend d’un contrôle plus long que le travail initial |
| Décision | quelle suite les preuves autorisent-elles ? | déployer, corriger, limiter ou arrêter, avec propriétaire et date de revue | le pilote devient permanent sans décision écrite |
Cette matrice ne remplace ni un audit de sécurité ni une analyse juridique lorsque le contexte les exige. Elle empêche surtout une belle démonstration de recevoir des permissions ou du trafic réel avant d’avoir prouvé la tâche complète.
Construire un jeu d’essai qui ressemble au travail
Le jeu d’essai doit être préparé avant les réglages finaux. Sinon, chaque mauvais résultat conduit à modifier les cas jusqu’à ce que la démonstration paraisse réussie.
Conservez trois ensembles distincts :
- un jeu de construction pour concevoir les instructions et les outils ;
- un jeu de réglage pour comparer les versions et corriger les écarts ;
- un jeu réservé que l’équipe ne découvre qu’au moment de la décision.
Les cas doivent provenir de situations autorisées et suffisamment représentatives. Ils peuvent être anonymisés ou synthétiques lorsque les données réelles sont sensibles, mais ils doivent conserver les difficultés du processus : pièces absentes, homonymes, doublons, délais, variantes de vocabulaire, règles contradictoires et outils indisponibles.
Pour une tâche qui interroge des métriques, stabilisez d’abord les sources et les définitions avec la méthode de préparation des données d’entreprise pour un agent IA. Une évaluation ne peut pas distinguer une erreur de l’agent d’une définition métier qui change selon l’interlocuteur.
Dix scénarios de recette avant la production
Un petit jeu contradictoire apprend davantage que cent cas faciles. Adaptez ces scénarios au processus réel.
| Scénario | Contrôle | Résultat attendu |
|---|---|---|
| Cas nominal | données complètes et outil disponible | tâche terminée avec les bonnes sources et le bon état final |
| Entrée incomplète | pièce, identifiant ou information manque | demande ciblée ou abstention, aucune donnée inventée |
| Ambiguïté | deux clients, contrats ou actions sont plausibles | arrêt avant action et explication de l’ambiguïté |
| Règles contradictoires | deux sources donnent des consignes différentes | conflit exposé et source prioritaire appliquée ou escaladée |
| Outil indisponible | l’API échoue ou répond trop tard | reprise bornée, pas de boucle infinie, passage au mode dégradé |
| Résultat partiel | une étape réussit et la suivante échoue | état intermédiaire visible, doublon évité à la reprise |
| Instruction adverse | un document demande d’ignorer la mission | instruction externe refusée, incident tracé |
| Permission refusée | l’action dépasse le rôle de l’agent | aucun contournement, validation ou escalade explicite |
| Coût anormal | les recherches ou appels se multiplient | limite atteinte, arrêt propre et cause observable |
| Changement de version | modèle, outil, instruction ou donnée évolue | jeu réservé rejoué et comparaison avant/après conservée |
Répétez les cas non déterministes. Une réussite unique ne prouve pas que le comportement restera stable. La fréquence de répétition dépend du coût de l’erreur : une suggestion réversible peut tolérer davantage de variation qu’une action financière ou un changement de droit.
Mesurer le résultat, la trajectoire et l’effet
Une évaluation utile combine des contrôles déterministes, une lecture humaine et, dans certains cas, un modèle juge. Aucun de ces moyens ne suffit seul.
Contrôler le résultat métier
Lorsque la sortie possède une vérité connue, utilisez une vérification explicite : catégorie attendue, somme, statut, identifiant, présence d’une source ou respect d’une règle. Lorsque plusieurs réponses sont acceptables, définissez une grille courte avec des niveaux qui ne se chevauchent pas.
Séparez toujours les erreurs critiques de la moyenne. Un taux de réussite de 96 % reste insuffisant si les 4 % restants contiennent un accès interdit, un envoi non validé ou une mauvaise personne ciblée.
Examiner la trajectoire sans exiger un chemin unique
Deux trajectoires différentes peuvent être valides. Ne pénalisez pas l’agent parce qu’il n’a pas reproduit exactement un scénario écrit à l’avance. Vérifiez plutôt des invariants : source autorisée, ordre indispensable, nombre maximal de boucles, absence d’outil interdit, justification d’une escalade et arrêt dans le budget prévu.
Le Hub France IA rappelle que l’efficacité porte aussi sur le chemin emprunté : étapes redondantes, mauvais choix d’outil, latence et coût. Un agent qui termine la tâche après quinze appels là où trois suffisent n’est pas nécessairement prêt à absorber le volume réel.
Vérifier les effets dans les systèmes
Chaque action doit laisser une preuve distincte du récit de l’agent : nom de l’outil, arguments utiles, identité utilisée, réponse technique, état avant/après, identifiant de l’objet créé et possibilité d’annulation. Les secrets et données inutiles ne doivent pas être copiés dans les traces.
Cette preuve permet de distinguer trois incidents : l’agent a choisi la mauvaise action, l’outil a reçu de mauvais arguments ou le service a échoué malgré une demande correcte. La correction n’est pas la même.
Ce qu’un modèle juge peut — et ne peut pas — décider
Un modèle peut aider à noter la clarté, la complétude ou le respect d’une grille lorsqu’une comparaison exacte est impossible. Il peut aussi regrouper des traces ou signaler des cas atypiques pour une revue humaine.
Il ne doit pas devenir la seule preuve d’un effet externe. Un modèle juge ne sait pas, à partir de la réponse finale, si le bon enregistrement a été modifié. Il peut également reproduire les préférences du système évalué, favoriser une formulation ou être instable lorsque la consigne change.
Calibrez donc le juge sur un petit ensemble déjà noté par les personnes métier. Comparez les désaccords, conservez sa version et réservez les contrôles déterministes aux droits, montants, identifiants, états et actions interdites. L’humain tranche les cas dont la conséquence dépasse la tolérance écrite.
Passer du laboratoire à la production par portes successives
L’annonce par OpenAI, le 29 septembre 2026, d’agents capables d’utiliser un ordinateur et de prendre en charge des responsabilités continues illustre l’élargissement du pouvoir d’action disponible. Elle ne prouve pas qu’un agent particulier est prêt pour un processus donné. Plus l’outil peut agir, plus la preuve doit suivre des portes explicites.
| Porte | Environnement | Preuve minimale | Action autorisée |
|---|---|---|---|
| 1 — hors ligne | cas enregistrés, aucun système réel | résultat, trajectoire et erreurs critiques connus | aucune écriture externe |
| 2 — bac à sable | doubles de services et données de test | outils, reprises, doublons et annulation vérifiés | écritures fictives ou entièrement réversibles |
| 3 — observation | production en lecture seule ou mode ombre | comparaison avec la décision humaine et coût réel | proposition sans effet métier |
| 4 — exposition limitée | petit groupe, volume et durée bornés | seuils, alertes, validation et repli tenus | actions réversibles dans une liste autorisée |
| 5 — exploitation | périmètre stable, propriétaire nommé | suivi continu, revue datée et procédure d’incident | seulement les actions ayant franchi les portes précédentes |
Une porte ne s’ouvre pas parce que le calendrier l’exige. Elle s’ouvre lorsque les preuves du niveau précédent répondent au contrat de recette.
Surveiller la production sans collecter tout le raisonnement
Après le lancement, rejouez régulièrement le jeu réservé et surveillez quelques signaux capables de changer une décision :
- part des tâches acceptées sans correction critique ;
- erreurs interdites, toujours séparées du score global ;
- taux d’escalade et d’abstention utile ;
- choix d’outil invalide ou appel avec arguments refusés ;
- reprise après panne et doublons évités ;
- latence et coût par résultat accepté ;
- temps de contrôle humain ;
- écart entre les nouvelles situations et le jeu d’essai.
Ne journalisez pas davantage de données parce que l’outil le permet. Conservez ce qui sert à diagnostiquer, prouver et corriger, avec une durée et des accès adaptés. Une trace utile explique l’action sans devenir une copie permanente des dossiers traités.
Définissez également les changements qui imposent une nouvelle recette : modèle, instructions, mémoire, outil, permission, source documentaire, schéma de données ou règle métier. Une mise à jour technique peut modifier la trajectoire même si l’interface ne change pas.
Exemple fictif : préparer l’affectation d’une demande de maintenance
L’exemple suivant est fictif. Une PME veut utiliser un agent pour lire une boîte dédiée, reconnaître le client, classer la demande, retrouver la procédure et créer un brouillon ainsi qu’une tâche « à vérifier ». L’agent ne doit ni envoyer, ni modifier le client, ni fixer une date d’intervention.
Le jeu réservé contient trente dossiers : demandes courantes, client introuvable, doublon, pièce absente, équipement ambigu, urgence supposée, instruction malveillante dans une pièce jointe et panne du CRM. Chaque cas indique la catégorie, les sources autorisées, l’état final et l’erreur critique à éviter.
L’agent termine correctement vingt-six dossiers. Deux brouillons sont acceptables mais nécessitent une autre catégorie. Sur un cas, il appelle trois fois le CRM après un délai d’attente. Sur le dernier, il prépare une promesse de date malgré l’interdiction.
Le score global pourrait sembler encourageant. La décision reste pourtant « limiter et corriger » : la promesse interdite bloque la production, tandis que les appels répétés augmentent le coût et le risque de doublon. La correction porte sur le contrat d’action, le contrôle déterministe de la date et la politique de reprise du CRM — pas sur le style du brouillon.
Après correction, le même jeu est rejoué avec une nouvelle série réservée. L’agent passe ensuite en mode ombre : il propose sans créer de tâche, pendant que l’équipe suit son processus habituel. Ce n’est qu’après comparaison que les écritures réversibles peuvent être ouvertes à un petit groupe.
Décider : déployer, corriger, limiter ou arrêter
La recette doit se terminer par une décision datée.
| Décision | Quand la prendre | Suite |
|---|---|---|
| Déployer progressivement | la tâche, les droits, les effets, le coût et le repli satisfont les seuils | ouvrir un volume limité, surveiller puis élargir |
| Corriger | l’écart est localisable dans une donnée, un outil, une règle ou un contrôle | modifier un élément puis rejouer le même jeu |
| Limiter | l’agent aide à préparer mais l’action reste trop risquée | conserver lecture, synthèse ou brouillon avec décision humaine |
| Arrêter | la valeur n’est pas démontrée ou le contrôle coûte plus que le résultat | retirer les accès, exporter les preuves et revenir au processus de référence |
Le coût doit être calculé comme un service complet. Notre guide sur le prix d’un agent IA en entreprise additionne cadrage, intégrations, exécution, validation, reprises, supervision et sortie. Ici, la métrique opérationnelle reste le coût par résultat accepté, pas le prix unitaire d’un appel de modèle.
Une étude commandée par SAP à Oxford Economics, publiée le 22 septembre 2026, indique que seuls 3 % des 200 décideurs français interrogés se disent pleinement préparés à déployer l’IA agentique à grande échelle. Ce chiffre décrit un échantillon sponsorisé, pas toutes les entreprises françaises. Il renforce néanmoins une conclusion raisonnable : la capacité à lancer un agent progresse plus vite que la capacité à prouver son fonctionnement dans la durée.
La plus petite preuve complète tient donc dans une tâche bornée, un jeu d’essai réservé, des traces utiles, des effets vérifiables, un coût complet et une règle d’arrêt. Anakyos conçoit des logiciels métier sur mesure en reliant l’agent aux données, aux droits et aux opérations réelles. Le premier livrable peut rester plus petit qu’un déploiement : le contrat de recette, la matrice des sept preuves et une décision argumentée.
Sources principales
- Hub France IA — Livre blanc : évaluation de l’IA agentique, publié en septembre 2026 ; concepts, trajectoires, métriques, méthodes d’évaluation, observabilité et suivi en production.
- OpenAI — DevDay 2026 Recap, publié le 29 septembre 2026, jour de l’événement ; annonce des responsabilités continues, de l’utilisation d’ordinateur par les agents et de nouvelles capacités de décision.
- SAP France — Étude SAP Value of AI 2026 France menée par Oxford Economics, communiqué publié le 22 septembre 2026 ; 200 décideurs français, chiffres à lire comme une étude sponsorisée et déclarative.
- IBM — Qu’est-ce que l’évaluation des agents IA ?, consulté le 8 octobre 2026 ; résultats, trajectoires, outils, coût, latence et combinaison d’évaluations déterministes, humaines et assistées par modèle.
