Observez un avocat, un comptable ou un clinicien aux prises avec une IA sur un dossier réel. Ce que les outils d'anonymisation ont tous laissé passer saute alors aux yeux : personne ne travaille en une seule passe. On pose une question, on lit la réponse, on enchaîne avec une relance plus précise, on colle un deuxième document, on revient au premier. Le travail, c'est la conversation. Or presque toutes les façons de masquer les données personnelles se brisent en silence dès que cette conversation démarre.
Cette observation explique à elle seule la forme qu'a prise promptShield. Nommons donc l'idée clairement, car à notre connaissance personne d'autre n'a bâti son produit autour d'elle. L'anonymisation stable en conversation : une même entité conserve un même code, d'un bout à l'autre de la conversation et à travers chaque fichier lié, de sorte que l'IA raisonne sur le document protégé comme elle le ferait sur le vrai et que vous puissiez en restaurer fidèlement les valeurs réelles à la fin.
Le travail se fait en plusieurs tours : la protection doit suivre
Prenons la tâche dans sa version réaliste. Vous avez un contrat et ses trois avenants. Vous collez le contrat, anonymisé, et demandez au modèle de résumer les obligations ; il s'en acquitte. Vous collez ensuite un avenant et demandez : « Cela modifie-t-il les conditions de paiement de l'acheteur par rapport à l'original ? » Puis : « Rédige une clause qui résout le conflit entre l'article 4 de l'un et l'article 7 de l'autre. »
Pour que cela produise quoi que ce soit d'utile, le modèle doit savoir que l'« acheteur » du contrat et l'« acheteur » de l'avenant sont la même personne morale, que l'adresse de l'article 4 est celle déjà évoquée trois tours plus tôt, que « le défendeur » et « Mme Laurent » forment une seule partie et non deux. La coréférence, ce fil d'identité qui traverse tout l'échange, fait la substance même du raisonnement professionnel : rompez-la, et la réponse de l'IA devient fausse avec aplomb, d'une manière qu'il est même difficile de repérer.
Une anonymisation qui traite le document comme « une chose à nettoyer une bonne fois pour toutes » ne voit rien de cela. Elle lave le fichier et le rend. Or le professionnel n'a pas un fichier ; il a une affaire, un dossier, un client : un ensemble de pièces liées sur lesquelles il raisonne ensemble, en dialogue, dans la durée. C'est la conversation qui est l'unité de travail, pas le document.
Pourquoi les approches évidentes s'effondrent
Dès lors que l'on formule la tâche comme « garder l'identité cohérente sur toute une conversation », les techniques habituelles se révèlent inadaptées :
| Approche | Ce qu'elle fait | Pourquoi la conversation la met en défaut |
|---|---|---|
| Le caviardage au marqueur | Recouvre le texte sur la page | Le modèle ne peut pas raisonner sur ce qu'il ne voit pas : plus aucun « l'acheteur » ne renvoie à quoi que ce soit |
| La suppression des noms | Retire purement et simplement l'entité | Des personnes distinctes se confondent dans le même vide, et le modèle invente discrètement quelqu'un pour le combler |
| Une étiquette neuve à chaque passage | Génère un nouveau pseudonyme à chaque exécution | Le deuxième tour renomme tout le monde : une personne en devient deux, et rien ne signale la contradiction |
| Le rechercher-remplacer | Fait correspondre une graphie à une chaîne | Rate les formes fléchies, les initiales et les alias, et ignore tout du deuxième document que vous collez |
| La tokenisation document par document | Des codes stables, mais à l'intérieur d'un seul fichier | Un contrat et son avenant attribuent deux codes différents à la même partie : le raisonnement croisé échoue en silence |
Le schéma se répète à chaque ligne : chaque approche convient pour assainir un bloc de texte unique, et chacune échoue dès que le travail devient une conversation. Elles ont été conçues pour une autre unité de travail que celle dont disposent réellement les professionnels.
Ce qu'exige l'anonymisation stable en conversation
Nommer la lacune est facile ; la combler suppose de vraies exigences, et ce sont elles qui en font un produit plutôt qu'une macro de rechercher-remplacer.
Une identité stable. Une même entité doit correspondre à un même code chaque fois qu'elle apparaît : pas seulement au sein d'un document, mais sur toute la conversation et dans chaque fichier lié. Dans promptShield, « John Smith » reçoit le même code (disons [P0ABCD]) qu'il figure dans le contrat, la facture ou la pièce jointe au courriel, parce que les fichiers liés partagent un même registre de codes. Déposez-les dans le même dossier : la liaison se fait d'elle-même, sans aucune configuration.
Des codes typés. Un code, c'est [P0ABCD], [A1WXYZ], [B2KLMN] : la première lettre en indique le type (P pour personne, A pour adresse, B pour IBAN), pour que le modèle sache toujours qu'il raisonne sur une personne, une adresse ou un compte, et qu'il puisse produire une réponse utile plutôt que de buter sur du charabia. Une consigne jointe au téléchargement demande à l'IA de restituer les codes tels quels. La structure qui aide l'IA est préservée ; seule l'identité est masquée.
Un aller-retour fidèle. Masquer l'identité n'est que la moitié du travail. La table qui ramène chaque code à sa valeur d'origine est conservée en local, de sorte que, lorsque la réponse de l'IA revient pleine de [P0ABCD] et de [B2KLMN], vous la décodez en une étape et obtenez un résultat qui se lit comme si vous n'aviez jamais rien anonymisé. Ce sont les codes stables qui rendent ce décodage sans ambiguïté : un code, une valeur d'origine, à chaque fois.
Réunies, ces trois exigences donnent la propriété qui compte : l'IA travaille sur le document protégé comme elle le ferait sur le vrai. Même raisonnement, mêmes renvois croisés, même cohérence sur plusieurs tours, sans qu'aucune identité réelle n'apparaisse jamais dans la conversation, et avec une restauration propre à la fin.
La boucle, de bout en bout
En pratique, c'est une seule boucle continue, et elle épouse le rythme du travail réel au lieu de l'interrompre :
- Encoder. Chaque entité est remplacée par un code stable et typé ; les fichiers liés partagent le registre ; un humain passe en revue les détections avant que quoi que ce soit ne soit validé. (Sur les documents à fort enjeu, c'est précisément là que cette relecture humaine prend tout son sens : voir pourquoi un humain reste dans la boucle.)
- Converser. Collez la version protégée dans ChatGPT, Claude ou n'importe quel modèle, enchaînez les relances, ajoutez d'autres pièces du même dossier, revenez en arrière. Les identités restent cohérentes aussi longtemps que dure la conversation, parce que les codes ne dérivent pas.
- Décoder. Ramenez la sortie de l'IA et restaurez chaque code à sa valeur réelle en une étape : vous obtenez un document final qui se lit comme si les vrais noms y avaient figuré depuis le début.
Comme toute la boucle s'exécute sur votre machine, aucune partie du dossier (ni les originaux, ni la table des codes, ni un seul tour du texte protégé de la conversation) ne quitte jamais votre périmètre.
La catégorie que nous revendiquons
Quantité d'outils savent masquer un nom. Certains savent même le masquer de façon cohérente si vous les configurez pour cela. Ce qui manque sur le marché n'a donc rien à voir avec la capacité prise isolément : il manque un produit conçu autour de la façon dont les professionnels travaillent réellement avec l'IA, de manière itérative, d'un tour à l'autre, à travers des fichiers liés, avec un humain qui se porte garant du résultat et un aller-retour propre à la fin. C'est le flux de travail pour lequel promptShield est pensé de fond en comble, et c'est l'idée à laquelle nous aimerions donner un nom.
Appelons cela l'anonymisation stable en conversation. Une entité, un code, d'un bout à l'autre, pour que vous puissiez enfin utiliser l'IA sur les documents qui comptent de la manière dont vous y pensez déjà : non pas comme des fichiers à nettoyer, mais comme un dossier à traiter.
Questions fréquentes
Pourquoi le même nom doit-il porter le même code à chaque fois ?
Parce qu'un professionnel n'anonymise pas en une passe. Il relance, colle un second document, raisonne sur les deux. Si la même personne reçoit un code différent à chaque tour, l'IA croit avoir affaire à deux personnes distinctes.
Que perd-on si les codes changent d'un document à l'autre ?
Le raisonnement croisé. Un contrat et son avenant cessent de désigner la même partie, et toute conclusion tirée des deux se révèle fausse. C'est pourquoi le caviardage réversible conserve un code stable par entité plutôt qu'une étiquette neuve à chaque exécution.
La table de correspondance est-elle stockée en ligne ?
Non. Le registre code-valeur reste sur la machine qui l'a créé : la même décision de conception que celle qui nous a fait écrire le moteur dédié à ce travail précis.