Idée principale

Une mémoire de session s'écrit toute seule : le hook tourne après chaque échange, sans qu'on y pense. Elle ne se relit pas toute seule pour autant — il faut lancer /memory_load en début de session pour que l'agent sache où en était le travail. L'asymétrie ressemble à une limitation qu'on n'aurait pas eu le temps de lever ; elle est un choix.

La raison tient à ce que chaque geste coûte. Écrire dans un fichier ne dérange personne : au pire, on a consigné quelque chose d'inutile qu'on ne lira jamais. Charger, en revanche, occupe la place — la mémoire d'un projet injectée dans une session ouverte pour une question de trois lignes encombre le contexte de matière sans rapport, et l'assistant répond moins bien pour l'avoir reçue.

Les deux mouvements n'ont donc pas la même règle. Ce qui est sans effet de bord peut être automatique ; ce qui consomme une ressource partagée demande une intention. C'est aussi ce qui permet de reprendre un travail sans avoir à subir sa mémoire chaque fois qu'on ouvre l'outil.

Pourquoi c'est important

Cela renverse une évidence — un système de mémoire complet serait celui qui se recharge seul — en montrant que le chargement automatique dégraderait précisément les usages les plus fréquents, les courts.

Et cela donne un critère général pour décider ce qu'on automatise : non pas ce qu'on répète, mais ce dont la répétition ne coûte rien à celui qui la subit.

Nuances et limites

Un geste manuel s'oublie. Une mémoire correctement écrite mais jamais rechargée ne sert à rien, et rien ne signale qu'on vient de retravailler à l'aveugle sur un sujet dont tout était consigné.

Et l'asymétrie suppose que l'humain sache quand il en a besoin — ce qui est vrai le lundi matin sur un bug laissé en suspens, moins vrai sur un projet repris après trois mois.

Questions ouvertes

• Que proposer à quelqu'un qui ne sait pas qu'une mémoire existe sur ce qu'il est en train de faire ?