Imaginez la scène. Votre équipe vient de déployer un système RAG (Retrieval-Augmented Generation) pour assister vos juristes internes. La base de connaissances contient vos brevets en cours d'instruction, vos plans stratégiques à trois ans, les comptes-rendus de comité de direction, peut-être des données RH. L'infrastructure tourne sur une machine virtuelle Azure dans la région France Central — un datacenter physiquement situé à Paris. Vous avez signé un DPA avec Microsoft conformément au RGPD. Votre RSSI a validé le chiffrement en transit et au repos. Vous vous sentez protégé.
Vous avez tort. Non pas parce que le RGPD est inefficace, mais parce qu'une loi américaine adoptée en 2018 — le CLARIFYING LAWFUL OVERSEAS USE OF DATA Act, dit Cloud Act — crée un mécanisme légal qui contourne entièrement la géographie physique de vos données. Et si vous utilisez un cloud américain, ce mécanisme vous concerne directement.
Qu'est-ce que le Cloud Act ?
Le Cloud Act a été signé par Donald Trump le 23 mars 2018, annexé discrètement à un projet de loi de financement du gouvernement fédéral. Son nom complet — Clarifying Lawful Overseas Use of Data Act — donne le ton : il s'agit de clarifier la capacité des autorités américaines à accéder à des données stockées à l'étranger par des opérateurs sous juridiction américaine.
Le mécanisme central est d'une brutalité juridique remarquable. La loi amende directement le Stored Communications Act de 1986 pour y préciser que les prestataires soumis à la juridiction américaine (c'est-à-dire dont le siège social, les actionnaires majoritaires ou les organes de direction sont américains) doivent conserver, sauvegarder et divulguer le contenu des communications et enregistrements électroniques en leur possession, garde ou contrôle — où qu'ils soient physiquement stockés.
La distinction avec les demandes d'entraide judiciaire classiques (les MLAT — Mutual Legal Assistance Treaties) est fondamentale. Un MLAT suppose une coopération bilatérale entre États : les autorités américaines font une demande formelle aux autorités du pays où se trouve le prestataire, qui instruit la demande selon son droit national. Ce processus peut prendre des mois, voire des années, et le pays sollicité peut refuser. Le Cloud Act, lui, court-circuite entièrement ce mécanisme : la demande est adressée directement à l'entreprise américaine, sans passer par les autorités du pays hébergeant les données.
« Il ne s'agit pas d'un risque théorique. Il s'agit d'une obligation légale directe, opposable à chaque ingénieur AWS ou Azure qui reçoit un warrant américain. »
Concrètement : le FBI, le DOJ ou tout autre organe fédéral américain peut adresser à Microsoft, Amazon ou Google un mandat (warrant) ou une ordonnance de communication (order) ciblant des données stockées dans votre datacenter parisien. Microsoft, Azure et Google ont l'obligation légale de répondre — ou de contester le mandat devant un tribunal américain, ce qui constitue un processus long et incertain.
Le mythe du chiffrement
L'argument le plus fréquemment avancé en réunion de COMEX tient en une phrase : « nos données sont chiffrées, donc même si quelqu'un y accède, il ne voit rien. » C'est une erreur de compréhension fondamentale du modèle de menace.
Le chiffrement au repos (encryption at rest) proposé par AWS, Azure ou GCP est réel et solide techniquement. Mais voici le détail qui change tout : l'opérateur détient les clés de chiffrement. Dans la configuration par défaut de la quasi-totalité des services cloud grand public, les clés sont générées, stockées et gérées par le prestataire lui-même dans son propre service de gestion de clés (KMS). Lorsqu'une autorité américaine exige la communication des données, elle peut exiger simultanément la communication des clés. Le chiffrement devient alors inopérant.
Il existe une alternative technique plus robuste : le chiffrement côté client avec vos propres clés (Customer-Managed Keys, ou CMK, voire Hold Your Own Key, HYOK). Dans ce modèle, votre organisation génère et conserve les clés ; l'opérateur cloud n'y a jamais accès. Techniquement, cela rend la communication de données en clair impossible pour le prestataire. Mais cette protection reste incomplète pour un système d'IA : les logs d'inférence, les requêtes envoyées au modèle, les vecteurs d'embedding — ces éléments circulent souvent en clair dans les couches applicatives, hors du périmètre CMK.
Ce que ça change pour les systèmes d'IA d'entreprise
Un système RAG n'est pas une simple base de données. C'est une infrastructure de traitement sémantique qui ingère, découpe, encode et indexe vos documents internes. Chaque pièce de l'architecture présente une surface d'exposition spécifique.
Les documents sources sont les plus évidents : contrats clients, procès-verbaux de CA, brevets, rapports cliniques, codes source propriétaires. Ces fichiers sont stockés dans un object store (S3, Azure Blob) soumis au Cloud Act.
Les index vectoriels sont moins intuitifs, mais potentiellement plus sensibles. Un vecteur d'embedding est une représentation mathématique du sens d'un texte. Des chercheurs ont démontré que, dans certaines configurations, il est possible de reconstruire partiellement le texte original à partir de ses embeddings. Votre index vectoriel — stocké dans une base comme Pinecone, Weaviate ou pgvector hébergée sur un cloud américain — est une représentation sémantique de l'ensemble de vos connaissances internes.
Les logs d'inférence constituent la troisième surface. Chaque requête envoyée à votre pipeline RAG — y compris par vos salariés — peut être loguée par l'infrastructure cloud. Ces logs contiennent non seulement les questions posées, mais parfois les passages de documents retournés en contexte.
Le risque n'est pas uniforme selon les secteurs. Le tableau ci-dessous synthétise les expositions les plus critiques.
Les alternatives souveraines
La bonne nouvelle : des alternatives existent, matures, et adaptées aux exigences de performance d'un pipeline RAG en production. Le critère discriminant n'est pas le pays du datacenter, mais la nationalité juridique de l'opérateur.
OVHcloud est une société de droit français, dont aucune entité mère n'est soumise à la juridiction américaine. Elle propose des gammes de serveurs dédiés et cloud public avec SLA de niveau entreprise, adaptés à l'hébergement de bases vectorielles et de modèles de langage ouverts (Mistral, LLaMA).
Scaleway (groupe Iliad) offre une alternative cloud public full-stack avec des instances GPU pour l'inférence, des services de stockage objet et une API compatible S3 — permettant une migration quasi-transparente depuis AWS.
3DS Outscale (groupe Dassault Systèmes) est le seul cloud français qualifié SecNumCloud par l'ANSSI, le niveau de certification le plus exigeant de l'État français pour les données les plus sensibles. Cette qualification s'accompagne d'une garantie de non-soumission à des législations extra-européennes.
Enfin, pour les organisations dont la sensibilité des données est maximale (défense, souveraineté nationale, secret médical), l'hébergement on-premise reste la seule option sans risque résiduel. Les modèles ouverts comme Mistral 7B ou Mixtral peuvent être déployés sur un parc GPU interne avec des performances tout à fait compétitives pour des usages RAG internes.
Ce qu'il faut exiger d'un prestataire cloud souverain
- Entité juridique européenne sans maison mère ni filiale soumise à la juridiction américaine
- Absence de tout accord de transfert de données vers les États-Unis (SCCs actives vers des entités US = risque)
- Qualification SecNumCloud (pour les données les plus sensibles) ou ISO 27001 + HDS (secteur santé)
- Gestion des clés de chiffrement exclusivement côté client (BYOK / HYOK disponible)
- Clause contractuelle explicite garantissant la non-réponse aux demandes extra-européennes sans notification préalable au client
- Localisation des données garantie contractuellement dans l'UE, avec audit possible
- Engagement de transparence sur les demandes d'accès aux données (transparency report)
Ce que DEEP-5 fait concrètement
Chez DEEP-5, la souveraineté des données n'est pas un argument commercial — c'est une contrainte d'architecture que nous appliquons par défaut. Voici notre politique opérationnelle.
Par défaut, toutes nos missions de déploiement RAG sont hébergées sur OVHcloud ou Scaleway, ou en on-premise chez le client si la sensibilité des données le justifie. L'utilisation d'un cloud américain (AWS, Azure, GCP) n'est envisagée que sur demande explicite et documentée du client, après que celui-ci a été informé par écrit des risques Cloud Act associés.
Notre contrat de traitement des données (DPA) contient une clause Cloud Act spécifique : nous décrivons explicitement les risques liés à l'utilisation éventuelle d'opérateurs soumis à la juridiction américaine, nous engageons à notifier immédiatement tout changement d'infrastructure pouvant modifier l'exposition, et nous décrivons les mesures techniques compensatoires mises en œuvre (chiffrement CMK, isolation réseau, minimisation des logs).
Sur le plan du conseil, nous accompagnons nos clients dans le choix de leur infrastructure dès la phase de cadrage : analyse des données traitées, classification selon la sensibilité, mapping des risques Cloud Act, et recommandation d'architecture souveraine adaptée à leur secteur et à leur budget.
La question n'est pas de savoir si le Cloud Act va affecter votre organisation — c'est de savoir si vous avez pris la décision en connaissance de cause. Le risque zéro n'existe pas, mais le risque non évalué, lui, est inexcusable.