Trouver et masquer les données personnelles avant qu'elles atteignent un modèle

Ce que vous saurez faire

Trouvez les données personnelles dans les documents d’une banque et masquez-les avant d’envoyer le texte à un modèle de langage. Vous comparez des règles simples, Microsoft Presidio sur votre ordinateur et les réponses enregistrées d’un modèle de langage. Vous mesurez les omissions et le masquage excessif de chaque méthode, par type de valeur et par langue. Vous décidez ensuite ce qui nécessite encore une personne et ce que le masquage fait perdre au modèle.

Étude de casPièce de portfolio

Jeu de données

synthetic_pii_finance_multilingual (Gretel), fichiers de test en anglais, en français et en allemand

Licence

Apache-2.0

Durée

Environ 2,5 heures

S’exécute dans

Colab, Kaggle ou VS Code

Compétences utilisées

• Données personnelles et politique de masquage
• Vérification des étiquettes
• Règles et reconnaissance d'entités nommées
• Omissions et masquage excessif
• Sous-groupes par type et par langue
• Intervalles de confiance
• Décisions de révision
• Sous-traitants et frontières de confiance

Ouvrir dans ColabOuvrir dans KaggleVoir sur GitHub

Les carnets sont en anglais. Colab et Kaggle ouvrent votre propre copie. Pour utiliser VS Code, téléchargez le carnet depuis GitHub. Vous êtes bloqué ? Consultez le carnet de solution.

Cette étude de cas porte sur une mesure. Elle prend donc la forme d’un carnet (notebook) Jupyter, pas d’un dossier de projet. Le carnet télécharge une version fixe des documents, exécute les détecteurs sur votre ordinateur et rejoue les réponses enregistrées du modèle. Vous n’avez besoin ni de compte ni de clé. À la fin, vous pouvez aussi faire une exécution en direct avec votre propre clé.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 150 minutes

Ce que vous devez savoir

Cette étude de cas s’appuie surtout sur ces leçons :

• Les données personnelles, les renseignements permettant d’identifier une personne (PII) et les sous-traitants, dans Inventaire des données.
• Le masquage avec des marqueurs et les limites des motifs, qui ne trouvent que les formes connues, dans Réduire et conserver de façon réfléchie.
• Les sous-groupes par langue et ce qu’un petit sous-groupe peut révéler, dans Biais et accessibilité.
• Les preuves d’architecture et les questions qui demandent une révision qualifiée, dans Résidence des données et questions contractuelles.
• L’intervalle à 95 % pour un nombre d’observations, dans Incertitude et sous-groupes, du cours d’évaluation.

Ce qu’il vous faut sur votre ordinateur

Rien : le carnet fonctionne dans Colab ou Kaggle. Pour l’exécuter dans VS Code, utilisez un nouvel environnement virtuel avec Python 3.12. La première cellule du carnet installe Presidio 2.2.364, spaCy 3.8.16 et trois petits modèles spaCy (environ 40 Mo). Nous l’avons testé dans Jupyter sur macOS, en partant de zéro. Nous ne l’avons pas exécuté dans Colab ou Kaggle.

Les modèles et les outils de détection changent vite. Les nombres sur cette page donnent un aperçu d’un modèle, d’une requête (prompt) et d’un échantillon. C’est la méthode qui reste utile.

La situation

Nordhafen Bank est une petite banque qui compte des clients dans plusieurs pays. Son service administratif reçoit environ deux mille documents par semaine : lettres, formulaires de réclamation, courriels et messages de paiement. Lena Brandt dirige ce service. Elle veut qu’un modèle de langage classe les documents dans la bonne file et rédige une première réponse.

Claire Morel est la responsable de la protection des données de la banque. Elle accepte, à une condition : « Les données personnelles restent chez nous. Aucun nom, numéro de compte ou adresse ne doit parvenir au fournisseur du modèle. » Yusuf Okafor, ingénieur en protection de la vie privée, doit respecter cette condition et mesurer à quel point elle l’est.

Yusuf a trois questions. Quelle proportion des données personnelles le masquage trouve-t-il? Où échoue-t-il : quelles valeurs, quelles langues? Qu’est-ce que le modèle perd? Lena en ajoute une quatrième : « Si le masquage ne suffit pas, qu’est-ce qu’une personne doit vérifier? »

Nous avons inventé la banque et les personnes. Les documents proviennent d’un jeu de données public où chaque personne, chaque compte et chaque adresse sont inventés. Les réponses du modèle sont de vrais enregistrements.

Ce que vous allez créer

Vous allez créer un petit pipeline de masquage et une mesure de son efficacité. Le pipeline trouve les données personnelles dans un document et remplace chaque valeur par un marqueur, comme <PERSON> ou <IBAN>. Vous le construisez avec deux détecteurs qui s’exécutent sur votre ordinateur : des règles et Presidio. Un troisième détecteur, un modèle de langage, sert à la comparaison.

Vous mesurez chaque conception sur les mêmes 900 documents de test en anglais, en français et en allemand. Vous utilisez deux mesures : la proportion de valeurs personnelles masquées et la proportion du reste du texte masquée en trop. Vous divisez chacune par type de valeur et par langue. Ensuite, vous rédigez une règle de révision, mesurez ce que le masquage fait perdre au modèle et recommandez une conception à Claire et Lena.

