Anonymiser avant le modèle, pas après
Données — écrit le 28 août 2026, repris ici le 2 septembre 2026
Note de reprise. Ce texte a été écrit et publié ailleurs le 28 août 2026, avant que ce site existe. Il est repris tel qu’il a été écrit, à une exception près : la version d’origine décrivait le système comme une recherche augmentée. C’était inexact — il s’agit d’un pipeline d’extraction déterministe suivi d’une classification locale. Le raisonnement de cette note, lui, vaut pour les deux.
« C’est bon, les identifiants sont remplacés. »
C’est la phrase qui m’a appris le plus d’humilité en six mois.
Remplacer les identifiants directs est nécessaire. Ça ne suffit pas dès qu’on manipule du texte libre.
Les identifiants ne vivent pas dans les colonnes
Ils vivent dans le texte libre : un commentaire, une note, un échange écrit. C’est-à-dire exactement ce qu’on envoie à un modèle.
Un schéma de base propre ne dit rien du contenu des champs de texte, et c’est là que se trouve l’essentiel de ce qui identifie une personne.
Trois attributs croisés suffisent souvent
Une date, une zone géographique, un statut. Le dossier « neutralisé » redevient unique.
L’anonymisation n’est pas une propriété d’un champ. C’est une propriété de l’ensemble, et elle se perd par recoupement.
Ce qui est entré dans le modèle ne se rappelle pas
Prompt journalisé, index construit, contexte en cache : chaque étape garde une copie. Nettoyer après coup, c’est courir derrière ses propres traces.
C’est le point qui change la conception plutôt que la procédure.
La règle que j’en tire
Traiter la donnée avant le modèle, pas après. Trois étapes.
Détecter les entités en amont, dans le texte libre. Substituer par des marqueurs cohérents, de sorte que le modèle ne voie jamais les valeurs réelles. Ré-hydrater en sortie, de façon contrôlée.
La protection est dans l’architecture, pas dans la confiance.