Infrastructure Cloud

Sur le marché mondial de l’infrastructure cloud, trois entreprises détiennent environ 65–70 % de parts de marché : Amazon Web Services, Microsoft Azure et Google Cloud Platform. Toutes trois sont américaines, soumises au droit américain — y compris le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), qui autorise les autorités américaines à contraindre des fournisseurs américains, par mandat ou assignation, à produire des données — quel que soit le lieu physique de stockage. Les fournisseurs peuvent contester ces ordonnances en justice, mais l’exposition juridictionnelle demeure.

Une atténuation courante consiste à choisir une région de centre de données européen d’un fournisseur américain. Cela réduit certains risques — latence, exigences de résidence de données — mais ne résout pas la question juridictionnelle. Les données restent sous le contrôle d’une entreprise constituée aux États-Unis, soumise au droit américain. Le EU-US Data Privacy Framework (2023) offre des garanties juridiques supplémentaires pour les transferts transatlantiques de données — mais c’est la troisième tentative, après Safe Harbor (invalidé en 2015) et Privacy Shield (invalidé en 2020), tous deux annulés par la Cour de justice de l’UE dans les arrêts Schrems I et Schrems II. Max Schrems a signalé qu’il pourrait contester ce cadre également. Sa stabilité à long terme reste une question ouverte.

En Europe, le tableau est encore plus net. Les hyperscalers américains contrôlent environ 70 % du marché cloud européen. Les fournisseurs européens — OVHcloud, Hetzner, IONOS, Scaleway et des dizaines d’opérateurs plus petits — représentent environ 15 %. Le reste revient à de petits acteurs internationaux.

Ce ne sont pas de simples parts de marché. Ce sont les paramètres d’une dépendance : la majorité des entreprises européennes, des administrations publiques et, de plus en plus, des infrastructures critiques fonctionnent sur des ressources de calcul sous juridiction américaine. La question n’est pas de savoir si un risque de concentration à ce niveau est un problème — n’importe quel gestionnaire de risques signalerait une dépendance à 70 % envers des fournisseurs sous une seule juridiction étrangère. Le Parlement européen l’a constaté en ces termes. La question est de savoir pourquoi cela persiste, et ce que l’on peut — concrètement — y faire.

Le mythe du prix

Demandez à n’importe quel directeur technique pourquoi il utilise AWS, et la réponse est généralement une combinaison d’« écosystème », de « services managés » et de « ça marche, tout simplement ». Rarement il dira « parce que c’est pas cher ». Et pour cause.

Une comparaison à ressources de calcul équivalentes raconte une histoire qui contredit la sagesse conventionnelle. Un serveur dédié avec 64 Go de RAM et un processeur AMD Ryzen 8 cœurs chez Hetzner coûte environ 40–50 € par mois. Une instance EC2 comparable chez AWS — disons une m6a.2xlarge — revient à environ 280 $ par mois, soit plus de cinq fois plus. L’écart se réduit quelque peu avec les instances réservées et les plans d’économie, mais même alors, la prime de prix de l’hyperscaler américain est typiquement de 3 à 5x pour le calcul et de 5 à 10x pour le stockage.

Ce n’est pas un secret. Toute start-up européenne ayant dépassé le stade de son financement initial a fait le calcul. Ce qui maintient les organisations chez les hyperscalers, ce n’est pas le prix — c’est l’écosystème. Bases de données managées, fonctions serverless, API de machine learning, services d’identité, monitoring, CDN, des dizaines de services pré-intégrés qui nécessiteraient chacun une configuration, une maintenance et une expertise distinctes chez un fournisseur européen. La couche de services managés est le fossé défensif, pas la machine virtuelle.

Pour les organisations qui exploitent des charges de travail standard — applications web, bases de données, stockage de fichiers, pipelines CI/CD —, les fournisseurs européens offrent des alternatives réellement compétitives à une fraction du coût. Pour les organisations profondément ancrées dans les services propriétaires des hyperscalers (Lambda, DynamoDB, BigQuery), le changement est coûteux et complexe. Cette distinction est capitale, car elle détermine si une migration est un projet de week-end ou un programme pluriannuel.

La saga EUCS

Pour comprendre pourquoi la souveraineté cloud européenne progresse au rythme qu’elle connaît, il suffit de regarder le schéma européen de certification cloud — EUCS.

