Anonymisation et NER par IA : le guide qui démêle anonymisation, pseudonymisation et RGPD (2026)

Q: Quelle est la différence concrète entre anonymisation et pseudonymisation ?

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 IA » produisent en réalité de la pseudonymisation. Les obligations RGPD continuent de s'appliquer (registre, base légale, AIPD si nécessaire), même si le risque a baissé.

Q: Le NER (reconnaissance d'entités nommées) suffit-il à anonymiser un texte ?

Non, presque jamais. Le NER détecte les entités nommées explicites : noms, prénoms, numéros de téléphone, 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), tournures contextuelles. Une anonymisation rigoureuse exige NER + analyse contextuelle + revue humaine sur les cas critiques + tests de robustesse à la re-identification.

Q: Quelle précision attendre d'un NER IA en 2026 ?

Sur du français standard, un LLM moderne (Mistral Large, GPT-4o, Claude) détecte 95 à 98 % des entités nommées explicites avec un prompt bien construit. Les modèles dédiés (spaCy fr_core_news_lg, GLiNER multilingue, modèles fine-tunés) atteignent 92 à 99 % de F1 selon le domaine. La performance chute fortement sur : noms étrangers ou rares, langues mixtes, abréviations métier, références implicites au sein du texte. Aucun modèle n'atteint 100 % — c'est pour cela que la revue humaine sur un échantillon reste indispensable au démarrage.

Q: Faut-il un LLM générique ou un modèle NER dédié ?

Pour la majorité des cas en 2026, un LLM générique bien prompté (Mistral, GPT-4o, Claude) suffit avec une précision supérieure à 95 %. Le modèle NER dédié (spaCy, GLiNER, modèle fine-tuné) devient pertinent quand le volume est très élevé (millions de documents par mois), quand la latence est critique (temps réel), ou quand le contexte est ultra-spécialisé (terminologie médicale ou juridique non standard). La règle simple : démarrer en LLM générique pour le prototype, basculer vers du dédié si le coût d'inférence ou la performance le justifie.

Q: Une donnée pseudonymisée par NER 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.

Q: Quels cas d'usage tiennent vraiment en entreprise ?

Six cas d'usage 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 (mails, comptes rendus) pour des finalités managériales sans franchir la ligne de la surveillance individuelle illégale ; (5) conformité sectorielle (santé HDS, juridique secret pro) ; (6) préparation de documents avant un appel à un LLM SaaS pour réduire l'exposition.

Q: Avec quels outils peut-on faire de l'anonymisation IA souveraine en 2026 ?

LLM génériques souverains : Mistral Large via La Plateforme (France), Mistral on-premise via vLLM, autres fournisseurs européens. 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 excellent 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 ou Llama 3 self-hosted + spaCy en interne, zéro sortie de données.

Q: Faut-il une AIPD pour un projet d'anonymisation 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 : l'anonymisation IA est elle-même un traitement automatisé de données personnelles, donc soumise au RGPD. L'AIPD documente le risque résiduel après pseudonymisation, justifie les choix techniques, et formalise le contrôle d'accès à la clé de re-identification.

Quick Answer : qu’est-ce que l’anonymisation par IA et le NER ?

L’anonymisation et la pseudonymisation par IA s’appuient sur la technique du NER (Named Entity Recognition, ou « reconnaissance d’entités nommées » : la capacité d’une IA à repérer automatiquement les noms, adresses, numéros, dates, organisations dans un texte). L’IA identifie ces données personnelles puis les remplace par des marqueurs ou des pseudonymes.

Distinction RGPD critique :

Anonymisation : transformation irréversible. La donnée sort du champ du RGPD. Très difficile à atteindre techniquement — il faut s’assurer qu’on ne pourra jamais retrouver la personne, même en croisant avec d’autres sources, et même si quelqu’un récupère la clé.
Pseudonymisation (article 4.5 du RGPD) : remplacement réversible sous accès strict. La donnée reste personnelle au sens du RGPD, mais le risque est réduit.

