Résidence vs souveraineté des données : ce que les acheteurs SaaS de l'UE confondent

Résidence vs souveraineté des données : ce que les acheteurs SaaS de l'UE confondent

Lorsqu'on évalue un fournisseur SaaS, « hébergé en UE » a quelque chose de rassurant. Les données restent en Europe. RGPD-compatible. Case cochée.

Ce n'est pas si simple. La plupart des fournisseurs vous vendent une résidence des données, alors que ce qu'il vous faut est une souveraineté des données. La distinction n'a rien d'académique. Sous le CLOUD Act, l'article 48 du RGPD, l'EU Data Act (chapitre VII) et l'environnement réglementaire post-Schrems II, les confondre est une erreur de qualification achat.

Points clés

• Résidence des données = où sont les bits. Souveraineté des données = quelle loi régit leur accès.
• Un fournisseur incorporé aux États-Unis est soumis au CLOUD Act, même si les données sont physiquement à Francfort ou à Dublin.
• L'article 48 du RGPD interdit la transmission de données personnelles à des autorités hors-UE sans accord international, plaçant les clients européens des éditeurs américains en conflit structurel permanent.
• L'EU Data Act, chapitre VII, s'applique depuis le 12 septembre 2025 et oblige les fournisseurs cloud et de traitement de données opérant dans l'UE à contester toute demande d'accès non-UE illicite.
• Pour les entités essentielles NIS2, les entités financières DORA et les secteurs régulés au Royaume-Uni et en Norvège, cette distinction est désormais un critère de sélection fournisseur.

Quelle est la différence ?

La résidence des données est l'emplacement géographique du stockage. C'est une question de fait : quel data center, quelle région, quel pays.

La souveraineté des données est l'autorité juridique qui régit ces données. C'est une question de juridiction : quels tribunaux peuvent émettre des injonctions, quel droit s'applique, quel gouvernement peut imposer la divulgation.

Résidence sans souveraineté est possible. Une société incorporée aux États-Unis exploitant des centres de données européens fournit la résidence. En tant qu'entité juridique américaine, elle reste sous droit américain — y compris le CLOUD Act.

Souveraineté sans résidence ne l'est pas. Mais la résidence à elle seule ne suffit pas.¹

Le problème CLOUD Act

Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) autorise les autorités américaines à exiger des fournisseurs incorporés aux États-Unis la production de données en leur « possession, garde ou contrôle » — peu importe où elles sont physiquement stockées.² Concrètement, un mandat américain peut atteindre un data center à Dublin, parfois assorti d'un gag order.

Cela crée un conflit direct avec le Règlement général sur la protection des données :

• Article 48 du RGPD : tout transfert de données personnelles à une autorité d'un pays tiers fondé sur une décision judiciaire ou administrative étrangère ne peut être reconnu ou exécutoire que sur la base d'un accord international (par exemple un MLAT). Le CLOUD Act n'est pas un tel accord.³
• Schrems II (affaire C-311/18, juillet 2020) : la CJUE a invalidé le Privacy Shield UE-US précisément parce que la législation américaine de surveillance donnait aux autorités américaines accès aux données personnelles européennes d'une manière incompatible avec le RGPD.⁴ La CJUE a établi que la localisation géographique ne remplace pas le contrôle juridictionnel.

Le CEPD a souligné à plusieurs reprises ce risque structurel. Un fournisseur tiraillé entre droit américain et droit européen ne peut pas livrer une réponse propre à vos clients.

« Sovereign cloud » n'est pas toujours souverain

Les fournisseurs américains ont compris la demande. Beaucoup commercialisent désormais des offres « sovereign cloud » ou « EU data residency ». Ajouter des serveurs européens à une société américaine ne change pas la question juridictionnelle — le CLOUD Act s'applique toujours.

Le Data Privacy Framework UE-US de 2023 devait aider, mais deux mécanismes antérieurs (Safe Harbor, Privacy Shield) sont déjà tombés. Bâtir une stratégie de souveraineté de long terme sur un troisième mécanisme « la prochaine sera la bonne » est fragile par construction.⁵

L'EU Data Act resserre la vis

Le développement structurant de 2025 est l'EU Data Act (Règlement (UE) 2023/2854).⁶ Le chapitre VII, applicable depuis le 12 septembre 2025, oblige les fournisseurs cloud et de traitement de données opérant dans l'UE à :

• mettre en œuvre des mesures techniques, juridiques et organisationnelles pour empêcher l'accès illicite par des autorités hors-UE aux données non personnelles détenues dans l'UE,
• contester les demandes d'accès non-UE qui entrent en conflit avec le droit de l'UE,
• documenter ces mesures et les rendre disponibles aux clients et aux régulateurs.

C'est, à ce jour, la réponse européenne la plus directe au CLOUD Act. Pour un fournisseur incorporé aux États-Unis opérant dans l'UE, respecter à la fois les assignations CLOUD Act et le chapitre VII du Data Act est structurellement difficile — l'éditeur est désormais juridiquement tenu de contester l'ordonnance américaine plutôt que de coopérer en silence.

Votre fournisseur peut être européen — pas son infrastructure

