Anonymiser ou pseudonymiser avant de vectoriser ? La distinction RGPD, pourquoi l'anonymisation parfaite est rare sur du texte libre, les techniques (NER, pseudonymisation cohérente) et les réflexes à adopter.
Avant qu'un document n'entre dans un pipeline RAG, il passe par une étape lourde de conséquences : la vectorisation. À partir de ce moment, son contenu — y compris les données personnelles qu'il contient — est dupliqué dans des embeddings, indexé, et potentiellement envoyé à des modèles externes au fil des requêtes. D'où une question que trop d'équipes repoussent : faut-il anonymiser ou pseudonymiser les données personnelles avant de vectoriser ? Et jusqu'où est-ce vraiment possible ?
Cet article fait le tour des techniques, de leurs limites, et des réflexes à adopter — sans vous vendre une promesse de conformité que la technique ne tient pas.
On confond souvent les deux termes. Le RGPD, lui, les sépare nettement :
La frontière entre les deux n'est pas un détail de vocabulaire : elle détermine si vous avez encore des obligations (base légale, durée de conservation, droits des personnes, registre de traitement) ou non. Et le critère officiel est exigeant. Pour qu'une donnée soit jugée anonyme, l'autorité de référence européenne (le G29, devenu le CEPD) demande qu'aucun des trois risques suivants ne subsiste : la singularisation (isoler un individu dans le jeu de données), la corrélation (relier deux enregistrements à la même personne) et l'inférence (déduire une information sur une personne avec une probabilité élevée). Sur du texte libre, écarter ces trois risques simultanément est extrêmement difficile.
L'anonymisation totale et irréversible est un Graal rarement atteint sur du texte riche. Dans la pratique, on fait surtout de la pseudonymisation — et on ne doit jamais prétendre le contraire, ni en interne, ni vis-à-vis d'un auditeur.
Anonymiser une colonne « email » dans une base, c'est simple. Anonymiser un texte libre — un compte-rendu, un ticket support, un contrat — c'est une autre affaire :
Le danger n'est pas tant le nom explicite que vous avez masqué — c'est tout ce qui reste autour. Quelques cas vus en production :
C'est le dilemme central : plus on protège, moins on conserve d'utilité — et inversement.
Repérer automatiquement noms, emails, téléphones, adresses, numéros (IBAN, sécurité sociale, plaques). C'est la brique de base, portée par des modèles spécialisés (spaCy, Presidio de Microsoft, modèles transformeurs fine-tunés, ou un LLM en extraction). Indispensable, mais imparfaite : elle trébuche sur le jargon métier, les fautes de frappe, les formats inhabituels, les noms rares ou étrangers, et surtout sur les identifiants indirects (une fonction, un lieu) qu'aucun détecteur d'entité ne flague comme « donnée personnelle ». Comptez sur un rappel élevé mais jamais total : prévoyez un filet de sécurité (revue humaine sur les corpus sensibles, listes de motifs métier).
Remplacer l'entité par un marqueur fixe ([NOM], [EMAIL]). Simple et robuste, mais casse la cohérence : deux mentions du même nom deviennent indistinctes. Le texte « [NOM] a transmis le dossier à [NOM], qui l'a validé » devient illisible pour un modèle — impossible de savoir s'il s'agit d'une ou deux personnes. Acceptable pour de la simple suppression de log, médiocre pour du RAG conversationnel.
Remplacer chaque entité par un jeton stable et unique (PERSONNE_42), de sorte que toute occurrence de la même personne reçoive le même jeton dans tout le corpus. C'est ce qui préserve les relations — donc l'utilité des réponses. Exemple avant/après :
# AVANT
Marie Dupont (marie.dupont@acme.fr), directrice juridique, a négocié
le contrat avec Acme Corp puis l'a fait signer par Jean Martin, son
adjoint. Marie Dupont reste l'interlocutrice du dossier.
# APRÈS (pseudonymisation cohérente)
PERSONNE_1 (EMAIL_1), ROLE_1, a négocié le contrat avec ORG_1 puis
l'a fait signer par PERSONNE_2, son adjoint. PERSONNE_1 reste
l'interlocutrice du dossier.
Le modèle conserve l'information structurante : il y a deux personnes distinctes, une relation hiérarchique, une organisation, et PERSONNE_1 apparaît bien deux fois. Une question comme « qui est l'interlocuteur du dossier Acme ? » renvoie PERSONNE_1, que l'application peut re-substituer par « Marie Dupont » à l'affichage si et seulement si l'utilisateur est habilité — via le coffre de correspondances décrit plus bas.
Remplacer une valeur précise par une catégorie : « 34 ans » → « 30-40 ans », « 12 mars 2024 » → « T1 2024 », « Lyon » → « grande métropole française ». Réduit le risque de singularisation au prix de la finesse. C'est l'outil idéal contre les quasi-identifiants vus plus haut, mais il faut doser : généraliser « directeur financier de la filiale lyonnaise » en « cadre dirigeant » peut vider la phrase de tout intérêt analytique.
Conserver la table qui relie chaque jeton (PERSONNE_42) à sa valeur réelle (« Marie Dupont ») dans un magasin séparé, chiffré, sous contrôle d'accès strict, avec sa propre durée de conservation et sa propre journalisation. C'est ce coffre qui rend la pseudonymisation réversible — et c'est précisément son existence qui maintient les données dans le champ du RGPD.
Pour le RAG, la pseudonymisation cohérente est souvent le meilleur compromis : elle préserve les relations entre entités (donc l'utilité des réponses) tout en retirant les identifiants directs des embeddings et des prompts. La généralisation vient en complément pour neutraliser les quasi-identifiants que le NER ne voit pas.
Il n'y a pas de réglage universel : le bon dosage dépend du corpus et de l'usage. Prenez un même passage et trois niveaux de traitement :
L'erreur fréquente est de croire que « plus de masquage = mieux ». Sur un corpus juridique ou médical, sur-anonymiser détruit la valeur même qui justifiait le projet RAG. La bonne démarche : classer les données par sensibilité, et n'appliquer le traitement le plus lourd qu'à ce qui le mérite. Parfois, la meilleure réponse n'est pas d'anonymiser davantage mais de restreindre l'accès et de maîtriser l'hébergement.
On sécurise souvent l'ingestion en oubliant l'autre bout de la chaîne. Au moment de répondre, un RAG récupère des chunks et les recolle dans un prompt envoyé au modèle de génération. Si ce modèle est une API hors UE, vous venez d'exporter des données personnelles — même si votre base vectorielle, elle, est parfaitement hébergée en Europe.
Requête utilisateur
→ recherche vectorielle (chunks pseudonymisés ou non ?)
→ assemblage du prompt
→ APPEL API LLM ← point de fuite si hors UE et si chunks non pseudonymisés
→ réponse
Deux conséquences pratiques. D'abord, si vos chunks contiennent encore des données personnelles, chaque requête qui les remonte les transmet au fournisseur du LLM, avec toutes les questions de transfert hors UE et de réutilisation que cela pose. Ensuite, c'est exactement là que la pseudonymisation cohérente paie : en pseudonymisant avant la vectorisation, les chunks remontés ne contiennent que des jetons, le LLM externe ne voit jamais d'identité, et la re-substitution se fait côté application, après la réponse, sous contrôle d'habilitation. La règle est simple : rien d'identifiant ne doit franchir la frontière du périmètre maîtrisé.
Anonymiser avant vectorisation est une bonne intention qui se heurte à une réalité technique : sur du texte riche, l'anonymisation parfaite est rare, et la pseudonymisation cohérente est le compromis réaliste. L'essentiel est de ne pas se mentir sur le niveau réel de protection, de traiter le risque de ré-identification par le contexte autant que les identifiants directs, de pseudonymiser systématiquement ce qui part vers l'extérieur, et de combler le reste par le contrôle d'accès et l'hébergement souverain. La protection des données personnelles dans un RAG n'est pas une case à cocher : c'est une chaîne de décisions, de l'ingestion à l'inférence.
Les agents IA gérés par les grands hyperscalers américains posent un problème de conformité que beaucoup de DSI préfèrent ignorer. Faisons le point.
Le guide de conformité RGPD pour vos projets RAG : base légale, minimisation, données personnelles dans les embeddings et les prompts, droit à l'effacement qui cascade jusqu'aux vecteurs, sous-traitants et articulation avec l'AI Act.
Calendrier réel des obligations de l'EU AI Act (2025-2027), niveaux de risque, place d'un assistant RAG d'entreprise et checklist de conformité concrète — sans jargon, pour DPO et équipes produit.
Démarrez gratuitement. Premier audit Knowledge Pulse en 60 secondes.
Démarrer gratuitement