En quoi le Data Act de l’UE et le RGPD s’opposent-ils aux exigences d’accès aux données du CLOUD Act américain — et quelles conséquences pour la souveraineté ?

Si vous recherchez « EU Cloud Act », vous trouverez des centaines de résultats — articles, guides de conformité et explications de fournisseurs, tous faisant référence à une loi qui, techniquement, n’existe pas. L’Union européenne ne possède aucun texte de loi portant ce nom. En revanche, elle dispose d’une architecture juridique qui entre directement et délibérément en conflit avec le CLOUD Act américain sur la question du contrôle d’accès aux données stockées en Europe : le Data Act européen (en vigueur depuis janvier 2024, applicable à partir de septembre 2025), qui prévoit explicitement de bloquer l’accès illégal des gouvernements de pays tiers aux données non personnelles ; et le RGPD, qui encadre la même question pour les données personnelles depuis 2018.

La confusion autour de la terminologie est importante, car elle masque une réalité plus fondamentale : le conflit juridique entre les cadres d’accès aux données européens et américains est réel, structurel et non résolu — avec des conséquences directes pour toute organisation qui stocke ou traite des données en Europe via une infrastructure contrôlée par des acteurs américains. Comprendre les véritables instruments en jeu est la première étape pour saisir ce que requiert réellement la conformité à la souveraineté des données.

Résumé Exécutif

Idée principale : Le CLOUD Act américain (2018) impose aux entreprises américaines de fournir les données qu’elles contrôlent sur demande valide du gouvernement américain, quel que soit l’endroit où ces données sont stockées. Le Data Act européen (applicable à partir de septembre 2025) exige que les fournisseurs de cloud opérant dans l’UE mettent en place des mesures techniques et organisationnelles empêchant l’accès illégal des gouvernements non européens aux données non personnelles stockées en Europe — et contestent les demandes d’accès contraires au droit européen. Le chapitre V du RGPD et les exigences post-Schrems II appliquent la même logique aux données personnelles. Ces cadres ne créent pas seulement des tensions de conformité — ils imposent des obligations juridiques directement opposées aux fournisseurs cloud américains opérant en Europe. La solution est architecturale : un chiffrement contrôlé par le client, avec des clés hors de l’infrastructure américaine, rend le fournisseur techniquement incapable de répondre à une demande de déchiffrement, satisfaisant ainsi simultanément les deux systèmes juridiques.

Pourquoi c’est important : Le Data Act européen s’applique à toute entreprise proposant des services cloud ou de traitement de données dans l’UE, quel que soit son siège social — et il s’applique depuis septembre 2025. Les fournisseurs cloud américains ayant des clients européens doivent désormais mettre en place des mesures empêchant l’accès illégal du gouvernement américain aux données stockées dans l’UE. Les organisations qui s’appuient sur une infrastructure cloud américaine pour leurs données européennes sans contrôle de souveraineté architecturale se retrouvent simultanément non conformes au droit américain (si elles bloquent des demandes CLOUD Act valides) ou au droit européen (si elles s’y conforment). Seule l’architecture permet de résoudre ce dilemme.

Points clés à retenir

