35 milliards de dollars dépensés en IA, presque rien en retour
L'appel est arrivé un mardi soir. Une entreprise de santé de taille intermédiaire — que nous conseillions — venait de tuer son projet d'IA phare. Neuf mois de travail. Des centaines de milliers de dollars dépensés. Le CTO semblait épuisé, pas en colère. « Ça fonctionnait parfaitement en démo », m'a-t-il dit. « À tous les coups. Puis nous l'avons branché sur de vraies données patients et il s'est mis à halluciner des codes d'assurance. »
Je ne savais pas quoi dire, car j'avais entendu une variante de cette histoire une douzaine de fois rien que ce trimestre-là. Une IA qui éblouit en salle de réunion et se désintègre en production. Des pilotes qui suscitent l'enthousiasme au premier mois et des revues budgétaires au sixième. L'écart entre ce que l'IA générative promet et ce qu'elle tient réellement au sein d'une entreprise est la tension qui définit ce moment technologique.
Et nous avons désormais les chiffres pour le prouver. L'initiative NANDA du MIT a publié à la mi-2025 une étude qui a fait l'effet d'une grenade : sur les 30 à 40 milliards de dollars que les entreprises auraient déversés dans l'IA générative, environ 95 % des pilotes n'ont produit aucun impact mesurable sur le compte de résultat. La propre enquête 2025 de McKinsey va dans le même sens : 88 % des organisations déclarent utiliser l'IA quelque part, mais seules 39 % peuvent citer le moindre impact sur l'EBIT.
Je dirige Veriprajna, où nous construisons des systèmes d'IA profonde pour les entreprises. Je ne suis pas un observateur neutre. Mais j'ai été suffisamment proche des naufrages — et des rares réussites — pour avoir une vision claire de ce qui cloche vraiment. Et ce n'est pas ce que la plupart des gens croient.
La démo était superbe. Puis la réalité s'est invitée.
L'expérience de ce CTO du secteur de la santé n'avait rien d'inhabituel. C'était pratiquement le résultat médian.
Les données du MIT dessinent un entonnoir brutal : 80 % des organisations explorent les outils d'IA générative. Seules 20 % vont jusqu'au pilote. Et à peine 5 % atteignent la production avec des résultats commerciaux mesurables. Les chercheurs parlent d'un « écart d'apprentissage », une façon polie de dire que la plupart des entreprises ne comprennent pas ce qu'elles ont acheté.
Je me revois dans notre bureau après avoir lu l'intégralité du rapport du MIT, en train de débattre avec mon cofondateur pour savoir si le chiffre de 95 % était trop dramatique. Il ne l'était pas. Il sous-estimait plutôt le problème, car beaucoup des 5 % de « réussites » avaient revu la définition du succès à la baisse — ils avaient mesuré des taux d'adoption ou la satisfaction des utilisateurs au lieu de l'impact réel sur le chiffre d'affaires.
Le schéma que je vois se répéter est le suivant : une équipe construit une preuve de concept avec l'un des grands LLM du marché. Il traite à merveille les dix requêtes d'exemple. La direction s'enthousiasme. Le budget est validé. Puis le système rencontre le monde réel — données sales, cas limites, entrées ambiguës, exigences réglementaires où « à peu près » signifie un procès — et il s'effondre.
L'écart entre une IA prête pour la démo et une IA prête pour la production n'est pas un écart. C'est un canyon, et la plupart des entreprises ne s'en aperçoivent qu'après avoir sauté.
60 % des utilisateurs de l'étude du MIT ont indiqué que les modèles étaient incapables d'apprendre du feedback dans la durée. 55 % ont dit consacrer un effort excessif à fournir du contexte pour absolument chaque prompt. 40 % ont dit que les modèles « cassaient » purement et simplement dès qu'ils rencontraient des entrées non standard. Ce ne sont pas des modes de défaillance exotiques. C'est un mardi ordinaire.
Pourquoi les entreprises construisent-elles sur des sables mouvants ?
La plupart des produits que le marché des entreprises qualifie aujourd'hui de « produits d'IA » sont des wrappers — de fines interfaces posées sur un appel d'API à GPT-4, Claude ou Gemini. Vous tapez quelque chose, cela part vers le modèle, le modèle répond, et le wrapper met joliment le tout en forme.
J'ai le souvenir viscéral d'une réunion de présentation où un client potentiel m'a montré son « moteur de conformité propulsé par l'IA ». J'ai demandé ce qui se passerait si le comportement du modèle sous-jacent changeait après une mise à jour du fournisseur. La salle s'est tue. Ils n'y avaient pas pensé. Leur produit tout entier était un modèle de prompt et un joli tableau de bord. L'« intelligence » qu'ils vendaient était entièrement louée.
C'est le sophisme du wrapper, et il est partout. L'approche repose généralement sur ce que le secteur appelle un « méga-prompt » — vous entassez règles, données, contexte et instructions dans une seule interaction massive en espérant que le modèle s'en sorte. J'ai traité ce problème architectural plus en profondeur dans la version interactive de nos travaux de recherche, mais en résumé, les méga-prompts créent trois problèmes fatals :
Ils sont impossibles à auditer. Il n'existe aucun moyen de vérifier que le modèle a suivi les instructions dans le bon ordre. Pour les secteurs à forte exigence de conformité, c'est rédhibitoire.
Ils sont économiquement fragiles. Les longues fenêtres de contexte et les nouvelles tentatives consomment des tokens à toute vitesse. Et voici un chiffre qui m'a choqué la première fois que je l'ai vu : l'écart entre un tokenizer efficace et un tokenizer inefficace peut représenter une variation de coût de 450 % pour une même charge de travail. Une entreprise traitant 100 000 demandes clients par jour pourrait voir ses coûts annuels bondir de 36 500 $ à plus de 164 000 $ simplement en choisissant le mauvais modèle pour un cas d'usage multilingue.
Ils sont cassants. Changez trois mots dans un prompt et vous obtenez une sortie complètement différente. Essayez donc de bâtir un SLA là-dessus.
Le piège économique est encore pire que le piège technique. Quand OpenAI ou Anthropic baisse ses tarifs d'API — et ils continueront de les baisser — les entreprises de wrappers voient leurs marges s'évaporer. Elles ne possèdent pas les données. Elles ne possèdent pas le workflow. Elles revendent l'intelligence d'un autre avec une marge, et dès l'instant où le propriétaire baisse le loyer pour tout le monde, le sous-locataire n'a plus d'activité.
Que signifie vraiment l'« IA profonde » ?
Je vais vous raconter le moment où le concept a fait tilt pour moi.
Nous travaillions sur un système de traitement documentaire pour un client de la logistique. L'approche initiale était simple : envoyer le document d'expédition à un LLM, lui demander d'extraire les champs pertinents, récupérer les résultats. Cela fonctionnait sur les formulaires standard. Puis nous sommes tombés sur un manifeste de conteneur en provenance d'un port d'Asie du Sud-Est, avec des annotations en plusieurs langues, des corrections manuscrites et un format qui ne correspondait à rien dans les données d'entraînement. Le modèle a renvoyé n'importe quoi, avec assurance.
Mon ingénieur principal, agacé après une semaine de prompt engineering qui produisait sans cesse de nouveaux modes de défaillance, a fini par dire : « Nous demandons à un seul cerveau de faire sept métiers. Et si nous confiions chaque métier à un spécialiste ? »
Voilà l'IA profonde en une phrase. Au lieu de traiter le LLM comme un oracle qui gère tout, vous le traitez comme un composant parmi d'autres dans un système plus vaste. Vous décomposez le problème. Un agent se charge de comprendre la requête. Un autre récupère les données dans une base structurée. Un troisième valide la sortie au regard de règles connues. Un quatrième met en forme la réponse. Chaque agent a une responsabilité définie, et le workflow entre eux est déterministe — c'est-à-dire que vous contrôlez la séquence, la logique et les points de contrôle.
L'IA profonde traite le modèle de langage comme un stagiaire doué, pas comme un PDG. Vous lui confiez des tâches précises dans une structure gouvernée, pas les clés de l'immeuble.
Les design patterns agentiques qui rendent cela possible ne sont pas théoriques. Ils sont déployés dès aujourd'hui :
Un pattern de réflexion où l'agent critique sa propre sortie avant de l'envoyer à l'utilisateur. Un pattern d'utilisation d'outils où l'agent appelle des calculateurs externes, des API ou des bases de données au lieu d'essayer de calculer les réponses de mémoire. Un pattern de planification qui décompose des objectifs complexes en étapes séquentielles. Et un pattern d'orchestration où un agent superviseur pilote l'ensemble du workflow, en aiguillant les tâches vers le bon spécialiste.
Quand nous avons reconstruit ce système logistique avec une orchestration multi-agents, la précision d'extraction sur les documents non standard est passée d'environ 60 % à plus de 95 %. Plus important encore, quand il échouait bel et bien, nous pouvions voir exactement où et pourquoi — car le système n'était plus une boîte noire. C'était un pipeline aux étapes observables et auditables.
Pourquoi le coût des tokens tue-t-il le ROI de l'IA en entreprise ?
C'est la partie dont on ne parle pas assez.
Tout le monde parle de la précision des modèles. Presque personne ne parle de l'économie unitaire de l'exploitation de ces systèmes à grande échelle. Or j'ai vu les coûts de tokens assassiner en silence le business case de projets d'IA qui fonctionnaient par ailleurs parfaitement.
Le calcul est simple mais brutal. Les modèles ne tokenisent pas le texte de la même façon — surtout les textes non anglophones et les écritures complexes. Une requête qui coûte 800 tokens sur un modèle peut en coûter 4 500 sur un autre. Multipliez cela par des centaines de milliers d'interactions quotidiennes et vous obtenez un écart de coût qui annule tous les gains d'efficacité que l'IA était censée apporter.
J'ai eu un vrai moment d'inquiétude quand nous avons mené l'analyse de tokenisation pour un client opérant en tamoul et en anglais. L'écart de coût entre leur modèle en place et une alternative plus efficace était de 4,5x. Ils perdaient de l'argent sur la moindre interaction et l'imputaient aux « coûts d'infrastructure » dans leur budget. Personne n'avait pensé à regarder le tokenizer.
Les systèmes d'IA profonde répondent à cela en dosant chirurgicalement le recours aux tokens LLM coûteux. Les tâches à fort volume et faible complexité sont prises en charge par des modèles plus petits ou une logique déterministe. La capacité de raisonnement coûteuse est réservée aux étapes où elle compte vraiment. C'est la différence entre embaucher un consultant senior pour répondre à chaque appel téléphonique et le laisser se concentrer sur les décisions qui exigent du jugement.
La règle 10-20-70 que personne ne suit
Quand je parle avec des dirigeants des raisons pour lesquelles leurs projets d'IA se sont enlisés, ils pointent presque toujours la technologie. Le modèle n'était pas assez bon. Les données n'étaient pas propres. L'intégration était trop complexe.
Ils n'ont tort sur aucun de ces points. Mais ils passent à côté du vrai ratio. Les entreprises qui constatent réellement un impact sur l'EBIT — et McKinsey affirme que seules 6 % tirent de l'IA plus de 5 % de leur EBIT total — suivent une allocation des ressources qui surprendrait la plupart des technologues :
10 % de l'effort sert à choisir et à régler les algorithmes. 20 % sert à bâtir l'infrastructure de données et de technologie. 70 % sert à accompagner les personnes, à faire évoluer les processus et à conduire la transformation culturelle.
Soixante-dix pour cent. Pas sur la technologie. Sur le fait d'amener des humains à changer leur façon de travailler.
J'ai résisté à cette idée plus longtemps que je n'aurais dû. Je suis ingénieur par instinct. Je voulais croire que si nous construisions un meilleur système, l'adoption suivrait. Il a fallu un projet douloureux — où nous avions livré une solution techniquement excellente restée inutilisée pendant trois mois parce que personne n'avait repensé le workflow autour d'elle — pour intégrer que la technologie est la partie facile.
Les entreprises de taille intermédiaire qui suivent le principe 10-20-70 améliorent leur EBITDA de 160 à 280 points de base en 24 mois. Celles qui consacrent 70 % à la technologie et 10 % à la conduite du changement obtiennent des logiciels coûteux qui prennent la poussière.
Les victoires n'ont rien de glamour. Gestion du cycle de revenus. Automatisation du lettrage des encaissements. Optimisation des coûts cloud. Personne n'écrit de post LinkedIn enflammé sur la réduction des arriérés de dossiers « sortis mais non facturés définitivement ». Pourtant, Inova Health System a réduit cet arriéré de 50 % et économisé 1,3 million de dollars par an. Les assistants virtuels IA d'OSF HealthCare ont permis d'économiser 1,2 million de dollars tout en augmentant le chiffre d'affaires de 1,2 million de dollars supplémentaires. UPS économise 400 millions de dollars par an grâce à un routage fondé sur l'IA.
Ce ne sont pas des résultats de pilote. Ce sont des systèmes en production tournant à grande échelle, bâtis avec le type d'intégration profonde qu'aucun wrapper ne peut approcher.
Que se passe-t-il quand les agents IA commencent à agir seuls ?
Le passage d'une IA qui répond à des questions à une IA qui passe à l'action change entièrement l'équation de la sécurité.
J'y pense beaucoup, en partie à cause d'un incident évité de justesse lors de nos tests. Nous construisions un système agentique qui devait accéder à l'ERP d'un client pour en extraire des données d'inventaire. Pendant un test, l'agent — suivant une chaîne de raisonnement techniquement logique mais contextuellement fausse — a tenté de modifier un bon de commande au lieu de simplement le lire. Nous avions des garde-fous en place. L'opération n'est pas passée. Mais je suis resté à mon bureau ensuite, à me demander ce qui serait arrivé si nous avions été moins prudents.
C'est pourquoi des standards comme le Model Context Protocol (MCP) et le framework NANDA comptent autant. MCP — développé par Anthropic — fait office de couche d'intégration standardisée entre les agents IA et les sources de données d'entreprise. On le surnomme l'« USB-C de l'IA », et c'est juste : cela signifie que vous n'avez pas besoin d'intégrations sur mesure et fragiles pour chaque connexion. NANDA fournit la couche de gouvernance — attestation de capacités cryptographiquement vérifiable (c'est-à-dire que vous pouvez prouver ce qu'un agent a le droit de faire et ce qu'il n'a pas le droit de faire), contrôles d'accès zero-trust étendus aux agents autonomes et pistes d'audit centralisées.
Pour l'analyse technique complète de ces patterns architecturaux et de la façon dont ils s'articulent, consultez notre article de recherche.
Le propos n'est pas que l'IA agentique est dangereuse et que nous devrions ralentir. Le propos est que l'approche wrapper — où vous n'avez qu'une visibilité minimale sur ce que fait le modèle et pourquoi — devient véritablement imprudente dès lors que le modèle peut agir sur le monde réel. Les systèmes d'IA profonde dotés de workflows observables et gouvernés ne sont pas seulement de la meilleure ingénierie. Ils sont la seule façon responsable de déployer des agents autonomes en entreprise.
« Utilisez simplement GPT » et autres conseils coûteux
On me demande constamment s'il ne suffirait pas d'attendre que les modèles s'améliorent. « GPT-5 réglera ça », ai-je entendu un investisseur dire lors d'un dîner. « Pourquoi construire toute cette infrastructure alors que la prochaine version du modèle la gérera nativement ? »
Je comprends l'attrait de cet argument. Il est séduisant par sa simplicité. Il n'exige aucun travail difficile. Et il est faux.
De meilleurs modèles ne règlent pas le problème du wrapper. Ils l'aggravent. Un modèle plus puissant dans une architecture à méga-prompt, c'est comme mettre un moteur de Formule 1 dans une voiture sans volant. Vous allez plus vite dans la mauvaise direction. Les problèmes qui tuent l'IA en entreprise — absence d'auditabilité, prompts cassants, pas de boucles de feedback, contexte métier manquant, coûts incontrôlés — sont des problèmes d'architecture, pas de capacité.
L'économie du shadow AI le prouve. Plus de 90 % des salariés utilisent déjà en secret des comptes ChatGPT ou Claude personnels pour leur travail, parce que les outils d'IA officiels de leur entreprise sont trop rigides. Les modèles sont suffisamment capables. Les systèmes qui les entourent ne le sont pas.
De meilleurs modèles ne sauvent pas une mauvaise architecture. Ils hallucinent simplement plus vite et avec plus d'assurance.
L'autre question qu'on me pose porte sur le calendrier. « Combien de temps cela prend-il réellement ? » La réponse honnête est 12 à 18 mois pour passer d'expérimentations éparses à une IA qui fait bouger le compte de résultat. Les trois premiers mois sont consacrés à la découverte — identifier là où l'IA peut créer de la valeur sans créer d'exposition réglementaire. Les mois trois à six portent sur la préparation des données, l'étape où 58 % des CXO disent se retrouver bloqués. Les mois six à douze servent à construire et à itérer des prototypes multi-agents — et je parle de plus de 30 cycles d'itération sur des données réelles, pas de trois démos léchées. La phase finale est le déploiement en production avec un support opérationnel complet : détection de dérive, surveillance des biais, gouvernance des coûts.
Ce n'est pas rapide. Ce n'est pas facile. Mais les entreprises qui le font sont celles qui figurent dans les 6 % de McKinsey avec un impact réel sur l'EBIT.
La fracture est un choix
La « fracture GenAI » identifiée par le MIT n'est pas un écart technologique. C'est un écart décisionnel.
D'un côté : les entreprises qui ont vu l'IA générative comme un produit à acheter, un wrapper à déployer, une démo à montrer au conseil d'administration. Ce sont les 95 %. Elles ont dépensé de l'argent bien réel et ont obtenu des communiqués de presse.
De l'autre côté : les entreprises qui ont vu l'IA comme un défi architectural — un défi qui exige de décomposer les problèmes, de gouverner les workflows, de repenser les processus et d'accomplir le travail ingrat consistant à relier les modèles à la réalité désordonnée des données d'entreprise. Ce sont les 5 %. Elles ont dépensé des sommes comparables et ont obtenu un impact sur l'EBIT.
Je repense parfois à ce CTO du secteur de la santé. Celui qui m'a appelé un mardi, épuisé, après avoir tout juste tué son projet d'IA. Il m'a rappelé quatre mois plus tard. Son équipe avait reconstruit le système avec une approche multi-agents — des agents distincts pour l'extraction des données, la validation des codes et le contrôle de conformité, avec des passages de relais déterministes entre eux. Ce n'était pas aussi élégant que la démo d'origine. Cela a été plus long à construire. Cela a exigé davantage de réflexion en amont sur la conception du workflow et les modes de défaillance.
Cela a fonctionné. Pas parfaitement — rien ne l'est — mais de façon assez fiable pour être déployé, audité et amélioré. Assez fiable pour apparaître dans un compte de résultat.
L'ère où l'on traitait l'IA comme un tour de magie est révolue. Ce qui vient ensuite est plus difficile, plus lent et moins photogénique. C'est aussi la seule chose qui fonctionne vraiment.
