DMA et cloud : le guide des PME/ETI européennes pour sortir de la dépendance aux hyperscalers américains

# DMA et cloud : le guide des PME/ETI européennes pour sortir de la dépendance aux hyperscalers américains

*En 2026, le Digital Markets Act est pleinement en vigueur. Les obligations imposées aux grandes plateformes numériques américaines créent des ouvertures réelles — mais elles ne se transforment pas en leviers de souveraineté sans une démarche active côté acheteur. Ce guide s'adresse aux DSI, CTO et RSSI de PME et ETI européennes qui souhaitent traduire le cadre réglementaire en décisions budgétaires concrètes.*

Pourquoi le DMA change (un peu) la donne, sans la régler

Le DMA contraint les « gatekeepers » — dont AWS et Microsoft Azure figurent parmi les acteurs concernés au titre de leurs activités cloud et plateformes — à faciliter l'interopérabilité, à ne plus pratiquer certaines formes de bundling anticoncurrentiel, et à permettre la portabilité effective des données. Ce sont des avancées réelles sur le papier.

Mais voici ce que le DMA ne fait pas : il ne supprime pas les coûts de sortie accumulés depuis des années de migration vers ces infrastructures. Il ne retire pas les clauses d'egress fees qui renchérissent mécaniquement tout départ. Il ne change pas le fait que les directions financières ont souvent internalisé les tarifs des hyperscalers américains comme une norme budgétaire de référence, sans les challenger.

Autrement dit : le DMA crée des droits. Il revient aux organisations européennes de les exercer — activement, méthodiquement, et avec une vision budgétaire à moyen terme.

Étape 1 — Cartographier sa dépendance réelle avant de parler de migration

La première erreur des organisations qui engagent une démarche de souveraineté numérique est de passer directement à la comparaison d'offres alternatives. Sans cartographie précise de la dépendance existante, toute évaluation budgétaire est faussée.

Ce qu'il faut produire :

• Un inventaire des services cloud consommés, classés par fournisseur américain et par criticité métier. Séparer clairement l'infrastructure (compute, stockage, réseau) des services managés (bases de données, IA, analytics) et des outils applicatifs (messagerie, collaboration, ERP en SaaS).
• Une mesure des coûts de sortie *théoriques* : egress fees, coûts de re-platforming, coûts de re-formation des équipes, délais de migration estimés.
• Une identification des données soumises à des obligations réglementaires spécifiques : RGPD, NIS2, sectorielles (santé, finance, défense). Ces données constituent la priorité absolue de tout programme de souveraineté.

Signal d'alerte budgétaire à surveiller : la part des services managés propriétaires (bases de données, fonctions serverless, IA as a service) dans la facture totale. Plus cette part est élevée, plus le coût de sortie est réel et sous-estimé. Ces services sont précisément ceux que le DMA cible — mais leur portabilité effective reste à tester concrètement.

Étape 2 — Utiliser le DMA comme levier de renégociation tarifaire, dès maintenant

Avant même d'envisager une migration, le DMA offre un levier de négociation immédiat que peu d'organisations exploitent.

Les obligations de portabilité et d'interopérabilité imposées aux gatekeepers signifient que vous pouvez légitimement exiger, lors de tout renouvellement contractuel, des conditions qui facilitent une éventuelle sortie : suppression ou réduction des egress fees pour les exports vers des fournisseurs européens certifiés, documentation technique de l'interopérabilité, garanties contractuelles de continuité en cas de changement tarifaire unilatéral.

