Détection multilingue des données personnelles pour le RGPD
Mis à jour pour 2026
La faille RGPD cachée
Le RGPD n'a pas de préférence linguistique. L'article 4(1) définit les « données à caractère personnel » sans mentionner 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.
La plupart des outils de détection de données personnelles ont été conçus pour l'anglais uniquement.
Des recherches de l'ACL 2024 montrent que les outils NLP hybrides atteignent des scores F1 de 0,60 à 0,83 pour les locales européens. Les outils uniquement en anglais obtiennent des scores proches de zéro pour les formats d'identifiants nationaux non anglais. L'écart est flagrant. Un outil peut détecter 95 % des données personnelles en anglais. Pourtant, il manque 40 à 60 % des données personnelles allemandes, françaises, polonaises ou néerlandaises dans le même fichier. C'est un problème grave. Cela expose les entreprises à des risques.
Il s'agit d'une réelle faille RGPD. Elle concerne presque toutes les entreprises mondiales utilisant des outils de rédaction centrés sur l'anglais. Consultez notre guide RGPD pour en savoir plus.
Pourquoi les données personnelles sont spécifiques au locale
La détection de données personnelles comporte deux parties.
La première est la détection basée sur des patterns. Elle couvre les identifiants structurés comme les numéros fiscaux et les formats téléphoniques.
La seconde est la détection basée sur la NER. Elle couvre les entités contextuelles comme les noms et les adresses.
Les deux parties dépendent du locale.
Les identifiants structurés diffèrent selon le pays
| Pays | Identifiant fiscal | Format | Validation |
|---|---|---|---|
| Allemagne | Steuer-ID | 11 chiffres | Modulo-11 |
| France | NIR | 15 chiffres + clé à 2 chiffres | INSEE |
| Suède | Personnummer | 10 chiffres | Luhn |
| Pologne | PESEL | 11 chiffres | Modulo-10 |
| Pays-Bas | BSN | 9 chiffres | Elfproef |
| Espagne | DNI/NIE | 8 chiffres + lettre | Modulo-23 |
| Italie | Codice Fiscale | 16 caractères | Somme de contrôle |
Un regex uniquement en anglais pour les SSN (NNN-NN-NNNN) ne correspondra à aucun de ces formats. Chacun nécessite son propre regex. Chacun nécessite aussi sa propre logique de somme de contrôle.
La NER a besoin de modèles natifs
Les noms allemands diffèrent des noms anglais. « Hans-Dieter Müller » est clair pour un modèle allemand natif. Un modèle entraîné en anglais les manque souvent.
Les faux positifs sont aussi un problème. Le gestionnaire d'issues Microsoft Presidio montre des mots allemands mal classifiés comme données personnelles anglaises. Le mot « Null » (zéro en allemand) en est un exemple. Il déclenche de fausses détections de noms dans les modèles entraînés en anglais. En production, les taux d'erreur montent à 3 faux positifs par entité réelle (Alvaro et al., 2024).
Risque réglementaire
Les autorités européennes de protection des données sont conscientes de ce problème. Plusieurs APD nationales ont émis des recommandations.
BfDI allemand : L'article 5(1)(f) du RGPD s'applique à tous les enregistrements. Il couvre les données non anglaises traitées par des outils tiers.
CNIL française : Le rapport annuel 2024 de la CNIL a soulevé des inquiétudes. Il a mis en lumière les outils d'IA qui traitent des données françaises sans détection de données personnelles en français.
APD européennes en général : L'article 25 du RGPD (Protection des données dès la conception) exige des garanties adaptées aux données réellement traitées. Cela inclut les données personnelles non anglaises dans les déploiements mondiaux.
Le risque est clair. Une entreprise peut montrer 95 % de détection de données personnelles sur du contenu anglais lors d'un audit RGPD. Mais si elle traite aussi des données allemandes, françaises et polonaises avec le même outil, des lacunes apparaîtront. Les auditeurs le remarquent. Des amendes peuvent suivre. Consultez notre page de sécurité pour savoir comment nous y répondons.
Architecture à trois niveaux
La recherche et la pratique s'accordent sur une conception hybride à trois niveaux comme meilleure approche.
Niveau 1 : Modèles spaCy natifs
spaCy fournit des modèles entraînés pour 25 locales. Ceux-ci incluent l'allemand, le français, l'espagnol, le portugais, l'italien, le néerlandais, le russe, le chinois, le japonais, le coréen et le polonais. Chaque modèle s'entraîne sur du texte natif. Ils apprennent la syntaxe et les patterns d'entités de chaque locale. C'est important. Un entraînement natif signifie un meilleur rappel et moins de faux positifs.
Pour l'allemand : de_core_news_lg gère les noms composés et les patterns de noms allemands.
Pour le français : fr_core_news_lg gère les entités françaises, les titres, les noms de lieux et les organisations.
Les modèles natifs surpassent les modèles multilingues pour la détection de noms dans les locales à haute ressource.
Niveau 2 : Stanza pour plus de locales
La bibliothèque Stanza de Stanford couvre les locales absents de spaCy. Ceux-ci incluent le croate, le slovène et l'ukrainien. Cela étend la portée aux groupes de locuteurs de l'UE que spaCy ne couvre pas. Stanza est gratuit et open source. Il s'intègre bien dans le reste de la pile.
Niveau 3 : XLM-RoBERTa pour une large portée
Pour les locales où spaCy et Stanza n'ont pas de modèles NER, XLM-RoBERTa comble le vide. Il s'entraîne sur du texte Common Crawl dans 100 locales. Il atteint 91,4 % de F1 multilingue pour la détection de données personnelles (HuggingFace 2024). Il gère bien le code-switching. C'est une caractéristique clé. Cela compte quand un document contient du texte dans plusieurs locales.
Consultez nos docs système de tokens pour voir comment les appels API s'adaptent au volume multilingue.
Types d'entités spécifiques au locale
Les modèles seuls ne suffisent pas. La conformité RGPD exige aussi une couverture des types d'entités pour les identifiants nationaux.
Identifiants nationaux de l'UE par pays :
- DE : Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR : NIR, SIREN, SIRET
- PL : PESEL, NIP, REGON
- NL : BSN
- SE : Personnummer, Samordningsnummer
- ES : DNI, NIE, NIF, CIF
- IT : Codice Fiscale, Partita IVA
Formats téléphoniques : Chaque pays de l'UE a des structures de préfixes uniques. +49, +33 et +48 ont chacun leur propre logique de validation.
Formats d'adresse : Les codes postaux varient largement. Le PLZ allemand utilise 5 chiffres. Les codes français utilisent 5 chiffres (plage 01–99). Les codes postaux britanniques sont alphanumériques. Les codes espagnols utilisent 5 chiffres (01000–52999).
Cas réel : Entreprise pharmaceutique suisse
Une entreprise suisse traite des contrats de travail. Chaque contrat mélange du texte allemand, français et anglais. La Suisse a quatre langues officielles. Leur outil était configuré pour l'allemand uniquement. Il manquait tout le PII des sections françaises.
Un contrat pour un employé basé à Genève contenait un numéro AVS français (13 chiffres), un IBAN de banque suisse et un nom au format français. L'outil uniquement en allemand a manqué le nom au format français. Il n'a pas trouvé le numéro AVS français. Le format AHV-Nummer allemand est différent. Il n'a détecté que partiellement l'IBAN.
L'approche à trois niveaux traite l'ensemble du document. Elle détecte le locale par segment de texte. Elle applique le bon modèle NER à chaque partie. Elle valide chaque identifiant national avec la logique pays correcte.
Documents à locales mixtes
Le cas le plus difficile est le mélange de locales au sein d'un document. Exemples :
- Le contrat en anglais d'une entreprise allemande avec des données d'employés allemands (noms, identifiants fiscaux)
- Un formulaire de consentement RGPD français avec un extrait de politique de confidentialité en anglais
- Un chat où l'agent répond en anglais et le client écrit en arabe
XLM-RoBERTa gère cela nativement. Il ne nécessite pas de déclarations de locale explicites. Il traite du texte à locales mixtes sans segmentation préalable. Cela fait gagner du temps. Cela évite aussi les erreurs dues à de mauvais découpages.
Pour une utilisation en production, combiner la détection automatique de locale (au niveau de la phrase) avec l'inférence XLM-RoBERTa donne une gestion robuste des documents à locales mixtes.
Étapes pratiques
Vérifiez la portée de votre outil. Demandez à votre fournisseur de rédaction des scores F1 pour vos locales spécifiques. « Prend en charge 20 langues » signifie souvent que l'outil passe d'abord le texte par traduction automatique. Ce n'est pas de la détection native.
Cartographiez vos données par locale. Faites un inventaire des données qui inclut la distribution par locale. Une entreprise mondiale avec 70 % d'anglais, 20 % d'allemand et 10 % de français fait face à des risques différents. Celle avec 95 % d'anglais est dans une autre situation.
Testez avec des exemples d'identifiants nationaux. Créez un ensemble de test avec 10 exemples de chaque identifiant national dans vos opérations—Steuer-ID, NIR, PESEL, BSN et autres. Vérifiez les taux de détection. C'est plus rapide qu'un test F1 complet.
Révisez vos AIPD. Vérifiez si la portée par locale est incluse. Une AIPD incomplète supposant des données uniquement en anglais peut nécessiter une mise à jour. Agissez maintenant. N'attendez pas un audit pour découvrir la lacune.
Pour les définitions complètes des types d'entités, consultez la référence des entités et la FAQ. Pour les plans et les tarifs des appels API, visitez tarification.
Le moteur de détection PII d'anonym.legal utilise une approche multilingue à trois niveaux. Il couvre 25 locales à haute ressource via des modèles spaCy natifs. Stanza ajoute une portée locale supplémentaire. Les transformeurs cross-linguaux XLM-RoBERTa étendent la portée à 48 locales. Les types d'entités spécifiques à chaque pays pour tous les États membres de l'UE sont inclus.