À retenir
- Le CLOUD Act (2018) autorise les autorités américaines à exiger d'un fournisseur cloud soumis à leur juridiction la remise de données, y compris si elles sont physiquement stockées en Europe.
- Trois grands fournisseurs cloud mondiaux (AWS, Azure, Google Cloud) sont, en tant que groupes, soumis au CLOUD Act. L'hébergement dans un datacenter européen ne suffit pas à s'y soustraire.
- Pour un avocat, le CLOUD Act crée un risque de conflit avec le secret professionnel (art. 66-5 loi 1971) et avec le RGPD (transferts internationaux non autorisés).
- La seule parade complète : contracter avec une entité juridique européenne qui n'est pas contrôlée opérationnellement par une société américaine — ou auto-héberger.
Avertissement préliminaire
Cet article explique un cadre juridique. Il ne constitue pas un avis juridique applicable à votre situation spécifique. Pour une application à votre cabinet, consultez votre DPO ou un confrère spécialisé en droit du numérique et souveraineté des données.
Ce qu'est le CLOUD Act — en une page
Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act) a été signé aux États-Unis le 23 mars 2018. Son objet : clarifier les conditions dans lesquelles les autorités américaines peuvent obtenir des données détenues par un fournisseur de services de communication ou cloud.
Point critique : le CLOUD Act s'applique à toute entité soumise à la juridiction américaine, indépendamment de la localisation physique des données concernées.
L'entité est soumise à la juridiction américaine si :
- Elle est enregistrée aux États-Unis (Delaware, Californie, etc.)
- Elle a une filiale US ayant un contrôle opérationnel sur le service
- Elle fournit des services aux États-Unis, même depuis une juridiction étrangère, dans certaines circonstances
En pratique, cela inclut :
- Amazon Web Services (AWS) — Amazon.com Inc. (Delaware)
- Microsoft Azure — Microsoft Corp. (Washington)
- Google Cloud — Alphabet Inc. (Delaware)
- OpenAI — OpenAI L.L.C. (Delaware)
- Anthropic — Anthropic PBC (Delaware)
Et les filiales opérationnelles qui en dépendent directement.
Pourquoi le CLOUD Act est un problème pour un avocat
1. Conflit avec le secret professionnel
L'article 66-5 de la loi du 31 décembre 1971 couvre du secret professionnel toutes les correspondances et consultations entre l'avocat et son client. Le CNB (délibération n° 2023-003) rappelle que cette obligation s'étend aux traitements par des tiers sous-traitants : l'avocat doit s'assurer que ses sous-traitants offrent des garanties équivalentes.
Si un sous-traitant (éditeur d'IA, hébergeur cloud) peut être légalement contraint par une autorité étrangère de remettre des données couvertes par le secret professionnel, l'équivalence des garanties n'est pas assurée. Le conflit de lois est réel.
2. Conflit avec le RGPD
Le RGPD (articles 44 à 50) encadre strictement les transferts de données personnelles hors UE. Une remise de données à une autorité américaine constitue un transfert international. Si ce transfert n'est pas couvert par une base légale (décision d'adéquation, clauses contractuelles types, intérêt public majeur…), il constitue une violation du RGPD.
Le problème pratique : un fournisseur soumis au CLOUD Act peut se trouver pris entre deux feux — obligation américaine de livrer, interdiction européenne de transférer. Les CCT (Clauses Contractuelles Types) prévoient des mécanismes de notification, mais ne suppriment pas le conflit.
3. Opacité potentielle
Le CLOUD Act prévoit des mécanismes de gag orders — le destinataire de la demande peut être contraint de ne pas en révéler l'existence. Si un fournisseur cloud reçoit une demande visant vos données, vous ne serez peut-être pas informé.
C'est le cas le plus préoccupant du point de vue déontologique : vous ne sauriez pas que le secret professionnel a été percé.
Les trois scénarios concrets
Scénario A — Le fournisseur est clairement américain
Exemple : vous utilisez ChatGPT Plus (OpenAI) pour des prompts contenant des éléments sensibles d'un dossier client.
Analyse : OpenAI L.L.C. est américain. Le CLOUD Act s'applique directement. Les prompts sont potentiellement accessibles par demande américaine.
Recommandation : inadapté pour du contenu confidentiel. Acceptable pour des tâches génériques sans données client identifiables.
Scénario B — Le fournisseur est une filiale européenne autonome
Exemple : vous utilisez Consia, dont le fournisseur d'infrastructure IA est une société française contractant en droit français.
Analyse : notre fournisseur d'infrastructure IA est une société française, contrat de droit français. Le CLOUD Act ne s'applique pas directement à elle. La question d'un éventuel « remontée » via une éventuelle maison-mère américaine reste débattue, avec un consensus sur un risque nettement réduit.
Recommandation : compatible avec un usage professionnel pour la plupart des cabinets. Reste à documenter dans votre DPIA.
Scénario C — Le fournisseur est européen à 100 %
Exemple : vous utilisez une solution d'IA open source hébergée sur un cloud souverain français (OVH, Scaleway) contractualisé avec une entité française.
Analyse : pas de lien juridique avec les États-Unis, CLOUD Act inapplicable.
Recommandation : setup le plus souverain. Souvent plus coûteux, et la qualité des modèles open source peut être en retrait sur certaines tâches.
Les arbitrages concrets pour votre cabinet
Pour les données ultra-sensibles
Certains dossiers justifient une exigence de souveraineté maximale :
- Dossiers impliquant des intérêts d'État (procédure pénale sensible, contentieux public)
- Dossiers transatlantiques où un intérêt américain est en jeu
- Cabinets d'avocats pénalistes travaillant sur des dossiers internationaux
- Cabinets spécialisés en droit public ou en droit de la concurrence avec gros enjeux
Pour ces dossiers, le scénario C (solution 100 % européenne) est à privilégier.
Pour la pratique courante
Pour la grande majorité des cabinets, le scénario B (filiale européenne autonome avec contrat de droit européen) offre un équilibre raisonnable :
- Réduction significative du risque CLOUD Act
- Qualité de service des grands modèles
- Coût maîtrisé
- DPA et conformité structurées
Chez Consia, nous avons choisi cette configuration : infrastructure IA opérée depuis la France sous contrat de droit français, base de données chiffrée hébergée en Union européenne, et stack applicative hébergée en Europe.
Les critères de vérification
Demandez à votre fournisseur d'IA des réponses écrites aux questions suivantes :
- Quelle est l'entité juridique avec laquelle je contracte ? (dénomination sociale complète, numéro d'immatriculation, pays)
- Quelle est la société mère de cette entité ? (nationalité et localisation du siège)
- Le CLOUD Act peut-il s'appliquer à l'entité contractante ? (réponse nuancée attendue, pas un simple « non »)
- Où sont physiquement hébergées mes données ? (région cloud précise, pas « UE »)
- Quelle est la politique en cas de demande d'accès par une autorité étrangère ? (contestation, notification, gag orders)
- Puis-je auditer ces pratiques ?
Les fournisseurs sérieux répondent sous 48 h par écrit. Les autres sont à écarter.
Ce qu'en dit la Commission européenne et la CNIL
La Commission européenne, dans ses communications sur la souveraineté numérique (2022-2025), identifie le CLOUD Act comme un risque structurel pour le RGPD et la souveraineté des données européennes.
La CNIL, dans ses recommandations sur les outils d'IA (2024-2025), invite les responsables de traitement à évaluer explicitement le risque CLOUD Act dans leur DPIA lorsqu'un sous-traitant est susceptible d'y être soumis.
L'ANSSI a développé la certification SecNumCloud qui impose explicitement qu'un prestataire certifié ne soit pas soumis à des législations extra-européennes. Pour les cabinets qui veulent aller plus loin, choisir un fournisseur certifié SecNumCloud est l'option la plus rigoureuse.
Pour aller plus loin
- Pourquoi votre IA juridique doit être hébergée en Europe — analyse complète hébergement & souveraineté
- RGPD et IA juridique : la checklist complète pour avocats — les 10 obligations concrètes
- IA et secret professionnel : les 7 vérifications à faire — la checklist déontologique
- Notre page sécurité et notre DPA-type
Sources citées
- 01.CLOUD Act — Clarifying Lawful Overseas Use of Data Act (H.R.4943)— Congress.gov · consulté le 2026-09-06
- 02.Arrêt Schrems II (C-311/18) — invalidation du Privacy Shield— Cour de justice de l'Union européenne · consulté le 2026-09-06
- 03.Référentiel SecNumCloud— ANSSI · consulté le 2026-09-06
- 04.Recommandations sur les outils d'IA— CNIL · consulté le 2026-09-06

