AWS a lancé son European Sovereign Cloud (ESC) en janvier 2026, et c'est une initiative significative. Contrairement aux régions AWS standard qui opèrent sous un plan de contrôle global, l'ESC adopte un modèle de « partition indépendante ». Concrètement, cela signifie que l'ESC dispose de sa propre pile IAM et de facturation distincte, et, surtout, qu'il est entièrement exploité par des résidents de l'UE. Ce niveau de séparation opérationnelle est conçu pour répondre aux préoccupations concernant la juridiction non-européenne sur le plan de contrôle, offrant aux clients une visibilité plus claire sur qui peut accéder et gérer leurs ressources.

L'approche de Microsoft inclut des concepts tels que les rôles de « Data Guardian » et les régions Azure Local. Le « Data Guardian » est un rôle fascinant : ce sont des personnels basés en Europe qui doivent approuver physiquement toute demande d'accès à distance formulée par des ingénieurs basés aux États-Unis pour le support. Imaginez le processus : un ingénieur basé aux États-Unis a besoin de résoudre un problème, mais au lieu d'un accès direct, un Data Guardian européen agit comme un gardien, assurant le respect des réglementations locales. Cela introduit un disjoncteur contrôlé par l'homme pour l'accès transjuridictionnel, ce que je considère comme une étape importante vers l'atténuation de la portée juridique extraterritoriale.

Pour ceux qui recherchent le plus haut niveau d'isolation, Google Distributed Cloud (GDC) dans son mode « déconnecté » ou « air-gapped » représente ce que je considère comme l'étalon-or de la « souveraineté tactique ». Avec GDC, vous pouvez déployer un environnement Google Cloud complet entièrement sur site, isolé du cloud public de Google. Dans sa configuration air-gapped, ce cloud fonctionne sans aucune connexion à l'internet public ou au plan de contrôle américain de Google. Cela signifie que les mises à jour, les correctifs et la gestion doivent être gérés localement, souvent via des supports physiques. Cela représente une surcharge opérationnelle significative, mais pour les environnements avec des exigences de souveraineté extrêmes, comme certains cas d'utilisation gouvernementaux ou d'infrastructures critiques, cela coupe efficacement le cordon ombilical numérique avec les juridictions non-européennes.

Bien que ces solutions d'hyperscalers offrent des options convaincantes, leur architecture sous-jacente les lie toujours intrinsèquement à une entité mondiale. Cela m'amène à envisager des alternatives qui sont nativement juridictionnelles dès le départ.

OVHcloud, un leader industriel dont le siège est en France, en est un exemple. Leur sélection pour le projet Euro numérique de 2026 en dit long sur la confiance qu'ils ont bâtie. Ce que je trouve particulièrement intéressant chez OVHcloud, c'est leur modèle intégré : ils construisent leurs propres serveurs, exploitent leurs propres centres de données et développent leur propre pile logicielle. Cela offre une souveraineté « du matériel à l'hyperviseur » que je crois que les entreprises basées aux États-Unis, en raison de leur empreinte opérationnelle mondiale, ne peuvent pas vraiment égaler. Il s'agit de posséder toute la chaîne d'approvisionnement, du silicium à l'API.

En Allemagne, T-Systems, une filiale de Deutsche Telekom, s'est associée à Broadcom (VMware) pour proposer une « pile souveraine gérée ». Cette initiative vise particulièrement le Mittelstand (petites et moyennes entreprises) allemand et le secteur public, en offrant une expérience de cloud privé basée sur VMware, entièrement gérée et exploitée selon la loi allemande. C'est un hybride intéressant, tirant parti d'une technologie de virtualisation mature mais l'enveloppant dans un cadre opérationnel et juridique souverain.

