#Sécuriser l'IA générative en entreprise (ChatGPT, Claude, Copilot) : guide RGPD 2026

En dix-huit mois, ChatGPT, Claude, Copilot et Mistral sont devenus des outils de bureau au même titre qu'Excel. Le rythme d'adoption a explosé, mais la maîtrise des flux de données a pris beaucoup de retard. Une collaboratrice colle un contrat dans une fenêtre web, un développeur copie un fragment de code contenant une clé d'API, une direction commerciale soumet une analyse stratégique pour la "résumer" : autant de gestes anodins qui, vus depuis un RSSI ou un DPO, ressemblent à des exfiltrations parfaitement légales en dehors du périmètre maîtrisé.

Les outils DLP classiques n'ont pas été conçus pour cela. Les contrats RGPD ne couvrent que la version professionnelle. Et la jurisprudence européenne autour de l'AI Act, du RGPD et de NIS2 commence à dessiner un cadre où la responsabilité du dirigeant et du DPO ne fait plus débat.

Ce guide rassemble ce que nous appliquons en mission d'audit ISO 27001 chez nos clients : un état des lieux factuel des risques, le cadre réglementaire applicable en 2026, les cinq familles de fuites à anticiper, cinq méthodes techniques d'anonymisation comparées avec leur code, et un plan de mise en oeuvre (charte IA, DLP poste de travail, sensibilisation). Il s'adresse aux DSI, RSSI, DPO et dirigeants qui doivent justifier devant un auditeur que l'usage de l'IA générative dans leur organisation est sous contrôle.

#1. État des lieux : pourquoi les LLM sont une bombe à retardement RGPD

#1.1 Des incidents documentés, pas une hypothèse

Le cas Samsung de 2023 reste l'exemple le plus cité : des ingénieurs ont collé du code source propriétaire et des comptes rendus de réunion internes dans ChatGPT pour gagner du temps. L'entreprise a interdit l'outil quelques semaines plus tard, après avoir constaté que les prompts soumis au modèle public risquaient d'être absorbés dans les jeux d'entraînement. L'épisode a accéléré la prise de conscience au niveau industriel.

Au-delà de ce cas, plusieurs sources convergent. Une étude citée par Varonis montre que les solutions DLP classiques ne couvrent pas les interactions avec les IA génératives, laissant des brèches critiques pour les secrets API, les PII et la propriété intellectuelle. Secuvy.ai relève que les employés collent régulièrement des documents internes, du code source ou des analyses confidentielles dans ChatGPT, transformant l'outil en un extracteur de données ultra-efficace : un seul prompt mal formulé peut exposer un deck stratégique ou des données RH restreintes, sans aucune alerte ni résistance du système.

#1.2 Pourquoi les DLP classiques ne voient rien

Les DLP réseau et endpoint ont été conçus pour détecter des pièces jointes, des copies vers une clé USB, des envois mail vers un domaine externe. Le pattern "coller du texte dans un champ HTML d'un onglet Chrome" leur échappe pour trois raisons :

• Le canal est chiffré de bout en bout en HTTPS, donc le contenu n'est pas inspectable au niveau du proxy sauf à casser la chaîne TLS (ce qui est juridiquement et techniquement coûteux).
• Le format est non structuré : les regex DLP ciblent des patterns comme un IBAN ou un numéro de carte, mais ratent un "notre marge brute Q3 est de 23,4 %" ou un nom de client énoncé en clair dans un paragraphe.
• L'utilisateur agit en bonne foi : il n'exfiltre rien, il "demande de l'aide" à un outil de productivité. Aucune alerte SIEM ne se déclenche.

Résultat : la majorité des organisations qui ont déployé un DLP réseau ou endpoint pensent être protégées et ne le sont pas pour ce nouveau canal.

#1.3 La zone grise des versions Entreprise

Les offres ChatGPT Enterprise, Claude Enterprise, Copilot for Microsoft 365 ou Azure OpenAI proposent un Data Processing Agreement (DPA), un chiffrement au repos et en transit, des contrôles d'accès et parfois la résidence des données en Union européenne. Elles règlent une partie du problème côté éditeur. Elles ne règlent pas trois questions :

