« Nos données sont hébergées en Europe, donc on est tranquilles. »
C'est la phrase qu'on entend le plus souvent en rendez-vous — chez des DSI, des DPO, des directions juridiques. Elle est rassurante, elle figure souvent noir sur blanc dans la documentation commerciale du fournisseur. Et elle est fausse.
Ce que dit vraiment le Cloud Act
Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) est une loi américaine qui permet aux autorités des États-Unis d'exiger d'un fournisseur soumis à la juridiction américaine la communication de données qu'il détient ou contrôle, où que ces données soient stockées dans le monde.
Le critère n'est pas géographique. Il est juridique :
- La question n'est pas « où sont les serveurs ? »
- La question est « qui opère le service, et sous quel droit ? »
Un datacenter à Paris, à Francfort ou à Dublin opéré par un fournisseur américain — ou par sa filiale européenne — reste dans le champ du droit américain. La localisation du disque dur ne change rien à la nationalité de l'obligation légale.
« Mais on a signé un DPA » — pourquoi le contrat ne suffit pas
L'objection classique : « notre contrat prévoit que les données restent en Europe, nous avons un DPA, des clauses contractuelles types, une certification. »
Un DPA encadre une relation commerciale entre deux parties privées. Il ne prime pas sur une loi. Si une autorité américaine adresse une injonction valide à un fournisseur soumis à sa juridiction, le fournisseur doit y répondre — le contrat signé avec vous n'y change rien, et dans certains cas il n'a même pas le droit de vous en informer (gag order).
C'est le point que beaucoup de documentation commerciale entretient dans le flou : les engagements contractuels de localisation sont réels et utiles, mais ils sont une protection commerciale, pas une protection structurelle.
Le RGPD et le Cloud Act sont d'ailleurs en tension frontale : ce que l'un interdit (transfert non encadré vers un pays tiers), l'autre peut l'exiger. L'entreprise cliente se retrouve au milieu.
Qui est concerné, concrètement
Si vos usages se limitent à des données publiques ou anodines, ce débat est théorique. Il cesse de l'être dès que vous manipulez :
- du secret professionnel (avocats, notaires, experts-comptables),
- des données de santé (HDS, dossiers patients),
- des dossiers M&A et données financières non publiques,
- des données RH et des contentieux en cours,
- des données réglementées (défense, OIV, secteur public).
Pour ces catégories, la question « qui opère l'infrastructure et sous quel droit ? » n'est pas un détail juridique. C'est un critère d'audit, une exigence d'assureur, et de plus en plus souvent une question posée par vos propres clients.
Le cas particulier de l'IA : vos prompts sont des données
Le sujet devient brûlant avec l'IA générative, pour une raison simple : un prompt est souvent plus sensible qu'un fichier.
Quand un collaborateur demande à un assistant IA « résume ce pacte d'actionnaires » ou « analyse ce reporting avant le comité », il transmet en une requête ce qu'un attaquant mettrait des semaines à assembler : le document, le contexte, l'intention. Si cet assistant est opéré par un fournisseur soumis au Cloud Act, toute cette matière entre dans le champ décrit plus haut — même si le serveur d'inférence est physiquement en Europe.
C'est vrai pour les outils grand public utilisés en shadow AI, mais aussi pour des déploiements « entreprise » dont l'opérateur reste américain.
La seule protection structurelle : que les données ne sortent pas
Il n'existe que deux réponses robustes au Cloud Act, et elles reviennent au même principe : retirer vos données du champ d'application. C'est d'ailleurs la logique de la qualification SecNumCloud de l'ANSSI, qui exige explicitement une immunité aux législations extraterritoriales et un contrôle capitalistique européen.
1. Un opérateur européen, de bout en bout. Fournisseur de droit français ou européen, hébergement chez un cloud européen (OVHcloud, Scaleway…), sans société mère américaine dans la chaîne. Le droit américain n'a alors pas de point d'appui.
2. L'on-premise. Le logiciel tourne sur vos propres serveurs, dans votre périmètre. Il n'y a tout simplement pas de fournisseur tiers à qui adresser une injonction : vos prompts, vos documents et vos réunions ne transitent par personne.
C'est l'architecture d'Eridia : opérateur français, plateforme déployée sur votre infrastructure ou hébergée en France, modèles open-source exécutés dans votre périmètre via Ollama ou vLLM en configuration 100 % souveraine. Opérateur français, hébergement français, droit français — la protection tient par construction, pas par contrat.
Trois questions pour votre prochain comité
Avant de trancher un choix d'outil IA, posez ces trois questions à votre fournisseur — les réponses tiennent en une ligne chacune :
- Quelle entité juridique opère le service, et de quel droit relève-t-elle ? (Y compris la société mère.)
- Où tournent les modèles d'IA, et qui opère cette infrastructure ? (L'interface peut être européenne et l'inférence américaine.)
- Pouvez-vous démontrer qu'aucune donnée ne sort de notre périmètre ? (Logs, architecture, déploiement on-premise possible.)
Si l'une de ces réponses est floue, vous avez votre réponse.
Et si vous voulez vérifier où vous en êtes, nous faisons un diagnostic gratuit de vos flux de données IA — qui opère quoi, sous quel droit, et ce qu'il faudrait déplacer.
