Ne plus être en infraction avec les lois UE sur la protection des données privées, face aux privilèges et abus de l’IA américaine (US CLOUD ACT)

Cet article est également publié en anglais, sous le même titre : version anglaise.

L’obligation, exactement

L’article 44 du RGPD n’énonce pas un principe : c’est une condition. Un transfert vers un pays tiers ne peut avoir lieu que si le chapitre V est respecté. Pour le cas UE, États-Unis, il reste deux voies : la décision d’adéquation (la décision d’exécution (UE) 2023/1795 de la Commission, qui couvre les transferts vers les organismes certifiés au titre du Data Privacy Framework, et dont la Commission doit suivre l’exécution en continu avec obligation de la suspendre, l’amender ou l’abréger si nécessaire, article 3(1) et (5)) ; et les garanties appropriées : les clauses contractuelles types (CCT), auxquelles s’ajoute, depuis Schrems II (C-311/18), une évaluation d’impact du transfert puis, s’il le faut, des mesures complémentaires de nature à garantir un niveau de protection essentiellement équivalent à celui du droit de l’Union.

Les recommandations 01/2020 du CEPB posent la feuille de route, connaître le transfert, identifier l’outil, évaluer la loi et la pratique dans le pays de destination, adopter les mesures complémentaires utiles, puis réévaluer régulièrement le résultat, et elles disent explicitement qu’une mesure prise isolément ne suffit pas à elle seule. Autrement dit : une organisation européenne qui fait appel à un service d’IA hébergé aux États-Unis n’est pas « à l’abri » parce qu’elle a signé des CCT. Elle doit évaluer si les pouvoirs d’accès aux données reconnus à l’administration américaine de son fournisseur font obstacle à ce que la protection promise soit effective, et le documenter d’une manière que son autorité de contrôle puisse auditer.

Le piège du CLOUD Act, dans le texte de la loi elle-même

18 U.S.C. § 2713, ajouté par le CLOUD Act en mars 2018, tient en une phrase volontairement très large :

« A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States. »

C’est ce dernier membre de phrase qui crée le piège : un centre de données européen exploité par un fournisseur sous contrôle américain ne met pas fin à l’exposition, car ce qui compte est la maîtrise que le fournisseur a de la donnée, la « possession, la garde ou le contrôle », et non l’emplacement du rack. Les engagements commerciaux (« vos données restent dans l’UE ») sont contractuels, non juridictionnels : ils déplacent la question de savoir qui peut être contraint de produire, mais ils ne suppriment pas l’obligation de produire. Et cette obligation est large : le § 2713 vise les enregistrements « relatifs à un client ou abonné », ce qui correspond exactement à la surface sur laquelle un fournisseur d’IA se trouve quand il conserve nos invites, fichiers, plongements et sorties dans son stockage.

Ce sont les deux pouvoirs de surveillance examinés par Schrems II, l’article 702 de la FISA et la collecte en masse prévue par l’Executive Order 12333, qui expliquent l’échec répété des nuages américains devant le droit européen, dans nos pages de confidentialité comme ailleurs. La première décision (Schrems I, C-362/14, Safe Harbour) comme la seconde (Schrems II, C-311/18, Privacy Shield) ont annulé les bases d’adéquation précisément parce que ces pouvoirs ne présentaient pas les garanties équivalentes qu’exige le droit de l’UE, notamment un contrôle indépendant suffisant.

Pourquoi le socle du DPF se déplace sous nos pieds

Le cadre actuel est fragile publiquement, et c’est pour cela qu’une posture de conformité reposant sur un seul mécanisme est une mauvaise stratégie.