• Qui s'assure que le collaborateur utilise bien l'instance Entreprise et pas son compte ChatGPT gratuit ouvert avec son email personnel ?
• Quels jeux de données sont autorisés dans les prompts, même sur l'instance pro ? Un RIB, un dossier médical, un code source sous NDA n'ont rien à y faire, contrat ou pas.
• La trace des prompts est-elle conservée et auditable pour démontrer la conformité a posteriori ? L'auditeur ISO 27001 ou la CNIL n'accepteront pas "on suppose que les équipes respectent la charte".

NOTE : la version gratuite de ChatGPT ne propose pas de DPA conforme à l'article 28 du RGPD. OpenAI se réserve le droit d'utiliser les prompts pour l'entraînement, et conserve les contenus 30 jours par défaut pour la détection d'abus.

#2. Cadre réglementaire 2026

#2.1 RGPD : articles 5, 6, 28, 32, 35

Le RGPD ne mentionne pas l'IA générative, mais ses principes s'appliquent intégralement aux prompts qui contiennent des données à caractère personnel.

• Article 5.1.c (minimisation) : ne transmettre au LLM que les données strictement nécessaires à la tâche. Coller un dossier RH complet pour demander "résume-moi ça" est par construction non conforme.
• Article 5.1.b (finalité) : l'usage doit être limité à un objectif précis et légitime. Soumettre un email client pour "voir ce que l'IA en pense" sans finalité documentée n'a pas de base légale.
• Article 6 : licéité du traitement. Si le LLM est un sous-traitant, il faut une base légale (intérêt légitime documenté, consentement, contrat).
• Article 17 (droit à l'oubli) : l'entreprise doit pouvoir faire supprimer les données envoyées au fournisseur LLM. C'est un point dur quand le prompt a déjà nourri un cycle d'entraînement.
• Article 28 : tout fournisseur LLM est un sous-traitant. Il faut un DPA signé. OpenAI Ireland Limited, filiale européenne d'OpenAI, est soumise à ces obligations même si les calculs sont opérés aux États-Unis.
• Article 32 : sécurité du traitement. Pas de chiffrement au repos, pas de masquage, pas de journalisation = manquement.
• Article 35 : analyse d'impact (AIPD) obligatoire pour les traitements à grande échelle de données sensibles. Soumettre des données RH ou des dossiers patients à un LLM grand public sans AIPD est un défaut documentaire majeur.

Les sanctions peuvent atteindre 4 % du chiffre d'affaires mondial ou 20 millions d'euros (article 83.5).

#2.2 AI Act européen

Le règlement européen sur l'IA, entré en application progressive depuis 2024, classe les systèmes par niveau de risque. Les obligations clefs pour les déploiements LLM en entreprise :

• évaluation des risques pour les systèmes d'IA à haut risque (RH, scoring, biométrie, justice, santé) ;
• mesures techniques pour prévenir les fuites de données et les biais ;
• documentation complète des processus (jeux d'entraînement, finalités, mécanismes de contrôle, journalisation) ;
• transparence vis-à-vis de l'utilisateur final et étiquetage des contenus générés.

Le règlement prévoit des sanctions du même ordre de grandeur que le RGPD.

#2.3 NIS2 et chaîne de fournisseurs IA

La directive NIS2 transposée en droit français renforce les obligations sur la sécurité des systèmes d'information des entités essentielles et importantes. Deux points concernent directement l'usage de LLM :

• la chaîne de fournisseurs : un éditeur de LLM utilisé pour des activités opérationnelles doit être évalué comme tout sous-traitant critique, avec exigences contractuelles, vérification de la posture sécurité, plan de continuité.
• la gestion des incidents : la fuite de données via un prompt entre dans les incidents notifiables, avec les délais associés (24 heures pour la notification initiale, 72 heures pour le rapport intermédiaire).

Nous détaillons ces obligations dans notre accompagnement NIS2 pour les entités concernées.

#2.4 Responsabilité du DPO et du RSSI

Sur le terrain, la combinaison RGPD + AI Act + NIS2 fait converger les responsabilités du DPO et du RSSI sur trois exigences minimales :

• une politique IA opposable, signée par les utilisateurs, intégrée au règlement intérieur ;
• des contrôles techniques effectifs au poste de travail (DLP navigateur, journalisation) ;
• une boucle d'audit : revue des incidents, mise à jour de la cartographie, formation continue.

Sans ces trois éléments, la défense devant un auditeur ISO 27001 ou la CNIL se résume à "on pensait que les équipes feraient attention" et ne tient pas.

#3. Les cinq catégories de fuites à anticiper

Toutes les fuites n'ont pas la même criticité ni le même mode de détection. La grille suivante structure ce que nous voyons en audit.

#3.1 Secrets techniques (API keys, tokens, mots de passe)

Le cas le plus fréquent et le plus mécanique. Un développeur colle un extrait de code contenant AKIA..., un token GitHub, un mot de passe BDD ou une clé Stripe. La donnée est cuite dès l'envoi : la clé peut être révoquée mais elle est sortie du périmètre.

Les patterns sont détectables par regex (voir section 4). C'est la catégorie la plus facile à couvrir techniquement et celle qui doit être traitée en priorité.

#3.2 Données personnelles (PII)

Nom, prénom, email, adresse, téléphone, numéro de sécurité sociale, RIB, IBAN, numéro de carte bancaire. Tout ce qui est défini comme donnée à caractère personnel au sens du RGPD.

Risque immédiat : violation de l'article 5 (minimisation) et de l'article 32 (sécurité). Risque secondaire : impossibilité d'exercer le droit à l'oubli si la donnée a nourri un modèle.

#3.3 Code source et propriété intellectuelle

Au-delà des secrets embarqués, le code lui-même peut être stratégique : algorithme propriétaire, schéma de base de données, configuration d'infrastructure. L'OWASP, dans sa checklist de gouvernance LLM, souligne aussi la question juridique : qui détient les droits sur le code produit par un LLM, et que devient la propriété intellectuelle des fragments soumis comme contexte ? Cette ambiguïté est mal traitée par la majorité des contrats actuels.

#3.4 Contrats, données commerciales et juridiques

Conditions tarifaires, clauses négociées, échéanciers, courriers d'avocat, conclusions judiciaires. Le risque ici n'est pas seulement réglementaire : c'est un avantage concurrentiel qui sort sans retour. Pour les officiers ministériels (avocats, notaires, huissiers) et les professions du chiffre, le secret professionnel ajoute une couche de responsabilité personnelle.

#3.5 Données métier sensibles non structurées

C'est la catégorie la plus difficile à détecter. "Notre marge brute Q3 est de 23,4 %", "le client X envisage de partir chez Y", "nous lançons le produit Z en septembre" : aucune regex ne déclenche, aucun pattern PII, et pourtant la valeur stratégique est énorme. Cette catégorie requiert une approche de classification (étiquetage des documents) plutôt qu'une détection purement syntaxique.

#4. Cinq méthodes techniques d'anonymisation comparées

#4.1 Regex maison (détection de motifs)

C'est la première brique technique. Pour les secrets et certaines PII structurées, des expressions régulières détectent le motif et permettent de bloquer ou masquer avant envoi.

# Détection de clés API AWS
\b(AKIA[0-9A-Z]{16})\b

# Numéros de carte bancaire (Luhn check optionnel)
\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9]{2})[0-9]{12})\b

