Blog
Sécurité

Le pipeline DLP documentaire : les masques qui tiennent

Le DLP documentaire : trois etages de detection, des placeholders numeres sur tout le document, un re-embedd total, des originalaux en AES-256-GCM - deux portes unmask explicites. Census : F-DLP-1.

Simmetric Team8 min de lecture13/10/2026
Le pipeline DLP documentaire : les masques qui tiennent

Le document entre une fois ; le placeholder reste

La base de connaissance d'un workspace AI ingère des documents réels - contrats, courriers RH, factures. Certains portent les données que nul ne devrait lire avec désinvolture, et un LLM ne devrait jamais les citer. La réponse de Simmetric Chat pour les workspaces activés : une pipeline de scan documentaire qui transforme les entités sensibles en placeholders numérotés sur tout le document, et garde l'unique copie propre chiffrée. Le point du design est la dernière phrase - le placeholder reste : le masquage est à sens unique par construction, si bien que « le document » et « le corpus cherchable » deviennent des objets différents du design.

Cet article parcourt la pipeline telle que l'opérateur la rencontre : le scan asynchrone, les trois étages de détection, ce qu'un placeholder garantit, ce qui arrive à la ré-injectation, comment les originalaux sont stockés, et les deux portes d'unmask (re-composition au chat, unmask de l'aperçu) qui rendent la copie propre joignable uniquement à dessein.

Une fonction Enterprise optionnelle, activable par workspace et éteinte par défaut (la bascule du workspace + la porte d'évaluation). Faits : FACT-CENSUS.md F-DLP-1.

Le scan : asynchrone, en file, après l'ingest

Quand le scan documentaire est activé pour un workspace, chaque document téléversé passe par un scan asynchrone via pg-boss après que l'ingest est complet - la voie du téléversement reste réactive, et le scan se comporte comme chaque autre job de fond : en file, retenté, observable. Un corpus legacy a son propre backfill (gated à l'évaluation et confirmé explicitement à l'interface), limité sous la file vivante et reprenable : une colonne marqueur (dlpScannedAt) borne chaque ré-exécution aux documents jamais scannerisés.

Détecter : trois étages

La détection est une pipeline à 3 étages, chacun pour ce qu'il est :

  1. Les patterns regex configurables par l'admin - le service de patterns que l'admin cultive (active/désactive tout pattern, aperçus de test).
  2. La validation par checksum des identifiants italiens/européens à format fixe - le Codice Fiscale (validation d'omocodia incluse), la P.IVA, l'IBAN : ces classes sont déterministes ; une chaîne qui faillit à son checksum n'est pas un identifiant, si bien que les nombres ordinaires ne les déclenchent jamais.
  3. La détection contextuelle par LLM pour les noms/adresses - les classes contextuelles passent par le modèle ; leur rappel est une valeur mesurée et documentée, pas une promesse.

Deux classes nommées sont déterministes (les checksums) et deux sont contextuelles (les classes LLM) - et la porte d'évaluation mesure exactement cet éclissement : la barre de qualité pour l'activation = zéro faux positifs supprimés sur les classes déterministes, avec le rappel des classes contextuelles documenté par exécution.

Le chiffre que ce billet n'imprimera jamais : un compte de « combien de types de PII existent ». Le contract du census est explicite - les nombres introuvables ne partent pas ; les classes sont nommées, le code dit ce qu'il détecte.

Masquer : des placeholders numérotés qui ne peuvent se re-accorder

Les entités détectées deviennent des placeholders numérotés à l'échelle du document ([PERSON_1], [GOV_ID_2], ...). Trois propriétés le rendent signifiant :

  • Cohérence à l'échelle du document - la même entité est le même placeholder sur tout le document ; le LLM continue de lire un document cohérent.
  • Idempotence - le masquage est son propre point fixe : la syntaxe du placeholder ne peut jamais se re-accorder, donc une ré-scannerisation ne produit jamais d'artefacts de la classe [PERSON_1_1].
  • La réécriture est totale - les chunks sont réécrits avec le texte masqué, les vecteurs FTS recalculés, et les embeddings re-générés sur le texte masqué. Aucun vecteur non caviardé ne reste cherchable.

Chiffrer : l'unique copie propre est AES-256-GCM

Le texte original et chaque valeur d'entité atterrissent chiffrés (AES-256-GCM sous le contract de clé de la plateforme). C'est ce qui rend honnête la pipeline : le masquage n'est pas « caché dans une couche de vue » - les octets non caviardés n'existent pas sans chiffrement dans le magasin. Les originalaux chiffrés sont l'unique copie propre.

Les deux portes d'unmask

La copie propre est joignable par exactement deux portes, toutes deux explicites :

  1. La re-composition au chat - à la fin du flux, exactement une fois, le serveur re-compose les placeholders dans le message terminal seulement pour les utilisateurs portant le droit dlp:unmask dans le workspace du document cité. Le texte re-composé voyage dans le payload done de l'SSE ; les visiteurs du widget ne reçoivent jamais de texte re-composé (appliqué côté serveur, pas en cachant une commande).
  2. L'unmask de l'aperçu - l'endpoint du texte documentaire sert le texte masqué par défaut ; un paramètre d'unmask ne vaut qu'à travers l'échelle de la porte (le paramètre présent, la bascule du workspace active, le rôle résolvant le droit). Chaque bras manquant renvoie tout de même du texte masqué avec un 200 - l'endpoint n'est jamais un oracle de droits.

La matrice d'audit

Chaque chemin de lecture est pinné par un test comportemental (la vue du texte, l'aperçu OCR, la synthèse, les citations, le widget, les outils MCP, la recherche plein-texte, les exports, la ré-injectation admin). Les trois piux les plus durs sont les bras du « jamais » : les visiteurs du widget, les surfaces de citations, et les outils MCP reçoivent du texte masqué et jamais une re-composition. La classe du journal d'audit (le registre immuable de la plateforme, F-AUDIT-1) enregistre les opérations qui touchent la surface.

Pour continuer

Le guide porte la marche opérateur complète - la bascule, le coureur d'évaluation, le backfill, chaque endpoint - sur /fr/docs/document-dlp-pipeline :

  • Document DLP pipeline - le guide
  • Faits de ce billet : lignes FACT-CENSUS.md F-DLP-1 (la pipeline), F-DLP-2 (la décision du compte introuvable), F-AUDIT-1 (le journal des événements)

Provenance : Simmetric Chat docs/DLP_DOCUMENT_PIPELINE.md (v0.28.1, Phase 192 DLP-01..06), packages/server/src/services/ (dlpPatternService/dlpChecksum/quota services), encryptionService - à l'état documentaire épinglé par le census (SHA aca5b8ff).

Articles associés