Proposé par l’ENISA (l’agence européenne de cybersécurité) en 2020, l’EUCS devait définir des niveaux de sécurité pour les services cloud utilisés par les gouvernements et les infrastructures critiques de l’UE. Trois niveaux étaient prévus : Basique, Substantiel et Élevé. Le niveau « Élevé » devait, dans les premières versions, inclure des exigences de souveraineté — le fournisseur cloud devait être exempt de toute juridiction extra-européenne, les données traitées exclusivement en Europe par des entités sous contrôle européen.

La France était la force motrice. Paris disposait déjà de son propre schéma national, SecNumCloud, opéré par l’ANSSI (l’agence française de cybersécurité). SecNumCloud exige que le fournisseur cloud soit détenu majoritairement par des entités de l’UE et qu’aucun droit extra-européen ne puisse contraindre à la divulgation de données. C’est, en fait, une exigence de souveraineté. La France voulait que le niveau Élevé de l’EUCS soit compatible avec SecNumCloud — ou à tout le moins pas plus faible.

Les hyperscalers américains ont, sans surprise, intensément lobbé contre les exigences de souveraineté. Leur argument : exclure les fournisseurs américains du niveau de certification le plus élevé serait protectionniste, réduirait le choix et n’améliorerait pas la sécurité. Plusieurs États membres de l’UE — en particulier les Pays-Bas et les pays nordiques — étaient sensibles à cette position, arguant que les exigences de souveraineté écarteraient les fournisseurs les plus performants.

Le résultat, après plus de quatre années de négociation : les exigences de souveraineté ont été retirées du projet EUCS. Le niveau « Élevé » se concentre désormais sur des mesures de sécurité techniques — chiffrement, contrôles d’accès, journaux d’audit — mais n’exige ni propriété ni juridiction européennes. La France a exprimé sa déception mais n’a pas bloqué le schéma, préférant maintenir SecNumCloud comme complément national.

La saga EUCS illustre la difficulté de définir des exigences de souveraineté que toutes les parties prenantes acceptent. Le schéma qui finira par émerger vaut mieux que rien — mais ce n’est pas ce que le mot « souveraineté » implique.

Gaia-X : la conférence devenue projet

Aucune discussion sur la souveraineté cloud européenne n’est complète sans mentionner Gaia-X. Et aucune discussion sur Gaia-X n’est complète sans une certaine lassitude.

Lancé en 2019 par l’Allemagne et la France avec beaucoup d’énergie, Gaia-X devait être la réponse européenne à la domination des hyperscalers : une infrastructure de données fédérée reposant sur des standards communs, permettant aux fournisseurs européens d’offrir des services interopérables sous les règles européennes. La vision était séduisante. L’exécution a été — pour le dire avec bienveillance — lente.

En 2024, l’association Gaia-X comptait plus de 350 membres. Parmi eux : AWS, Microsoft et Google. L’organisation censée réduire la dépendance aux hyperscalers américains avait invité les hyperscalers américains à contribuer à la définition des règles. C’est soit du pragmatisme, soit de l’absurdité, selon le point de vue.

Ce que Gaia-X a produit, ce sont des documents de standards, des cadres de conformité et un Trust Framework pour la labellisation des services. Ce qu’il n’a pas produit, c’est quoi que ce soit qu’un administrateur système pourrait déployer un lundi matin. Les Digital Clearing Houses de Gaia-X — destinées à vérifier la conformité — ont tardé à se concrétiser. Des projets vitrines existent mais restent de niche.

La lecture bienveillante : Gaia-X est un organisme de normalisation, pas un fournisseur cloud. Les standards prennent du temps. La lecture moins bienveillante : Gaia-X est devenu le symbole de la culture européenne de l’annonce — beaucoup discuté, bien documenté, jamais installé.

Sovereign Cloud Stack : le succès discret

Si Gaia-X est la conférence, le Sovereign Cloud Stack (SCS) est le code.

Financé par le ministère fédéral allemand de l’Économie et de la Protection du climat (BMWK) dans le cadre du programme de financement Gaia-X, SCS a adopté une approche différente : au lieu de définir des standards dans l’abstrait, il a construit une implémentation de référence. La pile repose sur OpenStack pour l’infrastructure, Kubernetes pour l’orchestration de conteneurs et Keycloak pour la gestion d’identité — le tout en open source, le tout éprouvé à l’échelle.

La valeur pratique de SCS est l’interopérabilité : les charges de travail exécutées sur un cloud certifié SCS peuvent être transférées vers un autre cloud certifié SCS sans modification. Cela répond directement au problème de la dépendance fournisseur — non par la réglementation, mais par l’architecture.

