Cloud Act, RGPD, AI Act, ce que votre DPO devrait vous dire avant de signer un contrat OpenAI.

Cet article ne contient aucun avis juridique. Il a été relu par notre DPO et par un avocat spécialisé en droit des données, mais vous devez consulter le vôtre avant toute décision contractuelle. Ce que je propose ici, c'est une lecture pratique, faite par une praticienne qui aide tous les jours des directions tech à arbitrer entre les fournisseurs IA. C'est le genre de note que j'aurais aimé lire quand j'ai commencé.

Trois textes qui ne se contredisent pas, mais qui ne se rencontrent jamais

Le débat sur la souveraineté de l'IA est saturé d'acronymes mal employés. Avant tout, remettons les trois textes utiles à plat :

Texte	Origine	Ce qu'il impose	À qui
Cloud Act	États-Unis, 2018	Toute entreprise soumise au droit US doit remettre les données qu'elle traite à l'autorité fédérale, où qu'elles soient hébergées.	OpenAI, Anthropic, Google, Microsoft, AWS, Meta… et leurs filiales européennes.
RGPD	Union européenne, 2018	Tout traitement de données personnelles d'un résident UE doit avoir une base légale, être documenté, sécurisé et limité dans le temps.	Tout responsable de traitement, peu importe la nationalité.
AI Act	Union européenne, 2024	Classement des systèmes IA par niveau de risque, avec obligations spécifiques (transparence, supervision humaine, audit) selon le niveau.	Fournisseurs et déployeurs d'IA en UE, à compter de 2026.

Ces trois textes ne se rencontrent pas dans la même salle. Le Cloud Act ne mentionne pas le RGPD. Le RGPD ne mentionne pas le Cloud Act. L'AI Act les ignore tous les deux. C'est cette absence de dialogue qui crée la zone grise dans laquelle se signent la plupart des contrats IA d'entreprise aujourd'hui.

Le Cloud Act, ce qu'il dit vraiment

Premier malentendu : « Cloud Act » est un acronyme. Le texte s'appelle Clarifying Lawful Overseas Use of Data Act. Il a été signé en mars 2018 sous l'administration Trump, et il dit en substance ceci :

Toute entreprise relevant du droit américain peut être contrainte par mandat fédéral de remettre les données qu'elle stocke ou traite, indépendamment de leur localisation géographique, et indépendamment de la nationalité de la personne concernée.

Section 103, Cloud Act, lecture pratique

« Toute entreprise relevant du droit américain » couvre : les sociétés enregistrées aux États-Unis (OpenAI Inc., Anthropic PBC, Google LLC), leurs filiales mondiales (OpenAI Ireland, Microsoft France), et toute entité dont la maison-mère est américaine. C'est extrêmement large.

« Indépendamment de leur localisation géographique » est le point qui surprend le plus les directions juridiques européennes. Une donnée hébergée à Francfort par Microsoft Azure peut être réclamée par une autorité fédérale américaine, sans passage par une autorité allemande, sans information de la personne concernée, et sans recours possible côté européen.

Le Cloud Act ne vous interdit pas de travailler avec un éditeur américain. Il vous oblige à savoir que la juridiction qui s'applique en dernier ressort sur vos données n'est pas la vôtre. Pour beaucoup de cas d'usage, c'est acceptable. Pour certains, c'est rédhibitoire. Le rôle du DPO et de la direction juridique est de savoir lesquels.

Le RGPD, ce qu'il impose dans un projet IA

Le RGPD ne dit rien de l'IA en tant que telle. Il s'applique au moment où un système IA traite des données personnelles, c'est-à-dire à peu près toujours en entreprise. Quatre obligations à connaître par cœur avant tout projet :

