Agents en entreprise : où s'arrêtent les projets

Les projets d’agents IA s’arrêtent massivement entre le pilote et la production, et l’obstacle n’est presque jamais technique : il tient à trois questions qui n’ont pas été posées au cadrage. C’est le constat que je tire des systèmes que j’ai vus passer, ou pas.

Un agent, au sens où l’on emploie le mot en entreprise, est un système dans lequel un modèle de langage décide lui-même de l’étape suivante et appelle des outils qui agissent sur le système d’information : lire un dossier, créer un ticket, envoyer un message, modifier un enregistrement. C’est cette capacité d’agir qui le distingue d’un assistant qui se contente de répondre.

La démonstration réussit presque toujours. Un agent qui enchaîne trois outils sur un cas préparé fonctionne, impressionne, et débloque un budget.

Le pilote fonctionne souvent, sur un périmètre restreint et sous surveillance rapprochée.

La production échoue sur trois questions : qui répond des actions, que fait le système quand il ne sait pas, et combien cela coûte réellement. Aucune n’est une question d’ingénierie.

Un agent IA qui agit engage l’organisation, et tant qu’aucun responsable métier n’a accepté de répondre de ses actions, il ne sera pas mis en production. C’est le blocage le plus fréquent et le plus légitime.

La question se pose au moment de la mise en service, jamais avant. Un responsable métier découvre que le système enverra des messages, modifiera des dossiers ou clôturera des demandes en son nom, et refuse : à juste titre, puisqu’il n’a pas participé à la définition du périmètre.

La parade est en amont : classer les actions par réversibilité, décider ce qui est automatique, ce qui est validé et ce qui n’est jamais délégué, et faire valider cette classification par celui qui en répondra. Une demi-journée d’atelier au cadrage.

Ce cadre est développé dans le périmètre avant l’autonomie, et son absence explique à elle seule une bonne part des projets arrêtés. Les actions validées supposent ensuite une supervision dimensionnée, faute de quoi la validation devient une formalité : voir la supervision humaine, la concevoir, pas la promettre.

Le comportement d’un agent en cas de doute se conçoit par des conditions d’arrêt explicites et un compte rendu structuré, qui disent quand s’arrêter et quoi transmettre à l’humain qui reprend le dossier. Un modèle plus puissant ne remplace pas cette conception.

Les conditions d’arrêt se formulent en règles vérifiables par le système, pas en consignes au modèle : une information requise absente, une contradiction entre deux sources, un droit d’accès refusé, une action irréversible à déclencher, un nombre de tentatives dépassé.

Le compte rendu, lui, contient trois éléments : ce qui a été tenté, ce qui a bloqué, et ce qui manquerait pour aboutir. Prenons un agent qui prépare des dossiers de sinistre dans une direction des assurances. S’il s’arrête en indiquant « pièce justificative absente, demande à adresser à l’assuré, dossier mis en attente », le gestionnaire reprend en une minute. S’il complète le dossier par une hypothèse plausible, l’erreur ne sera découverte que bien plus tard.

Au début, l’agent s’arrête souvent. Ces arrêts sont une information précieuse : ils cartographient les lacunes du corpus, des droits et des procédures, et chacune comblée élargit le périmètre exploitable.

Le coût d’un agent mesuré en pilote sous-estime le coût en production parce qu’un agent consomme un nombre d’appels très variable selon les cas, et que le pilote ne contient pas les cas difficiles. Sur les missions que j’ai menées, l’écart a souvent atteint un facteur trois à cinq ; c’est un constat de terrain, pas une loi générale.

La raison tient à la composition des cas. Un pilote porte sur des dossiers représentatifs, souvent choisis. La production apporte les cas difficiles, ceux qui font boucler l’agent, tenter plusieurs approches, consommer bien au-delà de la moyenne.

La parade tient en deux réglages posés dès le pilote : un plafond de dépense par exécution appliqué par le système, et une mesure au quantile élevé plutôt qu’en moyenne.

