Votre agent IA marche 8 fois sur 10 : construire l'évaluation qui manque

---

title: "Votre agent IA marche 8 fois sur 10 : construire l'évaluation qui manque" seoTitle: "Évaluer un agent IA avant la production" description: "Un agent qui réussit 8 fois sur 10 en démo s'effondre en clientèle. Comment bâtir un jeu d'évaluation, mesurer la fiabilité réelle et fixer un seuil de mise en production." seoDescription: "Un agent qui réussit 8 fois sur 10 en démo s'effondre en clientèle : comment mesurer sa fiabilité réelle et fixer un seuil de production." date: "2026-09-09" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["évaluation agent IA", "fiabilité LLM production", "jeu d'évaluation LLM", "LLM juge", "taux de réussite agent", "garde-fous agent IA", "mise en production IA", "tests non déterministes", "hallucination en production"]

La démo s'est bien passée. L'agent a traité les quatre demandes qu'on lui a soumises devant le comité, il a rédigé des réponses correctes, il a même reformulé une question mal posée. Trois semaines plus tard, le pilote sur 500 tickets réels rend 61 % de réponses exploitables, une dizaine de réponses factuellement fausses parties chez des clients, et un service support qui refuse désormais d'ouvrir l'outil. Personne n'a menti pendant la démo : l'agent marchait vraiment « 8 fois sur 10 ». C'est la mesure qui était fausse, pas l'agent.

C'est le scénario le plus fréquent dans les reprises de projet IA qui arrivent chez nous, avant même le problème de coût. Une équipe compétente a construit quelque chose qui fonctionne, l'a jugé sur un échantillon de démonstration, et découvre en production un écart de vingt points qu'elle ne sait ni expliquer ni réduire, parce qu'il n'existe aucun instrument de mesure. Cet article décrit comment construire cet instrument : définir ce qu'on mesure, fabriquer un jeu d'évaluation à partir de vos propres données, noter sans se raconter d'histoires, et fixer un seuil de mise en production défendable. Il s'adresse à une équipe qui a déjà un agent ou une fonctionnalité LLM qui tourne, et qui n'arrive pas à la faire passer le cap du pilote.

Pourquoi « 8 fois sur 10 » n'est pas 80 %

Quatre erreurs se cumulent dans ce chiffre, et elles vont toutes dans le même sens : celui de l'optimisme.

L'échantillon est choisi par les mauvaises personnes. Les vingt à quarante requêtes de test viennent de l'équipe qui a construit l'agent. Elles sont formulées comme l'agent aime qu'on lui parle, elles portent sur les cas que les développeurs ont en tête, et celles qui échouaient de façon embarrassante ont été discrètement écartées au fil de l'itération. Les vrais utilisateurs écrivent en trois mots, mélangent deux demandes dans un message, collent un numéro de commande sans contexte.

Un cas testé une fois n'est pas mesuré. Un appel LLM n'est pas déterministe. Sur un même prompt exécuté cinq fois, il n'est pas rare d'obtenir quatre réponses correctes et une réponse qui part ailleurs. Quand on teste chaque cas une seule fois, on ne mesure pas la fiabilité, on tire à la loterie — et on garde le souvenir du meilleur tirage.

Les étapes se composent en se multipliant. Un agent, ce n'est jamais un appel. C'est comprendre l'intention, récupérer les bons documents, en extraire une information, rédiger, puis appeler un outil avec les bons paramètres. Cinq étapes à 95 % de réussite chacune donnent 0,95 puissance 5, soit 77 % de bout en bout. Et l'étape de récupération est rarement à 95 % : à 85 %, l'ensemble tombe à 69 %. Les équipes mesurent les étapes isolément, se rassurent, et ne comprennent pas le résultat global.

