Deux mémoires, pas une : préférences du juriste et doctrine de l'équipe

Le même agent de relecture contractuelle, une fois en usage quotidien, finit par entendre les mêmes remarques revenir. Imaginez-les ainsi : « Ne me propose pas de révision sur les clauses de confidentialité, on les traite à part. » « Tes formulations sont trop agressives, on négocie avec ces fournisseurs depuis longtemps. » « Sur ce type de contrat, une garantie à douze mois est acceptable même si le référentiel dit vingt-quatre. »

Ces phrases ne sont pas du bruit : c’est le métier. Le problème, c’est qu’elles disparaissent avec la session. Le lendemain, l’agent recommence à zéro et le juriste réexplique. Si rien ne change, il finit par arrêter d’expliquer et corrige à la main : l’outil reste ouvert, mais on ne s’en sert plus.

Pourquoi la recherche documentaire n’y répond pas

Le réflexe est d’ajouter une recherche documentaire (RAG) : indexer les échanges passés, retrouver les passages pertinents et les glisser dans le prompt, la consigne envoyée au modèle. Ça ne règle rien : elle répond à « que dit le référentiel ? », pas à « comment cette équipe travaille ».

Sur cet agent, il n’y a d’ailleurs aucune base vectorielle. Le référentiel tient en quelques dizaines de clauses et de scénarios de risque, fournis en entier au modèle à chaque audit ; côté conversation, l’agent n’a qu’une recherche par mots-clés dans ce même référentiel. Retrouver la bonne clause n’est pas le problème.

Ce qui manquait, c’était deux choses que le référentiel ne contient pas, et ne doit pas contenir :

Les préférences d’une personne : son style, son périmètre, ses habitudes. Elles n’ont aucune raison de s’appliquer aux autres.
La doctrine d’usage de l’équipe : ce que l’équipe a tranché au fil des audits, qui précise ou nuance le référentiel pour un contexte donné, sans en modifier le texte. Elle engage l’équipe, et doit donc être validée par quelqu’un.

Mélanger les deux dans une même mémoire, c’est garantir qu’une préférence personnelle finisse par peser sur l’audit d’un collègue.

Deux niveaux, deux prompts

L’agent a deux usages. L’audit passe un contrat au crible du référentiel et en tire des propositions de correction. Le chat est l’espace où le juriste retravaille ces propositions avec l’assistant. D’où l’architecture : deux mémoires distinctes, une par usage, aucun point de contact.

                     session de travail (chat)
                              │
    « retiens que… »          │        fin de session : récolte
    (outil remember_rule)     │        (1 appel au modèle, 6 propositions max)
                              ▼
          propositions  { action, section, texte, route, justification }
                              │
              ┌───────────────┴────────────────┐
  route =     │                                │   route = "clausier"
  "agent_md"  ▼                                ▼
  ┌──────────────────────────┐    ┌────────────────────────────┐
  │ MÉMOIRE DU JURISTE       │    │ RÈGLE CANDIDATE de DOCTRINE│
  │ 4 sections, 8 000 car.   │    │ statut : brouillon         │
  │ validée par lui, ligne   │    │ validée par un admin       │
  │ à ligne                  │    │                            │
  └────────────┬─────────────┘    └──────────────┬─────────────┘
               │                                 │
    injectée dans le prompt           injectée dans le prompt
    du CHAT, uniquement               de l'AUDIT, uniquement

Les deux flèches du bas ne se rejoignent jamais. Une règle rangée dans la mémoire personnelle ne pèse sur aucun audit ; une règle de doctrine validée ne change pas la façon dont l’assistant parle à son juriste. Aucun code n’a à arbitrer entre les deux : elles n’arrivent jamais dans le même prompt.

Corollaire : une règle personnelle n’est jamais « promue » vers l’équipe. Un « retiens que… » alimente toujours la mémoire personnelle. C’est la récolte de fin de session qui aiguille chaque proposition via le champ route, et l’agent peut aussi proposer une règle de doctrine en cours de session, directement en brouillon. Le test de tri, pour le modèle comme pour l’humain : est-ce que ça décrit votre façon de travailler, ou ce qui est acceptable dans un contrat ?

Le fichier n’est jamais écrit par le modèle

La mémoire personnelle n’est pas une base de données : c’est un simple fichier texte par juriste, découpé en quatre sections fixes, relu par l’agent au début de chaque session.

MEMORY_MAX_CHARS = 8000
MEMORY_COMPACTION_THRESHOLD = 0.8

MEMORY_SECTIONS = [
    "Style d'écriture",
    "Priorités & scope",
    "Patterns récurrents",
    "Dépendances entre règles",
]

MEMORY_ACTIONS = {"add", "modify", "remove"}
MEMORY_ROUTES = {"agent_md", "clausier"}

Deux décisions tiennent tout le reste.

Le modèle ne touche jamais au fichier. Il produit des propositions : une action, une section, un texte, une justification. Le juriste les coche, les édite ou les refuse, et c’est ensuite du code déterministe qui applique : add insère une ligne en fin de section, modify remplace la ligne contenant le texte visé, remove la supprime. Si le texte à remplacer est introuvable, l’opération échoue avec une erreur explicite. Aucune écriture à l’aveugle.

Il n’y a jamais de troncature silencieuse. Le budget est dur : 8 000 caractères. À 80 %, l’interface signale qu’il faut faire le ménage ; le seuil nommé compaction dans le code déclenche cette alerte, pas un nettoyage. Au-delà du budget, l’enregistrement est refusé. Aucun mécanisme ne décide à la place du juriste quelle règle vaut la peine d’être gardée.