Avantages : coût quasi nul, transparence, déterminisme.

Limites : faux positifs et faux négatifs, maintenance permanente des patterns (chaque éditeur change ses formats de clés tous les ans), aucune capacité sur les données contextuelles non structurées.

#4.2 Presidio (Microsoft) et anonymisation par substitution

Presidio est une bibliothèque open source de Microsoft pour la détection et l'anonymisation de PII. Elle combine regex, NER et logique personnalisable. L'objectif est de remplacer les données sensibles par des valeurs fictives mais réalistes, en préservant la structure du texte. La k-anonymity garantit qu'un enregistrement ne peut pas être distingué d'au moins k-1 autres dans la base.

Trois techniques s'imbriquent :

• tokenisation : remplacement par jetons ([NAME_1], [EMAIL_2]) ;
• généralisation : "35 ans" devient "30-40 ans" ;
• bruitage : ajout d'une perturbation aléatoire de plus ou moins 5 % sur un montant.

Exemple minimal en Python avec la librairie faker :

from faker import Faker

fake = Faker()
text = "Le client John Doe ([email protected]) a commandé pour 1250€."
anonymized = text.replace("John Doe", fake.name()) \
                 .replace("[email protected]", fake.email()) \
                 .replace("1250€", f"{fake.random_int(min=1000, max=1500)}€")

