Ce que le masquage par règles couvre dans un ticket ou un journal de chat — et ce qui reste visible

Coller n’est pas une copie. Ce sont plusieurs copies que vous ne récupérez pas.

Beaucoup traitent le masquage comme une politesse : remplacer le numéro entier par des astérisques, pour que le message ait l’air professionnel. Le dégât commence après le collage. Le système de tickets enregistre le texte. La messagerie enregistre le message. La supervision d’erreurs attrape la pile. Le rejeu de session filme le champ. Une file d’externalisation exporte encore un fichier. Changer quelques caractères sur votre écran ne change aucune copie déjà écrite. Un « nettoyage du ticket » plus tard ne change que la ligne courante. L’historique de recherche, la notification mail et les analyses en aval gardent souvent le texte d’origine.

La fiche OWASP sur la journalisation en fait une contrainte technique, pas un conseil de style. Elle liste ce qui, avant d’entrer dans un journal, doit être supprimé, masqué, nettoyé, haché ou chiffré : données personnelles sensibles et certains identifiants (santé, identifiants d’État), mots de passe d’authentification, jetons d’accès, clés cryptographiques et autres clés maîtresses, comptes bancaires et données de titulaire de carte. En interne, tickets et discussions de groupe jouent souvent le rôle d’un journal informel : faciles à chercher, moins verrouillés que la production, conservés plus longtemps. Coller les mots du client sans les couper, c’est fabriquer exactement l’enregistrement qu’OWASP ne veut pas laisser.

HTTPS ne protège que le saut contre l’écoute. Il n’efface aucun clair que vous avez déjà remis au système suivant. La note précédente disait la même chose des chaînes de requête : elles atterrissent dans l’historique, le Referer et les journaux d’accès. Un numéro dans un paragraphe est la même classe d’exposition. Le support est une phrase, pas une URL. Avant d’envoyer, la question n’est pas « ce système de tickets est-il sûr », mais « ce paragraphe contient-il un champ qui ne devrait pas quitter cet onglet ».

Les règles voient une forme et une clé de contrôle. Elles ne lisent pas la phrase.

Le masquage par règles est un mandat étroit. Une expression régulière trouve un candidat. Une fonction de contrôle jette les hits qui échouent à un test public. Une liste de priorités départage les chevauchements. Le scanner ne sait pas que « Camille Dupont » est une personne, ni que « déposer à l’accueil, 12 rue de Rivoli » est une adresse. Il sait si onze chiffres ressemblent à un mobile chinois continental, si dix-huit chiffres passent le contrôle d’une pièce d’identité citoyenne, si seize chiffres passent le test de Luhn utilisé par les cartes.

Ce n’est pas le même chemin que « envoyer le ticket à un modèle et réécrire les données personnelles ». Un scan sortant vers un modèle remet le texte d’origine à un autre responsable de traitement. Un masqueur de passerelle fait la même chose. Un scan par règles peut rester dans cet onglet : la saisie ne quitte pas le navigateur, le résultat est une copie masquée. Le prix est la couverture. Les pièces hors liste, les préfixes de jetons maison et les chiffres cassés par des espaces manquent.

Une clé de contrôle réduit les fausses alertes. Elle ne prouve pas « cette personne existe ». Une pièce d’identité chinoise à 18 caractères calcule le dernier selon GB 11643-1999 / ISO 7064 MOD 11-2 : multiplier les 17 premiers chiffres par les poids 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2 ; somme modulo 11 ; reste lu dans la table 10X98765432. Un reste 2 donne X, qui vaut 10. Réussir le test veut dire « cette chaîne a l’air bien formée ». Cela ne veut pas dire qu’un état civil la connaît. Les cartes utilisent l’algorithme de Luhn d’ISO/IEC 7812 : depuis la droite, doubler un chiffre sur deux, soustraire 9 au-delà de 9, et n’accepter le numéro que si la somme est divisible par 10. La plupart des suites de 16 chiffres tapées au hasard échouent à Luhn. Une règle ne devrait pas les traiter comme une carte.

Six types de champs : ce qu’une règle peut nommer, et à quoi ressemble le masque

Sont nommables de façon stable les champs qui ont un format public plus un second contrôle. Le tableau suit l’ordre où ces champs apparaissent le plus souvent dans un texte à envoyer. Les formes de masque supposent un masquage « intelligent » : garder un peu du début ou de la fin, remplacer le milieu par des astérisques. Passez au masque complet si les chiffres restants doivent disparaître aussi.

