La démo a été parfaite. Le modèle a lu l'e-mail, compris la demande, rédigé une réponse impeccable, et la salle a applaudi. Trois mois plus tard, ce pilote est toujours exactement ça : une démo que quelqu'un allume quand un dirigeant passe. Il n'est jamais passé en production. Ce n'est pas de la malchance ni un manque de budget pour « plus d'IA » : c'est le schéma le plus courant du secteur. La démo impressionne parce qu'elle montre la partie facile. La production, c'est tout ce que la démo a, par conception, sauté.
Pourquoi les pilotes d'IA échouent (et ce n'est presque jamais le modèle)
Les chiffres de l'an dernier sont gênants. L'enquête Voice of the Enterprise de S&P Global Market Intelligence (2025) a trouvé que 42 % des entreprises ont abandonné la plupart de leurs initiatives d'IA en 2025 — contre 17 % un an plus tôt —, mettant au rebut près de la moitié de leurs preuves de concept avant qu'elles n'atteignent la production. IDC, de son côté, a calculé que 88 % des pilotes d'IA ne franchissent pas le passage au déploiement large : seules 4 preuves de concept sur 33 sont passées en production. Ce n'est pas que le modèle n'était pas capable dans la démo. C'est que « capable dans la démo » et « en production » sont deux choses distinctes — et la seconde n'a pas été achetée.
Il faut séparer deux questions que la démo brouille exprès. La première — « le modèle peut-il faire ça ? » — reçoit presque toujours un oui. La seconde — « ton entreprise peut-elle exploiter ça tous les jours, avec tes données, tes systèmes, tes permissions et tes exceptions ? » — est celle qui décide s'il y a un projet. La démo répond à la première et cache la seconde. C'est pour ça qu'une démo brillante est un aussi mauvais signe qu'un bon : elle prouve ce qui ne rate presque jamais et se tait sur ce qui rate toujours.
Les 70 % que la démo saute
BCG le résume dans un principe qui vieillit très bien : le succès d'un projet d'IA, c'est 10 % d'algorithmes, 20 % de données et de technologie, et 70 % de personnes, de processus et de changement culturel. La démo vit entièrement dans ce premier 10 %. Le fossé entre le pilote et la production, c'est ces 70 % — plus les 20 % de plomberie de données — qu'aucun deck de vente ne montre, parce que ça ne fait pas une jolie vidéo.
Ce 70–90 % invisible, concrètement, c'est ça :
- De vraies données, pas des données de labo. La démo tourne sur trois exemples propres. La production reçoit des PDF de travers, des champs vides, des doublons et l'e-mail qui ne suit aucun modèle. Sans données fiables et accessibles, le même modèle qui brillait dans la démo se met à inventer.
- Les intégrations. Le résultat doit entrer et sortir de tes systèmes — CRM, ERP, e-mail, base de données — avec authentification, permissions et traçabilité. Ce câblage, c'est 80 % du vrai travail et 0 % de la démo.
- Cas limites et gestion des erreurs. La démo n'a pas de cas limites ; le mardi, si. Que se passe-t-il quand le modèle n'est pas sûr, quand l'API tombe, quand la donnée arrive à moitié ? Un système en production a une réponse à ça. Une démo, non.
- Observabilité et coût. En production, tu dois voir ce que fait le système, quand il se trompe et combien coûte chaque exécution à l'échelle. Un pilote sans instrumentation ne se gouverne pas : on l'éteint à la première frayeur.
- Propriété et adoption. Quelqu'un doit être propriétaire du système, le maintenir et faire que l'équipe l'utilise vraiment au lieu de revenir au bon vieux tableur. Sans propriétaire et sans adoption, même le meilleur système meurt tout seul.
Démo vs production : pas le même projet
| Dimension | Dans la démo | En production |
|---|---|---|
| Données | Trois exemples propres et choisis | Tout ce qui entre, sale et à toute heure |
| Erreurs | N'apparaissent pas | Sont la moitié du design |
| Intégration | Copier-coller le résultat | Entre et sort de tes systèmes avec permissions |
| Coût | Sans importance (une exécution) | Mesuré par exécution, à l'échelle |
| Propriétaire | Celui qui a fait la démo | Quelqu'un qui le maintient chaque jour |
| Succès | Impressionner la salle | Marcher sans que personne ne regarde |
Il y a une version de cet échec qui relève de l'exploitation — les 70 % ci-dessus — et une autre qui relève de la conception : promettre un système qui se gouverne seul et le livrer sans la personne qui le gouverne. On développe cette seconde à part dans le mythe de l'agent 100 % autonome. Et parfois la conclusion honnête, c'est que ce processus n'aurait pas dû être automatisé en entier : on traite ça dans quand NE PAS automatiser un processus avec l'IA. Ici, le focus est autre : même si le processus est un bon candidat et l'humain bien placé, le pilote meurt quand même si personne ne construit les 70 % ennuyeux.
Comment franchir le fossé
L'ordre qui marche inverse celui de la démo. La démo commence par le modèle et espère que le reste s'emboîte tout seul. Un système commence par le processus et traite le modèle comme une pièce de plus :
- Commence par le processus, pas par le modèle. Cartographie comment le travail se fait aujourd'hui — où ça coince, quelles exceptions apparaissent, qui décide quoi. C'est ce qui sépare automatiser des processus avec l'IA d'acheter un outil et prier.
- Budgète les 70 % dès le premier jour. Données, intégrations, gestion des erreurs et adoption ne sont pas une « phase deux » : c'est le projet. Si le plan ne couvre que la démo, tu sais déjà comment ça finit.
- Instrumente avant de passer à l'échelle. Mesure la justesse, le coût par exécution et ce qui est escaladé vers un humain. Un système qu'on ne peut pas mesurer est un système qu'on ne peut pas gouverner.
- Mets un propriétaire et un humain dans la boucle. Quelqu'un maintient le système, et une personne relit pile là où le jugement pèse plus que la vitesse. C'est la logique de monter des processus internes avec des agents : l'IA fait le gros du travail, l'humain décide ce qui compte.
Rien de tout ça n'apparaît dans une vidéo de quatre-vingt-dix secondes, et c'est précisément pour ça que le secteur préfère te vendre la démo. Nous, on fait l'inverse : on construit les 70 % ennuyeux, on les câble à tes systèmes, on les instrumente et on les laisse tourner un mardi ordinaire sans que personne ne regarde. Ça s'appelle automatisation des opérations, et ça se facture pour ce qui marche en production, pas pour ce qui impressionne la salle.