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. 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. L’agent s’améliore, le jeu de test grossit, et la boucle tourne. 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.

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é.

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, 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 au feeling : il se définit par des règles explicites, testées comme le reste.

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.

L’accompagnement Agenticiel pour mettre un agent en production

Mesurer, borner, budgéter, escalader : c’est un savoir-faire qui s’acquiert en livrant, et c’est là qu’une équipe habituée à la production change la donne. Agenticiel construit des agents métier sur mesure, et la première étape n’est pas d’écrire du code : c’est de définir, avec vous, ce que « ça marche » veut dire, sur des cas réels, avant la moindre ligne.

L’évaluation n’est pas un contrôle final, c’est le point de départ. On construit le jeu de cas avec vos vraies demandes, on mesure l’agent dès le prototype, et on pose les garde-fous qui bornent le périmètre. Le résultat n’est pas une démonstration qui impressionne, c’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.

Ce travail est mené par des développeurs offshore francophones, à Madagascar. La sous-traitance de développement permet de garder la langue et le fuseau tout en maîtrisant le coût, ce qui est décisif quand on veut itérer vite sur un agent sans faire exploser le budget. Vous parlez directement à ceux qui construisent, pas à un intermédiaire.

Notre approche consiste à ne jamais confondre une réponse avec une bonne réponse : on mesure ce que l’agent fait, on borne ce qu’il ne doit pas faire, et on ne met en production que ce qu’on peut piloter avec des chiffres.