Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) est une loi fédérale américaine de mars 2018. Elle permet aux autorités américaines d'exiger d'un fournisseur de services soumis au droit des États-Unis la communication de données qu'il contrôle, y compris lorsqu'elles sont stockées hors du territoire américain, par exemple dans un datacenter en Europe.
Pour une entreprise française qui déploie un chatbot ou un outil IA, la question utile n'est donc pas seulement « où sont stockées mes données ? », mais aussi « quelle société les contrôle, et à quel droit est-elle soumise ? ». Cet article pose le cadre juridique, puis le traduit en questions concrètes à poser à un fournisseur.
Cet article est une information générale, pas un conseil juridique. Pour un cas précis (données de santé, secteur public, contrat sensible), appuyez-vous sur votre DPO ou un avocat spécialisé.
Sommaire
- Cloud Act : définition et fonctionnement
- Qui est concerné, même avec des données hébergées en Europe ?
- Cloud Act, RGPD (article 48) et Data Privacy Framework
- Ce que ça change pour un chatbot ou un outil IA
- Checklist : 10 questions à poser à votre fournisseur
- Notre position : ce que Heeya fait et ne fait pas
- FAQ : Cloud Act et outils IA
Cloud Act : définition et fonctionnement
Le CLOUD Act a été adopté en 2018, dans le cadre d'une loi de finances américaine. Son texte est consultable sur le site du Congrès américain. Il fait deux choses distinctes.
- Il affirme la portée extraterritoriale des réquisitions américaines. Un fournisseur de communications électroniques ou de services informatiques à distance soumis au droit américain doit communiquer les données demandées dans une procédure pénale américaine (« possession, custody, or control »), quel que soit le lieu de stockage.
- Il crée un cadre d'accords bilatéraux (« executive agreements ») avec des États étrangers, pour faciliter l'accès réciproque aux données dans les enquêtes sur les infractions graves.
Le texte prévoit aussi des voies de recours : un fournisseur peut contester une demande s'il estime qu'elle l'oblige à violer la loi d'un pays étranger avec lequel les États-Unis ont conclu un accord, ou si la personne visée n'est pas américaine. Ces recours sont encadrés, et leur portée réelle pour un client européen reste discutée par les juristes.
Le CLOUD Act ne donne pas un accès libre aux données : il faut une procédure judiciaire américaine (mandat, injonction). Mais il lève l'argument selon lequel « les données sont en Europe, donc hors de portée ».
Qui est concerné, même avec des données hébergées en Europe ?
Le critère n'est pas la localisation du serveur, mais le contrôle : sont visées les entreprises soumises à la juridiction américaine, c'est-à-dire de droit américain ou ayant un lien suffisant avec les États-Unis. Concrètement :
- Les grands fournisseurs cloud américains et leurs régions européennes (AWS, Microsoft Azure, Google Cloud), puisque l'opérateur reste une société du groupe américain.
- Les éditeurs SaaS de droit américain, même s'ils choisissent un datacenter UE.
- Les fournisseurs de modèles de langage américains (par exemple OpenAI ou Google pour Gemini) pour les requêtes qu'ils traitent.
À l'inverse, un hébergeur dont le capital et le siège sont en Europe, sans lien de contrôle avec un groupe américain, est en principe moins exposé. Je dis « en principe » : un fournisseur européen qui utilise lui-même un sous-traitant américain (pour un modèle, un service de messagerie, de l'analytique) recrée un point d'exposition. C'est toute la chaîne qui compte, pas seulement le premier maillon.
| Situation | Exposition potentielle au CLOUD Act |
|---|---|
| Société américaine, datacenter aux États-Unis | Oui |
| Société américaine, datacenter en Europe | Oui, le lieu de stockage ne change pas le critère de contrôle |
| Société européenne, hébergement européen, sans sous-traitant américain | Faible en principe |
| Société européenne, hébergement européen, mais requêtes envoyées à un modèle américain | Oui pour la partie traitée par le fournisseur du modèle |
Cloud Act, RGPD (article 48) et Data Privacy Framework
Le RGPD prévoit expressément ce cas de figure. Son article 48 dispose qu'une décision d'une juridiction ou d'une autorité administrative d'un pays tiers exigeant un transfert ou une divulgation de données personnelles ne peut être reconnue ou rendue exécutoire que si elle repose sur un accord international (par exemple un traité d'entraide judiciaire) entre ce pays et l'Union ou un État membre.
Le Comité européen de la protection des données (CEPD) a publié en décembre 2024 des lignes directrices 02/2024 sur cet article, présentées sur le site de la CNIL. Leur message : une demande directe d'une autorité étrangère ne suffit pas, à elle seule, à justifier un transfert. Il faut aussi une base légale (article 6) et un mécanisme de transfert valide (chapitre V).
Résultat pratique : un fournisseur soumis au CLOUD Act peut se trouver pris entre deux obligations contradictoires. C'est un risque juridique réel pour le client, même si aucune demande n'a été formulée.
Le Data Privacy Framework : statut à octobre 2026
Les transferts de données personnelles vers les États-Unis reposent aujourd'hui principalement sur le Data Privacy Framework (DPF), objet d'une décision d'adéquation de la Commission européenne adoptée en juillet 2023. Elle s'applique aux entreprises américaines qui se sont auto-certifiées.
- Le 3 septembre 2025, le Tribunal de l'Union européenne a rejeté le recours de Philippe Latombe (affaire T-553/23) et confirmé la validité de la décision d'adéquation.
- Un pourvoi a été formé devant la Cour de justice (affaire C-703/25 P). À ma connaissance, à la date de cet article, il est toujours pendant et la décision d'adéquation reste en vigueur.
À retenir : le DPF est valide aujourd'hui, mais son avenir dépend d'une décision de la Cour de justice. Les deux précédents accords (Safe Harbor en 2015, Privacy Shield en 2020) ont été invalidés. Un fournisseur sérieux doit donc pouvoir vous indiquer ses clauses contractuelles types de repli.
Attention : le DPF encadre le transfert vers une entreprise certifiée. Il n'efface pas la question de l'accès par les autorités américaines, qui est précisément celle que pose le CLOUD Act.
Ce que ça change pour un chatbot ou un outil IA
Un outil IA basé sur vos documents (chatbot RAG, assistant interne) comporte au moins trois couches, et chacune peut dépendre d'un opérateur différent.
| Couche | Ce qui y passe | Point de vigilance |
|---|---|---|
| Application et base | Comptes, historique des conversations, paramètres | Hébergeur, pays, société qui opère |
| Documents indexés | Fichiers sources, extraits découpés, vecteurs | Lieu de stockage, accès, suppression |
| Modèle de langage | La question de l'utilisateur et les extraits de documents injectés dans le prompt | Fournisseur du modèle, pays de traitement, journalisation, entraînement |
C'est la troisième couche qui est le plus souvent oubliée. Même si vos documents dorment chez un hébergeur français, chaque réponse générée envoie à l'API du modèle un extrait de ces documents, avec la question posée. Si ce modèle est fourni par une société américaine, ce texte est traité par elle, avec les garanties contractuelles prévues (clauses types, DPF, engagement de non-entraînement), mais dans son périmètre juridique.
Ce que vous pouvez faire concrètement
- Cartographier les trois couches pour chaque outil IA utilisé, y compris ceux adoptés « en douce » par les équipes.
- Trier vos données : une FAQ produit publique ne pose pas le même risque qu'un contrat client, un dossier RH ou des données de santé.
- Minimiser ce qui est indexé : ne pas charger dans un chatbot ce qu'il n'a pas besoin de connaître.
- Choisir un fournisseur de modèle adapté à la sensibilité des données, quand l'outil permet ce choix.
- Documenter : DPA, liste des sous-traitants, analyse d'impact si nécessaire. C'est votre responsabilité de responsable de traitement.
Pour le détail des obligations, voir notre guide chatbot IA et conformité RGPD. Pour les mesures techniques (chiffrement, journalisation, accès), voir la sécurité des données d'un chatbot IA en entreprise.
Checklist : 10 questions à poser à votre fournisseur
À envoyer par écrit avant de signer. Une réponse floue ou « tout est en Europe » sans détail sur le modèle est une information en soi.
- Quelle est la société qui opère le service, son siège et son capital (société européenne, filiale d'un groupe américain) ?
- Qui est l'hébergeur de l'application, de la base de données et des fichiers, et dans quel pays ?
- Quel fournisseur de modèle de langage traite mes requêtes, et dans quel pays ?
- Les extraits de mes documents sont-ils envoyés à ce fournisseur à chaque requête ?
- Puis-je choisir le modèle, ou le désactiver pour certaines données ?
- Les prompts et réponses sont-ils conservés par le fournisseur du modèle, combien de temps, et servent-ils à entraîner des modèles ?
- Quelle est la liste complète des sous-traitants ultérieurs (messagerie, analytique, paiement, support) ?
- Sur quel mécanisme repose chaque transfert hors UE (décision d'adéquation, clauses contractuelles types) et quel est le plan si le DPF était invalidé ?
- Quelle est votre politique face à une demande d'accès d'une autorité étrangère (information du client, contestation, article 48) ?
- Un DPA est-il fourni, et comment supprime-t-on mes données (délais, sauvegardes) en fin de contrat ?
Pour replacer ces critères dans un choix d'outil, voir notre comparatif chatbot IA français vs américain.
Notre position : ce que Heeya fait et ne fait pas
Par cohérence avec cette checklist, voici nos réponses. Heeya est édité par TENSORIA, société française. L'application, la base de données et les documents sont hébergés chez OVH, en France, dans l'Union européenne.
En revanche, pour générer les réponses, le contenu des conversations est envoyé à des fournisseurs de modèles de langage américains (notre politique de confidentialité cite notamment Google et OpenAI), avec les garanties contractuelles prévues : clauses contractuelles types ou adhésion au Data Privacy Framework selon le fournisseur. Ce traitement peut donc avoir lieu hors de l'Union européenne.
Autrement dit : Heeya ne prétend pas échapper au CLOUD Act sur la couche modèle. Nous n'avons aucune certification de type SecNumCloud ou HDS, et nous ne revendiquons pas de conformité certifiée. L'hébergement français réduit l'exposition sur le stockage, il ne la supprime pas sur le traitement par le modèle. Si vos données exigent un traitement sans fournisseur américain, un projet sur mesure avec un modèle hébergé en Europe est une autre voie, à discuter au cas par cas.
Pour comprendre ce que « souverain » peut vouloir dire pour un chatbot, voir chatbot IA et hébergement souverain en France.
FAQ : Cloud Act et outils IA
Cloud Act, c'est quoi en une phrase ?
Une loi américaine de 2018 qui permet aux autorités des États-Unis d'exiger d'un fournisseur de services soumis au droit américain les données qu'il contrôle, même stockées hors des États-Unis, y compris en Europe.
Le Cloud Act s'applique-t-il à des données hébergées en France ?
Il s'applique à l'entreprise qui contrôle les données, pas au serveur. Des données hébergées en France par une filiale d'un groupe américain restent potentiellement concernées. Chez un hébergeur européen sans lien de contrôle américain, l'exposition est en principe plus faible.
Le Cloud Act est-il contraire au RGPD ?
Les deux textes peuvent entrer en conflit. L'article 48 du RGPD n'admet une décision étrangère de divulgation que si elle repose sur un accord international. Le CEPD a publié en 2024 des lignes directrices sur ce point. Un fournisseur soumis aux deux régimes peut se trouver face à des obligations contradictoires.
Le Data Privacy Framework est-il toujours valide en octobre 2026 ?
Oui, la décision d'adéquation reste en vigueur. Le Tribunal de l'UE a rejeté le recours de Philippe Latombe en septembre 2025 ; un pourvoi (C-703/25 P) est pendant devant la Cour de justice. Son issue est incertaine, d'où l'intérêt de clauses contractuelles de repli.
Une IA souveraine est-elle forcément hors de portée du Cloud Act ?
Pas automatiquement. Il faut examiner toute la chaîne : société qui opère le service, hébergeur, fournisseur du modèle de langage, sous-traitants. Une application hébergée en France qui appelle un modèle américain reste exposée sur ce traitement.
Qu'est-ce que la souveraineté numérique pour une PME ?
C'est la capacité à savoir où sont vos données, qui les contrôle, à quel droit cette entité est soumise, et à pouvoir changer de fournisseur. Pour une PME, cela passe moins par une certification que par une cartographie claire des outils et des sous-traitants.
Où vont les documents que je charge dans le chatbot Heeya ?
Les documents et la base sont hébergés chez OVH, en France. Lors d'une réponse, des extraits pertinents et la question sont envoyés au fournisseur du modèle de langage, qui peut être américain et traiter ces données hors de l'UE, avec des garanties contractuelles.
Heeya est-il certifié SecNumCloud ou HDS ?
Non. Heeya ne revendique aucune de ces certifications. Il ne convient donc pas, en l'état, à des données de santé relevant de l'hébergement HDS ni à des exigences de qualification SecNumCloud.