1. Il n’existe pas de « EU Cloud Act » — les instruments pertinents sont le Data Act européen et le RGPD. Le chapitre VII du Data Act européen traite de l’accès illégal des gouvernements de pays tiers aux données non personnelles stockées dans l’UE. Le chapitre V du RGPD et les recommandations post-Schrems II couvrent les données personnelles. Ensemble, ils constituent la réponse juridique de l’UE à la portée extraterritoriale du CLOUD Act américain — mais ce sont des instruments distincts, avec des périmètres, des catégories de données et des mécanismes d’application différents.
2. Le CLOUD Act américain et le Data Act européen imposent des obligations directement opposées aux fournisseurs américains. Le CLOUD Act impose de se conformer aux demandes du gouvernement américain, quel que soit l’emplacement des données. Le Data Act européen exige de ces mêmes fournisseurs qu’ils empêchent un tel accès lorsqu’il serait illégal au regard du droit européen, et qu’ils contestent activement ces demandes. Un fournisseur ne peut pas se conformer simultanément aux deux lorsque le droit américain impose la divulgation que le droit européen interdit.
3. Le conflit concerne différentes catégories de données selon les instruments. Le chapitre VII du Data Act européen couvre les données non personnelles. Le chapitre V du RGPD et l’arrêt Schrems II couvrent les données personnelles. Pour toute entreprise disposant des deux types de données dans une infrastructure européenne — ce qui est quasiment toujours le cas — les deux instruments s’appliquent simultanément à l’ensemble du patrimoine de données.
4. Le chiffrement contrôlé par le client constitue la solution architecturale à ces deux conflits. Lorsqu’un fournisseur américain n’a pas accès aux clés de chiffrement des données stockées dans l’UE, il ne peut pas fournir de contenu lisible en réponse à une demande CLOUD Act — satisfaisant ainsi le critère d’impossibilité technique — tout en répondant à l’exigence du Data Act européen de mesures techniques empêchant l’accès effectif des gouvernements étrangers.
5. Les dispositions du Data Act européen sur la portabilité cloud réduisent le coût de la migration souveraine. En imposant aux fournisseurs de faciliter le changement de prestataire avec un préavis de deux mois et en supprimant les frais de migration d’ici janvier 2027, le Data Act européen a délibérément abaissé la barrière commerciale pour passer d’une infrastructure cloud contrôlée par des acteurs américains à des alternatives européennes souveraines.

Ce que le CLOUD Act américain exige réellement

Le Clarifying Lawful Overseas Use of Data Act (2018) a établi que les entreprises américaines doivent conserver et divulguer les données stockées partout dans le monde en réponse à une procédure judiciaire américaine valide — y compris les données hébergées dans des centres de données européens. Sa portée suit le contrôle de l’entreprise, non la géographie. Une demande adressée au siège américain d’un fournisseur américain oblige à produire les données de ses serveurs à Francfort, Amsterdam ou Dublin. L’emplacement du stockage n’a aucune importance ; ce qui compte, c’est que le fournisseur soit une entité américaine soumise au droit américain.

Le CLOUD Act prévoit un mécanisme de contestation : les fournisseurs américains peuvent demander la modification ou l’annulation d’une demande lorsque le client n’est pas une personne américaine et que la conformité exposerait à un risque de violation des lois d’un gouvernement étranger éligible. En pratique, ce mécanisme est limité — il s’applique de façon restrictive, exige une action juridique proactive du fournisseur et ne suspend pas l’obligation de se conformer pendant la période de contestation. Il n’offre pas de véritable protection pour la souveraineté des données européennes. L’adresse du centre de données européen change la géographie, mais pas la juridiction.

Ce que le Data Act européen exige — et où il entre en conflit

Le Data Act européen (Règlement (UE) 2023/2854), entré en vigueur en janvier 2024 et applicable à partir de septembre 2025, est avant tout un règlement sur le partage des données et la portabilité cloud — mais c’est le chapitre VII qui contient les dispositions les plus pertinentes pour la souveraineté. Ce chapitre impose aux fournisseurs cloud et aux prestataires de services de traitement de données opérant dans l’UE de mettre en place « des mesures techniques, juridiques et organisationnelles » pour empêcher l’accès des gouvernements non européens aux données non personnelles stockées dans l’UE lorsque cet accès serait illégal au regard du droit de l’UE ou d’un État membre.

Lorsqu’un fournisseur reçoit une demande d’accès d’un gouvernement de pays tiers — y compris une demande au titre du CLOUD Act américain — il doit évaluer si la demande est motivée, précise et proportionnée, et si elle est contraire au droit européen ou à des accords internationaux applicables. En cas de conflit, le fournisseur doit contester ou demander la modification de l’ordre. Si la divulgation est inévitable, il ne doit fournir que le strict minimum de données nécessaires, en appliquant des mesures de protection. Les fournisseurs doivent également publier les mesures techniques mises en œuvre pour empêcher l’accès illégal des gouvernements et la localisation de leur infrastructure TIC — créant ainsi une responsabilité : les clients et régulateurs européens peuvent vérifier si l’architecture de souveraineté du fournisseur est réelle ou seulement déclarative.