Un marqueur noir sur une lettre

Imaginez un employé qui doit envoyer une copie d’une lettre à un bureau externe, après avoir noirci les renseignements personnels. Deux choses peuvent mal tourner. L’employé peut omettre un nom, que le bureau externe pourra alors lire. Ou il peut noircir trop de texte, empêchant le bureau de travailler : on ne voit plus quelle entreprise a payé, ni quand.

Un logiciel fait les mêmes erreurs. Un détecteur qui omet une valeur la laisse fuiter. Un détecteur qui masque trop de texte détruit du sens. Une valeur peut aussi être partiellement masquée : la ville est masquée, mais la rue et le numéro de porte restent. L’image montre les quatre résultats sur une lettre inventée, avec la sortie réelle de Presidio et ses paramètres par défaut.

Les quatre résultats comptés dans cette étude de cas, sur une lettre inventée (sortie réelle de Presidio avec ses paramètres par défaut).

Description textuelle du diagramme

Une lettre inventée et quatre résultats de Presidio avec ses paramètres par défaut. Masqué : le numéro de téléphone est entièrement masqué. Partiellement masqué : seule la ville de l’adresse est masquée, et la rue reste. Omis : le nom Ana Lima n’est pas masqué. Masqué en trop : le nom de l’entreprise et la date sont masqués, même si ce ne sont pas des données personnelles.

Le numéro de téléphone est masqué : cette étude de cas considère une valeur comme masquée si au moins 80 % de ses lettres et chiffres le sont. L’adresse est partiellement masquée. Le nom est omis. L’entreprise et la date sont masquées en trop. Aucun pipeline ne ramène les trois derniers résultats à zéro. Vous devez donc les mesurer.

Les données

Les documents proviennent de synthetic_pii_finance_multilingual, un jeu de données créé par Gretel.ai pour tester les détecteurs de données personnelles. Chaque ligne contient un document financier complet et une liste de segments étiquetés. Ces segments indiquent le début et la fin de chaque valeur dans le texte, ainsi que son type, comme name (nom), iban (IBAN) ou company (entreprise). Des modèles de langage ont rédigé les documents, et toutes leurs valeurs sont inventées.

Source et licence

« synthetic_pii_finance_multilingual » de Gretel.ai (A. Watson, Y. Meyer, M. Van Segbroeck, M. Grossman, S. Torbey, P. Mlocek, J. Greco, 2024), huggingface.co/datasets/gretelai/synthetic_pii_finance_multilingual, sous la licence Apache-2.0. Nous utilisons les fichiers de test en anglais, en français et en allemand au commit (version enregistrée) 7b844d1. Nous prenons un échantillon fixe, sans modifier les documents ni les étiquettes.

Nous avons comparé quatre jeux de données avant de choisir celui-ci. Nemotron-PII de NVIDIA (CC BY 4.0) contient plus de types de valeurs, mais seulement de l’anglais. Le jeu de données PII anglais de Gretel (Apache-2.0) est aussi uniquement en anglais. Les jeux ai4privacy sont multilingues, mais leur licence autorise seulement l’utilisation non commerciale et interdit la redistribution. Le cours ne peut donc pas les utiliser. Le jeu multilingue de Gretel contient des documents complets avec des segments étiquetés dans trois langues du cours, sous une licence permissive.

L’échantillon et la politique

Le carnet prend au hasard 440 documents par langue, avec une graine fixe : 140 pour le développement et 300 pour le test. Vous pouvez examiner la partie développement, rédiger des règles et choisir les paramètres. Vous mesurez chaque conception sur la partie test une seule fois, à la fin.

Le jeu de données comporte 29 étiquettes. Une politique de masquage précise celles que le modèle ne doit jamais voir. Rédigez-la d’abord, car tous les nombres ci-dessous en dépendent :

Groupe dans le rapport	Étiquettes du jeu de données	Politique
nom	name, first_name, last_name	masquer
adresse	street_address, local_latlng	masquer
téléphone, courriel	phone_number, email	masquer
identifiant de client ou d’employé	customer_id, employee_id	masquer
compte bancaire, carte	iban, bban, bank_routing_number, credit_card_number, credit_card_security_code	masquer
identifiant gouvernemental	ssn, passport_number, driver_license_number	masquer
secret, identifiant en ligne	password, api_key, account_pin, ipv4, ipv6, user_name	masquer
date de naissance	date_of_birth	masquer
conservé pour le modèle	company, date, time, date_time, swift_bic_code	conserver

Un nom d’entreprise, une date ordinaire et le code SWIFT d’une banque n’identifient personne. Le modèle en a besoin pour classer un paiement. Les masquer ne protège personne et fait perdre du sens. Un champ de modèle comme [Date] ou MM/DD/YYYY ne contient aucune donnée personnelle. Il ne compte donc dans aucune catégorie : nous l’appelons un espace réservé.

La partie test contient 2 411 valeurs personnelles et 1 338 valeurs à conserver. Les noms (1 156) et les adresses (661) représentent les trois quarts des valeurs personnelles. Les cartes (34), les secrets (41) et les dates de naissance (39) sont rares. Dans une langue donnée, plusieurs groupes contiennent moins de 20 valeurs. Un pourcentage calculé sur 10 valeurs dit peu de choses. La page présente donc ces groupes sous forme de nombres.

