Le retour sur investissement de l'IA en entreprise est un problème d'architecture, pas d'intelligence
Il existe un chiffre que les directeurs des systèmes d'information mémorisent avec malaise : 72 % des organisations admettent que leurs investissements en IA sont, dans le meilleur des cas, à l'équilibre. Dans le pire, ils perdent de l'argent. Gartner a publié ce chiffre, et il n'a pas provoqué de panique, mais quelque chose de plus persistant : une incertitude silencieuse sur le temps encore possible de soutenir un pari sans démontrer qu'il fonctionne.
La réponse habituelle pointe vers les modèles. Il faut mieux choisir le fournisseur, affiner les invites, attendre que les prix d'inférence baissent. Cette réponse est commode et presque toujours erronée. Ce qui échoue, ce n'est pas l'intelligence de la machine. Ce qui échoue, c'est l'architecture de l'entreprise qui l'entoure.
Le problème a une mécanique très concrète : chaque fois qu'une entreprise lance un nouvel agent d'IA, cet agent repart de zéro. Il reconnecte les données, reconstruit le contexte métier, renégocie les permissions, redessine les contrôles, établit ses propres critères de validation. S'il y a six agents en production, il existe six versions parallèles et indépendantes de cette infrastructure. Chacune avec son propre coût, sa propre dette technique, sa propre opacité. Le résultat n'est pas de l'intelligence artificielle à l'échelle. C'est de la bureaucratie numérique à l'échelle.
Pourquoi le coût réel de l'IA n'apparaît pas sur la ligne d'inférence
Le piège comptable est sophistiqué. Lorsqu'une équipe évalue si un projet d'IA a un sens économique, elle regarde généralement le coût du modèle : combien coûte l'appel à l'API, combien de tokens chaque requête consomme, quel fournisseur offre le meilleur prix par capacité. Cette analyse n'est pas fausse, mais elle ne capture qu'une fraction du coût total.
Ce qui n'apparaît pas sur cette ligne, c'est le coût de l'intégration répétée. Chaque agent déployé sans une couche partagée de contexte métier nécessite que quelqu'un construise, depuis zéro, ses connexions avec les systèmes d'enregistrement de l'entreprise, ses mécanismes d'autorisation, ses règles métier, sa logique d'escalade. Ce n'est pas un coût de modèle. C'est un coût d'ingénierie, de gouvernance, d'opérations. Et il se répète intégralement à chaque nouveau cas d'usage.
Une équipe de services financiers étudiée par des chercheurs de l'Université de Hong Kong et Stellaris AI a constaté que plus de 70 % de ses requêtes étaient suffisamment routinières pour être résolues par des modèles plus petits et moins coûteux. Pourtant, tout s'exécutait sur la même infrastructure à coût élevé parce que personne n'avait conçu de mécanisme pour discriminer selon la complexité. Les dépenses d'inférence dépassaient 200 000 dollars mensuels, non pas parce que l'activité était sophistiquée, mais parce que l'architecture n'avait pas la mémoire de savoir quand l'être.
Le problème de répartition des coûts présente un autre angle moins visible : lorsque les coûts sont dispersés entre intégrations, équipes et outils, attribuer la valeur générée devient mathématiquement impossible. Ce n'est pas que le ROI est faible. C'est qu'il n'existe aucun moyen de le mesurer, faute d'un registre unifié de quelles données chaque agent a utilisées, quelles décisions il a prises, combien chaque étape a coûté et quel résultat elle a produit. La fragmentation ne fait pas seulement renchérir le déploiement. Elle détruit la traçabilité qui permettrait de justifier l'investissement.
Ce qu'une couche partagée change dans l'économie du déploiement
La solution qui commence à s'articuler parmi les architectes de systèmes d'entreprise n'est pas de moins investir dans l'IA ni d'acquérir de meilleurs modèles. C'est de construire une couche de contexte partagée qui fonctionne comme la colonne vertébrale de tous les agents et flux de travail de l'organisation.
L'idée obéit à une logique économique précise. Si la connaissance métier, les permissions, les règles de gestion et la logique de gouvernance sont construites une seule fois et exposées comme infrastructure réutilisable, le coût marginal du déploiement du deuxième, du cinquième et du dixième cas d'usage diminue de façon significative. Non pas parce que les modèles sont moins chers, mais parce que l'entreprise ne paie plus le coût de reconnexion de sa propre activité chaque fois qu'elle ajoute une nouvelle application.
Une entreprise multinationale du secteur cosmétique en a fait l'expérience. Ses premiers agents fonctionnaient bien en démo, mais s'effondraient en production parce que chacune des six solutions intégrées maintenait son propre référentiel de connaissances et ses propres règles de gouvernance dans des silos indépendants. Chaque agent repartait à froid. Chaque nouveau projet exigeait une reconnexion depuis zéro. Le coût n'était pas le modèle. C'était la répétition.
La centralisation du contexte modifie également la logique du routage. Lorsque l'infrastructure sait quel type de tâche elle traite, elle peut la diriger vers le modèle adéquat : un modèle plus puissant et plus coûteux pour le raisonnement complexe, un modèle plus petit et plus rapide pour les requêtes routinières. Les dépenses d'inférence cessent d'être un coût fixe et deviennent une variable qui répond à la complexité du travail. Ce n'est pas une optimisation marginale. C'est une reconfiguration du modèle de coûts.
De manière complémentaire, l'architecture en essaims d'agents spécialisés produit des résultats similaires du côté de l'efficacité computationnelle. Au lieu d'un super-agent qui doit traiter le contexte complet d'un problème à chaque étape, plusieurs agents aux domaines délimités opèrent en parallèle. Chacun travaille avec une fenêtre de contexte plus petite, plus précise, moins coûteuse. La coordination entre agents exige une gouvernance partagée pour fonctionner sans créer de nouveaux risques opérationnels, mais lorsque cette gouvernance existe, l'économie de tokens par tâche peut être considérable.
La gouvernance n'est pas le frein. Elle est la condition de mise à l'échelle.
McKinsey a documenté quelque chose que de nombreuses équipes technologiques ont appris à leurs dépens : intégrer la gouvernance après que l'IA est déjà en production génère des coûts de réingénierie qui peuvent dépasser la valeur que le système produisait. Gartner estime que des technologies de gouvernance bien intégrées peuvent réduire les dépenses réglementaires jusqu'à 20 %. Ce ne sont pas des chiffres de conformité. Ce sont des chiffres d'architecture.
Le problème avec la gouvernance comme couche ajoutée à la fin est le même qu'avec le contexte comme travail répété : elle se reconstruit intégralement pour chaque application. Un flux de traitement de sinistres en assurance nécessite un accès contrôlé aux données des assurés, la traçabilité des décisions, des limites à l'autonomie de l'agent et des règles d'escalade vers la révision humaine. Si cela est conçu uniquement pour ce flux, il faut tout reconcevoir pour le suivant. Dix agents indépendants signifient dix versions de la même architecture de contrôle, dix fois le coût d'approbation, dix fois le risque d'incohérence.
Lorsque la gouvernance est construite comme plateforme, les contrôles sont définis une fois sous forme de code et appliqués de manière transversale. Le coût n'évolue pas de façon linéaire avec le nombre d'agents, parce que les contrôles existent avant l'arrivée des agents. Cette différence sépare les organisations capables de mettre l'IA à l'échelle de celles qui accumulent une dette technique et opérationnelle tout en croyant qu'elles montent en charge.
La traçabilité qu'une plateforme de gouvernance produit présente un avantage supplémentaire que peu de conversations sur le ROI mentionnent explicitement : elle transforme l'IA de boîte noire en système auditable. Chaque flux de travail laisse un enregistrement des données utilisées, des actions entreprises, de l'intervention humaine requise, du coût engagé et du résultat produit. Ce n'est pas seulement du contrôle des risques. C'est l'infrastructure qui rend possible la mesure de la valeur économique avec la granularité que les conseils d'administration et les investisseurs exigeront avec une urgence croissante.
L'architecture comme décision de distribution de la valeur
Il existe une dimension que l'analyse technique tend à laisser de côté, mais qui a des conséquences économiques directes : l'architecture d'IA ne détermine pas seulement l'efficacité opérationnelle de l'entreprise. Elle détermine qui capte la valeur générée par l'IA.
Une organisation qui construit une couche de contexte partagée, un mécanisme de routage intelligent et une plateforme de gouvernance unifiée construit des actifs internes qui réduisent sa dépendance aux fournisseurs externes. Elle peut changer le modèle de langage sous-jacent sans reconstruire la logique métier. Elle peut ajouter de nouvelles applications sans repayer le coût complet d'intégration. Elle peut auditer la valeur de chaque flux de travail parce qu'elle dispose de l'infrastructure pour le faire.
Une organisation qui ne construit pas cela externalise en revanche de façon permanente les économies d'échelle de l'IA. Chaque nouveau fournisseur, chaque nouveau modèle, chaque nouvel outil capte une portion de la valeur, parce que l'entreprise ne possède pas l'architecture qui lui permettrait d'internaliser cette captation. Le coût de changement augmente. La capacité de négociation diminue. La valeur générée par l'IA se filtre vers l'extérieur au lieu de s'accumuler en interne.
Cela a des implications sur la façon d'évaluer les dépenses en IA. La question à laquelle les directeurs des systèmes d'information devraient répondre n'est pas combien coûte le modèle, mais quelle part de cette dépense construit une capacité réutilisable et quelle part paie, une fois de plus, pour une capacité qui devrait déjà exister. La réponse à cette question est la différence entre un investissement en architecture et une dépense qui se répète sans jamais s'accumuler.
Les 72 % d'organisations à l'équilibre ou en perte n'ont pas nécessairement de mauvais modèles. Elles ont une architecture qui garantit que le coût de chaque nouveau cas d'usage est presque aussi élevé que celui du premier. Ce n'est pas un problème d'intelligence. C'est un problème de conception. Et les problèmes de conception ont des solutions plus spécifiques, plus durables et plus mesurables qu'attendre que les prix d'inférence baissent suffisamment pour que les comptes s'équilibrent d'eux-mêmes.
