Points à régler

En bref

• Cette page suit les décisions prises sur les besoins et ce qu'il reste à faire pour les tenir.
• Chaque point cite le besoin concerné, comme DPO-10 ou OPS-6.
• Ce qui est fait n'est pas listé ici. Le besoin et ses tests d'acceptation le montrent, et l'historique git garde le détail.

Décidé, à faire

Décidé le 2 octobre 2026.

• DPO-10 DPO-10 Besoins par profil 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. : concevoir l'export des validations humaines, vers Langfuse par exemple. Trois formes seront au choix, les jetons à la place des valeurs, les valeurs en clair, ou l'entrée et la sortie entièrement masquées. La forme par défaut est les jetons.
• OPS-6 OPS-6 Besoins par profil 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. : accepter les configurations à modèle sur le catalogue. Leur refus actuel est temporaire. Il faut un format qui répartit les labels entre les motifs et le modèle, parce que chaque modèle NER est plus fort sur certains labels.

Proposé, pas encore tranché

Ces propositions ajoutent des critères à des besoins existants. Chaque critère décrit un comportement que des tests vérifient déjà. Il reste à décider s'il entre dans le texte du besoin.

• DPO-1 DPO-1 Besoins par profil 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. : ajouter deux critères.
  • Aucune valeur ne repart en clair vers le modèle, ni aux tours suivants de la conversation, ni dans un message découpé en plusieurs blocs, ni dans l'argument d'un appel d'outil.
  • Un jeton que l'utilisateur tape lui-même, comme <<PERSON:2>>, ne fait pas apparaître la valeur d'une autre personne.
• OPS-4 OPS-4 Besoins par profil 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. : ajouter deux critères.
  • Le serveur piighost-api refuse de démarrer si une clé d'API est mal formée, sauf si PIIGHOST_ALLOW_ANONYMOUS est activé.
  • Une route protégée appelée sans clé répond 401.