RGPD et résidence des données sur AWS : pourquoi eu-west-3 ne suffit pas toujours

« On héberge sur eu-west-3, à Paris, donc on est conformes RGPD » : c’est la phrase qu’on entend le plus souvent en début d’audit, et elle est à la fois vraie et incomplète. Vraie parce que la région Paris respecte les exigences de résidence des données du RGPD. Incomplète parce que la résidence des données et la souveraineté juridique sont deux choses différentes — et la confusion entre les deux devient un vrai sujet commercial depuis le lancement, le 15 janvier 2026, de l’AWS European Sovereign Cloud.

Cet article fait le point sur ce que couvre réellement eu-west-3, ce qu’apporte (et n’apporte pas) le nouveau cloud souverain d’AWS, où se situe SecNumCloud dans cette hiérarchie, et surtout : qui, parmi les PME, a vraiment besoin de regarder au-delà de la région Paris.

eu-west-3 : ce que ça couvre, et ce que ça ne couvre pas

La région AWS Paris (eu-west-3), opérationnelle depuis fin 2017 avec trois zones de disponibilité, héberge vos données physiquement en Île-de-France si vous n’activez aucune réplication cross-région. Ça répond à l’exigence RGPD de traitement au sein de l’UE, et AWS est certifié au Data Privacy Framework (DPF) UE-US adopté en juillet 2023, qui encadre juridiquement les rares flux transatlantiques (support technique, facturation).

Ce que ça ne règle pas : AWS reste une société de droit américain, soumise au CLOUD Act (2018), qui autorise la justice américaine à exiger l’accès à des données hébergées par une entreprise américaine — y compris quand ces données sont stockées physiquement en France. Le DPF protège juridiquement les transferts de données personnelles vers les États-Unis, mais ne neutralise pas le CLOUD Act pour les données hébergées en UE par une filiale d’un groupe américain. Le Comité européen de la protection des données (CEPD) l’a rappelé à plusieurs reprises : résidence géographique et immunité juridictionnelle ne sont pas la même garantie.

Pour l’écrasante majorité des PME B2B, ça reste un niveau de risque acceptable — la probabilité qu’une réquisition CLOUD Act cible spécifiquement une PME française sans lien avec les États-Unis est faible, et la CNIL ne l’exige pas comme critère de conformité RGPD de base. Mais deux catégories d’entreprises n’ont plus le luxe de l’ignorer : celles qui traitent des données de santé ou de défense sensibles, et celles qui répondent à des marchés publics ou des appels d’offres exigeant contractuellement une garantie de souveraineté.

Le nouveau venu : AWS European Sovereign Cloud

AWS a lancé le 15 janvier 2026 l’AWS European Sovereign Cloud (ESC), une infrastructure « physiquement et logiquement séparée » des régions AWS classiques. Sa première région, eusc-de-east-1, est située en Brandebourg (Allemagne), avec deux zones de disponibilité à l’ouverture.

Ce qui change réellement par rapport à eu-west-3 :

• Entité juridique dédiée. L’ESC est opéré par une nouvelle société de droit allemand (GmbH), avec trois filiales locales, dirigée par des citoyens européens (Stéphane Israël en tête d’exploitation, Stefan Höchbauer comme managing director), et supervisée par un conseil consultatif incluant deux membres indépendants européens.
• Personnel exclusivement européen. Seuls des résidents UE peuvent opérer l’infrastructure et accéder aux répliques de code source pour la maintenance exceptionnelle — sans dépendance critique vis-à-vis d’infrastructures non-UE.
• Continuité même en cas de rupture de communication avec le reste du monde, selon AWS — un scénario pensé pour les administrations et les OIV (opérateurs d’importance vitale).
• Investissement massif annoncé : 7,8 Md€ en Allemagne, environ 2 800 emplois ETP, et une extension de “Local Zones souveraines” vers la Belgique, les Pays-Bas et le Portugal.

Mais l’ESC reste une filiale d’Amazon, avec une chaîne de contrôle capitalistique qui remonte in fine aux États-Unis — ce qui, selon la plupart des analyses juridiques publiées depuis le lancement, ne suffit pas à neutraliser complètement l’exposition CLOUD Act au sens strict. C’est une avancée réelle en gouvernance et en résidence, pas une immunité totale.

L’autre limite, très concrète pour une PME qui évaluerait la migration : le catalogue de services est encore restreint. À date, l’ESC propose environ 90 services contre 240+ sur les régions commerciales standard. Manquent notamment : les instances GPU (aucune, ce qui exclut de facto l’entraînement ou l’inférence IA lourde), IAM Identity Center (prévu Q1 2026), CloudFront (prévu fin 2026), CodeDeploy (Q2 2026), et la chaîne CodeCommit/CodeBuild/CodePipeline (Q1 2027). Bedrock est disponible mais limité aux modèles Amazon Nova Lite et Nova Pro, sans RAG managé ni fine-tuning à date. Il n’y a pas de Free Tier, et le surcoût constaté sur les services communs tourne autour de 10 à 15 % par rapport à eu-central-1 (Francfort).