Cas d'usage typiques : préparation de datasets pour fine-tuning d'un LLM interne, soumission de logs ou de code à analyser ("pourquoi ce script PostgreSQL échoue ?"). Outils complémentaires : PyDP pour la differential privacy sur données tabulaires.

WARN : l'anonymisation par substitution ne suffit pas pour les données hautement sensibles (santé, défense). Privilégier alors le chiffrement homomorphe (section 4.4).

#4.3 Données synthétiques

Quand la volumétrie ou la criticité justifient l'effort, on génère des données artificielles qui reproduisent les propriétés statistiques des données réelles sans exposer d'informations identifiantes. Cas d'usage : entraînement de modèles RAG internes, tests de prompts, partage d'exemples avec des tiers (auditeurs, partenaires).

Outils :

• Synthea pour les données médicales synthétiques ;
• Gretel.ai pour des datasets synthétiques conformes RGPD ;
• CTGAN, modèle GAN spécialisé sur les données tabulaires.

Exemple avec Gretel CLI :

# Installer Gretel CLI
pip install gretel-client

# Générer un dataset synthétique à partir d'un schéma
gretel models create --config gretel-synthetics-default

Avantages : élimine le risque d'extraction de données réelles, permet de partager des exemples sans contrainte. Limites : coût computationnel sur les grands volumes, qualité dépendante de la modélisation source.

#4.4 Chiffrement homomorphe (workflows critiques)

Le chiffrement homomorphe permet d'effectuer des calculs sur des données chiffrées sans les déchiffrer. Réservé aux cas où la donnée ne doit jamais apparaître en clair : santé, défense, infrastructures critiques.

Implémentations :

• Microsoft SEAL (bibliothèque C++) ;
• TF Encrypted pour des workflows ML sur données chiffrées.

import seal

# Configuration du contexte de chiffrement
parms = seal.EncryptionParameters(seal.scheme_type.bfv)
parms.set_poly_modulus_degree(4096)
parms.set_coeff_modulus(seal.CoeffModulus.BFVDefault(4096))
context = seal.SEALContext(parms)

# Chiffrement des données avant soumission au LLM
encryptor = seal.Encryptor(context, public_key)
encrypted_data = seal.Plaintext("data_sensible")
encryptor.encrypt(encrypted_data, ciphertext)

Contraintes : overhead de 10 à 100 fois selon la complexité, et très peu de LLM grand public supportent nativement le chiffrement homomorphe. Cette méthode reste cantonnée aux déploiements on-premise avec des modèles open source (type Llama).

#4.5 SafePrompt et le DLP navigateur

Les quatre méthodes précédentes supposent une transformation des données en amont, par un outil ou un script. Sur le terrain, les fuites se produisent dans le geste quotidien : un onglet Chrome, un copier-coller, "envoyer". L'approche DLP navigateur déplace le point de contrôle au plus près du geste : une extension installée sur le poste analyse le contenu collé ou saisi avant qu'il ne quitte le navigateur.

Le fonctionnement de SafePrompt repose sur trois mécanismes :

• détection en temps réel des motifs sensibles (clés API, tokens, IBAN, PII) ;
• masquage automatique avant envoi (une clé AKIA... devient [AWS_KEY_REDACTED]) ou blocage du prompt selon la politique configurée ;
• alerte centralisée pour le RSSI avec contexte du prompt et journalisation horodatée auditable.

Outils complémentaires côté souveraineté : un LLM local via Ollama (Mistral 7B, Llama 3) pour les usages les plus sensibles, indexation via OpenSearch pour un RAG interne en alternative à Pinecone, intégration via Wazuh module gdpr pour les règles de détection d'exfiltration côté SIEM. Pour l'enclenchement quotidien sur le poste, l'extension navigateur reste la couche la plus efficace en rapport coût / risque évité.

# Lancer un modèle Mistral en local (pas de fuite vers le cloud)
ollama run mistral:7b-instruct

# Reverse proxy avec authentification devant le LLM local
nginx -g "daemon off;" -c /etc/nginx/nginx.conf