Plusieurs fournisseurs allemands ont adopté SCS : plusserver, REGIO.cloud, Wavecon et d’autres. L’adoption est modeste par rapport à l’échelle des hyperscalers, mais elle prouve que le concept fonctionne.

Le défi est survenu fin 2024, lorsque le financement du BMWK a expiré. SCS a opéré une transition vers une gouvernance communautaire sous l’égide de l’Open Source Business Alliance (OSBA). La question de savoir si un projet financé par la communauté peut maintenir l’élan d’un projet financé par l’État reste ouverte. Le code est solide. La question est de savoir si l’écosystème qui l’entoure croîtra assez vite.

Quand la réalité physique frappe : l’incendie d’OVH

Le 10 mars 2021, un incendie a détruit le centre de données SBG2 à Strasbourg, opéré par OVHcloud — le plus grand fournisseur cloud européen. 3,6 millions de sites web se sont retrouvés hors ligne. Des données clients ont été perdues. L’incendie a également endommagé le bâtiment adjacent SBG1.

L’incident a révélé une vérité inconfortable : certains clients avaient supposé que « cloud » signifiait automatiquement redondance géographique. Ce n’était pas le cas. Les offres d’entrée de gamme d’OVHcloud n’incluaient pas les sauvegardes hors site par défaut. Les clients qui n’avaient pas explicitement configuré une réplication multi-sites ont perdu leurs données de manière irréversible.

L’incendie n’a pas démontré que les fournisseurs européens sont peu fiables. Des incendies de centres de données peuvent survenir partout — un incendie dans un centre Cyxtera (US) à Londres en 2022 a causé des perturbations similaires. Ce que l’incendie d’OVH a démontré, c’est que « moins cher » signifie souvent « moins de fonctionnalités par défaut ». Les hyperscalers incluent la redondance géographique dans leur architecture standard. Les fournisseurs européens, en concurrence sur les prix, la proposent souvent en option. Pour les organisations migrant d’AWS vers Hetzner ou OVH, comprendre ce qui n’est pas inclus par défaut est aussi important que la comparaison de prix.

Les stratégies nationales

Pendant que l’UE débat de schémas de certification, les États membres construisent leurs propres stratégies de souveraineté cloud — avec des degrés variables d’ambition et de succès.

France : SecNumCloud et Bleu

La France possède le cadre national le plus abouti. SecNumCloud, opéré par l’ANSSI, impose des exigences strictes de souveraineté. Les fournisseurs certifiés doivent être détenus majoritairement par des entités de l’UE. Aucune juridiction extra-européenne ne doit s’appliquer aux données.

Le résultat le plus visible est Bleu — une coentreprise entre Orange et Capgemini, lancée en 2024, qui opère des services Microsoft 365 et Azure sous certification SecNumCloud. Le concept : le logiciel de Microsoft, mais tournant sur une infrastructure contrôlée par des entités françaises, opérée par des entités françaises, sous droit français. Microsoft fournit la technologie sous licence ; Bleu l’exploite.

C’est un compromis pragmatique. Il donne aux administrations françaises accès aux outils Microsoft familiers tout en maintenant la souveraineté juridique sur les données. Les critiques objectent que cela ne résout pas la dépendance de fond — la France reste tributaire du logiciel, des mises à jour et de la feuille de route de Microsoft. Les défenseurs rétorquent que le mieux ne doit pas être l’ennemi du bien : si l’alternative est que les données gouvernementales résident sur un Azure contrôlé par les États-Unis, Bleu est une amélioration significative.

Allemagne : Delos Cloud et SCS

L’Allemagne a suivi deux voies parallèles. Le Sovereign Cloud Stack, décrit ci-dessus, représente la voie open source. Delos Cloud — une coentreprise entre SAP et Arvato Systems (Bertelsmann) — reproduit le modèle français Bleu : des services Microsoft 365 opérés sous souveraineté allemande par des entités allemandes.

De plus, Microsoft a annoncé Microsoft 365 Local en juin 2025 — une option on-premises conçue pour répondre aux préoccupations de souveraineté. Que cela représente une véritable concession ou une stratégie pour maintenir les gouvernements européens sur la plateforme Microsoft en supprimant l’objection juridictionnelle est affaire de perspective. Pour Microsoft, le pire scénario n’est pas une marge réduite sur un déploiement souverain — c’est qu’un gouvernement bascule entièrement vers openDesk ou LaSuite.