Premières vérifications : tester les étiquettes

Un jeu de données étiqueté est le travail de quelqu’un, et tout travail comporte des erreurs. Sa fiche indique que les étiquettes proviennent d’un modèle d’entités nommées et d’un modèle de langage utilisé comme juge. Elle précise que « certaines erreurs peuvent encore être présentes ». Nous avons donc vérifié les étiquettes avant de nous fier aux scores. Le carnet répète les première et troisième vérifications.

1. Espaces réservés. 136 valeurs étiquetées de l’échantillon sont des champs de modèle, comme [Nom de la Société] ou [Phone Number] (numéro de téléphone). La politique les met de côté.
2. Mots désignant des rôles étiquetés comme noms. Nous avons lu 30 étiquettes de nom choisies au hasard par langue. Quelques-unes ne désignent pas une personne : guests and employees (invités et employés), L'Employé, une adresse de cryptomonnaie. Il y en avait 1 sur 30 en anglais, 2 en français et 1 en allemand.
3. Données personnelles sans étiquette. Parmi 278 chaînes ayant la forme d’un courriel dans l’échantillon, 154 n’ont aucune étiquette. Nous en avons lu 30 : 15 nomment une personne (jean.dupont@example.com), et les autres sont des adresses d’équipe (support@…). Les noms dans les salutations (« De rien, John! ») n’ont souvent aucune étiquette non plus.
4. Valeurs inventées qui échouent à leurs propres vérifications. Seulement 32 des 54 IBAN réussissent la vérification de la somme de contrôle IBAN. Seulement 10 des 26 numéros de carte réussissent celle des cartes. Un vrai IBAN réussit toujours cette vérification. Presidio vérifie ces sommes. Il omet donc beaucoup de valeurs inventées qu’il détecterait dans de vrais documents.

Ce que cela nous apprend. La vérification 3 est la plus importante. Quand un détecteur masque un courriel sans étiquette, il a raison, mais le score compte cela comme du masquage excessif. Quand il omet un nom sans étiquette, le score ne compte pas du tout cette omission. Les omissions mesurées sont donc une borne inférieure : la fuite réelle est un peu plus importante. La vérification 4 produit l’effet inverse : sur de vrais IBAN et numéros de carte, Presidio ferait mieux qu’ici.

Définir le problème

L’unité est une valeur personnelle étiquetée. Pour chaque valeur, une conception produit l’un de trois résultats : masquée, partiellement masquée ou omise. La mesure principale est la proportion de valeurs personnelles masquées. Une valeur partiellement masquée compte contre la conception : une rue et un numéro de porte sans ville mènent encore à une porte.

La deuxième mesure est le masquage excessif : la proportion de toutes les autres lettres et chiffres qu’une conception masque. Elle comprend les valeurs à conserver, les mots ordinaires et certaines données personnelles sans étiquette (vérification 3). Une troisième mesure répond directement à Lena : la proportion de documents dont toutes les valeurs personnelles sont masquées. Un document contenant un nom omis laisse encore fuiter ce nom.

L’endroit où s’exécute le masquage compte autant que son efficacité. La condition de Claire est une frontière de confiance, comme dans Frontières de confiance. Les données personnelles ne doivent pas passer de la banque au fournisseur. Le masquage doit donc s’exécuter dans la banque, avant l’appel au modèle.

L'endroit où s'exécute le masquage. Seul le texte masqué franchit la frontière; un modèle utilisé comme détecteur recevrait le texte non masqué.

Description textuelle du diagramme

Les documents entrent dans les systèmes de la banque. Les règles et Presidio trouvent les valeurs personnelles et les remplacent par des marqueurs. Une règle de révision envoie le texte masqué au fournisseur du modèle ou retient le document pour une personne. Un modèle utilisé pour trouver les données personnelles recevrait le texte non masqué. Son fournisseur aurait donc besoin du même contrat que tout autre sous-traitant.

Voilà pourquoi le modèle de langage sert de comparaison dans cette étude de cas, et non de candidat. Pour trouver les données personnelles, le modèle doit lire le texte avant son masquage. Les données franchiraient la frontière que le masquage doit protéger. Cela peut être acceptable, mais seulement comme décision concernant un sous-traitant et son contrat, pas comme détail technique.

Explorer ce qu’il faut pour décider

Une vue guide l’essentiel de cette étude de cas : quels types de données personnelles sont fréquents, et dans quelle langue. Dans le tableau du carnet, les noms et les adresses dominent dans les trois langues.

Les données réservent une deuxième surprise. La langue d’un document n’est pas celle des noms qu’il contient. Un document « français » peut contenir Giosuè Gelsomina Borsellino ou une rue suédoise, et un document « anglais », María Teresa Feijoo. Le générateur a mélangé des noms et des adresses de nombreux pays. Un détecteur entraîné sur les noms d’une langue rencontre donc aussi ceux d’autres langues.

La référence de base : les règles