• Les juridictions n’ont jamais jugé que le passé. Dans Latombe c. Commission (T-553/23), le Tribunal a débouté le recours le 3 septembre 2025 et confirmé la décision d’adéquation dans son ensemble, mais son contrôle était explicitement limité à la situation factuelle et juridique telle qu’elle existait au moment de l’adoption par la Commission, en 2023, et il n’a pas dit un mot du fonctionnement concret des garanties. Il a aussi laissé ouverte la recevabilité (la qualité pour agir), ce qui permet toujours une relance ultérieure.
• L’indépendance institutionnelle américaine est désormais discutée. Le 29 juin 2026, la Cour suprême des États-Unis a rendu Trump v. Slaughter : les protections légales contre le retrait motivé des membres de la FTC sont inconstitutionnelles et ces derniers sont désormais révocables sans motif ; l’arrêt Humphrey’s Executor (1935) est renversé. L’argument s’écrit tout seul côté européen : la décision de 2023 s’appuyait sur une autorité de contrôle « indépendante » (considérant 60 à propos de la FTC), et si cette indépendance disparaît, le socle de la constatation d’adéquation se fragilise. La lecture de l’équipe Skadden, « au moins une possibilité raisonnable » pour que la CJUE censure quand elle sera saisie, est ce qui tient lieu de conseil pratique ; Max Schrems a déjà annoncé son intention d’ester après cette décision.
• La Commission elle-même doit surveiller. L’article 3 de la décision lui impose une surveillance continue et, le cas échéant, de l’amender ou de l’abroger. Ce devoir a été exercé lors du premier réexamen périodique : le rapport (COM(2024) 451) et le rapport du CEPB sur ce réexamen figurent désormais au dossier public des deux côtés de l’Atlantique.

Rien de tout cela ne rend les transferts illicites aujourd’hui. Cela veut dire qu’une posture fondée sur la seule certification DPF est à un arrêt près de rester sans appui, d’où, pour les organisations sérieuses, les CCT en parallèle (« ceinture et double ceinture »), et des évaluations d’impact et des cartographies de flux à jour.

Ce que change réellement une inférence locale

Si le modèle tourne sur du matériel que vous exploitez, dans la juridiction où vous vous trouvez, il ne se produit aucun transfert au chapitre V pour ce qui reste chez vous : il n’y a pas de trajet exportateur → importateur à évaluer, donc pas d’adéquation à invoquer, pas de CCT à signer, pas d’évaluation d’impact à rédiger ni de mesures complémentaires à défendre. Le fournisseur n’acquiert jamais la « possession, la garde ou le contrôle » de vos invites au sens du § 2713, puisqu’il n’y a aucun fournisseur pour les détenir. C’est tout l’argument des modèles locaux ; et c’est ce qui rend un déploiement isolé (air gapé) si simple à auditer : sans sous-traitant hébergé chez un cloud dans le périmètre, sans remise à tiers de données médicales ou salariales, les garanties HIPAA et les contrôles ISO / SOC 2 se démontrent dans vos locaux, pas dans la documentation d’un fournisseur.

Cela change aussi ce que vous pouvez dire à un régulateur. On ne défend plus une argumentation sur l’indépendance suffisante d’un organisme étranger ; on décrit un fait tenu chez soi : où sont les poids du modèle, sur quelle machine ils tournent, qui peut lire les journaux.

Ce que cela ne change pas

Le local n’est pas une conclusion juridique, et ce qui déborde n’est presque jamais le modèle :

• Le RGPD s’applique toujours chez vous, licéité, limitation des finalités, sécurité, droits des personnes, notification des violations. Un déploiement local décale l’analyse du transfert ; il ne rend pas le traitement conforme à lui-même, et NIS2 et les règles sectorielles restent applicables.
• Les plans de contrôle débordent : la télémétrie de l’éditeur, l’observabilité managée, les bases vectorielles hébergées chez un tiers, l’inférence payée via une API (même annoncée « zone EEE »), et le réglage fin (fine-tuning) via API, tout cela est un transfert. Le défaut le plus courant consiste à garder les poids du modèle chez soi tout en envoyant chaque journal d’invites vers un tableau de bord SaaS.
• Les chaînes hybrides débordent en deux endroits : les plongements et les index RAG sont des données personnelles eux aussi, et leurs sauvegardes dorment souvent dans une autre région.
• La capacité des modèles est un arbitrage réel, pas une formalité : un modèle à poids ouverts exploité sur une carte de 8 GB ne soutiendra pas la comparaison avec une API frontière pour les tâches difficiles. Nos propres notes sur Strata, Avalon et la quantification GSQ-RCO sont le compte rendu de ce que le matériel local sait faire, y compris l’écart mesuré entre deux formats sur un fichier de même taille (un build à 367 jetons/s en lecture des invites, un autre à 108), exactement le genre de chose qu’il faut savoir avant de choisir un modèle et son format.

