Le modèle n'est pas la partie coûteuse. Dans la plupart des programmes d'IA en entreprise, l'intégration à l'infrastructure existante représente 40 à 60 % du coût total de livraison, et presque aucun dossier d'investissement ne la comptabilise.
This article was translated from the English original. Translations are machine-assisted and reviewed on a rolling basis.
Tout éditeur d’IA d’entreprise fait la démonstration de son produit dans un environnement propre. Les données sont structurées, les API sont bien documentées et le système a été bâti pour accepter exactement le type d’entrée que produit son modèle. Il n’y a là aucune tromperie ; un environnement propre est la seule façon rationnelle de démontrer un produit. C’est aussi profondément peu représentatif de l’environnement dans lequel le produit va réellement fonctionner.
Cet environnement s’est construit sur des décennies, par des équipes différentes, sur des piles techniques différentes, et il n’a jamais été conçu pour être relié à quoi que ce soit qui n’existait pas au moment de sa construction. Faire fonctionner l’IA de manière fiable dans cet environnement est un programme d’ingénierie, pas une tâche de configuration, et c’est systématiquement le poste de coût le plus lourd que les dossiers d’investissement en IA d’entreprise omettent.
Le modèle est la partie la moins chère
La structure tarifaire des éditeurs d’IA crée une distorsion systématique dans la manière dont les organisations estiment le coût d’un programme. Les coûts d’inférence du modèle sont visibles, prévisibles et en baisse. Ils apparaissent clairement dans les propositions des éditeurs et sont simples à projeter. Le travail d’ingénierie nécessaire pour relier un modèle aux systèmes dont il dépend n’apparaît nulle part dans les tarifs des éditeurs.
L’analyse de Gartner sur les structures de coût des programmes d’IA dans les grands déploiements d’entreprise indique que l’intégration et l’ingénierie des données représentent 40 à 60 % du coût total du programme dès lors qu’un déploiement atteint l’échelle de production. C’est le plus gros poste de coût unique dans la plupart des programmes, et dans la plupart des dossiers d’investissement c’est la catégorie la plus susceptible d’être remplie par une estimation de convenance plutôt que par une estimation fondée.
L’enquête Office of the CFO 2025 de L.E.K. Consulting a constaté que l’échec d’intégration était l’obstacle le plus souvent cité à la concrétisation de la valeur de l’IA, devant la performance du modèle, l’adoption par les équipes et les contraintes budgétaires. La technologie fonctionnait. L’infrastructure autour d’elle ne la portait pas.
Pourquoi les systèmes existants sont systématiquement sous-estimés
Les ingénieurs qui ont bâti la plupart des systèmes centraux des entreprises n’y travaillent plus. La documentation de ces systèmes est incomplète, incohérente, ou décrit une version du système remplacée en 2017. Les API, quand elles existent, ont été construites pour les intégrations de l’époque, pas pour l’accès temps réel, à haut volume et structuré aux données qu’exige l’IA.
Cela produit une séquence prévisible de découvertes pendant le travail d’intégration de l’IA. La première : les données dont l’IA a besoin existent, mais pas sous la forme dont elle a besoin. La deuxième : les rendre disponibles sous la bonne forme oblige à toucher des systèmes porteurs d’un risque organisationnel disproportionné (ERP central, grands livres financiers, dossiers clients) où les délais de gestion du changement se comptent en trimestres, pas en sprints. La troisième : la qualité des données dans ces systèmes, au niveau de champ dont dépend l’IA, est plus faible que ne le laissait entendre tout audit mené avant le projet.
Rien de tout cela n’est inhabituel. C’est l’état normal de l’infrastructure de données dans les organisations qui fonctionnent depuis plus de dix ans. Ce qui est inhabituel, c’est de le traiter comme un coût connu d’avance plutôt que comme un coût découvert en chemin.
Les quatre coûts d’intégration que les dossiers d’investissement oublient
Un schéma revient constamment dans les coûts d’intégration que l’on trouve dans les retours d’expérience mais pas dans les dossiers d’investissement.
Préparation et nettoyage des données. Les modèles d’IA produisent des sorties proportionnelles à la qualité de leurs entrées. Dans la plupart des déploiements d’entreprise, amener les données au niveau de qualité qu’exige le modèle est un programme à part entière : audits des systèmes sources, déduplication, normalisation, entretien continu des pipelines. Ce travail est rarement achevé avant qu’un pilote d’IA soit financé, et il est presque toujours sous-estimé quand il l’est.
Authentification et contrôle d’accès. Les systèmes d’entreprise ne partagent pas leurs données librement. Ils ont des structures de permissions, des exigences d’audit et des contrôles d’accès qui n’ont pas été pensés pour des comptes de service d’IA. Relier l’IA à ces systèmes demande un travail d’architecture de sécurité qui prend du temps et, dans les secteurs réglementés, passe par une revue de conformité. Cela n’apparaît sur la grille tarifaire d’aucun éditeur de modèle.
Gestion du changement sur les systèmes sources. Quand l’intégration de l’IA impose de modifier le fonctionnement d’un système source (changer une API, ajouter un déclencheur d’événement, altérer une structure de données), ce changement entre dans la file de gestion du changement de ce système. Dans les grandes organisations, ces files sont longues et les systèmes en tête de file sont rarement ceux dont le programme d’IA a besoin. Les estimations de délai bâties sur l’hypothèse que les changements des systèmes sources se font au rythme du programme sont systématiquement fausses.
Surveillance continue et gestion de la dérive. Une fois le modèle en production, l’intégration ne devient pas gratuite. Les données des systèmes sources changent. Les API en amont sont versionnées. Les sorties du modèle dérivent à mesure que les distributions d’entrée se déplacent. Surveiller et maintenir la couche d’intégration est un coût d’ingénierie permanent que la plupart des dossiers d’investissement tiennent pour négligeable après la mise en service.
À quoi ressemble un dossier d’investissement solide
Les organisations qui chiffrent l’intégration correctement avant le lancement d’un programme y parviennent en partant de l’architecture des systèmes, pas des tarifs des éditeurs.
Avant de soumettre un dossier d’investissement, les bonnes questions sont : à quels systèmes sources cette IA doit-elle accéder, sous quelle forme, avec quelle latence, et quel est l’état actuel de la qualité des données et de la surface d’API de ces systèmes ? Cette analyse produit un périmètre d’intégration réel et une estimation de coût réelle. Elle fait aussi remonter tôt les contraintes des systèmes sources, qui pèseront plus sur le calendrier du programme que n’importe quelle décision de choix de modèle.
Ce n’est pas un processus long. Une revue d’architecture des systèmes de deux jours, menée avant la sélection de l’éditeur, suffit à transformer un dossier d’investissement sans contraintes en un dossier doté d’une structure de coût défendable. Les organisations qui sautent cette étape n’évitent pas le coût. Elles le découvrent plus tard, quand le programme est déjà engagé et que les marges de manœuvre se sont nettement réduites.
Ce que cela implique pour les achats
La taxe d’intégration a une conséquence directe sur la façon dont l’IA d’entreprise est achetée. Choisir un éditeur sur la performance du modèle et le coût de licence, sans tenir compte de la complexité d’intégration, produit une structure de coût qui ne surprendra personne, sauf les personnes qui ont approuvé le budget.
Les processus d’achat qui évaluent les plateformes d’IA sur le risque d’implémentation, précisément sur la propreté et la rapidité avec lesquelles elles se connectent aux systèmes sources que l’organisation exploite réellement, donnent de meilleurs résultats que ceux qui évaluent sur les seuls tests de performance du modèle. Les capacités de modèle des grandes plateformes convergent. La surface d’intégration qu’elles offrent, et l’écosystème de services professionnels qui la soutient, divergent nettement.
Les organisations qui tirent le plus de valeur de l’IA d’entreprise sont celles qui ont abordé leurs programmes avec une idée exacte de ce que relier ces modèles à leur activité allait réellement demander, et qui ont inscrit cette exigence dans le programme dès le départ. La performance du modèle lui-même tranche rarement.
La taxe d’intégration n’est pas un coût caché au sens où il serait difficile à trouver. C’est un coût caché au sens où personne dans le processus d’achat n’a intérêt à le faire remonter tôt. Les éditeurs chiffrent les coûts de modèle. Les intégrateurs chiffrent les coûts d’implémentation sur un périmètre encore indéfini. Les équipes internes estiment sur le scénario optimiste, parce que c’est celui qui fait financer le programme.
Le résultat, ce sont des programmes structurellement sous-financés pour la production et structurellement surengagés sur les délais. Bien construire le dossier d’investissement ne demande ni nouveaux outils ni nouvelle méthodologie. Cela demande de poser les questions d’infrastructure avant les questions aux éditeurs, et de traiter les réponses comme des contraintes plutôt que comme des notes de bas de page.
Frequently asked questions
Why is AI integration into legacy systems so expensive?+
Legacy enterprise systems were not designed to expose the data AI requires in the form it requires it. Connecting them requires translation layers, data cleaning pipelines, authentication bridging, and often significant engineering work on systems that were never meant to be touched again. This work does not appear in model vendor pricing.
What portion of enterprise AI cost is integration?+
Estimates vary, but L.E.K. Consulting's 2025 Office of the CFO survey found integration failure cited as the single largest operational blocker to AI value realisation. Gartner's analysis of AI programme cost structures suggests integration accounts for 40–60% of total programme cost in mature enterprise deployments.
How should enterprise leaders account for integration cost in AI business cases?+
Integration costs should be estimated at the systems architecture level before a business case is submitted — not after a vendor is selected. The questions to answer: which source systems does this AI require access to, in what form, at what latency, and what is the current state of those systems' data quality and API surface?