Les règles font ce que fait la fonction mask() du cours dans Réduire et conserver de façon réfléchie : reconnaître des motifs de formes. Les règles de cette étude de cas reconnaissent les courriels, les IBAN, les numéros de carte et les adresses IP. Elles reconnaissent aussi les numéros de téléphone, les longs nombres, les codes en forme d’identifiant et les longues clés. Les règles de mots-clés masquent la valeur après des mots comme password: (mot de passe), date of birth (date de naissance), Geburtsdatum (date de naissance) ou adresse :. Les règles de rue reconnaissent rue, straße (rue), Street (rue) et quelques autres mots.

Un petit exemple montre ce que les règles peuvent faire, et leurs limites :

Notebook, section 4

TINY = "Dear Ms Ana Lima, your card 4111 1111 1111 1111 was blocked on 12/03/2024. Call Joe on +44 20 7946 0958."
print(mask(TINY, detect_rules(TINY)))

Dear Ms Ana Lima, your card <CARD> was blocked on 12/03/2024. Call Joe on <PHONE>.

Le numéro de carte et le numéro de téléphone ont une forme. Les règles les masquent donc. Les deux noms n’ont pas de forme, alors les règles les omettent tous les deux. La date reste, comme le veut la politique. Les noms sont les valeurs personnelles les plus fréquentes. Cette limite est donc importante.

Nous avons rédigé les règles uniquement sur la partie développement, en trois étapes, et consigné chaque étape :

Règles, partie développement	Masqué en anglais	Masqué en français	Masqué en allemand
1. Formes seulement : courriel, IBAN, carte, IP, téléphone, identifiant, clé	13,5 %	17,0 %	12,8 %
2. Formats de téléphone corrigés; longs nombres; mots-clés pour les secrets et les dates de naissance	23,1 %	24,3 %	20,2 %
3. Mots-clés et mots de rue pour les adresses	35,2 %	35,4 %	30,6 %

L’étape 1 omettait (800) 123-4567 à la fin d’une phrase, car le motif n’acceptait pas de point après le numéro. L’étape 2 ne trouvait toujours aucune adresse. Après l’étape 3, les règles masquent environ un tiers des valeurs personnelles et moins de 2 % du reste du texte. C’est la référence de base : peu coûteuse, rapide et facile à expliquer, mais incapable de voir les noms.

Reconnaissance d’entités nommées : Presidio

Pour trouver les noms, il faut un modèle qui lit les mots dans leur contexte. La reconnaissance d’entités nommées (NER) consiste à trouver les noms de personnes, de lieux et d’organisations dans un texte. Un petit modèle NER apprend que, dans « Ottmar Keudel signed », les deux premiers mots désignent probablement une personne. Il peut le faire même s’il n’a jamais vu ce nom. Microsoft Presidio (licence MIT) combine un modèle NER de spaCy avec ses propres détecteurs de motifs. Il fonctionne sur le processeur.

Il faut aussi vérifier la licence des modèles spaCy. Les petits modèles anglais et allemand sont sous licence MIT. Le petit modèle français est sous licence LGPL-LR, qui ne figure pas dans la liste du cours. Cette étude de cas utilise donc le modèle multilingue de spaCy (MIT) pour le français. Une licence peut limiter votre choix d’outil pour chaque langue.

Par défaut, Presidio trouve tous les types qu’il connaît, dont les dates (DATE_TIME) et les organisations (ORGANIZATION). L’étude de cas ajuste ses réglages : elle exclut les dates, les organisations, les URL et les détections dont le score est inférieur à 0,4. Sur la partie de développement :

Partie de développement	Masquées	Masquage excessif
Presidio, réglages par défaut	55,9 %	11,9 %
Presidio, réglages ajustés	49,6 %	4,7 %
Règles + Presidio, réglages ajustés	69,9 %	5,8 %

Les réglages par défaut masquent davantage que les réglages ajustés, car masquer toutes les dates masque aussi les dates de naissance. En contrepartie, ils produisent beaucoup plus de masquage excessif. Les règles combinées à Presidio ajusté masquent le plus de valeurs parmi les solutions locales, avec un masquage excessif modéré. Nous avons choisi cette solution sur la partie de développement, avant de calculer les scores sur la partie de test.

Le point de comparaison : un modèle de langage

Le troisième détecteur est chat-small (gpt-6-luna sur Azure). Nous lui avons demandé de lister chaque valeur personnelle du document en JSON, avec la même politique dans ses instructions. Nous avons enregistré ses réponses pour les 900 documents de test : 502 561 jetons d’entrée, 0,0759 $ US au total et une médiane de 1,02 secondes par document. Il a listé 2 880 valeurs. Parmi elles, 4 n’étaient pas des copies exactes du texte et n’ont donc rien masqué.

Rappelez-vous la frontière : en production, ce détecteur reçoit le document non masqué.

Une comparaison équitable, sur la partie de test

Chaque solution traite maintenant une fois les mêmes 900 documents de test, avec les mêmes étiquettes et les deux mêmes mesures.

Partie de test : 2 411 valeurs personnelles dans 900 documents (300 par langue). Intervalles : Wilson, 95 %. Le modèle est chat-small (gpt-6-luna sur Azure), une exécution enregistrée.

Description textuelle du graphique

