Anonymisation RGPD par IA : architecture on-premise

"On a anonymisé les données." Cette phrase, prononcée avec assurance par des équipes techniques parfaitement compétentes, cache dans 60 % des cas une réalité différente : elles ont pseudonymisé. Les données restent des données personnelles au sens du RGPD. Le traitement est toujours encadré. Et si ces données partent ensuite vers un prestataire analytics ou un LLM cloud pour "traitement", le problème est entier.

La confusion entre anonymisation et pseudonymisation n'est pas un détail de juriste. C'est le point de départ de la plupart des non-conformités relevées par la CNIL. Et c'est le premier point que nous adressons systématiquement dans nos missions d'audit IA chez Tensoria.

Cet article s'adresse aux équipes techniques et aux DPO qui souhaitent construire un pipeline d'anonymisation réellement conforme. Il couvre la distinction juridique (article 4 et considérant 26 du RGPD, tests CEPD), l'architecture on-premise recommandée avec Microsoft Presidio et spaCy fr, la configuration des entités françaises spécifiques (NIR, SIRET, IBAN, plaque d'immatriculation), et le paradoxe des LLM cloud pour ce use case. Tout vient du terrain, pas d'un document de conformité théorique.

Anonymisation vs pseudonymisation : la distinction juridique qui change tout

C'est le point de départ obligatoire, et il est souvent négligé. La distinction entre anonymisation et pseudonymisation n'est pas sémantique. Elle détermine si vos données restent soumises au RGPD ou en sortent. Et la frontière est beaucoup plus haute qu'on ne le croit généralement.

La pseudonymisation : toujours dans le champ du RGPD

L'article 4(5) du RGPD définit la pseudonymisation comme le traitement de données personnelles de façon que celles-ci ne puissent plus être attribuées à une personne précise sans avoir recours à des informations supplémentaires. Ces informations supplémentaires (la clé de correspondance, le vault) doivent être conservées séparément et sécurisées.

La conséquence juridique est claire : les données pseudonymisées restent des données à caractère personnel. Tous les principes du RGPD s'appliquent : base légale de traitement, droits des personnes, obligations de sécurité, registre des traitements, durées de conservation. La pseudonymisation est une mesure de sécurité reconnue et encouragée par le RGPD (article 25 sur la protection des données dès la conception), mais elle ne fait pas sortir les données du règlement.

En pratique, remplacer "Jean Dupont" par "PERS_4821" ou un hash SHA-256, c'est de la pseudonymisation. La réidentification reste possible si l'on accède à la table de correspondance.

L'anonymisation : la sortie du champ du RGPD

L'anonymisation, au sens du RGPD, est un processus irréversible. Le considérant 26 précise que les principes du règlement ne s'appliquent pas aux informations ne concernant pas une personne physique identifiée ou identifiable, ni aux données rendues anonymes de telle manière que la personne concernée n'est plus identifiable.

Le mot-clé est "n'est plus identifiable", apprécié en tenant compte de l'ensemble des moyens raisonnablement susceptibles d'être utilisés : coût, temps, technologies disponibles, sources d'information accessibles. Ce test n'est pas statique : ce qui est "raisonnablement impossible" à réidentifier aujourd'hui peut ne plus l'être dans cinq ans avec de nouvelles techniques.

Pourquoi la confusion est systémique

La confusion entre les deux notions vient de la terminologie des outils. La plupart des bibliothèques d'anonymisation (dont Presidio lui-même) utilisent indifféremment les termes "anonymisation" et "pseudonymisation" dans leur documentation. Presidio propose des opérateurs de masquage, de remplacement et de hachage — tous réversibles en théorie, donc relevant techniquement de la pseudonymisation selon le RGPD.

Ce n'est pas un reproche à Presidio : c'est un outil technique dont la conformité juridique dépend de l'usage qu'on en fait. Une opération de remplacement par entité synthétique non réversible (PERSONNE_001 sans vault) tend vers l'anonymisation. Un hachage avec clé secrète stockée est de la pseudonymisation pure. La qualification juridique appartient au DPO, pas au développeur.

Cadre RGPD applicable : article 4, considérant 26 et tests CEPD

Avant de poser la première ligne de code, l'équipe doit maîtriser le cadre juridique. Ces trois références balisent ce que signifie "anonymiser correctement" au sens de la réglementation européenne.

Article 4 du RGPD : les définitions de référence

L'article 4 du RGPD contient les définitions légales. Deux sont centrales pour notre sujet. Le texte intégral est consultable sur le site de la CNIL.

• Article 4(1) : "données à caractère personnel" — toute information se rapportant à une personne physique identifiée ou identifiable. La liste des identifiants est non exhaustive : nom, numéro d'identification, données de localisation, identifiant en ligne, éléments spécifiques à l'identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale.
• Article 4(5) : définition de la pseudonymisation. La séparation des informations supplémentaires (la clé) est une condition légale, pas une recommandation.

Considérant 26 : le test de réidentifiabilité

Le considérant 26 est le texte de référence pour évaluer si une donnée est réellement anonymisée. Il précise que pour déterminer si une personne est identifiable, il convient de prendre en considération "l'ensemble des moyens raisonnablement susceptibles d'être utilisés par le responsable du traitement ou par toute autre personne pour identifier la personne physique directement ou indirectement".

Ce test est contextuel et dynamique. Il ne suffit pas que vous, en tant que responsable du traitement, ne puissiez pas réidentifier. Il faut que personne ne puisse le faire avec des moyens raisonnables, y compris un tiers malveillant disposant de sources publiques (LinkedIn, données ouvertes, recoupements).

Les trois tests d'anonymisation du CEPD

Le Comité Européen de la Protection des Données (CEPD), dans son avis 05/2014 sur les techniques d'anonymisation, pose trois critères que les données doivent satisfaire simultanément pour être considérées comme anonymisées :

Ces trois tests s'appliquent principalement aux datasets structurés. Pour les textes non structurés (contrats, courriers, comptes rendus), la démarche est différente : on supprime ou remplace les entités identifiantes, et on évalue le risque de réidentification contextuelle.

Architecture on-premise recommandée

L'architecture d'un pipeline d'anonymisation on-premise suit une logique de pipeline séquentiel. Chaque étape a un rôle précis et des métriques à surveiller.

Étape 1 : extraction et pré-traitement

Les documents entrent rarement en texte brut. Les formats courants en entreprise sont les PDF (natifs ou scannés), DOCX, emails, champs de bases de données, transcriptions audio. Chaque format nécessite un extracteur dédié :

• PDF natifs : pdfplumber ou PyMuPDF, avec gestion des tableaux et des en-têtes.
• PDF scannés : OCR obligatoire (Tesseract avec modèle fr ou un service OCR on-premise). La qualité de l'OCR conditionne la qualité de la détection d'entités.
• DOCX / emails : python-docx, eml-parser. Attention aux métadonnées qui contiennent parfois des données personnelles (auteur du document, historique des révisions).
• Bases de données : traitement colonne par colonne, avec identification préalable des colonnes texte libre vs structuré.

Étape 2 : détection des entités personnelles

C'est le cœur du pipeline. Trois couches de détection se combinent :

• NER via spaCy fr_core_news_lg : détection des entités nommées françaises (personnes, organisations, lieux, dates). C'est la couche sémantique de base.
• Recognizers Presidio : 40+ types d'entités structurées (email, téléphone, adresse IP, numéro de carte bancaire, IBAN générique, coordonnées GPS).
• Recognizers custom regex : entités françaises spécifiques non couvertes nativement (voir section suivante).

Étape 3 : stratégie de substitution

Selon l'usage final, on choisit une stratégie différente :

• Anonymisation stricte : remplacement par entité synthétique de même type et sans vault (PERSONNE_001, ADRESSE_001). Irréversible. Applicable pour l'archivage longue durée ou le partage externe.
• Pseudonymisation avec vault : remplacement par alias chiffré, correspondance stockée dans un vault isolé (Vault by HashiCorp ou équivalent). Réversible pour les usages analytiques internes nécessitant la réidentification.
• Masquage : [REDACT] ou ████. Pour les documents archivés qui doivent rester lisibles par des humains sans que les données personnelles soient accessibles.

Étape 4 : post-traitement et audit trail

Deux contraintes post-traitement sont critiques pour la conformité :

• Cohérence inter-document : "Jean Dupont" doit recevoir le même alias dans tous les documents du corpus. Sans registre d'alias persistant, les analyses croisées sur données pseudonymisées deviennent impossibles.
• Audit trail : journalisation horodatée de chaque opération d'anonymisation (document traité, entités détectées par type, méthode appliquée, opérateur, hash du document original). C'est la preuve de conformité exigible en cas d'audit CNIL.

Stack Presidio + spaCy fr : configuration et entités françaises

Microsoft Presidio est le framework open source (licence MIT) qui s'impose pour ce type de projet. Son architecture en deux composants — Analyzer (détection) et Anonymizer (transformation) — est claire et auditée. Il est déployable entièrement on-premise sans aucun appel réseau externe.

Configuration du NER français avec spaCy

Presidio utilise spaCy par défaut avec le modèle anglais. Pour le français, la configuration nécessite quelques ajustements :

from presidio_analyzer import AnalyzerEngine
from presidio_analyzer.nlp_engine import NlpEngineProvider

# Configuration du moteur NLP avec spaCy fr
configuration = {
    "nlp_engine_name": "spacy",
    "models": [
        {"lang_code": "fr", "model_name": "fr_core_news_lg"}
    ],
}

provider = NlpEngineProvider(nlp_configuration=configuration)
nlp_engine = provider.create_engine()

analyzer = AnalyzerEngine(
    nlp_engine=nlp_engine,
    supported_languages=["fr"]
)

Le modèle fr_core_news_lg (large) est recommandé sur fr_core_news_sm pour un meilleur rappel sur les entités nommées françaises, au prix d'une empreinte mémoire supérieure (~570 Mo vs ~16 Mo). Sur un serveur dédié, ce surcoût est négligeable face au gain de couverture. Pour un panorama des librairies NLP françaises au sens large (spaCy, CamemBERT, Flair, Stanza, Sentence-Transformers), notre comparatif des librairies NLP pour le français couvre les forces de chacune selon le cas d'usage (NER, classification, embeddings).

Recognizers custom pour les entités françaises

Les entités françaises spécifiques ne sont pas couvertes nativement par Presidio. Il faut créer des recognizers custom basés sur des expressions régulières et des sommes de contrôle (checksum) :

from presidio_analyzer import PatternRecognizer, Pattern

# Exemple : recognizer NIR (numéro de sécurité sociale français)
nir_pattern = Pattern(
    name="NIR_pattern",
    regex=r'\b[12][0-9]{2}(0[1-9]|1[0-2]|[2-9][0-9]|[6-9][0-9])'
          r'(0[1-9]|[1-8][0-9]|9[0-5]|2[AB])[0-9]{3}[0-9]{3}[0-9]{2}\b',
    score=0.85
)

nir_recognizer = PatternRecognizer(
    supported_entity="FR_NIR",
    patterns=[nir_pattern],
    context=["sécurité sociale", "sécu", "numéro SS",
             "assuré", "carte vitale", "NIR"]
)

analyzer.registry.add_recognizer(nir_recognizer)

L'ajout de mots de contexte (context) améliore la précision : Presidio augmente le score de confiance quand l'entité détectée est précédée ou suivie de termes associés. Cela réduit les faux positifs sur des séquences numériques fortuites.

Exemple de sortie du pipeline

Entrée :

M. Jean Dupont (né le 12/03/1978, domicilié 14 rue des Lilas,
31000 Toulouse, NIR : 1 78 03 31 116 042 68) a subi un sinistre
le 15 mars 2026. Son IBAN : FR76 3000 6000 0112 3456 7890 189.

Sortie anonymisée (remplacement par entité synthétique) :

M. PERSONNE_001 (né le [DATE_001], domicilié [ADRESSE_001],
31000 [VILLE_001], NIR : [FR_NIR_001]) a subi un sinistre
le [DATE_002]. Son IBAN : [IBAN_001].

Rapport d'anonymisation joint :

{
  "document_id": "DOC-2026-00341",
  "date_traitement": "2026-05-18T10:14:00Z",
  "entites_detectees": {
    "PERSON": 1, "DATE_TIME": 2, "LOCATION": 2,
    "FR_NIR": 1, "IBAN_CODE": 1
  },
  "methode": "anonymisation_substitution_synthetique",
  "couverture_estimee": 0.97,
  "hash_document_original": "sha256:4a8f2c..."
}

Presidio, LLM ou CamemBERT NER : quel modèle choisir ?

Il n'existe pas une seule bonne réponse. Le choix dépend du volume, de la nature des entités à détecter et des contraintes de conformité. Voici la grille de décision que nous utilisons en mission.

Notre recommandation de départ

Pour 80 à 90 % des projets d'entreprise, Presidio + spaCy fr + recognizers custom est la bonne réponse. Le framework couvre les entités structurées avec un rappel élevé, tourne sur CPU standard sans coût GPU, et reste intégralement on-premise.

On ajoute un LLM on-premise (Mistral 7B ou 22B) uniquement pour les entités contextuelles qui échappent au NER classique : une personne mentionnée sans patronyme explicite ("le directeur de la filiale de Toulouse"), un compte bancaire décrit textuellement plutôt qu'en format IBAN, ou des données indirectement identifiantes complexes. Le LLM ne traite que les passages à faible score de confiance du premier pipeline, ce qui limite les ressources GPU nécessaires.

Le fine-tuning CamemBERT sur un corpus annoté métier est pertinent quand vous avez un domaine très spécifique (médical, juridique, RH) avec des entités que spaCy ne connaît pas. Il nécessite un dataset annoté de 500 à 2 000 exemples, ce qui représente un investissement humain significatif. On l'envisage au stade MVP, pas en POC.

Évaluation du pipeline : précision, rappel et faux négatifs

L'évaluation d'un pipeline d'anonymisation suit une logique inverse à celle des systèmes de classification classiques. Ici, le rappel prime absolument sur la précision. Un faux négatif (entité personnelle non détectée) est une fuite de données. Un faux positif (entité non personnelle supprimée) dégrade la lisibilité du document mais ne constitue pas une violation RGPD.

Métriques cibles en production

Comment construire le jeu de test

Le jeu de test doit être représentatif de vos vrais documents, pas de datasets génériques. La démarche recommandée :

• Sélectionner un échantillon stratifié de 200 à 500 documents couvrant tous les types de documents traités (contrats, courriers, emails, formulaires, comptes rendus).
• Annoter manuellement les entités personnelles dans cet échantillon (au minimum deux annotateurs pour mesurer l'accord inter-annotateur).
• Exécuter le pipeline sur cet échantillon et calculer les métriques par type d'entité et par type de document.
• Identifier les patterns de faux négatifs récurrents et ajuster les recognizers en conséquence.

Cette phase d'évaluation sur données réelles est non négociable. Les benchmarks génériques (CoNLL-2003, WikiNER) ne reflètent pas les spécificités de vos documents : langage interne, abréviations métier, formats propres à votre secteur.

Réversibilité et vault de pseudonymisation

Quand l'usage final nécessite de pouvoir réidentifier les individus (analyses internes, réponse à une demande de droit d'accès RGPD, correction d'une erreur), on opte pour la pseudonymisation réversible plutôt que l'anonymisation stricte. Le choix dépend de la finalité du traitement, à définir avec le DPO avant de coder quoi que ce soit.

Architecture du vault

Le vault est un registre chiffré qui fait correspondre les entités originales à leurs alias pseudonymisés. Il doit être :

• Séparé physiquement des documents pseudonymisés (condition légale de l'article 4(5) RGPD).
• Chiffré au repos (AES-256 minimum) et en transit (TLS 1.3).
• Accès restreint et audité : journalisation de chaque accès au vault avec identité de l'opérateur, horodatage et motif.
• Durée de vie limitée : le vault doit être supprimé ou rendu inaccessible à la fin de la durée de conservation des données.

HashiCorp Vault (open source, déployable on-premise) est la solution de référence pour ce besoin. Il propose un moteur de secrets dédié, des politiques d'accès granulaires et un audit log natif.

Cohérence inter-document avec un vault

Le vault résout également le problème de cohérence inter-document : avant d'attribuer un alias à une entité, le pipeline vérifie si cette entité est déjà dans le vault. Si oui, il réutilise l'alias existant. Cela garantit que "Jean Dupont" est toujours PERSONNE_001, quel que soit le document traité.

La normalisation des entités avant la vérification dans le vault est critique : "DUPONT Jean", "Jean Dupont" et "J. Dupont" doivent être reconnus comme la même entité. C'est un sous-problème de résolution d'entités (entity resolution) qui nécessite une couche de normalisation dédiée.

Le paradoxe cloud LLM et les solutions souveraines

C'est le point le plus contre-intuitif du sujet, et celui qui fait le plus souvent débat dans les équipes.

Le paradoxe formulé clairement

Pour anonymiser des données personnelles via un LLM cloud (ChatGPT, Claude Anthropic, Gemini), vous devez d'abord envoyer ces données personnelles aux serveurs du fournisseur. Ce transfert est lui-même un traitement de données à caractère personnel soumis au RGPD. Vous avez besoin :

• D'une base légale pour ce traitement (article 6 RGPD).
• D'un contrat de sous-traitance (DPA — Data Processing Agreement) avec le fournisseur LLM.
• D'une évaluation du transfert hors UE si les serveurs sont aux États-Unis (DTIA — Data Transfer Impact Assessment).
• De garanties que le fournisseur n'utilisera pas vos données pour entraîner ses modèles.

En pratique, envoyer des dossiers médicaux, des données RH ou des dossiers clients à OpenAI pour les "anonymiser" est rarement une démarche conforme sans un cadrage juridique solide en amont.

Les solutions acceptables selon le niveau de sensibilité

Conformité projet : AIPD, registre et contrat sous-traitant

La stack technique ne suffit pas. Un pipeline d'anonymisation conforme au RGPD nécessite trois livrables documentaires produits en parallèle du développement.

L'Analyse d'Impact relative à la Protection des Données (AIPD)

Un pipeline d'anonymisation par IA traite généralement des données personnelles en volume, potentiellement des catégories spéciales (santé, données judiciaires, origine ethnique), via un traitement automatisé à grande échelle. Ces critères réunis déclenchent dans la plupart des cas l'obligation d'AIPD selon les lignes directrices de la CNIL.

L'AIPD documente :

• La finalité précise du traitement d'anonymisation (pourquoi, pour qui, avec quelle durée de conservation des données avant anonymisation).
• Les catégories de données traitées et leur niveau de sensibilité.
• Les mesures techniques et organisationnelles mises en place (pipeline on-premise, accès restreint au vault, audit trail).
• Les risques résiduels identifiés et les mesures d'atténuation.
• La décision motivée du responsable du traitement.

Le registre des traitements

L'opération d'anonymisation elle-même est un traitement de données personnelles à inscrire au registre des traitements (article 30 RGPD). Elle doit figurer séparément du traitement initial qui a produit les données. Les champs à renseigner : finalité, catégories de données, catégories de personnes concernées, destinataires, durée de conservation, mesures de sécurité, sous-traitants.

Le contrat de sous-traitance

Si un prestataire externe (comme Tensoria) intervient sur le développement ou l'exploitation du pipeline, un contrat de sous-traitance conforme à l'article 28 du RGPD est obligatoire. Ce contrat doit préciser : les instructions documentées du responsable du traitement, les obligations de sécurité, l'interdiction de sous-sous-traitance non autorisée, les modalités d'audit, et la suppression ou restitution des données en fin de contrat. Pour aller plus loin sur ce sujet, notre article sur la confidentialité des données confiées à un prestataire IA détaille les clauses contractuelles et les précautions techniques à mettre en place.

Coûts, délais et pièges fréquents

Fourchettes de coût

Calendrier type

• Semaines 1-2 : audit RGPD avec le DPO (périmètre des données, finalité, registre des traitements), inventaire des types d'entités à couvrir.
• Semaines 3-5 : déploiement Presidio + spaCy fr, configuration des recognizers custom, évaluation sur échantillon annoté.
• Semaines 6-9 : intégration dans les flux documentaires, vault, audit trail, tests de non-réidentifiabilité.
• Semaines 10-12 : déploiement progressif, validation DPO, documentation du système.

Ce qui rallonge systématiquement : la validation juridique par le DPO ou un avocat spécialisé RGPD (indispensable mais souvent sous-estimée), la variété des formats de documents sources (chaque nouveau format nécessite un extracteur dédié), et les exigences de non-réidentifiabilité formelle (tests avec données externes, k-anonymisation pour les datasets structurés).

Les cinq pièges les plus fréquents

1. Confondre anonymisation et pseudonymisation. Remplacer un nom par un identifiant réversible, c'est de la pseudonymisation. Les données restent dans le champ du RGPD. Ce point est régulièrement soulevé lors des audits CNIL.

2. Ne pas tester la non-réidentifiabilité. Anonymiser les noms et emails sans vérifier si la combinaison (code postal + âge + profession) permet encore une ré-identification. Pour les datasets structurés, les techniques de k-anonymisation sont indispensables.

3. Les entités indirectement identifiantes manquées. Presidio détecte les noms, emails, téléphones. Il ne détecte pas "le directeur de la PME de Toulouse spécialisée en..." — qui peut être identifiant. Un LLM on-premise est nécessaire pour ces entités contextuelles rares.

4. Pas d'audit trail. Sans journalisation précise de qui a anonymisé quoi, quand, avec quelle méthode, la conformité RGPD est difficile à démontrer en cas d'audit CNIL. L'audit trail doit être généré automatiquement par le pipeline.

5. Incohérence inter-document. Si "Jean Dupont" devient PERSONNE_001 dans un document et PERSONNE_017 dans un autre, les analyses croisées sur données pseudonymisées produisent des résultats erronés et la réidentification devient plus difficile à garantir.

Questions fréquentes