Pourquoi la pseudonymisation locale protège mieux vos dossiers

La pseudonymisation locale change le risque avant toute IA : la pièce reste sur le poste, les identifiants deviennent des codes stables, la clé reste à part. Le modèle choisi ensuite ne voit que [PERS1] ou [ORG1], jamais le nom en clair. Ce n'est pas une question de slogan « hébergé près de chez vous ». C'est une question de qui lit le fichier pendant l'analyse. Lexanon traite le document en local, propose via Banco soit ce remplacement par codes, soit un caviardage, puis décode la réponse sur la machine.

Pseudonymisation et anonymisation : ne pas confondre

La pseudonymisation remplace un identifiant par un code. « Dupont » devient [PERS1]. « SAS Acme » devient [ORG1]. La même personne, la même société, gardent le même code sur toutes les pages et, si possible, sur toutes les pièces du dossier. Une table de correspondance, stockée à part, permet de revenir au clair. Tant que cette table existe, les données restent personnelles.

L'anonymisation, au sens fort, vise un résultat irréversible : personne ne doit pouvoir réidentifier, en pratique, par quelque moyen raisonnable. Dans un dossier contentieux, ce seuil est rarement atteint. Le contexte, les montants, les dates ou une clé restante suffisent souvent à retrouver la personne. Présenter un PDF « nettoyé » comme hors du règlement serait donc trompeur.

Le caviardage d'une pièce n'est pas non plus une pseudonymisation. Le caviardage masque (rectangle, biffure). La pseudonymisation remplace et conserve un fil utile pour relire le dossier ou interroger un modèle. Les deux opérations se choisissent au moment de l'analyse. Aucune ne garantit à elle seule une conformité. Le juriste reste responsable du contrôle final.

Pour les questions de méthode et de périmètre produit, le guide Lexanon et la FAQ complètent cette distinction sans la recycler ici.

Ce que change le traitement local

Le point décisif n'est pas le logo du fournisseur. C'est le lieu où le fichier est ouvert pour être analysé.

Dans un flux local, la pièce ne quitte pas la machine pour l'étape de détection et de remplacement. Les noms, adresses, numéros de sécurité sociale, parties adverses restent sur le poste pendant que Banco construit les codes. La table de correspondance reste chez le cabinet. Ensuite seulement, si le juriste le décide, un texte déjà traité peut être envoyé à un modèle via une clé API choisie par le cabinet (BYOK). Le modèle voit des codes. Lexanon décode la réponse en local. Le juriste relit du clair.

Dans un flux où le fichier brut part vers un service distant pour être « nettoyé », « détecté » ou « préparé » avant l'IA, le risque se déplace : un tiers reçoit le contenu nominatif pendant le traitement. Même si le serveur est en Europe, même si le marketing promet la souveraineté, le document a déjà quitté le périmètre du poste. Ce n'est pas le modèle qui lit d'abord. C'est le pipeline distant qui reçoit le clair pour le préparer.

La pseudonymisation locale n'élimine pas tout risque. Elle réduit la surface d'exposition avant toute interrogation d'IA. C'est une étape de préparation, pas une baguette magique. Sans cette pseudonymisation préalable, le premier destinataire du clair n'est plus le juriste : c'est le pipeline distant.

En pratique, le cabinet gagne aussi du temps de gouvernance. Au lieu de décider au cas par cas si un stagiaire peut coller un PDF dans un chat, la règle devient simple : aucune pièce nominative ne sort avant traitement. Le juriste choisit ensuite le modèle, la question et le niveau de détail. La pièce originale reste sur le poste. Les codes voyagent. La clé ne voyage pas.

Ce raisonnement rejoint aussi les freins d'adoption décrits dans pourquoi l'adoption des IA juridiques reste limitée : tant que le flux impose d'envoyer le dossier brut, beaucoup de cabinets restent à l'écart, ou basculent vers des usages non maîtrisés.

Le serpent : le nettoyage distant reçoit d'abord le clair

L'argument commercial le plus fréquent consiste à rassurer sur la suite du parcours : « l'IA ne verra que du texte déjà traité ». La question utile se pose plus tôt. Qui reçoit le dossier pour le préparer ?

