By · Last updated 2026-06-05

Retour au blogTechnique

Le problème de la fragmentation des formats de...

Une seule réponse DSAR peut couvrir des contrats Word, des factures PDF, des listes de clients Excel et des exports CSV.

June 5, 20267 min de lecture
document formatsPDF anonymizationExcel GDPRbatch processingDSAR compliance

Le problème multi-format dans la conformité PII

Mis à jour pour 2026

Demandez à un responsable conformité quels formats il anonymise pour les réponses DSAR. La liste est toujours la même : contrats Word, factures PDF, données clients Excel, exports CSV et journaux JSON.

Demandez-lui ensuite quels outils il utilise. La réponse est généralement : trois à cinq. Chaque outil a une couverture d'entités différente. Chacun a des paramètres différents. Chacun produit un journal d'audit différent.

C'est la fragmentation des formats. Elle crée de vraies failles de conformité.

Pourquoi la fragmentation se produit

Aucun outil unique n'a géré chaque format de production au même niveau de qualité. Des outils spécialisés ont émergé pour chaque format. Un pour les PDF. Un pour les tableurs. Une macro pour les CSV. Chacun a sa propre liste d'entités. Aucun ne partage de piste d'audit.

Le résultat est prévisible. Une réponse DSAR couvre plusieurs types de fichiers. Plusieurs outils la traitent. Chaque outil utilise des normes différentes. L'entité X est détectée dans le PDF mais manquée dans le fichier Excel. Les audits des APD exposent cette incohérence.

Défis techniques spécifiques aux formats

Chaque format crée ses propres problèmes de détection.

PDF

Les PDF existent en deux types : texte natif et scans basés sur des images. Les PDF scannés nécessitent d'abord l'OCR. L'OCR introduit des erreurs. Les PDF natifs stockent souvent chaque mot comme un objet texte séparé. Cela interrompt la détection d'entités aux limites des mots. Les mises en page multi-colonnes nécessitent une reconstruction de l'ordre de lecture avant l'analyse.

Word (DOCX)

Les fichiers DOCX contiennent du texte en XML. Mais aussi dans les en-têtes, pieds de page, commentaires, modifications suivies et zones de texte. Une adresse dans l'en-tête de page est une PII. La plupart des outils la manquent. Les modifications suivies peuvent contenir des PII supprimées. Ce texte est invisible dans la vue rendue mais présent dans le fichier.

Excel (XLSX)

Excel stocke les PII dans n'importe quelle cellule sur des centaines de colonnes et des milliers de lignes. Les en-têtes de colonnes comme « SSN » ou « Email » fournissent un contexte que les modèles NER manquent à partir du texte brut. Les dates et les SSN sont souvent stockés sous forme de nombres. Les champs de texte libre comme « notes du responsable » contiennent des PII non structurées. Les outils basés sur les colonnes ignorent ces champs.

CSV

Le CSV manque de la structure d'Excel. Les champs de texte libre dans les colonnes « notes » mélangent PII et autre contenu. Les problèmes d'encodage — UTF-8 versus Latin-1 — causent des échecs pour les caractères non-ASCII dans les noms et adresses européens.

JSON

Le JSON imbriqué enfouit les PII en profondeur : user.address.street.line1. Les tableaux nécessitent une itération. Le même nom de champ peut contenir différents types de données dans différents objets. Une bonne détection nécessite à la fois une conscience du schéma et une analyse du contenu.

L'incohérence est un risque juridique

Voici un scénario DSAR concret sous le RGPD.

Une personne concernée demande toutes les données personnelles détenues à son sujet. L'équipe de conformité trouve ces fichiers :

  • 3 documents Word (contrats, correspondance).
  • 2 documents PDF (factures, transcriptions de support).
  • 1 tableur Excel (données de compte client).
  • 1 export CSV (journaux d'accès système).

Ils utilisent l'outil A pour les PDF. L'outil B pour Word. Une macro pour XLSX. Révision manuelle pour CSV. Chaque outil a une couverture d'entités différente.

La personne concernée reçoit le paquet anonymisé. La colonne Excel « notes du responsable » n'a pas été traitée. L'adresse en en-tête Word a été manquée. Les deux contiennent des PII que la personne concernée avait demandé d'anonymiser.

En vertu de l'article 15 du RGPD (droit d'accès) ou de l'article 17 (droit à l'effacement), il s'agit d'une réponse DSAR incomplète. Si la personne concernée ou un régulateur découvre la lacune, l'outillage incohérent est un facteur contributif documenté.