La France a vu l'émergence d'entités de « Cloud de confiance » telles que Bleu (une coentreprise entre Orange et Capgemini) et S3NS (Thales). Ces fournisseurs opèrent sur un modèle où ils exécutent des logiciels d'hyperscalers américains (comme Microsoft Azure ou Google Cloud) mais sur du matériel détenu, exploité et physiquement sécurisé localement en France, sous les lois française et européenne. L'idée est de se prémunir contre la portée du « Cloud Act » des sociétés mères américaines en s'assurant que l'infrastructure physique et le contrôle opérationnel sont entièrement au sein de l'UE. C'est un moyen pragmatique de tirer parti des capacités des hyperscalers tout en répondant aux préoccupations de souveraineté.

Enfin, des acteurs comme IONOS et Orange Business sont des contributeurs clés à des initiatives comme GAIA-X. GAIA-X vise à construire une infrastructure de données européenne fédérée, créant un écosystème de services cloud et de données sécurisés, fiables et souverains. Leur objectif est moins la souveraineté d'un seul fournisseur que la création d'un réseau interconnecté où la souveraineté des données est maintenue grâce à des normes communes, l'interopérabilité et une gouvernance transparente entre plusieurs entités européennes. Il s'agit de construire la prochaine génération d'infrastructure numérique véritablement européenne.

Comprendre le paysage des fournisseurs est une chose, mais comment, en tant qu'architectes, construisons-nous réellement pour ce niveau de souveraineté ? Plongeons dans quelques modèles techniques concrets que j'ai trouvés efficaces.

L'un des modèles les plus puissants que j'ai mis en œuvre pour la souveraineté des données est le « coffre-fort de chiffrement » utilisant la gestion externe des clés (EKM). Cela déplace le contrôle ultime des clés de chiffrement de vos données en dehors de la portée directe du fournisseur de cloud. Au lieu d'utiliser le système de gestion de clés (KMS) natif du fournisseur de cloud, je configure les services pour utiliser une solution EKM où les clés sont détenues par un fournisseur de module de sécurité matériel (HSM) européen tiers, tel que Thales ou Entrust.

Ce modèle signifie que même si le plan de contrôle d'un fournisseur de cloud était compromis, ou si une juridiction non-européenne émettait une demande de données, le fournisseur de cloud n'aurait accès qu'aux données chiffrées. Sans les clés externes, qui sont physiquement et logiquement contrôlées par une entité distincte et juridictionnellement différente, les données restent illisibles. Cela rend effectivement l'accès du fournisseur de cloud inutile pour l'exfiltration de données.

Comme je l'ai mentionné plus tôt, le simple fait de sélectionner une région européenne pour vos données ne suffit pas. L'isolation du plan de contrôle signifie passer activement des déploiements « régionaux » standard aux déploiements de « partition souveraine » plus avancés offerts par les hyperscalers ou, mieux encore, aux modèles opérationnels entièrement séparés des fournisseurs natifs régionaux. Cela implique de s'assurer que les API, les consoles de gestion et les couches d'orchestration sous-jacentes sont toutes confinées dans l'environnement souverain désigné. Lorsque je conçois des systèmes, j'examine méticuleusement les flux réseau, les points de terminaison d'API et les chemins d'accès administratifs pour m'assurer qu'aucun trafic de gestion critique ne quitte par inadvertance la frontière souveraine.

Pour une protection optimale des données, même pendant le traitement, je me tourne vers la souveraineté zéro confiance permise par l'informatique confidentielle. Des technologies comme Intel SGX (Software Guard Extensions) et AMD SEV (Secure Encrypted Virtualization) permettent de chiffrer les données non seulement au repos et en transit, mais aussi en mémoire pendant leur traitement. Cela crée un « environnement d'exécution de confiance » (TEE) qui protège les données et le code même de l'hyperviseur ou du système d'exploitation du fournisseur de cloud. Si je travaille avec des données très sensibles, ce modèle garantit que ni l'opérateur de cloud ni quiconque ayant un accès au niveau de l'hôte ne peut « voir » la charge de travail ou les données qu'elle traite. C'est une révolution pour les applications critiques où même une exposition temporaire de données non chiffrées est inacceptable.