Le conflit avec le CLOUD Act est direct. Une demande CLOUD Act américaine portant sur des données non personnelles hébergées dans l’UE correspond précisément au scénario que le chapitre VII exige de contester. Le fournisseur ne peut pas satisfaire les deux simultanément : se conformer à la demande CLOUD Act peut violer le Data Act européen ; la contester pour respecter le Data Act peut exposer le fournisseur à des conséquences juridiques américaines.

Le rôle du RGPD : la dimension des données personnelles

Si le chapitre VII du Data Act européen concerne les données non personnelles, le chapitre V du RGPD encadre le même conflit pour les données personnelles depuis 2018. L’arrêt Schrems II (2020) a transformé ce cadre en un affrontement direct avec la législation américaine sur la surveillance : les clauses contractuelles types pour les transferts de fournisseurs américains ne sont valides que si les données sont réellement protégées contre l’accès du gouvernement américain — ce qui impose des analyses d’impact sur les transferts qui évaluent honnêtement l’exposition au CLOUD Act et à la FISA 702, ainsi que des mesures techniques complémentaires en cas de risque avéré. Les recommandations 01/2020 de l’EDPB désignent le chiffrement contrôlé par le client, avec des clés hors de l’infrastructure du fournisseur, comme la principale mesure technique adéquate. Les autorités autrichienne, française et italienne de protection des données ont rendu des décisions estimant que certaines configurations cloud américaines violent le RGPD — jugeant que l’exposition au CLOUD Act sans mesures techniques adéquates constitue une violation des règles de transfert du RGPD.

L’effet combiné est total : les données personnelles dans une infrastructure européenne sont protégées par le RGPD et l’arrêt Schrems II ; les données non personnelles par le chapitre VII du Data Act européen. Pour toute entreprise disposant des deux types de données — soit quasiment toutes les organisations — les deux instruments s’appliquent simultanément à l’ensemble du patrimoine de données.

Pourquoi le conflit ne peut pas être résolu contractuellement

La réponse classique à ce conflit a été contractuelle : les fournisseurs américains signent des accords de traitement de données s’engageant à ne pas divulguer de données européennes sans contrainte légale, à contester les demandes excessives et à notifier les clients lorsque cela est autorisé. Ces engagements ne sont pas dénués de sens — ils créent des obligations juridiques et des enjeux de réputation. Mais ils ne résolvent pas le conflit de fond, car les contrats lient les parties entre elles ; ils ne supplantent pas les obligations légales que chaque partie doit à ses gouvernements respectifs.

Lorsqu’une demande CLOUD Act valide est reçue, l’engagement contractuel du fournisseur américain envers son client européen ne modifie pas son obligation légale envers le gouvernement américain. Le fournisseur doit se conformer — sous peine de sanctions américaines. L’autorité de protection des données du client européen peut alors conclure que les garanties contractuelles étaient insuffisantes au regard de Schrems II ou du Data Act européen. Le problème n’est pas contractuel — il est juridictionnel.

Le mécanisme de contestation du Data Act européen améliore la situation en exigeant des fournisseurs qu’ils contestent activement les demandes illégales — mais il ne supprime pas la tension. Les recours prennent du temps, leur issue est incertaine et ils ne suspendent pas l’obligation de divulgation pendant la procédure. La solution structurelle est architecturale : un chiffrement contrôlé par le client, qui détient les clés dans sa propre infrastructure européenne, et le fournisseur américain n’a jamais la capacité de déchiffrement. Une demande CLOUD Act ne permet d’obtenir que des données chiffrées — le fournisseur se conforme légalement, mais ne peut rien divulguer de lisible. L’exigence de mesures techniques du Data Act européen est satisfaite. L’exigence de mesures complémentaires de Schrems II du RGPD est satisfaite. La demande CLOUD Act est techniquement satisfaite. Tout cela, grâce à l’architecture.

Conséquences pratiques pour la souveraineté des données

Le conflit Data Act européen/RGPD versus CLOUD Act américain transforme la souveraineté des données d’une simple case à cocher en propriété architecturale. La souveraineté ne s’obtient pas en choisissant un fournisseur qui promet de protéger les données — elle s’obtient en déployant une architecture dans laquelle le fournisseur est techniquement incapable de trahir cette promesse, car il n’a jamais eu l’accès qui rendrait la trahison possible.

