RGPD contre CLOUD Act : pourquoi la région de votre fournisseur IA ne garantit rien

L'emplacement d'un data center indique où sont les serveurs, pas quel gouvernement peut en exiger l'accès. Cette seconde question dépend de la juridiction de l'entreprise — qui possède et exploite la société qui opère les serveurs — pas de la géographie. Une région UE opérée par une société dont le siège est aux États-Unis reste atteignable par une injonction judiciaire américaine au titre du CLOUD Act, quel que soit l'endroit où les disques se trouvent physiquement. Si la réponse de votre fournisseur IA à « êtes-vous conforme RGPD ? » s'arrête à « nos serveurs sont à Francfort », vous n'avez obtenu aucune réponse à la question de juridiction.

Comment le CLOUD Act atteint réellement des données en UE

Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act) américain, promulgué en mars 2018, modifie le Stored Communications Act pour permettre aux autorités judiciaires américaines d'obliger un fournisseur basé aux États-Unis à produire des données qu'il possède, détient ou contrôle — « que cette communication, cet enregistrement ou toute autre information soit situé à l'intérieur ou à l'extérieur des États-Unis ». Le texte ne demande pas où se trouve le serveur. Il demande si l'entité qui peut accéder aux données est soumise à la procédure judiciaire américaine.

C'est ce mécanisme qui compte pour une décision d'achat : une citation à comparaître ou un mandat signifié au siège d'une société américaine engage les opérations mondiales de cette société, y compris une filiale ou une entité européenne techniquement distincte qu'elle contrôle. L'emplacement du data center ne change rien à la chaîne juridique — il ne change que le chemin que doit parcourir la demande avant d'être exécutée.

Ce que le RGPD exige réellement

Le RGPD (règlement (UE) 2016/679) régit un problème différent : il restreint les transferts de données personnelles hors de l'UE/EEE (chapitre V, articles 44 à 50), sauf mécanisme de transfert valide — décision d'adéquation, clauses contractuelles types, ou règles d'entreprise contraignantes. Il ne dit rien directement sur quel gouvernement peut signifier une citation à comparaître à votre sous-traitant. Une société peut être parfaitement conforme RGPD sur le papier — contrats en règle, résidence des données en UE, mécanisme de transfert valide pour les flux résiduels — tout en étant une société américaine soumise à la procédure du CLOUD Act. Les deux cadres répondent à des questions différentes, et satisfaire l'un ne répond pas à l'autre.

Pourquoi le cadre transatlantique s'effondre à répétition

L'UE et les États-Unis ont tenté à trois reprises de combler cet écart par un cadre d'adéquation formel pour les transferts vers des sociétés américaines : le Safe Harbor (invalidé par la CJUE en 2015, arrêt Schrems I), le Privacy Shield (invalidé en 2020, arrêt Schrems II), et l'actuel EU-US Data Privacy Framework, adopté par la Commission européenne en 2023. À chaque fois, la contestation est revenue sur le même point structurel : le droit américain de surveillance donne aux autorités américaines un accès à des données détenues par des sociétés américaines que le droit européen ne juge pas proportionné ni assorti d'un recours adéquat.

Le Data Privacy Framework est, mi-2026, toujours formellement en vigueur — le Tribunal de l'UE a rejeté un recours direct en annulation (Latombe contre Commission) en septembre 2025, jugeant suffisants le mécanisme de recours indépendant et les limites de collecte de données américaines. Mais le requérant a fait appel devant la Cour de justice de l'UE (affaire C-703/25 P, déposée en octobre 2025), sans date d'audience fixée à l'heure où ces lignes sont écrites. Si la CJUE tranche en sa défaveur, ce serait la troisième invalidation consécutive d'un cadre de transfert transatlantique en une décennie. Ce schéma est lui-même le signal : l'incompatibilité de fond entre le droit américain de surveillance et le droit européen de protection des données n'a été résolue par aucune des trois tentatives — elle a été mise en pause, puis contestée, à chaque fois.

