Chapitre 8 — Anonymisation des données dans la chaîne RAG
Huitième billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Faut-il anonymiser les données avant que le modèle les voie, ou avant que l'utilisateur ne voie la sortie ? La réponse change tout dans la chaîne, et le régime réglementaire choisit habituellement la réponse pour vous.
Pourquoi ce chapitre existe
Le Chapitre 7 a répondu qui peut voir quoi. Il supposait qu'il y avait quelque chose à verrouiller. Mais le Chapitre 6 a aussi montré que l'embedding n'est pas une fonction à sens unique — le magasin de vecteurs est une copie floue de la source, et le contrôle d'accès n'est que la couche extérieure. Si le corpus contient des numéros de sécurité sociale, des entrées de dossiers médicaux, des noms de clients ou des chemins de code propriétaires, la question n'est plus seulement qui est autorisé à les retrouver. C'est de savoir s'ils auraient dû être embarqués sous cette forme.
C'est la question de l'anonymisation, et c'est la décision de sécurité la plus chargée en ingénierie dans un déploiement RAG. Le choix est positionnel avant d'être algorithmique : à quelle étape le contenu sensible se fait-il transformer ?
8.1 Pré-génération contre post-génération
L'anonymisation pré-génération transforme les données avant qu'elles ne soient embarquées et stockées. Le magasin de vecteurs ne contient jamais les valeurs sensibles d'origine ; même une compromission complète de la couche modèle ne peut pas extraire ce qui n'a jamais été là. C'est l'architecture imposée pour beaucoup de RAG médicaux sous HIPAA et plusieurs applications juridiques soumises au RGPD. Le coût est la qualité de la recherche : la requête dit « Acme Corp » mais le corpus disait « [ORG_47] » avant l'embedding, et la similarité dense chute sur le token le plus informatif.
L'anonymisation post-génération tourne sur la sortie du modèle. La qualité de recherche est préservée ; la garantie de confidentialité est plus faible parce que les données sensibles sont dans l'index. Elle convient quand le modèle de menaces est une fuite côté utilisateur plutôt que côté infrastructure. La plupart des systèmes de production finissent par utiliser un hybride — identifiants directs et catégories à fort poids réglementaire traités en pré-génération, sensibilités opérationnelles de poids moindre masquées en sortie selon le profil d'autorisation de l'utilisateur. Deux disciplines de mise en œuvre comptent : lancer l'anonymisation avant le découpage (sinon le découpeur détruit le contexte dont le détecteur a besoin), et tenir un coffre de dé-tokenisation comme table de correspondance séparée, sous contrôle d'accès, pour qu'un médecin avec le bon rôle puisse encore voir l'identifiant du patient que l'index a masqué.
8.2 Masquage, remplacement synthétique, confidentialité différentielle
Les techniques se divisent en trois familles sur un seul cadran. Le masquage des données personnelles détecte les entités (Microsoft Presidio est l'implémentation open source la plus largement déployée) et les remplace par des placeholders. Les problèmes durs sont le rappel — un détecteur qui rate dix pour cent des noms produit des documents expurgés qu'un attaquant peut localiser par similarité d'embedding — et le sur-masquage, qui effondre le vocabulaire et dégrade la recherche. La discipline est la double mesure : rappel sur un ensemble étiqueté et benchmark hors ligne de qualité de recherche.
Le remplacement synthétique substitue une valeur factice plausible au lieu d'un placeholder, donc « John Smith » devient « Alex Romano » plutôt que [NOM]. L'embedding reste bien réparti et se lit naturellement pour le modèle. La correspondance est déterministe — un hash à clé entre entité réelle et factice — donc la même entité réelle obtient la même factice à travers le corpus, et la clé vit dans le coffre. Le remplacement synthétique fuit encore contre un adversaire muni d'informations auxiliaires, mais c'est une amélioration significative par rapport au masquage quand la qualité de recherche compte.
La confidentialité différentielle est la famille qui offre une garantie mathématique réelle — un mécanisme est ε-DP si la distribution de sortie change au plus d'un facteur exp(ε) quand un seul enregistrement est ajouté ou retiré. DP-Prompt perturbe les morceaux sélectionnés pour le prompt ; DP-MLM perturbe la passe d'embedding du modèle de langage masqué ; 1-Diffractor combine DP et réécriture préservant le sens. La DP est un budget, pas un interrupteur — chaque requête en dépense un peu, et la discipline opérationnelle est largement de la comptabilité de budget. Les trois familles se composent, et le bon déploiement les superpose généralement.
8.3 Le compromis utilité-confidentialité
Les tokens qui méritent le plus d'être anonymisés sont les tokens dont l'anonymisation dégrade le plus la recherche. L'asymétrie est malheureuse mais non négociable. Les atténuations sont partielles : le remplacement synthétique préserve plus de signal que les placeholders ; les placeholders typés ([PERSONNE nommée Alex] plutôt que [PERSONNE]) en préservent encore plus, au prix d'un masquage plus faible. Les corpus anonymisés veulent souvent des morceaux légèrement plus grands que les non-anonymisés, parce que la perte due à l'expurgation est amortie sur plus de contenu survivant.
Le cadrage honnête est que le compromis n'est pas un cadran à un seul axe mais une surface en deux dimensions — le plancher réglementaire en dessous duquel le système est illégal, le plancher d'utilité en dessous duquel les utilisateurs l'abandonnent, et la région d'exploitation entre les deux. Parfois l'écart est large et beaucoup de conceptions fonctionnent. Parfois l'écart est vide : le plancher réglementaire est au-dessus du plancher d'utilité, et la chose la plus précieuse que la phase de conception peut faire est de reconnaître cela avant d'investir dans un système qui ne peut pas être bâti.
8.4 Intégration en entreprise et choix d'une conception
Zilliz Cloud expose l'anonymisation comme transformation de pipeline entre parseur et embedder, avec des points d'attache à quatre étapes (ingestion, recherche, dé-tokenisation, sortie). PII Masker prend la forme opposée — un bloc de construction focalisé que les équipes composent dans leurs propres chaînes. Les déploiements mûrs construisent souvent un service d'anonymisation centralisé avec quatre opérations : anonymiser un document analysé, chercher la dé-tokenisation sous un contexte d'autorisation, scanner une chaîne de sortie pour du contenu sensible résiduel, et rapporter le budget de confidentialité consommé.
La décision de conception part de la réglementation, pas de l'algorithme. Le Safe Harbor HIPAA correspond proprement au masquage des données personnelles avec une liste fixe de dix-huit catégories. PCI DSS est satisfaite par la tokenisation — remplacement synthétique plus coffre. Le principe de minimisation des données du RGPD pousse vers le pré-génération pour les catégories les plus sensibles. La confidentialité différentielle n'est imposée par aucune grande réglementation, mais c'est la bonne réponse quand le modèle de menaces inclut un adversaire sophistiqué muni de données auxiliaires et que le corpus contient des enregistrements qui seraient à déclaration réglementaire en cas de ré-identification.
Ce que prépare le Chapitre 8
Les Chapitres 7 et 8 ensemble complètent la Partie IV. Le contrôle d'accès répond qui peut voir quoi ; l'anonymisation répond à ce qu'il y a à voir au départ. Les deux sont des décisions d'infrastructure que le reste de la chaîne doit respecter, et les deux dépendent de choix faits au moment de l'analyse et du découpage qui ne peuvent pas être inversés à bon compte plus tard. Avec le système conçu et sécurisé, la question suivante est de savoir s'il marche — et cela exige un moyen de le mesurer.
Prochaine étape — Chapitre 9 : La triade d'évaluation RAG. Pertinence du contexte, fidélité, et pertinence de la réponse — trois signaux indépendants qui, ensemble, disent à l'opérateur si le système échoue à la recherche, à la génération, ou à la connexion entre les deux.