Puis-je utiliser un fournisseur de cloud basé aux États-Unis si mes données doivent rester au sein de l’UE ?

La réponse courte est : sous conditions. Un fournisseur cloud basé aux États-Unis, disposant de centres de données dans l’UE, n’est pas automatiquement exclu de l’hébergement de données de résidents européens — mais la conformité exige bien plus que le choix d’une région serveur à Francfort ou à Dublin. La plupart des organisations qui pensent avoir réglé la question en choisissant une localisation géographique se trompent. Elles ont changé l’adresse de leurs données sans en modifier l’exposition juridique.

Ce billet répond à trois questions : peut-on utiliser des fournisseurs américains, quelles catégories de données sont soumises aux restrictions de souveraineté les plus strictes, et quelles garanties sont nécessaires pour rendre un dispositif réellement conforme.

Résumé Exécutif

À retenir : Les fournisseurs cloud américains peuvent légalement héberger des données de résidents européens uniquement si des garanties techniques et juridiques précises sont mises en place — des garanties qui vont au-delà du choix d’un serveur dans l’UE et qui répondent au problème structurel selon lequel la loi américaine s’applique aux entreprises américaines, quel que soit l’emplacement de leurs serveurs. Le CLOUD Act américain et la section 702 du FISA créent un risque d’accès gouvernemental que le Data Privacy Framework UE-États-Unis n’élimine pas et que les clauses contractuelles types ne suffisent pas à traiter. La solution requise est architecturale : un chiffrement contrôlé par le client, avec des clés hors de l’infrastructure du fournisseur, rendant ce dernier techniquement incapable de fournir des données lisibles, même sous contrainte légale.

Pourquoi c’est important : Les autorités européennes de protection des données ont pris des décisions de sanction, jugeant que certains dispositifs cloud américains enfreignent le RGPD, indépendamment de la localisation des serveurs. La directive NIS 2, DORA et des lois nationales sectorielles imposent des obligations supplémentaires de souveraineté, avec des sanctions pouvant atteindre 4 % du chiffre d’affaires mondial. Les organisations qui n’ont pas revu leurs accords avec des fournisseurs américains à l’aune des exigences post-Schrems II s’exposent à des risques de sanction.

Résumé des points clés

1. Localiser un serveur dans l’UE ne signifie pas juridiction européenne. Le centre de données de Francfort d’un fournisseur américain reste soumis aux exigences légales américaines via la structure de l’entreprise. La géographie détermine où sont stockées les données, mais pas quel gouvernement peut en exiger l’accès.
2. Le Data Privacy Framework UE-États-Unis ne supprime pas le CLOUD Act. Le DPF fournit un mécanisme de transfert pour les données personnelles au titre du RGPD — il ne lève pas les obligations des fournisseurs américains en matière de surveillance. Les demandes fondées sur le CLOUD Act restent valides, que le fournisseur participe ou non au DPF.
3. Certaines catégories de données sont soumises à des restrictions qui interdisent de fait l’usage de fournisseurs américains sans contrôles architecturaux de souveraineté. Les données de santé relevant de lois nationales, les données financières soumises à DORA, les données gouvernementales classifiées et certaines catégories de données personnelles à haut risque selon l’article 9 du RGPD sont toutes soumises à des restrictions que les seules clauses contractuelles types ne peuvent pas traiter efficacement.
4. L’utilisation conforme d’un fournisseur américain exige des garanties techniques précises, pas seulement des documents juridiques. Depuis Schrems II, l’EDPB identifie le chiffrement contrôlé par le client, avec des clés hors de l’infrastructure du fournisseur, comme la mesure technique complémentaire requise. Les engagements contractuels ne suffisent pas si la loi américaine impose la coopération du fournisseur, quels que soient les termes du contrat.
5. L’alternative architecturale consiste en un déploiement européen à locataire unique avec chiffrement géré par le client. Cela règle structurellement le problème du CLOUD Act : le fournisseur ne peut pas fournir de données lisibles car il n’a jamais détenu les clés — rendant possible la conformité simultanée avec les obligations américaines et européennes.

