Exigences de souveraineté des données dans l’UE : ce que le RGPD impose face aux véritables besoins en matière de souveraineté

Si vous interrogez la plupart des équipes en charge de conformité sur les exigences de souveraineté des données dans l’UE, elles vous parleront du RGPD. Si vous posez la question à leur service juridique sur les exigences de Schrems II, il vous parlera des analyses d’impact sur les transferts et des clauses contractuelles types. Demandez à leur RSSI ce qui se passe lorsqu’une assignation du gouvernement américain arrive au siège de leur fournisseur cloud, et la salle se tait.

Cette confusion est compréhensible. Les termes « résidence des données », « localisation des données » et « souveraineté des données » sont souvent employés de façon interchangeable dans les discussions d’entreprise — alors qu’ils sont distincts sur le plan juridique et architectural. Une organisation peut remplir toutes les obligations de résidence des données du RGPD sur le papier tout en restant structurellement exposée à l’accès d’un gouvernement étranger. Savoir où s’arrêtent les exigences du RGPD et où commence la véritable souveraineté des données n’est pas un simple débat théorique. C’est l’écart de conformité que les autorités de protection des données s’emploient désormais à combler.

Résumé Exécutif

Idée principale : Le RGPD définit des exigences de résidence et de transfert des données pour les données personnelles de l’UE — mais conformité RGPD et souveraineté des données ne sont pas synonymes. La résidence des données indique où les données doivent être stockées. La souveraineté détermine qui contrôle l’accès aux données et sous quelle juridiction légale. Pour les organisations utilisant une infrastructure cloud dont le siège est aux États-Unis, la résidence des données conforme au RGPD dans un centre de données à Francfort garantit la conformité géographique tout en laissant les données légalement accessibles aux demandes du gouvernement américain en vertu du CLOUD Act — une exposition structurelle que les clauses contractuelles types ne peuvent pas corriger. La conformité à la souveraineté des données exige des contrôles architecturaux — clés de chiffrement contrôlées par le client, déploiement européen à locataire unique, géorepérage appliqué par des règles — qui rendent l’accès non autorisé techniquement impossible, et non simplement interdit par contrat.

Pourquoi c’est important : Les autorités autrichiennes, françaises et italiennes de protection des données ont déjà jugé que certains accords cloud avec des fournisseurs américains enfreignent le RGPD. Les amendes RGPD peuvent atteindre 4 % du chiffre d’affaires mondial annuel. La directive NIS 2 ajoute la responsabilité pénale des dirigeants. Le rapport Kiteworks 2026 sur la sécurité des données et les risques de conformité révèle que 33 % des organisations ont connu un incident lié à la souveraineté au cours des 12 derniers mois, alors que 44 % se considèrent bien informées. Les organisations qui confondent résidence et souveraineté ne sont pas conformes — elles sont exposées.

Résumé des points clés

1. Résidence, localisation et souveraineté des données sont juridiquement distinctes. La résidence concerne l’endroit où les données sont physiquement stockées. La localisation exige qu’elles restent dans le pays de collecte. La souveraineté détermine qui contrôle l’accès et sous quelle juridiction légale. Remplir une exigence ne garantit pas la conformité aux autres.
2. Le RGPD définit des exigences de résidence, mais pas la souveraineté totale. Les articles 44 à 49 limitent les transferts de données à l’international — mais la conformité n’empêche pas une demande du CLOUD Act d’accéder à des données stockées par un fournisseur américain dans un centre de données européen. La localisation n’est pas la juridiction.
3. Schrems II a remis en cause la suffisance de la résidence. En imposant les analyses d’impact sur les transferts et en identifiant le chiffrement contrôlé par le client comme mesure complémentaire requise, la CJUE a établi que la localisation géographique ne peut pas se substituer au contrôle juridictionnel.
4. La souveraineté architecturale comble ce que les contrats ne peuvent pas. Les clauses contractuelles types lient les parties mais ne peuvent pas empêcher une demande légale du gouvernement américain. Des clés de chiffrement contrôlées par le client et stockées hors de l’infrastructure du fournisseur rendent ce dernier techniquement incapable de fournir des données lisibles, quelle que soit la demande légale reçue.
5. NIS 2 et DORA étendent les obligations de souveraineté au-delà du RGPD. La directive NIS 2 et DORA imposent des évaluations de souveraineté de la supply chain, des obligations de reporting et la responsabilité des dirigeants, qui s’ajoutent au RGPD. Les organisations des secteurs réglementés doivent se conformer simultanément à ces trois cadres.