#Tableau comparatif

#5. Mise en oeuvre : politique IA, outils, sensibilisation

#5.1 Rédiger sa charte IA

La charte IA est le document opposable qui définit ce que les collaborateurs peuvent faire ou non avec un LLM. Elle doit couvrir au minimum :

• types de données autorisées dans les prompts (et surtout : interdites) ;
• cas d'usage acceptables (résumé de document public, aide à la rédaction, génération de code non sensible) ;
• outils approuvés (liste blanche : par exemple ChatGPT Entreprise oui, ChatGPT compte personnel non) ;
• procédure de signalement d'incident (qui prévenir, sous quel délai, avec quel niveau de détail) ;
• règles de propriété intellectuelle sur les contenus produits par l'IA.

Côté gouvernance, mettre en place un comité IA avec représentants IT, juridique, conformité et au moins un métier opérationnel. Ce comité valide la charte, instruit les demandes d'usages nouveaux, et reçoit les rapports d'incidents trimestriels.

#5.2 Outiller le poste de travail (DLP navigateur)

La charte ne suffit pas : il faut un contrôle technique au plus près du geste. Trois briques se complètent :

• DLP navigateur au poste de travail (SafePrompt ou équivalent) pour la détection et le masquage en temps réel ;
• proxy d'entreprise pour les flux LLM côté API (Forcepoint, ZScaler, Netskope) avec inspection contextuelle et journalisation centralisée ;
• IAM strict : accès aux API LLM réservé aux rôles autorisés, gestion des clés via coffre-fort (HashiCorp Vault, AWS Secrets Manager).

Pour les développeurs, ajouter une couche en amont du push :

• pre-commit hooks (git-secrets, talisman) pour bloquer les commits contenant des clés ;
• environnements isolés pour le code sensible : LLM on-premise via Ollama avec Llama 3 ;
• revue automatisée des prompts dans les pipelines CI/CD quand l'usage est industrialisé.

#5.3 Sensibiliser les équipes et mesurer

La sensibilisation ne se traite pas en une session générique annuelle. Notre approche d'audit identifie systématiquement trois publics distincts avec des risques différents :

• développeurs : risques liés au partage de code, aux secrets embarqués, à la propriété intellectuelle ;
• RH et juridique : protection des données employés, dossiers contentieux, données médicales d'arrêt maladie ;
• direction et commerce : enjeux stratégiques, données concurrentielles, contrats en cours de négociation.

Côté mesure, suivre quatre indicateurs trimestriels :

• nombre de prompts bloqués ou masqués par la solution DLP ;
• nombre d'incidents signalés par les utilisateurs (la baisse à zéro est suspecte, pas rassurante) ;
• taux de couverture de la formation par service ;
• temps de remédiation moyen d'un incident identifié.

#5.4 Étude de cas

Une entreprise de 200 collaborateurs dans le secteur financier a implémenté un DLP navigateur (SafePrompt) pour sécuriser son usage de ChatGPT. Résultats observés sur trois mois :

• 42 % de réduction des incidents de fuite de données identifiés ;
• 78 % des secrets API détectés et masqués avant envoi ;
• conformité RGPD validée par audit externe sur le périmètre IA.

#5.5 Checklist conformité RGPD pour les LLM

Cette checklist est la base de l'instruction d'audit que nous documentons dans nos missions ISO 27001.

#5.6 Choix de l'API et configuration RGPD

Actions à mener côté éditeur :