1. Base légale du traitement. Vous ne pouvez pas envoyer un email à OpenAI au motif que « le LLM en a besoin pour répondre ». Il vous faut une base légale documentée. Pour la plupart des cas IA, ce sera l'intérêt légitime ou l'exécution contractuelle. Documentez-la avant de déployer.
2. Information des personnes. Si l'agent IA traite des emails clients, ces clients doivent être informés. Pas dans une CGU de 40 pages. Dans une mention claire et accessible.
3. AIPD (analyse d'impact). Obligatoire dès qu'un traitement IA est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. La CNIL a publié une grille pratique. Pour un workflow agentique non trivial, l'AIPD est presque systématiquement requise.
4. Sous-traitance et transferts hors UE. Si votre fournisseur IA est américain, vous concluez un transfert international. Cela suppose des clauses contractuelles types (CCT) à jour, et une analyse d'impact spécifique sur ce transfert.

Aucune de ces obligations n'est dramatique. Toutes prennent du temps. Le piège classique est de découvrir l'AIPD trois jours avant la mise en production, parce que personne n'avait pensé à l'inscrire au planning du POC. C'est aussi pour ça que nous incluons systématiquement l'AIPD dans le diagnostic Studio, pas dans le déploiement.

L'AI Act, ce qui s'applique vraiment dès 2026

L'AI Act est entré en vigueur en août 2024, mais ses obligations s'appliquent par paliers. Ce qui compte pour vos projets en 2026 :

• Systèmes interdits : déjà applicable depuis février 2025. Notation sociale, manipulation cognitive, certains usages biométriques. Si votre projet ne tombe pas dedans (ce qui est presque toujours le cas en entreprise), passez.
• Modèles à usage général (GPAI) : obligations de transparence sur le modèle (documentation technique, droits d'auteur, énergie consommée). Cela concerne les fournisseurs de LLM, pas vous, sauf si vous fine-tunez votre propre modèle de base.
• Systèmes à haut risque : applicable à compter d'août 2026. Si votre agent prend des décisions impactantes (recrutement, crédit, accès à un service public, sécurité critique), vous tombez ici. Documentation, audit, supervision humaine, registre… obligations significatives.
• Systèmes à risque limité : obligations de transparence légères. Un chatbot doit dire qu'il est un chatbot. Un contenu généré doit être marqué comme tel.

La grande majorité des workflows agentiques que nous déployons relève de la catégorie « risque limité ». La transparence est facile à respecter par construction. Le seul piège réel est de tomber par surprise dans « haut risque » parce que l'agent a pris une décision RH ou financière sans qu'on l'ait anticipé. D'où, encore une fois, l'importance de cartographier les workflows en début de projet.

Les alternatives EU réellement disponibles aujourd'hui

Si vous arrivez à la conclusion qu'un fournisseur soumis au Cloud Act est rédhibitoire pour votre cas, vous avez désormais des alternatives crédibles, et elles ont rattrapé une partie du retard de capacités :

LLM EU à usage général

• Mistral (France) propose Mistral Large, Mistral Small et Codestral, hébergeables en propre via leur plateforme ou disponibles sur Scaleway. Données traitées en UE. Performances sur la plupart des cas business indiscernables de GPT-4o pour des tâches métier, plus faibles sur certains raisonnements complexes ou code de niveau senior.
• Modèles ouverts (Llama 3.x, Mixtral, Qwen) hébergés en propre. Plus exigeant en compétences techniques, mais ouvre la porte à un déploiement entièrement souverain. C'est le choix par défaut quand l'AIPD aboutit à une exigence stricte.

Hébergement souverain

• Scaleway et OVHcloud en France, Hetzner en Allemagne. Aucun lien capitalistique avec un acteur US. Conformes par défaut au critère « hors Cloud Act ».
• Outscale (qualifiée SecNumCloud) pour les cas qui exigent le plus haut niveau de qualification ANSSI.

Le compromis raisonnable

Pour la plupart de nos clients, l'arbitrage tient en trois lignes :

1. Données non sensibles (génération de contenu marketing, brainstorming, première rédaction de documents internes), un fournisseur US peut convenir, sous réserve d'un DPA propre.
2. Données personnelles classiques (emails, fichiers RH, CRM), priorité à un LLM EU avec hébergement EU. Mistral via Scaleway est aujourd'hui notre défaut.
3. Données sensibles ou réglementées (santé, finance critique, secret industriel), self-host obligatoire, modèle ouvert sur cluster client. Pas de discussion.

C'est précisément la matrice que la plateforme OpsClaw permet d'appliquer en pratique, parce qu'elle découple le choix du modèle du choix de l'hébergement. Vous pouvez utiliser Anthropic Claude pour un workflow non sensible, et basculer sur Mistral self-host pour un autre, depuis la même console, sans recoder vos agents.

La checklist pratique avant signature

Si vous êtes sur le point de signer un contrat IA d'entreprise, voici la checklist qu'on remet à nos clients avant que la direction juridique ne valide :

1. Le fournisseur est-il soumis au Cloud Act ? Vérifier la maison-mère, pas la filiale. Réponse écrite dans le contrat.
2. Où sont stockées les données techniques ? Stockage du contenu envoyé, des logs, des éventuelles ré-utilisations pour entraînement.
3. Les données sont-elles utilisées pour ré-entraîner un modèle ? Si oui, dans quelles conditions et avec quelle fenêtre de désengagement.
4. Le DPA est-il signé et conforme aux clauses CCT 2021 ? Cherchez la dernière version, pas une déclinaison de 2018.
5. Existe-t-il une clause de portabilité ? En cas de rupture, vous récupérez vos données dans un format ouvert, sous combien de jours.
6. Le contrat couvre-t-il l'AIPD que vous devez produire ? Le fournisseur doit vous remettre la documentation technique nécessaire.
7. Quelle juridiction et quelle langue en cas de litige ? Si le contrat est en anglais avec juridiction Delaware, vous prenez un risque de défense disproportionné.

Si trois cases sur sept ne sont pas claires, ne signez pas avant d'avoir des réponses écrites. Personne ne perdra du temps à clarifier après signature.

---

Marion Krief pilote la plateforme chez OpsTech. Avant OpsTech, elle a passé sept ans à concevoir des architectures cloud souveraines pour des grands comptes (santé, énergie, banque). Elle écrit ici sur les sujets qui croisent l'IA, la conformité et l'ingénierie.