Pseudonymisation vs anonymisation : la différence RGPD expliquée
Quick Answer : pseudonymisation vs anonymisation
La différence tient en un mot : la réversibilité.
- Anonymisation : transformation irréversible. Il devient impossible de retrouver la personne, même en croisant avec d’autres sources, même avec une clé. La donnée sort du champ du RGPD. Très difficile à atteindre techniquement.
- Pseudonymisation (article 4.5 du RGPD) : remplacement réversible des identifiants directs par des pseudonymes, avec une clé de re-identification conservée séparément sous accès strict. La donnée reste personnelle au sens du RGPD, mais le risque est fortement réduit.
Conséquence pratique : la majorité des projets dits « anonymisation » produisent en réalité de la pseudonymisation. Tout en découle — base légale, AIPD, durée de conservation, transferts hors UE continuent de s’appliquer.
Comment un logiciel fait ce travail en 2026 : par la reconnaissance d’entités nommées (NER — la capacité d’une IA à repérer automatiquement noms, adresses, numéros, dates et organisations dans un texte), puis remplacement selon une politique définie. Précision de 92 à 99 % selon les outils — jamais 100 %, d’où la revue humaine sur échantillon.
Ce qu’aucun outil ne promet honnêtement : « sortir du RGPD » en un clic. La pseudonymisation est une fonction logicielle avec des limites documentées, pas une baguette magique juridique.
Pseudonymisation : la définition RGPD (article 4.5)
L’article 4.5 du RGPD définit la pseudonymisation comme « le traitement de données personnelles de telle façon qu’elles ne puissent plus être attribuées à une personne sans information supplémentaire conservée séparément, et soumise à des mesures techniques et organisationnelles ».
En clair : on remplace Marie Dupont par Personne_001, et on garde une table Personne_001 → Marie Dupont ailleurs, sous accès très restreint. La pseudonymisation réduit fortement le risque, mais la donnée reste personnelle au sens du RGPD. Toutes les obligations s’appliquent : registre, base légale, durée de conservation, droits des personnes, AIPD si applicable, contrats avec sous-traitants.
Le RGPD encourage explicitement la pseudonymisation comme mesure de sécurité (article 32) et comme garantie appropriée : c’est l’un des rares mécanismes techniques cités nommément par le texte.
Anonymisation : les trois conditions à réunir
Pour qu’une donnée soit vraiment anonymisée au sens du RGPD (considérant 26), trois conditions doivent être réunies en même temps :
- Pas de re-identification directe — les noms, identifiants, numéros sont supprimés ou transformés.
- Pas de re-identification indirecte — aucune combinaison d’attributs ne permet d’isoler une personne, y compris les contextes singuliers (« le seul directeur commercial parti d’ACME en mars 2025 »).
- Pas de re-identification par croisement — même en combinant avec un fichier électoral, un annuaire LinkedIn ou une base ouverte, la personne reste indistinguable.
Si ces trois conditions sont remplies, la donnée sort du champ du RGPD. Les atteindre est techniquement très difficile, surtout pour des textes libres (mails, comptes rendus, contrats). Les techniques formelles — k-anonymity, l-diversity, t-closeness — s’appliquent surtout aux bases tabulaires, pas au texte libre.
Anonymisation vs pseudonymisation : le tableau comparatif
| Critère | Anonymisation | Pseudonymisation |
|---|---|---|
| Lien avec la personne | Détruit irrémédiablement | Conservé via une clé séparée |
| Soumise au RGPD ? | Non | Oui |
| Faisabilité sur texte libre | Très difficile | Faisable avec NER + politique |
| Cas d’usage typique | Publication d’un dataset ouvert | Traitement interne, partage cadré |
| Risque résiduel | Quasi-nul (si bien faite) | Faible mais non nul |
| Effort de mise en œuvre | Élevé | Modéré |
Verdict pratique : la plupart des projets dits « anonymisation IA » sont en réalité de la pseudonymisation. Ce n’est pas une faiblesse, c’est un cadre clair. Le piège, c’est de promettre l’anonymisation et de livrer la pseudonymisation : la conformité s’effondre, et le DPO découvre le problème six mois plus tard.
Comment l’IA pseudonymise : la reconnaissance d’entités nommées
Le NER (Named Entity Recognition) est la brique technique au cœur de tout logiciel de pseudonymisation : il identifie dans un texte les entités appartenant à des catégories prédéfinies — personnes (PER), organisations (ORG), lieux (LOC), dates, emails, téléphones, IBAN, NIR. Pour un usage entreprise, on enrichit cette taxonomie de catégories métier : numéro patient, identifiant client, numéro de dossier. C’est ce typage métier qui fait la différence entre un NER générique et une pseudonymisation utilisable.
La pipeline d’un outil de pseudonymisation :
[Texte source]
│
▼
[NER] → liste d'entités détectées (type, valeur, position)
│
▼
[Politique de remplacement] → quoi supprimer, quoi pseudonymiser, quoi garder
│
▼
[Génération de pseudonymes] → table « original → pseudonyme »
│ │
│ ▼
│ [Coffre sécurisé]
▼ (clé de re-identification,
[Texte pseudonymisé] accès très restreint)Deux exigences techniques non négociables : le pseudonyme doit être stable (la même personne reçoit le même pseudonyme dans tous les documents, y compris quand Marie Dupont réapparaît sous Mme Dupont ou Mme D.) et non corrélé à la valeur originale (pas de simple hash, attaquable par dictionnaire). Le coffre qui stocke la table de correspondance est la pièce critique : si quiconque peut y accéder, la pseudonymisation s’effondre.
Trois approches d’outillage en 2026
- LLM générique bien prompté (Mistral Large, GPT-4o, Claude) : précision 95-98 % sur du français standard, taxonomie souple, mais coût d’inférence au volume et dépendance fournisseur. Le bon choix pour prototypes et volumes faibles à moyens.
- Modèle NER dédié open-source (spaCy, GLiNER, Camembert-NER, Presidio) : millisecondes par document, économique au volume, déployable on-premise avec zéro sortie de données — mais taxonomie plus figée et faible compréhension du contexte. Le bon choix pour gros volumes et souveraineté maximale.
- Hybride : modèle dédié sur le gros du flux + LLM sur les cas ambigus + revue humaine sur les cas critiques. L’optimum coût/précision en production stabilisée.
Pour la souveraineté : Mistral on-premise (vLLM) ou La Plateforme (France) + spaCy en interne. Attention à Presidio : excellent framework, mais l’inférence par défaut transite via OpenAI — à recâbler.
Les limites : ce que l’outil ne voit pas
Un logiciel de pseudonymisation honnête documente ses limites. Le NER, même excellent, rate trois familles de données identifiantes :
- Les données indirectement identifiantes par contexte. « Le directeur commercial qui a quitté ACME en mars 2025 pour un concurrent » — aucun nom propre, mais une seule personne au monde correspond. Le NER détecte les entités, pas la singularité de leur combinaison.
- Les combinaisons rares. « Femme, 47 ans, ingénieure agronome, vivant à Guérande, mère de jumeaux » — aucun élément n’est identifiant isolément, l’ensemble l’est très fortement.
- Les références implicites internes. « Le client dont on parlait hier au téléphone » — aucune entité détectable, et pourtant identifiable par qui connaît le contexte.
D’où deux garde-fous obligatoires : la revue humaine sur échantillon (5-10 % du corpus au démarrage, 1-2 % en régime stable) et les tests de re-identification — on tente activement de re-identifier sur un échantillon ; si on y arrive trop facilement, la pseudonymisation est insuffisante. Cette pratique est attendue par la CNIL pour les projets sensibles. Aucun modèle n’atteint 100 % de rappel : un outil qui promet le contraire ment.
Cas d’usage en entreprise : où la pseudonymisation tient
Six cas robustes, du point de vue de ce qu’un outil fait réellement :
- Préparer un corpus pour fine-tuning interne — sans pseudonymisation, les données personnelles risquent de se retrouver dans les poids du modèle, extractibles par membership inference. Métrique de succès : taux de re-identification < 1 % sur échantillon manuel.
- Partager un dataset avec un consultant ou un partenaire académique — avec DPA, durée de conservation limitée et destruction prouvable. La pseudonymisation seule ne remplace pas le contrat.
- Répondre à une demande RGPD article 15 — la personne a droit à ses données, pas à celles des tiers présents dans les mêmes documents. NER + caviardage des tiers rend la réponse conforme.
- Analyser un corpus interne (mails, support) pour des finalités managériales sans franchir la ligne de la surveillance individuelle illégale — pseudonymisation + agrégation, information du CSE, AIPD documentée.
- Conformité sectorielle — santé HDS, secret professionnel : pseudonymiser en amont permet parfois d’envoyer le contenu à un LLM moins contraint, l’original restant en environnement HDS. Voir notre guide IA santé HDS.
- Préparer des documents avant un appel à un LLM SaaS — réduire l’exposition en supprimant les identifiants dont le modèle n’a pas besoin. Une bonne IA n’a pas besoin de savoir qui est concerné pour rédiger une synthèse.
Ce que le RGPD attend vraiment
La pseudonymisation par IA est elle-même un traitement automatisé de données personnelles — donc soumise au RGPD. En cas de contrôle, il faut pouvoir produire :
- Une fiche au registre des traitements : finalité, catégories de données, personnes concernées, durées de conservation (de l’original, de la version pseudonymisée, de la table de correspondance — chacune justifiée), sous-traitants, mesures de sécurité.
- Une base légale : le plus souvent l’intérêt légitime (avec test de mise en balance documenté), parfois l’exécution d’un contrat ou une obligation légale.
- Une AIPD quand le traitement est à risque élevé : volumes élevés, données sensibles, grande échelle, surveillance d’employés, croisement de sources. Voir notre guide AIPD pour projet IA.
- Un DPA avec le fournisseur LLM le cas échéant : localisation UE, interdiction d’entraînement sur les données, durées de rétention, sous-traitants ultérieurs. Avec un fournisseur souverain européen, le dossier est nettement plus simple ; avec un fournisseur américain, il devient un dossier technique à part entière.
Pour des données sensibles, la localisation du traitement compte autant que l’outil : cloud souverain (Scaleway, OVHcloud, Outscale) ou on-premise, zéro sortie de données. C’est l’approche que retient DPLIANCE dans ses solutions IA sur mesure : la pseudonymisation y est une fonction intégrée à la pipeline, avec ses métriques et ses limites documentées — pas une prestation de conseil.
Ce qu’on refuse de promettre
« On va anonymiser, donc on sort du RGPD. » Non, sauf cas très exceptionnel. La pseudonymisation reste sous RGPD. Si la promesse de sortie du RGPD est nécessaire au projet, il faut redessiner le projet — pas tordre le sens des mots.
« Le logiciel détecte tout, pas besoin de revue humaine. » Aucun NER ne détecte les contextes singuliers, les combinaisons rares, les références implicites. La revue humaine sur échantillon est non négociable au démarrage, et reste recommandée en régime stable.
« On garde la clé de re-identification, mais on la verrouille bien. » Si la clé reste accessible à plusieurs personnes, la pseudonymisation devient théorique. La pratique RGPD attend un accès très restreint, journalisé, avec un processus de récupération exceptionnel et tracé.
FAQ
Quelle est la différence concrète entre pseudonymisation et anonymisation ?
L’anonymisation est irréversible : il devient impossible de retrouver la personne, même en croisant avec d’autres sources, même avec une clé. La donnée sort du champ du RGPD. La pseudonymisation est réversible : un identifiant pseudonyme remplace les identifiants directs, mais une clé de re-identification existe ailleurs sous accès strict. La donnée reste personnelle au sens du RGPD. Conséquence pratique : la majorité des projets dits « anonymisation » produisent en réalité de la pseudonymisation, et les obligations RGPD continuent de s’appliquer (registre, base légale, AIPD si nécessaire).
Une donnée pseudonymisée reste-t-elle soumise au RGPD ?
Oui. Le RGPD considère qu’une donnée reste personnelle dès lors qu’une re-identification reste possible — directement, indirectement, par croisement avec d’autres sources, ou via la clé de pseudonymisation. La pseudonymisation réduit le risque mais ne fait pas sortir la donnée du champ RGPD. Pour atteindre une vraie anonymisation au sens du RGPD, il faut détruire la clé, supprimer les données indirectement identifiantes, et résister à des attaques par croisement. C’est techniquement très difficile.
Comment un logiciel pseudonymise-t-il un texte ?
Par la reconnaissance d’entités nommées (NER, Named Entity Recognition) : l’outil détecte les noms, adresses, numéros, dates et organisations dans un texte, puis les remplace par des pseudonymes stables (Marie Dupont devient Personne_001) selon une politique de remplacement définie. La table de correspondance est stockée séparément dans un coffre à accès restreint. Sur du français standard, un LLM moderne bien prompté détecte 95 à 98 % des entités explicites ; les modèles dédiés (spaCy, GLiNER, Camembert-NER) atteignent 92 à 99 % de F1 selon le domaine.
Le NER suffit-il à anonymiser un texte ?
Non, presque jamais. Le NER détecte les entités nommées explicites : noms, prénoms, téléphones, adresses, IBAN, dates. Il rate systématiquement les données indirectement identifiantes : descriptions précises (« le directeur commercial qui a quitté ACME en mars 2025 »), combinaisons singulières (âge + ville + métier), références internes (numéro de dossier corrélé à un client). Une anonymisation rigoureuse exige NER + analyse contextuelle + revue humaine sur les cas critiques + tests de robustesse à la re-identification.
Quels cas d’usage de la pseudonymisation tiennent vraiment en entreprise ?
Six cas robustes : (1) préparer un corpus pour fine-tuning d’un modèle interne sans risque de fuite ; (2) partager un dataset avec un consultant ou un partenaire académique ; (3) répondre à une demande RGPD article 15 (droit d’accès) sans exposer les données d’autres personnes ; (4) analyser des corpus internes pour des finalités managériales sans surveillance individuelle illégale ; (5) conformité sectorielle (santé HDS, secret professionnel) ; (6) préparation de documents avant un appel à un LLM SaaS pour réduire l’exposition.
Avec quels outils peut-on pseudonymiser de manière souveraine en 2026 ?
LLM génériques souverains : Mistral Large via La Plateforme (France), Mistral on-premise via vLLM. Modèles dédiés open-source : spaCy avec corpus français (excellent rapport performance/coût), GLiNER multilingue, Camembert-NER. Microsoft Presidio est un bon framework open-source mais l’inférence par défaut transite via OpenAI — à recâbler vers un fournisseur souverain ou en local. Pour la souveraineté maximale : Mistral on-prem + spaCy en interne, zéro sortie de données.
Faut-il une AIPD pour un projet de pseudonymisation par IA ?
Recommandée dans la plupart des cas, obligatoire dans plusieurs : volumes élevés, données sensibles (santé, opinions, biométriques), traitement à grande échelle, surveillance systématique d’employés, croisement de sources. La logique : la pseudonymisation par IA est elle-même un traitement automatisé de données personnelles, donc soumise au RGPD. L’AIPD documente le risque résiduel, justifie les choix techniques, et formalise le contrôle d’accès à la clé de re-identification.
Sources : Règlement (UE) 2016/679 (RGPD), notamment articles 4(5), 32 et considérant 26 ; G29/EDPB, avis 05/2014 sur les techniques d’anonymisation ; CNIL, fiches pratiques sur l’anonymisation et la pseudonymisation ; documentation officielle spaCy, Microsoft Presidio, GLiNER, Camembert-NER ; documentation Mistral AI La Plateforme.
Pour cadrer un projet de pseudonymisation dans votre organisation — choix d’outil, pipeline, conformité — voir notre guide IA et RGPD, notre guide AIPD pour projet IA, notre guide LLM local en entreprise, ou contactez-nous via nos solutions IA sur mesure.