Y a-t-il une vie après le POC ?
Pourquoi la grande majorité des projets d'IA dans les PME et ETI françaises n'atteignent jamais la production
Dans les entreprises que je côtoie, j'observe depuis quelques années le même scénario se répéter. Tel un épisode de Scooby-Doo, les modalités changent, mais l'histoire est toujours la même.
Tout commence par un atelier, une démo bluffante, des promesses alléchantes, un comité conquis, et l'enthousiasme de "se lancer dans l'IA".
Puis la réalité reprend le dessus : faible adoption métier, produit qui vieillit mal, coûts de maintenance qui explosent.
Le MIT a mis un chiffre sur ce malaise : selon son étude NANDA publiée à l'été 2025, 95 % des projets d'IA générative en entreprise ne vont pas en production.
Le chiffre a été discuté, nuancé, contesté. Peu importe l'exactitude : l'ordre de grandeur, lui, est confirmé par l'expérience terrain.
L'explication qu'on donne souvent est que l'intelligence artificielle n'est pas assez mature. En réalité, c'est un bouc-émissaire : la technologie est là, et parfaitement actionnable.
C'est une question d'approche projet.
Le POC réussit presque toujours. C'est justement le problème.
Un POC, par construction, est fait pour réussir. On choisit un besoin exprimé par le métier, un périmètre flatteur, des données propres, des cas idéaux. On démontre une faisabilité théorique. Mais prouver qu'une IA peut résumer trois documents bien rangés avec des requêtes bien rédigées ne dit rien de sa scalabilité.
La première difficulté : bâtir un "MVP" utilisé et pertinent
Les difficultés vont commencer dès la première version mise dans les mains des métiers. En effet, gérer efficacement vingt ans d'archives hétérogènes et contradictoires, traiter les besoins terrain non exprimés et des cas limites que personne n'avait anticipés est beaucoup plus difficile qu'un cas théorique.
Par exemple, cette ETI, qui propose des services techniques B2B, avait bien fait les choses en amont : cartographie sérieuse de ses cas d'usage, priorisation de quelques chantiers à forte valeur. Puis le développement est confié à une ESN, qui l'intègre dans le tenant Microsoft de l'entreprise. Ici, l'ESN réinvente la roue du RAG : elle redéveloppe à la main les briques de base que des solutions éprouvées offrent déjà.
Résultat : des performances en deçà des attentes, une facturation conséquente (obligation de moyens, pas de résultats...) pour un outil dont le résultat est inférieur à celui d'une solution clé en main disponible sur étagère.
Sur ce projet, l'entreprise a estimé à 85 % le temps passé qui n'était pas spécifique à elle. Il est peu probable que la DSI ou qu'une ESN fasse mieux qu'un éditeur spécialisé sur ces couches. Il vaut mieux se focaliser sur là où la DSI apporte de la valeur : sa connaissance du métier et du fonctionnement de l'entreprise.
Si l'on réussit le MVP, arrive le coût de maintenance
L'histoire s'arrête parfois ici, et cela peut être une bonne décision.
Dans d'autres cas, la "V1", même si elle a coûté cher, rencontre ses premiers utilisateurs et s'en sort assez bien.
Généralement, c'est le cas quand le périmètre de l'outil est assez restreint et qu'il répond à un vrai point de douleur des métiers.
Arrive ensuite une nouvelle difficulté : la maintenance. Un système d'IA n'est pas un livrable qu'on installe et qu'on oublie.
C'est un organisme vivant.
Les modèles et technologies évoluent à une vitesse que l'on n'avait jamais vue auparavant, et sont parfois dépréciés quelques mois après leur sortie. De plus, les utilisateurs adoptent les nouveaux usages très vite et un produit bâti sur les technologies d'il y a un ou deux ans est vite perçu comme inefficace et sans intérêt.
J'ai ainsi vu, chez une entreprise, le coût de maintenance annuel d'un outil atteindre le double de son coût de développement initial.
On retrouve alors trois grands "failure stories" :
- le dépassement budgétaire (qui tue le ROI),
- l'abandon progressif de l'outil par ses utilisateurs,
- le départ de la personne-clé dont tout dépendait.
Le tueur silencieux : le projet qui ne tient qu'à une personne
Ce dernier cas est un grand classique : un projet qui ne repose que sur une seule personne, qui peut ensuite changer de poste, de responsabilité... ou d'entreprise.
Par exemple, j'ai rencontré une entreprise qui avait été très novatrice en développant il y a plus de 4 ans en interne deux outils maison : un traducteur spécialisé sur son métier, et un assistant généraliste (façon ChatGPT), là aussi adapté au métier. Techniquement, c'était réussi. Sauf que tout reposait sur une seule personne.
Cette personne est partie.
Depuis, l'entreprise paie des prestataires pour maintenir des outils qu'elle ne maîtrise plus. Le produit a vieilli : il n'implémente pas les mécanismes agentiques récents, il est désormais beaucoup moins performant qu'une solution clé en main à laquelle n'importe qui peut souscrire en quelques clics. Mais elle continue de payer la maintenance, car elle a déjà tant investi.
C'est le biais des coûts irrécupérables : il est difficile psychologiquement d'arrêter un projet sur lequel on a investi.
Projet d'IA en PME et ETI : comment réussir là où tant échouent ?
Que peut-on retenir de ces échecs récurrents et des quelques réussites ?
Les POC qui parviennent à franchir le cap de la production partagent plusieurs principes :
- Sous-traiter le générique, se concentrer sur le métier.
La grande majorité des briques d’un projet IA sont transverses, complexes à faire évoluer et à maintenir : il vaut mieux les confier à des spécialistes, garants de la fiabilité et de la mise à jour du socle technique. Ils doivent réserver leur énergie à ce qui fait la singularité de leur métier et de leurs cas d’usage. Le rapport NANDA du MIT va dans ce sens : les démarches fondées sur l’achat auprès d’éditeurs spécialisés et sur des partenariats réussissent dans environ 67 % des cas, bien plus souvent que les développements internes.
- Privilégier des solutions réversibles
Sous-traiter ne veut pas dire s'enchaîner : on délègue le socle technique sans pour autant remettre les clés de sa maison. Standards ouverts, portabilité des données et des configurations : il faut pouvoir changer de fournisseur sans tout reconstruire. Se retrouver enfermé chez un éditeur (vendor lock-in) transforme le moindre désaccord commercial ou technique en impasse coûteuse.
- Mettre rapidement le produit entre les mains du métier.
Il est illusoire de deviner en amont tous les besoins réels ou toutes les situations problématiques. Plutôt que de multiplier les ateliers théoriques, ils doivent donner accès à une version utilisable le plus vite possible, observer, recueillir les difficultés, et ajuster instructions et données à partir du terrain.
- Faire du métier un vrai copilote, dès le début.
Le dialogue permanent entre DSI et équipes métier reste le seul moyen d’ancrer l’IA dans la réalité de l’entreprise, d’assurer l’adoption et d’éviter les biais d’isolement.
Pas de magie, pas de secrets. Juste du pragmatisme : c’est souvent là que réside la durabilité d’un projet IA.
Alors, une vie après le POC ?
Oui. Mais à une condition : cesser de traiter l'IA comme une prouesse technique et commencer à la traiter comme ce qu'elle est : un système à exploiter dans la durée, ancré dans un métier, dont le vrai coût se compte après la démo.