Il existe un chiffre qui n’apparaît dans aucun document budgétaire d’IA en entreprise. Il ne figure ni dans la conférence de résultats de Microsoft, ni dans le dossier investisseurs de Salesforce, ni dans la présentation d’analyst day de ServiceNow. Ce chiffre, c’est le coût pour défaire ce que l’entreprise a déjà construit.
Les coûts de changement s’accumulent avant que personne ne les remarque. C’est ce qui les rend efficaces en tant que barrière concurrentielle, et ce qui les rend dangereux en tant que passif stratégique. En 2026, les acheteurs de logiciels d’entreprise accumulent simultanément des coûts de changement auprès de quatre fournisseurs d’IA distincts — Microsoft, Salesforce, ServiceNow et Amazon Web Services — et presque aucun d’entre eux ne dispose d’une méthodologie pour mesurer ce que cette accumulation signifie pour sa position de négociation en 2028.
Ce n’est pas une critique du verrouillage fournisseur dans l’abstrait. C’est une observation structurelle sur la manière dont l’adoption de l’IA crée des dépendances à une vitesse et une profondeur que les vagues logicielles précédentes n’ont pas connues. La vague ERP des années 1990 et du début des années 2000 a créé d’importants coûts de changement, mais ces coûts étaient visibles — les projets de migration prenaient des années, portaient des étiquettes de prix définies et exigeaient l’approbation explicite du conseil d’administration. La vague IA actuelle intègre les coûts de changement dans les pipelines de données, les automatisations de flux de travail, la formation des habitudes des employés et le savoir institutionnel — autant d’éléments qui n’apparaissent sur aucun bilan comptable.
Le cadre des sept pouvoirs appliqué à l’IA en entreprise
Le cadre de Hamilton Helmer sur l’avantage concurrentiel durable identifie les coûts de changement comme l’une des sept sources durables de pouvoir. La définition est précise : les coûts de changement existent lorsque la valeur perdue par un client changeant de fournisseur dépasse le gain potentiel de ce changement. Le mot clé est perdue. Les coûts de changement ne se limitent pas au coût financier direct de la migration. Ils incluent la productivité perdue pendant la transition, les coûts de reformation, la perte des configurations personnalisées, et le savoir institutionnel intégré dans le système actuel.
Appliqué à l’IA en entreprise en 2026, ce cadre révèle quelque chose qui n’a pas été largement formulé : les fournisseurs d’IA ne sont pas en concurrence sur la même dimension que celle sur laquelle les acheteurs d’entreprise les évaluent. Les acheteurs mènent des évaluations de capacité — quel modèle produit les meilleurs résultats, quelle interface est la plus facile à utiliser pour les employés, quelle API offre la latence la plus faible. Les fournisseurs mènent des campagnes d’accumulation de coûts de changement. Les deux processus ne sont pas alignés, et les acheteurs perdent du terrain dans la négociation avant même que celle-ci ne commence.
La stratégie Copilot de Microsoft en est l’exemple le plus clair. Au troisième trimestre fiscal 2026 de Microsoft, la pénétration de Copilot au sein de la base de clients entreprise de Microsoft 365 s’établissait à environ 3,3 % — un chiffre qui a suscité une attention notable des analystes, interprété comme la preuve que la vague de l’IA calait. Mais ce taux de pénétration masque ce qui se passe réellement. Les 3,3 % de postes qui utilisent Copilot ne génèrent pas de revenus proportionnels à la valeur du produit ; ils génèrent des dépendances de flux de travail. Chaque utilisateur en entreprise qui construit une habitude régulière de prompts Copilot pour des synthèses de réunion, la rédaction d’e-mails ou l’analyse de documents crée un coût de changement comportemental qui n’apparaît dans aucun tableur. Les propres recherches du Work Trend Index de Microsoft documentent les habitudes de productivité que les utilisateurs adoptent dans les 90 jours suivant l’activation de Copilot — et cette recherche, bien que conçue pour démontrer un retour sur investissement, documente aussi involontairement la profondeur de l’intégration au flux de travail qu’il faudrait défaire pour qu’un utilisateur bascule vers une alternative.
Quatre trajectoires d’accumulation simultanées
Ce qui distingue 2026 des vagues technologiques précédentes, c’est l’accumulation simultanée de coûts de changement à travers plusieurs relations fournisseurs. Une entreprise de taille moyenne dotée d’une pile technologique standard construit désormais probablement des dépendances IA avec au moins quatre fournisseurs distincts à la fois.
Microsoft Copilot. Intégré à Microsoft 365, Teams et GitHub. Les coûts de changement s’accumulent via la formation des habitudes des employés, les automatisations de flux de travail Copilot Studio construites sur SharePoint et les données Teams, et le savoir institutionnel encodé dans des agents Copilot personnalisés. Le coût de changement pertinent n’est pas la redevance de licence Microsoft. C’est le coût de reconstruction des agents personnalisés, de reformation des employés, et de migration des connexions de données sous-jacentes.
Salesforce Agentforce. Intégré à la couche CRM, là où résident déjà les données clients, l’historique des transactions et les dossiers de service. Les coûts de changement d’Agentforce comptent parmi les plus élevés de la vague actuelle car ils s’additionnent aux coûts de changement CRM Salesforce déjà existants. Une entreprise qui abandonne Agentforce évalue implicitement une migration CRM simultanée — un projet qui dure généralement 18 à 36 mois et affiche un taux d’échec que la plupart des directeurs financiers n’accepteront pas.
ServiceNow AI. Intégré à la couche de gestion des services IT. Les capacités d’IA de ServiceNow, lancées en 2025, sont liées au moteur de flux de travail ITSM que la plupart des grandes entreprises ont mis des années à configurer. Le coût de changement y est le plus élevé des quatre : les configurations ServiceNow représentent des dizaines de milliers d’heures d’ingénierie chez la plupart des clients entreprise, et les capacités d’IA sont directement intégrées dans ces configurations, les rendant indissociables de la logique de flux de travail sous-jacente.
AWS Bedrock. Intégré à la couche d’infrastructure. Bedrock est la plateforme IA la plus susceptible de rester invisible aux dirigeants qui évaluent les relations fournisseurs IA — c’est l’environnement d’exécution où les développeurs construisent des applications IA internes. Le coût de changement réside dans la familiarité des développeurs avec les API Bedrock, le coût de refactorisation des applications construites sur des abstractions propres à Bedrock, et l’inertie créée par l’intégration de Bedrock à l’infrastructure AWS existante (politiques IAM, configurations VPC, data lakes S3). Les coûts de changement liés à l’infrastructure AWS sont les mieux étudiés et les mieux compris des quatre, mais Bedrock ajoute une couche nouvelle, absente des analyses de verrouillage AWS antérieures.
L’observation critique n’est pas qu’un seul de ces coûts de changement soit inhabituel. C’est que les quatre s’accumulent simultanément, dans la même organisation, à travers différents services, selon des calendriers différents, sous des responsables budgétaires différents — et sans que personne dans l’organisation ne soit chargé d’en mesurer l’agrégat.
Le trou de responsabilité que personne ne nomme
Voici à quoi ressemble la structure de pouvoir du côté fournisseur. Microsoft, Salesforce, ServiceNow et AWS mènent chacun une stratégie rationnelle de leur point de vue individuel : intégrer les capacités d’IA aussi profondément que possible dans des produits dont l’entreprise dépend déjà, rendre les capacités d’IA essentielles aux flux de travail quotidiens avant que l’entreprise n’ait le temps de mener une évaluation structurée, et faire en sorte que le coût de suppression de la capacité IA soit supérieur au coût de changement du produit sous-jacent seul.
Du point de vue de l’acheteur en entreprise, cette stratégie n’apparaît pas comme une dynamique coordonnée. Chaque décision d’achat est évaluée individuellement : faut-il étendre les postes Copilot, faut-il activer Agentforce, faut-il déployer ServiceNow AI pour notre help desk ? Les critères d’évaluation sont fondés sur la capacité. L’accumulation de coûts de changement est un sous-produit, pas une ligne budgétaire.
C’est un schéma documenté dans les achats de logiciels d’entreprise. Il est apparu lors de la transition du logiciel sur site vers le cloud dans les années 2010, où les entreprises prenaient des décisions individuelles de migration vers le cloud qui créaient collectivement des dépendances multi-fournisseurs sans qu’aucune décision individuelle ne semble porter un risque de verrouillage significatif. La vague IA reproduit ce schéma à une vitesse supérieure, car les capacités d’IA sont intégrées directement dans des produits existants plutôt que d’exiger des décisions d’achat distinctes.
Le trou de responsabilité se situe dans la structure de gouvernance. La plupart des fonctions achats en entreprise évaluent les fournisseurs d’IA sur la capacité, le prix et la posture de sécurité. Très peu disposent d’une méthodologie formelle pour mesurer l’accumulation de coûts de changement en tant que variable de risque. L’approximation la plus proche est l’analyse de risque de concentration fournisseur, que les grandes institutions financières appliquent à leurs fournisseurs technologiques — mais cette analyse a été conçue pour la dépendance à un seul fournisseur, pas pour l’accumulation simultanée de coûts de changement multi-fournisseurs qui se produit aujourd’hui.
Le schéma d’échec du « travail à accomplir » dans l’adoption de l’IA en entreprise documente un problème connexe : les outils d’IA sont recrutés pour la mauvaise tâche par les acheteurs en entreprise, ce qui conduit à de faibles taux d’utilisation. Mais une faible utilisation ne signifie pas un faible verrouillage. Une entreprise peut afficher 3 % d’utilisation de Copilot tout en ayant 60 % de ses travailleurs du savoir avec des habitudes Copilot intégrées à leur flux de travail quotidien — les 97 % de postes restants représentent une croissance potentielle d’utilisation déjà intégrée au prix contractuel, tandis que le coût de changement s’accumule chez les 3 % déjà actifs.
Ce que montre l’histoire du verrouillage multi-fournisseurs
Le parallèle historique le plus proche de la situation actuelle est le marché des middlewares d’entreprise de la fin des années 1990 et du début des années 2000. Les entreprises déployaient simultanément des bases de données Oracle, un ERP SAP, un CRM Siebel et un middleware IBM — chacun portant individuellement des coûts de changement significatifs, et qui créaient collectivement une architecture IT d’entreprise coûteuse à modifier au niveau de chaque composant, car changer un seul composant exigeait de recertifier l’intégration avec tous les autres.
L’analogie du middleware est imparfaite mais instructive. La différence clé réside dans le couplage d’intégration. À l’époque du middleware, les composants logiciels d’entreprise étaient faiblement couplés selon les standards modernes — ils communiquaient via des API et des formats de données définis, et la couche d’intégration était visible en tant que centre de coût distinct. À l’ère de l’IA, l’intégration se produit au niveau de la couche de données : les capacités d’IA ingèrent les données de l’entreprise, apprennent de ses flux de travail et intègrent le savoir institutionnel d’une manière qui n’est pas séparée du produit sous-jacent. Lorsque l’agent personnalisé Copilot d’un travailleur du savoir ingère 18 mois de transcriptions de réunions internes et d’historique d’e-mails pour générer des synthèses contextuelles, le savoir institutionnel qui en résulte est encodé dans l’infrastructure de Microsoft, et non dans un format portable qui migrerait proprement vers une alternative.
La vague middleware a fini par briser le verrouillage multi-fournisseurs grâce à la standardisation — XML, SOAP, puis les API REST ont créé des couches d’interopérabilité qui ont réduit les coûts de changement au niveau des points d’intégration. Reste ouverte la question de savoir si une couche de standardisation comparable émergera dans l’IA. La trajectoire actuelle suggère qu’elle n’émergera pas rapidement : Microsoft, Salesforce et ServiceNow ont des incitations économiques à empêcher l’interopérabilité au niveau de la couche IA, et l’architecture technique du fine-tuning des grands modèles de langage et de la génération augmentée par récupération (RAG) ne produit pas naturellement de résultats portables.
Le problème de mesure
Les coûts de changement sont difficiles à mesurer avec précision car leur ampleur dépend de circonstances qui ne se sont pas encore produites. On ne peut pas savoir exactement ce que coûterait une migration hors de Salesforce avant de la tenter réellement. Mais cette incertitude n’est pas une raison d’éviter la mesure — c’est une raison de mesurer prudemment et tôt, avant que le coût de changement ne s’accumule davantage.
Une approche de mesure pratique des coûts de changement liés à l’IA en entreprise comporterait quatre composantes.
Audit de résidence des données. Pour chaque produit d’IA, documenter quelles données de l’entreprise ont été ingérées dans l’infrastructure du fournisseur, sous quel format, et si elles sont exportables dans un format portable. C’est la tâche de diligence la plus négligée dans les achats d’IA en entreprise. La plupart des contrats fournisseurs précisent les droits de portabilité des données en termes généraux, qui n’ont jamais été testés face à un scénario de migration réel.
Cartographie des dépendances de flux de travail. Identifier quels processus métier ont été modifiés pour dépendre de résultats produits par l’IA. Un flux de travail de synthèse de réunion qui produisait auparavant une synthèse rédigée par un humain et qui produit désormais une synthèse Copilot constitue une dépendance de flux de travail — supprimer Copilot exige soit de rétablir le flux humain, soit de remplacer la sortie IA par une alternative. Le coût de cette substitution est le coût de changement de la dépendance de flux de travail.
Inventaire des configurations personnalisées. Pour des produits comme Salesforce Agentforce et ServiceNow AI, documenter les configurations personnalisées, les agents personnalisés et les données d’entraînement personnalisées créées au sein de l’environnement du fournisseur. C’est le coût de changement le plus souvent sous-estimé : le travail de configuration n’est pas facturable en tant que ligne budgétaire, il s’accumule via l’effort d’ingénierie interne, et il est rarement documenté de manière exhaustive avant qu’une migration ne devienne imminente.
Évaluation des compétences des employés. Mesurer à quel point les flux de travail des employés dépendent d’outils IA spécifiques. C’est le coût de changement le plus souvent totalement ignoré, car la gouvernance IT en entreprise n’inclut généralement pas la formation des habitudes des employés comme variable de risque d’achat. Mais les coûts de reformation des employés — le temps nécessaire pour que les travailleurs du savoir atteignent une productivité équivalente avec un autre outil IA — constituent un coût de changement réel et mesurable, qu’il convient d’estimer avant qu’il ne s’accumule.
Le contre-argument : la concurrence limitera les coûts de changement
Le contre-argument évident est que le marché de l’IA est intensément concurrentiel, et que la concurrence empêchera les coûts de changement de devenir prohibitifs. Si Microsoft augmente agressivement les prix de Copilot, les entreprises migreront vers Google Workspace AI ou une autre alternative, et la menace de cette migration contraindra le pouvoir de fixation des prix de Microsoft.
Cet argument a un précédent historique sur le marché du logiciel d’entreprise. Le pouvoir de fixation des prix des bases de données Oracle a été contraint par l’existence de PostgreSQL et d’autres alternatives, même si les coûts de changement des bases de données Oracle sont élevés. Le pouvoir de fixation des prix de Salesforce a été contraint par Microsoft Dynamics et HubSpot, même si les coûts de changement du CRM Salesforce comptent parmi les plus élevés du logiciel d’entreprise.
L’argument est valide dans son principe, mais il sous-estime la dynamique actuelle de deux façons. D’abord, la pression concurrentielle sur les prix de l’IA exige que des alternatives concurrentielles existent à des niveaux de capacité équivalents — et en 2026, l’écart de capacité entre les principaux produits d’IA en entreprise (Copilot, Agentforce, Bedrock) et leurs alternatives les plus proches est plus important que l’écart de capacité entre Oracle et PostgreSQL au sommet du verrouillage d’Oracle. Ensuite, les coûts de changement de la vague actuelle s’additionnent entre fournisseurs d’une manière que les vagues précédentes ne connaissaient pas : une entreprise qui abandonne Copilot doit aussi évaluer les effets en cascade sur ses intégrations Agentforce et Bedrock, car ces intégrations peuvent dépendre de flux de données qui transitent par l’infrastructure Microsoft.
Une formulation plus exacte de l’argument de la contrainte concurrentielle serait : la concurrence empêchera les hausses de prix extrêmes, mais pas les hausses de prix modérées et durables qui restent en deçà du seuil de coût de changement. Ce seuil est plus élevé que ne l’estiment actuellement la plupart des acheteurs en entreprise, et il continue de croître.
Ce que les entreprises devraient faire avant 2027
Le problème d’accumulation des coûts de changement n’a pas de solution propre, car cette accumulation est un sous-produit d’une valeur réelle du produit. Les entreprises utilisent Copilot, Agentforce et Bedrock parce que ces produits produisent des résultats réels, et arrêter ou ralentir l’adoption pour limiter l’accumulation de coûts de changement imposerait un coût de productivité direct, plus facile à mesurer que le risque futur de coût de changement.
La prescription pratique est une discipline de mesure et d’architecture, pas une retenue d’adoption.
Les entreprises qui construisent leurs capacités d’IA sur des couches d’abstraction — API agnostiques au modèle, formats de données standardisés, contrats d’intégration documentés — auront des coûts de changement plus faibles que les entreprises qui construisent directement sur des API et des pipelines de données propres à un fournisseur. Ce n’est pas un principe nouveau ; c’est le même principe qui a poussé l’adoption en entreprise des architectures ESB (enterprise service bus) dans les années 2000. Son application à l’IA est directe : traiter les API des fournisseurs d’IA comme des points d’intégration nécessitant une abstraction, et non comme des couches applicatives natives.
Le bilan plus large du retour sur investissement de l’IA en entreprise est déjà visible dans les données : les entreprises qui ont déployé l’IA largement sans cadres de mesure ne peuvent pas démontrer de retour, tandis que celles qui l’ont déployée étroitement avec des définitions claires de tâche à accomplir le peuvent. La dimension coût de changement ajoute une seconde exigence de mesure : les entreprises qui déploient l’IA sans suivre la profondeur de la dépendance fournisseur feront face à un second bilan en 2027 et 2028, lorsque les coûts de changement accumulés en 2025 et 2026 détermineront leur position de négociation lors des renouvellements de contrats.
Les entreprises qui en sortent gagnantes sont celles qui traitent leurs relations avec les fournisseurs d’IA comme le font les acheteurs avertis pour toute relation fournisseur où les coûts de changement sont élevés : avec une documentation explicite des dépendances, un étalonnage concurrentiel régulier, et des clauses contractuelles qui préservent l’option de changer même lorsque la probabilité de le faire est faible. La valeur de cette option de pouvoir changer mérite d’être préservée même lorsqu’on n’a pas l’intention de l’exercer. Sur le marché actuel, la plupart des entreprises laissent cette option s’éteindre sans même s’en rendre compte.
Pourquoi les fournisseurs préfèrent vous vendre des dépendances plutôt que des postes
Il vaut la peine de se demander pourquoi Microsoft, Salesforce et ServiceNow ont convergé vers la même conception de produit : intégrer l’IA dans une application que l’entreprise utilise déjà, plutôt que de vendre un produit IA autonome qu’un acheteur pourrait évaluer selon ses propres critères. La réponse se trouve dans le modèle économique, pas dans la technologie. Un produit IA autonome se retrouve en concurrence sur la capacité à chaque cycle de renouvellement, et la capacité, sur ce marché, est une cible mouvante qu’aucun fournisseur ne peut garantir de conserver dans dix-huit mois. Une dépendance, elle, ne se retrouve en concurrence sur rien. Une fois que les synthèses de réunion, les tickets de service et les enregistrements CRM transitent par le modèle d’un fournisseur, la conversation de renouvellement cesse de porter sur la question de savoir si ce modèle est le meilleur disponible, et commence à porter sur la volonté de l’acheteur de défaire toute cette plomberie. C’est une position bien plus confortable pour négocier, et chaque grand fournisseur le sait.
C’est la même manœuvre qui a transformé les marchés du CRM et de l’ITSM en rentes il y a dix ans, et la couche IA ne fait que l’amplifier. Les chiffres de pénétration de postes comme les 3,3 % de Copilot sont lus comme une faiblesse d’adoption, mais du côté du fournisseur, le nombre de postes n’a jamais été le véritable enjeu. Les postes sont conçus pour croître plus tard ; la dépendance, elle, est mise en banque dès maintenant. Un acheteur qui traite chaque achat d’IA comme une décision de capacité isolée mesure ce que le fournisseur est ravi de le voir mesurer, tandis que la variable qui façonnera réellement le renouvellement de 2028 — à quel point le flux de travail suppose désormais l’existence de ce fournisseur — reste non comptabilisée. La réponse stratégique n’est pas de ralentir l’adoption, mais d’intégrer le coût de la dépendance dans la décision d’achat, de la même manière qu’un acheteur intègre déjà le risque de changement dans toute relation fournisseur où la sortie est coûteuse. Les fournisseurs ont bâti leur modèle en pariant que l’entreprise ne ferait jamais ce calcul. Le faire tôt est le seul levier qu’il reste à un acheteur.
Questions fréquentes
Que sont les coûts de changement de fournisseur d’IA et pourquoi comptent-ils en 2026 ?
Les coûts de changement de fournisseur d’IA désignent l’ensemble des coûts — dépenses de migration directes, perte de productivité pendant la transition, coûts de reformation, et valeur du savoir institutionnel perdu — qu’une entreprise supporterait en remplaçant un système IA déployé par une alternative concurrente. Ils comptent en 2026 parce que les entreprises déploient simultanément des systèmes d’IA de plusieurs fournisseurs (Microsoft, Salesforce, ServiceNow, AWS) et accumulent des coûts de changement auprès de chacun d’eux avant même d’avoir développé une méthodologie pour mesurer l’exposition agrégée.
En quoi les coûts de changement de Microsoft Copilot diffèrent-ils des coûts de changement logiciel traditionnels ?
Les coûts de changement logiciel traditionnels sont principalement des coûts de migration de données et de reformation. Microsoft Copilot crée une catégorie de coût de changement supplémentaire : le savoir institutionnel encodé dans les résultats générés par l’IA et les agents personnalisés. Lorsque des employés construisent des flux de travail Copilot qui ingèrent des mois d’historique de communication organisationnelle, ce contexte est stocké dans l’infrastructure de Microsoft. Migrer vers un système d’IA alternatif exigerait de reconstruire ce contexte, ce qu’une simple migration de données ne peut accomplir.
La concurrence sur le marché de l’IA peut-elle limiter le verrouillage fournisseur en entreprise ?
La concurrence limite le pouvoir de fixation des prix extrême, mais n’élimine pas le levier des coûts de changement. Les alternatives concurrentes doivent atteindre une parité de capacité avant que la pression concurrentielle ne devienne effective, et en 2026, l’écart de capacité entre les principaux produits d’IA en entreprise et leurs alternatives les plus proches est significatif. Plus important encore, les coûts de changement s’additionnent entre fournisseurs lorsque les intégrations dépendent de flux de données partagés — abandonner un fournisseur peut exiger d’évaluer les effets en cascade sur les intégrations d’autres fournisseurs.
Quel est le coût de changement d’IA en entreprise le plus sous-estimé ?
La configuration personnalisée et le développement d’agents au sein d’environnements gérés par le fournisseur. Les entreprises qui construisent des agents Salesforce Agentforce, des flux de travail ServiceNow AI et des automatisations Microsoft Copilot Studio encodent un savoir institutionnel dans des configurations qui ne sont pas portables en dehors de la plateforme du fournisseur. Ce travail s’accumule via l’effort d’ingénierie interne et est rarement documenté de manière exhaustive avant qu’une migration ne soit tentée.
Comment les entreprises devraient-elles mesurer les coûts de changement de fournisseur d’IA avant qu’ils ne s’accumulent ?
Quatre composantes : un audit de résidence des données (quelles données de l’entreprise résident dans l’infrastructure du fournisseur, sous quel format, avec quel degré de portabilité), une cartographie des dépendances de flux de travail (quels processus métier ont été modifiés pour dépendre de résultats produits par l’IA), un inventaire des configurations personnalisées (dénombrement et complexité documentés des configurations propres au fournisseur), et une évaluation des compétences des employés (à quel point les flux de travail des employés dépendent d’outils IA spécifiques, et le coût de reformation estimé pour les remplacer par une alternative).
Sources : Hamilton Helmer, 7 Powers: The Foundations of Business Strategy ; conférence de résultats du troisième trimestre fiscal 2026 de Microsoft (avril 2026) ; présentation des résultats du premier trimestre de l’exercice 2027 de Salesforce (mai 2026) ; documents de l’investisseur day du premier trimestre 2026 de ServiceNow ; recherche Gartner sur la stratégie cloud 2026 ; Harvard Business Review — Stratégie technologique 2026.
