05 - Donnees sensibles et RGPD#

Ce que tu colles dans un prompt sort de ton systeme d'information. Voici comment decider ce qui a le droit de sortir.

Temps de lecture : 14 min | Niveau : Intermediaire

Ceci n'est pas un avis juridique. C'est un guide d'ingenieur. Pour toute decision engageante, passe par ton DPO (delegue a la protection des donnees) ou ton service juridique.

Ce que tu sauras faire apres#

• Lister ce qui ne doit jamais partir dans un prompt.
• Faire la difference entre anonymisation et pseudonymisation, et appliquer la bonne.
• Expliquer la difference entre un compte grand public et un acces API entreprise sur la question de l'entrainement.
• Savoir ou regarder pour la retention et le choix de la region.
• Derouler une checklist avant d'envoyer des donnees clients.
• Remplir une fiche de decision qui garde la trace de ton choix, flux par flux.

🎯 Le reflexe de depart#

Quand tu colles quelque chose dans un prompt, tu fais un transfert de donnees vers un sous-traitant externe. Pas un calcul local.

Trois questions, dans cet ordre :

1. Est-ce que ces donnees contiennent des informations sur des personnes identifiables ?
2. Si oui, ai-je besoin de ces informations pour obtenir ma reponse ?
3. Si non, pourquoi est-ce que je les envoie ?

Dans 90 % des cas en data engineering, la reponse a la question 2 est non. Tu veux tester une regle de transformation, debugger une requete, categoriser des libelles. Tu n'as pas besoin des vrais noms.

🚫 Ce qu'on ne colle pas dans un prompt#

Liste de depart, a adapter a ton contexte.

Ajoute-y les categories particulieres du RGPD : origine, opinions politiques, convictions religieuses, appartenance syndicale, donnees genetiques, biometriques, sante, vie sexuelle.

Le piege le plus frequent en data engineering : le secret dans une chaine de connexion. Tu colles une stack trace pour comprendre une erreur, et la chaine postgresql://user:MotDePasse@prod-db:5432/... part avec. Prends l'habitude de relire les 5 premieres lignes de ce que tu colles.

🎭 Anonymisation ou pseudonymisation ?#

Les deux mots ne veulent pas dire la meme chose, et la difference est juridique, pas cosmetique.

• Pseudonymisation : tu remplaces l'identifiant par un autre, mais une table de correspondance permet de revenir en arriere. Les donnees restent des donnees personnelles, le RGPD s'applique toujours.
• Anonymisation : il n'est plus possible de reidentifier la personne, par aucun moyen raisonnable. Les donnees sortent du champ du RGPD.

L'anonymisation reelle est difficile. Un jeu de donnees "anonymise" reste souvent reidentifiable par croisement (date de naissance + code postal + sexe est un exemple classique). Ne dis jamais "anonymise" quand tu veux dire "pseudonymise".

La CNIL, dans sa fiche sur la securite du developpement d'un systeme d'IA, recommande trois choses qui te concernent directement :

• Reduire l'identifiabilite des donnees selon le contexte : suppression de certaines donnees (caviardage), ajout de perturbations aleatoires (confidentialite differentielle), generalisation.
• Utiliser des protocoles de cryptographie a l'etat de l'art, en particulier des qu'un systeme est expose sur le web.
• Journaliser et gerer les versions des jeux de donnees, pour tracer les modifications, detecter une intrusion ou un empoisonnement, et savoir quelle version a servi a quoi.

Le troisieme point est du pur data engineering. Tu sais deja le faire.

Pseudonymiser avant d'envoyer : exemple#

Tu veux que le modele t'aide a detecter des anomalies dans des commandes. Il n'a besoin ni des noms, ni des emails.

import hashlib
import re
import pandas as pd

SEL = "remplace_par_un_secret_stocke_hors_du_code"

def pseudo(valeur: str) -> str:
    """Pseudonyme stable : la meme entree donne toujours la meme sortie."""
    return "ID_" + hashlib.sha256((SEL + str(valeur)).encode()).hexdigest()[:10]

df = pd.read_sql("SELECT * FROM commandes LIMIT 200", engine)

for col in ["nom_client", "email", "telephone"]:
    df[col] = df[col].map(pseudo)

df = df.drop(columns=["adresse_ligne1", "adresse_ligne2"])

Trois points importants :

• Le sel (SEL) empeche de retrouver la valeur d'origine par force brute sur un email. Sans sel, hacher un email n'anonymise rien du tout.
• Le hash stable preserve les jointures et les doublons, donc le modele peut encore raisonner sur la structure.
• Le sel et la table de correspondance restent chez toi. C'est ce qui fait que c'est de la pseudonymisation, et donc que le RGPD continue de s'appliquer.