Danemark : diversification systématique des fournisseurs

À l’été 2025, le Danemark a annoncé un programme systématique de réduction de la dépendance à Microsoft 365 dans l’administration. La ministre des Affaires numériques Caroline Stage Olsen l’a formulé en termes de risque de concentration : « Nous ne devons jamais nous rendre aussi dépendants d’un si petit nombre. »

L’approche danoise est globale. Le ministère des Affaires numériques a commencé à déployer LibreOffice sur les postes de travail gouvernementaux durant l’été-automne 2025. Copenhague et Aarhus ont annoncé des initiatives similaires au niveau municipal. La migration est en cours, et le bilan complet prendra des années à se dessiner — mais le Danemark est devenu le cas le plus emblématique d’un gouvernement d’Europe occidentale choisissant explicitement de réduire sa dépendance à Microsoft à l’échelle nationale.

Le fossé des services managés

Voici ce que les défenseurs de la souveraineté passent parfois sous silence : les fournisseurs cloud européens sont plus faibles sur les services managés.

AWS propose plus de 200 services managés. Azure offre une gamme comparable. Cela inclut des bases de données managées (RDS, Cosmos DB), du calcul serverless (Lambda, Azure Functions), des services d’IA (SageMaker, Azure OpenAI), de l’analytique (Redshift, Synapse), des plateformes IoT et des dizaines d’autres. Chaque service managé signifie moins de charge opérationnelle pour le client — et plus de dépendance.

Les fournisseurs européens comme Hetzner et OVH excellent dans l’infrastructure : machines virtuelles, serveurs bare-metal, stockage, réseau. Leur offre de services managés progresse mais reste modeste en comparaison. Scaleway a davantage investi dans cette direction, proposant du Kubernetes managé, des bases de données et des instances GPU pour l’IA. Mais le fossé est réel.

Pour les organisations évaluant une migration, cela signifie : si vous utilisez EC2, S3 et RDS dans une configuration standard, un fournisseur européen peut probablement vous servir à un coût 3 à 5 fois inférieur. Si vous êtes profondément ancrés dans Lambda, Step Functions et DynamoDB — une migration est possible mais nécessite une ré-architecture significative. Le calcul du coût total de possession doit inclure non seulement la facture mensuelle, mais l’effort de migration.

Le Data Act : la réglementation comme levier

Un texte européen mérite d’être mentionné pour sa pertinence directe avec la migration cloud : le Data Act (UE 2023/2854), applicable depuis le 12 septembre 2025.

Le Data Act introduit des obligations pour les fournisseurs cloud de faciliter le changement de prestataire : ils doivent fournir des outils d’exportation de données, supporter la portabilité des données, et il leur est interdit de facturer des frais de changement excessifs. À partir de janvier 2027, les frais de changement devront être entièrement supprimés.

C’est significatif non parce que cela rend la migration facile — la complexité technique demeure — mais parce que cela supprime l’un des obstacles que les fournisseurs cloud ont délibérément érigés. Jusqu’à présent, extraire de grands volumes de données d’un hyperscaler impliquait souvent des frais de sortie substantiels. Le Data Act change le calcul économique.

À quoi ressemble une migration réaliste

Les organisations qui ont réussi à transférer des charges de travail hors des hyperscalers partagent des caractéristiques communes :

1. Elles ont commencé par les nouveaux projets. Plutôt que de migrer des applications existantes (complexe, risqué, coûteux), elles ont déployé les nouveaux projets directement chez des fournisseurs européens. Avec le temps, l’équilibre a basculé.

2. Elles ont évité les services propriétaires. Les organisations qui ont construit sur Kubernetes, PostgreSQL et un stockage objet compatible S3 (tous disponibles chez des fournisseurs européens) ont trouvé la migration simple. Celles construites sur Lambda et DynamoDB ont constaté le contraire.

3. Elles ont accepté l’hybride. La plupart des migrations réussies n’aboutissent pas à un hébergement 100 % européen. Certains services — en particulier les API d’IA et le CDN mondial — peuvent rester chez les hyperscalers, tandis que les données et le calcul de base migrent vers l’infrastructure européenne. Une stratégie hybride consciente — avec des critères clairs sur ce qui reste et ce qui migre — est plus durable qu’une approche du tout ou rien.