Part des valeurs personnelles masquées sur la partie de test, avec des intervalles à 95 % : Règles 30,1 % (28,3 à 32); Presidio, réglages par défaut 53,8 % (51,8 à 55,8); Presidio, réglages ajustés 46,7 % (44,7 à 48,7); Règles + Presidio 65,8 % (63,9 à 67,7); Modèle (chat-small) 90,6 % (89,4 à 91,7); Règles + Presidio + modèle 94 % (93 à 94,9). Part des autres lettres et chiffres masqués : Règles 1,7 %; Presidio, réglages par défaut 12,5 %; Presidio, réglages ajustés 4,9 %; Règles + Presidio 5,9 %; Modèle (chat-small) 1,9 %; Règles + Presidio + modèle 6,6 %.

Lisez d’abord le panneau du haut. Les règles seules masquent 30,1 % des valeurs personnelles. Les réglages par défaut de Presidio en masquent 53,8 %, mais masquent aussi 12,5 % du reste du texte. Les règles et Presidio ajusté masquent ensemble 65,8 % des valeurs, avec 5,9 % de masquage excessif. C’est la meilleure solution qui fonctionne à l’intérieur de la banque. Le modèle masque 90,6 % des valeurs et ne masque excessivement que 1,9 % du reste. Les trois ensemble masquent 94 % des valeurs.

Les intervalles sont étroits. L’écart de 25 points entre la solution locale et le modèle est bien plus grand que ces intervalles.

Comptez maintenant les documents, comme le ferait Lena. Parmi les 640 documents de test contenant des données personnelles, les règles et Presidio masquent toutes les valeurs dans seulement 245 documents. Les 395 autres laisseraient passer au moins une valeur. Avec le modèle, 538 documents sont entièrement masqués; avec les trois détecteurs, 576. La part des valeurs masquées cache la fréquence des fuites dans les documents.

Sous-groupes : par langue et par type

Partie de test, environ 800 valeurs personnelles par langue. Intervalles : Wilson, 95 %.

Description textuelle du graphique

Règles et Presidio : Anglais 58,2 % (54,8 à 61,5); Français 72,6 % (69,6 à 75,5); Allemand 66,6 % (63 à 70). Le modèle : Anglais 90,4 % (88,2 à 92,2); Français 91,9 % (89,9 à 93,6); Allemand 89,3 % (86,8 à 91,4).

La solution locale donne ses pires résultats en anglais : 58,2 %, contre 72,6 % en français et 66,6 % en allemand. Vous pourriez vous attendre au contraire, car les outils anglais sont les plus connus. Les noms expliquent ce résultat. Les documents anglais contiennent beaucoup de noms espagnols, italiens et néerlandais, et le petit modèle anglais en manque beaucoup. Il masque seulement 56 % des noms dans les documents anglais. Le modèle multilingue qui lit les documents français en masque 73 %. Le détecteur fondé sur le modèle de langage donne des résultats semblables dans les trois langues, près de 90 %.

La vue par type montre où se trouvent les valeurs manquées :

Partie de test, les trois langues; nombre de valeurs entre parenthèses. Orange : moins de 90 %. Intervalles : Wilson, 95 %.

Description textuelle du graphique

Règles combinées à Presidio, part masquée par type de valeur : adresse (661) 57,2 % (53,4 à 60,9); secret (41) 61 % (45,7 à 74,3); nom (1 156) 63,1 % (60,2 à 65,8); compte bancaire (103) 67 % (57,4 à 75,3); carte (34) 67,7 % (50,8 à 80,9); identifiant en ligne (53) 71,7 % (58,4 à 82); identifiant de client ou d’employé (75) 78,7 % (68,1 à 86,4); date de naissance (39) 79,5 % (64,5 à 89,2); pièce d’identité officielle (62) 85,5 % (74,7 à 92,2); téléphone (114) 96,5 % (91,3 à 98,6); courriel (73) 98,6 % (92,6 à 99,8).

Les adresses courriel et les numéros de téléphone sont presque entièrement détectés : ils ont une forme reconnaissable. Les noms et les adresses sont les deux plus grands groupes et deux des plus faibles. Les comptes bancaires sont aussi mal détectés, en partie parce que beaucoup de faux IBAN échouent à la vérification de leur somme de contrôle (vérification 4). Les cartes et les secrets ont des intervalles larges, car ils sont peu nombreux.

Un exemple de chaque échec

Chaque échec a une cause visible :

• Noms manqués : Hugh M. McLean et María Teresa Feijoo dans les documents anglais; un prénom seul comme Jean, Sophie ou Pierre dans les documents français. Un prénom seul offre peu de contexte.
• Adresses partiellement masquées : 378 Stewart Coves, Chanburgh conserve sa rue; 4 Skolstigen, Skövde conserve son numéro civique. Presidio trouve la ville, mais pas la ligne de rue.
• Codes manqués : U733-U3195-Ti (un identifiant de client) et une fausse clé d’API infonuagique commençant par AKIA ne correspondent à aucune règle.
• Masquage excessif : dans les documents français, le modèle multilingue classe des mots ordinaires avec une majuscule comme des personnes ou des lieux : Boissons, Développer, Destinataire, Partie.
• Valeurs manquées par le modèle lui-même : il a listé 567, East Sunshine Avenue, Los Angeles avec une virgule ajoutée. Ce texte exact ne figurait donc pas dans le document, et rien n’a été masqué. Un détecteur qui réécrit les valeurs échoue sans le signaler.