Pour les organisations qui évaluent leur infrastructure européenne, quatre contrôles pratiques s’imposent. Déploiement européen à locataire unique — une infrastructure dédiée dans un centre de données européen via un fournisseur cloud européen ou une infrastructure détenue par le client, et non une région européenne d’un hyperscaler américain — isole les données européennes du contrôle des sociétés américaines. Chiffrement contrôlé par le client avec des clés dans le HSM du client européen comble la faille CLOUD Act. Géorepérage appliqué par des règles garantit que la résidence des données est une réalité technique — les exigences de transparence du Data Act européen exposent les promesses de géorepérage non tenables au lieu de les masquer. Enfin, journaux d’audit immuables fournissent la documentation probante exigée par le Data Act européen et le RGPD en matière de responsabilité.

Les dispositions du Data Act européen sur la portabilité cloud ajoutent une dimension commerciale : le droit de résiliation avec un préavis de deux mois et la suppression des frais de migration d’ici janvier 2027 abaissent délibérément le coût de la migration d’une infrastructure contrôlée par des acteurs américains vers des alternatives souveraines — rendant l’option de souveraineté architecturale plus accessible, précisément au moment où les conséquences juridiques se renforcent.

Comment Kiteworks résout le conflit juridique par l’architecture

Le « EU Cloud Act » n’existe pas — mais le conflit juridique qu’il désigne est bien réel et désormais pleinement en vigueur. Le chapitre VII du Data Act européen et le chapitre V du RGPD établissent que les données stockées dans l’UE — personnelles et non personnelles — sont protégées contre l’accès illégal des gouvernements non européens par des instruments qui entrent directement en conflit avec les exigences de divulgation du CLOUD Act américain. Les fournisseurs cloud américains font face à des obligations juridiques opposées que les contrats ne peuvent concilier et que les procédures de contestation ne peuvent qu’atténuer partiellement.

La solution réside dans la souveraineté architecturale : des clés de chiffrement contrôlées par le client dans une infrastructure européenne, un déploiement à locataire unique dans l’UE hors du contrôle des sociétés américaines, et un géorepérage technique qui rend la résidence des données vérifiable. Kiteworks fournit cette architecture — vos données, votre juridiction, vos clés — rendant le conflit juridique techniquement inopérant pour les fournisseurs et véritablement protecteur pour les organisations dont les données sont en jeu.

Kiteworks fournit la résolution architecturale exigée par le Data Act européen et les exigences Schrems II du RGPD — et rendue nécessaire par le paradoxe du CLOUD Act.

Le Réseau de données privé Kiteworks se déploie en instance dédiée à locataire unique dans le lieu européen choisi par le client — sur site, via un fournisseur cloud européen ou une infrastructure Kiteworks hébergée dans l’UE. Aucun traitement de données client de l’UE n’a lieu aux États-Unis. 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 détient jamais les clés de chiffrement du client. Une demande CLOUD Act adressée à Kiteworks ne permet d’obtenir que des données chiffrées — une divulgation techniquement conforme mais sans contenu lisible. L’exigence de mesures techniques du Data Act européen est satisfaite. L’exigence de mesures complémentaires Schrems II du RGPD est satisfaite. L’obligation CLOUD Act est remplie. Tout cela, grâce à l’architecture.

Le géorepérage appliqué par des règles verrouille le contenu dans les régions européennes désignées au niveau de l’infrastructure. Les contrôles de sécurité Zero trust régissent tous les accès et chaque interaction est enregistrée dans un journal d’audit immuable via le tableau de bord RSSI. Le reporting de conformité préconfiguré pour le RGPD, NIS 2, DORA et ISO 27001 fournit le dossier de preuves réglementaires lorsque les autorités ou les clients demandent comment le conflit CLOUD Act a été résolu. Tous les canaux — messagerie électronique, partage de fichiers, MFT, formulaires web, API — sont gérés sur une plateforme unique avec des contrôles de souveraineté cohérents.

Pour découvrir comment Kiteworks résout le conflit entre le Data Act européen, le RGPD et les demandes du CLOUD Act américain, réservez une démo personnalisée dès maintenant.

Ressources complémentaires

Article de blog

• eBook 
  Souveraineté des données et RGPD
• Article de blog 
  Évitez ces pièges de la 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]