Tactique concrète : Ne renégociez pas seul. Plusieurs fédérations professionnelles européennes (et certains groupements d'achat sectoriels) mutualisent désormais ces renégociations pour peser davantage face aux équipes commerciales des hyperscalers. Le poids d'un groupement d'ETI dans une même filière est sans commune mesure avec celui d'une organisation isolée.

Point de vigilance : Les équipes commerciales des acteurs américains ont intégré le DMA dans leurs argumentaires. Elles mettront en avant leur conformité déclarée. Exigez des preuves contractuelles, pas des assurances verbales.

Étape 3 — Prioriser les workloads à rapatrier selon un critère souveraineté × coût de sortie

Tout rapatrier d'un coup n'est ni réaliste ni nécessairement pertinent. La méthode efficace consiste à croiser deux axes :

• Axe souveraineté : quel est le risque réglementaire, opérationnel ou stratégique si ce workload reste sous contrôle américain ? (Données personnelles de clients, PI, données de production industrielle, etc.)
• Axe coût de sortie : ce workload repose-t-il sur des services standardisés (portables) ou sur des services managés fortement propriétaires (difficiles à migrer) ?

Les workloads à fort enjeu souveraineté ET faible coût de sortie sont la cible prioritaire. Ce sont typiquement les workloads de stockage de données froides, les sauvegardes, certains environnements de développement/test, et les applications métier standardisées hébergées en IaaS basique.

Les workloads à fort enjeu souveraineté mais coût de sortie élevé (bases de données propriétaires, pipelines IA managés) nécessitent un plan pluriannuel avec une phase de refactoring applicatif. C'est un investissement — à inscrire explicitement dans le budget pluriannuel IT, pas dans les dépenses courantes.

Étape 4 — Évaluer les alternatives européennes sur des critères opérationnels, pas sur des arguments marketing

L'écosystème cloud européen a progressé. Des acteurs comme Scaleway ou Exoscale proposent des infrastructures IaaS/PaaS dont la maturité technique est désormais suffisante pour couvrir une large gamme de workloads de PME/ETI. La question n'est plus « existe-t-il une alternative ? » mais « sur quels critères précis l'évaluer ? »

Critères opérationnels à tester en priorité :

• Conformité réglementaire vérifiable : localisation des données, certifications (SecNumCloud pour la France, équivalents selon les pays), engagement contractuel sur la loi applicable.
• SLA réels sur les services que vous consommez effectivement — et pas seulement sur l'infrastructure de base.
• Capacité de support en langue locale et en fuseau horaire européen. Pour une ETI sans équipe infra dédiée 24/7, c'est un critère budgétaire réel (coût du risque opérationnel).
• Roadmap produit : un acteur européen qui stagne techniquement sur ses services managés vous expose à un écart de fonctionnalités croissant.

Ce qu'il ne faut pas faire : choisir un fournisseur européen uniquement parce qu'il est européen, sans POC technique. La souveraineté n'est pas un substitut à la rigueur d'évaluation.

Étape 5 — Construire un business case budgétaire honnête, avec les coûts cachés visibles

Le principal obstacle à la décision de migration n'est pas technique. Il est financier et politique en interne. Les directions financières comparent naturellement le coût marginal de rester (connu, budgété) au coût total de migrer (incertain, avec effort initial visible).

Pour construire un business case solide :

• Intégrez le risque tarifaire des hyperscalers américains comme un coût probabiliste. Les révisions tarifaires unilatérales, les changements de modèle de licence, et les dépréciations de services ont un historique documenté. Ce risque a une valeur budgétaire.
• Intégrez le risque réglementaire : en 2026, les amendes RGPD et NIS2 sont effectives. Le coût d'une non-conformité liée à une dépendance cloud mal maîtrisée n'est plus théorique.
• Présentez la migration comme un programme pluriannuel avec des jalons de valeur intermédiaires, pas comme un projet tout-ou-rien. Chaque workload migré réduit l'exposition et génère une économie mesurable.
• Ne promettez pas une économie immédiate. Sur les 12 à 18 premiers mois d'un programme de migration sérieux, les coûts sont souvent supérieurs à la situation initiale. C'est un investissement en résilience et en souveraineté, pas une optimisation de court terme.

Étape 6 — Documenter et piloter la réduction de dépendance comme un indicateur de gouvernance SI

Ce qui n'est pas mesuré n'est pas piloté. La dépendance aux hyperscalers américains doit devenir un indicateur explicite dans les tableaux de bord IT, au même titre que la disponibilité ou la sécurité.

Indicateurs à suivre :

• Part de la facture cloud totale hébergée chez des fournisseurs soumis au droit européen.
• Nombre de workloads critiques (données personnelles, PI, données de production) encore hébergés hors juridiction européenne.
• Évolution du coût de sortie théorique total — à la baisse, ce chiffre valide le progrès du programme.

Ces indicateurs ont également une valeur externe : vis-à-vis de clients grands comptes qui auditent désormais la chaîne de sous-traitance numérique de leurs fournisseurs, et vis-à-vis d'assureurs cyber qui intègrent la dépendance cloud dans leurs modèles de risque.

Ce que le DMA ne règle pas — et ce qui reste à faire

Le DMA est un cadre. Il crée des obligations pour les gatekeepers et des droits pour les organisations européennes. Il ne crée pas de volonté politique interne dans vos organisations, il ne finance pas les programmes de migration, et il ne réduit pas mécaniquement le talent gap en compétences cloud alternatives.

La dépendance aux hyperscalers américains s'est construite sur dix ans de décisions budgétaires rationnelles à court terme. La réduire exige une vision à moyen terme, un portage politique interne, et une discipline d'exécution que le cadre réglementaire ne peut pas substituer.

Ce que le DMA offre, en revanche, c'est une légitimité nouvelle pour porter ce sujet en comité de direction — et des obligations contractuelles opposables qui n'existaient pas avant. C'est un point de départ, pas une solution clé en main.