Évaluer un agent IA en production : comment savoir s'il marche vraiment (et qu'il ne régresse pas)

TL;DR

• La plupart des PME jugent leur agent IA au feeling, sur trois exemples qui passent en démo. C'est une des causes des pilotes qui n'aboutissent jamais : on ne sait pas dire si l'agent marche, donc on ne sait pas l'améliorer ni le défendre en interne.
• Les classements publics de modèles ne disent rien de votre cas. Même sur une tâche propre et calibrée, les meilleurs modèles inventent encore quelques pour cent du temps. Sur vos données métier en désordre, c'est davantage.
• L'évaluation tient en trois questions : est-ce que ça marche assez ? est-ce que ça régresse quand je change quelque chose ? est-ce que c'est rentable ? Pour y répondre, un jeu de quarante à soixante cas réels et cinq métriques suffisent.
• Pas besoin d'une plateforme sophistiquée au jour un. Un tableur, un script qui rejoue le jeu, et la discipline de ne jamais déployer une régression valent mieux que n'importe quel outil acheté trop tôt.

Posez la question à un dirigeant de PME qui vient de déployer un agent IA : comment savez-vous qu'il marche ? La réponse la plus fréquente, c'est un silence gêné, puis quelque chose comme « eh bien, on l'a testé, ça avait l'air bien ». Testé sur quoi ? Sur les trois ou quatre exemples qu'on a tapés pendant la démo, ceux qui tombaient juste. C'est rarement plus que ça.

Ce n'est pas de la négligence, c'est un angle mort. On sait évaluer un commercial sur son chiffre, un développeur sur ses livraisons, un comptable sur ses clôtures. Mais un agent IA qui répond en langage naturel, qui prend des décisions floues, qui se trompe une fois sur vingt sans prévenir, on ne sait pas par quel bout le mesurer. Alors on le juge à l'impression. Et l'impression est le pire des instruments, parce qu'elle est dominée par les derniers exemples vus, pas par la réalité statistique de ce que l'agent produit toute la journée.

Le coût de cet angle mort est documenté. Le rapport du MIT publié en juillet 2025 (le GenAI Divide, porté par le programme Project NANDA, appuyé sur cinquante-deux entretiens de dirigeants, cent cinquante-trois répondants à une enquête et l'analyse de trois cents déploiements publics) trouve que quatre-vingt-quinze pour cent des pilotes d'IA générative n'ont produit aucun impact mesurable sur le compte de résultat. Le mot important dans cette phrase, c'est mesurable. Beaucoup de ces pilotes faisaient peut-être quelque chose d'utile. Personne ne pouvait le prouver, donc personne ne pouvait défendre le budget, donc le projet est mort. On ne pilote pas ce qu'on ne mesure pas, et un agent qu'on ne sait pas mesurer finit presque toujours par être abandonné.

Cet article décrit la méthode qu'on installe chez nos clients pour sortir de l'impression et passer aux chiffres. Elle est volontairement légère. Évaluer un agent de PME n'est pas un projet de recherche, c'est une feuille de calcul et une habitude.

Pourquoi les classements de modèles ne vous disent rien d'utile

Quand on commence à s'intéresser à la fiabilité des modèles, on tombe vite sur les classements publics. C'est intéressant pour se faire une idée générale, et franchement utile pour présélectionner. Mais ça répond à une question qui n'est pas la vôtre.

Prenons un exemple concret. Le classement d'hallucination de Vectara mesure, sur un jeu fixe d'environ cent trente articles de presse (longueur médiane autour de deux cent dix-sept mots), à quelle fréquence chaque modèle invente une information absente du texte qu'on lui demande de résumer. En 2025, les meilleurs modèles sur cette tâche (GPT-5, Gemini 2.5 Pro) tournent autour de un à deux pour cent d'hallucination, tandis que d'autres modèles très capables (Claude 4, Grok 4) sont plutôt autour de quatre à cinq pour cent.

Regardez bien ce que ça dit, et surtout ce que ça ne dit pas. La tâche est idéale : un texte propre, court, fourni, avec une consigne simple (résume sans inventer). C'est le terrain le plus favorable qu'on puisse imaginer pour un modèle. Et même là, le meilleur d'entre eux invente encore une fois sur cinquante ou sur cent. Sur vos données à vous, qui ne ressemblent pas à des articles de presse bien rédigés (un fil d'emails contradictoires, une fiche produit mal remplie, un ticket client écrit à la va-vite), le taux réel sera plus élevé, parfois beaucoup plus.