L'argument pour une norme cohérente

Une conformité DSAR solide ne se contente pas de lister les types de PII à anonymiser. Elle exige la même norme pour chaque format dans l'ensemble de réponses.

Cela signifie :

  • Les mêmes types d'entités vérifiés dans Word, PDF, Excel, CSV et JSON.
  • Les mêmes seuils de confiance appliqués à tous les fichiers.
  • Les mêmes tokens de remplacement utilisés. Si « Jean Dupont » apparaît dans trois documents, un token remplace le nom dans tous les trois.
  • Une piste d'audit couvrant tous les formats.

Une solution mono-plateforme rend cela possible grâce aux préréglages. Un préréglage « DSAR EU Individuals » vérifie les mêmes 32 types d'entités. Il s'exécute sur un contrat PDF, un dossier Excel et un journal CSV. Le même moteur traite les trois.

Pour en savoir plus sur le fonctionnement des préréglages dans les traitements par lots, consultez notre guide sur le traitement DSAR RGPD à grande échelle.

Traitement par lots de jeux de formats mixtes

La conformité DSAR à grande échelle signifie traiter les dossiers multi-formats comme une unité.

Entrée : Un dossier avec 15 fichiers — PDF, DOCX, XLSX, CSV — représentant toutes les données d'une personne concernée.

Étapes de traitement :

  • Détecter le format de chaque fichier.
  • Appliquer le bon analyseur. Extraction de texte PDF. Analyse XML DOCX. Itération de cellules XLSX. Analyse de champs CSV.
  • Exécuter le même pipeline NLP sur le texte extrait de tous les fichiers.
  • Appliquer le même préréglage à chaque fichier du lot.
  • Utiliser un pool de tokens partagé. Le même nom reçoit le même token de remplacement dans les 15 fichiers.

Sortie :

  • Versions anonymisées des 15 fichiers dans leurs formats d'origine.
  • Un rapport d'audit inter-formats. Il montre chaque entité détectée, son document source, son score de confiance et l'action prise.

Ce rapport d'audit est le document de conformité. Il prouve que les 15 fichiers ont été traités selon la même norme. Pour un audit de l'APD, c'est bien plus solide qu'un outillage fragmenté.

Connexe : prévention PII en temps réel pour les fuites de données IA.

Limites connues des pipelines unifiés

L'unification des formats résout la fragmentation. Mais elle introduit ses propres contraintes.

Fidélité de conversion : La conversion de DOCX vers un format de traitement et retour peut perdre l'historique des modifications ou corrompre des objets incorporés. Les documents juridiques nécessitent une validation supplémentaire après traitement.

Maintenance par format : Les reconnaisseurs d'entités pour CSV structuré diffèrent de ceux pour les formulaires scannés. Un pipeline « unifié » nécessite encore un prétraitement par format. Ce prétraitement doit être mis à jour à mesure que les formats évoluent.

Précision sur les formats inhabituels : La plupart des modèles NLP s'entraînent sur du texte web et des documents bureautiques courants. Les formats hérités — anciens fichiers EDI, schémas XML personnalisés, métadonnées CAO — produisent souvent une précision de détection bien inférieure aux benchmarks.

Formats non reconstructibles : Certains types de PDF et les fichiers uniquement en images ne peuvent pas être anonymisés en place. Ils nécessitent une rédaction visuelle. La rédaction visuelle détruit la structure lisible par machine. Si vous avez besoin d'une recherche ou d'une indexation après anonymisation, cela peut ne pas suffire.

Flux de travail DSAR pratique

Pour les équipes de conformité avec des volumes DSAR réguliers :

  1. Collecter tous les documents de la personne concernée
  2. Créer un lot DSAR — glisser tous les fichiers dedans, quel que soit le format
  3. Sélectionner le préréglage « DSAR EU Individuals »
  4. Exécuter le lot
  5. Télécharger les sorties anonymisées et le rapport d'audit consolidé
  6. Vérifier par sondage deux ou trois documents de la sortie
  7. Préparer les documents anonymisés pour la réponse à la personne concernée
  8. Joindre le rapport d'audit au dossier DSAR

L'étape 1 (collecte manuelle) est toujours le coût principal en temps. Les étapes 2 à 8 prennent moins de 10 minutes pour un lot typique. Le rapport d'audit de l'étape 5 satisfait au principe de responsabilité du RGPD.


anonym.legal gère DOCX, PDF, XLSX, CSV et JSON. Chaque fichier utilise le même préréglage. Un rapport d'audit couvre le lot.

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.