Agent IA : éviter la sur-promesse et livrer ce qui tient

Entre la démonstration d’un agent IA et son comportement en production, il y a un fossé que beaucoup de projets découvrent trop tard. La démo tourne sur des exemples choisis, avec des données propres et un opérateur attentif. La production, elle, rencontre des cas que personne n’avait prévus, des entrées mal formées, des situations où l’agent doit dire non au lieu d’agir. C’est là que la promesse se mesure à sa réalité.

La cause de ce fossé n’est pas la mauvaise foi, elle est structurelle. Un agent IA est par nature non déterministe : on ne peut pas garantir qu’il réussira à tous les coups. Or la plupart des promesses commerciales sont formulées comme des garanties, des pourcentages de réussite, des gains de temps automatiques. Il suffit d’une promesse formulée au-dessus de ce que la technologie tient pour que le projet, même bien mené, finisse en déception.

Cet article explique comment éviter ce piège : définir un périmètre que l’agent peut réellement tenir, mesurer son taux de réussite sans complaisance, et construire les mécanismes de repli qui font qu’un échec ponctuel ne devient pas un échec du projet.

Définir un périmètre que l’agent peut tenir

La première source de sur-promesse est un périmètre trop large. On demande à un agent de répondre aux clients dans Zendesk, de mettre à jour HubSpot ou Salesforce, de rédiger des comptes rendus et de faire de la veille, le tout en une fois. Résultat : il fait tout à moitié, échoue sur les cas difficiles, et l’équipe passe son temps à réparer. Un agent tient ses promesses quand sa mission est étroite et claire, pas quand elle embrasse tout.

La bonne pratique consiste à découper la mission en tâches unitaires, et à n’en confier qu’une à la fois à l’agent, avec des critères d’acceptation explicites. Un agent qui classe des tickets fait cela, et rien d’autre. Un agent qui génère un premier brouillon de réponse fait cela, et rien d’autre. Chaque tâche est plus facile à évaluer, plus facile à fiabiliser, et plus facile à arrêter proprement si elle dérape.

Ce découpage a un second bénéfice : il rend la promesse réaliste par construction. On ne promet pas « un agent qui s’occupe du support », on promet « un agent qui trie les tickets entrants selon trois critères ». Cette formulation est vérifiable, et c’est ce qui permet de dire, à la fin, si la promesse a été tenue.

Mesurer un taux de réussite sans complaisance

Une promesse ne vaut que si elle se mesure. Trop de projets annoncent un agent performant sur la foi d’une démo, sans jamais mesurer ce qu’il réussit réellement en production. Une mesure rigoureuse consiste à définir ce qu’est un succès, à compter les succès et les échecs sur un volume réel, et à publier ce chiffre en interne. Un jeu d’evals rejoué avec Promptfoo ou DeepEval avant chaque modification, et des traces de production suivies dans Langfuse ou LangSmith, suffisent à produire ce chiffre sans effort manuel. C’est ce chiffre, et non l’impression de la démo, qui dit si l’agent tient. Nous détaillons quoi mesurer exactement dans Un agent IA en production : ce qu’on mesure avant de dire « ça marche ».

Cette mesure révèle presque toujours un taux inférieur à ce que la démo laissait espérer, et c’est une information précieuse, pas une mauvaise nouvelle. Elle dit où l’agent échoue, sur quels types de cas, avec quelle fréquence. C’est sur cette base que l’on améliore le prompt, les outils ou les données, et que l’on observe, itération après itération, le taux monter. Sans cette mesure, on améliore au hasard.

Il faut aussi mesurer les coûts de l’échec. Un agent qui réussit quatre-vingt-quinze fois sur cent mais dont les cinq échecs coûtent cher en correction humaine n’est pas meilleur qu’un agent qui réussit quatre-vingt-dix fois mais échoue proprement. La mesure du taux de réussite doit donc s’accompagner d’une mesure de ce que coûte chaque échec, pour juger de la performance réelle et non de la seule statistique.

Construire les garde-fous du repli

La seconde source de sur-promesse est l’absence de repli. Un agent qui échoue sans le signaler, ou pire, qui échoue en produisant une action incorrecte, transforme une erreur ponctuelle en incident durable. La fiabilité d’un agent se joue donc moins sur sa capacité à réussir que sur sa capacité à échouer proprement : détecter qu’il n’est pas sûr, et passer la main à un humain ou à une règle déterministe.

Ce repli s’appelle le human-in-the-loop, et il prend des formes concrètes. L’agent évalue sa propre confiance et, sous un seuil, s’abstient d’agir et demande une validation. Les actions irréversibles, envoi d’email, modification de données, paiement, sont systématiquement soumises à une confirmation. Les cas hors périmètre sont refusés explicitement plutôt que traités approximativement. Les frameworks d’agents le prévoient : LangGraph sait suspendre un graphe en attente d’une validation humaine, et l’OpenAI Agents SDK propose des guardrails qui bloquent une entrée ou une sortie non conforme. Ces garde-fous font partie intégrante de notre méthode, au même titre que les evals et la CI/CD.

Ces garde-fous ne dégradent pas la promesse, ils la rendent tenable. Un agent qui sait dire « je ne sais pas » et qui passe la main est plus fiable qu’un agent qui répond toujours, même faux. C’est en intégrant l’échec dans la conception, plutôt qu’en le niant, que l’on construit un agent qui tient dans la durée.

Livrer ce qui tient, et seulement cela

La conclusion pratique de tout ce qui précède tient en une phrase : on livre ce que l’agent tient réellement, pas ce qu’il tient en démo. Cela suppose de communiquer avec précision sur le périmètre, le taux de réussite mesuré et les limites connues. Cette communication n’affaiblit pas le projet, elle le crédibilise, car elle installe la confiance sur des faits plutôt que sur des promesses.

Cela suppose aussi d’accepter de commencer petit. Un agent qui réussit une tâche étroite de façon fiable vaut mieux qu’un agent qui prétend tout faire et ne tient rien. Le premier ouvre la voie à une extension progressive, tâche après tâche, chacune validée par la mesure (c’est tout l’objet de l’article pourquoi commencer petit est presque toujours la bonne idée). Le second brûle la confiance de l’équipe et des utilisateurs, et il est rare qu’un projet s’en remette.

La discipline du périmètre, de la mesure et du repli n’est pas une entrave à l’ambition, c’est la condition de sa réalisation. C’est elle qui distingue les projets d’agents qui durent de ceux qui s’épuisent après une démo brillante et une production décevante.

Reformuler la promesse avant de lancer le projet

Un test simple avant de démarrer : écrivez la promesse de votre agent en une phrase vérifiable, avec la tâche, le volume et le taux de réussite visé. « Un agent qui trie les tickets entrants en trois catégories, avec moins de 5 % de reclassements manuels » se vérifie. « Un agent qui gère le support » ne se vérifie pas. Si vous n’arrivez pas à écrire la première version, le périmètre n’est pas encore prêt.

C’est sur ce type de promesse qu’on s’engage quand on construit un agent IA : une mission découpée en tâches mesurables, un taux de réussite suivi sur des cas réels, et une validation humaine là où une erreur coûte cher. L’objectif : que votre premier agent en production ouvre la voie aux suivants.