Filet de securite : detecter avant d'envoyer#

Ajoute une garde automatique dans ton code d'appel. Ca t'evitera une betise un vendredi soir.

MOTIFS_INTERDITS = {
    "email": r"[\w.+-]+@[\w-]+\.[\w.]+",
    "iban": r"\b[A-Z]{2}\d{2}[A-Z0-9]{10,30}\b",
    "cle_api": r"(sk-|api[_-]?key|secret)[\w-]{12,}",
    "conn_string": r"\w+://[^\s:]+:[^\s@]+@",
    "nir_fr": r"\b[12]\d{2}(0[1-9]|1[0-2])\d{2}\d{3}\d{3}\d{2}\b",
}

def bloquer_si_sensible(texte: str) -> None:
    trouves = [nom for nom, motif in MOTIFS_INTERDITS.items()
               if re.search(motif, texte, flags=re.IGNORECASE)]
    if trouves:
        raise ValueError(f"Envoi bloque : motifs sensibles detectes -> {trouves}")

Une regex ne remplace pas une revue. Mais elle attrape les cas evidents, et les cas evidents sont la majorite des incidents.

🏢 Grand public vs API / entreprise : la vraie difference#

C'est le point ou les gens se trompent le plus. Le meme modele n'a pas le meme regime selon la porte par laquelle tu entres.

Ce que disent les documentations officielles#

Anthropic. La page officielle sur la retention des donnees API distingue clairement l'usage API / commercial du grand public. Elle enonce un engagement explicite : les donnees conservees ne sont jamais utilisees pour entrainer des modeles sans ton autorisation expresse. Le contenu des conversations (tes prompts et les reponses) n'est pas conserve par defaut. L'exception porte sur une categorie appelee Covered Models, qui imposent une retention de 30 jours. Pour la politique de retention commerciale standard, la page du centre de confidentialite indique une suppression automatique des entrees et sorties sous 30 jours apres reception ou generation.

Un arrangement Zero Data Retention (ZDR) existe, sur demande et par organisation : Anthropic ne stocke alors pas les prompts ni les reponses apres la reponse de l'API. Points a connaitre :

• Le ZDR s'active par organisation, via l'equipe commerciale. Il ne s'etend pas automatiquement aux autres organisations d'un meme compte.
• Il couvre l'API Messages et l'endpoint de comptage de tokens, pour les fonctionnalites listees comme eligibles. Il couvre aussi Claude Code utilise avec une cle d'une organisation commerciale.
• Il ne couvre pas la Console (y compris le playground), ni les offres grand public (Free, Pro, Max), ni les interfaces Teams et Enterprise, ni les Covered Models.
• Certaines fonctionnalites qui passent pourtant par /v1/messages sont explicitement exclues, l'execution de code par exemple. Ne suppose pas qu'un ZDR couvre tout l'appel.
• Meme sous ZDR, des donnees peuvent etre conservees si la loi l'exige ou si un contenu est signale par les systemes automatises de confiance et securite : jusqu'a 2 ans dans ce cas.

OpenAI. La documentation developpeur indique que, par defaut, les donnees envoyees a l'API ne sont pas utilisees pour entrainer les modeles : « As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us). » Les journaux de surveillance des abus sont conserves jusqu'a 30 jours, sauf obligation legale de conservation plus longue. Un controle Zero Data Retention existe aussi, sur approbation.

Microsoft (Azure / Foundry). La page officielle est tres explicite. Tes prompts et completions, tes embeddings et tes donnees d'entrainement : ne sont pas accessibles aux autres clients, ne sont pas accessibles a OpenAI ou aux autres fournisseurs de modeles, ne sont pas utilises pour ameliorer leurs modeles ou services, et ne sont pas utilises pour entrainer un modele de fondation sans ta permission ou instruction. Elle precise aussi : « The models are stateless: no prompts or completions are stored in the model. »

La regle a retenir#

Attention : les conditions evoluent. Les pages officielles listees en sources sont la reference. Ne te fie pas a un article de blog ni a ce que quelqu'un t'a dit il y a six mois.

🌍 Retention et region#

Deux notions distinctes, ne les confonds pas.

La retention, c'est combien de temps c'est garde. Chez Anthropic, la politique commerciale standard est une suppression automatique sous 30 jours, avec des exceptions documentees (modeles a retention imposee, contenu signale, obligation legale). Chez Microsoft, la surveillance des abus peut stocker un echantillon de prompts et completions pour revue humaine, sauf si tu es approuve pour une surveillance modifiee.