4. Elles ont investi dans les opérations. Les fournisseurs européens offrent moins d’accompagnement. Les organisations ont besoin d’expertise interne ou externalisée pour le déploiement, la supervision et la réponse aux incidents. Le coût total de possession inclut les personnes, pas seulement les serveurs.

5. Elles ont utilisé des standards ouverts. Kubernetes, API compatibles S3, PostgreSQL, OpenStack — plus la pile est standard, plus la migration est facile. La dépendance propriétaire n’est pas un problème de cloud ; c’est un choix d’architecture.

Ce qui reste

La souveraineté cloud européenne n’est pas un problème technologique. Les fournisseurs européens offrent une infrastructure compétitive. SCS a démontré que des piles cloud interopérables et souveraines fonctionnent. L’avantage tarifaire des fournisseurs européens est réel et substantiel.

Deux échéances réglementaires créent une fenêtre d’action concrète. Le Data Act est applicable depuis septembre 2025, obligeant les fournisseurs cloud à supporter la portabilité des données. À partir de janvier 2027, les frais de changement doivent être entièrement éliminés. Pour la première fois, les barrières économiques érigées par les hyperscalers autour de leurs plateformes sont démantelées par la réglementation.

Si vous exploitez des charges de travail sur un hyperscaler américain et envisagez des alternatives, les schémas ci-dessus indiquent une séquence claire :

Commencer maintenant :

• Déployer toutes les nouvelles charges de travail chez des fournisseurs européens. Les nouveaux projets n’ont aucun coût de migration. Un cluster Kubernetes chez Hetzner ou Scaleway coûte une fraction de l’équivalent AWS — et vous évitez de construire un nouveau lock-in.
• Auditer votre pile existante pour les dépendances propriétaires. À quel point êtes-vous ancré dans Lambda, DynamoDB ou des services spécifiques Azure ? La réponse détermine la complexité et le calendrier de votre migration. Cet audit prend des jours, pas des mois.

Avant janvier 2027 (Data Act : élimination des frais de changement) :

• Planifier la migration des charges de travail à frais de sortie élevés. Lorsque le Data Act éliminera entièrement les frais de changement, le coût du transfert de volumes importants de données hors des hyperscalers baissera considérablement. Utilisez le temps restant pour préparer : identifier ce qui migre, tester l’environnement cible, former l’équipe.
• Négocier votre prochain contrat cloud avec une clause de sortie. Si votre Enterprise Agreement est renouvelé avant 2027, assurez-vous qu’il inclut des dispositions de portabilité conformes aux exigences du Data Act.

Accepter et piloter :

• L’hybride n’est pas un échec. Les API d’IA, le CDN mondial et les services managés de niche peuvent rester chez les hyperscalers tandis que les données et le calcul de base migrent vers l’infrastructure européenne. L’objectif est le choix conscient, pas la pureté dogmatique. Pour un cadre structuré sur ce qu’il faut contrôler et ce qu’il faut louer, voir Les limites de l’indépendance numérique.

Le coût de l’inaction : Si vous exécutez des charges de travail d’infrastructure standard (calcul, stockage, bases de données) sur AWS ou Azure, les fournisseurs européens offrent la même chose à 3 à 5 fois moins cher. Pour un déploiement typique de 50 serveurs, ce sont des dizaines de milliers d’euros par an de dépenses inutiles — de l’argent qui pourrait financer l’expertise opérationnelle nécessaire à une infrastructure souveraine. Chaque année de retard approfondit le lock-in et augmente les coûts.

Sources

• Parts de marché du cloud européen (Synergy Research, cité dans le rapport du PE)
• Europe votes to tackle deep dependence on US tech (Computerworld, 2026)
• Qualification SecNumCloud (ANSSI/cyber.gouv.fr)
• Gaia-X — À propos (officiel)
• Pérennité du Sovereign Cloud Stack (SCS)
• Incendie du centre de données OVHcloud à Strasbourg (Wikipédia)
• Bleu — cloud souverain pour la France (coentreprise Orange/Capgemini, domaine inactif)
• Delos Cloud — Microsoft 365 souverain pour l’Allemagne (SAP/Arvato)
• Le Danemark abandonne Microsoft (annonce du gouvernement danois, 2025)
• Data Act de l’UE (EUR-Lex)
• Texte intégral du CLOUD Act (Congress.gov)
• Serveurs dédiés Hetzner — tarifs

Aperçu du thème : Infrastructure Cloud