Personne n'a défini « ça marche ». Lors de la démo, le juge est un humain bienveillant qui lit une réponse plausible et hoche la tête. En production, la réponse doit être exacte, dans le bon format, sans information inventée, et l'action déclenchée doit être la bonne. Ce ne sont pas les mêmes critères, et le second n'a jamais été écrit.

Définir la tâche avant d'espérer la mesurer

Avant tout jeu de test, il faut deux documents courts. Ils prennent une demi-journée et déterminent tout le reste.

Le premier est la spécification de sortie. Quel format exact : texte libre, ou objet structuré avec des champs obligatoires ? Quelles informations l'agent a le droit d'affirmer, et lesquelles doivent obligatoirement provenir du contexte fourni ? Qu'est-ce qui est explicitement interdit — citer un prix, promettre un délai, mentionner un concurrent ? Une spécification de sortie qui tient sur une page transforme la moitié de votre évaluation en assertions automatiques.

Le second est la classification des échecs, et c'est celui qui manque presque toujours. Un taux de réussite global mélange des événements qui n'ont rien de comparable :

• Échec bénin : l'agent dit qu'il ne sait pas, ou produit une réponse incomplète mais honnête. Coût réel : deux minutes de reprise par un humain.
• Échec coûteux : l'agent répond avec assurance quelque chose de faux — un montant, une date de livraison, une clause de contrat. Coût réel : le temps de traiter la réclamation, plus souvent un geste commercial.
• Échec critique : l'agent agit. Il déclenche un remboursement, envoie un email au mauvais client, modifie une donnée. Coût réel : un incident.

Le même agent à « 80 % » peut avoir 18 % d'échecs bénins et 2 % d'échecs coûteux — déployable — ou 5 % de bénins, 12 % de coûteux et 3 % de critiques — indéployable. Tant que vous publiez un chiffre unique, vous ne pouvez pas prendre la décision.

Fabriquer le jeu d'évaluation

La règle principale : les cas viennent de vos logs, pas de votre imagination. Un jeu de cas inventés mesure votre capacité à imaginer des problèmes, ce qui est précisément la compétence qui vous manque.

Comptez 100 à 200 cas. En dessous de 100, l'intervalle de confiance est si large qu'une amélioration de cinq points est indistinguable du bruit. Au-delà de 200, le coût d'annotation croît plus vite que l'information gagnée, au moins pour la première version.

Échantillonnez de façon stratifiée, pas chronologiquement. Prendre les 150 dernières requêtes reproduit la saisonnalité du mois écoulé. Regroupez plutôt les requêtes réelles par intention, puis tirez dans chaque groupe proportionnellement à son volume. Visez une répartition de ce type :

• 60 % de cas nominaux, dans les proportions réelles du trafic ;
• 25 % de cas limites : messages ambigus, deux demandes dans un seul texte, information absente de la base, formulations abrégées ;
• 15 % de cas adversariaux : questions hors périmètre, tentatives d'extraction du prompt système, demandes qui poussent à inventer une donnée qui n'existe pas.

Chaque cas a besoin d'une réponse attendue, écrite par quelqu'un qui connaît le métier — pas par un développeur. Pour 150 cas, comptez deux à trois jours d'un expert métier. C'est la ligne de budget la plus rentable de tout le projet, et c'est systématiquement celle qu'on essaie de couper.

Enfin, coupez le jeu en deux : un lot de développement que vous regardez tous les jours, et un lot de garde d'une cinquantaine de cas que vous n'ouvrez qu'avant une décision de déploiement. Sans cette séparation, vous finirez par optimiser vos prompts pour vos cas de test, et l'écart avec la production réapparaîtra intact.

Noter sans se raconter d'histoires

Trois niveaux de notation, à employer dans cet ordre de préférence.

Les assertions déterministes d'abord. Elles sont gratuites, instantanées et incontestables. Le JSON est-il valide et conforme au schéma ? Le montant cité apparaît-il dans les documents fournis ? Tous les numéros de commande de la réponse existent-ils réellement dans le contexte — un test qui attrape à lui seul une bonne partie des hallucinations ? Les phrases interdites sont-elles absentes ? Bien conçues, ces assertions couvrent 50 à 70 % de ce que vous voulez vérifier.