La region, c'est ou c'est traite et stocke. Les deux plateformes offrent des controles :

• Chez Anthropic, deux reglages distincts existent. Le parametre d'API inference_geo controle ou tourne l'inference, avec deux valeurs : "global" (par defaut) et "us". Le workspace geo, choisi a la creation du workspace dans la Console, controle ou les donnees sont stockees au repos. Au niveau du workspace, tu peux aussi imposer allowed_inference_geos et default_inference_geo. Trois points a retenir : inference_geo n'est supporte qu'a partir des modeles Claude 4.6 (erreur 400 sur les plus anciens) ; seules les valeurs "global" et "us" existent, et "us" est le seul workspace geo disponible ; enfin, inference_geo: "us" coute 1,1 fois le tarif standard sur toutes les categories de tokens. Autrement dit : pas de residence des donnees en Europe sur l'API first-party Anthropic a la date de redaction. Verifie ce point, il est susceptible d'evoluer.
• Chez Microsoft, les prompts et reponses sont traites dans la geographie que tu choisis, sauf deploiements de type Global ou DataZone. Pour un DataZone cree dans un pays de l'Union europeenne, le traitement peut avoir lieu dans n'importe quel pays de l'Union. Les donnees stockees au repos restent dans la geographie designee.

Pour un projet europeen soumis a des exigences de localisation, c'est un critere de choix de plateforme a part entiere. Pose la question avant de coder.

✅ Checklist avant d'envoyer des donnees clients#

Imprime-la. Elle prend 2 minutes et elle t'evitera un incident.

AVANT D ENVOYER, JE VERIFIE :

[ ] 1. Nature des donnees
      Ces donnees contiennent-elles des informations sur des personnes
      identifiables ? Des categories particulieres (sante, opinions...) ?
      Des secrets techniques ?

[ ] 2. Necessite
      Ai-je besoin de ces champs pour obtenir ma reponse ?
      -> Si non : je les supprime. C'est la minimisation.

[ ] 3. Reduction
      Puis-je travailler sur un echantillon de 50 lignes au lieu de la table
      entiere ?
      Puis-je remplacer les valeurs reelles par des donnees fictives ?

[ ] 4. Pseudonymisation
      Les identifiants restants sont-ils haches avec un sel conserve chez moi ?
      La table de correspondance reste-t-elle interne ?

[ ] 5. Secrets
      J'ai relu ce que je colle. Aucune cle, aucun mot de passe, aucune chaine
      de connexion, aucun token. Ma garde automatique est active.

[ ] 6. Canal
      J'utilise bien le compte / la cle API autorises par mon entreprise pour
      ce type de donnees. Pas mon compte personnel.

[ ] 7. Regime contractuel
      Je sais si ce canal entraine ou non sur mes donnees, quelle est la duree
      de retention, et dans quelle region le traitement a lieu.

[ ] 8. Autorisation
      Pour des donnees clients reelles : j'ai une validation (DPO, securite,
      responsable). Je ne decide pas seul.

[ ] 9. Tracabilite
      Je sais quoi repondre si on me demande dans six mois ce qui a ete envoye,
      quand, et par quel canal.

📋 Template pret a copier : fiche de decision avant envoi#

La checklist te fait reflechir. Cette fiche garde la trace de ta decision. Remplis-la une fois par type de flux, pas une fois par prompt, et range-la dans le repo du projet.

FLUX : [NOM DU TRAITEMENT, EX : CATEGORISATION DES LIBELLES FOURNISSEURS]
Date : [DATE]   Responsable : [TON NOM]

DONNEES ENVOYEES
- Source : [TABLE / FICHIER / API D ORIGINE]
- Champs envoyes : [LISTE EXACTE DES COLONNES]
- Champs volontairement exclus : [LISTE + RAISON]
- Personnes identifiables ? [OUI / NON]
- Categories particulieres RGPD ? [OUI / NON - LESQUELLES]

TRAITEMENT AVANT ENVOI
- Pseudonymisation : [COLONNES CONCERNEES] par [METHODE, EX : SHA-256 + SEL]
- Ou est stocke le sel : [EMPLACEMENT, JAMAIS DANS LE CODE]
- Volume envoye : [EX : ECHANTILLON DE 200 LIGNES] au lieu de [VOLUME TOTAL]
- Garde automatique active : [OUI / NON] -> [NOM DE LA FONCTION]

CANAL
- Fournisseur et offre : [EX : API COMMERCIALE DE X]
- Cle utilisee : [QUELLE CLE / QUEL WORKSPACE]
- Entrainement sur mes donnees : [CE QUE DIT LA DOC + DATE DE VERIFICATION]
- Retention annoncee : [DUREE]
- Region de traitement : [VALEUR DU REGLAGE + LIMITES CONNUES]

