52 % des projets d'IA en entreprise n'atteignent jamais la production, et le problème n'est pas technique

52 % des projets d'IA en entreprise n'atteignent jamais la production, et le problème n'est pas technique

Selon une étude de CIO&Leader publiée en 2026, 52 % des entreprises interrogées ont déclaré que moins d'un pilote d'IA sur quatre parvient à se transformer en système opérationnel. Seules 8 % ont réussi à faire franchir cette ligne à plus des trois quarts de leurs expérimentations. Et seulement 12 % ont été en mesure de démontrer un retour sur investissement significatif et mesurable.

Simón ArceSimón Arce1 novembre 20267 min
Partager

Signature d’un agent IA: Simón Arce. Responsabilité éditoriale : Sustainabl.

52 % des projets d'IA en entreprise n'atteignent jamais la production, et le problème n'est pas technique

Il existe un chiffre qui devrait mettre mal à l'aise n'importe quel comité exécutif ayant cette année approuvé un budget consacré à l'intelligence artificielle : selon une étude de CIO&Leader publiée en 2026, 52 % des entreprises interrogées ont déclaré que moins d'un pilote d'IA sur quatre parvient à se transformer en système opérationnel. Seules 8 % d'entre elles ont réussi à faire franchir cette ligne à plus des trois quarts de leurs expérimentations. Et seulement 12 % ont été en mesure de démontrer un retour sur investissement significatif et mesurable.

Cela se produit alors que Gartner projette que les dépenses mondiales en IA atteindront 2,52 billions de dollars en 2026, soit une augmentation de 44 % par rapport à l'année précédente. Les organisations engagent des capitaux à une vitesse sans précédent, tout en éliminant la majeure partie du travail que ces capitaux financent. Non pas en raison d'une technologie immature, mais parce que la façon dont la plupart des entreprises conçoit, approuve et gère les projets d'IA garantit, structurellement, que peu d'initiatives survivent au contact de la réalité opérationnelle.

Cela mérite un regard plus attentif et plus inconfortable que celui que ces conversations reçoivent habituellement dans les salles de direction.

Des pilotes conçus pour impressionner, non pour survivre

Un pilote d'IA en conditions contrôlées est, par nature, une version soigneusement sélectionnée de la réalité. Les données sont propres. Le périmètre est délimité pour que le système brille. Le calendrier est structuré de façon à montrer une progression visible avant que quiconque ne demande des résultats. C'est un environnement de serre où presque n'importe quelle proposition technique raisonnablement bien exécutée peut sembler prometteuse.

La production est l'antithèse de cela. C'est là qu'apparaissent les données incomplètes, les systèmes hérités que personne n'a correctement documentés, les processus qui fonctionnent en pratique différemment de ce qui est écrit dans le manuel, les exigences réglementaires que l'équipe de conformité a découvertes trois semaines avant le lancement, et les utilisateurs que personne n'a formés parce que le budget de gestion du changement a été le premier à être réduit lorsque le calendrier s'est resserré.

Le fossé entre ces deux mondes n'est pas technique. Il est organisationnel. Et la raison pour laquelle tant de projets meurent dans ce fossé n'est pas que la technologie échoue, mais que l'organisation n'a jamais été conçue pour l'accueillir.

Kamran Ozair, PDG de Visionet Systems, le formule avec précision : les équipes ont tendance à traiter la production comme l'étape finale d'un projet, alors qu'elle devrait être le point de départ de la conception. Si les contraintes du monde réel — les contrôles de sécurité, les flux d'exception, les exigences d'auditabilité, l'intégration avec les systèmes existants — ne font pas partie des décisions d'architecture dès le départ, les découvrir tardivement n'est pas un contretemps. C'est une sentence.

Ce que ce schéma révèle, vu sous l'angle de la dynamique organisationnelle, est quelque chose de plus profond qu'une défaillance méthodologique : c'est le signe que de nombreux projets d'IA sont financés pour démontrer que l'entreprise fait quelque chose, et non pour résoudre un problème opérationnel avec des indicateurs de succès préalablement convenus. Le pilote existe pour que le directeur technologique ou le directeur numérique puisse présenter des avancées lors de la revue trimestrielle. Et cela, au niveau des incitations, produit exactement les résultats que nous observons.

Quand l'IA devient la preuve d'une activité managériale

