Quels champs masquer avant d’envoyer un ticket ou un journal de chat

Le support colle le message d’un client dans Zendesk ou Freshdesk. L’équipe colle un export d’inscription dans Slack ou Teams. Un développeur jette une pile d’erreurs dans le fil. Ces trois gestes ont lieu tous les jours. L’article précédent traitait quels paramètres d’URL supprimer : utm_source et fbclid peuvent partir, id= doit rester. Beaucoup s’arrêtent là. Un mobile comme 06 12 34 56 78, un NIR, un PAN et une adresse e-mail ne disparaissent pas parce que le lien est plus court.

La question n’est pas « faut-il masquer ». C’est comment séparer deux familles de chaînes. Tout ce qui permet d’atteindre une personne ou de bouger de l’argent doit passer derrière des astérisques. Un numéro de commande, une clé de ticket et un SKU localisent le travail, pas la personne — les masquer et l’équipe suivante n’ouvre plus le même dossier. Le tableau, les exceptions et les contrôles ci-dessous restent sur cette seule décision. La page Nettoyer URL de MyPassGen applique la même frontière au texte. Cet article n’est pas une visite de l’outil. Il répond à quels champs masquer avant de transférer un ticket ou un journal de chat, et comment vérifier le résultat.

Un lien propre n’est pas un texte propre

La CNIL rappelle que les données à caractère personnel sont, au sens de l’article 4 du RGPD, toute information se rapportant à une personne physique identifiée ou identifiable. Un numéro de téléphone, un NIR ou une adresse e-mail dans un ticket tombent du côté « identifiable ». Transférer l’original entier dans le canal suivant, le tableur suivant ou le « masqueur en ligne » suivant, c’est aussi transférer cette capacité d’identification.

L’article 9 traite la santé, les données biométriques et d’autres catégories comme des données particulières. L’article 5 fixe la minimisation : n’envoyer que ce dont la personne suivante a besoin pour finir le travail, pas le dossier client complet. Coller un PAN entier dans Slack, ou laisser les coordonnées d’un mineur sur un ticket public, échoue à ce test. Le NIR — le numéro d’inscription au répertoire, souvent appelé numéro de sécurité sociale — est en France un identifiant particulièrement encadré : il n’a rien à faire en clair dans un fil d’équipe ou un export « pour le prestataire ».

Les textes ne placent pas chaque astérisque à votre place. Ils posent une valeur par défaut : la copie que vous envoyez doit permettre de continuer le travail sans voir un numéro complet. Si un masque ou un identifiant de ticket suffit, envoyez cela. Si une personne nommée doit recevoir une clé encore utilisable, n’écrivez pas cette clé dans le corps du ticket. Passez par un canal à usage unique.

Les champs à masquer

Le tableau groupe des champs que vous voyez vraiment dans les tickets, les listes d’inscription, les decks de démo et les journaux collés. Ce n’est pas un catalogue de conformité exhaustif — les éditeurs inventent de nouveaux préfixes — mais il couvre les valeurs qui fuient le plus souvent. Après le masque, le lecteur doit encore reconnaître « c’est un téléphone / une pièce / un e-mail », et ne plus pouvoir s’en servir tel quel.

Téléphone : s’il est encore composable, vous n’avez pas fini

La recommandation ITU-T E.164 limite un numéro public international à 15 chiffres, hors préfixe international. Le plus n’est qu’une notation, pas un chiffre. Un mobile français s’écrit souvent avec le zéro initial ; à l’international, +33 remplace ce zéro. Un masque de ticket comme 06 ** ** ** 78 dit à l’agent suivant « c’est un téléphone » sans lui donner un numéro qu’il peut composer.

Avant de décider, extrayez les chiffres des espaces, parenthèses et +33. Ne cherchez pas seulement un bloc compact de dix chiffres. À l’inverse, un bloc de 8 à 15 chiffres peut être un numéro de commande. Sans +, sans séparateur et sans forme mobile reconnaissable (06, 07, +33), ne traitez pas toute longue suite comme un téléphone. Masquer le numéro de commande est l’erreur la plus fréquente : l’équipe suivante ne retrouve plus la facture.

Pièces d’identité : c’est le milieu qui identifie

Un NIR français a quinze caractères. Les positions du milieu portent notamment le sexe, l’année, le mois et le département de naissance. Masquer seulement la clé de deux chiffres en fin de chaîne et laisser la date, c’est encore transférer l’âge et une zone géographique. Une forme d’envoi plus sûre garde juste assez pour dire « c’est un NIR » et couvre le milieu. La fiche CNIL sur le NIR insiste sur le caractère sensible de cet identifiant : un ticket externe n’a en général aucun besoin de le voir en clair.

