Pourquoi anonymiser des documents juridiques pour l'IA est (vraiment) difficile

Avant qu'un document juridique puisse être analysé par une IA générative, il doit être débarrassé de toute donnée identifiante : noms des parties, adresses, numéros de sécurité sociale, IBAN, numéros SIREN/SIRET... C'est la première étape de notre pipeline, et c'est celle qui protège vos clients avant même qu'une seule requête ne parte vers un modèle de langage.

Sur le papier, ça ressemble à une tâche de reconnaissance d'entités assez classique. En pratique, nous avons passé plusieurs semaines à démontrer que non.

Le problème n'est pas "trouver un nom", c'est "trouver tous les noms"

Un modèle de détection d'entités généraliste repère facilement "Maître Dubois" la première fois qu'il apparaît. Le vrai défi arrive ensuite : dans un jugement de 8 pages, cette même personne sera souvent citée à nouveau sous la forme "Dubois" seul, ou "M. Dubois", sans plus jamais son prénom complet. Un modèle qui ne fait le lien qu'avec le nom complet laisse fuiter toutes ces occurrences partielles.

Nous avons mesuré ce phénomène précisément sur notre jeu de test interne : la majorité des occurrences manquées d'un nom de personne étaient exactement ce cas — une référence partielle à une entité déjà détectée ailleurs dans le même document. La solution n'était pas "plus de données d'entraînement", mais un mécanisme de propagation : une fois qu'un nom complet est détecté, chacun de ses composants (nom, prénom) est recherché activement dans le reste du texte. Ce correctif seul a fait franchir à notre système un seuil de fiabilité qu'aucun ajustement du modèle n'avait réussi à atteindre.

Les organisations n'apparaissent pas de la même façon partout

Un contrat commercial et une décision de justice ne parlent pas des organisations de la même manière. Un modèle entraîné majoritairement sur des données d'entreprise (marchés publics, immatriculations, annonces légales) devient excellent pour détecter "SARL Dupont Construction" dans un contrat — et beaucoup moins fiable face à la façon dont une organisation est mentionnée dans un jugement du tribunal judiciaire.

Nous avons découvert que ce déséquilibre venait directement de la composition de nos données d'entraînement : elles couvraient bien le droit des affaires, mais quasiment aucune décision de justice réelle. Le correctif a été double : aller chercher davantage de décisions de justice réelles auprès de sources publiques (Judilibre), et découper les documents longs en fenêtres de texte qui respectent la limite technique du modèle plutôt que de les tronquer silencieusement.

Les faux positifs coûtent aussi cher que les faux négatifs

Un détecteur trop agressif abîme le document autant qu'un détecteur trop timide le laisse fuiter. Nous avons découvert un bug révélateur : lorsqu'un numéro de TVA et un numéro de sécurité sociale ont exactement la même longueur de caractères et se chevauchent dans le texte, notre logique de fusion des détections choisissait arbitrairement l'un des deux labels — parfois le mauvais. Le correctif : en cas d'égalité, la détection la plus fiable (une expression régulière validée, pas une prédiction de modèle) doit toujours l'emporter pour les catégories structurées comme les IBAN ou les numéros de TVA.

Ce genre de bug ne se voit pas dans un test rapide. Il ne se révèle qu'avec une méthodologie de test rigoureuse — documents réels, catégories croisées, et analyse individuelle de chaque erreur plutôt qu'un score global rassurant.

Ce que ça change concrètement

Après plusieurs cycles d'entraînement, de mesure et de correction, notre système de détection atteint aujourd'hui, sur notre jeu de test interne de plusieurs milliers d'entités annotées :

• 85,5 % de rappel sur les personnes physiques (+19 points par rapport au modèle générique de départ)
• 95,7 % de rappel sur les organisations
• 95,7 % de rappel sur les données structurées (IBAN, numéros de TVA, identifiants d'entreprise)

Ces chiffres ne viennent pas d'un seul ajustement magique, mais d'une méthode : mesurer précisément où le système échoue, comprendre pourquoi plutôt que d'ajouter aveuglément des données, et corriger la cause réelle — qu'elle soit dans le modèle, dans les données, ou dans le code de production.

Vous voulez le détail technique complet — l'entraînement du modèle, les hypothèses testées et rejetées, les chiffres de chaque itération ? Nous avons écrit le récit d'ingénierie complet pour ceux qui veulent creuser.