L'écart de conformité RTL
L'arabe et l'hébreu présentent un échec systématique de détection des PII pour les organisations utilisant des outils principalement conçus pour les langues à écriture de gauche à droite. Le problème n'est pas seulement directionnel. Les scripts de droite à gauche nécessitent une tokenisation différente, une logique de segmentation différente et une détection des limites d'entité différente par rapport aux approches LTR. Les systèmes NER standard formés sur des données anglaises appliquent des hypothèses de segmentation LTR qui produisent des limites d'entité incorrectes dans le texte arabe et hébreu.
Au-delà de la directionnalité, la morphologie arabe ajoute un défi plus profond. L'arabe utilise un système basé sur les racines où une seule racine peut produire des dizaines de formes superficielles à travers des préfixes et des suffixes. Le nom d'une personne — Mohammed — peut apparaître sous les formes "Mohammed," "Al-Mohammed," "bin Mohammed," "Mohammed al-Rashid," ou plusieurs formes fléchies selon le contexte grammatical. Les motifs Regex conçus pour les formats de noms occidentaux ne peuvent pas capturer cette variation morphologique. Un modèle ML formé principalement sur des données anglaises manquera les formes superficielles alternatives.
Le RGPD ne reconnaît pas la langue comme une frontière de conformité. Une entreprise de l'UE traitant la correspondance client en arabe de clients MENA doit appliquer les mêmes normes de protection des données que pour la correspondance en français. L'échec technique à détecter les PII en arabe constitue un échec de conformité légale en vertu de l'article 32 du RGPD.
Le cas d'utilisation KYC
Une entreprise fintech à Dubaï traitant des documents KYC (Know Your Customer) pour des clients de l'UE illustre le schéma. Les documents KYC pour les clients arabes contiennent des noms de clients en arabe, des identifiants d'Émirats (format 15 chiffres) et des adresses en script arabe aux côtés de correspondances commerciales en anglais.
Le format de l'ID des Émirats — 784-XXXX-XXXXXXX-X — a une structure spécifique : code pays 784, année de naissance, séquence de sept chiffres, chiffre de contrôle. Les outils PII occidentaux qui manquent de définitions d'entités spécifiques aux Émirats ne peuvent pas détecter ce format d'identifiant du tout. Les champs de nom en arabe sont traités par un NER en script latin qui produit une segmentation incorrecte. Le résultat : invisibilité systématique des PII dans les flux de travail de conformité KYC.
Pour les organisations soumises aux obligations du RGPD concernant ces données, l'écart technique crée une exposition réglementaire directe. L'article 32 du RGPD exige des "mesures techniques et organisationnelles appropriées" — un système qui ne peut pas détecter les identifiants dans 22 % des langues du monde n'est pas une mesure technique appropriée.
Documents en hébreu et en langues mixtes
L'hébreu présente des défis similaires. L'alphabet hébreu est écrit de droite à gauche ; les numéros d'identité israéliens ont un algorithme de validation spécifique (somme de contrôle de type Luhn pour les numéros d'identité israéliens à 9 chiffres). Les documents juridiques israéliens peuvent inclure du texte hébreu, du texte arabe et du texte anglais dans le même document — en particulier dans les contrats commerciaux où l'hébreu est la langue principale, les conditions de service en anglais sont incorporées par référence, et l'arabe est utilisé pour les parties arabophones.
Les documents en langues mixtes avec plusieurs scripts dans le même bloc de texte nécessitent une détection de script avant la reconnaissance d'entité. Sans détection de script, un seul passage NER peut appliquer une tokenisation latine à des scripts sémitiques, produisant une segmentation complètement incorrecte.
Des recherches publiées dans Nature Scientific Reports (2025) ont spécifiquement examiné la performance du NER cross-lingual pour la détection des PII en arabe, trouvant des scores F1 de 0,60 à 0,83 pour les modèles standard contre 0,88+ pour les approches cross-lingual conçues sur mesure (XLM-RoBERTa affiné sur des données NER en arabe).
L'exigence d'une architecture cross-lingual
Une détection efficace des PII en arabe et en hébreu nécessite trois composants que les outils orientés vers l'Occident manquent généralement :
Traitement de texte RTL : conformité à l'algorithme bidirectionnel Unicode pour un rendu correct du flux de texte, et tokenisation consciente du RTL qui respecte les limites de mots dans le texte de droite à gauche.
NER conscient de la morphologie : soit un analyseur morphologique (Farasa pour l'arabe, ou équivalent) soit un modèle de transformateur affiné sur des données NER en arabe/hébreu qui a appris la variation morphologique.
Définitions d'entités spécifiques à la région : les ID des Émirats, les ID israéliens, les ID nationaux saoudiens, les ID nationaux égyptiens et d'autres formats d'identifiants spécifiques à la MENA nécessitent des définitions explicites de types d'entités avec des spécifications de format.
Sources :