Définitions : que signifient résidence, localisation et souveraineté des données ?

La résidence des données désigne le lieu géographique physique où les données sont stockées et traitées. Une exigence de résidence implique : ces données doivent être stockées sur des serveurs situés dans cette juridiction. Le RGPD crée de fait des exigences de résidence via ses restrictions de transfert — en limitant la circulation des données personnelles, il pousse les organisations à conserver les données dans l’UE. Mais la résidence est une question de localisation, pas de contrôle. Les données peuvent être physiquement stockées en Allemagne tout en restant légalement accessibles à un gouvernement étranger.

La localisation des données est une version plus stricte de la résidence : elle impose que les données soient non seulement stockées localement, mais qu’elles restent dans le pays où elles ont été collectées. Certaines réglementations nationales et sectorielles au sein de l’UE imposent des exigences de localisation en plus du RGPD — notamment pour les données de santé, les transactions financières et les archives du secteur public.

La souveraineté des données est le concept le plus large. Elle repose sur le principe que les données sont régies par les lois de la juridiction où elles résident — et que l’organisation détentrice dispose d’un contrôle légal et technique effectif sur les accès. Choisir un centre de données européen ne suffit pas à garantir la souveraineté. Un fournisseur américain opérant un centre de données à Francfort n’est pas une infrastructure européenne souveraine ; c’est une adresse européenne exposée au droit américain.

Conséquence concrète : une organisation peut cocher toutes les cases de résidence RGPD — centres de données UE, mécanismes de transfert documentés, sous-traitants conformes — et ne pas atteindre la souveraineté si le fournisseur est américain et détient les clés de chiffrement.

Ce que le RGPD exige réellement en matière de résidence et de transfert des données

Le RGPD n’impose pas que les données personnelles de l’UE soient systématiquement stockées dans l’UE. Le chapitre V (articles 44 à 49) limite les transferts de données personnelles hors UE/EEE — via des décisions d’adéquation, des clauses contractuelles types, des règles d’entreprise contraignantes ou d’autres mécanismes approuvés. En pratique, ce chapitre crée une forte pression en faveur de la résidence : si aucun mécanisme de transfert valable n’existe pour une destination donnée, les données doivent rester dans l’UE.

Pour la plupart des organisations utilisant des fournisseurs cloud américains, les CCT sont le mécanisme principal — complété, depuis Schrems II, par des analyses d’impact sur les transferts qui évaluent si le droit américain compromet l’efficacité de ces CCT. L’article 32 du RGPD exige des « mesures techniques et organisationnelles appropriées » qui, depuis Schrems II, sont interprétées par les autorités comme nécessitant des contrôles techniques démontrables et proportionnés au risque identifié. Les recommandations 01/2020 de l’EDPB désignent le chiffrement contrôlé par le client, avec des clés détenues exclusivement dans l’EEE, comme la mesure technique capable de répondre à l’exposition au CLOUD Act. C’est là que les exigences de résidence RGPD et l’architecture de souveraineté convergent : une conformité réelle à l’article 32 pour les transferts via un fournisseur américain impose la même architecture de contrôle des clés que celle exigée pour la souveraineté.

L’écart CLOUD Act : pourquoi la résidence n’est pas la souveraineté

Le CLOUD Act américain impose aux entreprises américaines de fournir les données qu’elles contrôlent à la demande du gouvernement américain, quel que soit le lieu de stockage physique de ces données. Un fournisseur américain opérant un centre de données à Francfort n’est pas une organisation européenne — c’est une organisation américaine avec une implantation européenne. La demande ne requiert aucune décision de justice européenne, n’informe ni le responsable de traitement ni la personne concernée, et le fournisseur doit s’exécuter, quel que soit son contrat avec le client européen. Les clauses contractuelles types précisent ce que le fournisseur entend faire ; elles ne peuvent pas modifier ce que la loi américaine l’oblige à faire.

