L'an dernier, le MIT a publié un chiffre qui aurait dû écourter un millier de conseils d'administration : 95 % des pilotes d'IA générative ne produisent aucun retour mesurable. Pas « des retours décevants ». Rien. Zéro impact sur le compte de résultat.
RAND avait déjà dit quelque chose de similaire : plus de 80 % des projets d'IA échouent, environ le double du taux d'échec des projets informatiques ordinaires. Et en 2025, 42 % des entreprises ont abandonné l'essentiel de leurs initiatives IA, contre 17 % l'année précédente. La moitié des preuves de concept ne sont jamais arrivées en production.
Nous construisons des systèmes d'IA pour gagner notre vie. Vous vous attendez donc à ce qu'on vous dise que ces entreprises ont simplement choisi le mauvais prestataire.
On ne le fera pas. Le mauvais prestataire est rarement le problème. La mauvaise question, oui.
La question que personne ne pose avant de commencer
Presque tous les projets d'IA échoués que nous avons vus (et on nous appelle parfois pour l'autopsie) ont commencé pareil. Un dirigeant a vu une démo, s'est enthousiasmé, et a demandé : « Comment utiliser l'IA dans notre entreprise ? »
Cette question n'a pas de bonne réponse. C'est comme demander « comment utiliser l'électricité dans notre entreprise ? ». On n'utilise pas l'électricité. On utilise ce qu'elle alimente.
Les entreprises où l'IA fonctionne partent de l'autre bout. Elles choisissent un processus qui saigne déjà. Des appels manqués, des leads qui refroidissent dans un tableur, la cuisine qui surcommande chaque semaine. Puis elles demandent : « Que faudrait-il pour régler ça ? » Parfois la réponse implique de l'IA. Parfois c'est juste de la meilleure plomberie. Dans les deux cas, le projet a une ligne d'arrivée — et on sait quand on l'a franchie.
Les chercheurs du MIT ont trouvé le même motif côté données : les pilotes échoués avaient des métriques de succès floues, un sponsoring faible, et aucun lien avec un vrai flux de travail.
Les échecs n'étaient pas techniques. Les modèles fonctionnaient très bien. Les organisations autour, non.
— Sur l'endroit où les pilotes meurent vraiment
Pourquoi le pilote lui-même est le piège
Voici la partie qu'on a mis le plus de temps à accepter : le format pilote est souvent la raison de l'échec.
Un pilote, par conception, vit hors de vos vraies opérations. Il tourne sur des données d'exemple, est utilisé par des volontaires, et le poste de personne n'en dépend. Il produit donc une démo soignée et aucune habitude. Puis quelqu'un demande « on déploie ? » — et la réponse honnête est qu'on n'a jamais testé la seule chose qui compte : sa survie au contact de votre mardi après-midi.
Quand nous avons construit un système de prévision de la demande pour un opérateur de produits frais, il n'a pas tourné en expérience parallèle. Il est entré dans la base de données que les cuisines utilisaient déjà. La prévision s'affichait là où se prenait la décision de commande — pas dans un tableau de bord séparé que personne n'ouvre. Si elle avait été fausse, tout le monde l'aurait su avant vendredi. Cette pression est inconfortable, et c'est exactement elle qui rend un système réel.
Une base de données. Un flux de travail. Pas d'univers parallèle où vivrait l'IA.
La taxe du « on le fait nous-mêmes »
L'étude du MIT contenait un autre résultat passé trop inaperçu : les projets menés avec des partenaires externes spécialisés réussissaient environ deux fois plus souvent que les constructions internes — grosso modo 67 % contre 33 %.
Ce n'est pas que les développeurs externes soient plus intelligents. C'est qu'une équipe interne qui construit son premier système d'IA paie l'écolage sur chaque erreur : mauvaise architecture, mauvais pipeline de données, six mois sur un chatbot que personne n'a demandé. Une équipe qui en a livré vingt a déjà payé cet écolage — sur le budget de quelqu'un d'autre. De préférence pas le vôtre.
Une réserve honnête, parce qu'il en faut toujours une : un partenaire externe échoue aussi si on lui confie la version vague de la question. « Construisez-nous une stratégie IA » échoue à n'importe quel prix. « Notre accueil manque 30 % des appels après 18 h, réglez ça » réussit presque à chaque fois. Et coûte généralement moins cher que n'aurait coûté le deck de stratégie.
Ce que font vraiment les 5 %
Une fois les études de cas décapées, il reste des habitudes, pas du génie :
- Partir d'un processus qui saigne, pas d'une technologie. Le projet existe parce qu'un chiffre précis est mauvais — pas parce qu'une démo a impressionné.
- Définir « ça marche » avant d'écrire du code. En argent ou en heures gagnées, validé par les gens à qui appartient le chiffre.
- Vivre dans le vrai flux de travail dès le premier jour. Vraies données, vraie base, utilisées par des gens dont le poste dépend du résultat.
- Traiter le lancement comme un point de départ. Les systèmes qui survivent continuent d'apprendre du feedback au lieu d'être gelés en v1.
Rien de tout cela n'est glamour. Aucune keynote là-dedans. Mais 2026 est en train de devenir l'année où la conversation sur l'IA devient ennuyeuse de la meilleure façon possible — moins de « qu'est-ce qui est possible », plus de « qu'est-ce qui est rentable ».
Si vous êtes assis sur une initiative IA au point mort : ne demandez pas si la technologie est prête. Elle l'est. Demandez si quelqu'un dans la pièce peut finir cette phrase : « Ce projet réussit si le chiffre ___ passe de ___ à ___ d'ici ___. »
Si personne ne peut, vous n'avez pas un problème d'IA. Vous avez un problème de clarté — et aucun modèle, à aucun prix, ne règle ça.
Remplir cette phrase — chiffre, de, à, pour quand — est la première chose que nous faisons avec nos clients avant de choisir le moindre modèle. Apportez-nous la vôtre, vide.
