Idée principale

Dans une mémoire de session alimentée par un hook, personne ne désigne ce qui doit survivre. À la fin de chaque tour de conversation, un modèle léger relit le dernier échange et décide seul de ce qu'il en consigne : ce qui va dans le log du jour, ce qui monte dans long_memory.md parce qu'il le juge durable, ce qu'il laisse tomber.

Le tri n'a pas disparu pour autant — il a changé de nature. Il était un geste, il devient un texte : le prompt d'extraction, les sections imposées, la consigne de ne pas dupliquer ce qui existe déjà. Ce qui sera retenu dans six mois est décidé aujourd'hui, une fois, par la formulation de ce critère, et non échange par échange par quelqu'un qui lit.

D'où le déplacement de l'effort. Écrire un critère coûte plus cher qu'un geste ponctuel, et beaucoup moins que mille gestes. Mais le critère s'applique aussi aux échanges qu'on n'a pas anticipés, et personne ne s'aperçoit qu'il a mal trié : une mémoire déléguée est silencieuse sur ses oublis.

Pourquoi c'est important

Cela ouvre une troisième voie entre tout garder et désigner à la main, et c'est la seule qui passe à l'échelle d'un usage quotidien : un tri automatique n'est acceptable que si l'on peut lire, corriger et versionner la règle qui le produit.

Cela dit aussi où porte désormais l'attention. Relire la mémoire produite ne sert pas seulement à la corriger : c'est le seul moyen d'évaluer le critère qui l'a écrite.

Nuances et limites

L'humain ne disparaît pas partout. Dans ce système, la clôture d'un point à suivre reste un acte déclaré — on envoie OK-done pour qu'une ligne passe en « Finalisé ». Ce qui est délégué, c'est le tri de ce qui entre ; pas le verdict sur ce qui est achevé.

Et le critère écrit vieillit comme toute règle : il a été formulé pour un projet à un moment, il continue de s'appliquer quand le projet a changé de nature.

Questions ouvertes

• Comment mesurer ce qu'un critère de tri automatique a laissé passer, puisque ce qui manque n'apparaît nulle part ?