Les règles téléphone doivent accepter à la fois une suite continue de 11 chiffres et des numéros avec espaces, parenthèses ou tirets. Un mobile continental qui commence par 1[3-9] et fait 11 chiffres est une forme publique, pas une table interne d’opérateur. Les numéros internationaux se prennent à l’allure E.164 habituelle : un + en tête, puis 7 à 15 chiffres. Les chaînes trop courtes, ou coincées dans une suite plus longue, doivent tomber, sinon les numéros de commande et de colis deviennent des téléphones.

Pour un texte français du quotidien, c’est la première lacune honnête — et elle n’est pas la même que pour un numéro allemand. Un mobile national du type 06 12 34 56 78 fait dix chiffres. Beaucoup de règles qui acceptent « dix chiffres, ou un numéro avec séparateurs » le voient. La même ligne écrite +33 6 12 34 56 78 tombe dans la règle internationale. Avant d’envoyer, la forme E.164 reste la plus sûre — non parce qu’elle serait « plus française », mais parce qu’une règle la voit même si le critère « dix chiffres » est plus strict ailleurs. Un numéro collé sans espace, du type 0612345678, passe souvent aussi. Un fixe parisien écrit 01 23 45 67 89 ressemble à la même famille.

Le NIR — le numéro d’inscription au répertoire, quinze chiffres avec clé — n’est dans aucune des trois formes de pièce : ni les 18 caractères chinois, ni le SSN à tirets, ni le NINO à lettres. La règle générique de pièce demande des lettres et des chiffres sur 6 à 12 caractères. Quinze chiffres purs restent donc souvent en clair — ou, s’ils portent des espaces et tombent dans la fenêtre 7–15, se font parfois étiqueter à tort comme téléphone. Le numéro fiscal (SPI, treize chiffres) a le même trou. Un numéro de carte nationale d’identité récente, alphanumérique, peut coincer au hasard dans le motif 6–12. Ce n’est pas un format français de premier rang sur la liste.

Côté cartes, le secteur des paiements sépare « combien de chiffres peuvent rester à l’écran » et « comment tronquer un PAN stocké ». Le PCI Security Standards Council, dans la note sur les BIN à 8 chiffres, rappelle une limite d’affichage encore acceptée par les marques : six premiers et quatre derniers. Un poste qui n’a besoin que des quatre derniers pour un rappel ne devrait voir que les quatre derniers. Transmettre un ticket n’est pas de l’acquisition. Garder les quatre derniers par défaut est l’habitude d’envoi la plus prudente. Ce n’est pas une affirmation de certification PCI. Cela dit seulement : coller les 16 chiffres dans le chat dépasse déjà la limite d’affichage habituelle. Un IBAN du type FR14 2004 1010 0505 0001 3M02 606 n’est pas un type à part. Luhn sur 13–19 chiffres ne le prend pas. Dans un ticket français, c’est souvent exactement cette chaîne qui reste. Un SIRET — quatorze chiffres, et Luhn s’applique — peut à l’inverse se faire prendre pour une carte.

Un masque d’e-mail qui ne cache que la partie locale et laisse le domaine entier dit encore au destinataire dans quelle entreprise la personne travaille. Les règles de clés s’accrochent à des préfixes publics : les jetons d’accès personnels GitHub classiques utilisent ghp_ plus 36 caractères ; les jetons à grain fin utilisent github_pat_. Les identifiants de clé d’accès IAM AWS commencent souvent par AKIA plus 16 caractères. Les clés secrètes live Stripe utilisent sk_live_. Ces préfixes existent pour que les SDK et les scanners les reconnaissent — c’est pourquoi une règle peut les voir. Un jeton maison sans préfixe stable, ou une chaîne « g h p underscore… », est pour le scanner du texte ordinaire.

Les IP se prennent sur des plages décimales à points (chaque octet 0–255), pour qu’une version du type 1.2.3 touche moins souvent. Démos et canaris appartiennent à des plages de documentation, pas à des adresses de production. La RFC 5737 réserve 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 et dit qu’elles ne doivent pas apparaître dans le routage public. Les démos d’e-mail utilisent example.com, d’après les noms réservés de la RFC 2606, pas une vraie entreprise.

Pièce et carte peuvent revendiquer la même suite de chiffres

Une pièce citoyenne à 18 caractères est faite de chiffres (le dernier peut être X). Si quelqu’un envoie une identité purement numérique à la règle carte, Luhn réussit parfois. Quand les deux règles portent sur le même paragraphe, il faut une priorité, sinon la même plage est masquée deux fois — ou dans la mauvaise forme.

