Prévenez les risques liés au CLOUD Act : sécurisez les données européennes par l’architecture

Comment empêcher l’accès du gouvernement américain aux données européennes : une approche architecturale face au problème du CLOUD Act

Les organisations européennes qui traitent des données sensibles via des plateformes cloud dont le siège est aux États-Unis font face à un problème structurel de conformité que ni le droit contractuel ni la localisation des données ne peuvent résoudre.

Le Clarifying Lawful Overseas Use of Data (CLOUD) Act de 2018 impose aux entreprises américaines de fournir des données stockées partout dans le monde dès lors qu’elles reçoivent une demande valide du gouvernement américain — et ce, quel que soit l’emplacement des données ou les accords de confidentialité des données en vigueur.

Pour les organisations soumises au RGPD, à NIS2 et à DORA, cela crée un conflit direct entre les plateformes sur lesquelles elles s’appuient et les obligations légales qui leur incombent.

Résumé Exécutif

Idée principale : Le CLOUD Act américain crée un conflit insoluble entre les obligations légales des fournisseurs américains et la législation européenne sur la souveraineté des données. Les solutions comme les clauses contractuelles types, le déploiement de centres de données dans l’UE, etc., ne suppriment pas ce risque, car le CLOUD Act s’applique selon le contrôle exercé par le fournisseur, et non la localisation des données. Seule la gestion des clés de chiffrement par le client — détenues par l’organisation européenne et non par le fournisseur — constitue une mesure architecturale qui rend techniquement impossible l’exécution des demandes du gouvernement américain sur le contenu réel des données.

Pourquoi c’est important : L’article 48 du RGPD interdit le transfert de données personnelles à des autorités non européennes sur la seule base d’une décision judiciaire ou administrative étrangère. Une organisation qui traite des données via une plateforme américaine soumise au CLOUD Act peut se retrouver en violation structurelle permanente — non pas à cause d’un incident précis, mais en raison de l’architecture elle-même. NIS2 et DORA ajoutent des obligations de gestion des risques liés à la supply chain TIC qui aggravent ce risque pour les secteurs critiques et les services financiers.

5 points clés à retenir

1. Le CLOUD Act s’applique selon le contrôle du fournisseur, et non la localisation des données. Stocker des données dans un centre de données à Francfort ou Amsterdam exploité par une entreprise américaine ne place pas ces données sous la juridiction allemande ou néerlandaise. Les autorités américaines peuvent contraindre le fournisseur à les fournir, quel que soit l’emplacement physique du stockage.
2. Les clauses contractuelles types et les accords de traitement des données ne peuvent pas s’opposer à une obligation légale américaine. Le CLOUD Act impose aux fournisseurs de répondre aux demandes valides du gouvernement américain même si cela entre en conflit avec une loi étrangère. Les SCC et DPA sont des instruments contractuels sans force légale face à une décision judiciaire ou administrative américaine adressée au fournisseur.
3. Le Data Privacy Framework UE-États-Unis ne résout pas l’exposition au CLOUD Act. Le DPF encadre les règles de transfert de données personnelles pour les entreprises américaines certifiées, mais n’empêche pas les autorités américaines d’émettre des demandes au titre du CLOUD Act. La Section 702 du FISA, réautorisée avec un champ élargi en avril 2024, demeure une préoccupation distincte et non résolue au regard du droit européen sur la protection des données.
4. Des Transfer Impact Assessments menés avec rigueur identifieront le risque CLOUD Act comme non atténué sans mesures techniques. Les recommandations Schrems II de l’EDPB identifient explicitement la gestion des clés de chiffrement par le client, conservées dans l’EEE, comme la principale mesure technique complémentaire permettant de répondre au risque lié à la législation américaine sur la surveillance.
5. La gestion du chiffrement par le client rend les demandes du CLOUD Act techniquement inapplicables au contenu des données. Lorsque l’organisation européenne — et non le fournisseur américain — détient les clés de chiffrement, intégrées à un HSM sous contrôle juridictionnel, le fournisseur ne peut fournir de données lisibles même sous contrainte légale. L’architecture résout ce que les contrats ne peuvent pas couvrir.

