Aller au contenu

Besoins par profil

En bref

La documentation métier recense quatre profils qui ont besoin de la dé-identification, chacun pour une raison différente :

  • Le responsable conformité (DPO) : il veut qu'aucune donnée confidentielle ne sorte en clair.
  • Le développeur : il veut intégrer piighost sans réécrire son application.
  • L'exploitant : il veut le faire tourner en production.
  • L'utilisateur de l'application : il ne doit jamais s'en apercevoir.

Chaque besoin porte un identifiant en anglais, le même dans toutes les langues, de la forme DPO-n, DEV-n, OPS-n ou USER-n. Il donne des critères que vous pouvez constater, puis renvoie vers la page de la documentation métier qui le décrit en détail, avec son scénario et ses règles. Les tests d'acceptation de chaque besoin sont listés dans Tests d'acceptation.

Les points de vigilance, en fin de page, listent les réponses imprévues d'un modèle et le besoin qui les couvre. Les termes sont définis dans le glossaire.


Responsable conformité (DPO)

DPO-1  : En tant que DPO, je veux qu'aucune donnée personnelle ni aucun secret ne parte en clair vers le LLM, afin de rester conforme au RGPD et de ne pas exposer d'identifiants d'accès.

  • Le message « Écrivez à Jean Dupont, jean.dupont@exemple.fr » part vers le LLM sous la forme « Écrivez à <<PERSON:1>>, <<EMAIL:1>> ».
  • Une clé d'API collée dans un message part en jeton, dès qu'un groupe de secrets est configuré.
  • Voir Protéger un message et les points de vigilance. Tests : AT-DPO-1-….

DPO-2  : En tant que DPO, je veux choisir les types de données protégées, afin d'adapter la protection à mon activité.

  • Une configuration qui tire le groupe français du catalogue masque un IBAN et un numéro de sécurité sociale.
  • Un motif propre à l'entreprise, un numéro de dossier par exemple, s'ajoute en une ligne.
  • Voir Configurer un pipeline et Protéger un message. Tests : AT-DPO-2-….

