By · Last updated 2026-06-05

Retour au blogGDPR & Conformité

Pourquoi 'Supprimer la colonne Email' ne suffit pas...

Les CSV d'enquête contiennent des PII non seulement dans des colonnes structurées mais aussi dans des réponses en texte libre.

June 5, 20267 min de lecture
research dataCSV anonymizationGDPR Article 89survey datadata sharing

La Lacune Que la Suppression de Colonnes Ne Couvre Pas

Mis à jour pour 2026

Les jeux de données de recherche circulent entre universités sous forme de fichiers CSV. Quand les équipes préparent un CSV pour le partage, le travail est basé sur les colonnes. Trouver les informations personnelles. Les supprimer ou les remplacer.

Cette méthode fonctionne pour les champs fixes. Une colonne nommée « email » contient des adresses e-mail — la supprimer. Une colonne nommée « phone » contient des numéros de téléphone — la supprimer. Une colonne nommée « participant_name » contient des noms — les remplacer par un code.

Mais les réponses en texte libre sont un angle mort. Supprimer les colonnes étiquetées ne les touche pas.

Une enquête avec 5 000 lignes peut avoir cinq colonnes PII structurées et quinze colonnes de réponses en texte libre. Les colonnes structurées contiennent des noms, e-mails, numéros de téléphone, identifiants et années de naissance. Les colonnes de texte libre contiennent des commentaires, notes et suggestions.

Les colonnes structurées sont nettoyées. Les colonnes en texte libre restent brutes. Mais les répondants écrivent des choses comme ces trois exemples.

Premier : « Mon médecin au Boston Medical Center, Dr Maria Santos, a dit que le traitement était nouveau. » Deuxième : « Je vis avec cela depuis mon accident de 2019. » Troisième : « Vous pouvez joindre mon aidant à margaret.wells@gmail.com pour plus de détails. »

Chaque entrée nomme une vraie personne. Certaines contiennent des informations médicales ou des coordonnées. Rien de tout cela n'apparaît dans un en-tête de colonne. Rien de tout cela n'est intercepté par la suppression de colonnes.

Pourquoi Cela Ne Respecte Pas le Standard du RGPD

Le considérant 26 du RGPD définit les données anonymes comme des données qui ne peuvent être liées à aucune personne. Le seuil est élevé. Les données ne sont vraiment anonymes que lorsque la ré-identification n'est pas raisonnablement possible.

Un CSV avec des colonnes structurées nettoyées mais des personnes nommées dans le texte libre ne passe pas ce test. Ces noms sont identifiables. Le jeu de données reste personnel. Les règles de protection de l'article 89 du RGPD s'appliquent toujours. Trois risques en découlent.

Exemption de recherche scientifique (art. 89) : L'article 89 permet aux chercheurs de traiter des données personnelles à des fins scientifiques avec moins d'obligations. Mais seulement là où des « garanties appropriées » existent. Partager un fichier contenant encore des PII en texte libre en invoquant l'article 89 constitue un manquement juridique.

Approbation éthique : La plupart des comités d'éthique et IRB exigent une anonymisation complète pour les jeux de données partagés. Un travail partiel — colonnes structurées nettoyées, texte libre laissé brut — échoue généralement à ce test. Le comité peut rejeter la demande.

Accords de partage de données : Les DSA entre institutions fixent le niveau d'anonymisation requis. Un travail partiel qui ne respecte pas le considérant 26 du RGPD peut violer le DSA. Consultez notre aperçu de la conformité légale pour situer cela dans un programme plus large.

Pourquoi le Texte Libre Est si Difficile à Nettoyer

Les réponses libres sont parmi les cibles PII les plus difficiles à traiter. Voici pourquoi.

Noms en contexte : « Dr Maria Santos au Boston Medical Center » nécessite une reconnaissance d'entités nommées (NER) pour signaler une personne et une organisation. Les listes de mots clés ne peuvent pas trouver cela.

Noms dans des récits : « La voiture de Jean a heurté la mienne » place un vrai prénom dans une histoire. C'est une personne mentionnée en passant. Seul le NER le détecte.

Formats non standards : Les coordonnées peuvent se lire « contactez-moi chez margaret point wells chez gmail. » Les outils regex simples manquent ces variantes.

Entités spécifiques à la recherche : Les enquêtes cliniques contiennent souvent des identifiants d'hôpitaux, des codes de sites et des noms de lieux. Ces éléments peuvent identifier une personne même s'ils semblent génériques.

La correspondance de motifs seule ne suffit pas. Des outils NLP sont nécessaires pour une vraie anonymisation d'enquête. Consultez Sécurité & Conformité pour les options techniques.

Un Exemple Réel de Trois Universités

Une équipe de recherche de trois universités européennes a mené une enquête sur l'expérience des patients. Le jeu de données comptait 5 000 répondants, 3 colonnes PII structurées et 8 colonnes de réponses en texte libre. L'objectif était un partage inter-institutionnel sous DSA et article 89 du RGPD.

Avec suppression de colonnes seulement :

  • Colonnes PII structurées : supprimées
  • Réponses en texte libre : laissées brutes
  • Affirmation : « Colonnes PII supprimées »
  • PII restantes : 47 personnes nommées, 23 adresses e-mail dans les commentaires, 18 références de lieu pouvant identifier des répondants

Avec détection NLP :

  • Colonnes PII structurées : pseudonymisées avec des tokens cohérents
  • Réponses en texte libre : 47 noms remplacés, 23 e-mails masqués, 18 références de lieu généralisées (« Boston Medical Center » → « [Établissement de santé] »)
  • Résultat : un fichier conforme au considérant 26 du RGPD
  • Comité d'éthique a approuvé la méthode
  • DPO a confirmé la conformité au DSA

L'écart est réel. Le premier résultat semble propre. Le second est propre.

Un Protocole en Cinq Étapes Avant le Partage

Utilisez ces étapes avant de partager tout fichier d'enquête ou d'entretien.

Étape 1 : Étiqueter chaque colonne Marquer chaque colonne comme PII structurée, non-PII structurée ou réponse en texte libre. L'écrire.

Étape 2 : Traiter les PII structurées Supprimer les entrées inutiles pour l'analyse. Pseudonymiser les entrées nécessaires au lien entre enregistrements. Documenter les codes utilisés.

Étape 3 : Scanner les colonnes en texte libre Appliquer la détection NLP sur toutes les colonnes de texte libre. Examiner chaque entité détectée. Confirmer lesquelles sont de vraies PII.

Étape 4 : Appliquer les remplacements Remplacer les PII confirmées dans le texte libre. Utiliser des étiquettes claires comme [PERSONNE], [EMAIL] ou [LIEU].

Étape 5 : Vérifier et documenter Échantillonner 50 à 100 lignes de la sortie. Vérifier les entrées en texte libre manuellement. Rédiger une courte note : outils utilisés, types d'entités trouvés, colonnes traitées. La partager avec le jeu de données pour la révision éthique.

Cela transforme « nous avons supprimé la colonne des noms » en un processus clair et documenté. Il répond aux exigences de l'article 89 du RGPD et aux standards d'anonymisation de la plupart des comités d'éthique. Visitez notre hub docs pour des guides connexes.

Sources

Prêt à protéger vos données ?

Commencez à anonymiser les PII avec plus de 285 types d'entités dans 48 langues.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.