Un ordre stable : pièce avant les clés, clés avant le téléphone, téléphone avant l’e-mail, e-mail avant la carte, carte avant l’IP. Les raisons sont concrètes. D’abord la pièce, pour qu’un numéro d’identité à 18 caractères ne soit pas avalé comme carte. Un préfixe de clé est plus distinctif que « des chiffres qui ressemblent à un téléphone ». Les chiffres dans un e-mail ne doivent pas être recoupés une seconde fois par la règle téléphone. L’IP est le filet le plus large, elle tourne donc en dernier et mange moins souvent des versions ou des nombres à points dans un numéro de commande. En cas de chevauchement, on garde le hit de plus haute priorité, ou le plus long.

Si vous coupez « numéro de pièce » et laissez « carte bancaire », l’inverse doit se produire : cette suite de chiffres peut valoir comme carte. C’est attendu quand on débogue une règle. Ce n’est pas la politique d’envoi par défaut. Par défaut, les six types sont allumés, puis une passe humaine pour les noms et adresses que les règles ne touchent pas.

Les astérisques ne sont pas une anonymisation, et ce n’est pas une pseudonymisation terminée

Le RGPD trace une ligne que le masquage ne franchit pas. Le considérant 26 dit que le règlement ne s’applique pas aux informations anonymes : informations qui ne se rapportent pas à une personne physique identifiée ou identifiable, ou données à caractère personnel rendues anonymes de telle façon que la personne n’est plus identifiable. Il dit aussi qu’il faut tenir compte de tous les moyens dont le responsable du traitement ou un tiers pourrait raisonnablement se servir pour identifier quelqu’un. L’article 4, point 5, définit la pseudonymisation comme le traitement de données à caractère personnel de telle façon que celles-ci ne puissent plus être attribuées à une personne concernée précise sans informations supplémentaires, et que ces informations supplémentaires soient conservées séparément et soumises à des mesures techniques et organisationnelles. La CNIL sépare les deux mots sans ambiguïté : l’anonymisation rend impossible, en pratique et de façon irréversible, toute identification ; la pseudonymisation remplace des identifiants directs par des identifiants indirects, reste réversible, et les données restent personnelles. Des astérisques au milieu d’un numéro ne figurent nulle part dans le texte comme contrôle achevé.

Le masquage intelligent laisse exprès une queue vérifiable : les quatre derniers d’un téléphone, les quatre derniers d’une carte, le domaine de l’e-mail, le préfixe de la clé. S’il reste dans le ticket un nom, une rue ou un numéro client interne, ces quatre chiffres suffisent souvent à ramener la personne de « identifiable » à « identifiée ». C’est au mieux un pas vers la pseudonymisation. Ce n’est pas une anonymisation. Un masque complet remplace le hit par le même nombre d’astérisques et retire un lien. La longueur, la position et la phrase autour restent. La phrase peut encore dire « merci de rappeler le titulaire » ou « copie de pièce d’identité en pièce jointe ».

Donc « nous avons fait tourner les règles » ne s’écrit pas « ce paragraphe peut entrer dans une base de connaissances publique » ni « cela satisfait une certification ». La page d’outil ne revendique ni le RGPD ni un autre sceau de conformité. La phrase exacte : les formes connues ont été remplacées par un masque ; les formes inconnues n’ont pas été touchées ; savoir si une personne précise reste identifiable, c’est à vous de le juger sur le contexte.

Ce que les règles ratent est souvent la phrase qui déclenche l’incident

Une liste de manques sert plus qu’une liste de hits. Premièrement : les identifiants directs sans forme numérique stable — prénoms, rues, employeurs, notes cliniques, l’école d’un enfant. Il n’existe pas de « table nationale des noms » qu’une regex pourrait interroger, et la reconnaissance de noms dans le cloud confond encore des mots ordinaires. Deuxièmement : les secrets réécrits : « zéro six douze trente-quatre cinquante-six soixante-dix-huit », chiffres pleine chasse, un mot ou un caractère de largeur nulle au milieu, une capture plutôt que du texte. Une regex voit la suite de points de code courante. Elle n’entend pas le numéro qu’on a dicté.

Troisièmement : les secrets sans préfixe public. Une URL de base, un JWT en trois parties, un token= maison, un cookie de session issu du chat ou d’une appli interne — aucun n’est sur la courte liste ghp_ / AKIA. Quatrièmement : pièces jointes et texte riche : un en-tête Word, une colonne de tableau cachée, un numéro dans la signature mail, un calque dans un PDF. Les règles ne scannent que le texte que vous avez collé dans le champ. Cinquièmement : les secrets sémantiques : un montant de contrat non publié, le détail d’une faille, une réclamation dans les mots du client. Ce ne sont pas des formes de données personnelles. Les faire circuler fait tout de même du mal.