Le piège, c'est de regarder un classement, de voir « un pour cent d'hallucination » et d'en conclure que votre agent sera fiable à quatre-vingt-dix-neuf pour cent. Ce chiffre a été mesuré sur une autre tâche, avec d'autres données, selon une autre définition de l'erreur. Il ne se transfère pas. Un modèle peut dominer un classement de résumé et se planter à qualifier vos leads, simplement parce que votre définition d'un bon lead ne fait partie d'aucun benchmark public. Le classement présélectionne un modèle. Il ne décide rien sur votre agent. Cette décision, vous ne pouvez la prendre qu'en mesurant votre agent sur votre travail.

Les trois questions auxquelles une évaluation répond

Avant de parler de méthode, il faut être clair sur ce qu'on cherche. Une évaluation utile répond à trois questions, et trois seulement. Tout le reste est du raffinement.

La première : est-ce que ça marche assez bien pour être mis en production ? C'est la question de seuil. Un agent qui qualifie correctement quatre-vingt-douze pour cent des leads est-il suffisant, ou faut-il attendre quatre-vingt-seize ? La réponse dépend du coût d'une erreur dans votre contexte, pas d'un idéal abstrait. Sans chiffre de départ, vous ne pouvez même pas avoir cette conversation.

La deuxième, et c'est la plus négligée : est-ce que ça régresse quand je change quelque chose ? Vous allez modifier le prompt pour corriger un cas qui clochait. Vous allez passer à une nouvelle version du modèle parce que l'éditeur a déprécié l'ancienne. Vous allez ajouter un outil. Chacun de ces changements peut améliorer trois cas et en casser cinq autres que vous ne regardiez plus. Sans jeu de test rejouable, vous ne le verrez pas avant que le client s'en plaigne. C'est le scénario le plus fréquent et le plus douloureux : l'agent qui marchait il y a deux mois et dont plus personne ne sait pourquoi il s'est dégradé.

La troisième : est-ce que c'est rentable ? Un agent qui marche techniquement mais qui coûte plus cher que le temps humain qu'il économise n'a pas de raison d'exister. Cette question relie l'évaluation au coût réel d'exploitation, que nous détaillons dans notre article sur le coût d'un agent IA en production. La performance sans le coût ne veut rien dire, et le coût sans la performance non plus.

Retenez ce cadrage, parce qu'il discipline tout le reste. Vous ne construisez pas une évaluation pour avoir un joli tableau de bord. Vous la construisez pour répondre à ces trois questions, et chaque métrique que vous ajoutez doit servir l'une d'elles.

Construire un jeu de test maison (la pièce maîtresse)