La majorité des projets dits « anonymisation IA » produisent en réalité de la pseudonymisation. C’est la première chose à clarifier : tout le reste — base légale, AIPD, durée de conservation, transferts hors UE — en découle.

Outils 2026 :

Grands modèles de langage (Mistral Large, GPT-4o, Claude) : précision 95-98 % sur du français standard, simples à mettre en œuvre via une instruction (« prompt »), mais coût d’inférence et dépendance fournisseur.
Modèles NER dédiés (spaCy, GLiNER, Camembert-NER, Presidio Microsoft) : plus rapides, plus économiques pour gros volumes, mais taxonomie figée.
Pour la souveraineté : Mistral installé localement (« on-premise ») + spaCy hébergé en interne, zéro sortie de données vers les États-Unis.

Cas d’usage qui tiennent : préparation de corpus pour fine-tuning interne, partage avec partenaires académiques, réponse à une demande RGPD article 15 sans exposer les données d’autres personnes, analyse managériale de corpus internes, conformité sectorielle (santé HDS, juridique secret professionnel), préparation de documents avant un appel à un LLM SaaS.

Pourquoi ce sujet, maintenant

Beaucoup d’organisations ont en tête « envoyer nos documents à un LLM, mais sans les données personnelles dedans ». L’idée est saine. La promesse est rarement tenue.

Trois choses ont changé en 2026. Un, les LLM modernes savent vraiment faire du NER en français — ce n’était pas vrai en 2022. Deux, les modèles dédiés open-source (spaCy, GLiNER, Camembert-NER) sont désormais à portée d’un déploiement souverain — pas besoin d’envoyer un mot à OpenAI pour anonymiser un mot. Trois, la doctrine RGPD s’est durcie sur ce qu’on appelle vraiment « anonymisation » : la CNIL et l’EDPB rappellent régulièrement que pseudonymiser n’est pas anonymiser.

Le piège : croire qu’un détecteur de noms suffit pour « sortir du RGPD ». Il ne suffit pas. Cet article démêle ce qui marche, ce qui ne marche pas, et où placer la frontière entre l’IA, l’organisation, le DPO et la machine humaine de validation.

Anonymisation vs pseudonymisation : la distinction qui change tout

C’est la base. Tout le reste — base légale, AIPD, contrats avec sous-traitants, durée de conservation — dépend de cette distinction.

Anonymisation au sens du RGPD

Pour qu’une donnée soit vraiment anonymisée, 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. Cela inclut 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 d’application du RGPD. C’est la promesse maximale.

Atteindre ces trois conditions est techniquement très difficile, particulièrement pour des textes libres (mails, comptes rendus, contrats). Les techniques formelles existent — k-anonymity, l-diversity, t-closeness — mais elles s’appliquent surtout à des bases tabulaires, pas à du texte libre.

Pseudonymisation au sens du RGPD

L’article 4.5 du RGPD la définit 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.

Tableau de décision rapide

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.

Le NER : ce qu’il fait, ce qu’il ne fait pas

La mécanique

Le NER (Named Entity Recognition) identifie dans un texte les entités nommées appartenant à des catégories prédéfinies. Une taxonomie classique :

Catégorie	Exemple	Sensibilité RGPD
PER — personne	Marie Dupont, M. Martin	Identifiant direct
ORG — organisation	ACME SA, CHU de Lille	Indirect (combiné à PER)
LOC — lieu	Paris, 24 rue Lafayette	Indirect, parfois direct (adresse précise)
DATE	15 mars 2026	Indirect (dates événements personnels)
EMAIL / PHONE / IBAN / NIR	marie@acme.com, 06 12 34 56 78	Identifiants directs
MISC — divers	Numéro de dossier, référence interne	Variable