Pourquoi le CLOUD Act pose un problème structurel aux organisations européennes

La distinction essentielle réside entre l’emplacement des données et leur contrôle. La plupart des organisations européennes ayant migré vers des plateformes cloud américaines l’ont fait en se rassurant par le fait que « nos données sont dans l’UE ». Ce sentiment de sécurité est en grande partie infondé.

Comment fonctionne le CLOUD Act et pourquoi les centres de données européens ne protègent pas

Le CLOUD Act impose aux entreprises américaines de préserver, sauvegarder et divulguer les communications électroniques et les enregistrements en leur possession, garde ou contrôle lorsqu’elles reçoivent une demande légale valide — quel que soit l’emplacement du stockage. Le critère déterminant est le contrôle, pas la géographie. Un fournisseur cloud américain exploitant un centre de données à Francfort reste une entreprise américaine qui contrôle les données stockées sur place. Si le Department of Justice ou le FBI émet une demande, l’emplacement à Francfort n’a aucune incidence juridique.

Le problème est aggravé par le fait que les demandes au titre du CLOUD Act s’accompagnent souvent d’ordonnances de non-divulgation — le fournisseur américain peut être légalement empêché d’informer le client européen dont les données sont consultées. Une organisation peut donc être en violation permanente de l’article 48 du RGPD, qui interdit la remise de données personnelles à des autorités non européennes sans accord international, sans jamais savoir qu’une demande a eu lieu. Le CLOUD Act ne constitue pas un tel accord.

Pourquoi les protections contractuelles ne suffisent pas

Le CLOUD Act prévoit explicitement que les fournisseurs américains doivent répondre aux demandes valides même si cela contrevient à une loi étrangère. L’engagement contractuel du fournisseur à contester une demande ou à informer le client est subordonné à ses obligations légales américaines. Ce n’est pas théorique. L’arrêt Schrems II de la CJUE a invalidé le Privacy Shield UE-États-Unis précisément pour cette raison : le droit américain permettait aux autorités d’accéder aux données personnelles européennes d’une manière incompatible avec le RGPD, sans recours judiciaire effectif pour les citoyens européens. La Cour a confirmé que les clauses contractuelles types ne pouvaient être invoquées lorsque le droit américain en sapait l’efficacité, et que des mesures techniques complémentaires étaient nécessaires.

Comment le cadre de transfert du RGPD croise le risque CLOUD Act

Le chapitre V du RGPD — articles 44 à 49 — régit les transferts internationaux de données personnelles. Pour les organisations européennes utilisant des plateformes américaines, comprendre ce cadre est indispensable. Le fait d’utiliser un fournisseur cloud américain constitue-t-il un transfert international permanent, et sur quelle base juridique ? Cela a un impact direct sur l’exposition réglementaire en matière de conformité RGPD.

Articles 44-49, Schrems II et les enjeux des Transfer Impact Assessments

Les organisations qui s’appuient sur les SCC de l’article 46 doivent, depuis Schrems II, réaliser des Transfer Impact Assessments afin d’évaluer si le droit américain compromet l’efficacité des SCC pour leurs transferts spécifiques. Les recommandations 01/2020 de l’EDPB détaillent ce processus. L’EDPB a identifié comme mesure technique complémentaire le chiffrement fort avant la transmission — avec des clés de déchiffrement conservées uniquement sous contrôle de l’EEE. Le chiffrement cloud standard, où le fournisseur gère les clés dans le cadre de son service, ne répond pas à cette exigence : le fournisseur conserve un accès technique aux données en clair et reste soumis aux demandes du CLOUD Act.

Pourquoi le Data Privacy Framework UE-États-Unis ne résout pas le problème