Erreur courante

Le score semble bon, mais la plupart des documents laissent encore passer des données

Symptôme : l’équipe annonce « 66 % des données personnelles masquées » et prévoit d’envoyer chaque document masqué au modèle.

Cause : la proportion compte les valeurs, pas les documents. Un document avec 12 valeurs et un nom manqué obtient 92 %, mais envoie quand même un nom au fournisseur. Sur la partie de test, la solution locale masque entièrement seulement 245 des 640 documents contenant des données personnelles.

Correction : présentez la part des documents entièrement masqués à côté de la part des valeurs masquées, par langue. Décidez pour chaque document s’il peut être envoyé, comme dans la prochaine section.

Ce qui exige encore une personne

Lena a besoin d’une règle qu’elle peut appliquer chaque jour. Un groupe de valeurs dans une langue passe à une personne si la partie de test contient au moins 20 valeurs de ce groupe et si la solution en masque moins de 90 %. Un groupe de moins de 20 valeurs ne peut pas être évalué à partir de cet échantillon. Il faut donc plus de données avant de lui faire confiance.

Règles + Presidio, partie de test	Anglais	Français	Allemand
nom	56 % sur 411 révision	73 % sur 396 révision	60 % sur 349 révision
adresse	46 % sur 244 révision	63 % sur 241 révision	64 % sur 176 révision
téléphone	93 % sur 41	100 % sur 44	97 % sur 29
courriel	97 % sur 32	100 % sur 22	19/19
identifiant de client ou de membre du personnel	83 % sur 23 révision	77 % sur 22 révision	77 % sur 30 révision
compte bancaire	56 % sur 32 révision	75 % sur 36 révision	69 % sur 35 révision
identifiant gouvernemental	11/14	92 % sur 25	83 % sur 23 révision
carte	6/10	13/18	4/6
secret	10/17	8/13	7/11
identifiant en ligne	9/11	66 % sur 32 révision	8/10
date de naissance	7/9	13/17	11/13

La réponse est inconfortable. Avec la solution locale, les noms et les adresses exigent une personne dans chaque langue. Presque tous les documents contenant des données personnelles ont un nom ou une adresse. En pratique, chaque document contenant des données personnelles exige donc une personne. Le masquage local seul ne respecte pas la condition de Claire.

Avec le modèle comme détecteur, la même règle signale seulement les noms (87–89 %) et les comptes bancaires en anglais et en allemand. Cela réduit la charge de révision, mais le modèle y parvient en lisant le texte non masqué.

Ce que le masquage coûte au modèle

Le masquage protège les personnes, mais le modèle lit moins de contenu. Nous avons enregistré deux tests sur les documents de test. Chaque test utilise trois versions du texte : l’original, le texte masqué par les règles et Presidio, et celui masqué par les réglages par défaut de Presidio.

Routage. Le modèle a choisi le type de document parmi cinq choix, pour 100 documents par langue. Il a correctement classé 295 des 300 documents originaux, 295 des 300 masqués par les règles et Presidio, et 296 des 300 masqués par les réglages par défaut. Le type d’un document ne dépend pas de la personne concernée. Le masquage ne coûte donc rien au routage ici.

Faits. Le modèle a listé les dates et les noms d’entreprises dans 300 documents. Le score est la part des dates et des entreprises étiquetées qu’il a renvoyées :

chat-small (gpt-6-luna sur Azure), 300 documents de test avec une date ou une entreprise étiquetée (100 par langue) : 156 dates et 574 noms d’entreprises. Intervalles : Wilson, 95 %.

Description textuelle du graphique

Dates renvoyées : Texte original 98,1 %; Masqué : règles + Presidio 95,5 %; Masqué : Presidio par défaut 10,9 %. Noms d’entreprises renvoyés : Texte original 81,5 %; Masqué : règles + Presidio 73,5 %; Masqué : Presidio par défaut 28,9 %.

Le masquage qui suit la politique coûte peu. Avec les règles et Presidio, le modèle a encore renvoyé 95.5 % des dates, contre 98.1 % avec l’original. Il a aussi renvoyé 73.5 % des noms d’entreprises, contre 81.5 %. Les entreprises perdues sont celles que Presidio a prises pour une personne ou un lieu, comme une entreprise nommée d’après ses fondateurs. Les réglages par défaut de Presidio coûtent beaucoup plus : seulement 10.9 % des dates et 28.9 % des noms d’entreprises restent. Le masquage excessif n’est pas une précaution supplémentaire sans conséquence; c’est du travail perdu.

Certaines tâches ont précisément besoin des valeurs masquées : une réponse qui salue le client par son nom, par exemple. La banque peut alors garder la liste des marqueurs et des valeurs à l’intérieur de ses systèmes. Après l’appel, elle remet le nom dans le brouillon du modèle. Cette liste contient aussi des données personnelles. Elle exige donc la même protection et une date de fin, comme dans le module 4.

La recommandation