Pour la pseudonymisation en entreprise, on enrichit cette taxonomie de catégories métier : numéro patient, identifiant client, numéro de dossier, montants sensibles, identifiants de contrats. C’est ce travail de typage métier qui fait la différence entre un NER générique et une pseudonymisation utilisable.

Schéma simplifié de la pipeline

[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)

Le coffre est la pièce critique. Si quiconque peut accéder à la table de correspondance, la pseudonymisation s’effondre. C’est un point d’architecture, pas un détail d’implémentation.

Ce que le NER ne voit pas

Le NER, même excellent, rate trois familles de données identifiantes :

1. Les données indirectement identifiantes par contexte. « Le directeur commercial qui a quitté ACME en mars 2025 pour un concurrent » — aucun nom propre dans la phrase, mais une seule personne au monde correspond. Le NER détecte « directeur commercial », « ACME », « mars 2025 ». Il ne comprend pas que la combinaison est singulière.

2. Les combinaisons rares. « Femme, 47 ans, ingénieure agronome, vivant à Guérande, mère de jumeaux » — aucun élément n’est identifiant pris isolément, l’ensemble l’est très fortement. Aucun NER ne détecte « combinaison rare ».

3. Les références implicites internes. « Comme convenu hier au téléphone, voici le projet de courrier pour le client dont on parlait » — le NER ne voit aucune entité identifiable, et pourtant un humain qui connaît le contexte sait exactement de qui il s’agit.

C’est pour cela que la revue humaine sur un échantillon reste obligatoire : 5 à 10 % du corpus au démarrage, baissable à 1-2 % une fois les patterns stabilisés. Et c’est aussi pour cela qu’on combine systématiquement le NER avec une politique de réécriture contextuelle sur les cas à fort enjeu : on ne remplace pas seulement les noms, on neutralise aussi les contextes singuliers.

Les trois approches techniques (vulgarisées)

Approche 1 — LLM générique avec instruction

On donne au LLM une instruction du type : « identifie dans ce texte toutes les entités nommées et retourne-les sous forme structurée, avec leur type et leur position ». Les modèles modernes (Mistral Large, GPT-4o, Claude) le font très bien sur le français standard.

Avantages	Limites
Précision élevée (95-98 % sur français standard)	Coût d’inférence non négligeable au volume
Gère le contexte (utile pour les cas ambigus)	Latence (quelques secondes par document)
Souple : on adapte la taxonomie via le prompt	Dépendance fournisseur LLM
Pas de courbe d’apprentissage technique	Sortie potentielle vers fournisseur étranger si SaaS

Quand c’est le bon choix : prototypes, volumes faibles à moyens (jusqu’à quelques dizaines de milliers de documents par mois), taxonomie évolutive, équipe qui n’a pas d’expertise NLP.

Approche 2 — Modèle NER dédié (open-source)

Modèle pré-entraîné spécialisé : spaCy, GLiNER, Camembert-NER, Presidio Microsoft. Tourne en local, très rapide, faible coût.

Avantages	Limites
Très rapide (millisecondes par document)	Taxonomie figée par défaut
Économique au volume	Performance variable selon le domaine
Déployable on-premise, zéro sortie de données	Setup plus technique (Python, modèles à packager)
Mature (spaCy est en production depuis 2015)	Faible compréhension du contexte

Quand c’est le bon choix : volumes élevés, latence critique, exigence de souveraineté maximale, budget d’inférence à maîtriser.

Approche 3 — Hybride

Modèle dédié pour la détection rapide sur le gros du flux + LLM générique pour les cas complexes ou ambigus + revue humaine sur les cas critiques.

Avantages	Limites
Optimum coût / précision sur gros volumes	Architecture plus complexe
Robuste sur les cas atypiques	Demande un orchestrateur (LangChain, code custom)
Compatible souveraineté	Exige un suivi des métriques (taux de bascule LLM)

Quand c’est le bon choix : production stabilisée, gros volumes, exigence de qualité élevée, équipe capable d’opérer une pipeline.