Le problème central : la juridiction suit l’entreprise, pas le serveur

L’idée reçue derrière la plupart des dispositifs « centre de données UE » est que l’emplacement physique des données détermine la juridiction. Ce n’est pas le cas. Le CLOUD Act américain (2018) oblige les entreprises américaines à fournir les données qu’elles contrôlent en réponse à une demande gouvernementale valide, quel que soit le lieu de stockage. Une demande adressée au siège d’un fournisseur américain impose la production de données stockées sur ses serveurs européens. L’adresse du serveur n’a aucune importance ; c’est la nationalité de l’entreprise qui déclenche la compétence juridique américaine. La section 702 du FISA étend cette obligation aux données de communication dans le cadre de la sécurité nationale. Aucun de ces textes n’impose de contrôle judiciaire compatible avec l’UE ni d’obligation d’information du client.

Ce risque n’est pas théorique. Les autorités autrichienne, française et italienne de protection des données ont pris des décisions de sanction, concluant que certains dispositifs cloud américains enfreignent le RGPD précisément parce que le risque lié au CLOUD Act n’était pas suffisamment pris en compte dans les garanties mises en place.

Ce que le Data Privacy Framework UE-États-Unis règle — et ne règle pas

Beaucoup d’organisations pensent que le Data Privacy Framework UE-États-Unis, adopté en 2023, a résolu le problème Schrems II. Ce n’est pas le cas. Le DPF fournit un mécanisme d’adéquation au titre de l’article 45 du RGPD — une base légale pour transférer des données personnelles à des entreprises américaines certifiées. Mais il ne supprime pas le CLOUD Act. Les fournisseurs américains certifiés DPF restent légalement tenus de répondre à toute demande valide fondée sur le CLOUD Act. Le DPF répond à la question de la base légale du transfert ; il ne répond pas à la question de savoir si une demande gouvernementale américaine pourrait contraindre le fournisseur à fournir des données européennes.

Le DPF fait également l’objet de recours juridiques actifs de la part de NOYB — l’organisation à l’origine de l’invalidation du Privacy Shield en 2020. Les organisations qui fondent leur conformité uniquement sur la certification DPF s’exposent au même risque d’invalidation qui a fait disparaître le Privacy Shield. Le chiffrement contrôlé par le client offre une protection qui reste valable quel que soit le mécanisme de transfert, car les données ne sont jamais accessibles au fournisseur, peu importe le cadre juridique applicable.

Quelles données sont soumises aux restrictions de souveraineté les plus strictes

Toutes les données ne présentent pas le même risque de souveraineté. Cinq catégories sont soumises aux exigences les plus strictes selon les cadres européens et nationaux.

Données personnelles sensibles (article 9 du RGPD). Les données de santé, biométriques, génétiques et autres catégories sensibles exigent une base légale spécifique en plus des fondements standards du RGPD, et les transferts doivent satisfaire à la fois au chapitre V et à la base de l’article 9 — une double exigence que les clauses contractuelles types ne couvrent souvent pas.

Données de santé et de patients. Les lois nationales sur les données de santé imposent des exigences supplémentaires au RGPD. La France exige que les données de santé soient traitées sur une infrastructure sous souveraineté française. L’Allemagne impose des protections équivalentes pour les données patients. Plusieurs cadres nationaux interdisent de fait aux fournisseurs américains de traiter des données de santé sans contrôles de souveraineté au niveau de l’infrastructure, indépendamment des clauses contractuelles types.

Données des services financiers. DORA (en vigueur à partir de janvier 2025) impose aux entités financières et à leurs prestataires TIC d’inclure dans leurs contrats des clauses sur la localisation des données, la gestion des clés et les stratégies de sortie. Les lignes directrices de l’EBA sur l’externalisation exigent des évaluations documentées de souveraineté. Les entités financières européennes utilisant des fournisseurs cloud américains sans dispositif adéquat de gestion des clés ne sont actuellement pas conformes.