Le Data Privacy Framework UE-États-Unis (2023) offre un mécanisme de transfert mais ne supprime pas le CLOUD Act. Il ajuste la surveillance du renseignement américain ; il n’empêche pas les demandes du CLOUD Act d’atteindre les données contrôlées par le fournisseur. Les défenseurs de la vie privée engagent déjà des recours juridiques. Bâtir une infrastructure de conformité pérenne sur le DPF revient à accepter une incertitude juridique permanente.

Le seul contrôle qui comble cet écart est architectural : un chiffrement géré par le client avec des clés détenues entièrement hors de l’infrastructure du fournisseur. Si le fournisseur n’a pas accès aux clés, une demande fondée sur le CLOUD Act ne fournit que des données chiffrées — légalement obtenues mais illisibles. Le fournisseur devient techniquement incapable de répondre à une demande de déchiffrement, quelle que soit la contrainte légale. L’architecture pallie ce que les contrats ne peuvent empêcher. C’est précisément ce que l’EDPB entend par « mesure technique complémentaire » suffisante pour répondre à l’exposition au CLOUD Act — et c’est la norme désormais appliquée par les autorités européennes.

Le cadre européen élargi : NIS 2 et DORA

Le RGPD est la base, mais pour la plupart des organisations opérant dans l’UE, ce n’est pas le seul cadre de souveraineté applicable. Deux autres règlements européens imposent des obligations de souveraineté qui s’ajoutent au RGPD — et vont parfois plus loin.

La directive NIS 2, transposée par les États membres en octobre 2024, couvre les secteurs essentiels — énergie, transport, banque, santé, infrastructures numériques — et les secteurs importants comme l’industrie et les services professionnels. Son volet souveraineté figure à l’article 21 : obligation d’évaluer la sécurité de la supply chain TIC, y compris la posture de souveraineté des fournisseurs cloud. Un fournisseur américain soumis au CLOUD Act est un risque de souveraineté supply chain que NIS 2 impose au client de documenter et d’adresser. Les manquements à la conformité NIS 2 sont passibles d’amendes jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial, avec responsabilité personnelle directe des dirigeants — une responsabilité que le RGPD n’impose pas aux individus.

DORA, applicable dès janvier 2025 pour les entités financières de l’UE, va plus loin : l’article 30 impose explicitement que les contrats avec les fournisseurs TIC traitent la souveraineté des données, la gestion des clés de chiffrement et les stratégies de sortie. Pour les acteurs financiers, RGPD, DORA et lois nationales sur le secret bancaire créent une triple obligation de souveraineté que la seule conformité RGPD ne peut satisfaire.

Ce que la conformité réelle à la souveraineté des données européennes implique concrètement

Clés de chiffrement contrôlées par le client. L’EDPB désigne cette mesure comme principale pour les transferts via un fournisseur américain. Des clés dans le HSM du client, hors de l’infrastructure du fournisseur, font qu’une divulgation imposée par le CLOUD Act ne livre que des données chiffrées. Ce contrôle architectural satisfait à la fois l’article 32 du RGPD, l’article 30 de DORA sur la gestion des clés et l’évaluation de la souveraineté supply chain de NIS 2 — simultanément, pour les trois cadres.

Déploiement européen à locataire unique. Une infrastructure dédiée dans un centre de données de l’UE, sous contrôle opérationnel du client, garantit une résidence des données documentée conforme au chapitre V du RGPD et à la norme probatoire appliquée par les autorités lors des analyses d’impact sur les transferts. La juridiction suit le contrôle, pas les coordonnées géographiques.