La récolte de fin de session est un seul appel au modèle, réglé pour limiter la variabilité, qui lit deux choses : la conversation, et ce que le juriste a fait des propositions de l’audit. Une proposition ignorée renseigne sur son périmètre, une proposition retouchée sur son style, une proposition acceptée sur ses priorités. Consigne au modèle : généraliser. Une règle doit servir les prochaines sessions, pas décrire ce contrat.

Gouvernance : personne ne s’auto-valide

Le second niveau exige une vraie gouvernance : une règle validée pèse sur les audits des autres.

L’outil distingue trois statuts : utilisateur, qui lance des audits ; juriste, qui a en plus accès à l’assistant ; admin, qui valide la doctrine.

Proposer n’exige pas d’être admin. Tout juriste peut proposer une règle candidate, en cours de session ou lors de la récolte. Elle est créée en brouillon, et un brouillon n’est appliqué nulle part.
Valider est réservé au statut admin. Le contrôle est fait par le serveur : masquer un bouton dans l’interface ne suffirait pas.
Une règle ne peut pas être activée incomplète. L’activation exige un périmètre, une instruction et au moins une limite explicite. La condition est vérifiée au moment de la validation, pas de la création : on n’empêche pas de proposer une idée floue, on empêche de la mettre en production. Le périmètre d’une proposition n’est pas saisi à la main : il est hérité de la session où la règle est née. À défaut, la règle reste « à rattacher » et ne peut pas être activée.
Une garde anti-doublon compare chaque proposition aux règles existantes du même périmètre et bloque la création en affichant les règles proches. On peut passer outre, en cochant explicitement une case qui atteste que la règle est bien distincte.
Le cycle de vie est complet : brouillon, active, suspendue, désactivée, archivée, avec versions et restauration. Restaurer une version ancienne ne restaure jamais son statut ni sa validation ; sinon, revenir à une version active réactiverait la règle sans que personne la valide.

Choix assumé : une règle active dont l’échéance de revue (90 jours) est dépassée reste appliquée. L’échéance alimente une file « à revoir » dans l’administration ; ce n’est pas un disjoncteur. Une règle de doctrine qui s’éteint toute seule, sans que personne le voie, est un incident plus grave qu’une règle un peu vieille.

Ce qui a marché, ce qui a coincé

Ce qui a marché. L’aiguillage à la source plutôt qu’une promotion entre niveaux : ça supprime toute une classe de fuites et de conflits. L’application déterministe : le modèle ne peut pas réécrire silencieusement une règle qu’il a mal comprise. Et l’ordre des opérations : la mémoire personnelle est enregistrée avant les règles candidates de doctrine. Si ce second enregistrement échoue, l’échec est signalé règle par règle et la mémoire personnelle reste intacte.

Ce qui coince. Trois choses :

Les règles demandées en cours de session ne sont conservées nulle part avant la récolte. Si la session s’interrompt avant, un « retiens que… » est perdu. L’agent dit bien que la règle sera proposée à la validation, mais la friction est réelle.
Rien n’empêche techniquement un extrait de contrat d’atterrir dans la mémoire. La barrière est une consigne de prompt (des consignes sur la manière de travailler, jamais le contenu d’un contrat) et la validation humaine. Il n’y a pas de détecteur de données personnelles. Sur un périmètre plus sensible, c’est la première brique que j’ajouterais.
Deux personnes n’obtiennent pas le même audit. Aujourd’hui, la doctrine n’est appliquée qu’aux audits lancés par un admin ; juristes et utilisateurs reçoivent un audit fondé sur le seul référentiel. Chaque audit enrichi trace les règles considérées puis celles réellement appliquées, mais l’écart doit être expliqué aux utilisateurs, sinon il ressemble à un bug.

Checklist : concevoir la mémoire d’un agent métier

Écrire noir sur blanc ce que la mémoire n’a pas le droit de contenir. Ici, pour la mémoire personnelle : la manière de travailler, jamais le contenu d’un contrat ni une règle de fond, qui relève de la doctrine.
Séparer ce qui n’engage qu’une personne de ce qui engage l’équipe, dès la proposition : deux chemins d’écriture, pas un statut dans une même table ni une promotion après coup.
Le modèle suggère, un humain coche, le code applique. Toute modification doit être déterministe, réversible, et doit échouer de façon visible.
Fixer un budget dur et refuser l’écriture au-delà. Jamais de troncature silencieuse.
Rendre la validation asymétrique : proposer est ouvert, activer est réservé et tracé (qui, quand, sur quel périmètre).
Interdire l’activation d’une règle incomplète, bloquer les doublons, et prévoir suspension, archivage, versions et restauration, sans qu’une restauration réactive quoi que ce soit.
Choisir si l’échéance de revue coupe ou alerte, et l’écrire. Les deux se défendent ; l’implicite, non.
Tracer, à chaque exécution, quelles règles ont été considérées et lesquelles ont été appliquées, et montrer sa mémoire à l’utilisateur, en clair et modifiable. Une mémoire qu’on ne peut pas relire est une mémoire qu’on ne peut pas corriger.

Là où ça se joue

La partie difficile d’une mémoire d’agent n’est pas technique : un fichier texte par juriste et une table de règles suffisent. Elle est organisationnelle : qui a le droit d’apprendre à l’agent quelque chose qui s’appliquera aux autres, et comment on le défait.

C’est ce que je construis en accompagnement, sur la durée : qui propose, qui valide, comment on revient en arrière, puis la passation aux équipes qui feront vivre ces règles sans moi.