La réponse honnête est à la fois oui et non. OpenAI peut traiter des données personnelles d'une manière défendable au regard du RGPD — il propose les bases contractuelles et techniques des transferts, et beaucoup d'entreprises européennes l'utilisent légalement. Mais « conforme » n'est pas « à l'abri d'une injonction américaine » : OpenAI est une société américaine, et comme telle, elle peut être contrainte par le CLOUD Act a livrer les données qu'elle contrôle, où qu'elles soient physiquement stockées. Si votre exigence est qu'aucune juridiction non-UE ne puisse atteindre vos prompts, aucune dose de conformité contractuelle de la part d'un fournisseur américain ne comble cet écart. C'est la différence entre « conforme au RGPD » et « souverain UE » — et elle tient à qui contrôle la société, pas à où se trouve le serveur.
« Conforme » veut dire deux choses
Avant de répondre si OpenAI est conforme au RGPD, il faut couper la question en deux, parce que « conforme » fait deux travaux à la fois. L'un est procédural : les contrats, les conditions, l'accord de traitement des données et les garanties techniques sont-ils tels que vous, client, pouvez satisfaire aux exigences de responsabilité du RGPD ? L'autre est juridictionnel : un État non-UE peut-il forcer le fournisseur a fournir les données, quoi que dise le contrat ?
Ce ne sont pas les mêmes axes, et les confondre est la source de l'essentiel de la confusion. Un fournisseur peut être procéduralement irréprochable et juridictionnellement exposé. Inversement, un fournisseur peut être juridictionnellement propre et procéduralement bâclé. Quand une entreprise européenne demande « OpenAI est-il conforme au RGPD ? », elle pose en réalité la deuxième question — la loi américaine peut-elle atteindre mes données ? — même quand elle emploie le mot « conforme ».
Ce que le RGPD exige réellement
Le RGPD encadre le traitement des données personnelles des personnes dans l'UE. Pour un outil comme une API de LLM, les dispositions pertinentes concernent la base légale, la minimisation, la limitation des finalités, la transparence et, de façon cruciale, les transferts internationaux. Si vous envoyez un prompt contenant des données personnelles à une API, vous êtes un responsable de traitement qui transfère des données personnelles, et il vous faut une base légale qui tienne.
Rien de tout cela n'est propre à OpenAI. Tout fournisseur de LLM — américain ou européen — est un sous-traitant de données dans cette image, et les obligations pèsent surtout sur vous, le responsable de traitement. La partie procédurale de « OpenAI est-il conforme au RGPD » est donc largement une question de savoir si le Data Processing Addendum et les conditions d'OpenAI vous donnent ce dont un responsable a besoin. Pour un grand nombre d'entreprises européennes, c'est le cas ; ce n'est pas une affirmation controversée. Mais si vous avez un délégué à la protection des données (DPO) en interne, il vous posera probablement la question suivante : avez-vous réalisé une analyse d'impact relative aux transferts de données pour le traitement de données personnelles que cette API représente, et que se passe-t-il quand une injonction judiciaire américaine atteint le sous-traitant ?
Le problème des transferts : SCC et adéquation
La friction apparaît avec les transferts internationaux. Si vous êtes une entreprise européenne qui envoie des données personnelles à un fournisseur américain, c'est un transfert hors EEE, et il doit satisfaire au chapitre V du RGPD. Sans décision d'adéquation, le mécanisme standard est un ensemble de clauses contractuelles types (SCC) — un contrat signé qui oblige le destinataire a protéger les données aux normes européennes.
Les SCC sont réelles et légales ; ce n'est pas une contournement. Mais depuis Schrems II (CJUE, 2020), s'appuyer sur les SCC vers un pays comme les États-Unis impose d'évaluer si le destinataire peut réellement les honorer — dans le contexte du droit de surveillance américain, CLOUD Act compris. C'est pourquoi la réponse « est-ce conforme » dépend de votre posture de risque : pour beaucoup d'entreprises, la voie SCC est adéquate ; pour d'autres — secteurs régulés, certaines obligations contractuelles, une exigence dure qu'aucun tribunal américain ne puisse atteindre les données — elle ne suffit pas.
Le CLOUD Act est un levier juridictionnel, pas un bug
Le CLOUD Act américain (2018) permet aux autorités américaines de contraindre une entreprise américaine à divulguer les données qu'elle contrôle, où qu'elles soient stockées. Peu importe que les serveurs soient en Virginie ou à Francfort : l'obligation s'attache à l'entreprise, pas à la machine.
C'est la partie qu'aucune clause contractuelle ne peut neutraliser complètement. Un fournisseur américain peut être parfaitement coopératif avec le RGPD, signer tous les SCC, chiffrer tout en transit et au repos — et rester soumis à une injonction légale, adossée à la menace du outrage au tribunal, qu'aucun tribunal de Paris ou de Berlin ne peut opposer. Pour la plupart des entreprises, cela n'arrive jamais. Pour celles dont la raison d'être est « aucune société américaine ne peut être sommée de remettre nos données », c'est décisif.
Fournisseur par fournisseur : OpenAI, Microsoft, Anthropic
Il aide d'être précis, car ces trois-là sont souvent regroupés alors qu'ils ne sont pas identiques.
- OpenAI. Société américaine, soumise au CLOUD Act. Utilisable de façon conforme au RGPD au sens procédural ; juridictionnellement, c'est une société américaine.
- Microsoft (Azure OpenAI). Microsoft est aussi une société américaine. Ses régions UE sont réelles, mais « région UE » n'est pas « hors de portée du droit américain » — une société américaine reste une société américaine où que soit sa région.
- Anthropic. Également une société américaine, soumise au droit américain, même si son API est énormément utilisée par les développeurs européens.
Le schéma est partagé : ce sont des entités sous contrôle américain. Aucune n'est « souveraine UE », et aucun arrangement contractuel ne change qui possède et contrôle l'entreprise.
Vos obligations en tant que responsable
« OpenAI est-il conforme au RGPD » risque de reformuler la question d'une façon qui cache votre propre rôle. Sous le RGPD, quand vous envoyez des données personnelles à une API de LLM, vous êtes le responsable de traitement et le fournisseur est un sous-traitant. Une grande partie de la conformité vit de votre côté de la relation, quel que soit le fournisseur choisi :
- Base légale. Vous avez besoin d'une base valide pour le traitement — consentement, contrat, intérêt légitime, obligation légale — et elle doit être documentée.
- Minimisation. N'envoyez que les données personnelles dont la tâche a réellement besoin. Une part étonnante du « problème RGPD » avec les API de LLM est en réalité « nous avons envoyé beaucoup plus de données personnelles qu'il ne fallait ».
- Limitation des finalités. Les données collectées pour une finalité ne peuvent pas être réutilisées silencieusement pour une autre sans rapport — y compris l'entraînement du modèle, sauf si c'est divulgué et justifié séparément.
- Registre (article 30). Vous devez pouvoir montrer un registre des traitements, ce qui pour une API inclut de savoir ce qui est parti vers quel fournisseur et pourquoi.
- Droits et conservation. Les demandes d'accès et les limites de conservation s'appliquent à ce que vous détenez, ce qui inclut les journaux et transcriptions de vos appels.
La question juridictionnelle (CLOUD Act) se superpose à tout cela et lui est orthogonale. Un fournisseur souverain aide côté transfert ; il ne vous dispense pas de vos obligations de responsable. À l'inverse, être scrupuleux sur la minimisation rend quel que soit le fournisseur plus facile à défendre. Les deux couches comptent, et aucune n'est facultative si la tâche implique réellement des données personnelles.
Quand cela compte pour votre charge de travail
Bien cadrer le risque compte plus qu'un verdict tiède, alors voici la ligne que nous tracerions en pratique.
- Si vous êtes une startup ou une petite entreprise qui construit un produit grand public, et que votre accord de traitement de données plus les SCC satisfont votre conseil, qu'OpenAI soit une société américaine est très souvent un compromis acceptable. C'est un choix légitime.
- Si vous servez un secteur régulé — santé, marchés publics, juridique, certaines activités financières — ou un client dont le contrat dit « aucune donnée traitée sous juridiction non-UE », alors la personnalité américaine du fournisseur est le problème, pas la paperasse. Aucun SCC ne saute par-dessus.
- Si vous construisez pour une administration ou un organisme public avec des exigences explicites de souveraineté, seul un fournisseur réellement hors de contrôle non-UE ferme la boucle.
Rien de tout cela n'est une leçon de morale anti-OpenAI. C'est le même test que nous nous appliquons en miroir : nous étiquetons chaque modèle souverain ou accès rapide selon qui contrôle l'opérateur, pas selon la localisation de la région — et nous ne qualifions jamais un modèle américain de souverain.
L'alternative souveraine UE
L'alternative n'est pas « pas d'IA » — c'est faire tourner des modèles open-source sur une infrastructure exploitée par des sociétés sans contrôle capitalistique ou juridictionnel non-UE. Quand l'opérateur est, par exemple, OVHcloud ou Scaleway, le CLOUD Act n'a pas de prise sur la société elle-même, et la discussion RGPD n'est plus dominée par la question du transfert. C'est toute la position sur laquelle Frontière AI est bâti : les mêmes poids open-source que vous pourriez appeler chez OpenAI, servis via une infrastructure sous contrôle UE, derrière une API compatible OpenAI que vous savez déjà appeler.
Il ne s'agit pas de prétendre qu'OpenAI est mauvais — il s'agit de donner à l'acheteur qui a une exigence juridictionnelle dure l'option qu'une API américaine, si bien gérée soit-elle, ne peut structurellement pas être.
FAQ
OpenAI est-il conforme au RGPD ?
Au sens procédural, largement oui : OpenAI propose des conditions de traitement des données et des clauses contractuelles types qui permettent aux entreprises européennes de satisfaire au RGPD pour beaucoup de charges de travail. Mais OpenAI est une société américaine soumise au CLOUD Act, donc aucun arrangement contractuel n'écarte la possibilité que le droit américain la contraigne a divulguer des données — c'est un fait juridictionnel, pas une lacune de conformité qu'on peut neutraliser par contrat.
Azure OpenAI est-il conforme au RGPD ?
Procéduralement, Azure propose des régions UE et des conditions de protection des données d'entreprise, et Microsoft signe des SCC. Mais Microsoft est une société américaine, donc une région UE n'écarte pas la prise du CLOUD Act sur la société elle-même. Pour beaucoup de clients européens, les conditions sont adéquates ; pour une exigence dure qu'aucun tribunal américain ne puisse atteindre les données, elles ne le sont pas.
Que signifie le CLOUD Act pour les utilisateurs européens d'OpenAI ?
Le CLOUD Act permet aux autorités américaines de contraindre une société américaine a divulguer les données qu'elle contrôle, où qu'elles soient stockées — région UE comprise. L'obligation suit la société, pas la localisation du serveur. C'est pourquoi « exploité dans l'UE » et « hors de portée des États-Unis » sont deux choses différentes.
Les clauses contractuelles types suffisent-elles sous le RGPD ?
Pour beaucoup de transferts, oui — les SCC sont un mécanisme de transfert légal. Mais depuis Schrems II, il faut évaluer si le destinataire peut réellement les honorer, en tenant compte du droit de surveillance américain. Pour des charges de travail régulées ou sensibles à la souveraineté, cette évaluation peut échouer ; dans ce cas, un fournisseur réellement souverain UE est la voie la plus défendable.
Puis-je utiliser OpenAI pour des charges de travail conformes au RGPD en France ?
Vous pouvez, via l'accord de traitement des données et la voie SCC, et beaucoup d'entreprises françaises le font. « Pouvoir » et « devoir pour votre posture de risque spécifique » sont deux questions différentes : si vous avez besoin d'avoir l'assurance qu'aucun tribunal américain ne puisse atteindre vos prompts, un fournisseur américain ne peut pas la donner, quelle que soit la paperasse.
Quelle est l'alternative souveraine UE à OpenAI ?
Faire tourner des modèles open-source sur une infrastructure exploitée par des entreprises UE sans contrôle capitalistique non-UE — OVHcloud, Scaleway, ou serveurs UE dédiés. Cela supprime le problème du transfert et du CLOUD Act. Frontière AI est une API compatible OpenAI sur exactement cette infrastructure, avec chaque modèle étiqueté souverain ou accès rapide avant votre appel.
Quelles sont mes propres obligations RGPD quand j'utilise une API de LLM ?
Vous êtes le responsable de traitement, donc il vous faut une base légale documentée, une minimisation des données (n'envoyer que ce dont la tâche a besoin), une limitation des finalités, un registre des traitements, et le respect des droits des personnes et de la conservation. Un fournisseur souverain aide côté transfert mais ne vous dispense pas de vos obligations de responsable ; les deux couches comptent.
La minimisation des données peut-elle régler le problème RGPD avec OpenAI ?
Elle le réduit beaucoup et c'est une bonne pratique indépendante. Si vous n'envoyez que les données personnelles réellement nécessaires, vous réduisez votre exposition au transfert et votre charge de registre. Mais elle n'écarte pas la question du CLOUD Act pour les données que vous envoyez quand même — c'est un axe séparé qu'un fournisseur souverain adresse.
Prêt à essayer ?
Créez un compte et appelez n'importe quel modèle du catalogue en quelques minutes.