Ce n'est pas le modèle qui lit d'abord. C'est le pipeline distant qui reçoit le clair pour le préparer. Autrement dit, le service de nettoyage, de détection d'identifiants ou de « PII redaction » devient le premier destinataire du contenu nominatif. Le serpent se mord la queue : on envoie le clair pour obtenir un fichier moins clair, en passant par un tiers qui lit justement ce que l'on voulait protéger.

Les documentations publiques des API cloud le disent sans détour.

Google Cloud Sensitive Data Protection (ex-DLP) propose des méthodes d'inspection et de dé-identification où le contenu à analyser est envoyé dans la requête API. Le fichier ou le texte transitent donc vers le service pour être inspectés ou transformés.

Azure AI Language, pour la détection et la rédaction de PII sur documents natifs, s'appuie sur un flux asynchrone : le PDF ou le DOCX est déposé côté stockage cloud (Blob), puis le service détecte et masque dans le cloud. La pièce part avant d'être « nettoyée ».

OpenAI, côté ChatGPT et API Files, stocke et traite les fichiers uploadés sur ses serveurs. Un prompt du type « pseudonymise avant de lire » ne change pas le fait que le fichier a déjà été transmis et traité à distance.

AWS Comprehend DetectPiiEntities reçoit également le texte en clair dans le paramètre Text de la requête. Même logique : détection distante sur contenu transmis.

Une intégration IA qui « upload » la pièce pour la préparer n'échappe pas à ce schéma. Même avec une instruction de pseudonymisation dans le prompt, le prestataire distant a déjà reçu le dossier en clair. Le prompt ne remonte pas le temps. Il ne retire pas le fichier des serveurs qui viennent de le traiter. Demander une pseudonymisation après upload, c'est encore confier le nominatif au cloud.

La pseudonymisation sur le poste coupe ce serpent. La détection et le remplacement ont lieu avant toute sortie. Ce qui peut éventuellement partir vers un modèle n'est plus le nominatif brut, mais un texte déjà codé, sous contrôle du cabinet. Le troisième niveau (quand le fichier est lu) devient alors le point de décision, plutôt qu'une étape marketing oubliée.

Autrement dit : promettre un résultat « nettoyé » après un envoi du clair, c'est inverser l'ordre des opérations. Le juriste qui veut réduire le risque commence par traiter localement. Il choisit ensuite, s'il le veut, un modèle via BYOK. Il ne confie pas d'abord le dossier à un pipeline distant pour que celui-ci « prépare » ce qu'il ne devait pas voir.

La table de correspondance, pièce maîtresse

Sans table, un code [PERS1] n'est qu'un alias opaque. Avec table, la pseudonymisation reste réversible pour celui qui détient la clé. C'est exactement ce qui la distingue d'une suppression définitive d'identifiants.

Une table utile tient plusieurs propriétés.

Cohérence : la même entité reçoit le même code partout. Sinon le modèle (et le juriste) perdent le fil du dossier. « Dupont » page 2 et « M. Dupont » page 17 doivent converger vers [PERS1] si c'est la même personne.

Séparation : la table n'est pas collée dans le PDF exporté vers l'IA. Elle reste à part, chez le cabinet, sous le contrôle du poste.

Catégories lisibles : personnes, organisations, lieux, identifiants techniques. Le choix des catégories dépend du type de pièce. Un contrat commercial n'a pas les mêmes priorités qu'une pièce pénale.

Contrôle humain : aucun moteur ne garantit l'exhaustivité. Une signature manuscrite, un tampon, un en-tête d'e-mail ou une métadonnée peuvent encore identifier. La relecture reste obligatoire avant transmission.

Dans Lexanon, cette table accompagne le mode pseudonymisation. Le mode caviardage, lui, masque sans produire le même type de fil narratif. Les deux passent par Banco au moment de l'analyse. Le cabinet choisit selon la destination : partage humain où le masquage suffit, ou préparation IA où les codes gardent la structure.

Sur un lot de pièces, la stabilité des codes devient critique. Si chaque fichier invente sa propre numérotation, le modèle croit voir dix personnes là où le dossier n'en compte qu'une. Une pseudonymisation cohérente sur l'affaire évite cette dérive. Le juriste peut fusionner, corriger et valider avant export.

