Pourquoi 95 % des projets IA échouent
Une étude du MIT (2025) l'a chiffré : l'immense majorité des pilotes d'IA générative en entreprise ne produisent aucune valeur mesurable. Le problème n'est presque jamais le modèle — c'est tout ce qu'il y a autour.

Le chiffre qui dérange
En 2025, des chercheurs du MIT ont étudié des centaines de déploiements d'IA générative en entreprise. Leur constat : environ 95 % des pilotes ne produisent aucun impact mesurable sur le compte de résultat. Pas « un impact décevant » — aucun impact mesurable. Pendant ce temps, une minorité d'organisations en tire une valeur réelle et récurrente.
Ce n'est pas un problème de technologie : les mêmes modèles sont accessibles à tout le monde. La différence se joue ailleurs.
Ce que l'étude dit vraiment — et ce qu'elle ne dit pas
Avant d'en tirer des conclusions, il faut lire le chiffre correctement. L'étude du MIT mesure l'impact des pilotes officiels d'IA générative sur le compte de résultat — pas l'utilité de l'IA en général. Elle ne dit pas que l'IA ne fonctionne pas : elle dit que la façon dont les entreprises la déploient ne produit pas de valeur mesurable.
Un détail de l'étude est d'ailleurs savoureux : les chercheurs observent que les usages individuels d'outils grand public — des employés qui utilisent un chatbot de leur propre initiative — produisent souvent plus de valeur que les grands projets officiels. La « shadow AI » fonctionne mieux que les programmes à comité de pilotage. Pourquoi ? Parce que l'employé part de SA tâche réelle, itère vite, et abandonne sans cérémonie ce qui ne marche pas. C'est exactement l'état d'esprit qu'un bon projet IA doit institutionnaliser — avec la gouvernance en plus.
Autre limite à garder en tête : « pas d'impact mesurable » ne signifie pas toujours « aucun impact ». Beaucoup d'organisations ne mesurent tout simplement rien — ni avant, ni après. Leur projet est peut-être utile, peut-être pas : personne ne le sait, et c'est déjà un échec de pilotage.
Les quatre causes réelles
1. La démo n'est pas le produit
Un POC impressionne en réunion parce qu'il tourne sur des exemples choisis. En production, il rencontre vos vraies données : incomplètes, ambiguës, changeantes. Sans architecture pensée pour ça — récupération fiable, gestion des cas limites — il s'effondre.
2. Pas de mémoire, pas de contexte
L'étude du MIT pointe le « learning gap » : la plupart des outils n'apprennent rien de vos process et oublient tout d'une session à l'autre. Un assistant qui repart de zéro à chaque échange ne s'intègre jamais au travail réel.
3. Zéro gouvernance
Qui vérifie les réponses ? Où vont les données ? Que se passe-t-il quand l'IA se trompe ? Sans garde-fous, traçabilité et règles claires, les équipes — à raison — n'utilisent pas l'outil. Et un outil qu'on n'utilise pas a, par définition, un retour sur investissement nul.
4. Partir de la techno, pas du métier
« On doit faire de l'IA » est un point de départ qui mène aux 95 %. Les projets qui réussissent partent d'un point de friction métier précis et chiffrable — puis choisissent l'outil.
L'IA utile se construit — elle ne s'achète pas en kit.
Les signaux d'alerte d'un projet mal parti
On reconnaît un futur membre des 95 % bien avant la mise en production. Si vous cochez plusieurs de ces cases, il est temps de s'arrêter et de recadrer :
- Le projet s'appelle « projet IA » — et non « réduire le délai de traitement des devis ». Quand l'outil est le sujet, le métier n'y est pas.
- Personne ne sait dire ce qui sera mesuré — ni le chiffre de départ, ni la cible, ni qui regardera le tableau de bord.
- La démo tourne toujours sur les mêmes exemples — si on n'a jamais vu l'outil affronter un cas tordu, c'est qu'il ne sait pas le faire.
- Les utilisateurs finaux n'ont pas été consultés — le projet appartient à la direction ou à l'IT, pas à ceux qui devront s'en servir chaque jour.
- Aucune réponse claire sur les données — où elles vont, qui y accède, ce qui se passe en cas d'erreur de l'IA.
- Pas de chemin vers la production — le POC vit dans un environnement jouet, et personne n'a budgété l'intégration au système réel.
Aucun de ces signaux n'est fatal isolément. Leur accumulation, si — et la bonne nouvelle, c'est qu'ils se corrigent tous avant d'avoir dépensé le budget.
Et pour une PME ou une ETI, concrètement ?
L'étude du MIT porte surtout sur de grandes organisations, mais le mécanisme d'échec est identique à plus petite échelle — avec un budget d'erreur bien plus réduit. Une PME qui souscrit trois outils IA « sur étagère » sans les brancher à ses données paie trois abonnements pour un gain proche de zéro. À l'inverse, c'est souvent dans les structures de taille moyenne que le retour est le plus rapide : les process sont courts, les points de friction connus de tous, et la décision se prend vite.
Les bons premiers candidats sont presque toujours les mêmes : le traitement de documents entrants (devis, factures, dossiers), les réponses appuyées sur la documentation interne, la préparation de livrables répétitifs. Des tâches à fort volume, faible ambiguïté — exactement là où un diagnostic IA permet de chiffrer l'enjeu avant d'investir le moindre euro de développement.
Anatomie d'un projet qui réussit
À quoi ressemble, concrètement, un projet du bon côté de la statistique ? Le déroulé varie, mais la trame est étonnamment constante :
Au début : un problème concret, pas une techno. Le projet naît d'une phrase du type « on passe un temps fou à ressaisir les devis » — pas de « il nous faut un chatbot ». On chiffre le problème (volume, temps, taux d'erreur), et ce chiffre devient la référence contre laquelle tout sera mesuré.
Ensuite : un périmètre volontairement étroit. Un seul process, une seule équipe, des données dont on a vérifié l'état. La tentation de « faire profiter tout le monde » est l'ennemi numéro un : chaque extension de périmètre avant la preuve multiplie les chances d'enterrement.
Pendant : des utilisateurs dans la boucle dès la deuxième semaine. Pas une démo de fin de trimestre — des vrais cas traités chaque semaine, des retours intégrés, et le droit de dire « ça ne marche pas sur ce type de dossier ». C'est ce qui transforme la méfiance en adoption.
À la fin : une décision explicite. On compare la mesure au chiffre de départ, et on décide — généraliser, ajuster, ou arrêter. Les 5 % ne réussissent pas tous leurs pilotes : ils savent arrêter vite ce qui ne paie pas, et c'est précisément ce qui finance les suivants.
Comment rejoindre les 5 %
- Diagnostiquer avant d'investir : cartographier les cas d'usage, les prioriser par impact × faisabilité, et cadrer le premier — c'est exactement le rôle d'un diagnostic IA.
- Brancher l'IA à vos données : réponses appuyées sur vos documents (RAG), sources citées, mémoire du contexte — un socle, pas un gadget.
- Mesurer avant de déployer : un harnais d'évaluation (fidélité, coûts, latence) et des garde-fous validés avant la mise en production.
- Garder l'humain au contrôle : validation aux points clés, traçabilité de chaque action, montée en charge par étapes.
C'est moins spectaculaire qu'une démo. C'est aussi ce qui sépare un projet IA qui vit en production d'un pilote qu'on enterre à la fin du trimestre. Cette approche — partir du métier, brancher les données, mesurer — est le principe même du Cœur IA d'entreprise que nous défendons.
Questions fréquentes
Le chiffre de 95 % signifie-t-il que l'IA ne fonctionne pas en entreprise ?
Non. L'étude du MIT mesure l'échec des pilotes tels qu'ils sont menés — outils génériques plaqués sur des process sans intégration ni mesure. Les organisations qui intègrent l'IA à leurs données et à leurs flux de travail en tirent une valeur réelle et récurrente. C'est un problème de méthode, pas de technologie.
Combien de temps faut-il pour obtenir une valeur mesurable ?
Cela dépend du cas d'usage, mais l'ordre de grandeur raisonnable est de quelques semaines pour un premier périmètre cadré et mesuré — pas dix-huit mois de plateforme. La clé est de commencer petit sur un point de friction métier chiffrable, avec un critère de succès défini avant de développer.
Par quoi commencer pour éviter de rejoindre les 95 % ?
Par un diagnostic : cartographier les cas d'usage, les prioriser par impact et faisabilité, vérifier l'état des données, et cadrer un premier périmètre avec un objectif mesurable. Investir dans un outil avant d'avoir fait ce travail, c'est choisir la solution avant d'avoir posé le problème.
Plus de 25 ans d’artisanat logiciel. Ces décryptages sortent de l’atelier — celui qui conçoit nos SaaS, applications et socles IA —, pas d’un service marketing. Quand un chiffre est cité, sa source l’est aussi.
Rencontrer l’équipe