- Nature
- Contrainte : loi étrangère à portée extraterritoriale. Elle s'applique à votre fournisseur et vous atteint à travers lui
- Déclenchée si
- un fournisseur de votre chaîne (hébergement, CDN, identité, messagerie, IA, sauvegardes, support) est soumis à la juridiction américaine, où que soient vos serveurs
- Statut
- En vigueur depuis le 23 mars 2018 (Public Law 115-141)
- Met en tension
- RGPD chapitre V · HDS (localisation EEE, transparence pays tiers) · SecNumCloud · loi SREN art. 31 · Data Act art. 32
- Mis à jour
- 6 novembre 2026
Qu'est-ce que le CLOUD Act ?
Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) permet aux autorités américaines d'exiger d'un fournisseur soumis à leur juridiction les données qu'il détient, contrôle ou possède, quel que soit le pays où elles sont stockées, le cas échéant sans que le client en soit informé. Il modifie le Stored Communications Act de 1986 et clôt l'affaire Microsoft Ireland, dans laquelle Microsoft refusait de remettre des courriels stockés à Dublin.
Un datacenter à Paris n'y change rien si l'entreprise qui l'exploite est américaine, filiale d'un groupe américain, ou assez liée au marché américain.
Êtes-vous concerné ?
Votre produit est utilisé en France, et au moins un de ces fournisseurs est américain ou contrôlé depuis les États-Unis :
- l'hébergement de votre application ou de vos bases de données
- votre CDN, votre pare-feu applicatif ou votre DNS : le frontal par lequel passe chaque requête
- votre fournisseur d'identité ou d'authentification
- votre messagerie et vos notifications
- l'API de modèle d'IA que votre produit appelle (quand sa facture grimpe, changer de fournisseur pose la même question : facture d'IA qui dérive dans un logiciel de santé)
- vos sauvegardes ou votre archivage
- le prestataire dont le support accède à votre production
Chaque rôle compte à part : un hébergement français avec une authentification américaine reste exposé sur l'identité.
Estime vérifie aujourd'hui cinq de ces rôles : l'hébergement, le frontal, l'identité, la messagerie et l'API d'IA. Les sauvegardes et le support se vérifient avec vous, en Sonar Express.
Vérifier pour votre produit avec Estime →
Que change-t-il dans votre produit ?
Il agit sur les preuves que vous pouvez produire, texte par texte :
| Référentiel touché | Ce qui devient difficile ou impossible | Gravité |
|---|---|---|
| RGPD, chapitre V | Un transfert vers les États-Unis exige une base valable (adéquation « Data Privacy Framework », clauses types avec analyse d'impact de transfert). Une injonction américaine n'en est pas une (art. 48). | Haute |
| HDS | Les données de santé doivent être hébergées dans l'Espace économique européen. L'hébergeur doit être transparent sur les risques d'accès depuis des pays tiers. Hors EEE : pas de certification. Dans l'EEE chez un fournisseur exposé : risque à documenter dans le contrat. Le décret n° 2026-209 du 24 mars 2026 inscrit ce stockage à l'article R. 1111-9-1 du code de la santé publique. | Haute (hébergement) Moyenne (autres rôles) |
| SecNumCloud | Les critères d'immunité (contrôle du capital, siège, personnel) excluent les fournisseurs exposés. Exigé par certains acheteurs publics. | Haute si marché public |
| Loi SREN, art. 31 | Les données sensibles de l'État et de ses opérateurs doivent être hébergées hors de portée des autorités d'États tiers. | Haute si client public |
| Data Act, art. 32 | Votre fournisseur de traitement de données doit prévenir les accès gouvernementaux de pays tiers, y compris sur les données non personnelles (logs, télémétrie). À lire dans son contrat. | Moyenne |
| NIS2 | La dépendance à un fournisseur exposé entre dans l'analyse de risque de la chaîne d'approvisionnement. | Moyenne |
| HDS, pour une API d'IA | Une API d'inférence qui reçoit des données de santé recueillies dans un cadre de soins relève, à ma lecture, des activités d'hébergement de R.1111-9 (2°, 3°, 5°) : le fournisseur du modèle doit la même transparence sur les pays tiers que votre hébergeur. Lecture du texte, pas une position publiée de l'ANS ni de la CNIL à ce jour. | Haute |
Que n'est-il pas ?
- Une interdiction d'héberger aux États-Unis. C'est une raison pour laquelle d'autres textes vous l'interdisent, ou vous demandent de le justifier.
- Neutralisé par le RGPD. Le RGPD encadre vos traitements. Il n'empêche pas une injonction étrangère d'arriver chez votre fournisseur : il vous rend responsable de la base de transfert, sans vous protéger d'une injonction.
- Réglé par un datacenter en Europe. La localisation protège d'une saisie physique. Une injonction adressée à l'exploitant n'en tient pas compte.
- La même chose que FISA 702, qui vise le renseignement sur des personnes non américaines. La loi a expiré le 12 juin 2026, sans réautorisation au 26 octobre 2026. La collecte continue sous des certifications valables jusqu'au 17 mars 2027, selon le Brennan Center.
Comment lever l'exposition ?
Par rôle, du plus simple au plus lourd :
- 1Changer de fournisseur
Sur le rôle exposé. Un CDN, un DNS ou une messagerie se remplacent en quelques jours, une base de données en quelques mois.
- 2Chiffrer avant d'envoyer
Avec des clés que le fournisseur ne détient pas (BYOK/HYOK, HSM externe) : il peut remettre les données sans pouvoir les lire. Ne vaut que si le traitement n'a pas besoin du clair chez lui, ce qui exclut les bases applicatives qui lisent les données et toute inférence IA.
- 3Choisir une offre immunisée
Fournisseur européen sous contrôle européen, ou partenariat qualifié SecNumCloud quand on tient à la pile technique américaine (qualification à contrôler au catalogue de l'ANSSI à la date de la décision).
- 4Réduire le périmètre
Ne faire transiter par le fournisseur exposé aucune donnée personnelle ni aucun secret : possible pour un CDN de ressources statiques, pas pour une authentification.
Dans Sonar Express : lister les rôles exposés, nommer les référentiels mis en tension, estimer l'effort de chaque levée. Ce que je ne fais pas : apprécier à votre place le risque d'une injonction. C'est une décision de direction, avec votre juriste quand le contrat ou l'adéquation sont en jeu.
Quels textes recoupe-t-il ?
- AI Act : une API de modèle hors de l'Union croise ce que l'AI Act demande au logiciel.
- FISA section 702 et Executive Order 12333 : les deux autres voies d'accès américaines, l'une au renseignement, l'autre en transit.
- Arrêt Schrems II (CJUE, C-311/18, 16 juillet 2020) : invalidation du Privacy Shield, précisément à cause de ces textes.
- Data Privacy Framework (décision du 10 juillet 2023) : la base de transfert actuelle. Le Tribunal de l'Union européenne a rejeté le recours Latombe (T-553/23) le 3 septembre 2025.
- Lois chinoises (renseignement national 2017, sécurité des données 2021) : le même mécanisme, sous juridiction chinoise.
Tous les textes, et ce qui les relie : les référentiels côté produit.
Questions fréquentes
Nos serveurs sont à Paris chez un fournisseur américain : sommes-nous exposés ?
Oui. Le CLOUD Act vise le fournisseur, où que soient ses serveurs. Un datacenter français exploité par une société américaine ou sa filiale répond à une injonction américaine.
Notre hébergeur est certifié HDS : est-ce suffisant ?
HDS exige l'hébergement dans l'Espace économique européen et la transparence sur les accès depuis des pays tiers. Un hébergeur exposé peut être certifié. Il doit alors documenter le risque, et vous devez l'avoir lu dans votre contrat. La certification laisse l'exposition en place et vous oblige à la connaître. Voir ce que HDS demande au logiciel.
Le Data Privacy Framework nous couvre-t-il ?
Pour les transferts vers une organisation américaine certifiée, c'est une base de transfert valable aujourd'hui. Deux décisions d'adéquation précédentes ont été annulées par la Cour de justice, et la troisième est contestée. Une architecture fondée sur elle seule dépend de l'issue de ce recours.
Chiffrer nos données règle-t-il le problème ?
Seulement si les clés sont hors de portée du fournisseur et qu'il n'a jamais besoin du clair. Pour une base applicative, une recherche, un modèle d'IA, le fournisseur traite en clair : le chiffrement au repos ne protège pas d'une injonction sur un système en marche.
Faut-il tout rapatrier chez un fournisseur français ?
Non. Il faut savoir, rôle par rôle, où vous êtes exposé, ce que cela empêche, et ce que coûte chaque levée. Un CDN se change en quelques jours. Une base de données se migre en quelques mois. Une API d'IA se remplace par de l'inférence embarquée quand le cas d'usage le permet.
Sources
CLOUD Act, Public Law 115-141, division V (23 mars 2018), congress.gov · Ministère de la Justice américain, ressources CLOUD Act · Comité européen de la protection des données, évaluation initiale de l'impact du CLOUD Act (10 juillet 2019) · CJUE, Schrems II, C-311/18 (16 juillet 2020) · Décision d'exécution (UE) 2023/1795 (Data Privacy Framework) · Tribunal de l'UE, Latombe, T-553/23 (3 septembre 2025) · Brennan Center, section 702 · Arrêté du 26 avril 2024 (référentiel HDS) · Décret n° 2026-209 du 24 mars 2026 · ANSSI, SecNumCloud 3.2 · Loi n° 2024-449 du 21 mai 2024, art. 31 · Règlement (UE) 2023/2854, art. 32.
Olivier Philippot, ingénieur. Il pilote seul la partie technique de Serenaid. Hébergement Scaleway, inférence embarquée, aucun service américain dans la chaîne : une chaîne française de bout en bout. Laboratoire →
En cinq jours, Sonar Express liste les rôles exposés de votre produit, les référentiels que cela met en tension, et l'effort de chaque levée.