Le cœur de tout ce dispositif, c'est un jeu de cas de test. On l'appelle parfois jeu étalon, ou jeu de référence. C'est une liste de situations réelles, chacune avec son entrée (ce que l'agent reçoit) et sa réponse attendue (ce qu'on considère comme une bonne réponse). C'est l'instrument de mesure. Sans lui, tout le reste est de l'impression habillée.

La bonne nouvelle, c'est qu'il est beaucoup plus petit qu'on ne croit. Pour un agent de PME au périmètre serré, quarante à soixante cas suffisent pour démarrer. Ce qui compte n'est pas le volume, c'est la couverture. Un bon jeu contient quatre familles de cas. Des cas faciles, ceux que l'agent doit réussir les yeux fermés, pour détecter les régressions grossières. Des cas limites, à la frontière de ce qu'il doit savoir faire. Des pièges connus, les situations ambiguës qui tendent un croc-en-jambe au modèle. Et surtout, les cas où votre agent s'est déjà trompé en vrai, transformés en cas de test pour garantir qu'il ne refera pas la même erreur.

Cette dernière famille est la plus précieuse, et c'est elle qui fait grossir le jeu de manière saine. La règle qu'on installe chez nos clients est simple : chaque fois qu'un incident révèle un angle mort en production, ce cas entre dans le jeu de test. Le jeu n'est jamais figé. Il est la mémoire des erreurs de l'agent, et il grandit avec sa maturité. Un agent qui tourne depuis six mois a un jeu de test qui raconte son histoire, cas après cas.

Définir la réponse attendue demande un peu de soin, et c'est là que se cache le vrai travail métier. Pour une tâche de classement (ce ticket va au support technique ou à la facturation ?), c'est simple : la bonne catégorie. Pour une tâche de génération (rédige une réponse à ce client), c'est plus subtil, parce qu'il n'y a pas une seule bonne réponse. On ne note alors pas la réponse mot à mot, on note des critères : est-elle factuellement correcte, répond-elle à la question posée, respecte-t-elle le ton, ne promet-elle rien d'interdit. Écrire ces critères noir sur blanc oblige à dire ce qu'on attend vraiment de l'agent, et cet exercice à lui seul fait souvent émerger des désaccords internes qu'il vaut mieux trancher avant de déployer qu'après.

Un détail qui compte : ne laissez pas l'agent fabriquer son propre jeu de test. Les cas doivent venir de vos données réelles et du jugement de la personne qui connaît le métier. Un jeu généré par le modèle teste surtout la capacité du modèle à se donner raison.

Les cinq métriques qui comptent pour une PME

Une fois le jeu de test en place, il faut décider quoi mesurer. La tentation est d'empiler les indicateurs. Résistez. Pour une PME, cinq métriques couvrent l'essentiel, et chacune éclaire une décision concrète.

Le taux de réussite de la tâche, d'abord. Sur votre jeu de test, quelle proportion de cas l'agent traite correctement selon vos critères ? C'est la métrique reine, celle qui répond à la première question (est-ce assez bon ?). Suivez-la version après version. C'est elle qui vous dit si vous progressez ou si vous tournez en rond.

Le taux d'erreur grave, ensuite, et il faut le distinguer du précédent. Toutes les erreurs ne se valent pas. Un agent support qui formule une réponse correcte mais un peu sèche, ce n'est pas grave. Un agent qui affirme avec assurance une information fausse à un client, c'est une erreur grave, le genre qui détruit la confiance et qui peut coûter cher. Comptez ces deux choses séparément. Un agent peut avoir un bon taux de réussite global et un taux d'erreur grave inacceptable, et c'est ce second chiffre qui décide s'il peut toucher un client sans validation humaine. C'est aussi le lien direct avec la sécurité : un agent dont on ne mesure pas le taux d'erreur grave est un agent dont on ne maîtrise pas le risque, sujet que nous traitons dans notre article sur la sécurité d'un agent IA en production.

Le taux d'escalade, troisième métrique, est souvent mal compris. Un agent bien conçu sait dire « je ne sais pas, je passe la main à un humain ». Ce n'est pas un échec, c'est une qualité. Le taux d'escalade mesure à quelle fréquence il le fait. Trop bas, l'agent est probablement trop sûr de lui et se trompe au lieu de passer la main. Trop haut, il n'automatise plus rien et vous payez un modèle pour transférer du travail. Le bon niveau dépend de votre tolérance au risque, et le suivre dans le temps révèle des dérives intéressantes.

Le coût par tâche, quatrième, relie l'évaluation à l'économie. Combien coûte en moyenne un passage de l'agent, en appels au modèle ? Ce chiffre, multiplié par votre volume, vous donne le coût mensuel réel, à confronter au temps humain économisé. Un agent qui s'améliore en qualité mais double son coût par tâche n'est pas forcément un progrès.

La latence, enfin. Combien de temps l'agent met-il à répondre ? Pour un agent qui tourne en arrière-plan la nuit, on s'en moque. Pour un agent qui répond à un client en direct, trois secondes et quinze secondes, ce n'est pas le même produit. Mesurez-la si votre cas l'exige, ignorez-la sinon.

Cinq métriques, pas douze. Chacune répond à une question que vous vous poserez vraiment. Le reste, vous l'ajouterez le jour où une décision précise l'exigera, pas avant.

Le LLM juge : un accélérateur, pas un oracle

Rejouer quarante cas à la main et noter chaque réponse, c'est faisable une fois. Le faire à chaque changement de prompt, plusieurs fois par semaine, devient vite décourageant, et ce qui décourage finit par ne plus être fait. D'où l'idée d'automatiser la notation avec un modèle : on demande à un LLM de juger les réponses de l'agent selon une grille qu'on lui donne. C'est ce qu'on appelle le LLM juge.

Bien utilisé, c'est un vrai levier. Il permet de noter des centaines de réponses en quelques minutes, donc d'évaluer souvent, donc de tenir la discipline dans la durée. Pour des jugements sémantiques (cette réponse contient-elle une information inventée ? répond-elle à la question ? l'appel d'outil était-il le bon ?), un modèle fait un travail honnête à condition qu'on lui donne une grille claire.

Mais il y a une règle à ne jamais sauter, et c'est elle qui sépare l'usage sérieux du gadget. On valide le juge avant de lui faire confiance. Concrètement : vous prenez un échantillon de cas, vous les faites noter par un humain qui connaît le métier, vous les faites noter par le LLM juge, et vous comparez. La règle de l'art consiste à viser un accord de l'ordre de soixante-quinze à quatre-vingt-dix pour cent entre le juge et l'humain avant de s'appuyer dessus à l'échelle. En dessous, le juge n'est pas fiable : il est peut-être systématiquement trop indulgent (il valide des réponses que vous auriez recalées) ou trop sévère. Un juge non calibré donne une fausse assurance, ce qui est pire que pas d'évaluation du tout, parce qu'on prend des décisions sur un chiffre qui ment.

Une fois calibré, le LLM juge fait tourner votre évaluation sans effort. Mais gardez l'humain dans la boucle sur les cas à fort enjeu et sur la calibration périodique. Le juge dérive lui aussi quand vous changez de modèle ou quand vos critères évoluent. Un accélérateur, donc, pas un oracle qu'on installe et qu'on oublie.

Le piège du « ça marchait en démo »

Je veux m'arrêter sur l'échec le plus fréquent, parce qu'il est sournois et qu'il a une cause précise. Un agent impressionne en démonstration, on le déploie, et trois semaines plus tard il déçoit. Que s'est-il passé ?

La démo a été construite, consciemment ou non, autour des cas qui marchent. On montre ce qui brille. Le problème, c'est que ces quelques cas finissent par servir de jeu de test informel : on ajuste le prompt jusqu'à ce qu'ils passent tous, on se félicite, on déploie. Sauf que la réalité envoie des cas qu'on n'avait pas en tête, et l'agent calibré sur cinq exemples se comporte mal sur le sixième.

Un cas vécu en 2025. Un client voulait un agent pour trier ses demandes entrantes en trois catégories. En démo, sur la quinzaine d'exemples qu'on avait sous la main, l'agent tournait à quasiment cent pour cent. Tout le monde était content. Avant de déployer, on a quand même construit un vrai jeu de test : soixante demandes tirées au hasard dans l'historique réel, y compris les messages courts, les fautes de frappe, les demandes qui mélangeaient deux catégories. Le taux de réussite est tombé à soixante-dix-huit pour cent. Pas une catastrophe, mais très loin du « ça marche » de la démo, et surtout très loin du seuil acceptable pour ce client. On a passé deux semaines à corriger les catégories de pièges révélées par le jeu, et on a déployé à quatre-vingt-onze pour cent, avec un taux d'escalade qui captait l'essentiel du reste. Sans ce jeu de test, on aurait déployé à soixante-dix-huit pour cent en croyant être à cent, et le client aurait perdu confiance en quinze jours.

La leçon n'est pas que les démos mentent. C'est qu'une démo et une évaluation sont deux choses différentes. La démo montre le potentiel. L'évaluation mesure la réalité. Confondre les deux, c'est précisément le mécanisme par lequel un pilote prometteur rejoint la statistique des quatre-vingt-quinze pour cent.

Surveiller en continu, parce que le monde bouge

Une évaluation au moment du déploiement vous dit que l'agent marche aujourd'hui. Elle ne garantit rien sur dans trois mois, et pour une raison qui n'a rien à voir avec l'agent : la réalité change. De nouveaux types de demandes apparaissent. Le vocabulaire de vos clients évolue. Un document de référence sur lequel l'agent s'appuie devient périmé. Une nouvelle version du modèle est déployée par l'éditeur. L'agent n'a pas bougé, mais le terrain sous ses pieds, si.

La parade est légère : l'échantillonnage continu. Chaque semaine, on prélève un petit nombre d'interactions réelles (vingt à cinquante, selon le volume), on les fait noter (par un humain, par le LLM juge calibré, ou les deux), et on regarde la tendance. On ne cherche pas la perfection, on cherche la dérive. Si le taux de réussite mesuré sur ces échantillons commence à glisser semaine après semaine, c'est un signal d'alerte qui vous laisse le temps d'agir avant que ça devienne visible côté client.

Cet échantillonnage suppose une chose : que chaque interaction de l'agent soit journalisée proprement. Entrée reçue, décisions prises, outils appelés, réponse produite. Cette journalisation n'est pas une option, c'est l'infrastructure de base d'un agent qu'on prétend exploiter sérieusement. Elle sert l'évaluation, elle sert le débogage quand un cas part de travers, et elle sert l'auditabilité au sens du RGPD. Si votre agent ne journalise pas, vous ne l'évaluez pas vraiment, vous l'espérez.

Ne pas tomber dans l'excès inverse

Tout ce que je viens de décrire pourrait laisser croire qu'il faut monter une usine à gaz avant de déployer le moindre agent. C'est faux, et l'excès de rigueur tue autant de projets que l'absence de mesure. Une PME qui passerait trois mois à bâtir un harnais d'évaluation parfait avant de mettre quoi que ce soit en production n'aurait rien automatisé du tout, et aurait dépensé un budget sans retour. La sur-ingénierie de l'évaluation est une façon élégante de ne jamais livrer.

Le bon dosage est proportionné à l'enjeu. Un agent qui rédige des brouillons internes que personne ne lit sans relecture n'a pas besoin du même niveau d'évaluation qu'un agent qui répond directement à des clients ou qui déclenche des actions irréversibles. Pour le premier, un jeu de quelques cas et un coup d'œil hebdomadaire suffisent. Pour le second, le dispositif complet se justifie. C'est exactement la même logique de réversibilité et d'impact qui guide la sécurité d'un agent : on met l'effort là où une erreur coûte cher, on reste léger là où elle est sans conséquence.

Et ce dispositif se construit progressivement, pas d'un bloc. On démarre avec un jeu de quarante cas dans un tableur et un script qui les rejoue. On ajoute le LLM juge quand noter à la main devient pénible. On branche une plateforme d'observabilité quand le volume et le nombre de personnes impliquées le justifient. Chaque couche s'ajoute quand la douleur la réclame, jamais par anticipation. Une évaluation imparfaite mais réelle, tenue avec discipline, bat un système parfait qui n'existe que sur le papier.

Le plan de mise en place, en pratique

Si vous partez de zéro, voici l'ordre dans lequel on procède. Première étape, avant même de coder l'agent : écrire la définition du succès. Une phrase par tâche, qui dit ce qu'est une bonne réponse et ce qu'est une erreur grave. Si vous ne savez pas l'écrire, vous n'êtes pas prêt à déployer, et aucune évaluation ne vous sauvera.

Deuxième étape : constituer le jeu de test initial, quarante à soixante cas tirés de vos données réelles, couvrant le facile, le limite, le piège et les erreurs déjà vues. Troisième étape : un script simple qui rejoue ce jeu contre l'agent et calcule les cinq métriques. Un tableur pour stocker les résultats par version. C'est tout l'outillage nécessaire pour démarrer.

Quatrième étape : la règle d'or, celle qui fait toute la différence. Aucun changement (prompt, modèle, outil) ne part en production sans avoir rejoué le jeu de test, et aucun changement qui fait régresser le score ne part, même s'il améliore le cas qui vous avait motivé. Cette discipline, et elle seule, est ce qui sépare un agent qui se bonifie d'un agent qui dérive lentement vers l'abandon. Cinquième étape, une fois en production : l'échantillonnage hebdomadaire pour surveiller la dérive, et l'ajout systématique au jeu de test de chaque incident révélé par la réalité.

Aucune de ces étapes ne demande une compétence de data scientist. Elles demandent de la clarté sur ce qu'on attend de l'agent, et la discipline de mesurer avant de croire. C'est précisément ce qui manquait aux quatre-vingt-quinze pour cent de pilotes qui n'ont rien prouvé, et ce que partagent les cinq pour cent qui tiennent.

Ce qu'il faut retenir

Évaluer un agent IA, ce n'est pas un luxe d'ingénieur, c'est ce qui transforme un pari en système pilotable. Les classements publics présélectionnent un modèle mais ne mesurent jamais votre cas : même sur une tâche idéale, le meilleur modèle invente encore quelques pour cent du temps, et sur vos données le chiffre grimpe. La seule mesure qui prédit la production, c'est votre agent sur votre travail.

Le dispositif tient en peu de choses. Un jeu de quarante à soixante cas réels, qui grossit à chaque incident. Cinq métriques (réussite, erreur grave, escalade, coût, latence) qui répondent chacune à une décision concrète. Un LLM juge calibré contre l'humain pour évaluer souvent sans s'épuiser. Une règle d'or, ne jamais déployer une régression. Et un échantillonnage continu pour attraper la dérive que le monde vous impose. Le tout commence dans un tableur, pas dans une plateforme à plusieurs milliers d'euros.

La raison de fond pour laquelle tant de projets d'agents s'éteignent (les quatre-vingt-quinze pour cent du MIT, les quarante pour cent de projets agentiques que Gartner voit annulés d'ici fin 2027 faute de valeur démontrée) n'est presque jamais technique. C'est qu'on n'a pas su dire, chiffres à l'appui, que ça marchait et que ça rapportait. L'évaluation est l'outil qui produit ces chiffres. Si vous avez un agent en production que vous jugez à l'impression, ou un projet d'agent que vous voulez démarrer sur de bonnes bases, c'est exactement le genre de socle que nous aidons les PME à poser : mesurable dès le premier jour, défendable au comité suivant, et améliorable version après version.