La check-list que j’utilerais vraiment

1. Recenser tout ce qui sort de votre réseau, invites, fichiers, plongements, journaux, télémétrie, sauvegardes, et nommer la juridiction de chaque destination.
2. Si quelque chose doit aller chez un fournisseur sous contrôle américain : s’appuyer sur le DPF et sur les CCT, faire l’évaluation d’impact, documenter les mesures complémentaires (clés tenues par vous, pseudonymisation avant transfert, pas de traitement en clair en mémoire), puis réévaluer régulièrement.
3. Considérer que la base d’adéquation peut tomber, c’est à quoi servent le pourvoi contre Latombe et Trump v. Slaughter. Concevoir pour que CCT et évaluation documentée tiennent encore si cela arrive.
4. Pour les données régulées, médicales, sociales, contractuelles, financières, déplacer l’inférence et le stockage vers des systèmes que vous exploitez : sur site ou matériel sous contrôle EEE, modèles à poids ouverts, sans sous-traitant hébergé chez un cloud dans le périmètre.
5. Garder la preuve d’audit chez vous : configuration, journaux d’accès, durées de rétention, et la trace de qui a fait quoi avec quel modèle.

La position de conformité tient en un mot : on ne se défait pas par un contrat d’une obligation légale américaine de produire ; on se défit, par l’architecture, du transfert auquel cette obligation s’applique. Des modèles à poids ouverts sur des machines Linux que vous administrez ne sont pas une scène de théâtre de la vie privée : c’est la seule configuration où la question du § 2713 ne se pose jamais, parce que la donnée n’a jamais été sous la maîtrise d’autrui.

Sources

• 18 U.S.C. § 2713 (conservation et divulgation obligées des communications et enregistrements), via Cornell LII : https://www.law.cornell.edu/uscode/text/18/2713
• Recommandations 01/2020 du CEPB sur les mesures complémentaires aux outils de transfert : https://www.edpb.europa.eu/system/files/2021-06/edpbrecommendations202001vo.2.0supplementarymeasurestransferstoolsen.pdf
• Décision d’exécution (UE) 2023/1795 de la Commission (adéquation Data Privacy Framework UE, États-Unis), y compris les obligations de suivi de l’article 3 et le considérant 60 sur la FTC, cités dans la note Skadden ci-dessous.
• Skadden, « Supreme Court Decision Raises New Questions for EU-US Data Transfers », 28 juillet 2026 : https://www.skadden.com/insights/publications/2026/07/supreme-court-decision-raises-new-questions
• CiTiP (KU Leuven), « EU, US Data Transfers Survive: What Latombe Really Tells Us », 27 janvier 2026 : https://www.law.kuleuven.be/citip/blog/eu-us-data-transfers-survive-what-latombe-really-tells-us/
• Rapport de la Commission sur le premier réexamen périodique de la décision d’adéquation DPF UE, États-Unis, COM(2024) 451 : https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A52024DC0451
• Rapport du CEPB sur le premier réexamen de la décision d’adéquation, 4 novembre 2024 : https://www.edpb.europa.eu/system/files/documents/2024-11/edpbreport20241104reportonfirstreviewofeu-u.s.dpfen.pdf
• Nos propres pages de confidentialité (EN/FR/ES/CA) sur la FISA 702 et le CLOUD Act : https://localai.hex7.com/privacy.html