Intégrer un LLM sans violer le RGPD : guide

L'essor des LLM soulève une question concrète pour les entreprises françaises et européennes : peut-on utiliser un LLM en restant conforme au RGPD ?

La réponse courte : oui, mais pas avec n'importe quelle architecture. La majorité des intégrations "plug and play" (envoyer des prompts directement à l'API OpenAI) exposent l'entreprise à des violations réglementaires sérieuses, y compris quand les données semblent anodines. Ce guide explique pourquoi, et quelles alternatives permettent de déployer l'IA générative en toute légalité.

Pourquoi envoyer des données à OpenAI pose un problème RGPD

Envoyer des données à une API américaine crée trois risques RGPD simultanés : transfert hors UE sans garantie adéquate (Article 44), absence de contrat de sous-traitance conforme (Article 28), et exposition au Cloud Act américain de 2018 qui autorise les autorités US à accéder aux données d'entreprises américaines, même hébergées en Europe. La CJUE a confirmé ce conflit dans l'arrêt Schrems II.

Qu'est-ce qu'une donnée personnelle au sens de l'Article 4 RGPD ?

L'Article 4(1) du RGPD définit la donnée personnelle comme "toute information se rapportant à une personne physique identifiée ou identifiable." Cette définition est volontairement large. Un nom, une adresse e-mail, un numéro de ticket client, un extrait de conversation, une référence à un salarié dans un document interne : toutes ces informations sont des données personnelles.

Conséquence directe : si vos prompts contiennent des informations sur des clients, employés, ou prospects, vous traitez des données personnelles au sens du RGPD, et toutes les obligations afférentes s'appliquent.

Le Cloud Act 2018 : le risque qui vient des États-Unis

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, loi américaine de 2018) autorise les autorités américaines (FBI, DOJ) à contraindre toute entreprise américaine à leur communiquer des données stockées sur ses serveurs, y compris des serveurs situés en Europe. OpenAI, Microsoft, Google, Amazon Web Services sont toutes des entreprises américaines soumises à cette loi.

En pratique : si vous envoyez des données clients à l'API d'OpenAI, ces données peuvent légalement être consultées par des autorités américaines, sans que vous en soyez informé. Le RGPD et le Cloud Act sont structurellement incompatibles sur ce point.

La CJUE a d'ailleurs rappelé ce conflit dans l'arrêt Schrems II (16 juillet 2020), qui a invalidé le Privacy Shield précisément parce que les entreprises américaines ne peuvent pas garantir une protection équivalente au RGPD face à la surveillance étatique américaine.

L'Article 44 RGPD : les transferts hors UE sont encadrés

L'Article 44 du RGPD pose le principe fondamental : tout transfert de données personnelles vers un pays tiers (hors UE/EEE) est interdit sauf s'il respecte les conditions des Articles 45 à 49. En clair, envoyer des données à un serveur américain n'est pas automatiquement illégal, mais cela requiert une base juridique spécifique.

L'Article 46 liste les garanties acceptables : décision d'adéquation de la Commission européenne, clauses contractuelles types (CCT), règles d'entreprise contraignantes (BCR). OpenAI propose des CCT dans son DPA, mais plusieurs autorités de protection des données européennes ont émis des réserves sur leur effectivité face au Cloud Act.

Le risque réel pour une PME : en cas de contrôle CNIL, vous devrez démontrer que votre transfert est couvert par une garantie adéquate ET que cette garantie est effective en pratique. "OpenAI nous a fait signer un DPA" ne suffit pas si les données restent exposées au Cloud Act.

L'Article 28 RGPD : le contrat avec votre sous-traitant