Le DPF, adopté par la Commission européenne en juillet 2023, permet aux entreprises américaines certifiées de recevoir des données personnelles européennes sans SCC distinctes. Il n’empêche pas les autorités américaines d’émettre des demandes au titre du CLOUD Act ou de la Section 702 du FISA à l’encontre de ces entreprises. La Section 702 du FISA a été réautorisée en avril 2024 avec un champ élargi. Le Parlement européen a averti en mai 2023 que le DPF « n’assure pas l’équivalence essentielle ». Le rapport d’examen de l’EDPB de novembre 2024 a appelé à une réévaluation sous trois ans. Début 2025, l’administration Trump a révoqué trois des cinq membres du US Privacy and Civil Liberties Oversight Board — l’organe chargé de superviser les engagements du DPF en matière de renseignement — le privant de quorum. Les deux prédécesseurs du DPF, Safe Harbour et Privacy Shield, ont tous deux été invalidés par la CJUE. Les organisations qui considèrent la certification DPF comme leur principale parade au CLOUD Act s’appuient sur des bases manifestement fragiles.

NIS2 et DORA aggravent l’exposition

Le RGPD n’est pas le seul cadre imposant des obligations liées au risque CLOUD Act. Pour les organisations des infrastructures critiques et des services financiers, NIS2 et DORA ajoutent des exigences spécifiques de gestion des risques liés aux tiers, directement concernées par la dépendance à des fournisseurs américains.

Sécurité de la supply chain NIS2 et risques tiers TIC DORA

NIS2, applicable à partir d’octobre 2024, impose aux entités essentielles et importantes d’évaluer la sécurité de la supply chain TIC — y compris l’exposition de leurs fournisseurs aux demandes d’accès des gouvernements non européens au titre de l’article 21. Une organisation qui n’a pas évalué si l’exposition de son fournisseur cloud américain au CLOUD Act constitue un risque supply chain est potentiellement non conforme aux obligations de gestion des risques de NIS2, qu’une demande ait eu lieu ou non. Les amendes peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles.

DORA, applicable à partir de janvier 2025, impose aux entités financières d’évaluer le risque de concentration lié à la dépendance aux fournisseurs TIC, d’examiner les engagements de confidentialité et de maintenir des stratégies de sortie documentées pour les relations TIC critiques. Le CLOUD Act crée un risque de concentration spécifique que DORA impose d’évaluer et de traiter. Le guide de la BCE de juillet 2025 sur l’externalisation des services cloud va dans ce sens, en insistant sur l’évaluation des risques juridiques liés aux fournisseurs cloud pour les banques supervisées par la BCE.

La solution architecturale : gestion du chiffrement par le client

Les recommandations de l’EDPB sont claires : le fournisseur américain ne doit jamais avoir accès ni aux données en clair ni aux clés de chiffrement. Il s’agit d’une exigence architecturale, non contractuelle. Pour y répondre, il faut déployer des plateformes où la conformité souveraine est intégrée à la couche de chiffrement elle-même — avec des clés sous contrôle du client européen, stockées dans des HSM situés dans la juridiction du client.

Comment la gestion du chiffrement par le client répond au risque CLOUD Act

La gestion du chiffrement par le client repose sur un principe simple : les données sont chiffrées avant d’atteindre l’infrastructure du fournisseur américain, à l’aide de clés générées et stockées de façon indépendante par le client. Lorsqu’une autorité américaine formule une demande au titre du CLOUD Act, le fournisseur peut fournir les données chiffrées — mais pas le contenu lisible, car il ne détient pas les clés. La demande devient techniquement inapplicable sur l’information réelle. Pour le RGPD, cette architecture répond directement à l’exigence de mesure complémentaire de l’EDPB. L’exportateur de données — l’organisation européenne — conserve le contrôle exclusif des clés de déchiffrement dans l’EEE. L’importateur — le fournisseur américain — ne traite que des données chiffrées. C’est la configuration précise identifiée par l’EDPB pour répondre au risque lié à la législation américaine sur la surveillance.

Déploiement de clés par juridiction pour les opérations multi-pays