La comparaison à une référence ensuite. Pour les tâches d'extraction ou de classification, une correspondance champ par champ suffit. C'est mesurable, stable dans le temps, et cela produit des courbes exploitables.

Le LLM juge en dernier, et seulement pour ce que les deux premiers niveaux ne savent pas faire : la fidélité au contexte, la pertinence, la qualité rédactionnelle. Avec deux précautions non négociables. D'abord, calibrez-le : notez cinquante cas à la main, comparez avec le juge, et exigez plus de 85 % d'accord. En dessous, ce n'est pas le juge qui est mauvais, c'est votre grille de notation qui est ambiguë — réécrivez-la avant de continuer. Ensuite, ne publiez jamais un chiffre issu d'un juge non calibré : il rassure sans informer, et c'est exactement le problème que vous cherchez à corriger. Notez au passage que faire juger chaque cas par un modèle a un coût en tokens qui n'est pas négligeable à l'échelle d'une exécution quotidienne, un poste à intégrer dans le raisonnement décrit dans notre article sur la maîtrise des coûts d'API LLM.

Le harnais technique

Quelques exigences rendent les mesures comparables d'une semaine à l'autre.

Figez tout ce qui peut bouger : version exacte du modèle, instantané du corpus de récupération, paramètres d'échantillonnage. Une amélioration de six points qui venait en réalité d'une mise à jour silencieuse du modèle côté fournisseur, c'est une demi-journée perdue en réunion.

Exécutez chaque cas trois à cinq fois et rapportez deux chiffres : le taux de réussite moyen, et le taux de cas réussis à tous les essais. Le second est celui que vit un utilisateur qui refait la même opération deux fois de suite, et il est souvent dix à quinze points sous le premier. C'est aussi votre indicateur d'instabilité : plus l'écart entre les deux est grand, plus votre pipeline laisse de latitude au modèle. La réponse n'est alors pas de retoucher le prompt, mais de contraindre — sortie structurée imposée, choix réduit à une liste fermée, étape découpée en deux.

Rendez chaque échec reproductible. Enregistrez le prompt complet, les documents effectivement récupérés et la sortie brute pour chaque exécution. Un échec qu'on ne sait pas rejouer n'est pas un bug, c'est une anecdote.

Côté ordre de grandeur : 150 cas exécutés trois fois font 450 appels, soit quelques minutes avec huit requêtes en parallèle et un coût de quelques euros. C'est assez léger pour tourner en intégration continue sur chaque modification de prompt, et c'est ce qui empêche la régression silencieuse — celle où un ajustement destiné à corriger un cas en casse quatre autres sans que personne ne le voie.

Ce que l'évaluation ne remplacera jamais : les garde-fous

Mesurer ne suffit pas. Un agent honnêtement mesuré à 88 % reste un agent qui échoue une fois sur huit, et l'architecture doit absorber ces échecs.

Réduisez le périmètre. Un agent qui traite trois types de demandes à 97 % crée de la valeur ; le même qui en traite douze à 70 % en détruit. Le découpage du périmètre est le levier de fiabilité le plus efficace, et le moins utilisé.

Validez la sortie par schéma, et en cas de non-conformité, redemandez ou basculez sur le chemin de secours — ne laissez jamais passer une sortie non validée en priant pour qu'elle soit correcte.

Interdisez l'action irréversible sans confirmation. Remboursement, email client, suppression, écriture en base : l'agent propose, un humain valide, au moins pendant les premiers mois. Et rendez vos appels d'outils idempotents : sans cela, une simple reprise après erreur réseau produit deux remboursements.