SecNumCloud : le vrai plancher souveraineté

Si votre exigence est la souveraineté au sens strict — immunité contre le droit extraterritorial, pas seulement résidence UE — le référentiel qui compte en France est SecNumCloud, la qualification de l’ANSSI. Elle impose notamment que le capital du prestataire soit majoritairement détenu par des acteurs européens, ce qui exclut de fait les filiales de groupes américains, ESC compris. En 2026, seuls trois fournisseurs sont qualifiés SecNumCloud pour des offres cloud public généralistes : OVHcloud, 3DS Outscale et Cloud Temple.

Le prix à payer : un catalogue de services encore plus restreint que l’ESC, un écosystème d’outillage et de compétences plus étroit que celui d’AWS, et pour beaucoup de PME, une migration ou une architecture hybride qui coûte plus cher à construire et à maintenir que ce que la conformité réelle exige. SecNumCloud n’est obligatoire que pour certains OIV/OSE (opérateurs d’importance vitale / de services essentiels) et pour des marchés publics qui l’exigent explicitement dans leur cahier des charges — pas pour une PME B2B standard, même en traitant des données de santé au sens large (voir la distinction avec l’hébergement de données de santé HDS, qui a son propre référentiel, moins strict que SecNumCloud).

La grille de décision pour une PME

Trois questions suffisent, dans l’ordre :

1. Un texte contractuel ou réglementaire vous impose-t-il explicitement SecNumCloud ou une clause d’immunité CLOUD Act ? Marché public avec cette clause, statut OIV/OSE notifié par l’ANSSI, exigence contractuelle d’un grand donneur d’ordre public. Si oui → SecNumCloud, et c’est un chantier d’architecture à part entière, pas un choix de région.
2. Traitez-vous des données dont la sensibilité justifie une gouvernance renforcée sans aller jusqu’à l’obligation réglementaire ? Données de santé à grande échelle, données régaliennes, secteurs sensibles (défense, énergie critique). Si oui → évaluez l’ESC, en acceptant le surcoût de 10-15 % et le catalogue de services réduit — et vérifiez service par service que ce dont vous avez besoin (GPU, CloudFront, CI/CD managé) y est déjà disponible avant de vous engager.
3. Aucune des deux ne s’applique ? C’est le cas de la grande majorité des PME B2B, SaaS et e-commerce que nous auditons. eu-west-3 + chiffrement côté client + Data Privacy Framework reste le bon compromis coût/conformité. Ajouter une couche de souveraineté sans obligation réelle, c’est payer un surcoût récurrent et une complexité opérationnelle pour un risque résiduel que ni la CNIL ni vos clients ne vous demandent de couvrir.

Un point souvent oublié dans cette réflexion : le chiffrement géré côté client (KMS avec clés que vous contrôlez, ou chiffrement applicatif avant écriture) réduit l’exposition réelle bien plus efficacement, et à coût quasi nul, qu’un changement de région. Une réquisition CLOUD Act qui obtient des données chiffrées sans les clés n’obtient rien d’exploitable.

Ce qu’on recommande concrètement

• Documentez la distinction résidence/souveraineté dans votre registre de traitement RGPD. Beaucoup d’audits CNIL ou de due diligence client posent la question explicitement depuis le lancement médiatisé de l’ESC — mieux vaut avoir la réponse écrite que de l’improviser.
• Chiffrez côté client les données réellement sensibles, indépendamment de la région choisie — c’est la mesure avec le meilleur ratio protection/coût.
• Ne migrez pas vers l’ESC par précaution. Le catalogue de services incomplet (pas de GPU, pas de CloudFront avant fin 2026) rend une migration prématurée coûteuse en complexité pour un bénéfice juridique partiel.
• Si un appel d’offres exige SecNumCloud, chiffrez le sujet dès la phase de réponse, pas après : une architecture hybride AWS + SecNumCloud pour isoler uniquement les données réglementées est souvent plus réaliste qu’une migration complète.

Notre audit Architecture & DevSecOps inclut systématiquement une revue de la cartographie de résidence et d’exposition réglementaire de vos données — utile avant de répondre à un appel d’offres ou de trancher sur une extension européenne.

Conclusion

Le lancement de l’AWS European Sovereign Cloud change la conversation sur la souveraineté cloud en Europe, mais il ne change pas le calcul pour la plupart des PME : eu-west-3 reste conforme RGPD, le CLOUD Act reste un risque théorique pour une entreprise sans lien direct avec les États-Unis, et SecNumCloud reste réservé à un périmètre réglementaire précis. La vraie question à se poser n’est pas « faut-il migrer vers du souverain », mais « qu’est-ce qui, dans mes données, justifierait de payer le surcoût et la complexité d’en sortir » — et pour l’immense majorité, la réponse tient en une ligne : rien, tant que le chiffrement côté client est en place.