Dans le quotidien francophone, trois trous supplémentaires, déjà posés plus haut, tiennent ici comme liste de contrôle : le NIR (quinze chiffres, pas de lettre), l’IBAN, et souvent le numéro fiscal. Qui n’écrit dans la passation que « le masquage a tourné » a souvent laissé ces chaînes intactes. Un SIRET peut au contraire être pris pour une carte. Un numéro de CNI peut matcher ou non ; n’en faites pas une assurance.

Il y a aussi le « hit, mais le mauvais ». Numéros de commande, identifiants de colis et postes de table ressemblent parfois à des téléphones. Une version de document 10.20.30.40 ressemble à de l’IPv4. Clés de contrôle et « pas de chiffre à gauche ni à droite » filtrent une partie. Elles ne filtrent pas tout. C’est pourquoi une zone de résultat doit nommer les types de hits et leurs comptes, pas seulement renvoyer un paragraphe étoilé. Vous contrôlez si le type est juste, pas s’il y a assez d’astérisques.

Contrôler sur place : un canari dans le champ, puis chercher dans Network

« Masquage local, rien n’est envoyé » ne peut pas se prouver tout seul comme slogan. Quatre choses que vous voyez en une séance : quels types ont été nommés, si la forme du masque est juste, si une phrase que vous vouliez laisser est encore là, et si le texte d’origine est parti comme donnée métier.

Construisez un canari sans vraie identité. Pour un numéro français, prenez la forme E.164, par exemple +33 1 23 45 67 89 — une combinaison fictive, pas votre propre ligne. Pour une forme de mobile continental, 13800138000 est une forme factice publiée dans la pub et la doc. E-mail : canary@example.com. IP : 203.0.113.10. Carte : 4111111111111111. Clé : un jeton jetable à préfixe public, par exemple ghp_ plus 36 caractères que vous inventez et traitez ensuite comme brûlé. N’utilisez le numéro de pièce de personne. S’il faut exercer une clé de contrôle, choisissez une date de naissance impossible (1^er janvier 1900), calculez le dernier caractère et marquez le paragraphe « fictif ».

Insérez le canari dans un ticket ordinaire : « L’utilisateur canary@example.com n’arrive pas à se connecter. Rappel +33 1 23 45 67 89. IP source 203.0.113.10. Carte de test 4111111111111111. Jeton ghp_…. Livraison 12 rue de Rivoli, 75001 Paris. » Après le passage, e-mail, téléphone, IP, carte et jeton devraient apparaître dans les comptes de hits et devenir des masques comme dans le tableau. « 12 rue de Rivoli, 75001 Paris » devrait survivre tel quel. C’est la frontière de la règle, pas une panne. Si la rue est masquée aussi, vous n’êtes pas sur un jeu de règles pur, ou les règles ont été élargies — alors contrôler les fausses alertes à part.

Ouvrez ensuite Network dans les outils de développement, cochez Preserve log, et cherchez des chaînes de canari uniques : +33 1 23 45 67 89, canary@example.com ou le faux jeton entier. Elles ne devraient apparaître ni dans une ligne, une query ou un corps XHR / Fetch, ni dans la query ou le corps des statistiques. Un nom de script statique avec « privacy » ou « redact » est attendu. Du texte d’origine qui part comme champ métier est un échec.

1. Rédigez un ticket avec un numéro E.164 fictif, un mail example.com, une adresse RFC 5737, un PAN de test et un faux jeton préfixé. Laissez exprès une rue française en clair.
2. Après le passage, contrôlez les types de hits : les cinq champs nombres ou comptes devraient être nommés ; la rue devrait rester dans le résultat.
3. Cherchez le texte d’origine du canari dans Network. Toute requête métier qui matche veut dire : la saisie a quitté cet onglet.

La preuve est étroite. Dans ce seul passage, les formes connues sont devenues des masques, la phrase d’adresse est restée, et le texte d’origine n’a pas quitté cet onglet comme champ HTTP observé. Cela ne prouve pas qu’une extension n’a jamais lu le champ. Cela ne prouve pas qu’un vrai ticket ne manque pas. Après un changement de navigateur ou le bascule d’une règle, relancez le canari.

S’exercer à la frontière sur une page de masquage qui s’ouvre sans compte