Dès que vous utilisez un tiers pour traiter des données personnelles pour votre compte (y compris un fournisseur d'API IA), cet Article oblige à signer un Data Processing Agreement (DPA). Ce contrat doit préciser les finalités du traitement, les mesures de sécurité, les sous-traitants ultérieurs, les modalités d'exercice des droits des personnes.

OpenAI et les grands fournisseurs proposent des DPA, mais leur portée réelle varie. Vérifier que le DPA couvre explicitement le fait que les données ne servent pas à réentraîner les modèles est indispensable.

Les sanctions : Article 83 RGPD

L'Article 83 prévoit des amendes pouvant atteindre 4% du chiffre d'affaires mondial annuel ou 20 millions d'euros (le montant le plus élevé s'applique). La CNIL a déjà sanctionné des entreprises françaises pour des transferts illicites vers des outils américains : Clearview AI, Google Analytics, et plusieurs sites utilisant des CDN américains.

Quelles architectures permettent de rester conforme ?

Trois architectures permettent une intégration LLM conforme RGPD : utiliser un fournisseur avec hébergement européen (Mistral AI, OVHcloud), déployer un modèle open source en auto-hébergement sur vos propres serveurs, ou anonymiser les données personnelles avant envoi à un fournisseur externe. Le choix dépend de la sensibilité des données et du budget disponible.

Option 1 : Fournisseurs IA avec hébergement européen

La solution la plus simple pour les entreprises qui veulent utiliser une API externe. Plusieurs acteurs proposent des modèles de qualité frontier avec données hébergées en Europe :

• Mistral AI (Paris) : modèles Mistral Small, Medium, Large, hébergés en France, API avec DPA conforme RGPD. Priorité à recommander pour les cas d'usage cloud.
• OVHcloud AI Deploy : déploiement de modèles open source (Llama, Mistral) sur infrastructure française, aucun transfert hors EU.
• Microsoft Azure West Europe + DPA enterprise : acceptable si le DPA est bien configuré et que les données ne quittent pas la région EU. Moins recommandé en raison du Cloud Act résiduel.

Le guide de la CNIL sur l'intelligence artificielle recommande de vérifier systématiquement la localisation effective des données, pas seulement la localisation contractuelle.

Option 2 : Modèles open source en auto-hébergement

C'est l'architecture la plus robuste sur le plan RGPD : aucune donnée ne quitte votre infrastructure. Des modèles comme Mistral 7B, Llama 3 8B/70B, Qwen 2.5 ou Phi-3 peuvent être déployés sur vos propres serveurs (on-premise ou VPS européen).

La stack typique :

# Inférence CPU/GPU avec vLLM
pip install vllm
vllm serve mistralai/Mistral-7B-Instruct-v0.3 --port 8000

Ou via Ollama pour un déploiement simplifié en local :

ollama run mistral:7b

Les performances sur GPU récente (RTX 4090, A100) sont tout à fait acceptables pour des usages internes : chatbots documentaires, extraction d'information, classification, synthèse.

Option 3 : Anonymisation des inputs avant envoi

Si votre cas d'usage impose un LLM externe (performances, coût, raison contractuelle), une pipeline d'anonymisation peut réduire significativement le risque :

1. Détection des PII dans le prompt (noms, e-mails, numéros, adresses, SIRET) avec un modèle de NER (spaCy fr, GLiNER, Presidio)
2. Remplacement par des tokens réversibles : Jean Dupont → PERSONNE_001
3. Envoi du prompt anonymisé au LLM externe
4. Désanonymisation de la réponse côté serveur