• désactiver l'entraînement via le tableau de bord OpenAI API (opt-out explicite) ;
• exiger un DPA conforme à l'article 28 RGPD ;
• vérifier la conservation des prompts (OpenAI conserve 30 jours par défaut pour la détection d'abus).

#6. FAQ

#Le compte ChatGPT gratuit d'un collaborateur engage-t-il l'entreprise ?

Oui, dès lors que la donnée traitée appartient à l'entreprise. L'employeur reste responsable du traitement même si l'outil utilisé est un compte personnel ouvert en dehors du périmètre IT. La parade est double : interdire l'usage non approuvé dans la charte, et déployer un contrôle technique (DLP navigateur, blocage proxy) pour rendre l'interdiction effective.

#ChatGPT Enterprise suffit-il à se conformer au RGPD ?

Non. ChatGPT Enterprise propose un DPA, l'opt-out d'entraînement et le chiffrement, ce qui couvre une partie des exigences de l'article 32. Mais l'entreprise reste responsable de la nature des données envoyées (article 5 : minimisation), de la finalité (article 6), de l'AIPD si applicable (article 35) et de la capacité à exercer le droit à l'oubli. La conformité ne se résout pas en cochant une case côté éditeur.

#Une fuite via ChatGPT est-elle un incident notifiable à la CNIL ?

Oui, dès lors qu'elle implique des données personnelles. Le délai de notification est de 72 heures après prise de connaissance. La directive NIS2 ajoute un délai de notification initiale de 24 heures pour les entités essentielles et importantes. La traçabilité des prompts (journalisation horodatée) est ce qui permet de répondre dans ces délais sans improviser.

#Faut-il interdire les LLM ou les encadrer ?

Sauf cas particulier (secteur très réglementé sans API conforme disponible), l'interdiction pure est inefficace : les collaborateurs trouveront un contournement (smartphone personnel, compte perso, copier-coller). L'encadrement par charte + DLP + sensibilisation donne un résultat mesurable. C'est aussi la posture attendue par les auditeurs ISO 27001 et la CNIL.

#Que faire pour les professions soumises au secret professionnel ?

Les avocats, notaires, huissiers, médecins, experts-comptables ont une responsabilité personnelle au-delà du RGPD. La règle pratique : aucune donnée client en clair dans un prompt, même sur une instance Entreprise. Soit recours à une anonymisation systématique en amont (Presidio, SafePrompt), soit déploiement d'un LLM local on-premise sur lequel l'éditeur n'a aucun accès.

#Comment justifier le budget d'un DLP navigateur dédié IA auprès de la direction ?

Trois éléments concrets : le coût d'une amende RGPD (jusqu'à 4 % du CA mondial), le coût d'un incident de fuite de propriété intellectuelle (souvent non chiffrable mais documenté dans des cas comme Samsung), et le coût opérationnel d'une non-conformité ISO 27001 ou NIS2 si l'organisation est concernée. Le ROI d'un outil DLP IA se mesure à l'incident évité, pas à l'efficacité brute.

#7. Comment M-KIS et SafePrompt peuvent vous aider

M-KIS est un cabinet de conseil Lead Auditor ISO 27001 basé en Grand Est, spécialisé en conformité ISO 27001, NIS2 et SOC open source souverain. Nous accompagnons les organisations sur trois plans complémentaires :

• diagnostic et cartographie : revue des usages IA, identification des flux à risque, construction du registre RGPD spécifique aux LLM, AIPD si nécessaire ;
• mise en oeuvre technique : déploiement DLP navigateur, configuration SIEM Wazuh pour la détection d'exfiltration, intégration avec votre IAM existant ;
• gouvernance et conformité : rédaction de la charte IA, formation des équipes par public, préparation aux audits ISO 27001 et NIS2.

Côté outil, SafePrompt est notre solution de DLP IA navigateur : extension Chrome ou Firefox installable en 30 secondes, détection et masquage automatiques des secrets API et PII avant envoi à ChatGPT, Claude, Mistral ou Copilot, dashboard centralisé pour le RSSI, hébergement France 100 % souverain.

Pour les organisations qui pilotent leurs équipes terrain depuis WhatsApp et veulent garder leur infrastructure 100 % souveraine sur le sol français, notre offre Merlya propose une couche conversationnelle IA pensée pour le contexte artisan et PME française.

Pour les RSSI qui souhaitent évaluer SafePrompt en conditions réelles avant déploiement, un programme gratuit de 3 mois est ouvert aux 100 premiers ambassadeurs.

Pour les acheteurs publics, SafePrompt entre dans le cadre de l'article R2122-9-1 du Code de la commande publique (achat innovant) : pas de marché ni de mise en concurrence préalable pour un déploiement à moins de 100 000 euros HT.

Pour les professions soumises au secret professionnel (avocats, notaires, huissiers), notre note dédiée aux officiers ministériels détaille les contraintes spécifiques et la configuration recommandée.

Installer SafePrompt en 30 secondes : Chrome / Firefox