Données gouvernementales et sensibles pour la défense. Les données classifiées, celles des sous-traitants de la défense et les données soumises à des politiques nationales de cloud public ne peuvent généralement pas être traitées légalement sur une infrastructure contrôlée par une entreprise américaine, quel que soit le mécanisme de transfert. La plupart des États membres de l’UE imposent des restrictions explicites sur le traitement des données gouvernementales par des fournisseurs non européens.

Données opérationnelles d’infrastructures critiques. L’article 21 de NIS 2 impose aux opérateurs de services essentiels — énergie, transport, santé, eau, infrastructures financières et numériques — d’évaluer la posture de souveraineté de leurs fournisseurs cloud dans le cadre des obligations de sécurité de la supply chain. Le seuil d’acceptabilité du risque CLOUD Act dans ces contextes est bien plus élevé que pour des données commerciales classiques.

Garanties techniques et juridiques requises

Pour les organisations qui estiment qu’un dispositif avec un fournisseur américain peut être conforme, quatre garanties sont indispensables.

Évaluation d’impact sur les transferts (TIA) avec analyse honnête du CLOUD Act. Une TIA dont la conclusion repose sur des contrôles techniques, et non sur des engagements contractuels. Une TIA qui reconnaît le risque CLOUD Act mais s’appuie sur des notifications comme mesure d’atténuation ne répond pas à la norme post-Schrems II — l’évaluation doit conclure qu’une demande valide ne permettrait pas la production de données lisibles, et cette conclusion doit être fondée sur l’architecture technique.

Chiffrement contrôlé par le client avec des clés hors de l’infrastructure du fournisseur. Les recommandations 01/2020 de l’EDPB identifient cette mesure technique complémentaire comme indispensable : des clés générées par le client, stockées dans des HSM sous le contrôle exclusif du client européen, jamais détenues par le fournisseur américain. Sans cela, toute TIA qui reconnaît le risque CLOUD Act ne peut conclure valablement que le transfert est suffisamment protégé.

Application de la résidence des données au niveau de l’infrastructure. Les clauses contractuelles de localisation sont des mesures complémentaires contractuelles. Le géorepérage appliqué par la politique, qui empêche toute sortie de données hors des régions UE désignées, quelle que soit la configuration, est une mesure technique. Depuis Schrems II, cette distinction est déterminante pour l’évaluation des autorités de protection des données.

Traçabilité immuable et documentation continue de la conformité. Le principe d’accountability du RGPD impose de démontrer la conformité en continu. Journaux d’audit immuables, enregistrements de gestion des clés et révision régulière des TIA constituent le socle minimal. Pour DORA et NIS 2, cette documentation doit être accessible aux régulateurs sur demande.

Comment Kiteworks garantit la souveraineté des données UE conforme

Le Réseau de données privé Kiteworks répond directement au problème structurel. Un déploiement à locataire unique dans la zone choisie par le client européen — sur site, dans un cloud privé européen ou sur l’infrastructure UE hébergée par Kiteworks — place les données sous juridiction européenne, et non sous contrôle d’une entreprise américaine. Le chiffrement géré par le client (BYOK/BYOE) avec chiffrement validé FIPS 140-3 niveau 1 garantit que Kiteworks ne détient jamais les clés du client : une demande fondée sur le CLOUD Act ne permet d’obtenir que des données chiffrées. La conclusion de la TIA est fondée sur l’architecture — Kiteworks est techniquement incapable de fournir des données lisibles, et ne se contente pas d’un engagement contractuel. Le géorepérage appliqué par la politique assure la résidence des données au niveau de l’infrastructure sur tous les canaux — messagerie électronique, partage de fichiers, MFT, formulaires web et API. Le tableau de bord RSSI fournit une traçabilité immuable de chaque mouvement de données. Le reporting conformité préconfiguré pour le RGPD, NIS 2, DORA et ISO 27001 facilite la démonstration de conformité et la réponse aux régulateurs pour les catégories de données soumises aux exigences de souveraineté les plus strictes.

Pour discuter des besoins spécifiques de votre organisation en matière de souveraineté des données et de la façon dont Kiteworks y répond, réservez une démo personnalisée dès maintenant.

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]