Le rapport de Yusuf à Claire et Lena comporte quatre parties.

1. Masquez toujours à l’intérieur de la banque. Les règles et Presidio ajusté fonctionnent sur les propres ordinateurs de la banque. Ils ont pris environ 34 secondes pour 1 320 documents sur un portable et masquent 65,8 % des valeurs personnelles. Ils conservent les dates, les montants et la plupart des entreprises. Ils forment la première couche pour chaque document et chaque journal.
2. N’envoyez pas automatiquement les documents sur la seule base du masquage local. Seulement 245 des 640 documents étaient entièrement masqués. Les noms et les adresses échouent à la règle de révision dans les trois langues.
3. Choisissez la deuxième couche en prenant une décision sur le sous-traitant. Un modèle de langage masque environ 91 % des valeurs, mais doit d’abord les lire. Claire peut l’accepter seulement si le fournisseur est un sous-traitant lié par contrat pour ces documents. Le masquage protège alors encore les étapes suivantes : requêtes stockées, journaux et tout deuxième modèle. Si elle refuse, les options sont une personne ou un détecteur plus performant qui fonctionne à l’intérieur de la banque. Cela exige une révision qualifiée, comme dans Résidence des données et questions contractuelles. Les mesures fournissent les éléments techniques sur l’architecture nécessaires à cette décision.
4. Gardez une personne pour les cellules faibles, et mesurez de nouveau sur de vrais documents, avec des étiquettes vérifiées par la banque.

De bout en bout : une nouvelle lettre

Une nouvelle lettre arrive, en français. Le carnet Jupyter lui applique la solution choisie. Voici ce que le modèle recevrait :

The masked letter (notebook, section 10)

Objet : remboursement
<PERSON>, <PERSON>,
Je m'appelle <PERSON>, cliente n° <ID>. Le 3 mars 2026, votre agence de <LOCATION> a débité deux fois 129,90 € sur mon compte <IBAN>. Merci de me rembourser. Vous pouvez me joindre au <PHONE> ou à <EMAIL>.
Adresse : <ADDRESS>, <PERSON>

Chaque valeur personnelle est masquée : le nom (deux fois), le numéro de client, l’IBAN, le téléphone, le courriel et l’adresse de rue. La date et le montant restent, ce qui permet au modèle de traiter le remboursement. Cherchez maintenant le masquage excessif. La salutation Madame, Monsieur est devenue deux personnes. La ville de la succursale est devenue un lieu. La règle d’adresse a aussi pris la ligne suivante, Cordialement. Aucun de ces éléments n’identifie une personne, et le modèle perd un peu d’information. Selon la règle de révision, cette lettre passerait quand même à une personne, car elle contient un nom et une adresse.

Constats et limites

• Les formes sont faciles, les noms sont difficiles, et les noms et les adresses sont les valeurs les plus courantes.
• Une langue n’est pas un sous-groupe uniforme. L’anglais était la langue la plus faible pour la solution locale, à cause des noms étrangers qu’il contenait.
• Comptez les documents, pas seulement les valeurs, et vérifiez les étiquettes : ces deux éléments changent le sens d’une proportion.
• Le meilleur détecteur franchit la frontière. Le modèle masque environ 25 points de plus, parce qu’il lit les données personnelles.

Les limites sont réelles. Les documents sont synthétiques, rédigés par des modèles de langage, dans un seul secteur. L’échantillon contient 300 documents de test par langue, ce qui rend les résultats incertains pour les groupes rares. Nous avons utilisé les petits modèles spaCy. Des modèles plus grands, ou un détecteur comme GLiNER, pourraient trouver plus de noms. Le modèle testé est un seul modèle avec une seule requête, enregistré une seule fois.

Utilisation responsable

Apprenez sur des données synthétiques. Ne testez jamais un détecteur en envoyant les documents de vrais clients à un modèle ou à un site Web. Appliquez la méthode aux données réelles seulement là où elles sont autorisées, avec la permission de leur propriétaire.

N’appelez pas un pipeline de masquage « anonymisation ». Le texte masqué contient encore des dates, des montants, des noms d’entreprises et du contexte. Un lecteur déterminé peut souvent le relier à une personne. Inventaire des données le précise : les données qu’on peut relier à une personne restent des données personnelles. Envoyer un texte masqué à un fournisseur est une question juridique et contractuelle, pas une question de score.

Quand vous publiez les résultats, présentez les documents entièrement masqués, les sous-groupes et les vérifications des étiquettes à côté de la proportion principale.

Faites-en un projet de portfolio

Placez le carnet Jupyter, un court rapport et votre tableau de révision dans un dépôt public. Le jeu de données est sous licence Apache-2.0. Vous pouvez donc le nommer et le lier en indiquant son attribution. Un README de cette forme convient :

# Masking personal data before an LLM call: misses, over-masking, review

## Problem
A bank wants a model to route documents, but personal data must not reach the provider.
How much does local masking find, where does it fail, and what does it cost the model?

## Data and licence
Gretel synthetic_pii_finance_multilingual (Apache-2.0), test files EN/FR/DE, 440 per language
(140 development, 300 test). Label checks: placeholders, unlabelled emails, invalid fake IBANs.