Si vous voulez une page qui pose à plat les interrupteurs de types et les comptes de hits, commencez chez MakePwd par le masquage de données sous Supprimer les UTM. Elle s’ouvre sans compte et sans inscription. Analyse et masquage tournent dans cet onglet. Selon la description produit, le texte d’origine ne part pas comme requête et n’est pas écrit dans les statistiques. Les six types contrôlables sont ceux du haut : téléphone, numéro de pièce, carte bancaire, e-mail, clé API et IP. Le masquage intelligent est le défaut ; vous pouvez passer au masque complet. Un collage est limité à 512 Ko. La page écrit les limites clairement : elle ne reconnaît pas tous les formats de pièce, elle ne remplace pas un contrôle de conformité, et un envoi important exige encore une passe humaine.

N’exercez qu’avec des canaris. Après un passage, regardez trois endroits en même temps : les comptes par type de hit, si la rue est restée dans le résultat, et si Network contient le texte d’origine. Les comptes répondent à « a-t-il nommé les bons types ». La rue répond à « où s’arrête la règle ». Network répond à « est-ce que c’est parti ». Si les trois tiennent, vous pouvez dire : j’ai masqué ces types, je sais que l’adresse est encore là, et j’ai cherché le canari sur la ligne.

Les paramètres de suivi d’une URL sont un autre travail. Si le ticket colle aussi une URL complète avec utm_source ou fbclid, retirez d’abord la query par nom de clé, puis les numéros dans le texte. Les étapes sont dans Quelles données de suivi partent quand vous collez un lien UTM dans un chat. S’il reste après le masquage un secret qui doit arriver intact, envoyez-le une fois par lien auto-destructible et laissez la clé dans le fragment # de l’URL. Un fichier entier : chiffrez-le localement en .lock / .enc (un fichier, 5 Go au plus) puis cloud ou e-mail. Aucune de ces étapes n’exige de compte.

Questions fréquentes

Après les astérisques, ces données restent-elles personnelles ?

Presque toujours. Le considérant 26 du RGPD n’exclut que les informations anonymes : celles qui ne se rapportent pas à une personne identifiée ou identifiable. L’article 4, point 5, définit la pseudonymisation comme un traitement qui, sans informations supplémentaires tenues à part, ne permet plus d’attribuer les données à une personne. Un téléphone qui garde les quatre derniers chiffres, ou un e-mail qui garde le domaine, se recollent souvent avec le contexte du ticket. Un masquage par règles se rapproche au mieux de la pseudonymisation. Ce n’est pas une anonymisation.

Le masquage par règles peut-il remplacer une relecture humaine ?

Non. Les règles voient des formes et des clés de contrôle, pas le sens. Noms, rues, chiffres dictés, captures et jetons réécrits passent. Un envoi important se relit. La page d’outil ne revendique aucune certification RGPD.

Le masquage envoie-t-il le texte d’origine ?

Selon la description produit, l’analyse et le masquage se font dans cet onglet. Le texte d’origine ne part pas comme corps de requête et n’est pas écrit dans les statistiques. Un canari fictif permet de le vérifier dans Network pour ce passage. Cela ne prouve pas qu’une extension n’a jamais lu le champ.

Comment envoyer un secret que le masquage ne termine pas ?

Téléphones et numéros de pièce épars : masquez-les par règles. Un mot de passe entier, un document non publié ou une clé qui doit arriver intacte : envoyez-les une fois par lien auto-destructible et laissez la clé derrière le fragment # de l’URL. Un fichier entier : chiffrez-le localement en .lock ou .enc, puis cloud ou e-mail.

Trois points à retenir avant le prochain envoi

Premièrement : coller, c’est copier. Ticket, chat, supervision et export gardent chacun une ligne. Changer la page courante ne ramène aucun texte déjà parti. Deuxièmement : les règles ne voient que les champs formatés et contrôlables. Noms, rues, chiffres dictés, NIR, IBAN, numéro fiscal et jetons maison sont une passe humaine, et les queues restantes plus le contexte peuvent encore identifier une personne. Troisièmement : contrôler trois endroits — les types de hits, la phrase que vous vouliez laisser, et une recherche Network du canari.

Si la question suivante est de savoir si la query d’une URL complète doit voyager, lisez Quelles données de suivi partent quand vous collez un lien UTM dans un chat. Si vous voulez vérifier que le clair n’a pas quitté cet onglet comme donnée métier, lisez Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Cette note ne trace qu’une ligne que vous pouvez écrire dans une conclusion : ce que le masquage par règles peut faire sur le corps d’un ticket — et ce que vous n’avez pas le droit d’affirmer qu’il a fait.