Comment nettoyer les données sensibles des logs et du JSON avant de partager.

Dès l’instant où vous collez un fichier de log, une réponse d’API ou un dump d’erreurs dans un ticket Jira, un canal Slack ou une issue GitHub, vous partagez potentiellement plus que vous ne le pensez. E-mails, tokens d’authentification, adresses IP internes, numéros de téléphone, identifiants utilisateurs — tout est en clair, enfoui dans du JSON imbriqué ou caché dans des stack traces. Cela arrive tous les jours, et la plupart des gens ne s’en rendent compte qu’après coup.

Ce que vous divulguez probablement sans le savoir

Les données sensibles se cachent là où on ne les attend pas :

• Tokens JWT dans les en-têtes Authorization — ils ressemblent à eyJhbGciOi... et peuvent être décodés en quelques secondes pour révéler des claims utilisateur et la date d’expiration
• Clés d’API dans les query strings et les en-têtes — sk_live_..., AKIA..., xoxb-... — n’importe laquelle dans un log partagé est une fuite d’identifiants
• Adresses e-mail dans les objets utilisateur, les messages d’erreur et les logs d’audit
• Adresses IP internes dans les logs réseau — 10.x.x.x, 192.168.x.x, 172.16.x.x — elles révèlent la topologie de votre réseau interne
• UUID qui correspondent à de vraies fiches utilisateurs dans votre base de données
• Numéros de téléphone au format international — +44..., +1... — dans des objets de contact ou des logs SMS
• Longues chaînes hexadécimales qui sont en réalité des IDs de session, des refresh tokens ou des chemins de fichiers contenant de vrais noms d’utilisateurs

Le problème n’est pas que l’un de ces éléments soit difficile à repérer. C’est qu’un dump d’erreurs de production peut en contenir des dizaines, imbriqués dans plusieurs objets, et que vous essayez de le partager vite parce que quelque chose est cassé.

Pourquoi la rédaction manuelle échoue

Vous ouvrez le log, cherchez @ et masquez les cinq adresses e-mail que vous trouvez. Vous passez à côté de la sixième, enfouie trois niveaux plus bas dans un objet metadata.contact_info imbriqué. Vous cherchez des chaînes qui ressemblent à des tokens et attrapez l’en-tête Authorization, mais vous manquez le refresh token dans le corps de la réponse. Vous masquez l’e-mail mais laissez le user_id qui y correspond directement dans votre base de données.

La rédaction manuelle échoue parce que :

• Vous êtes pressé — la production est en panne et vous avez juste besoin d’aide
• Les vrais logs ont des structures profondément imbriquées où le même type de valeur apparaît à différents niveaux
• Les stack traces référencent des chemins de fichiers avec de vrais noms d’utilisateurs — /home/jsmith/app/src/handler.py
• Vous trouvez les valeurs évidentes mais manquez celles qui le sont moins et qui pointent toujours vers de vraies données

Comment fonctionne le Masqueur de Données Sensibles

Le Masqueur de Données Sensibles fonctionne entièrement dans votre navigateur. Rien n’est envoyé à un serveur — collez votre texte, il le traite localement et vous donne une version nettoyée à copier.

Voici ce qu’il fait :

1. Détecte automatiquement le JSON lorsque l’entrée peut être interprétée comme du JSON et la traite de façon structurée — il parcourt l’arborescence d’objets et remplace les valeurs sensibles tout en gardant les clés et la structure intactes
2. Repli sur le mode texte pour CSV, XML, logs bruts et tout autre format — il recherche des motifs et remplace les correspondances en ligne
3. Masque les motifs sensibles courants :
   • Adresses e-mail
   • Numéros de téléphone (formats international et américain)
   • Adresses IP (IPv4 et IPv6)
   • Tokens JWT (eyJ...)
   • Clés d’API et tokens (longues chaînes alphanumériques correspondant aux formats courants)
   • UUID
   • Longues chaînes hexadécimales qui ressemblent à des IDs de session ou des secrets