C'est là que beaucoup d'acheteurs trébuchent. De nombreux SaaS incorporés en Europe tournent sur AWS, Azure ou Google Cloud. D'autres dépendent de sous-traitants américains pour l'analytics, le support ou les intégrations.

Si vos données touchent une entité sous contrôle américain dans la chaîne — infrastructure principale, outillage de support, journalisation, inférence IA — la même question CLOUD Act s'applique à ce maillon. La liste des sous-traitants en dit plus long sur la posture de souveraineté que la page d'accueil. L'article 28 du RGPD fait de cette liste une obligation contractuelle, pas une politesse.⁷

Pour les plateformes Trust Center, c'est encore plus structurant. Voir Trust Center : souveraineté des données — hébergement UE vs souveraineté UE.

Hébergement UE par défaut, ou « réservé enterprise » ?

Vérifiez. De nombreux éditeurs américains traitent la résidence des données comme un add-on premium. Si vous devez parler au commercial pour savoir où vivent vos données, cela en dit long sur la centralité réelle de l'UE dans le design du produit. Souveraineté UE en upsell enterprise = pas de souveraineté UE — résidence UE sur demande.

Et le Royaume-Uni et la Norvège ?

La conformité européenne dépasse l'UE.

• Royaume-Uni. Le UK GDPR a été conservé après le Brexit et reflète largement les articles 44 à 50 du RGPD. Le Data Protection Act 2018 renforce les obligations de transfert ; l'Information Commissioner's Office (ICO) publie ses propres lignes directrices sur les transferts internationaux. Le Cyber Security and Resilience Bill, déposé au Parlement le 12 novembre 2025 et en cours d'examen en 2026, étendrait des obligations type NIS aux managed service providers et aux fournisseurs critiques, relevant encore le niveau d'exigence côté chaîne d'approvisionnement.⁸⁹
• Norvège / EEE. La Norvège applique le RGPD via l'accord EEE, avec Datatilsynet comme autorité de protection des données et Nasjonal sikkerhetsmyndighet (NSM) pour la cybersécurité. Les acheteurs publics norvégiens et les secteurs régulés examinent de plus en plus l'exposition aux fournisseurs américains après Schrems II ; les lignes directrices de Datatilsynet sur Google Analytics en sont un exemple concret.¹⁰

Si un fournisseur ne traite pas distinctement les questions UK et Norvège, c'est un angle mort paneuropéen.

Les questions à poser à un fournisseur

Si la souveraineté compte pour votre cas d'usage :

• Où le fournisseur est-il incorporé ? Pas le « based in » marketing — l'entité juridique réelle.
• Qui sont les sous-traitants et où sont-ils incorporés ? Liste publique idéalement.
• L'hébergement UE est-il par défaut, ou en surcoût ?
• Qui détient les clés de chiffrement ? Si le client les détient, le fournisseur ne peut pas livrer des données lisibles, même sous contrainte.
• Le fournisseur publie-t-il un transparency report ? Demandes des autorités, refus, issues documentées.
• Quel est le processus déclaré sous l'EU Data Act, chapitre VII ? Le fournisseur contestera-t-il une assignation CLOUD Act sur des données de clients UE ?

Tout n'exige pas ce niveau de scrutin

Pour un site marketing ou une landing page publique, le risque est faible. Choisissez l'outil le plus simple et avancez.

Pour des données client sensibles, des secteurs régulés (finance sous DORA, entités essentielles sous NIS2, secteur public, santé) ou des positions de fournisseur d'enregistrement dans la conformité d'un autre — les questions pèsent davantage. La résidence est une case à cocher. La souveraineté demande du travail.

Quand vous publiez à grande échelle des preuves de sécurité et de conformité, la plateforme retenue pour votre Trust Center porte cette exposition pour le compte de vos clients. C'est l'une des raisons pour lesquelles les plateformes Trust Center construites en Europe — voir notre Logiciel Trust Center : guide complet 2026 et Pourquoi les entreprises européennes ont besoin d'un Trust Center européen — sont aujourd'hui un choix d'achat sérieux, et non une préférence nationaliste.

---

Sources & références

---

À lire aussi

• Trust Center : souveraineté des données — hébergement UE vs souveraineté UE
• RGPD articles 28, 32, 33 et 34
• Alternative à SafeBase pour entreprises UE
• Meilleurs Trust Centers en 2026
• Logiciel Trust Center : le guide complet pour 2026
• Glossaire souveraineté des données

Footnotes

1. IBM. "Data Sovereignty vs. Data Residency". ↩

2. US CLOUD Act (H.R. 4943). Congress.gov. ↩

3. RGPD article 48. EUR-Lex. ↩

4. CJUE, arrêt dans l'affaire C-311/18 (Schrems II), 16 juillet 2020. CURIA. ↩

5. Orrick. "Data Localization and the Sovereign Cloud: EU Cloud Regulations Explained" (janvier 2026). ↩

6. Règlement (UE) 2023/2854 (Data Act). EUR-Lex. Chapitre VII applicable depuis le 12 septembre 2025. ↩

7. RGPD article 28. EUR-Lex. ↩

8. UK Information Commissioner's Office. "International data transfers". ↩

9. UK Department for Science, Innovation and Technology. "Cyber Security and Resilience Bill". ↩

10. Datatilsynet. "Google Analytics kan være ulovlig" (2022). ↩