Arbre de décision rapide

Volume mensuel ?
│
├── < 10 000 documents
│   └── Latence critique (temps réel) ?
│       ├── Oui → NER dédié (spaCy)
│       └── Non → LLM générique
│
├── 10 000 – 1 million
│   └── Sensibilité maximale ?
│       ├── Oui → Hybride sur stack souveraine
│       └── Non → LLM générique souverain (Mistral)
│
└── > 1 million
    └── Hybride obligatoire (économie d'inférence + qualité)

Cas d’usage qui tiennent

Pas de catalogue exhaustif. Six cas robustes, avec ce qu’il faut savoir avant de démarrer.

Cas 1 — Préparer un corpus pour fine-tuning interne

Contexte : une organisation veut adapter un LLM open-source (Llama, Mistral) à son métier. Elle dispose d’un corpus de comptes rendus internes, d’échanges mail, de documentation. Sans pseudonymisation, ces données risquent de se retrouver dans les poids du modèle final, et de réapparaître via une attaque dite par membership inference (« est-ce que ce document était dans le corpus d’entraînement ? »).

Volumétrie type : 10 000 à 500 000 documents.

Ce qui peut foirer : pseudonymisation incomplète sur les références internes (numéros de dossier, codes projets) — ces références ne sont pas vues par le NER mais permettent un croisement interne.

Métrique de succès : taux de re-identification < 1 % sur un échantillon manuel post-pseudonymisation.

Cas 2 — Partager avec un partenaire académique ou un consultant

Contexte : un cabinet juridique veut partager un corpus de contrats avec un laboratoire pour une analyse statistique. Un acteur santé veut partager des comptes rendus avec un consultant data pour un audit qualité.

Volumétrie type : quelques milliers de documents.

Ce qui peut foirer : sous-estimation des données indirectement identifiantes. Un contrat anonymisé sur les noms des parties peut rester identifiable par le numéro d’affaire, le tribunal compétent, la date d’enregistrement.

Garde-fou : DPA (accord de traitement des données) avec le partenaire, durée de conservation limitée, destruction prouvable, audit possible. La pseudonymisation seule ne remplace pas le contrat.

Cas 3 — Répondre à une demande RGPD article 15

Contexte : une personne demande l’accès à ses données personnelles. Elle a le droit de les recevoir — mais pas d’obtenir au passage les données d’autres personnes présentes dans les mêmes documents (mails, comptes rendus). Le NER + caviardage des tiers rend la réponse conforme.

Volumétrie type : variable, parfois quelques documents, parfois plusieurs centaines.

Ce qui peut foirer : sur-pseudonymisation qui rend le document inintelligible et empêche le demandeur de comprendre ses propres données.

Garde-fou : politique claire de ce qu’on caviarde et de ce qu’on garde, validation par le DPO ou le service juridique avant envoi.

Cas 4 — Analyser un corpus interne sans tomber dans la surveillance individuelle

Contexte : une direction veut comprendre les sujets récurrents dans les échanges internes (mails, support client) sans franchir la ligne de la surveillance individuelle illégale au sens du Code du travail. La pseudonymisation des expéditeurs et destinataires permet une analyse agrégée.

Volumétrie type : 10 000 à 1 million de messages par mois.

Ce qui peut foirer : la pseudonymisation ne suffit pas si l’analyse révèle indirectement le comportement individuel (volume d’envoi atypique, patterns horaires uniques). Il faut aussi agréger avant analyse.

Garde-fou : information préalable du CSE, AIPD documentée, finalité limitée, accès restreint aux résultats.

Cas 5 — Conformité sectorielle (santé HDS, juridique secret pro)

Contexte : un acteur santé veut utiliser un LLM externe pour analyser des comptes rendus médicaux. Si l’identifiant patient n’est pas nécessaire à l’analyse, la pseudonymisation en amont permet d’envoyer le contenu à un LLM moins contraint (Mistral Le Chat Enterprise) au lieu d’imposer une infrastructure HDS complète. Voir notre guide IA santé HDS.

Garde-fou : DPA avec le fournisseur LLM, AIPD obligatoire, traçabilité de chaque envoi, conservation de la version originale en environnement HDS.

Cas 6 — Préparation comptable et flux financiers

Contexte : factures sensibles (factures fournisseurs incluant des données salariales, factures de soins en mutuelle), notes de frais détaillées. Pseudonymisation des données patients ou salariés avant traitement par un LLM SaaS pour l’extraction structurée. Voir notre guide automatisation factures par IA.

Volumétrie type : 10 000 à 500 000 documents par mois selon la taille de l’organisation.

Architecture-type : ce qu’on monte concrètement

Une pipeline d’anonymisation IA en production se décompose en sept étapes. Chacune a ses pièges.

Étape 1 — Ingestion. Le document arrive au format brut : PDF, Word, mail, export base de données, image scannée. Pour les documents non-textuels, OCR préalable (Tesseract, AWS Textract en local, Doctly). À ce stade, on conserve l’original chiffré pour audit.

Étape 2 — Détection NER. LLM ou modèle dédié identifie les entités. Sortie : liste structurée {type, valeur, offset_début, offset_fin}. Pour les longs documents, on découpe en blocs de quelques milliers de caractères avec recouvrement (« chunking »), sinon les modèles ratent les entités à cheval.

Étape 3 — Politique de remplacement. Décision métier, pas technique :

Catégories à supprimer (suppression nette, ex : numéros de carte bancaire dans des mails)
Catégories à pseudonymiser (remplacement par identifiant pseudonyme stable, ex : noms de personnes)
Catégories à conserver (utiles à l’usage en aval, ex : dates si elles servent à l’analyse temporelle)

Étape 4 — Génération de pseudonymes. Marie Dupont → Personne_001. Le pseudonyme doit être stable (la même personne reçoit le même pseudonyme dans tous les documents) et non corrélé à la valeur originale (pas de hash de la valeur — un hash peut être attaqué par dictionnaire si le domaine est petit). On stocke la table de correspondance dans un coffre séparé.

Étape 5 — Application au texte. Remplacement effectif. Attention aux frontières de mots, à la casse, aux accents, aux variations orthographiques. Une Marie Dupont peut apparaître plus loin sous Mme Dupont, M. Dupont, Mme D. — le NER doit relier ces formes.

Étape 6 — Validation. Revue humaine sur un échantillon (5 à 10 % au démarrage, baissable à 1-2 % après stabilisation). On mesure :

Taux d’entités manquées (rappel)
Taux de fausses détections (précision)
Présence de données indirectement identifiantes résiduelles

Étape 7 — Audit et logs. Conservation séparée :

Document original chiffré (en cas de litige, demande RGPD article 15, audit)
Document pseudonymisé (pour usage en aval)
Table de correspondance (coffre, accès très restreint)
Logs d’accès (qui a vu quoi, quand)

Schéma de production simplifié

[Source]              [Traitement]              [Destinations]
   │                       │                         │
   ▼                       ▼                         ▼
PDF / mail ──► OCR ──► NER ──► Politique ──► Pseudo. ──► LLM SaaS / fine-tune / partage
                          │           │
                          └─► Audit ──┘
                                │
                                ▼
                          Coffre clé (accès strict)
                          Original chiffré (HDS si santé)

Le piège de la re-identification

C’est le test ultime. Une pseudonymisation qui ne résiste pas aux attaques par croisement n’est pas une pseudonymisation utilisable.

Trois attaques classiques

Attaque 1 — Croisement avec une source ouverte. L’attaquant dispose d’un fichier électoral, d’une base SIRENE, d’un export LinkedIn. Il croise les attributs restants dans le document pseudonymisé (âge, ville, métier, employeur) avec ces sources. Si une combinaison est unique, la re-identification réussit.

Attaque 2 — Inférence par contexte. L’attaquant connaît le domaine. Il sait qu’un seul directeur commercial a quitté ACME en mars 2025. Il déduit l’identité.

Attaque 3 — Membership inference (sur LLM fine-tuné). Un attaquant interroge un modèle fine-tuné sur un corpus pseudonymisé pour deviner si tel ou tel individu était dans le corpus. Si le modèle a sur-appris, il révèle des informations.

Trois défenses

Défense 1 — k-anonymity (pour bases tabulaires). Chaque combinaison d’attributs apparaît au moins k fois dans le dataset. Si k = 5, chaque profil est indistinguable d’au moins 4 autres. Sur du texte libre, transposition partielle via généralisation : « 47 ans » → « 40-50 ans », « ingénieure agronome à Guérande » → « cadre dans l’ouest de la France ».

Défense 2 — l-diversity et t-closeness. Extensions de k-anonymity qui contraignent aussi la diversité des valeurs sensibles dans chaque groupe. Utile quand les données sensibles (santé, opinion) sont au cœur du dataset.

Défense 3 — Tests de re-identification. Plus pragmatique : 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.

Aucune des trois ne protège totalement. La règle pratique : tester explicitement la robustesse avant la mise en production, et documenter les tests.

Conformité RGPD : ce qui est vraiment attendu

L’anonymisation/pseudonymisation par IA est elle-même un traitement automatisé de données personnelles. Donc soumis au RGPD. Voici ce qu’on inscrit, et ce qu’on doit pouvoir produire en cas de contrôle.

Au registre des traitements

Une fiche dédiée : « pseudonymisation automatisée par NER pour [finalité précise] ». On y consigne :

Finalité (ex : préparer un corpus pour fine-tuning, partager avec un partenaire X, analyser des mails internes)
Catégories de données traitées (texte libre, types d’entités détectées)
Personnes concernées (clients, salariés, patients selon le cas)
Durée de conservation (de l’original, de la version pseudonymisée, de la table de correspondance — chacune justifiée)
Sous-traitants (fournisseur du LLM, hébergeur)
Mesures techniques et organisationnelles

Base légale

Selon le contexte :

Intérêt légitime : cas le plus fréquent pour des traitements internes, à condition de documenter le test de mise en balance (intérêt poursuivi vs droits des personnes).
Exécution d’un contrat : si le traitement découle directement de l’exécution d’un contrat avec la personne.
Obligation légale : rare, mais possible (réponse à une demande RGPD article 15, par exemple).
Consentement : exceptionnellement, et à éviter si une autre base est mobilisable — le consentement peut être retiré.

AIPD (analyse d’impact)

Recommandée dans la majorité des cas, obligatoire dans plusieurs scénarios listés par la CNIL :

Volumes élevés
Données sensibles (santé, opinions politiques, biométriques, judiciaires)
Traitement à grande échelle
Surveillance systématique d’employés
Croisement de sources

L’AIPD documente le risque résiduel après pseudonymisation, justifie les choix techniques, et formalise le contrôle d’accès à la clé. Elle est tenue à disposition de la CNIL en cas de contrôle. Voir notre guide AIPD pour projet IA.

DPA avec le fournisseur LLM

Si vous utilisez un LLM SaaS, le contrat de sous-traitance (DPA) doit prévoir :

Localisation du traitement (idéalement UE — Mistral, Scaleway)
Interdiction d’utiliser les données pour entraîner le modèle
Durée de conservation des prompts et complétions
Sous-traitants ultérieurs (hébergeur, sauvegardes)
Modalités de notification d’incident

Avec un fournisseur souverain européen, le DPA est nettement plus simple. Avec un fournisseur américain, il devient un dossier technique à part entière (clauses contractuelles types, transfer impact assessment, parfois inutilisable selon la nature des données).

Localisation du traitement

Pour des données sensibles (santé, secret professionnel, données salariales), la localisation est un sujet à part entière. Trois niveaux :

Cloud souverain (Scaleway, OVHcloud, Outscale) — données restent en UE, sous droit européen, sans risque de saisie au titre du Cloud Act.
On-premise — l’IA tourne sur les serveurs de l’organisation, zéro sortie de données. Voir notre guide LLM local en entreprise.
Cloud étranger avec encadrement contractuel — possible mais avec une charge documentaire conséquente, et un risque résiduel non nul.

Pour la majorité des cas sensibles en France, on retient soit un fournisseur souverain (Mistral La Plateforme), soit du on-premise. C’est l’approche que retient DPLIANCE pour ses clients, dans le cadre de solutions IA sur mesure.

Ce qu’on refuse de promettre

Trois antiPatterns qu’on voit régulièrement dans les projets, et qu’on évite chez DPLIANCE.

« 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 NER détecte tout, on n’a 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 anonymisation et pseudonymisation ?

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 IA » produisent en réalité de la pseudonymisation. Les obligations RGPD continuent de s’appliquer (registre, base légale, AIPD si nécessaire), même si le risque a baissé.

Le NER (reconnaissance d’entités nommées) suffit-il à anonymiser un texte ?

Non, presque jamais. Le NER détecte les entités nommées explicites : noms, prénoms, numéros de téléphone, 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), tournures contextuelles. Une anonymisation rigoureuse exige NER + analyse contextuelle + revue humaine sur les cas critiques + tests de robustesse à la re-identification.