4. Étiquette ce qu’il remplace — la sortie affiche [REDACTED-EMAIL], [REDACTED-TOKEN], [REDACTED-IP], etc., pour que vous voyiez ce qui a été détecté

Mode JSON vs mode texte — ce qui change

Le mode JSON préserve la structure et la validité. Les valeurs sont remplacées, mais les clés et l’imbrication restent intactes. La sortie reste un JSON valide que vous pouvez coller dans un ticket, et un développeur peut toujours comprendre la forme de la réponse sans voir les données réelles.

Le mode texte remplace les correspondances en ligne, où qu’elles apparaissent. La structure de votre log ou CSV est préservée telle quelle, mais les valeurs sensibles sont échangées contre des étiquettes de masquage. C’est préférable pour :

• Les entrées de log multi-lignes mêlant texte et données structurées
• Les exports CSV où vous voulez garder les colonnes intactes
• Le XML avec des valeurs en ligne
• Les stack traces avec chemins de fichiers et noms d’utilisateurs

L’outil détecte automatiquement le mode à utiliser, mais vous pouvez le déduire de la sortie — si vous voyez du JSON structuré avec des valeurs [REDACTED-*], c’était en mode JSON. Si vous voyez des remplacements en ligne dans du texte libre, c’était en mode texte.

Quand la sortie nettoyée est sûre à partager

Le masqueur attrape les motifs courants — e-mails, tokens, IP, UUID, numéros de téléphone et chaînes qui ressemblent à des secrets. Mais il ne peut pas connaître votre domaine. Avant de coller la sortie, passez en revue :

• Les noms de code de projets internes — l’outil ne sait pas que « Projet Sundance » est un nom interne confidentiel
• Les IDs clients qui ne sont pas des UUID — un champ customer_id: 847291 ne sera pas repéré car il ressemble à un entier ordinaire
• Les chemins de fichiers avec de vrais noms d’utilisateurs — /home/jsmith/ ou /Users/sarah.chen/ dans des stack traces
• Les messages d’erreur mentionnant de vraies personnes — « Erreur lors du traitement du paiement de John Smith » ne sera pas signalé car l’outil ne sait pas que John Smith est un client

Le masqueur est une première passe solide. Ajoutez par-dessus votre propre connaissance du domaine avant de partager.

Scénarios concrets

Rapport de bug dans Jira : vous collez la réponse complète de l’API, vous la nettoyez et partagez la structure sans les données. Le développeur peut voir la forme de la réponse, le code d’erreur et l’imbrication — sans voir de vrais e-mails ni tokens.

Message Slack pendant un incident : au lieu de faire une capture d’écran d’un log (difficile à rechercher et impossible à copier-coller), collez le texte, nettoyez-le et partagez la version propre. Vos collègues obtiennent du texte recherchable, et vous ne divulguez pas d’identifiants dans un chat qui sera archivé.

Issue GitHub pour une bibliothèque tierce : vous tombez sur un bug dans un client d’API et voulez coller la requête et la réponse. Nettoyez d’abord — le mainteneur n’a pas besoin de votre vraie clé d’API pour reproduire le problème, et une fois dans une issue publique, le tout est indexé par les moteurs de recherche.

Intégration d’un prestataire ou d’un sous-traitant : vous devez partager un export de données d’exemple pour qu’il puisse construire une intégration. Collez-le, nettoyez-le et partagez la forme — en-têtes de colonnes, noms de champs, structure d’imbrication — sans les vraies fiches clients.

Nettoyez avant de partager — à chaque fois

Le Masqueur de Données Sensibles prend environ cinq secondes à utiliser. Coller, cliquer, copier, partager. C’est plus rapide que le rechercher-remplacer manuel, il attrape les champs imbriqués que vous manqueriez, et il n’envoie jamais rien à un serveur.

Ajoutez-le à vos favoris. La prochaine fois que la production est en panne et que vous devez coller un log dans un ticket, vous serez heureux de l’avoir fait.