Pour les organisations opérant en Allemagne, France, Pays-Bas et Royaume-Uni, la gestion du chiffrement par le client permet un déploiement des clés adapté à chaque juridiction. Les organisations allemandes déploient des HSM en Allemagne, respectant le RGPD et les obligations de confidentialité pénale du §203 StGB. Les organisations françaises contrôlent les clés en France, assurant le secret professionnel selon le Code de la Santé Publique. Les organisations néerlandaises détiennent les clés aux Pays-Bas, répondant aux attentes de l’AP. Les organisations britanniques déploient au Royaume-Uni, conformément aux recommandations de l’ICO sur les mesures complémentaires de transfert. Cette architecture ne nécessite pas d’abandonner les plateformes cloud américaines — il s’agit de garantir que la couche de chiffrement reste sous contrôle européen avant que les données n’atteignent l’infrastructure américaine.

Constituer le dossier documentaire pour les régulateurs

Déployer la bonne architecture est nécessaire, mais pas suffisant. Les autorités de protection des données, les organismes de supervision NIS2 et les autorités compétentes DORA attendent des preuves documentées. Pour les organisations ayant traité le risque CLOUD Act via la gestion du chiffrement par le client, la documentation suit une structure claire.

Preuves du Transfer Impact Assessment et conformité continue

Un Transfer Impact Assessment conforme à Schrems II pour une relation avec un fournisseur américain doit documenter : les lois américaines concernées (CLOUD Act, FISA 702) ; une évaluation de leur impact sur les SCC ; les mesures techniques complémentaires adoptées ; la justification de l’équivalence de protection obtenue ; et un engagement de veille sur l’évolution de la décision d’adéquation DPF. Les preuves techniques incluent des schémas d’architecture, des procédures de gestion des clés, des registres de déploiement HSM et des journaux d’audit attestant du fonctionnement des contrôles d’accès. Pour NIS2 et DORA, ajoutez des analyses de risques supply chain sur l’exposition du fournisseur au CLOUD Act, des évaluations du risque de concentration, des stratégies de sortie et des matrices RBAC indiquant qui peut déchiffrer quoi.

Comment Kiteworks permet aux organisations européennes de traiter le risque CLOUD Act sur le plan architectural

Le problème du CLOUD Act est réel, structurel et ne peut pas être résolu par contrat. Les organisations européennes qui traitent des données sensibles via des plateformes américaines sans gestion des clés de chiffrement par le client présentent un déficit de conformité que des Transfer Impact Assessments honnêtes mettront en évidence, que les autorités de contrôle du RGPD sont de plus en plus enclines à sanctionner, et que les cadres de gestion des risques tiers de NIS2 et DORA imposent de traiter. La solution architecturale validée par l’EDPB existe dès aujourd’hui. Il s’agit de garantir que la couche de chiffrement se situe là où elle doit être : sous contrôle européen, avant que les données n’atteignent l’infrastructure américaine.

Kiteworks propose aux organisations européennes un Réseau de données privé qui répond directement au risque CLOUD Act grâce à la gestion du chiffrement par le client. Les clés de chiffrement restent sous le contrôle exclusif du client européen, stockées dans des HSM déployés dans la juridiction du client. Lorsque Kiteworks traite des données, il ne traite que des données chiffrées — rendant techniquement inaccessibles les données en clair aux demandes du gouvernement américain adressées à Kiteworks.

La plateforme prend en charge le déploiement par juridiction — les organisations allemandes contrôlent les clés en Allemagne, les françaises en France, les néerlandaises aux Pays-Bas, les britanniques au Royaume-Uni — respectant les exigences de mesures complémentaires Schrems II de l’EDPB et fournissant la base documentaire requise pour les Transfer Impact Assessments. Kiteworks intègre la messagerie électronique, le partage et le transfert de fichiers, ainsi que les formulaires de données sécurisés Kiteworks dans une architecture unifiée — la gestion du chiffrement par le client s’applique ainsi à tous les canaux d’échange de données.

Pour en savoir plus sur la façon dont Kiteworks aide les organisations européennes à traiter le risque CLOUD Act, réservez votre démo sans attendre !

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]