Comprendre l'anonymisation
Comment Zeuslock réécrit les valeurs sensibles en faux structurellement valides pour que l'IA reste utile, sans que l'original ne quitte jamais votre poste.
Les trois modes de politique, en une minute
Chaque détecteur de Zeuslock fonctionne dans l'un des trois modes, et vous pouvez les combiner par type de donnée. Monitor laisse passer le prompt et journalise la détection pour l'équipe sécurité. Anonymiser réécrit la valeur sensible avant l'envoi : l'IA ne voit jamais la donnée réelle mais reçoit tout de même une question exploitable. Bloquer arrête le prompt et vous explique pourquoi.
Cet article porte sur le mode intermédiaire, parce que c'est celui qui suscite le plus de questions. Monitor est invisible. Bloquer est évident. Anonymiser, lui, travaille discrètement.
Ce que fait réellement l'anonymisation
Quand Zeuslock détecte une valeur sensible dans votre prompt, il ne la supprime pas et n'y colle pas une balise générique [MASQUÉ]. Cela ferait répondre l'IA n'importe comment, ou la pousserait à refuser. À la place, Zeuslock remplace la valeur par un faux structurellement valide : une chaîne qui ressemble et se comporte comme l'original, mais sans la partie secrète.
Concrètement, cela signifie :
- La nouvelle valeur conserve le même format, la même longueur et les chiffres de contrôle quand ils comptent.
- Le contexte non sensible (préfixe pays, marque, 4 derniers chiffres) est préservé pour que l'IA puisse encore raisonner dessus.
- Les octets vraiment secrets — le numéro de carte, la clé API, les chiffres du téléphone — disparaissent.
Exemples
| Type | Original | Anonymisé | Pourquoi cette réécriture |
|---|---|---|---|
| Carte bancaire | 4111-1111-1111-1111 | 4xxx-xxxx-xxxx-1111 | La clé de Luhn reste valide, la marque reste déductible du 4 initial, les 4 derniers chiffres servent au service client. |
| alice@acme.com | user@example.com | Forme d'e-mail valide, aucune identité réelle, aucun domaine réel. | |
| Clé d'accès AWS | AKIAIOSFODNN7EXAMPLE | AKIA**************** | Le préfixe est conservé pour que l'IA sache qu'il s'agit d'une clé AWS, l'entropie secrète est supprimée. |
| IBAN | FR76 3000 6000 0123 4567 8901 234 | FR76 XXXX XXXX XXXX XXXX XXXX XXX | Code pays et préfixe banque préservés, chiffres du compte détruits. |
| Téléphone | +33 6 12 34 56 78 | +33 6 XX XX XX XX | Indicatif pays et opérateur conservés, chiffres de l'abonné détruits. |
Pourquoi on parle de format-préservant
L'intérêt de garder le préfixe, la longueur et la somme de contrôle, c'est que l'IA peut encore répondre à des questions au sujet de la valeur sans jamais voir la valeur elle-même. Si vous demandez à ChatGPT « de quel pays vient cet IBAN ? », la version anonymisée répond toujours « France » — parce que FR76 est resté. Si vous demandez à Claude de rédiger un e-mail de remboursement qui mentionne « la carte se terminant par 1111 », ça fonctionne — parce que les 4 derniers chiffres sont restés.
L'anonymisation n'est donc pas une perte d'utilité. C'est l'inverse d'un gros rectangle noir sur l'écran. Votre prompt continue de marcher ; seul le secret ne voyage pas.
L'aperçu avant envoi
L'anonymisation n'est jamais silencieuse. Avant qu'un prompt réécrit ne quitte votre navigateur ou votre agent desktop, Zeuslock affiche une fenêtre d'aperçu avec le texte exact qui va être envoyé. Vous voyez, sous-chaîne par sous-chaîne, ce qui a été remplacé. Vous pouvez annuler, modifier le prompt, ou confirmer.
Ce mécanisme a deux vertus. Il instaure la confiance — vous savez toujours ce que l'IA a vu. Et il forme l'utilisateur : après quelques aperçus, vous repérez naturellement les valeurs que vous étiez sur le point de divulguer.
Ce qui n'est pas anonymisé
Seules les valeurs détectées sont réécrites. Le texte autour reste intact. Un prompt comme :
Mon client chez acme.com a payé avec 4111-1111-1111-1111 hier, peux-tu me rédiger un e-mail de remerciement ?
devient :
Mon client chez user@example.com a payé avec 4xxx-xxxx-xxxx-1111 hier, peux-tu me rédiger un e-mail de remerciement ?
L'intention du prompt est préservée. L'IA rédige l'e-mail. Ni le numéro de carte ni l'e-mail du client ne quittent votre poste.
Unidirectionnel et local
L'anonymisation est à sens unique. La valeur sensible originale n'atteint jamais le fournisseur LLM, et elle n'atteint pas non plus les serveurs de Zeuslock. La correspondance entre valeur réelle et valeur factice ne vit que dans votre navigateur ou agent desktop, le temps du prompt, puis elle est jetée. Aucune table de réversibilité, ni de notre côté ni d'aucun autre.
Quand l'anonymisation ne suffit pas
L'anonymisation excelle sur les valeurs à structure claire : cartes, clés, IBAN, e-mails, téléphones. Elle fonctionne moins bien pour deux catégories de contenu :
- Le code source. Une fonction propriétaire est sensible en tant que tout — on n'anonymise pas « l'algorithme secret » en renommant les variables. Pour le code, utilisez Bloquer, ou une politique d'organisation qui ne route le code que vers les outils homologués.
- Le texte propriétaire libre. Notes de stratégie internes, détails produit non publiés, prose confidentielle client. Ici, la sensibilité est dans le sens, pas dans un jeton. Bloquer est la bonne réponse.
Le déploiement recommandé reste valable : Monitor pendant les deux premières semaines pour observer ce qui circule, puis Anonymiser pour tout ce qui a une réécriture exploitable, et réserver Bloquer aux catégories où aucune réécriture sûre n'existe.