Limites : cette approche ne couvre pas tous les cas (contextes implicites, inférences sur l'identité) et ne supprime pas les obligations de l'Article 44. Elle réduit l'exposition mais ne remplace pas une analyse juridique.

Option 4 : Architecture privacy by design (Article 25 RGPD)

L'Article 25 du RGPD impose le principe de "protection des données dès la conception" (privacy by design). Pour une intégration LLM, cela signifie concevoir l'architecture avec les questions suivantes répondues avant le premier déploiement :

• Quelles catégories de données transitent dans les prompts ? (Article 9 pour les données sensibles : santé, convictions religieuses, etc.)
• Quel est le registre de traitements mis à jour ? (Article 30)
• Comment les droits des personnes sont-ils exercés : accès, rectification, effacement ? (Articles 15-17)
• Les logs des échanges avec le LLM sont-ils conservés, et pour quelle durée ?
• Un DPO (délégué à la protection des données) doit-il être consulté ? (Article 37)

Tableau récapitulatif : quel fournisseur pour quel niveau de conformité ?

Arbre de décision : quelle solution pour votre cas ?

Avant de choisir une architecture, répondez à ces quatre questions :

1. Vos prompts contiennent-ils des données personnelles ?

• Non : vous pouvez utiliser n'importe quel fournisseur IA, mais préférez quand même un DPA signé.
• Oui : passez à la question suivante.

2. Ces données sont-elles des données sensibles au sens de l'Article 9 (santé, convictions, données biométriques) ?

• Oui : déploiement on-premise ou cloud EU strict (Mistral AI, OVHcloud) obligatoire + AIPD préalable (Article 35).
• Non : passez à la question suivante.

3. Votre secteur est-il régulé (santé, finance, droit, RH) ?

• Oui : on-premise ou cloud EU + vérification de la conformité sectorielle spécifique.
• Non : passez à la question suivante.

4. Quel est votre budget et votre tolérance à la complexité opérationnelle ?

• Budget limité, équipe technique réduite : Mistral AI API (hébergement EU) — conformité RGPD, coût faible, intégration simple.
• Budget moyen, exigences RGPD fortes : OVHcloud + modèle open source — bon équilibre coût/conformité.
• Budget élevé, données très sensibles : On-premise (Llama/Mistral) — conformité maximale, coût infra élevé.
• Fournisseur externe imposé par contrat : Pipeline d'anonymisation — réduction du risque sans changer de fournisseur.

Que recommande la CNIL sur l'utilisation des LLM ?

La CNIL recommande trois points essentiels : documenter la base légale du traitement (Article 6), signer un DPA conforme avec chaque prestataire IA (Article 28), et réaliser une analyse d'impact préalable pour tout traitement de données sensibles (Article 35). L'hébergement européen est fortement conseillé pour éviter le conflit structurel avec le Cloud Act américain.

La CNIL a publié plusieurs prises de position sur l'IA générative. Les points clés :

• Un LLM peut être un sous-traitant (Article 28) ou un responsable de traitement conjoint selon la configuration. Cette distinction a des implications importantes sur les responsabilités.
• L'utilisation d'un LLM pour traiter des données de santé ou des données sensibles (Article 9) requiert une Analyse d'Impact sur la Protection des Données (AIPD, Article 35) préalable.
• Les entreprises doivent documenter leur base légale pour chaque traitement impliquant un LLM (Article 6 : intérêt légitime, consentement, exécution d'un contrat...).

La CNIL maintient une page dédiée à l'IA mise à jour régulièrement, avec des recommandations sectorielles (RH, santé, marketing).

Conclusion

La conformité RGPD n'est pas incompatible avec l'IA générative. Elle demande une architecture réfléchie et une connaissance minimale des articles clés : Article 4 (définitions), Article 6 (base légale), Article 25 (privacy by design), Article 28 (DPA sous-traitant), Article 44 (transferts hors UE), Article 83 (sanctions).

Les PME qui traitent des données clients ou RH ont tout intérêt à privilégier des fournisseurs européens (Mistral AI, OVHcloud) ou des déploiements on-premise dès le départ. Corriger l'architecture après coup coûte significativement plus cher que de bien la concevoir.

Si votre cas d'usage traite des données sensibles ou que vous opérez dans un secteur régulé (santé, finance, droit), un audit préalable de l'architecture IA peut vous éviter des sanctions qui atteignent jusqu'à 4% de votre chiffre d'affaires mondial.

Contactez-moi pour discuter de votre situation et évaluer l'architecture adaptée à vos contraintes.