Méthode · 25 juin 2026 · 5 min
Pourquoi les projets IA échouent en entreprise
Quatre causes, toujours les mêmes, et aucune n'est technique. Ce que j'observe quand on m'appelle pour rattraper un projet qui s'est arrêté — et comment les éviter dès le départ.
Une partie de mes missions consiste à reprendre des projets qui se sont arrêtés. À chaque fois, on me présente la chose comme un problème technique. À chaque fois, elle ne l'est pas.
Quatre causes reviennent, et elles sont toutes décidées bien avant la première ligne de code.
1. Personne n'est responsable
Le projet appartient à tout le monde : un peu à la direction, un peu à l'informatique, un peu au métier. Donc à personne. Les arbitrages ne se prennent pas, les décisions attendent la prochaine réunion, et le sujet s'éteint sans que quiconque ait décidé de l'arrêter.
Un projet IA a besoin d'une personne nommée, du métier plutôt que de la technique, avec du temps réellement dégagé. Pas un parrain honorifique : quelqu'un dont c'est une part du travail.
2. On n'a rien décidé à mesurer
Sans indicateur fixé à l'avance, la question « est-ce que ça marche ? » devient une affaire de ressenti. Et le ressenti, au bout de trois mois, penche toujours du côté de l'habitude.
Un seul chiffre suffit, choisi avant de commencer et mesuré avant et après : temps par dossier, délai de réponse, nombre de traitements par semaine. Ce chiffre est ce qui vous permettra d'obtenir la suite du budget.
3. L'outil a été choisi avant le problème
C'est la cause la plus fréquente, et la plus coûteuse. Une démonstration impressionnante, une signature, et ensuite seulement la question de savoir à quoi ça va servir chez nous.
Un outil acheté sans problème identifié trouve rarement son usage après coup. On se retrouve à chercher des tâches à lui donner, ce qui est exactement l'inverse d'un projet.
4. La formation a été mise à la fin
Elle apparaît en dernière ligne du planning, et c'est donc elle qui saute quand le calendrier glisse. On livre alors un outil parfaitement fonctionnel à des gens qui ne savent pas quoi en faire, et on conclut que l'outil est mauvais.
Je place désormais la montée en compétences au début. Une équipe qui sait dialoguer avec un modèle obtient des résultats avant même que le système soit livré — et surtout, elle sait dire ce qu'elle veut vraiment.
Le point commun
Aucune de ces quatre causes n'est technique. Toutes relèvent de l'organisation, et toutes se décident au premier mois.
C'est pour ça que je passe beaucoup plus de temps à poser des questions qu'à installer des outils. L'installation est la partie facile — et c'est rarement elle qui fait échouer un projet.