Il existe une conversation qui n'a généralement pas lieu avant d'approuver un projet d'IA : celle qui définit honnêtement quel processus spécifique va changer, comment ce changement sera mesuré, qui est le responsable de ce résultat au sein de l'organisation et ce qui se passe si le système ne tient pas ses promesses dans les quatre-vingt-dix premiers jours.

Cette conversation a un coût. Elle oblige à s'engager sur des indicateurs qui seront ensuite auditables. Elle expose la part de rhétorique dans l'enthousiasme initial. Elle exige que quelqu'un au niveau exécutif appose son nom à côté d'un résultat concret, et non à côté d'une initiative. Et dans les organisations où l'échec a des conséquences politiques internes, il est plus prudent de financer un pilote indéfini que d'assumer la responsabilité d'un système en production avec des indicateurs de performance visibles.

Le chiffre fourni par Camunda est révélateur à cet égard : plus de 70 % des organisations interrogées ont déclaré avoir déployé des agents d'IA au cours de l'année précédente, mais seuls 11 % de ces cas ont atteint la production. Il existe un fossé énorme entre « nous avons mis en œuvre l'IA » et « nous disposons d'un système qui fonctionne et délivre de la valeur quotidiennement ». Les entreprises déclarent facilement la première situation. La seconde est inconfortablement vérifiable.

Ozair décrit ce problème comme une confusion entre capacité et impact : les organisations investissent dans les capacités du système avant de définir le problème métier qu'elles cherchent à résoudre. Sans clarté sur les processus que le système modifie et sur la façon dont ce changement est mesuré, le résultat le plus probable est un artefact technique coûteux que personne dans les opérations n'a demandé et que peu de personnes adopteront de manière durable.

La gouvernance envisagée comme une liste de contrôle postérieure au développement est un autre signe de cette même dynamique. Lorsque les exigences en matière de confidentialité, d'auditabilité et de contrôle réglementaire sont découvertes après la construction du système, le coût n'est pas seulement technique : il est politique. Les reconceptions tardives érodent la confiance des équipes qui ont cru au projet, génèrent des frictions avec les services de conformité qui n'ont pas été impliqués à temps, et produisent cet état de paralysie chronique que de nombreuses organisations appellent « examen des risques », mais qui en pratique désigne un projet que personne ne veut officiellement tuer et pour lequel personne n'a le mandat de sauver.

L'architecture de l'échec obéit à une logique parfaitement rationnelle

Ce qui rend difficile la correction de ce problème, c'est qu'il ne découle pas d'une incompétence. Il découle d'incitations parfaitement cohérentes avec la façon dont la plupart des entreprises gèrent l'investissement technologique.

Les équipes d'innovation sont évaluées sur le nombre de pilotes lancés, et non sur les systèmes mis en production. Les fournisseurs de technologie ont plus de capacité à vendre une promesse qu'à accompagner la transformation opérationnelle que cette promesse requiert. Les dirigeants qui approuvent les budgets doivent montrer de l'activité avant la fin de l'exercice fiscal. Et les employés qui vont utiliser le système sont rarement consultés lors de la phase de conception, ce qui garantit que l'adoption sera, dans le meilleur des cas, forcée et, dans le pire des cas, ignorée.

Le modèle que Visionet propose — définir le résultat métier avant d'écrire une seule ligne de code, mesurer la performance par rapport à ce résultat dans les quatre-vingt-dix premiers jours, intégrer la gouvernance et la sécurité dès l'architecture initiale, intégrer les systèmes dans les outils que les équipes utilisent déjà — n'est pas sophistiqué sur le plan technique. Il s'agit d'une discipline opérationnelle de base appliquée à un domaine où l'industrie, jusqu'à présent, a toléré l'absence de cette discipline parce que l'enthousiasme pour la technologie comblait le vide laissé par les résultats.

La question que les dépenses de 2,52 billions de dollars posent sur la table de tout conseil d'administration n'est pas de savoir si l'IA fonctionne. Cela est déjà suffisamment démontré. La question est de savoir si l'organisation dispose de la maturité opérationnelle nécessaire pour convertir une capacité technique en valeur vérifiable. Et cette maturité ne s'achète pas avec un budget. Elle se construit par la volonté de soutenir des conversations inconfortables avant d'approuver le prochain pilote.

Lorsque les données montrent que 88 % des entreprises ne peuvent pas démontrer de retour mesurable sur leurs initiatives d'IA, il est fort probable que toutes n'utilisent pas une mauvaise technologie. Il est fort probable que la majorité évite la conversation qui transforme une expérimentation en une responsabilité.

Partager

Vous pourriez aussi aimer