DPO-3  : En tant que DPO, je veux forcer la protection d'une valeur, ou laisser en clair un terme public, sans attendre le détecteur, afin d'imposer la politique de l'entreprise.

  • Une valeur de la liste à masquer de la configuration (deny_list dans la section [override], dans l'application ou dans piighost-api) est masquée même si aucun détecteur ne la voit.
  • Un terme de la liste à laisser en clair (allow_list) de la même section reste en clair même quand un détecteur le relève.
  • Voir Imposer une liste à masquer et une liste à laisser en clair. Tests : AT-DPO-3-….

DPO-4  : En tant que DPO, je veux refuser un texte qui contient encore une donnée, afin qu'une détection manquée ne parte pas.

DPO-5  : En tant que DPO, je veux savoir où sont gardées les vraies valeurs et qu'elles soient chiffrées au repos, afin de maîtriser la pseudonymisation.

  • Avec une mémoire Redis chiffrée, la base ne contient ni « Jean Dupont » ni le message en clair.
  • Quand le chiffrement est configuré mais que ses secrets manquent dans l'environnement, le pipeline refuse de démarrer plutôt que de stocker en clair.
  • Voir Stocker les conversations et protéger les traces. Tests : AT-DPO-5-….

DPO-6  : En tant que DPO, je veux effacer une conversation sur demande, afin de répondre au droit à l'effacement.

  • Après l'effacement d'une conversation, restaurer son jeton <<PERSON:1>> le rend tel quel, sans « Jean Dupont ».
  • Le serveur d'API expose cet effacement sur une route.
  • Voir Suivre une conversation. Tests : AT-DPO-6-….

DPO-7  : En tant que DPO, je veux observer le pipeline sans que les traces contiennent les données, afin de prouver la protection.

DPO-8  : En tant que DPO, je veux documenter l'analyse d'impact, afin de justifier le traitement.

DPO-9  : En tant que DPO, je veux qu'un détecteur en panne bloque le message plutôt que de le laisser passer, afin qu'une panne ne devienne pas une fuite.

  • Quand le modèle d'un détecteur LLM rend une sortie illisible, le message doit être refusé avec une erreur au lieu de partir sans détection.
  • Un réglage explicite doit laisser passer le message, pour qui préfère la disponibilité à la protection.
  • Les hooks Claude Code doivent de même bloquer un prompt ou un appel d'outil quand le serveur ne répond pas, et remplacer une sortie d'outil par un avis.
  • Voir les points de vigilance et Points à régler. Tests : AT-DPO-9-….

DPO-10  : En tant que DPO, je veux choisir sous quelle forme les corrections humaines sont conservées, afin que leur stockage ne devienne pas une copie des données.

  • Une correction exportée vers un outil d'annotation, Langfuse par exemple, se conserve sous la forme choisie. Les formes possibles sont les jetons à la place des valeurs, les valeurs en clair, ou l'entrée et la sortie entièrement masquées.
  • Le développeur règle cette forme, le DPO la décide.
  • Sans choix explicite, la correction est conservée sous forme de jetons. L'export ne contient alors aucune valeur réelle.

Limite connue. Le choix de la forme n'existe pas encore dans le code.


Développeur

DEV-1  : En tant que développeur, je veux protéger les appels LLM de mon agent sans réécrire sa logique, afin d'ajouter la protection à un projet existant.

DEV-2  : En tant que développeur, je veux que la réponse soit restaurée automatiquement, afin de ne rien écrire pour remettre les vraies valeurs.

DEV-3  : En tant que développeur, je veux qu'une valeur garde le même jeton sur toute la conversation, afin que le LLM suive le fil.

  • « jean.dupont@exemple.fr » reste <<EMAIL:1>> trois messages plus tard.
  • Un jeton d'une conversation ne se restaure pas dans une autre, même si les deux ont émis <<PERSON:1>>.
  • Voir Suivre une conversation. Tests : AT-DEV-3-….

DEV-4  : En tant que développeur, je veux que mes outils reçoivent les vraies valeurs alors que le LLM ne voit que des jetons, afin que les actions s'exécutent.

  • Un outil appelé avec <<EMAIL:1>> reçoit « jean.dupont@exemple.fr », et son résultat repasse en jetons avant le LLM.
  • Voir Laisser un outil agir. Tests : AT-DEV-4-….

DEV-5  : En tant que développeur, je veux ajouter mes propres détecteurs ou valeurs, afin de couvrir un identifiant propre à mon métier.

  • Un motif écrit dans la configuration masque un numéro de commande « CMD-2024-0042 ».
  • Un détecteur maison se branche dans le pipeline sans toucher à la bibliothèque.
  • Voir Ajouter ou remplacer un composant. Tests : AT-DEV-5-….

DEV-6  : En tant que développeur, je veux décrire le pipeline dans un fichier et le valider en CI, afin de le faire relire sans lire de code.

  • La validation réussit sur une configuration correcte et échoue, en nommant la clé fautive, sur une faute de frappe.
  • Voir Configurer un pipeline. Tests : AT-DEV-6-….

DEV-7  : En tant que développeur, je veux tester mon intégration sans télécharger de modèle, afin d'avoir des tests rapides et reproductibles.

DEV-8  : En tant que développeur, je veux décider quoi faire d'un jeton que le LLM a inventé, afin qu'il n'arrive pas tel quel à l'utilisateur.

DEV-9  : En tant que développeur, je veux restaurer une réponse streamée au fil des morceaux, afin de l'afficher sans attendre la fin.

DEV-10  : En tant que développeur, je veux que chaque conversation soit nommée explicitement, afin que deux utilisateurs ne partagent jamais leurs jetons par accident.

DEV-11  : En tant que développeur, je veux choisir le sort d'une valeur que l'assistant introduit lui-même, afin de décider si le LLM garde ce qu'il sait d'elle.

  • Par défaut, « Napoléon », cité d'abord par l'assistant, reste en clair, même quand l'utilisateur le reprend ensuite.
  • Un réglage passe cette valeur en jeton, un autre n'analyse pas du tout les messages de l'assistant.
  • Voir Suivre une conversation. Tests : AT-DEV-11-….

Exploitant

OPS-1  : En tant qu'exploitant, je veux déployer une API de dé-identification partagée, afin que plusieurs applications utilisent un seul pipeline et un seul modèle.

OPS-2  : En tant qu'exploitant, je veux que la mémoire survive aux redémarrages et soit partagée entre instances, afin qu'une conversation ne perde pas ses jetons.

OPS-3  : En tant qu'exploitant, je veux fournir les secrets par l'environnement, afin qu'aucune clé ne soit écrite dans un fichier.

OPS-4  : En tant qu'exploitant, je veux protéger l'API par des clés, une taille de requête maximale et un débit, afin qu'elle ne soit ni ouverte ni abusée.

OPS-5  : En tant qu'exploitant, je veux traiter un long document sans que le modèle en tronque la fin, afin qu'aucune valeur en fin de texte ne parte en clair.

OPS-6  : En tant qu'exploitant, je veux charger une configuration relue depuis le catalogue par sa référence, afin de ne pas maintenir de copie locale.

  • Une référence épinglée sur un commit est téléchargée au premier démarrage, puis lue depuis le cache.
  • Une référence sans commit, qui peut changer, est relue à chaque chargement et jamais mise en cache.
  • Le catalogue n'est joint qu'en HTTP ou HTTPS, et une configuration du catalogue qui embarque un modèle est refusée.
  • Voir Configurer un pipeline. Tests : AT-OPS-6-….

Limite connue. Le catalogue ne sert pour l'instant que des groupes de motifs. Un modèle NER reconnaît mieux certains labels que d'autres. Répartir les labels entre motifs et modèle demande un format de configuration que le catalogue n'a pas encore.

OPS-7  : En tant qu'exploitant, je veux que la mémoire en processus soit bornée par défaut, afin qu'un serveur qui tourne des semaines ne garde pas toutes les valeurs qu'il a vues.


Utilisateur de l'application

Ce profil ne manipule jamais piighost. Il utilise l'application qu'un développeur a construite avec, et ses besoins disent ce que cette application doit lui garantir.

USER-1  : En tant qu'utilisateur, je veux lire la réponse avec mes vraies informations, afin de ne jamais voir de jeton.

Limite connue. Avec les hooks Claude Code, la réponse affichée dans Claude Code garde ses jetons, car aucun hook ne peut réécrire ce texte. Le proxy compatible Anthropic restaure, lui, la réponse.

USER-2  : En tant qu'utilisateur, je veux que la conversation reste cohérente de bout en bout, afin que l'assistant ne confonde pas deux personnes.

USER-3  : En tant qu'utilisateur, je veux que les actions de l'assistant utilisent mes vraies données, afin que l'e-mail parte à la bonne adresse.

Limite connue. Le proxy compatible OpenAI ne restaure pas les arguments d'un appel d'outil quand la réponse arrive en flux. Voir Dé-identifier un client OpenAI avec le proxy.

USER-4  : En tant qu'utilisateur, je veux voir la réponse s'afficher au fil de l'eau sans morceau de jeton, afin de la lire normalement.

USER-5  : En tant qu'utilisateur, je veux que les termes publics restent lisibles, afin que la réponse garde son sens.

USER-6  : En tant qu'utilisateur, je veux corriger une détection, ajouter un nom oublié ou rendre lisible un terme masqué à tort, afin que l'assistant reçoive le bon texte.


Points de vigilance

Un LLM peut mal répondre, qu'il serve de détecteur, de garde-fou ou de modèle de conversation, c'est-à-dire le modèle qui répond à l'utilisateur. Ces cas définissent ce que piighost doit faire, et le besoin qui le porte.

SituationCe que fait piighostBesoin
Le LLM détecteur rend une sortie illisible, un JSON cassé ou un champ manquantLe message est refusé avec une erreur, sauf si l'échec ouvert est demandéDPO-9
Le LLM garde-fou rend une sortie illisibleLe texte est refusé avec une erreur, sauf si l'échec ouvert est demandéDPO-9
Le LLM détecteur cite une valeur absente du texteLa valeur n'est retrouvée nulle part dans le texte et n'est pas retenueDPO-1
Le LLM détecteur oublie une valeurElle part en clair, sauf si un garde-fou relit le texteDPO-4
Le texte analysé contient une balise qui imite la zone de données du promptLa balise est neutralisée avant l'envoi au LLM détecteurDPO-1
Le modèle de conversation invente un jeton, <<PERSON:10>> alors que la conversation n'a que <<PERSON:1>>Refusé par défaut, retiré ou laissé selon la stratégieDEV-8
Le modèle de conversation change la casse ou les chiffres d'un jeton, <<Person:1>> ou <<PERSON:01>>Il n'est pas restauré, et il est traité comme un jeton inventéDEV-8
Le modèle de conversation abîme les délimiteurs d'un jeton, << PERSON:1 >> ou PERSON:1Il n'est ni restauré ni reconnu comme jeton, et l'utilisateur le lit tel quel. Aucune valeur ne fuit, et ce comportement est acceptéUSER-1
Le modèle de conversation devine la vraie valeur derrière un jeton et l'écritLa valeur est traitée comme introduite par l'assistantDEV-11
L'utilisateur tape lui-même un jeton, <<PERSON:2>>Il ne fait pas apparaître la valeur d'une autre personneDPO-1
Le flux de réponse s'arrête au milieu d'un jetonLe fragment est rendu tel quel, sans valeur réelleUSER-4
Le modèle de conversation coupe ou reformule un jeton dans un argument d'outilSeul un jeton écrit en entier est restauré, l'outil reçoit le reste tel quelDEV-4
Le serveur d'API est injoignable depuis les hooks Claude CodeLe prompt ou l'appel d'outil est bloqué, la sortie d'outil remplacée par un avis, sauf si l'échec ouvert est demandéDPO-9

Voir aussi

  • Processus, les scénarios complets avec leurs règles et leurs cas d'erreur.
  • Glossaire, les termes de la dé-identification.