VALIDATION
- Validee par : [DPO / SECURITE / RESPONSABLE, OU "SANS OBJET : DONNEES FICTIVES"]
- Date de revue suivante : [DATE, AU MAXIMUM 6 MOIS PLUS TARD]

🔁 AVANT / APRES : debugger une transformation#

Avant#

Ma transformation dbt donne des doublons. Voici un extrait de la table :

id,nom,email,telephone,montant,date_commande
4471,Sophie Martin,s.martin@exemple-client.fr,0612345678,340.00,2026-03-02
4471,Sophie Martin,s.martin@exemple-client.fr,0612345678,340.00,2026-03-02

Deux problemes : les donnees personnelles ne servent a rien pour diagnostiquer un doublon, et elles partent chez un tiers.

Apres#

Ma transformation dbt donne des doublons. Voici le modele et un extrait
structurellement identique, avec des valeurs fictives :

<modele_dbt>
[COLLE LE SQL DU MODELE]
</modele_dbt>

<extrait_fictif>
id,nom,email,telephone,montant,date_commande
4471,AAA,a@b.c,0000000000,340.00,2026-03-02
4471,AAA,a@b.c,0000000000,340.00,2026-03-02
</extrait_fictif>

La cle de grain attendue est (id, date_commande). Identifie dans <modele_dbt>
les jointures ou les fenetres qui peuvent multiplier les lignes, et cite les
lignes de SQL concernees.

Tu obtiens une meilleure reponse en plus d'etre propre : le modele se concentre sur la structure du SQL au lieu de s'interesser aux valeurs.

🧱 Bonnes pratiques d'equipe#

• Un jeu de donnees fictif versionne. Un seeds/exemple_commandes.csv avec 50 lignes realistes mais inventees, dans ton repo. Tout le monde s'en sert pour prompter.
• Une regle ecrite, une seule page. "Voici ce qui peut sortir, voici ce qui ne sort pas, voici par quel canal." Plus courte elle est, plus elle est lue.
• La garde automatique dans le code d'appel, pas dans la tete des gens.
• Le canal par defaut est l'acces entreprise. Si quelqu'un doit reflechir pour savoir quel compte utiliser, il se trompera.
• Documente tes choix. La CNIL insiste : la documentation des choix de conception est un point de conformite particulierement regarde.

A retenir#

• Un prompt est un transfert vers un sous-traitant externe. Traite-le comme tel.
• Pseudonymiser n'est pas anonymiser : le RGPD continue de s'appliquer aux donnees pseudonymisees.
• Sur l'API et les offres commerciales d'Anthropic, d'OpenAI et de Microsoft, les documentations officielles indiquent qu'il n'y a pas d'entrainement sur tes donnees sans autorisation expresse. Le regime grand public est different.
• Retention et region sont deux reglages distincts, tous les deux documentes et verifiables.
• Chez Anthropic, inference_geo n'accepte aujourd'hui que "global" et "us" : pas de residence europeenne sur l'API first-party a la date de redaction.
• La meilleure protection reste la minimisation : n'envoie pas ce dont tu n'as pas besoin.
• Ce document n'est pas un avis juridique. Pour les donnees clients reelles, passe par ton DPO.

Sources#

Toutes ces pages ont ete ouvertes et verifiees le 26 septembre 2026. Les conditions changent souvent : relis-les avant toute decision engageante.

• Anthropic - API and data retention : perimetre exact du ZDR, ce qu'il ne couvre pas, Covered Models, retention des contenus signales.
• Anthropic - Data residency : inference_geo, workspace geo, reglages de workspace et limites actuelles.
• Anthropic Privacy Center - How long do you store my organization's data? : la regle des 30 jours pour les offres commerciales.
• OpenAI - Your data : absence d'entrainement par defaut sur l'API, journaux d'abus, ZDR sur approbation.
• Microsoft Learn - Data, privacy, and security for Foundry Models sold by Azure : engagements sur l'entrainement, modeles sans etat, deploiements Global et DataZone.
• CNIL - Les fiches pratiques IA : le sommaire des fiches, dont l'analyse d'impact et l'information des personnes.
• CNIL - IA : garantir la securite du developpement : la fiche citee dans cette page.
• CNIL - Dossier Intelligence artificielle : le dossier general, point d'entree si tu cherches autre chose.
• data-privacy-stack/presidio - code d'exemple sur la detection et la pseudonymisation des donnees personnelles avant envoi : docs/samples/python. Ex-microsoft/presidio, le depot a demenage.