Une entreprise peut parfaitement affirmer que ses données sont hébergées en Europe tout en dépendant presque entièrement de technologies sur lesquelles elle a peu de prise.
Microsoft 365 pour l'e-mail et la collaboration. Azure ou AWS pour l'infrastructure. Un CRM américain. Une solution de cybersécurité d'un autre fournisseur. Des services d'IA intégrés au même écosystème cloud.
Il n'y a rien d'anormal à cela. Beaucoup de ces plateformes sont solides, évolutives et très bien opérées. Elles disposent d'équipes, de moyens de sécurité et d'une capacité d'innovation qu'une entreprise belge de taille moyenne ne pourrait pas facilement reproduire seule.
Pourtant, la souveraineté numérique est devenue un sujet central en Europe. Le terme donne parfois l'impression qu'il faudrait demain remplacer chaque fournisseur américain ou tout reconstruire en interne. Pour la plupart des entreprises, ce serait irréaliste, voire contre-productif.
La question utile est plus simple :
Quel contrôle nous reste-t-il lorsque quelque chose change ?
Une hausse de prix. De nouvelles conditions contractuelles. Une panne. Une évolution réglementaire. Ou simplement la volonté de changer de fournisseur.
Un datacenter en Europe ne signifie pas que tout est sous contrôle européen
La Commission européenne a rendu cette distinction beaucoup plus concrète en 2026. Dans le cadre de sa stratégie de souveraineté technologique, elle a notamment proposé le Cloud and AI Development Act.
Le texte ne présente pas la souveraineté cloud et IA comme un choix binaire. Il définit plusieurs niveaux d'assurance. Au premier niveau, les données doivent être traitées et stockées dans des infrastructures situées dans l'Union européenne. Les niveaux supérieurs prennent aussi en compte l'indépendance vis-à-vis de pays tiers, la transparence de la chaîne logicielle et, à terme, la propriété et le contrôle depuis l'UE.
La nuance est importante.
Des données peuvent être physiquement stockées à Francfort, Paris ou Bruxelles alors que la technologie, la feuille de route, les mises à jour logicielles, les contrats et les décisions stratégiques restent pilotés ailleurs.
Cela ne rend pas le service mauvais. Cela montre simplement que résidence des données et souveraineté numérique ne sont pas synonymes.
Pour beaucoup d'entreprises, cette distinction est déjà plus utile que la seule question : "Nos données sont-elles en Europe ?"
Le vendor lock-in s'installe progressivement
Le vendor lock-in vient rarement d'une seule mauvaise décision.
Personne ne se réunit avec l'objectif de rendre un changement de fournisseur aussi difficile que possible cinq ans plus tard. C'est plutôt l'inverse qui se produit.
Une équipe choisit une bonne base de données managée. Puis un service d'identité qui s'y intègre bien. Du monitoring. Une plateforme data. Des fonctions serverless. Des outils de sécurité. Quelques services d'IA.
Chaque décision est logique prise séparément.
Quelques années plus tard, toutes ces décisions raisonnables forment ensemble un engagement architectural beaucoup plus important.
L'environnement fonctionne peut-être très bien, mais le faire évoluer ou le déplacer est devenu bien plus difficile que prévu au départ.
C'est la réalité du cloud lock-in. Pas forcément un mauvais choix, mais un choix dont le coût de sortie augmente avec le temps.
L'Europe le traite aussi comme un problème de marché
En juin 2026, la Commission européenne a estimé à titre préliminaire qu'Amazon Web Services et Microsoft Azure pourraient devoir être désignés comme gatekeepers au titre du Digital Markets Act.
La Commission cite notamment leur position durable sur le marché, la taille de leurs écosystèmes, les coûts de changement et les effets de lock-in. Le développement de l'IA compte aussi, car les décisions cloud et IA sont de plus en plus liées.
Le débat devient alors plus intéressant qu'une opposition entre "cloud américain" et "cloud européen".
La vraie question est plutôt :
Une entreprise peut-elle encore réellement choisir, ou ce choix existe-t-il surtout sur le papier ?
Pour un CIO ou un IT manager, c'est plus utile que la nationalité d'un logo.
Changer de fournisseur devient plus simple
Le Data Act européen prévoit des règles spécifiques pour le cloud et les autres services de traitement de données. Les fournisseurs doivent réduire les obstacles techniques au switching et mieux accompagner les clients qui veulent migrer ou combiner plusieurs services.
À partir du 12 janvier 2027, les switching charges disparaîtront également, y compris certains frais de data egress nécessaires pour changer de fournisseur.
C'est utile. Mais cela ne règle pas la difficulté principale.
Déplacer les données n'est pas la même chose que déplacer un environnement.
Exporter une base de données peut être relativement simple. Les applications, policies, scripts, identités et processus construits autour ne suivent pas automatiquement.
Un export n'est pas une stratégie de sortie
Imaginons une entreprise très dépendante d'Azure aujourd'hui et qui veut migrer demain. Les fichiers et bases de données pourront probablement être exportés. Le vrai coût de migration se trouve souvent dans tout ce qui a été construit autour.
Par exemple :
- Identité et accès : intégrations Entra ID, rôles, policies et service accounts.
- Services de plateforme : Azure Functions, monitoring, outils de sécurité et services d'IA.
- Opérations : pipelines de déploiement, automatisation, runbooks, logging et procédures de restauration.
- Connaissance : l'expérience de l'équipe avec cette architecture et ces outils précis.
Une cloud exit strategy commence donc bien avant le jour où quelqu'un décide de partir.
Une entreprise n'a pas besoin d'avoir un projet de migration complet prêt à démarrer. Elle doit en revanche savoir ce qui est portable, ce qui est volontairement lié à une plateforme et quelles dépendances deviendraient coûteuses ou difficiles à remplacer.
Le multicloud n'est pas une assurance gratuite
La réaction classique est : "Alors utilisons plusieurs clouds."
Cela peut être pertinent lorsqu'il existe une raison concrète, par exemple la résilience, la réglementation ou les besoins d'une workload particulière.
Mais le multicloud ne supprime pas automatiquement le lock-in. Il ajoute ses propres coûts et sa propre complexité : davantage de compétences, plusieurs modèles de sécurité, plus de monitoring, plus de contrats, plus d'intégrations et parfois des outils en double.
Et si une organisation se limite volontairement aux services les plus génériques pour rester portable, elle peut aussi perdre une partie des avantages qui l'avaient attirée vers le cloud.
La portabilité a elle aussi un prix.
L'objectif n'est pas que chaque workload puisse tourner demain sur trois plateformes. L'objectif est de savoir où l'on accepte volontairement une dépendance et pourquoi.
Tout lock-in n'est pas mauvais
Dépendre d'un fournisseur n'est pas automatiquement une erreur.
Une plateforme peut apporter pendant dix ans suffisamment de rapidité, d'intégration, de sécurité et de productivité pour justifier largement le coût d'une migration future.
Le problème n'est pas toujours la dépendance elle-même. Le problème est de faire comme si elle n'existait pas.
Si une entreprise choisit consciemment une plateforme parce que la valeur métier est supérieure au risque, c'est une décision d'architecture défendable. Si plus personne ne sait expliquer jusqu'où va la dépendance, c'est autre chose.
La souveraineté est aussi une question de continuité
Il n'est pas nécessaire de transformer ce sujet en débat géopolitique.
Pour une entreprise belge, il s'agit aussi de business continuity très concrète. Quels services s'arrêtent si un fournisseur critique devient indisponible ? Quelles données et configurations pouvons-nous restaurer nous-mêmes ? Et avons-nous encore les connaissances et les alternatives nécessaires si les prix, les conditions ou la réglementation changent fortement ?
Ce ne sont pas des questions abstraites. Elles touchent directement la résilience, le risque et le pouvoir de négociation.
L'IA peut encore renforcer la dépendance
Avec l'IA, le sujet devient très concret parce que la dépendance se situe rarement uniquement dans le modèle choisi.
Une application RAG moderne peut s'appuyer à la fois sur du stockage documentaire, un service d'embeddings, de la vector search, l'identité, le monitoring, la sécurité et un agent framework du même fournisseur cloud. Pour une équipe de développement, c'est séduisant : les composants fonctionnent déjà ensemble et une première application peut être construite rapidement.
Mais chaque composant intégré augmente aussi l'adhérence à la plateforme.
Les embeddings peuvent être recalculés et les données déplacées vers une autre base vectorielle. Cela ne déplace pas automatiquement la logique de retrieval, les règles d'accès, les évaluations, l'observability ni les intégrations. Plus ces éléments reposent sur un seul écosystème, plus le projet de migration devient important.
Le modèle choisi aujourd'hui peut être remplacé l'année prochaine. L'architecture autour reste souvent beaucoup plus longtemps.
Une application IA construite en quelques semaines peut donc devenir sans qu'on s'en rende compte une décision d'architecture pour plusieurs années.
Ce n'est pas forcément un mauvais choix. Il vaut simplement mieux le voir pendant la conception que cinq ans plus tard.
L'indépendance totale n'est pas l'objectif
Pour presque toutes les organisations modernes, l'indépendance technologique complète est irréaliste. Elle n'a pas besoin d'être l'objectif.
La question la plus utile est :
Quelles dépendances acceptons-nous consciemment, et lesquelles pourraient nous bloquer plus tard ?
Cette discussion ne concerne pas uniquement l'IT. Security, procurement, finance, legal et management ont également leur mot à dire.
Trois questions pour le prochain comité IT
- Quels systèmes sont devenus si critiques qu'un changement de fournisseur prendrait aujourd'hui plus d'un an ?
- Où acceptons-nous volontairement une dépendance parce que la valeur métier la justifie, et où cette dépendance s'est-elle simplement installée sans décision consciente ?
- Que pourrions-nous réellement faire si les prix, les conditions, la disponibilité ou la réglementation autour de notre fournisseur principal changeaient fortement ?
La souveraineté numérique ne signifie pas qu'il faut tout posséder soi-même. Héberger les données en Europe peut faire partie de la réponse, mais le contrôle réel va plus loin.
On ne dispose d'un vrai choix que lorsqu'on sait où l'on dépend d'un tiers, pourquoi on l'accepte et ce que l'on ferait s'il fallait un jour changer de direction.
Sources et lectures complémentaires
- Commission européenne, Strengthening Europe's Tech Sovereignty (3 juin 2026) : https://digital-strategy.ec.europa.eu/en/policies/eu-tech-sovereignty
- Commission européenne, Cloud and AI Development Act : https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act
- Commission européenne, Preliminary position on AWS and Microsoft Azure under the Digital Markets Act (25 juin 2026) : https://digital-markets-act.ec.europa.eu/commission-reaches-preliminary-position-amazons-and-microsofts-market-leading-cloud-services-should-2026-06-25_en
- Commission européenne, Data Act explained : https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained