Pourquoi votre outil de détection de PII n'est...

L'écart caché de conformité au GDPR

Le GDPR n'a pas de préférence linguistique. L'article 4(1) définit "les données personnelles" sans référence à la langue dans laquelle elles apparaissent. Un Steuer-ID allemand est aussi protégé qu'un numéro de sécurité sociale américain. Un NIR français est aussi réglementé qu'un numéro d'assurance nationale britannique.

Mais la plupart des outils de détection de PII ont été conçus pour l'anglais.

Des recherches publiées à l'ACL 2024 ont révélé que les approches hybrides de NLP atteignent des scores F1 de 0,60-0,83 pour les localités européennes — mais les outils uniquement en anglais appliqués à des textes non anglais obtiennent des scores proches de zéro pour les identifiants nationaux structurés. L'implication pratique : un outil d'anonymisation déployé dans une organisation multinationale peut détecter 95 % des PII anglaises tout en manquant 40-60 % des PII allemandes, françaises, polonaises ou néerlandaises dans le même ensemble de données.

C'est un écart systématique de conformité au GDPR qui affecte pratiquement toutes les entreprises multinationales utilisant des outils d'anonymisation centrés sur l'anglais.

Pourquoi les PII sont spécifiques à la langue

La détection de PII a deux composants : détection basée sur des modèles (identifiants structurés comme les numéros de taxe, formats de téléphone) et détection basée sur NER (entités contextuelles comme les noms de personnes, noms d'organisations, adresses).

Les deux composants sont profondément spécifiques à la langue.

Les identifiants structurés diffèrent radicalement selon le pays

Un modèle regex uniquement en anglais pour les SSN (format : NNN-NN-NNNN) ne correspondra à aucun de ces identifiants. Chacun nécessite une logique regex spécifique au pays plus une validation de contrôle de somme.

La reconnaissance des entités nommées nécessite des modèles natifs à la langue

Les noms de personnes en allemand suivent des modèles différents des noms anglais. "Hans-Dieter Müller" et "Anna-Lena Schreiber-Koch" sont reconnaissables comme des noms allemands par le contexte — mais un modèle formé principalement sur du texte anglais les manquera souvent ou les classera mal.

Plus problématique : les faux positifs dans une langue peuvent devenir des faux négatifs dans une autre. Le suivi des problèmes GitHub de Microsoft Presidio documente des faux positifs systématiques pour des mots allemands étant mal classés comme PII anglaises. Le même mot "Null" (allemand pour "zéro") déclenche des faux positifs de détection de noms dans des modèles formés en anglais. Cela gonfle les taux de faux positifs à 3 erreurs par 1 entité réelle dans des environnements de production multilingues (Alvaro et al., 2024).

L'exposition réglementaire

Les autorités de protection des données de l'UE sont de plus en plus conscientes de cet écart. Plusieurs DPAs nationaux ont publié des orientations ou des actions d'exécution qui impliquent le traitement multilingue :

BfDI allemand : A clarifié que l'article 5(1)(f) du GDPR (intégrité et confidentialité) s'applique aux données sous toutes les formes de traitement, y compris les données non anglaises traitées par des outils tiers.

CNIL française : Le rapport annuel 2024 de la CNIL a noté des préoccupations croissantes concernant les outils d'IA qui traitent des données en langue française sans capacités de détection de PII en langue française.

DPAs européens en général : En vertu de l'article 25 du GDPR (Privacy by Design), les mesures techniques doivent être appropriées pour les données réellement traitées — ce qui inclut les PII non anglaises dans les déploiements multinationaux.

Le risque pratique : une organisation peut démontrer une efficacité de détection de 95 % des PII sur du contenu anglais lors d'un audit GDPR, mais si elle traite également du contenu allemand, français et polonais avec le même outil, l'audit peut révéler des lacunes systémiques pour ces langues.

L'approche en trois niveaux pour la détection multilingue de PII

Les recherches académiques et les déploiements de production ont convergé vers une architecture hybride en trois niveaux comme l'approche la plus efficace pour la détection multilingue de PII :

Niveau 1 : Modèles spaCy natifs à la langue (langues à ressources élevées)

spaCy fournit des composants de pipeline formés pour 25 langues, y compris l'allemand, le français, l'espagnol, le portugais, l'italien, le néerlandais, le russe, le chinois, le japonais, le coréen, le polonais et d'autres. Ces modèles sont formés sur des corpus dans la langue native et comprennent la morphologie, la syntaxe et les modèles d'entités de chaque langue.

Pour l'allemand : le modèle spaCy de_core_news_lg comprend les noms composés, l'inflexion des cas et les modèles de noms allemands. Pour le français : fr_core_news_lg gère les modèles d'entités françaises, y compris les titres, les noms de lieux et les formats d'organisation.

Les modèles natifs à la langue atteignent une précision et un rappel significativement plus élevés pour la détection de noms que les modèles multilingues appliqués à des langues spécifiques à ressources élevées.

Niveau 2 : Stanza (langues supplémentaires)

La bibliothèque Stanza de Stanford fournit NER pour des langues supplémentaires non couvertes par l'offre commerciale de spaCy, y compris le croate, le slovène, l'ukrainien et d'autres. Cela étend la couverture aux langues avec des populations de locuteurs de l'UE plus petites mais encore significatives.

Niveau 3 : XLM-RoBERTa (couverture cross-linguale)

Pour les langues pour lesquelles ni spaCy ni Stanza ne fournissent de modèles NER formés, XLM-RoBERTa fournit un transfert cross-lingual. Formé sur des données Common Crawl à travers 100 langues, XLM-RoBERTa atteint 91,4 % de F1 cross-lingual pour la détection de PII (HuggingFace 2024), permettant une détection raisonnable pour les langues à ressources plus faibles.

Le modèle cross-lingual gère particulièrement bien le code-switching (texte en langues mélangées) — une propriété qui devient critique pour les organisations internationales où un seul document peut contenir du texte dans plusieurs langues.

Types d'entités spécifiques à la langue

Au-delà du modèle de détection, la conformité au GDPR nécessite une couverture des types d'entités pour les identifiants spécifiques au pays. Un outil multilingue a besoin :

Identifiants nationaux de l'UE :

• DE : Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
• FR : NIR, SIREN, SIRET, numéro de téléphone
• PL : PESEL, NIP, REGON
• NL : BSN, BurgerServiceNummer
• SE : Personnummer, Samordningsnummer
• ES : DNI, NIE, NIF, CIF
• IT : Codice Fiscale, Partita IVA

Formats de numéros de téléphone : Chaque pays de l'UE a des structures de préfixe mobile uniques, des formats de code régional et des conventions de composition locales. +49 (Allemagne), +33 (France), +48 (Pologne) nécessitent tous une validation spécifique au pays.

Formats d'adresse : Les formats de code postal diffèrent radicalement — PLZ allemand (5 chiffres), code postal français (5 chiffres commençant par 01-99), code postal britannique (alphanumérique, plusieurs formats), code postal espagnol (5 chiffres 01000-52999).

Le cas d'utilisation : Documents multilingues d'une entreprise pharmaceutique suisse

Une entreprise pharmaceutique suisse traite des contrats de travail contenant du texte en allemand, en français et en anglais dans le même document (la Suisse a quatre langues officielles). Leur outil actuel est configuré pour l'allemand et manque toutes les PII de la section française.

Un contrat de travail pour un employé basé à Genève fait référence à son numéro AVS français (13 chiffres), à son IBAN de compte bancaire suisse, à son canton de résidence et à son nom au format français. L'outil configuré pour l'allemand manque le nom au format français, ne parvient pas à détecter le modèle de numéro AVS français (différent du format AHV-Nummer allemand) et ne détecte que partiellement l'IBAN.

L'approche en trois niveaux traite le document dans son ensemble, détectant automatiquement la langue pour chaque segment de texte, appliquant des modèles NER appropriés à la langue et utilisant des validateurs regex spécifiques au pays pour chaque type d'identifiant national — peu importe dans quelle section de langue il apparaît.

Gestion des documents en langues mélangées

Le problème le plus difficile de PII multilingue est le mélange de langues intra-document : un document qui contient des paragraphes dans différentes langues, des phrases en code-switching, ou du texte cité dans une langue différente du contexte environnant.

Exemples :

• Un contrat en anglais d'une entreprise allemande avec des données d'employés allemands (noms, numéros de taxe)
• Un formulaire de consentement GDPR français qui inclut un extrait de politique de confidentialité en anglais
• Un journal de chat de service client multilingue où l'agent répond en anglais mais le client écrit en arabe

XLM-RoBERTa gère cela de manière native : sa formation cross-linguale signifie qu'il ne nécessite pas de déclarations de langue explicites et traite le texte en langues mélangées sans nécessiter de segmentation.

Pour les déploiements de production, la combinaison de la détection automatique de la langue (appliquée au niveau de la phrase) et de l'inférence cross-linguale de XLM-RoBERTa fournit la gestion la plus robuste des documents en langues mélangées.

Conseils pratiques pour le déploiement

Auditez la couverture linguistique de votre outil actuel : Demandez à votre fournisseur d'anonymisation actuel de fournir des scores F1 pour les langues spécifiques de vos données. "Prend en charge 20 langues" signifie souvent que l'outil passe le texte par Google Translate avant d'appliquer NER formé en anglais — ce qui n'est pas la même chose que la détection native à la langue.

Mappez vos données aux langues : Réalisez un inventaire des données incluant la distribution linguistique. Une multinationale avec 70 % de données en anglais, 20 % en allemand et 10 % en français a une exposition au risque différente de celle avec 95 % de données en anglais.

Testez avec des échantillons d'identifiants nationaux : Créez un ensemble de données de test avec 10 exemples de chaque identifiant national pertinent pour vos opérations (Steuer-ID, NIR, PESEL, BSN, etc.) et vérifiez les taux de détection. C'est un audit plus rapide qu'une évaluation F1 à grande échelle.

Revoyez vos DPIAs : Si vous avez des évaluations d'impact sur la protection des données couvrant vos outils d'anonymisation, vérifiez que l'analyse de couverture linguistique est incluse. Une DPIA incomplète qui suppose une couverture uniquement en anglais peut nécessiter une mise à jour.

Le moteur de détection de PII d'anonym.legal utilise une approche multilingue en trois niveaux : modèles spaCy natifs à la langue pour 25 langues à ressources élevées, Stanza pour une couverture linguistique supplémentaire, et XLM-RoBERTa transformers cross-lingual pour une couverture globale de 48 langues. Les types d'entités spécifiques au pays pour tous les États membres de l'UE sont inclus.

Sources :

• ACL 2024 : Détection hybride de PII pour les localités européennes
• Cadre d'annotation PII multilingue évolutif (arXiv 2025)
• HuggingFace XLM-RoBERTa Benchmarks NER cross-lingual
• Microsoft Presidio GitHub Problème #1071 — Faux positifs allemands
• Lignes directrices du CEPD sur l'article 25 Privacy by Design
• Rapport annuel 2024 de la CNIL