Traitez l'abstention comme un succès. Un agent qui répond « je ne sais pas, je transfère » dans 15 % des cas et supprime ainsi la moitié de ses erreurs coûteuses est meilleur qu'un agent qui répond toujours. Mesurez ce taux d'abstention explicitement, sinon vos optimisations le feront baisser sans que vous le remarquiez.

Soignez l'escalade. Le passage à un humain doit transmettre tout le contexte déjà collecté. Une escalade qui oblige le support à repartir de zéro est la raison numéro un pour laquelle les équipes internes finissent par contourner l'outil — un point commun avec ce qui fait échouer beaucoup de chatbots exposés aux clients.

Fixer un seuil de mise en production défendable

Le seuil ne se décide pas à l'intuition, il se calcule à partir du coût des échecs. Un exemple concret sur un volume de 3 000 demandes par mois.

À 8 % d'échecs coûteux, cela fait 240 réclamations à traiter chaque mois : personne ne signera. En ajoutant une abstention à 15 % et en resserrant le périmètre, on passe à 1,5 %, soit 45 cas par mois — un chiffre qu'on peut comparer à quelque chose.

Et c'est le second point, celui qui débloque le plus de projets : comparez à la référence humaine, pas à la perfection. Presque aucune organisation ne connaît le taux d'erreur de son support actuel. Quand on prend la peine de le mesurer sur le même jeu de cas, il se situe fréquemment entre 4 et 9 %. La conversation change alors complètement de nature : elle ne porte plus sur un agent imparfait face à un idéal imaginaire, mais sur deux dispositifs mesurés sur la même échelle.

Le déploiement lui-même se fait par paliers. Deux semaines en mode observation, où l'agent produit sa réponse, un humain répond réellement, et on compare les deux — c'est le seul dispositif qui donne un chiffre de production sans risque de production. Puis 10 % du trafic, puis 50 %. À chaque palier, tout échec réel est réinjecté dans le jeu d'évaluation : c'est ce qui empêche votre référentiel de vieillir.

Le plan de deux semaines

Pour une équipe qui part de zéro sur le sujet, avec un agent déjà écrit.

Semaine 1 — spécification de sortie et classification des échecs le premier jour ; échantillonnage stratifié de 150 cas depuis les logs le deuxième ; annotation métier les troisième et quatrième ; assertions déterministes le cinquième.

Semaine 2 — harnais d'exécution avec trois essais par cas les jours 6 et 7 ; première mesure de référence le jour 8, celle qui donne le vrai chiffre, généralement entre 55 et 70 % là où l'équipe annonçait 80 ; calibration du juge le jour 9 ; puis attaque des trois principaux modes d'échec, qui concentrent presque toujours plus de la moitié des erreurs.

L'erreur à ne pas commettre est de retoucher les prompts avant d'avoir la mesure. C'est tentant, c'est rapide, et c'est exactement ce qui fait tourner une équipe en rond pendant six semaines : sans référentiel, on ne sait pas si on progresse, on sait seulement que le dernier cas essayé passe. C'est le même mécanisme que celui décrit dans notre retour sur les erreurs qui coûtent cher en développement SaaS — on optimise ce qu'on voit, faute de mesurer ce qui compte.

Conclusion

La fiabilité d'un agent n'est pas une propriété du modèle, c'est une propriété de votre dispositif de mesure et de vos garde-fous. Les projets qui franchissent le cap de la production ne sont pas ceux qui ont choisi le meilleur modèle : ce sont ceux qui savent, chiffre en main, ce que leur système rate, à quelle fréquence, et ce que chaque catégorie d'échec coûte réellement.

La prochaine action est courte et ne demande l'autorisation de personne : sortez cent requêtes réelles de vos logs, faites-les passer trois fois dans l'agent tel qu'il est aujourd'hui, et classez les échecs en bénins, coûteux et critiques. Le chiffre que vous obtiendrez sera plus bas que celui que vous annoncez en interne. C'est le premier chiffre honnête du projet, et le seul depuis lequel on peut progresser.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.