Remettez un fichier à quelqu'un qui ne doit jamais voir les données personnelles qu'il contient — et assurez-vous qu'il ne le pourra pas. Quand vous tirez une tranche de production en CSV pour qu'un prestataire reproduise un bug, ou que vous acheminez un lot de tickets vers une équipe d'analytique externalisée, les noms, les e-mails et les numéros de compte ne sont pas rangés en colonnes bien nettes. Ils vivent dans les lignes de log et le corps des tickets sous forme de texte libre. Vous pouvez nettoyer un fichier texte maintenant sans compte : téléversez-le, cochez les catégories à retirer et téléchargez un .txt simple que vous pouvez comparer à l'original.
Où se cachent vraiment les données personnelles
Dans un tableur, vous savez quelle colonne contient l'e-mail. Dans un log ou un export de tickets, non : le nom de famille du client surgit au milieu d'une phrase, le téléphone est coincé dans une trace d'erreur, le numéro de carte a été collé dans une note par un agent pressé. C'est ce qui rend le texte en masse si perméable. Effacer les valeurs à la main sur des milliers de lignes est lent, et un oubli est une brèche — le travail doit donc être mécanique.
Téléversez le fichier et choisissez parmi les catégories que le pipeline sait trouver :
- Noms de personnes, y compris au milieu d'une ligne.
- E-mails et téléphones, dans leurs formes internationales courantes.
- Numéros de carte (PAN), reconnus par leur structure et vérifiés avant retrait.
- IBAN et données bancaires, validés par leur clé de contrôle intégrée.
- Pièces d'identité — DNI, NIF, NIE, CIF et assimilés — repérées par leur caractère de contrôle.
- Adresses postales qui rattachent un enregistrement à un lieu.
Tout ce que vous connaissez déjà — un code interne d'affaire, un nom de projet, un identifiant précis — va dans une deny-list et est retiré au même passage.
Un retrait validé, pas un coup de chance
Les catégories qui feraient le plus mal si une vraie valeur passait sont précisément celles que le pipeline refuse de deviner. Une suite de seize chiffres n'est traitée comme une carte que si elle satisfait l'algorithme de Luhn, donc une PAN authentique est retirée tandis qu'un numéro de commande de même longueur reste intact. Un IBAN n'est réécrit que si son reste mod-97 est correct. Les DNI/NIF/NIE/CIF espagnols sont validés par leur lettre de contrôle, et les téléphones par leur schéma national. Comme ces tests sont arithmétiques, ils fonctionnent de la même façon quelle que soit la langue du texte autour : un identifiant structuré se moque que la phrase autour de lui soit en allemand ou en portugais.
Les identifiants structurés voyagent entre les langues ; les noms non
Le détecteur de noms s'appuie sur des modèles espagnol et anglais, donc les noms de personnes dans du texte allemand, français et italien ne sont trouvés que partiellement. Soyez honnête là-dessus : ajoutez à la deny-list les noms de famille que vous connaissez et relisez ces fichiers. Cartes, IBAN, e-mails, téléphones et identifiants à clé de contrôle sont indépendants de la langue et n'ont pas besoin de cette réserve.
Éditer à la main contre un passage déterministe
- Un chercher-remplacer manque la ligne écrite autrement
- Chaque relecteur retire un ensemble légèrement différent
- Aucune trace de ce qui a été retiré, ni où
- Une seule valeur oubliée est une fuite
- Chaque segment d'une catégorie choisie est trouvé en un passage
- La même entrée donne la même sortie, passage après passage
- Effacer, masquer par
*ou remplacer par<ENTITY>— à vous de voir - Le journal d'audit garde des décalages, jamais la valeur
La sortie est un .txt simple, vous pouvez donc la comparer à la source par un diff et constater par vous-même que chaque segment détecté a disparu : supprimé jusqu'à ne rien laisser, masqué par une série d'astérisques, ou remplacé par un marqueur typé. Le style que vous choisissez est appliqué de la même façon partout dans le fichier. Et la trace d'audit ne consigne que l'emplacement d'un segment — son début et sa fin — jamais les caractères qui s'y trouvaient, si bien que le journal lui-même ne peut jamais divulguer ce qu'il a retiré.
La minimisation des données est le point juridique
L'article 5, paragraphe 1, point c du RGPD rend la minimisation contraignante : les données personnelles doivent être limitées à ce qui est nécessaire. Un prestataire qui débogue une requête, ou une machine de staging qui exécute une suite de tests, n'a pas besoin d'identités réelles — selon le principe, il ne devrait donc pas les recevoir. L'article 4, point 5 trace la ligne qui vous importe vraiment : les enregistrements pseudonymisés restent traçables, alors que retirer purement les identifiants pousse le fichier vers l'anonymisation et hors de ce risque. Remettre un export brut à un tiers, ou copier des données vives dans un environnement hors production, c'est exactement là où les régulateurs regardent. Retirer les données personnelles d'abord est le moyen le moins coûteux de rester du bon côté de cette ligne — et cet outil traite du texte et renvoie du texte : il n'annote pas visuellement un PDF, ne floute pas un visage et ne bipe pas un fichier audio, qui sont des travaux distincts avec leurs propres outils.
Nettoyer un fichier maintenant
Téléversez le .txt, .docx ou PDF, choisissez les catégories et le style de réécriture, confirmez le prix et téléchargez la copie propre. La détection trouve les segments ; le code déterministe les réécrit, le résultat est donc identique à chaque passage. Sans compte, ne payez que pour ce que vous nettoyez.
Quand en avez-vous besoin
Un ingénieur doit remettre un fichier à quelqu'un qui ne devrait jamais voir les données personnelles qu'il contient. Ce peut être un export de la base de production tiré en CSV pour qu'un prestataire reproduise un bug, un lot de tickets de support destiné à une équipe d'analytique externalisée, ou une tranche de logs applicatifs qui deviendra des fixtures de test pour un environnement de staging. Le fichier est du texte libre, donc les noms de clients, les e-mails, les téléphones, les numéros de pièce d'identité, les IBAN et le numéro de carte égaré ne sont pas rangés dans des colonnes étiquetées : ils sont éparpillés dans les lignes de log et le corps des tickets. Les effacer à la main sur des milliers de lignes est source d'erreurs, et une valeur oubliée est une fuite. Téléversez le fichier, choisissez les catégories à retirer, et chaque segment qui est un nom, un e-mail, un téléphone, une carte, un IBAN ou un identifiant est localisé et réécrit de façon déterministe, de sorte que le .txt que vous remettez conserve la structure et aucune des personnes.
L'angle de la conformité
L'article 5, paragraphe 1, point c du RGPD fait de la minimisation des données un principe contraignant : les données personnelles doivent être limitées à ce qui est nécessaire, et un prestataire qui débogue une requête ou une machine de staging qui exécute des tests n'a pas besoin d'identités réelles. L'article 4, point 5 trace la ligne qui vous importe vraiment : la pseudonymisation permet encore de relier un enregistrement à une personne, tandis que retirer purement les identifiants pousse le fichier vers l'anonymisation et hors de ce risque. Partager un export brut avec un tiers ou copier des données vives dans un environnement hors production est précisément là où les régulateurs regardent ; retirer les données personnelles d'abord est le moyen le moins coûteux de rester du bon côté de cette ligne.
Ce que vous pouvez vérifier
Le résultat est un .txt simple que vous pouvez comparer à la source par un diff. Chaque segment détecté a disparu : supprimé jusqu'à ne rien laisser, masqué par une série d'astérisques, ou remplacé par un marqueur typé comme <PERSON> ou <IBAN_CODE> — à votre choix, appliqué de la même façon à chaque passage. Les catégories risquées sont validées, pas devinées : une chaîne de seize chiffres n'est retirée que si elle passe le contrôle de Luhn, un IBAN que si sa clé mod-97 est correcte, donc les vrais numéros de carte partent et un numéro de commande quelconque reste. Le journal d'audit ne stocke que des décalages de caractères — début et fin — jamais la valeur qui s'y trouvait.
Questions fréquentes
- Quels types de fichiers puis-je téléverser, et que reçois-je en retour ?
- Téléversez un `.txt` en texte brut, un `.docx` Word ou un PDF. Le texte est extrait, les catégories que vous avez choisies sont localisées et réécrites, et vous récupérez un `.txt` propre que vous pouvez comparer à la source par un diff. C'est un travail fichier-entrant, fichier-sortant : un seul fichier texte pour tout le lot de lignes, pas un formulaire par enregistrement.
- Quelle est la différence entre supprimer, masquer par des astérisques et remplacer par <ENTITY> ?
- Supprimer efface le segment et ne laisse rien à la place de la valeur. Masquer conserve la longueur en écrivant une série d'astérisques par-dessus. Remplacer insère un marqueur typé comme `<PERSON>` ou `<IBAN_CODE>`, qui garde une ligne lisible et montre à un relecteur quel type de valeur s'y trouvait. Vous choisissez un style et il est appliqué de la même façon à chaque segment détecté du fichier.
- Détecte-t-il de façon fiable les numéros de carte, les IBAN et les pièces d'identité — ou signale-t-il des chiffres au hasard ?
- Les catégories risquées sont validées, pas devinées. Une chaîne de seize chiffres n'est traitée comme une carte que si elle passe l'algorithme de Luhn, donc une vraie PAN part et un numéro de commande de même longueur reste. Un IBAN n'est retiré que si sa clé mod-97 est correcte, et les téléphones sont reconnus par leur schéma national. Comme ce sont des contrôles arithmétiques, ils se comportent de la même façon quelle que soit la langue autour.
- Fonctionne-t-il sur du texte allemand, français ou italien, ou seulement en anglais et espagnol ?
- Les identifiants structurés — cartes, IBAN, e-mails, téléphones, identifiants à clé de contrôle — sont indépendants de la langue et fonctionnent partout. Les noms de personnes sont différents : le modèle de noms s'appuie sur l'espagnol et l'anglais, donc les noms dans du texte allemand, français et italien ne sont détectés que partiellement. Pour ces fichiers, ajoutez à la deny-list les noms de famille que vous connaissez et relisez la sortie.
- Une fois une valeur supprimée, le texte original peut-il être récupéré depuis le fichier de sortie ?
- Non. Les caractères détectés sont réécrits hors du fichier lui-même — supprimés, masqués ou remplacés — et un `.txt` neuf est écrit. Il n'y a pas de couche cachée en dessous ni de métadonnées qui conservent le texte d'avant. Le journal d'audit ne garde que des décalages de caractères, le début et la fin de chaque segment, jamais la valeur qui s'y trouvait, de sorte que rien dans la sortie ne peut être ramené à l'original.