Comment Lexanon orchestre le flux

Lexanon est un logiciel de bureau. L'analyse des pièces se fait en local. Le document ne quitte pas la machine pour cette étape.

À l'analyse, via le moteur Banco, le cabinet choisit :

1. la pseudonymisation : remplacement par codes du type [PERS1], [ORG1], avec clé à part ;
2. ou le caviardage : masquage des zones concernées.

Les deux options passent par Banco. Ce n'est pas « notre IA cloud » qui lit le dossier. C'est un moteur embarqué sur le poste. Les données restent personnelles. Lexanon ne prétend pas les faire sortir du règlement. Lexanon ne garantit pas non plus une conformité automatique.

Ensuite seulement vient le mode BYOK. Le cabinet fournit sa propre clé API vers le modèle qu'il a choisi. Le prompt part déjà traité. Lexanon décode la réponse sur le poste. Le juriste lit du clair, contrôle, décide.

Tarifs publics : 450 € HT par an, ou 45 € HT par mois, essai de 7 jours. Contact : [email protected].

Ce flux répond à une contrainte simple : réduire le risque avant toute IA grâce à une pseudonymisation ou un caviardage locaux, sans interdire l'usage des modèles, et sans confondre pipeline distant de « préparation » et lecture réelle du fichier en local.

FAQ

La pseudonymisation locale suffit-elle à sortir du RGPD ?

Non. La pseudonymisation réduit certains risques. Elle ne rend pas les données anonymes tant qu'une clé, un contexte ou des éléments réidentifiants existent. Le cabinet reste responsable du traitement et de la décision de transmission. Un outil accélère la détection. Il ne délivre pas de certificat de conformité.

Pourquoi traiter en local avant d'envoyer un texte à une IA ?

Parce que l'étape dangereuse est souvent la première lecture du fichier brut. Si cette lecture a lieu sur le poste, le modèle distant ne reçoit que des codes. La pseudonymisation prépare ce texte. Le décodage de la réponse se refait ensuite en local, sous le contrôle du juriste.

Un service distant de nettoyage / détection reçoit-il mon dossier en clair ?

Oui, dans le schéma habituel des API cloud de détection ou de rédaction PII : le contenu part dans la requête ou via un dépôt cloud avant traitement. Le service distant lit donc le clair pour « préparer » le fichier. Une pseudonymisation locale évite cet envoi préalable. Le pipeline ne reçoit pas ce qu'il n'aurait pas dû voir.

Lexanon fait-il de la pseudonymisation ou du caviardage ?

Les deux, au moment de l'analyse, via Banco. Soit remplacement par codes stables, avec clé à part. Soit masquage des zones concernées. Le choix dépend de la destination du fichier : partage humain, ou préparation d'une interrogation d'IA en mode BYOK.

Que devient la table de correspondance ?

Elle reste chez le cabinet, séparée du texte envoyé au modèle. Sans elle, on ne revient pas au clair de façon contrôlée. Avec elle, la pseudonymisation reste réversible pour le détenteur de la clé. Lexanon décode ensuite les réponses sur le poste.

Conclusion

La pseudonymisation locale ne promet pas l'impossible. Elle change l'ordre des opérations : d'abord la pseudonymisation de la pièce sur le poste, ensuite seulement choisir un modèle. Les codes stables gardent le fil du dossier. La clé reste à part. Le caviardage reste disponible quand le masquage suffit. Lexanon orchestre ce choix via Banco, en local, avec décodage des réponses sur la machine.

Ce n'est pas le modèle qui lit d'abord. C'est le pipeline distant qui reçoit le clair pour le préparer. Traiter en local coupe ce serpent. Pour approfondir la différence entre masquage et codes, voir le caviardage des documents d'avocats. Pour le contexte d'adoption, voir pourquoi l'adoption des IA juridiques reste limitée. Méthode et questions produit : guide et FAQ.

Avertissement. Cet article fournit une information générale sur la pseudonymisation de documents juridiques et le traitement local. Il ne constitue pas un conseil juridique personnalisé. Le cabinet reste responsable de l'analyse de chaque pièce et de la décision de transmission.