Un SSN américain a neuf chiffres en trois groupes. Les exemples publics de la Social Security Administration masquent en ***-**-1234 : les quatre derniers restent pour que quelqu’un puisse demander « est-ce la même personne ? », zone et groupe disparaissent. Une suite de neuf chiffres n’est pas automatiquement un SSN. Les zones 000, 666 ou commençant par 9, ainsi que les groupes ou séries à zéros, sont invalides — souvent plutôt un identifiant métier ou une faute de frappe. Les tickets transfrontaliers portent parfois une carte d’identité chinoise à 18 chiffres : les huit du milieu sont une date de naissance. La même règle s’applique : garder la forme « c’est une pièce », enlever le milieu qui dit quelle personne.

Cartes : le plafond d’affichage n’est pas un objectif

Le numéro de compte principal (PAN) porte une clé calculée par l’algorithme de Luhn (ISO/IEC 7812-1, annexe B). Luhn attrape les fautes de saisie ; il ne prouve pas qu’une carte est active. La longueur va en général de 13 à 19 chiffres. Le PCI DSS autorise, pour l’affichage, au plus les six premiers et les quatre derniers. Sans besoin réel du BIN, n’utilisez pas tout le plafond.

Presque aucun ticket sortant n’a besoin du BIN. Les quatre derniers suffisent pour « est-ce la carte se terminant par 4242 ». Mettre le PAN complet et le nom du titulaire dans le même message Slack empile un compte financier et une identité — plus dangereux qu’une seule fin de numéro. Ne traitez une longue suite comme une carte que si Luhn passe. S’il échoue, préférez « identifiant métier » et laissez le numéro de suivi.

E-mail, clés et adresses

La partie identifiante d’un e-mail est avant le @. Gardez le premier caractère, masquez le reste, laissez le domaine. Cela suffit en général pour distinguer une boîte pro d’une boîte perso, pas pour écrire. Transférer local@domaine tel quel, c’est donner un canal de contact à quiconque ouvre le fil.

Les clés API portent souvent un préfixe de famille : sk- / sk_live_, AKIA / ASIA, AIza, ghp_ / github_pat_, glpat-, npm_, xoxb-, et le jeton après Bearer. Le préfixe nomme la famille. Il n’est pas là pour continuer à appeler l’API. Si la chaîne masquée authentifie encore, vous avez trop peu masqué — ou la clé utilisable n’aurait jamais dû entrer dans le ticket. Une clé complète va sur un lien à usage unique, avec la clé après le # de l’URL. La page de lecture n’exige pas de compte.

Pour l’IPv4, les deux premiers octets suffisent en général (le bloc de documentation 203.0.113.0/24 s’écrit 203.0.*.*) pour reconnaître un opérateur ou un réseau de bureau, sans pointer un hôte. Même règle pour les adresses privées, les sorties VPN et la box familiale dans une pile d’erreurs : masquer les deux derniers octets.

Les suites de chiffres à ne pas toucher

Dans le corps comme dans la query, certaines suites ont l’air aléatoires et servent pourtant à ouvrir le même dossier. Si vous les masquez, la passation casse.

• Commandes et livraison : numéros de commande boutique, de colis, de SAV. La longueur chevauche souvent téléphone ou PAN, mais la chaîne n’a ni forme téléphonique ni Luhn.
• Tickets et identifiants d’objet : clés Zendesk / Jira, identifiants internes, SKU, ID auto-incrémentés. On transfère souvent précisément pour que quelqu’un d’autre ouvre la même ligne.
• Builds et horodatages : numéros de build, préfixes courts de commit, horodatages. Les masquer coupe les étapes de reproduction.

Un essai immédiat : copiez le texte sortant dans un bloc-notes, traitez un type à la fois (téléphone, puis pièce, puis carte), et relisez après chaque passage. Les identifiants métier sont-ils encore là ? Les phrases tiennent-elles encore ? N’écrasez pas toutes les longues suites d’astérisques pour ensuite deviner laquelle vous avez cassée.

Les formes « une ou deux lettres plus six à neuf chiffres » (passeport, PNR) se confondent facilement avec une immatriculation ou une référence de vol. Si une somme de contrôle échoue, ou si le contexte est clairement un siège d’avion, laissez et marquez à la main. Ne déléguez pas cette décision à une seule expression régulière.

Masquer n’est pas anonymiser

