Anonymisation locale : comment ça fonctionne avant un appel LLM

L’usage d’un modèle de langage sur des documents d’entreprise pose une question simple en apparence : que voit réellement le fournisseur ? Dès qu’un texte contient des noms, des adresses, des identifiants clients ou des coordonnées bancaires, l’envoyer tel quel à un service tiers revient à exposer des données personnelles. L’anonymisation locale répond à ce problème en transformant le texte avant tout appel au modèle, de sorte que ce dernier ne raisonne que sur des données dépourvues d’éléments identifiants. Cet article décrit le fonctionnement de cette mécanique sans en masquer les limites.

Étape 1 : détecter les entités sensibles, en couches

La première étape consiste à repérer, dans un texte, ce qui identifie une personne ou une organisation. Aucune méthode unique ne suffit. Une implémentation sérieuse combine plusieurs couches complémentaires, chacune couvrant un angle mort des autres :

• Les formats déterministes (expressions régulières) : l’IBAN, le numéro de sécurité sociale, le SIREN, une adresse e-mail ou un numéro de téléphone suivent des structures connues. Ils se détectent par règle, sans ambiguïté, et constituent le socle le plus fiable de la détection.
• La reconnaissance d’entités nommées (NER) : des modèles locaux de traitement du langage repèrent les noms de personnes, les lieux ou les organisations, y compris ceux qu’aucune liste ne pouvait prévoir. Ces modèles tournent sur le serveur de l’entreprise, sans appel externe.
• Les listes propres à l’entreprise : une liste noire (termes à ne jamais laisser sortir, par exemple un nom de projet interne) et une liste blanche (termes à ne jamais bloquer). C’est le levier d’adaptation le plus puissant : un élément que la détection automatique a manqué une fois est ajouté à la liste et systématiquement bloqué pour les envois suivants, sans réentraînement.

Ce point mérite d’être souligné : la détection ne repose pas sur l’entraînement d’un modèle propriétaire sur les données du client. Elle enrichit des couches de code (règles, listes, lexiques) qui se calibrent par client de façon quasi immédiate.

Étape 2 : remplacer par des jetons typés et cohérents

Une fois une entité détectée, elle est remplacée par un jeton, c’est-à-dire un marqueur neutre. Deux propriétés de ce jeton sont déterminantes pour la qualité du résultat.

Le jeton est d’abord typé : « Sophie Martin » ne devient pas un code opaque mais un marqueur qui conserve la nature de l’information, par exemple un jeton de type « personne », un autre de type « IBAN ». Le modèle sait ainsi qu’il manipule une personne ou un compte bancaire, ce qui lui permet de raisonner correctement sans connaître la valeur réelle.

Le jeton est ensuite cohérent : si « Sophie Martin » apparaît à plusieurs endroits du document, ou dans plusieurs documents d’un même dossier, elle reçoit toujours le même jeton. Cette stabilité préserve la logique du texte. Le modèle comprend qu’il s’agit de la même personne, et les recoupements entre documents restent possibles côté serveur sans jamais exposer l’identité.

Étape 3 : la table de correspondance ne quitte pas le serveur

À chaque remplacement, une table associe le jeton à la valeur réelle. Cette table de correspondance est le point sensible de tout le dispositif : c’est elle qui permet de reconstituer le sens. Elle reste donc strictement sur le serveur de l’entreprise, chiffrée. Le modèle, lui, ne reçoit que le texte transformé. Il n’a aucun moyen de retrouver qui ou quoi se cache derrière un jeton, car la clé de lecture ne lui est jamais transmise.

Étape 4 : réversibilité locale de la réponse

Le modèle traite le texte transformé et renvoie une réponse qui contient, naturellement, les mêmes jetons. La dernière étape rétablit le sens : en s’appuyant sur la table de correspondance restée en local, chaque jeton est remplacé par sa valeur réelle. L’utilisateur lit une réponse complète, en valeurs d’origine, alors que le fournisseur du modèle n’a jamais vu l’identité des personnes ou des organisations concernées. La réversibilité est entièrement locale ; elle ne dépend d’aucun service externe.

Étape 5 : le journal d’egress, la preuve de ce qui est sorti

Une anonymisation qui ne se vérifie pas reste une affirmation. C’est pourquoi chaque envoi vers un modèle est journalisé. Le journal ne contient jamais le texte réel : pour chaque envoi, il enregistre quelles sources sont sorties, combien d’identifiants ont été remplacés par des jetons, ce qui a été bloqué (santé, données interdites de cloud), l’horodatage et un identifiant de requête. Ce journal d’egress permet à une direction de la sécurité ou à un délégué à la protection des données de constater lui-même ce qui a quitté le serveur, sans avoir à s’en remettre à une parole de fournisseur. La transparence devient un artefact consultable, pas un engagement.

Les limites : le risque zéro n’existe pas

L’honnêteté impose de poser clairement les limites de la méthode, car aucune détection automatique n’est parfaite. Sur notre corpus interne (206 documents synthétiques français, multi-métiers, écrits pour le test), la détection atteint un recall mesuré de 94,2 %. Sur un benchmark public français, dans notre périmètre de types d’entités, ce recall se situe autour de 75 %. Nous ne présentons jamais ces chiffres comme 100 % : une part résiduelle d’entités peut échapper à la détection, et prétendre le contraire serait trompeur.

Deux principes de conception encadrent ce risque résiduel. D’abord le fail-closed : en cas de doute, ce qui n’est pas certifié sûr n’est pas envoyé, mais conservé en local ou soumis à une revue humaine. La sécurité tient par du code déterministe et un filet humain, pas par le bon vouloir du modèle. Ensuite, certaines catégories ne relèvent pas de l’anonymisation : les données de santé, qui constituent des données sensibles au sens de l’article 9 du RGPD, sont bloquées plutôt qu’anonymisées. La pseudonymisation ne rend pas licite un traitement qui ne le serait pas autrement ; pour ces données, l’arbitrage prudent consiste à ne pas sortir du tout.

Une précision de rigueur enfin sur le vocabulaire : au sens strict du RGPD, une transformation réversible, comme la jetonisation qui peut être ré-associée à la valeur d’origine, relève de la pseudonymisation, et non de l’anonymisation au sens juridique, laquelle suppose une irréversibilité empêchant toute ré-identification. Nous employons le terme « anonymisation » au sens courant et produit, pour désigner le fait que le réel ne quitte pas le serveur ; juridiquement, la donnée pseudonymisée reste une donnée à caractère personnel.

Pour aller plus loin

Cette mécanique constitue la partie aujourd’hui mesurée et prouvée de la couche de souveraineté de CLEVYA. Le composant qui se place devant vos appels d’IA est décrit sur la page Audit de clé API, l’ensemble des couches de sécurité sur la page Sécurité. Sur la distinction entre une promesse contractuelle et une preuve technique, voir Souveraineté IA : contrat vs preuve ; et sur ce qu’un agent doit garantir au-delà de la confidentialité, ce qu’il faut à un agent IA pour être fiable.

Vous vous demandez ce que cette mécanique donnerait sur vos propres données ? Parlez-nous de votre cas : on vous répond franchement, limites comprises.