Un agent IA en production : ce qu'on mesure avant de dire « ça marche »

Il existe un écart, rarement mesuré, entre l’agent qui impressionne en démonstration et l’agent qui tient la production. La démonstration montre un cas, choisi, propre, préparé. La production, c’est le reste du temps : les cas bizarres, les données sales, les utilisateurs qui posent la question autrement. Cet écart est la raison pour laquelle tant d’agents construits avec enthousiasme finissent débranchés après quelques semaines.

Le problème n’est pas la technologie, qui progresse vite. Le problème est qu’on confond « l’agent a répondu » avec « l’agent a bien répondu ». Sans mesure, cette confusion est inévitable. On retient la réponse brillante, on oublie les dix réponses médiocres, et on se persuade que ça marche alors qu’on ne sait pas ce que ça fait vraiment.

Cet article propose une position simple : un agent n’est « en production » que lorsqu’on peut dire, chiffres à l’appui, ce qu’il réussit, ce qu’il rate, ce qu’il coûte, et où il s’arrête. Avant cela, c’est une démonstration, même si elle tourne sur un serveur.

La démo n’est pas la production

Il faut d’abord accepter une réalité dérangeante : les cas qu’on montre en démo sont les cas les plus faciles, et ce n’est pas un hasard. On choisit naturellement l’exemple qui valorise l’agent, celui sur lequel il a été réglé, celui où la réponse est propre. C’est humain, et c’est précisément pourquoi la démo ne prouve rien sur la production.

En production, l’agent rencontre ce qu’on n’avait pas anticipé. Des emails mal rédigés, des documents scannés de travers, des questions ambiguës, des demandes hors périmètre. Chacun de ces cas est une occasion d’échec silencieux, et l’échec silencieux est le pire, parce qu’il ne remonte pas. L’utilisateur reçoit une réponse fausse, plausible, et il ne le sait pas.

La seule façon de savoir ce que l’agent fait vraiment, c’est de le confronter à des cas réels et de mesurer le résultat. C’est exactement ce que font les evals, et c’est là que tout se joue.

Les evals : mesurer sur des cas réels

Les evals, c’est un ensemble de cas de test avec une réponse attendue. On fait passer l’agent sur ces cas, et on mesure son taux de réussite. Rien de plus, rien de moins. Des outils comme Promptfoo ou DeepEval automatisent ce passage et comparent les résultats d’une version à l’autre. La subtilité tient dans la façon de constituer cet ensemble.

La règle d’or : les cas doivent venir des vraies demandes utilisateurs, pas de ce qu’on imagine. Un agent de support évalué sur les cinquante questions qu’on anticipe rate forcément les cinq cents qu’on n’avait pas vues. Il faut donc collecter de vrais exemples, les catégoriser, et construire l’évaluation sur ce matériau. C’est un travail fastidieux, peu gratifiant, et c’est pourtant lui qui fait la différence entre un agent qu’on croit fiable et un agent qui l’est.

Ensuite, il faut accepter que l’évaluation évolue. Chaque nouvel échec en production devient un cas d’évaluation : Langfuse et LangSmith permettent d’ajouter une trace réelle à un jeu de test en quelques clics. L’agent s’améliore, le jeu de test grossit, et la boucle tourne. Pour choisir l’outillage qui fait tourner cette boucle, notre comparatif des outils d’évaluation d’agents fait le tri. Un agent qui n’a pas ce cycle se dégrade doucement, parce que le monde change autour de lui et que rien ne le lui dit.

Le taux d’hallucination, par catégorie

Une moyenne cache le pire. Un agent qui répond bien 95 % du temps mais invente 5 % du temps sur des faits critiques est dangereux, même si 95 % paraît excellent. Tout dépend de ce sur quoi portent les 5 %.

