AWS, GCP, Azure en région UE : sont-ils vraiment à l’abri du CLOUD Act ?
Non. Choisir une région AWS eu-west-1, une région Google Cloud europe-west1 ou une région Azure France Centre change la localisation physique des serveurs, pas la nationalité de la société qui les exploite. AWS, Google Cloud et Microsoft Azure restent des filiales de sociétés de droit américain : Amazon.com Inc., Alphabet Inc. et Microsoft Corporation. Le CLOUD Act s’applique à l’entreprise, pas au datacenter.
Les trois ont pourtant lancé, ces dernières années, des programmes de souveraineté distincts. AWS a lancé l’European Sovereign Cloud, Google Cloud des contrôles d’accès et des partenariats locaux, Microsoft l’engagement EU Data Boundary. Ce comparatif détaille ce que chacun couvre réellement, et ce qu’aucun des trois ne change à lui seul. Le sujet pèse peu pour un projet sans donnée sensible. Il devient déterminant dès qu’un DPO, une donnée de santé ou un marché public européen entre dans l’équation, un point de bascule déjà détaillé dans notre grille de décision sur le choix d’un BaaS.
- Le CLOUD Act s’applique à la nationalité de la société exploitante, pas à la région du datacenter : une donnée hébergée en UE par une société américaine reste, en théorie, accessible sur requête du droit américain.
- AWS a lancé l’European Sovereign Cloud (gouvernance et personnel opérationnel basés en UE, première région en Allemagne) mais reste une offre d’Amazon.com Inc.
- Microsoft applique un engagement EU Data Boundary qui limite le traitement des données de ses principaux services cloud au territoire européen, sans changer la nationalité de Microsoft Corporation.
- Google Cloud propose des contrôles de souveraineté (chiffrement côté client, Key Access Justifications) et des partenariats locaux, sous la même réserve : Google LLC reste une filiale d’Alphabet Inc.
- Aucune des trois initiatives ne crée, à ce jour, une société exploitante totalement indépendante d’un actionnariat américain, à la différence d’un fournisseur dont la société mère est elle-même de droit européen.
Pourquoi une région serveur ne suffit pas : rappel en bref
Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) autorise les autorités fédérales américaines à requérir des données détenues ou contrôlées par une société soumise à leur juridiction, où que ces données soient stockées physiquement. La loi cible l’entreprise, pas le pays du datacenter.
Une filiale européenne d’un groupe américain reste, en dernier ressort, sous le contrôle capitalistique de sa société mère. C’est ce lien de contrôle qui déclenche l’exposition théorique, pas l’adresse du datacenter choisi dans la console.
Le détail du texte et son articulation avec le RGPD sont couverts dans notre guide Backend conforme RGPD et souverain UE, et l’effet précis de la nationalité d’un fournisseur dans notre article nationalité du fournisseur et exposition CLOUD Act. Cette section se limite à ce qui distingue les trois hyperscalers étudiés ici.
AWS : régions européennes et l’European Sovereign Cloud
AWS opère plusieurs régions dans l’Union européenne, dont l’Irlande (eu-west-1), Francfort (eu-central-1) et Paris (eu-west-3). Chacune répond à des exigences de latence et de résidence des données, sans changer l’entité juridique qui signe le contrat.
Fin 2023, AWS a annoncé l’European Sovereign Cloud, une infrastructure distincte pensée pour une gouvernance opérationnelle basée en UE : personnel et prise de décision opérationnelle localisés en Europe, première région prévue dans le Brandebourg, en Allemagne. Le programme répond directement aux exigences exprimées par des clients publics et des secteurs réglementés.
Cette gouvernance opérationnelle ne change pas la structure actionnariale. L’European Sovereign Cloud reste une offre d’Amazon Web Services, Inc., filiale d’Amazon.com Inc., société de droit américain. L’exposition CLOUD Act se rattache à ce lien de contrôle, indépendamment de l’indépendance opérationnelle revendiquée.
Google Cloud : contrôles de souveraineté et partenariats locaux
Google Cloud propose des régions européennes à Bruxelles (europe-west1), Francfort (europe-west3) et dans plusieurs autres villes du continent. Son approche de souveraineté repose moins sur une entité juridique distincte que sur des contrôles techniques appliqués au niveau de la donnée.
Deux mécanismes concrets illustrent cette approche. Le chiffrement côté client fait en sorte que les données soient chiffrées avant d’atteindre l’infrastructure Google, sans que Google ne détienne les clés. Les Key Access Justifications affichent au client chaque demande d’accès à ses données, y compris une demande gouvernementale, avant qu’elle ne soit honorée.
Google Cloud a aussi noué des partenariats locaux, comme la coentreprise S3NS avec Thales en France, pour proposer une offre de cloud de confiance évaluée selon des référentiels de sécurité nationaux. L’infrastructure sous-jacente reste néanmoins opérée par Google LLC, filiale d’Alphabet Inc., société de droit américain : le même lien de contrôle capitalistique s’applique.
Azure : régions UE et l’engagement EU Data Boundary
Microsoft Azure propose de nombreuses régions européennes : France Centre, Germany West Central, West Europe (Pays-Bas) et North Europe (Irlande). Le choix d’une région Azure UE répond avant tout à des exigences de latence et de résidence contractuelle des données.
Depuis 2021, Microsoft déploie par phases un engagement appelé EU Data Boundary : les données traitées par ses principaux services cloud, Azure, Microsoft 365, Dynamics 365 et Power Platform, sont stockées et traitées dans le périmètre européen. L’objectif affiché est de réduire les transferts hors UE devenus superflus, pas de créer une entité juridique distincte de Microsoft Corporation.
Microsoft publie par ailleurs un rapport de transparence détaillant le volume de demandes gouvernementales reçues et la part à laquelle l’entreprise a donné suite. Cette transparence documente l’exposition réelle sans pour autant l’éliminer : Microsoft Corporation demeure une société de droit américain, quel que soit le lieu de stockage des données.
Comparatif : régions UE, initiative de souveraineté, société mère
Trois colonnes de faits, une seule constante : la nationalité de la société exploitante ne change pas d’un hyperscaler à l’autre, quel que soit le sérieux du programme de souveraineté associé.
Les trois lignes de la colonne « nationalité » sont identiques. C’est précisément le point que ce comparatif documente : un programme de souveraineté ne modifie pas cette colonne.
Ce que ces initiatives améliorent, et ce qu’elles ne changent pas
Ces trois programmes améliorent des choses réelles : résidence des données, transparence des accès, réduction de transferts hors UE devenus inutiles, et pour AWS, une gouvernance opérationnelle assurée par du personnel basé en Europe. Ce sont des progrès mesurables, pas des effets d’annonce vides.
Aucun des trois ne change en revanche le lien de contrôle actionnarial entre la filiale ou la division européenne et sa société mère américaine. Une demande adressée à la société mère, ou qu’elle peut contraindre sa filiale à satisfaire, reste, en théorie juridique, exécutoire indépendamment de l’indépendance opérationnelle affichée.
Que vérifier avant de s’appuyer sur un programme de souveraineté hyperscaler
Quatre questions à poser avant de considérer un programme de souveraineté hyperscaler comme suffisant pour un projet sensible.
- Le contrat que vous signez est-il rattaché à l’entité du programme de souveraineté, ou reste-t-il rattaché à l’entité américaine standard du fournisseur ?
- Le programme couvre-t-il précisément les services que vous utilisez (calcul, stockage, base de données managée), ou seulement une partie du catalogue ?
- Le fournisseur documente-t-il publiquement sa position sur le CLOUD Act, pas seulement sur le RGPD ?
- Une clause contractuelle existe-t-elle sur le traitement des demandes gouvernementales : notification, contestation, transparence ?
L’autre option : une société mère elle-même sous juridiction UE
Une approche structurellement différente consiste à choisir un fournisseur dont la société mère est elle-même incorporée sous juridiction UE, ce qui supprime le lien de contrôle vers une société américaine plutôt que de l’encadrer.
C’est le cas d’Aurabase SAS, société de droit français, dont l’infrastructure de production vérifiée tourne en Allemagne et en Finlande. La souveraineté UE tient à ces deux conditions cumulatives, l’hébergement et la société exploitante, plutôt qu’à l’une des deux seules. Le détail technique et juridique de ce comparatif face à un fournisseur comparable est couvert dans Aurabase vs Supabase, et la posture de conformité complète sur le centre de conformité Aurabase.
FAQ
AWS, Google Cloud et Microsoft Azure ont chacun investi dans une réponse sérieuse à la question de la souveraineté : gouvernance opérationnelle en UE chez AWS, contrôles d’accès et partenariats locaux chez Google Cloud, engagement de résidence des données chez Microsoft. Aucun des trois ne change la case qui compte le plus sur un contrat : la nationalité de la société qui le signe.
Pour un projet sans donnée sensible, ce distinguo reste secondaire. Pour un DPO, une donnée de santé ou un marché public UE, il mérite d’être vérifié avant la signature, pas après.
Pour la grille de décision complète appliquée au choix d’un BaaS, voir pourquoi le CLOUD Act change le choix de votre BaaS. Pour le détail de ce qui différencie juridiquement un fournisseur selon la nationalité de sa société mère, voir nationalité du fournisseur et exposition CLOUD Act.