Le MIT a analysé 300 déploiements d'IA générative en entreprise en 2025. Résultat : moins de 5% atteignent vraiment la production avec un impact mesurable. Ce n'est pas une intuition de consultant, c'est une mesure. Et si vous avez lancé un pilote IA ces dix-huit derniers mois, il y a de fortes chances que vous fassiez partie des 95%.
La question n'est pas de savoir si l'IA générative est prometteuse. Elle l'est. La question c'est : pourquoi autant de projets qui fonctionnent en démo finissent dans un tiroir ?
Le POC qui impressionne, et le système qui déçoit
Il existe un gouffre entre "ça marche en démo" et "ça tourne en production". Ce gouffre a un nom dans le secteur : le POC graveyard, le cimetière des preuves de concept. Et il est plein.
Le scénario est presque toujours le même. Une équipe interne, parfois aidée d'un freelance ou d'un intégrateur, construit un prototype en quelques semaines. Le résultat impressionne lors de la présentation : le modèle répond bien, l'interface est propre, le cas d'usage est réel. La direction valide. On parle de déploiement.
Puis six mois passent. Le prototype n'est toujours pas en prod. Un an plus tard, le projet est "en pause". Deux ans après, personne ne s'en souvient.
Le rapport du MIT, "The GenAI Divide", donne une lecture froide de ce phénomène à l'échelle de 300 déploiements. Ce qui est frappant, c'est que la cause principale n'est presque jamais le modèle d'IA lui-même. GPT-4, Claude, Mistral : les performances techniques sont rarement en cause. Ce qui bloque, c'est tout ce qui entoure le modèle.
Les quatre murs que personne n'anticipe
1. L'intégration au système d'information existant
Un POC tourne souvent sur des données propres, isolées, formatées pour l'occasion. La production, c'est l'inverse : des données éparpillées entre un ERP vieux de quinze ans, un CRM dont les exports sont irréguliers, des fichiers Excel partagés sur un SharePoint mal organisé, et des bases locales que seul le responsable informatique connaît vraiment.
Connecter un système d'IA générative à cette réalité prend du temps, nécessite des accès, et implique des choix d'architecture qui ne se font pas en deux sprints. C'est ici que la majorité des projets perdent plusieurs mois, souvent sans que la direction comprenne pourquoi "ça prend si longtemps alors que la démo marchait si bien".
2. La gouvernance : RGPD, EU AI Act, et traçabilité
L'IA générative en production, c'est un système qui traite des données, prend des décisions, et produit des outputs qui ont un effet réel sur le métier. Cela implique des obligations légales qui n'existaient pas pour un POC interne.
L'EU AI Act, entré en vigueur en 2024 avec des délais d'application progressifs, impose des niveaux de conformité selon les cas d'usage. Un système d'IA qui assiste des décisions RH ou qui traite des données clients sensibles ne se déploie pas sans analyse de risque, sans documentation, sans mécanismes de contrôle humain. Le RGPD s'applique toujours, et les questions de souveraineté des données (où s'exécutent les inférences ? qui a accès aux logs ?) reviennent systématiquement dès que la DSI ou le DPO entre dans la boucle.
Ce n'est pas un obstacle insurmontable, mais c'est un travail réel, qui prend du temps et qui doit être anticipé dès la conception. Un POC construit sans penser à la traçabilité est un POC qu'il faudra reconstruire avant de le mettre en production.
3. Le monitoring et la fiabilité en conditions réelles
Un modèle de langage n'est pas un algorithme déterministe. Ses outputs varient, peuvent se dégrader silencieusement quand le contexte change, quand les données d'entrée évoluent, quand le prompt sous-jacent commence à montrer ses limites sur des cas que le POC n'avait pas couverts.
En production, un système sans monitoring, c'est un système dont vous découvrez les pannes quand un utilisateur se plaint, pas avant. Pour nos projets comme Périscope, le monitoring n'est pas une couche optionnelle : c'est une condition de mise en service. Alertes, logs structurés, tableaux de bord de qualité des outputs. Sans ça, vous ne savez pas si votre système fonctionne encore correctement dans six mois.
C'est d'ailleurs l'un des points que nous développons dans notre approche de la livraison en production : l'observabilité n'est pas un luxe, c'est ce qui vous permet de maintenir le système sans refaire appel à l'équipe qui l'a construit.
4. L'adoption par les équipes
Le dernier mur est humain. Un système d'IA peut être techniquement irréprochable et ne jamais être utilisé. Parce que les équipes ne comprennent pas pourquoi il change leur workflow. Parce que personne n'a formé les utilisateurs clés. Parce que le système a été conçu sans impliquer ceux qui doivent s'en servir au quotidien.
Le rapport du MIT est explicite sur ce point : l'adoption est l'un des facteurs les plus discriminants entre les projets qui produisent un impact et ceux qui végètent. Ce n'est pas un problème de communication interne à gérer à la fin. C'est une dimension du projet à intégrer dès la conception.
Ce que le rapport dit sur le "build" interne
L'un des enseignements les plus clairs du "GenAI Divide" concerne le mode de développement. Les projets construits avec un partenaire externe spécialisé aboutissent significativement plus souvent que les développements 100% internes.
Cela ne signifie pas que les équipes internes sont incompétentes. Cela signifie que passer un POC en système de production est un métier à part entière. Ce n'est pas la même compétence que de construire la démo. L'intégration SI, la sécurité, l'observabilité, la documentation opérationnelle, le transfert de compétences : tout ça demande une expérience de cycles complets de livraison, pas juste de prototypage.
| Facteur d'échec | Fréquence selon le rapport | Détectable dès le POC |
|---|---|---|
| Intégration SI sous-estimée | Très fréquent | Souvent non |
| Gouvernance absente | Fréquent | Partiellement |
| Pas de monitoring | Fréquent | Non |
| Adoption ratée | Très fréquent | Partiellement |
| Modèle insuffisant | Rare | Oui |
Ce tableau résume bien le paradoxe : les seuls problèmes visibles en phase de POC sont les moins fréquents en production. On optimise là où il y a peu de risque, on ignore là où ça bloque vraiment.
La différence entre un POC et un système
Un POC valide une hypothèse. Il répond à la question : est-ce que l'IA peut faire ça ? La réponse est presque toujours oui. Les modèles actuels sont capables d'un nombre impressionnant de tâches.
Un système de production répond à des questions différentes : est-ce que ça tourne de manière fiable ? Est-ce que les équipes s'en servent ? Est-ce que vous savez quand ça dysfonctionne ? Est-ce que vous pouvez le faire évoluer sans repartir de zéro ?
C'est ce gap qui explique les 95%. La validation de l'hypothèse est rapide et peu coûteuse. La construction du système, elle, demande une rigueur d'ingénierie que peu d'équipes ont le temps et l'expérience d'appliquer en parallèle de leur activité principale.
Sur Universal, notre système de qualification et de lead gen automatisée, le POC initial a pris trois semaines. La mise en production réelle, avec intégration CRM, gestion des erreurs, monitoring des outputs et documentation des règles métier, a pris trois mois supplémentaires. Et c'est normal. Ce n'est pas un signe d'inefficacité, c'est le coût réel d'un système qui tient.
Pour des PME qui envisagent de lancer leur premier projet d'automatisation, comprendre ce que coûte vraiment un projet évite les mauvaises surprises en cours de route.
Pourquoi garder la main sur ce qu'on déploie
Il y a un autre angle que le rapport du MIT soulève indirectement : la question de la souveraineté sur le système livré. Beaucoup de projets pilotes sont construits sur des outils no-code ou des plateformes SaaS qui facilitent le prototypage mais verrouillent la maintenance.
Quand le prestataire disparaît ou augmente ses tarifs, quand la plateforme change ses conditions, quand vous voulez adapter le système à un nouveau cas d'usage : vous êtes dépendant. Ce n'est pas une position tenable pour un système en production.
Ce que nous livrons, c'est du code qui vous appartient, une documentation opérationnelle, des accès complets à l'infrastructure, et un transfert structuré pour que vos équipes puissent maintenir et faire évoluer le système. Ce que cela implique concrètement en termes de structure de livraison, c'est ce que nous détaillons dans notre approche du transfert de système IA : documentation, formation, et continuité réelle après la livraison.
Le bon diagnostic avant de relancer
Si vous avez un POC IA qui dort en ce moment, avant de lancer un nouveau projet ou de tenter de le ressusciter seul, posez-vous quatre questions :
- L'intégration avec vos données réelles a-t-elle été testée, ou le POC tournait-il sur des données de test propres ?
- La conformité RGPD et le niveau de risque EU AI Act ont-ils été analysés pour ce cas d'usage ?
- Avez-vous un mécanisme pour détecter les dégradations de qualité en production ?
- Les futurs utilisateurs ont-ils participé à la conception, et ont-ils été formés ?
Si la réponse est non à plus d'une de ces questions, vous avez votre diagnostic. Le problème n'est pas le modèle d'IA. Le problème c'est tout ce qui entoure le modèle, et c'est résolvable avec la bonne approche.
95% de POC sans impact, ce n'est pas une fatalité. C'est le résultat prévisible d'une approche qui confond validation d'hypothèse et mise en production. Si vous voulez sortir un projet du tiroir ou éviter d'y mettre le prochain, le point de départ c'est un diagnostic honnête de ce qui manque vraiment. On fait ça en une heure, sans engagement.