Le considérant 26 du RGPD ne sort les informations anonymes du règlement que lorsque la personne n’est plus identifiable. L’article 4, point 5 définit la pseudonymisation comme un traitement qui ne permet plus d’attribuer les données à une personne sans informations supplémentaires. Un ticket qui dit 06 ** ** ** 78 plus un nom, une adresse et un numéro de commande reste identifiable dans l’outil de support. C’est au mieux de la pseudonymisation. Ce n’est pas de l’anonymisation, et ce n’est pas une licence de publication. La fiche CNIL sur l’anonymisation insiste sur cette distinction : tant que la ré-identification reste raisonnablement possible, les données restent personnelles.

Formulez l’objectif correctement : réduire l’usage direct au prochain transfert, à la prochaine capture, dans le prochain canal. Masquer n’autorise pas à poster le résultat sur une page publique, et ne remplace pas « n’envoyer que le nécessaire ». Noms, adresses postales, visages, données d’enfants et clés encore utilisables se trouvent souvent là où aucune règle ne regarde : une autre colonne, des pixels dans une capture, un numéro coupé par des espaces.

Empiler un nom, un téléphone, une pièce et une adresse dans le même message est plus sensible qu’un seul téléphone masqué. Si vous pouvez séparer, ne mettez pas les quatre dans une ligne Slack. Si un numéro de ticket suffit pour que l’autre personne ouvre le dossier elle-même, ne copiez pas le dossier hors du système.

Vérifier sur place : textes côte à côte, astérisques et Réseau

Un slogan ne se vérifie pas. Des caractères, si. Ces étapes ne dépendent d’aucune promesse de marque. Un bloc-notes et les outils de développement suffisent.

1. Collez l’original sortant en entier dans un éditeur local et gardez une copie intacte — ne masquez pas de mémoire.
2. Suivez le tableau : d’abord les téléphones, puis les pièces, les cartes, les e-mails. Un type par passage. Laissez les identifiants métier pour l’instant.
3. Placez original et résultat côte à côte. Les champs traités doivent montrer des astérisques ou un équivalent. Numéros de commande, SKU et dates restent lisibles.
4. Cherchez dans le résultat le mobile complet de l’original, le NIR entier ou la partie locale avant @. Si vous le trouvez encore, vous n’avez pas fini.
5. Si un outil liste dans le navigateur les types trouvés, relisez cette liste contre les astérisques du résultat. Type sur la liste et masque au bon endroit : ce type est fait. Type sur la liste et valeur encore complète : ce type n’est pas fait.
6. Ouvrez les outils de développement → Réseau, cochez « Conserver les journaux », relancez le masquage. Les requêtes document et API ne doivent pas contenir l’original que vous venez de coller. L’analytics ne doit pas emporter une pièce complète ni une boîte entière.

La page Nettoyer URL de MyPassGen travaille sur cette frontière. Dans le masquage, choisissez un type à la fois — téléphone, pièce d’identité, carte bancaire, e-mail, clé API ou IP — et comparez l’original au résultat côte à côte. Les numéros NANP masquent les quatre derniers ; l’E.164 garde un indice de pays ; une carte d’identité chinoise à 18 chiffres est contrôlée ISO 7064 avant masquage ; les cartes passent Luhn, puis ne gardent que les quatre derniers (plus serré que « six premiers + quatre derniers ») ; les e-mails gardent le premier caractère de la partie locale. Le traitement se termine dans l’onglet courant. L’original n’est pas envoyé et n’est pas écrit dans les journaux d’analyse. Aucun compte n’est requis. La page le dit : c’est une aide. Les cas importants demandent encore un passage humain.

Captures, tableaux et l’illusion « déjà masqué »

Un tableau est plus dur qu’un paragraphe. Le téléphone est en colonne A, le nom en B, le scan de pièce en image page trois. Les règles texte ne voient pas les pixels. Avant d’envoyer un deck : photos de pièce non recadrées, enregistrements d’écran avec le numéro complet, Excel avec l’original dans une colonne masquée ou une deuxième feuille.

La « réponse » d’un chat reprend le message précédent. Vous masquez la dernière ligne ; la citation porte encore le numéro complet. Les fils Slack, les transferts d’e-mail et les notes Intercom font la même chose. Dépliez la citation avant d’envoyer, ou écrivez un nouveau message sans citation. Transférer tout un fil de mail, c’est aussi transférer les signatures et les corps de ticket non masqués du début.

Un raccourci ou un QR code ne répare pas le corps. L’article précédent traitait les raccourcis comme une couche de redirection. À ajouter ici : on écrit « commande pour 06 12 34 56 78 » dans un titre de page ou dans utm_content. Après le retrait des noms de tracking, le titre et le paragraphe sont encore là. Nettoyer une URL et masquer un texte sont deux métiers. L’un ne remplace pas l’autre.

