Carnet de fabrication

Pourquoi un outil d'anonymisation ne doit jamais masquer un article de loi

Parce qu'un article de loi n'identifie personne et qu'il fait fonctionner la clause qui le cite. Remplacer « L. 441-10 » ou « Tribunal de commerce de Marseille » par une balise ne protège aucune donnée, rend le contrat inutilisable pour l'IA comme pour l'avocat, et montre que l'outil ne comprend pas ce qu'il lit. Nous l'avons appris sur notre propre moteur.

Par Florent Lable · publié le · 4 min de lecture

Cette page raconte une erreur de notre moteur, et ce que nous en avons tiré. Nous la publions parce que la question qu'elle pose vaut pour tout outil d'anonymisation, et que c'est la première chose qu'un avocat devrait vérifier avant d'en adopter un.

Que s'est-il passé ?

Le 20 septembre 2026, nous avons fait tourner pour la première fois la détection réelle sur notre contrat de test, un contrat de prestation fictif de neuf articles. Nous surveillions les fuites : il n'y en avait aucune. Le défaut était l'inverse. Le moteur avait trouvé 42 éléments à masquer, dont sept qui n'avaient rien à faire là :

  • « l'article L. 441-10 du Code de commerce », dans la clause de pénalités de retard ;
  • « Tribunal de commerce de Marseille », dans la clause attributive de juridiction ;
  • des nombres : « douze (12) mois », « trente (30) jours », « quinze », « cinq ».

Le contrat anonymisé lisait « … prévue à l'article {{DONNEE_5}} du Code de commerce » et « Tout litige […] sera soumis au {{LIEU_2}} ».

Pourquoi est-ce grave, et pas seulement gênant ?

Un faux positif ordinaire coûte un peu de lisibilité. Celui-là abîme le sens juridique du document :

  • Il ne protège rien. Un article de loi, une juridiction, une durée ne désignent aucune personne.
  • Il rend la clause inopérante. Une clause de pénalités qui renvoie à un article inconnu, une clause attributive qui ne nomme plus de tribunal : l'IA à qui l'on demande d'analyser le contrat ne peut plus raisonner dessus, et risque d'inventer.
  • Il détruit la confiance. Une avocate voit l'erreur en trois secondes et en tire, à juste titre, une conclusion sur tout le reste : l'outil ne comprend pas ce qu'il lit.

Pourquoi une consigne au modèle ne suffisait pas ?

C'est le point le plus instructif. La consigne donnée au modèle de détection interdisait déjà de masquer les articles de loi. Il l'a fait quand même. Un modèle de langage suit ses consignes la plupart du temps, pas toujours ; et sur un contrat, « la plupart du temps » veut dire qu'un article sur vingt ressortira masqué.

D'où la règle que nous suivons désormais : quand une erreur abîme le document, la protection ne doit pas dépendre du modèle. Nous avons ajouté, après la détection, un filtre déterministe — du code classique, qui se comporte toujours de la même façon et que l'on peut tester.

Quelle règle avons-nous retenue ?

Un principe : l'anonymisation ne doit jamais altérer le fonctionnement juridique du contrat. Ce qui identifie une partie s'en va ; ce qui fait tourner la mécanique juridique reste. Concrètement, restent en clair :

  • les citations de textes : articles de code, lois, décrets et ordonnances numérotés, textes de l'Union ;
  • les notions légales nommées : « taux d'intérêt légal », indices de révision des loyers ;
  • les juridictions ;
  • les durées et les quantièmes ;
  • les qualités (Présidente, Gérant). Ce dernier point se discute : une fonction peut identifier quelqu'un par recoupement dans une petite structure. Nous la laissons en clair par défaut et le rapport le signale.

Surtout, tout ce qui est laissé en clair est affiché dans le rapport, avec son motif. Un outil qui décide de ne pas masquer doit dire pourquoi : c'est ce qui permet de vérifier son raisonnement plutôt que de lui faire confiance.

Sur le même contrat, le résultat est passé de 42 éléments masqués à 26, et de sept faux positifs à zéro, sans aucune fuite.

Quels pièges avons-nous rencontrés en corrigeant ?

Deux, trouvés par les tests et non à la relecture :

  1. Le SIREN qui se faisait passer pour un article. La première version de la règle reconnaissait une citation à sa forme numérique. Elle aurait pris « 842137655 » pour un numéro d'article et laissé un SIREN en clair. La règle exige désormais une marque explicite : la lettre du livre (L., R., D.) ou le mot « article ». Laisser un « 441-10 » nu masqué est un défaut cosmétique ; laisser fuiter un SIREN n'en est pas un. Entre les deux erreurs, nous choisissons toujours celle qui ne fuit pas.
  2. La date qui appartenait à la loi. Le 28 septembre, un nouveau cas : « la loi du 31 décembre 1971 » ressortait en « la loi du {{DATE_3}} », parce que le détecteur de dates voyait une date, sans voir qu'elle faisait partie d'une citation. La règle juge désormais l'élément dans son contexte : si toutes ses apparitions tombent dans une citation, il reste en clair ; s'il apparaît une seule fois ailleurs, il est masqué partout. La date de signature reste donc masquée, même quand elle coïncide avec celle d'un décret cité.

Que vérifier sur n'importe quel outil ?

Soumettez-lui un contrat qui cite des articles de code, une loi datée, une juridiction et des délais, puis regardez le résultat :

  • les références aux textes sont-elles intactes ?
  • la juridiction compétente est-elle lisible ?
  • les délais se lisent-ils encore ?
  • l'outil vous dit-il ce qu'il a laissé en clair, et pourquoi ?

Si l'une des réponses est non, l'outil masque par excès de prudence. C'est moins dangereux qu'une fuite, mais le document que vous confierez à l'IA ne dira plus ce que dit le contrat.

Ce que cette page ne couvre pas. Les chiffres cités ont été mesurés sur un seul contrat fictif. Ils illustrent un défaut et sa correction ; ils ne constituent pas une mesure de performance sur des documents réels, qui ne sera établie qu'à l'occasion d'un pilote avec un cabinet.

Voir ce que Caviardeur produit sur un vrai contrat

Un contrat fictif, anonymisé par le moteur réel : le document avant et après, la table de correspondance, et ce que l'IA reçoit.

Voir la démonstration