Géorepérage appliqué par des règles. Des contrôles de géorepérage qui empêchent techniquement la sortie des données des régions désignées — appliqués au niveau de l’infrastructure, et non seulement par des règles — constituent ce que l’EDPB classe comme « mesure technique complémentaire » plutôt que « mesure contractuelle complémentaire ». Seules les premières sont jugées suffisantes pour les transferts exposés au CLOUD Act.

Traçabilité immuable. L’article 30 du RGPD, le reporting d’incident NIS 2 et la documentation des risques TIC de DORA exigent tous la même base : des traces infalsifiables de chaque accès, transfert et traitement de données, avec la portée géographique documentée. Les évaluations de gestion des risques tiers doivent vérifier que les fournisseurs peuvent produire cette preuve à la demande, et non simplement l’affirmer.

Comment Kiteworks garantit la souveraineté architecturale pour la conformité européenne

La frontière entre les exigences de résidence RGPD et la véritable souveraineté des données européennes, c’est la différence entre l’endroit où vos données sont stockées et qui contrôle réellement leur accès. Une organisation peut stocker ses données à Francfort, signer des clauses contractuelles types et tenir une analyse d’impact sur les transferts conforme — et rester à une assignation CLOUD Act de voir les données de ses clients européens transmises aux autorités américaines sans notification. C’est la réalité structurelle de l’utilisation d’une infrastructure contrôlée par les États-Unis pour des données européennes, et c’est ce que les autorités européennes sanctionnent désormais.

La véritable souveraineté des données européennes exige une architecture qui pallie ce que les contrats ne peuvent pas : des clés de chiffrement contrôlées par le client qui rendent le fournisseur techniquement incapable de fournir des données lisibles, un déploiement européen à locataire unique qui place les données sous juridiction européenne, et un géorepérage appliqué par des règles qui fait de la résidence une réalité technique, et non une simple déclaration contractuelle. Kiteworks propose cette architecture. Vos données, votre juridiction, votre contrôle.

Kiteworks a été conçu autour d’un principe fondateur : vos données doivent rester sous votre contrôle — dans votre juridiction, chiffrées avec vos clés, inaccessibles à toute personne non autorisée, y compris Kiteworks lui-même. Voilà ce que signifie la souveraineté architecturale en pratique.

Le Réseau de données privé Kiteworks regroupe tous les canaux de communication de contenu sensible — messagerie électronique, partage sécurisé de fichiers, MFT, formulaires web et API — sur une plateforme unique régie par des contrôles de souveraineté unifiés. Le chiffrement géré par le client (BYOK/BYOE) avec chiffrement validé FIPS 140-3 niveau 1 et AES-256 au repos garantit que Kiteworks ne peut pas déchiffrer les données du client — non par promesse, mais par architecture. Nous ne détenons jamais les clés. Lorsqu’une demande gouvernementale parvient à Kiteworks, elle ne fournit que des données chiffrées. C’est la mesure complémentaire requise par l’EDPB, appliquée au niveau de l’infrastructure.

Les options de déploiement européen — sur site, cloud privé avec un fournisseur européen, ou infrastructure Kiteworks hébergée dans l’UE — appliquent la résidence des données techniquement. Le géorepérage appliqué par des règles verrouille le contenu dans les régions désignées. Les contrôles de sécurité Zéro trust régissent les accès, chaque interaction étant enregistrée dans une traçabilité immuable et unifiée, visible via le tableau de bord RSSI. Le reporting conformité préconfiguré pour le RGPD, NIS 2, DORA et ISO 27001 fournit la preuve d’analyse d’impact sur les transferts, les registres de l’article 30 et la documentation de la gestion des clés — une souveraineté que vous pouvez prouver à un régulateur, et non simplement affirmer à un client.

Pour découvrir comment Kiteworks contribue à la conformité souveraineté des données pour les organisations opérant dans l’UE, réservez votre démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Souveraineté des données : bonne pratique ou exigence réglementaire ?
• eBook 
  Souveraineté des données et RGPD
• Article de blog 
  Les pièges à éviter en matière de souveraineté des données
• Article de blog 
  Bonnes pratiques pour la souveraineté des données
• Article de blog 
  Souveraineté des données et RGPD [Comprendre la sécurité des données]