Erreurs fréquentes

« Les quatre derniers suffisent pour un téléphone. » Laisser 06 12 34 et ne cacher que 56 78, c’est encore beaucoup de matière pour un fichier de recherche de personnes. Quatre derniers seuls est un compromis d’affichage, pas une preuve. Pour un SSN, laisser zone et groupe et ne cacher que le numéro de série est le même travail à moitié.

« HTTPS protège déjà la vie privée. » HTTPS arrête les oreilles sur le chemin. Le destinataire, chaque membre du canal et chaque administrateur du helpdesk voient encore le texte clair que vous avez collé. Ce que vous réduisez, ce sont les numéros complets inutiles dans la copie que vous envoyez.

« Masqué veut dire publiable. » Après pseudonymisation, le helpdesk peut encore ré-identifier. Une page publique, une étude de cas externe ou un support de formation exige une information qui, sans données supplémentaires, n’est plus rattachable — c’est l’anonymisation. Quelques astérisques n’en sont pas.

« La règle a déjà tourné, on peut sauter la relecture. » Les numéros coupés (06 12 34 56 78), les chiffres écrits en toutes lettres, les pièces dans les images et les préfixes de clé que la règle ne connaît pas fuient. Le passage humain : trouvez-vous encore un original complet par recherche dans le résultat — et le contexte restant permet-il encore de recomposer la même personne ?

Par où commencer le masquage

Commencez par le paragraphe que vous allez envoyer aujourd’hui. Copiez en local, masquez d’abord les téléphones, comparez à l’original, décidez ensuite si les pièces et les e-mails ont besoin du même passage. Les vieux fils et les pages de base de connaissance peuvent attendre. Vous n’avez pas à nettoyer tout l’historique en une séance.

Si un collage mélange URL et corps, retirez d’abord les UTM et identifiants de clic avec le tableau de l’article précédent, puis masquez le texte. Quand un message porte à la fois un numéro de commande et un téléphone, gardez le numéro de commande, masquez le téléphone, relisez la phrase. Après ce seul passage, vous pouvez déjà répondre au titre : masquer les champs qui atteignent une personne ou bougent de l’argent ; laisser les identifiants qui ouvrent le même dossier métier.

Si une personne nommée doit recevoir un mot de passe encore utilisable, un code de récupération ou une clé API, n’écrivez pas le secret complet dans le ticket — et ne traitez pas un masque comme « nous ne l’avons pas envoyé ». Générez un lien à usage unique. Un fichier qui doit pouvoir se déchiffrer plusieurs fois va dans Chiffrer, qui construit un fichier .lock / .enc sur cet appareil ; la phrase secrète part dans un autre message. Masquer un texte réduit les numéros complets dans une discussion. Ce n’est pas un canal d’échange de clés.

Questions fréquentes

Après masquage, l’autre personne sait-elle encore de qui il s’agit ?

Souvent oui. Un identifiant de ticket, un nom et un téléphone masqué se résolvent encore dans le helpdesk. Le masquage réduit la chance qu’une personne hors de ce système compose ou usurpe à partir d’un numéro complet. Il ne transforme pas le texte en statistique anonyme.

Pourquoi cette suite de dix chiffres n’a-t-elle pas été traitée comme un téléphone ?

Une longue suite sans forme mobile, sans 0 initial ou +33 et sans séparateur est plutôt un numéro de commande. Traiter chaque suite comme un téléphone masque le localisateur dont l’équipe suivante a besoin. Dans le doute, laissez, ne traitez que les numéros qui ressemblent à un mobile français, à un NANP ou à un + — marquez le reste à la main.

Pour une carte, les quatre derniers suffisent-ils à la conformité ?

Le plafond d’affichage PCI DSS est six premiers + quatre derniers. Quatre derniers seuls est plus serré et suffit en général à confirmer une fin de numéro. Ce n’est toujours pas une autorisation de poster le numéro dans un canal public. Un PAN complet plus un nom n’ont rien à faire dans Slack.

Faut-il un compte pour masquer ? L’original est-il envoyé ?

Aucun compte. Le risque de journal commence quand vous donnez un ticket complet à un site qui envoie l’original. Un traitement local garde l’original dans l’onglet courant. Vous contrôlez si Réseau a envoyé une pièce complète ou une boîte entière à un tiers — et si vous trouvez encore un numéro complet non masqué dans le résultat.