Il faut donc mesurer les hallucinations non pas globalement, mais par catégorie. Inventer une date de livraison, un prix, une information médicale ou juridique n’a pas le même poids qu’une maladresse de formulation. Sur les sujets sensibles, la tolérance doit être zéro. Sur le reste, on peut accepter un taux et le surveiller. Pour un agent qui répond à partir de vos documents (RAG), Ragas mesure la fidélité de la réponse aux sources récupérées, ce qui donne un premier indicateur d’hallucination par catégorie.

Cette granularité change la conception de l’agent. Plutôt que de chercher à éliminer toute hallucination, ce qui est illusoire, on borne le périmètre : l’agent a le droit de répondre sur ce qu’il maîtrise, et il doit s’abstenir, voire basculer vers un humain, sur ce qu’il ne maîtrise pas. La frontière est explicite, et c’est elle qui rend le taux d’hallucination acceptable.

Le coût par tâche

Un agent peut être excellent et coûter trois euros par requête, ce qui le rend inutilisable à l’échelle. Le coût par tâche se mesure dès le prototype, pas après. Choix du modèle, longueur des prompts, nombre d’appels successifs, volume de contexte : tout cela se budgète, et les mauvaises surprises viennent toujours de là où on n’a pas regardé. Comparer sur vos evals un grand modèle (GPT, Claude Sonnet) et un modèle plus léger (Claude Haiku, Mistral Small) montre souvent que la version économique suffit pour une partie des tâches.

Le coût a aussi une composante invisible : la maintenance. Un agent, ça se supervise, ça se corrige, ça s’améliore. Ce temps humain est un coût récurrent qu’on oublie systématiquement dans les calculs, et qui peut dépasser le coût des appels au modèle. Un agent qui n’est pas pensé pour être maintenu coûte plus cher en supervision qu’il ne rapporte en automatisation.

La bonne pratique est de fixer un budget par tâche dès le départ, de le suivre en continu grâce à une observabilité dédiée aux LLM, et de traiter tout dépassement comme un signal d’alerte. Un agent dont le coût dérive est un agent qui n’est plus rentable, même s’il répond bien.

Le garde-fou humain

Un agent en production doit savoir s’arrêter. Quand la confiance est faible, quand la requête est sensible, quand il dépasse son périmètre, il bascule vers un humain. Ce seuil ne se décide pas à l’intuition : il se définit par des règles explicites, testées comme le reste, au même titre que les evals et la CI/CD qui composent notre méthode de mise en production.

Le garde-fou humain n’est pas un aveu de faiblesse, c’est une condition de confiance. Un agent qui escalade proprement les cas qu’il ne maîtrise pas inspire plus de confiance qu’un agent qui répond à tout, y compris à ce qu’il ne sait pas. C’est aussi ce qui protège l’entreprise des erreurs coûteuses : la décision sensible reste là où elle doit rester.

Concrètement, cela suppose de définir, pour chaque tâche, les critères d’escalade : niveau de confiance trop bas, sujet exclu du périmètre, donnée manquante ou incohérente. L’agent applique ces critères automatiquement, et l’humain ne voit que ce qui mérite son attention. C’est le partage des rôles qui rend l’automatisation durable.

La checklist avant de dire « ça marche »

Avant d’ouvrir un agent à de vrais utilisateurs, vous devriez pouvoir répondre par un chiffre ou une règle à cinq questions : sur combien de cas réels l’agent a-t-il été évalué, et avec quel taux de réussite ? Quel est son taux d’hallucination sur les catégories sensibles ? Combien coûte une tâche réussie ? Dans quels cas bascule-t-il vers un humain ? Comment un nouvel échec en production devient-il un cas de test ? Une réponse floue à l’une d’elles signale une démonstration, pas encore un produit.

Quand on construit un agent IA, on commence par là : définir avec vous ce que « ça marche » veut dire sur vos vraies demandes, avant d’écrire la moindre ligne, puis mesurer dès le prototype. Le résultat est un agent dont on peut dire précisément ce qu’il réussit, ce qu’il rate et ce qu’il coûte.