Quelle précision attendre d’un NER IA en 2026 ?

Sur du français standard, un LLM moderne (Mistral Large, GPT-4o, Claude) détecte 95 à 98 % des entités nommées explicites avec un prompt bien construit. Les modèles dédiés (spaCy fr_core_news_lg, GLiNER multilingue, modèles fine-tunés) atteignent 92 à 99 % de F1 selon le domaine. La performance chute fortement sur : noms étrangers ou rares, langues mixtes, abréviations métier, références implicites au sein du texte. Aucun modèle n’atteint 100 % — c’est pour cela que la revue humaine sur un échantillon reste indispensable au démarrage.

Faut-il un LLM générique ou un modèle NER dédié ?

Pour la majorité des cas en 2026, un LLM générique bien prompté (Mistral, GPT-4o, Claude) suffit avec une précision supérieure à 95 %. Le modèle NER dédié (spaCy, GLiNER, modèle fine-tuné) devient pertinent quand le volume est très élevé (millions de documents par mois), quand la latence est critique (temps réel), ou quand le contexte est ultra-spécialisé (terminologie médicale ou juridique non standard). La règle simple : démarrer en LLM générique pour le prototype, basculer vers du dédié si le coût d’inférence ou la performance le justifie.

Une donnée pseudonymisée par NER 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.

Quels cas d’usage tiennent vraiment en entreprise ?

Six cas d’usage 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 (mails, comptes rendus) pour des finalités managériales sans franchir la ligne de la surveillance individuelle illégale ; (5) conformité sectorielle (santé HDS, juridique secret pro) ; (6) préparation de documents avant un appel à un LLM SaaS pour réduire l’exposition.

Avec quels outils peut-on faire de l’anonymisation IA souveraine en 2026 ?

LLM génériques souverains : Mistral Large via La Plateforme (France), Mistral on-premise via vLLM, autres fournisseurs européens. 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 excellent 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 ou Llama 3 self-hosted + spaCy en interne, zéro sortie de données.

Faut-il une AIPD pour un projet d’anonymisation 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 : l’anonymisation IA est elle-même un traitement automatisé de données personnelles, donc soumise au RGPD. L’AIPD documente le risque résiduel après pseudonymisation, 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) 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 d’anonymisation par IA dans votre organisation — choix d’outil, méthodologie, 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.