La démo a marché. L’agent répond bien, l’interface est propre, le comité de pilotage a validé. Six mois plus tard, le projet est « en pause ». Ce scénario revient dans beaucoup d’organisations qui ont lancé un POC IA ces deux dernières années : un pilote convaincant, un enthousiasme réel côté métier, puis un enlisement progressif face aux cas réels. Personne ne dit clairement que le projet est abandonné. Il glisse dans les priorités, remplacé par d’autres urgences, jusqu’à devenir un sujet qu’on évite d’évoquer en comité.
Pour des organisations déjà familières avec les projets IA, ce constat n’a rien de neuf. Ce qui l’est moins, c’est la raison réelle de ce blocage. On l’attribue souvent au modèle, à sa fiabilité, à sa capacité à généraliser. Le vrai problème se situe ailleurs, en amont du code.
Ces échecs silencieux coûtent cher, pas seulement en budget consommé. Ils entament la crédibilité de l’IA en interne. Après un ou deux POC qui finissent ainsi, le projet suivant part avec une réputation de fragilité qu’il n’a pas encore méritée.
Un agent conçu pour un POC IA fonctionne sur un périmètre défini. Les cas d’usage testés sont ceux qu’on a anticipés, ceux qui figurent dans le cahier des charges ou dans le scénario de démonstration. L’agent les traite bien, parfois très bien. Le problème apparaît au moment du passage à l’échelle.
La production, ce sont les cas imprévus. Un client qui formule sa demande autrement que prévu. Une exception métier que personne n’avait documentée parce qu’elle survient une fois par mois. Un document mal renseigné. Un enchaînement de règles que deux services appliquent différemment selon leur historique. Chacune de ces situations devient un ticket. Chaque ticket appelle un patch. Et chaque patch complexifie un peu plus un système qui, à l’origine, devait simplifier les choses.
Ce mécanisme n’a rien d’exceptionnel. Les retours d’expérience des équipes qui déploient des agents en production convergent sur ce point : l’écart entre le comportement observé en test et le comportement requis en conditions réelles se creuse à mesure que le volume de cas traités augmente. Plus l’agent touche de situations, plus il rencontre de scénarios qui n’ont jamais été formalisés nulle part, ni dans une documentation, ni dans la tête des équipes qui exécutaient la tâche avant lui.
Au bout de quelques mois, l’agent ressemble à un empilement de règles ajoutées au fil de l’eau. Chaque correctif traite le cas qui vient de se produire, sans jamais interroger pourquoi ce cas n’avait pas été anticipé. Le système grossit, sa logique devient plus difficile à suivre, et l’équipe qui le maintient passe plus de temps à colmater qu’à l’améliorer. C’est souvent à ce stade que le sponsor métier commence à douter, non pas de l’IA en général, mais de ce projet précis.
La réponse la plus commune consiste alors à muscler l’agent : plus de règles, plus de garde-fous, un prompt plus détaillé. Cela traite les symptômes, rarement la cause. Le vrai sujet reste en amont, dans la compréhension du travail que l’agent doit reproduire, avec ses détours et ses ajustements informels.
C’est là que se loge le malentendu. On pense avoir automatisé un processus métier. On a en réalité automatisé une procédure, c’est à dire une version simplifiée et documentée de ce processus. Interroger un opérateur sur sa façon de traiter un dossier fait souvent apparaître ce décalage : ce qu’il décrit en trois étapes cache une dizaine de micro-décisions prises sans y penser.
| Procédure documentée | Processus réel | |
|---|---|---|
| Ce qui est écrit | Le cas nominal, les étapes standard | Le cas nominal, plus les exceptions jamais formalisées |
| Qui le connaît | L’auteur du cahier des charges | La personne qui traite les dossiers au quotidien |
| Ce que voit le POC | Ce cas, souvent avec brio | Rarement testé avant la mise en production |
Nous voyons trop de projets agents jugés sur la qualité du modèle, alors que la variable qui
décide de leur sort se joue en amont. Un modèle bien outillé sur un processus mal compris échoue en production, quelle que soit sa version. Cette conviction ne remet pas en cause la valeur des modèles actuels, elle change simplement où porter l’effort. Le temps gagné à choisir le bon modèle ne compense jamais un processus resté mal compris.
Le problème n’est pas le modèle. Ce que nous voyons échouer, projet après projet, c’est l’automatisation d’une procédure là où il fallait cadrer un processus. Le cadrage cognitif n’est pas une étape de confort à ajouter si le temps le permet. C’est la condition pour qu’un agent survive à son premier contact avec la réalité.
Un POC IA qui reste bloqué six mois après une démo réussie n’est pas un échec technique. C’est le signal qu’une étape a été sautée, celle qui consiste à comprendre le travail réel avant de l’automatiser. Cette étape ne se rattrape pas une fois l’agent construit, elle se pense avant.
Après avoir vu pourquoi tant de POC échouent pour des raisons qui n’ont rien à voir avec la technologie, la question qui suit est celle de la méthode : comment cadrer un projet agent pour qu’il tienne au-delà de la démo.
Un POC bloqué dans un tiroir ? On peut regarder ensemble ce qui manquait au cadrage avant de le relancer.