S’y ajoute une règle de conception : au-delà de trois tentatives infructueuses, l’agent s’arrête. Sans elle, les cas pathologiques n’ont aucune borne. C’est le mécanisme décrit dans le risque croît avec la durée sans contrôle. Les autres postes, souvent oubliés, figurent dans le coût réel d’un système d’IA en production.

Les agents IA qui aboutissent en production partagent trois traits : un périmètre étroit, un résultat vérifiable, et une action réversible. Ce ne sont pas les plus impressionnants.

Le périmètre étroit signifie trois ou quatre outils, pas quinze. Au-delà, le modèle choisit mal, les erreurs deviennent difficiles à diagnostiquer, et le périmètre cesse d’être compréhensible par un humain. La facilité de branchement qu’apporte un protocole comme MCP rend cette discipline plus nécessaire, pas moins.

Le résultat vérifiable signifie qu’on sait dire, à la fin, si c’est juste : par une citation, un test automatique, une comparaison avec une donnée de référence.

L’action réversible signifie qu’une erreur se rattrape sans conséquence durable : préparer un brouillon plutôt qu’envoyer, proposer un classement plutôt que l’appliquer, signaler une anomalie plutôt que la corriger.

Ces traits décrivent des systèmes modestes. Ce sont ceux qui tournent encore un an plus tard.

Un projet d’agent qui ira jusqu’en production commence par la liste des actions classées par réversibilité, validée par celui qui en répondra, et par le jeu de tests, avant toute ligne de code. Cette séquence paraît lente et elle est plus rapide.

1. Lister les actions candidates et les classer par réversibilité : automatique, validée, jamais déléguée.
2. Faire valider cette liste par le responsable métier concerné, qui accepte d’en répondre.
3. Construire le jeu de tests avant le système, en y incluant les cas difficiles et pas seulement les cas typiques ; la méthode est dans construire un jeu de tests en une journée.
4. Développer avec un plafond de dépense, une limite de tentatives et un point d’arrêt sur l’irréversible.
5. Journaliser chaque étape de l’agent, pour pouvoir expliquer un comportement après coup, comme le décrit l’observabilité des systèmes d’IA.
6. Ouvrir progressivement, en commençant par le mode proposition avant le mode action.

Elle évite le seul scénario réellement coûteux : un système terminé qui ne sera jamais mis en service. Pour un projet déjà engagé, un audit IA permet de vérifier ces six points avant la mise en production.

Les erreurs qui font échouer un projet d’agent en entreprise sont des erreurs de cadrage : démontrer sur des cas choisis, multiplier les outils, viser l’autonomie complète et découvrir trop tard qui en répond. Elles ressemblent beaucoup à celles d’un prototype classique.

• Juger sur la démonstration. Un cas préparé ne dit rien des cas difficiles ; c’est le mécanisme décrit dans l’anatomie d’un POC qui ne passe jamais.
• Donner trop d’outils. Chaque outil ajouté multiplie les chemins possibles et les erreurs de choix.
• Confondre autonomie et valeur. Un agent qui prépare et laisse un humain décider apporte souvent l’essentiel du gain, avec une fraction du risque.
• Accorder des droits trop larges. Un agent qui peut agir sur une interface ne doit pas pouvoir tout y faire ; voir piloter un écran ne vaut pas droit de tout cliquer.
• Ignorer les verrous classiques. Données, intégration, exploitation : les obstacles décrits dans sortir du prototype, les cinq verrous s’appliquent aussi aux agents.

Pour l’année prochaine, je recommande de viser des agents plus petits, dont le périmètre est validé au cadrage par celui qui en répondra, et dont le résultat se vérifie. C’est moins ambitieux et cela aboutit.

Cette orientation a un autre mérite. Un agent modeste qui tourne produit des cas d’usage pour le suivant, et la confiance nécessaire pour élargir le périmètre. Un agent ambitieux arrêté ne produit rien du tout.