## Approach
Masking policy first (24 labels mask, 5 keep). Detectors: rules; Presidio 2.2.364 with small
spaCy models; a recorded LLM as comparison. Measures: share of values hidden (>= 80% of
characters), over-masking, share of clean documents; by type and language; 95% intervals.

## Results (test part)
Rules 30% hidden; Presidio defaults 54% (12.5% over-masked); rules + Presidio 66% (5.9%);
LLM 91% (1.9%). Clean documents: 245/640 locally, 538/640 with the LLM.
Routing unchanged by masking; Presidio defaults lose 89% of the dates.

## Decision
Mask locally always; local masking alone is not enough to send automatically; names and
addresses go to a person; the LLM detector is a processor decision.

## Limits
Synthetic documents, incomplete labels, small rare groups, one model and one prompt.

Comment le décrire en entrevue, en deux phrases : « J’ai mesuré les données personnelles que des outils locaux et un modèle de langage trouvent, manquent et masquent excessivement dans des documents bancaires en trois langues. Le masquage local cachait deux tiers des valeurs, mais masquait entièrement seulement 38 % des documents; j’ai donc conçu une règle de révision humaine. »

Allez plus loin :

• Remplacez les petits modèles spaCy par en_core_web_lg et un modèle GLiNER PII (Apache-2.0), puis mesurez de nouveau les noms. Prédisez d’abord l’ampleur du changement.
• Ajoutez l’espagnol et l’italien du même jeu de données, puis vérifiez si le tableau de révision change.
• Rendez la politique plus stricte : masquez aussi les noms d’entreprises. Mesurez ce que le test des faits perd.
• Étiquetez vous-même 50 documents de développement, y compris les courriels et les noms non étiquetés. Mesurez ensuite à quel point les scores changent.

Vérification des connaissances

Vérifiez votre compréhension

Les règles et Presidio masquent 66 % des valeurs personnelles dans la partie test. Lena demande : « Donc, on peut envoyer deux documents sur trois sans risque? » Que répondez-vous, et quel chiffre lui montrez-vous?

Afficher la réponse

Non. Les 66 % comptent les valeurs, pas les documents. Un document divulgue des données dès qu’une valeur échappe au masquage. La plupart des documents contiennent plusieurs valeurs. Montrez-lui la proportion de documents entièrement masqués. Seulement 245 des 640 documents de test contenant des données personnelles avaient toutes leurs valeurs masquées, soit environ 38 %. Montrez aussi cette proportion par langue. Ajoutez que les étiquettes omettent certaines données personnelles. Même ce chiffre est donc optimiste.

Vérifiez votre compréhension

Le modèle de langage masque environ 91 % des valeurs personnelles, contre 66 % pour les règles et Presidio. Tomás dit : « Alors, utilisez le modèle comme détecteur, problème réglé. » Quel est le problème?

Afficher la réponse

Pour trouver les données personnelles, le modèle doit lire le document avant son masquage. Le texte non masqué franchit alors la frontière que le masquage doit protéger, vers le fournisseur du modèle. Cela n’est acceptable que si le fournisseur est un sous-traitant lié par contrat pour traiter ces données. Le responsable de la protection des données en décide, avec une révision qualifiée. Ce n’est pas un choix technique. Le modèle manque aussi environ 7 % des valeurs. Et lorsqu’il réécrit une valeur, rien n’est masqué et rien ne vous avertit.

Vérifiez votre compréhension

Les paramètres par défaut de Presidio masquent davantage de valeurs personnelles que les paramètres ajustés dans la partie développement. Pourquoi l'étude de cas choisit-elle quand même les paramètres ajustés, combinés aux règles?

Afficher la réponse

Les paramètres par défaut masquent toutes les dates et les organisations. Cela masque certaines dates de naissance, mais détruit aussi des valeurs dont le modèle a besoin. Dans le test des faits, seulement environ 11 % des dates ont été conservées. Les règles combinées à Presidio ajusté masquent davantage de valeurs personnelles que les paramètres par défaut. Elles produisent aussi beaucoup moins de masquage excessif. Elles sont donc meilleures selon les deux mesures. Nous les avons choisies sur la partie développement, avant le test.

Récapitulatif

• Rédigez d’abord la politique de masquage : ce qui ne doit pas atteindre le modèle et ce dont il a besoin.
• Vérifiez les étiquettes avant de vous fier à un score. Les espaces réservés, les données personnelles non étiquetées et les fausses valeurs changent le sens des chiffres.
• Mesurez deux erreurs : les valeurs personnelles manquées ou partiellement masquées, et le reste du texte masqué en trop. Comptez aussi les documents entièrement masqués.
• Ventilez par type et par langue : les formats sont faciles, les noms et les adresses sont difficiles. La langue d’un document n’est pas celle de ses noms.
• Un détecteur qui doit d’abord lire les données exige une décision sur le sous-traitant, pas seulement un meilleur score.
• Décidez ce qu’il faut confier à une personne selon les résultats ventilés. Mesurez aussi ce que le masquage coûte au modèle.

Ensuite, la deuxième étude de cas : créer le modèle de menace d’une application d’IA libre et la tester sur votre ordinateur.

Leçon suivante : Créer le modèle de menace d'une application d'IA libre et la tester