Un agent qui fonctionne en démo, ça se voit tout de suite. Les métiers applaudissent. Ils veulent la version qui tourne vraiment, celle qui traite les dossiers du quotidien, pas seulement les dix scénarios choisis pour la présentation.
Et c’est là que tout se grippe. La DSI arrive avec ses questions, normales, prévisibles, mais jamais posées avant : qui s’occupe des prompts quand le processus change ? Qui valide ce que l’agent décide ? Comment retrouver, six mois plus tard, la logique derrière une action précise ?
Silence côté porteur de projet. Le POC a été pensé pour convaincre un comité, pas pour survivre à un audit. Ce trou n’est pas rare. À mesure que les agents se multiplient dans les entreprises, il revient presque systématiquement, et il coûte cher à qui le découvre trop tard.
Le responsable data qui a porté le projet connaît la suite par cœur. Il a montré l’agent, les métiers ont validé, tout le monde est reparti convaincu. Puis vient la réunion avec la DSI, et la liste de questions qui n’avaient jamais été posées jusque-là.
Voici le paradoxe : un agent peut réussir presque tout ce qu’on lui montre en démo et rester inutilisable en production. , lors du passage à l’échelle de l’IA agentique. Pas parce qu’il est mauvais techniquement. Parce que le POC n’a jamais regardé du bon côté.
Un POC, par nature, prouve une capacité sur un terrain dégagé. Il suit le chemin nominal, la route bien tracée, celle où tout se passe comme prévu. Les à-côtés du métier restent hors champ : les exceptions gérées à la main, les arbitrages qu’un collaborateur tranche sans même y penser, les contrôles qui existent sans être écrits nulle part.
Personne ne les a documentés. Pourquoi l’aurait-on fait ? Ils n’ont jamais eu besoin d’exister sur le papier ; ils vivaient dans les têtes et les habitudes. Un POC construit pour une démo n’a aucune raison de s’y intéresser.
Le vrai problème arrive au moment d’industrialiser. Copier ce que fait un agent pendant une démo, c’est simple. Copier ce que fait une organisation entière, avec ses détours, ses ajustements, ses cas particuliers, l’est beaucoup moins.
Et voilà pourquoi les questions de la DSI tombent si souvent à plat : elles ne visent pas la technologie, elles visent un processus qui n’a jamais été mis en mots. Industrialiser devient alors une reprise complète du projet, une refonte que personne n’avait prévue, ni chiffrée.
Le porteur de projet se retrouve coincé. D’un côté, des métiers convaincus qui veulent aller vite. De l’autre, une DSI qui refuse, à juste titre, de mettre en production un système qu’elle ne peut ni garantir ni auditer. Ce blocage n’a rien d’administratif. Il dit simplement que le projet n’avait, jusqu’ici, jamais eu à répondre à ces questions.
Certaines organisations ont pris les devants. Avant de lancer un agent en production, elles listent noir sur blanc les questions qui, sinon, arrivent trop tard. Elles ne réinventent rien : ce sont, presque mot pour mot, les questions qu’une DSI pose spontanément dès qu’un projet frappe à la porte de la production.
Répondre à ces questions demande de sortir du chemin nominal.
Le tableau suivant résume l’écart entre ce qu’un POC couvre d’ordinaire et ce qu’exige un vrai déploiement :
Dimension | POC de démonstration | Déploiement en production |
Cas traités | Scénarios maîtrisés, chemin nominal | Ensemble des cas, y compris les exceptions |
Validation | Implicite, jugée sur le résultat final | Explicite, avec seuils et points de contrôle |
Traçabilité | Non requise | Nécessaire à l’audit et à la conformité |
Gouvernance | Absente ou informelle | Rôles et responsabilités définis |
Cartographier chaque exception une par une serait sans fin, et inutile. L’objectif est plus modeste : identifier les grandes familles d’exceptions, repérer les rôles qui interviennent aujourd’hui de façon informelle, poser les points de contrôle qui devront devenir explicites. Un dossier bloqué pour cause de données manquantes ne se traite pas comme un dossier qui déroge à une règle métier ; les deux sont des exceptions, mais elles n’engagent ni les mêmes personnes, ni les mêmes niveaux de décision.
Concrètement, cela veut dire s’asseoir avec les équipes qui font tourner le processus au quotidien. Leur demander non pas ce que dit la procédure, mais ce qu’elles font vraiment : les contournements connus, les validations à l’oral, les moments où seule l’expérience fait la différence. La question change de nature. On ne demande plus si l’agent sait faire la tâche. On demande si l’on a vraiment compris ce que fait, aujourd’hui, la personne qu’il doit assister.
Ce travail là, fait avant d’écrire le premier prompt de production, pèse plus lourd dans la réussite du projet que n’importe quel réglage du modèle.
Nous avons vu ce schéma se répéter, notamment chez un acteur industriel de l’automobile confronté à la même bascule entre POC et production. Notre conviction s’est construite là : un agent réussit en production quand le travail de fond a été fait avant la démo, pas après.
Modéliser les composantes cognitives d’un processus, ses exceptions, ses contrôles, les moments où l’humain reste nécessaire, dès le cadrage, change la nature même du projet. On ne cherche plus à prouver qu’un agent peut automatiser une tâche isolée. On construit, dès le départ, un système taillé pour encaisser la charge réelle, la variabilité du métier, les exigences de contrôle d’un environnement qui ne ressemble jamais tout à fait à la démo.
C’est ce changement de regard, du chemin nominal vers le processus entier, qui sépare un prototype qui reste un prototype d’un projet qui passe vraiment à l’échelle. Ce n’est pas un détail méthodologique réservé aux grands comptes : c’est la différence entre un agent qu’on montre et un agent qu’on utilise.
Un agent impressionnant en démo n’est pas un agent prêt pour la production, encore moins pour le passage à l’échelle de l’IA agentique. L’écart ne vient pas de la puissance du modèle, mais de ce que le projet a choisi de regarder avant de construire.
Les organisations qui franchissent ce cap traitent les exceptions, les contrôles et la gouvernance comme des choix de conception, pas comme des problèmes à régler après coup.
Chez JEMS, c’est l’approche que nous appelons l’architecture cognitive : elle structure notre accompagnement des entreprises sur leurs projets d’IA, dès le cadrage. Votre POC fonctionne et la question de l’industrialisation se pose déjà ? Parlons-en avec vos équipes, avant que la refonte ne devienne la seule option.
