Pourquoi 95 % des projets d'IA en entreprise ne survivent pas au pilote
Il existe une différence entre une démonstration qui éblouit dans une salle de conseil d'administration et un système qui fonctionne du lundi au vendredi sans que quelqu'un doive venir le sauver. L'industrie de l'intelligence artificielle passe depuis deux ans à construire la première avec une dextérité qu'elle n'est pas parvenue à transférer à la seconde. Et la raison ne réside pas dans les modèles, qui sont de plus en plus puissants. Elle réside dans la façon dont on a décidé de les présenter, et par extension, dans la façon dont on a décidé de les construire.
Le chiffre qui circule parmi les équipes techniques les plus honnêtes du secteur est difficile à ignorer : jusqu'à 95 % des projets d'IA générative en entreprise n'atteignent pas un retour sur investissement mesurable, selon la MIT NANDA Initiative, citée par Iris.ai. Une fourchette d'échec allant de 70 à 95 % n'est pas le signe que le marché « n'est pas encore mature ». C'est le signe que quelque chose de structurel est brisé dans la façon dont on construit ces systèmes.
Enrique Dans, dans un article publié le 10 juin 2026 dans Fast Company, indique où se trouve la fracture. Pas dans la capacité technique des modèles de langage. Pas dans la résistance des employés. Mais dans quelque chose de plus difficile à admettre pour une industrie qui vit de convaincre des investisseurs : l'IA en entreprise a été construite sur des métaphores plutôt que sur des modèles formels. Et les métaphores, aussi utiles qu'elles soient pour vendre, ne s'industrialisent pas.
Du langage poétique à l'architecture qui ne passe pas à l'échelle
L'inventaire des métaphores qui ont peuplé le discours sur l'IA au cours des deux dernières années est vaste et révélateur. Les systèmes « se souviennent », « réfléchissent », « planifient » et, dans le cas de la technique de « sommeil » que Anthropic a décrite pour ses agents, « dorment » littéralement. La documentation de l'API Assistants d'Azure OpenAI décrit des « fils de discussion » qui stockent l'historique des messages et les tronquent lorsque la fenêtre de contexte est épuisée, en présentant cela comme de la « mémoire ». L'équipe d'ingénierie d'Anthropic parle d'agents « de longue durée » qui doivent « préserver la continuité entre les sessions ».
Aucune de ces descriptions n'est techniquement incorrecte. Le problème est qu'elles sont descriptives alors qu'elles devraient être formelles. Une métaphore décrit. Un modèle formalise. Cette différence a des conséquences économiques directes.
Lorsque la « mémoire » n'est pas un modèle de données mais une analogie opérationnelle, il n'y a pas d'identité définie, pas d'état persistant, pas de relations avec des autorisations explicites, pas de contraintes que le système garantit indépendamment de qui l'utilise ou du nombre de fois qu'il est sollicité. Il n'y a pas, en termes techniques, d'invariants : les règles qu'une architecture maintient quelles que soient les conditions externes. Sans invariants, chaque implémentation est une nouvelle négociation. Chaque déploiement exige que quelqu'un traduise la réalité opérationnelle de l'entreprise dans le langage que le système peut traiter. Et cette traduction ne peut pas être déléguée à un modèle de document.
Le résultat observable est que les principaux fournisseurs d'IA de pointe, notamment OpenAI et Anthropic selon la note de Dans, envoient des ingénieurs et des équipes terrain chez leurs clients en entreprise pour cartographier les flux de travail, définir les contraintes et connecter les systèmes. Ce qui ressemble à un service premium est en réalité un signal structurel : la plateforme ne peut pas fonctionner seule. Lorsque la traduction personnalisée devient le mode de livraison dominant, le produit cesse d'être une plateforme et devient du conseil avec une interface technologique.
Le coût de ce modèle pour les acheteurs est double. Premièrement, la dépense directe en intégration sur mesure qui doit être répétée à chaque fois qu'un système, une réglementation ou un processus interne change. Deuxièmement, le coût d'opportunité de ne pas pouvoir passer à l'échelle : si chaque nouvelle application nécessite la même intervention manuelle, le retour marginal de chaque implémentation supplémentaire ne s'améliore pas avec le temps. La courbe des coûts ne descend pas. La promesse de la plateforme ne se matérialise pas.
Le schéma historique que l'industrie de l'IA n'a pas encore traversé
Dans relie le moment actuel de l'IA en entreprise à trois transitions technologiques qui ont réussi à s'industrialiser, et la comparaison est inconfortable pour quiconque préfère penser que les agents d'IA sont un phénomène sans précédent.
Edgar F. Codd a développé le modèle relationnel de données dans les années soixante-dix. Avant ce travail, les bases de données étaient des implémentations propriétaires, chacune avec son propre langage, sa propre logique de stockage et sa propre méthode d'accès. Après Codd, il y eut une abstraction formelle : relations, attributs, clés, dépendances fonctionnelles. Sur cette formalisation émergea SQL, et sur SQL naquit un marché de plusieurs milliards de dollars en logiciels, intégrations et services. Ce qui rendit ce marché possible, ce n'est pas que les bases de données devinrent plus puissantes. C'est qu'elles devinrent descriptibles avec une précision suffisante pour que deux systèmes indépendants se comprennent sans négociation préalable.
Le web suivit le même schéma. Le W3C définit des ressources identifiées par des URI, un protocole sans état formalisé dans la RFC 9110, et une grammaire partagée de méthodes HTTP, de codes de statut et de HTML. Aucune entreprise n'a inventé le navigateur puis demandé à ses clients d'engager des consultants pour interpréter ce que signifiaient ses pages. La grammaire était publique, formelle et suffisamment précise pour que n'importe quel développeur puisse construire dessus sans appeler personne.
SAP fit de même avec les processus d'entreprise. Sa domination dans l'ERP ne vint pas du fait d'avoir de meilleures interfaces que les consultants de l'époque. Elle vint d'avoir formalisé l'entreprise comme objet technique : données de référence, transactions, logique comptable, inventaire, approvisionnement, relations opérationnelles. Cette formalisation rendit les implémentations suffisamment reproductibles pour qu'il existe des modèles, des partenaires certifiés, des extensions et un marché secondaire solide. La variance entre un client et un autre se réduisit suffisamment pour que les connaissances accumulées dans une implémentation transfèrent de la valeur à la suivante.
Ce que ces trois cas ont en commun, c'est que le saut de la capacité à la plateforme ne s'est pas produit parce que la technologie s'est améliorée. Il s'est produit parce que quelqu'un a défini avec précision ce que la technologie représentait et selon quelles règles elle fonctionnait. Dans les trois cas, il y eut un moment de formalisation qui précéda le moment du passage à l'échelle.
L'IA en entreprise n'a pas encore traversé ce moment. Elle a la capacité. Il lui manque la grammaire.
Ce que McKinsey confirme et que la plupart des équipes ignorent
Les chiffres du MIT sur l'échec ne sont pas la seule preuve disponible. La recherche de McKinsey sur l'état de l'IA, référencée dans l'article de Dans, parvient à une conclusion qui devrait mettre mal à l'aise les équipes qui mesurent leur progrès en nombre de pilotes lancés : les entreprises qui tirent des bénéfices matériels de l'IA ne sont pas celles qui utilisent le plus d'IA. Ce sont celles qui ont repensé leurs flux de travail.
Cette distinction n'est pas sémantique. Utiliser l'IA sur un processus existant produit des gains marginaux dans le meilleur des cas. Repenser le processus autour d'une représentation formelle du travail produit quelque chose de différent : un système dans lequel l'intelligence artificielle n'est pas un accessoire mais une condition de fonctionnement du processus lui-même.
Michael Hammer a écrit dans la Harvard Business Review que les entreprises commettent une erreur prévisible lorsqu'elles adoptent une nouvelle technologie : elles accélèrent les processus existants au lieu de les remplacer. Dans reprend cet argument pour le moment actuel. La version contemporaine de l'erreur de Hammer consiste à prendre un flux d'approbations conçu pour des humains qui lisent des documents papier, à y ajouter un modèle de langage qui résume les documents, et à appeler cela une transformation. Le processus a la même structure causale. Il dispose simplement d'un composant plus rapide à une étape intermédiaire.
La reconception que McKinsey détecte dans les entreprises avec un retour mesurable a une caractéristique structurelle : il existe une couche qui définit ce qu'est une entité dans le métier, quels états elle peut avoir, quelles transitions sont valides, quelles autorisations sont requises pour chaque action et quelles règles ne peuvent être violées indépendamment de l'instruction que reçoit le système. Ce n'est pas un prompt élaboré. C'est ce que Dans appelle la couche formelle que l'industrie n'a pas encore construite de manière standardisée.
La différence entre avoir cette couche et ne pas l'avoir est auditable. Sans elle, le système peut donner une réponse différente à la même requête selon l'historique de la session, l'utilisateur qui pose la question ou la façon dont l'instruction précédente a été formulée. Avec elle, il y a des invariants : le contrat avec le client ne peut pas être modifié sans l'autorisation du directeur régional, indépendamment de ce que l'agent a « compris » de l'e-mail qu'il a lu. Cette garantie ne vient pas du modèle de langage. Elle vient de l'architecture qui le contient.
Pour les secteurs réglementés, cette distinction n'est pas une préférence technique. Dans les services financiers, la santé ou le secteur public, l'absence d'invariants vérifiables n'est pas une gêne opérationnelle. C'est un bloquant pour le déploiement à grande échelle, car aucune équipe juridique ne va signer la responsabilité d'un système qui ne peut pas garantir la cohérence de ses décisions.
La prochaine bataille n'est pas entre les modèles, mais entre les abstractions
L'analyse de Dans se conclut par une projection qu'il vaut la peine de prendre au sérieux comme signal stratégique : l'avantage concurrentiel dans la prochaine phase de l'IA en entreprise ne sera pas remporté par les fournisseurs disposant des modèles les plus puissants. Il sera remporté par ceux qui définiront l'abstraction formelle sur laquelle les autres construiront.
Cela ouvre une question aux conséquences concrètes sur le marché, même si la réponse n'est pas encore claire. Les candidats naturels pour définir cette abstraction sont nombreux et ont des motivations différentes. Les grands fournisseurs de cloud, Microsoft, Google et Amazon, disposent de la distribution et des relations en entreprise, mais ont également l'incitation à maintenir le modèle de conseil intensif qui génère des revenus via les services professionnels. Les laboratoires de modèles comme OpenAI et Anthropic ont la profondeur technique, mais ont construit leurs activités autour de la capacité des modèles, et non autour de la formalisation des processus qui les entourent. Les éditeurs de logiciels d'entreprise établis, SAP, Salesforce, Oracle, opèrent déjà sur des couches formelles de données et de processus, mais leur vitesse d'adaptation à de nouvelles architectures a historiquement été lente.
L'espace le plus intéressant pourrait appartenir à un type d'acteur qui n'a pas encore de nom clair sur le marché : un spécialiste en infrastructure de connaissance et de flux de travail dont la proposition de valeur n'est pas le modèle de langage mais la couche qui le rend opérable au sein d'une entreprise sans nécessiter une traduction manuelle à chaque implémentation. Quelque chose d'analogue à ce qu'a représenté le middleware dans les années quatre-vingt-dix, mais avec la capacité de raisonner sur les règles qu'il contient.
Le signal indiquant que cet acteur est en train de gagner ne sera pas une annonce de produit. Ce sera le moment où deux entreprises de secteurs différents pourront partager une implémentation sans qu'aucune des deux n'ait besoin d'appeler un consultant pour expliquer ce que signifie « approuvé » dans son organisation. Lorsque la grammaire sera suffisamment précise pour que cela se produise, la phase artisanale de l'IA en entreprise sera terminée. D'ici là, le taux d'échec de 95 % n'est pas un accident statistique. C'est le prix à payer pour construire sur des analogies plutôt que sur des définitions.