Pour une entreprise qui prend une décision d'infrastructure sur plusieurs années, parier sur la tenue du cadre actuel revient à parier sur l'issue d'un appel précis, pendant devant la plus haute juridiction européenne. Choisir une infrastructure qui n'est pas soumise, à la base, au conflit de juridiction sous-jacent permet d'éviter ce pari entièrement.

La réponse française : SecNumCloud et l'exigence d'« immunité »

L'agence nationale française de cybersécurité, l'ANSSI, gère une qualification cloud appelée SecNumCloud. Sa révision majeure la plus récente (v3.2) a ajouté une exigence explicite : le niveau de confiance le plus élevé doit être exempt de tout contrôle capitalistique ou juridique non-UE — pas seulement une résidence des données, mais une « immunité » de propriété et de juridiction vis-à-vis du droit non-UE. C'est l'articulation officielle la plus claire de la distinction exacte que cet article établit : le lieu d'hébergement et l'exposition juridique sont deux axes différents, et un référentiel de souveraineté sérieux doit préciser les deux.

Bleu, S3NS, et pourquoi « cloud français » n'est pas automatiquement souverain

Deux projets français très médiatisés de « cloud souverain » illustrent pourquoi cette distinction est contestée en pratique, pas seulement en théorie. Bleu est une coentreprise entre Orange et Capgemini exploitant la technologie Microsoft Azure sous licence. S3NS est une coentreprise entre Thales et Google exploitant la technologie Google Cloud sous licence. Les deux sont immatriculées et opérées en France, présentées comme des offres souveraines en voie de qualification SecNumCloud — et les deux ont fait l'objet de critiques soutenues, précisément parce que la pile technologique sous-jacente est licenciée auprès d'un hyperscaler américain, ce qui pose la même question de « qui contrôle réellement » que l'exigence d'immunité de SecNumCloud a été écrite pour trancher. La controverse ne porte pas sur l'emplacement de leurs data centers (la France) — elle porte sur la question de savoir si une relation de licence avec un fournisseur technologique américain réintroduit l'exposition que l'exigence de souveraineté était censée éliminer.

La leçon dépasse ces deux cas : la page marketing d'un fournisseur peut dire « hébergé en UE », « souverain » ou « conforme RGPD » tout en ne décrivant que l'axe résidence des données, en laissant l'axe propriété/juridiction sans réponse — parfois parce que tout va bien, parfois non, et la page ne dit pas lequel.

Comment vérifier concrètement un fournisseur

Quatre questions permettent d'obtenir l'essentiel d'une vraie réponse, à peu près dans l'ordre où il vaut la peine de les poser :

• Qui est la société mère ultime, et où est-elle domiciliée ? Une filiale immatriculée en UE d'une société mère américaine reste atteignable via cette société mère par les dispositions de contrôle capitalistique du CLOUD Act.
• Le fournisseur détient-il — ou revendique-t-il l'éligibilité à — le niveau le plus élevé de SecNumCloud, ou une qualification équivalente strictement UE ? Ce niveau exige spécifiquement le test de non-contrôle non-UE décrit ici ; un niveau inférieur ou un simple badge auto-déclaré « cloud UE » ne l'exige pas.
• Une partie de la pile technique est-elle licenciée auprès d'un fournisseur technologique non-UE ? Comme le montre le cas Bleu/S3NS, une dépendance de licence peut compter même quand l'entité opératrice est réellement immatriculée en UE.
• Que dit le contrat sur qui répond à une demande de données d'un gouvernement étranger, et selon quelle procédure ? Un fournisseur confiant dans sa propre position aura une réponse claire et précise ici — pas une déclaration de conformité générale.

Rien d'exotique dans cette diligence — c'est la même distinction qu'un DPO applique déjà à tout flux de données transfrontalier, simplement appliquée à la couche infrastructure plutôt qu'au contrat de transfert de données.

FAQ