Angle
Donner une mémoire à un assistant de développement ne consiste pas à choisir un endroit où écrire : cela consiste à répartir cinq décisions — où la mémoire réside, ce qu'on y retient, quand on la resserre, à quelle cadence on l'écrit, et quand on la relit. Quatre d'entre elles s'automatisent sans perte ; la cinquième, le rechargement, doit rester un geste humain, parce qu'elle est la seule qui consomme la ressource rare d'une session. Une mémoire échoue par cette répartition bien avant d'échouer par son format : un fichier Markdown mal réparti ne vaut pas mieux qu'une base de données, et une répartition juste fonctionne dans les deux.
Synthèse
Le problème de départ ressemble à un problème de stockage. Claude Code oublie tout entre deux sessions, il faut donc écrire quelque part ce qu'il devrait savoir. La question paraît close dès qu'on a tranché le format : des fichiers Markdown dans le dépôt git plutôt qu'un répertoire caché sur la machine.
Ce choix règle en réalité une seule des décisions, et c'est la seule qui soit entièrement réversible. Les quatre autres se posent ensuite, et chacune tranche entre un humain et une machine.
Ce qu'on retient ne se désigne plus à la main. Un modèle léger relit chaque échange et décide seul de ce qui entre dans le log du jour et de ce qui monte en mémoire longue. La décision n'a pas disparu : elle est passée du geste au texte — un prompt, des sections imposées, une consigne de déduplication. Ce déplacement est le point le plus discutable de tout le dispositif, parce qu'il contredit une position mieux établie ailleurs, selon laquelle ce qui fait la valeur d'une persistance est précisément qu'un humain ait dit « ça compte ». Les deux tiennent, mais pas pour le même volume : on ne désigne pas à la main vingt échanges par jour.
Quand on resserre n'est pas non plus laissé à la bonne volonté. Un plafond de trois cents lignes sur long_memory.md déclenche la consolidation, et c'est la contrainte de taille — arbitraire, assumée — qui produit l'occasion de relire. Sans elle, l'entretien reste une intention.
À quelle cadence on écrit est imposé par le point d'accroche retenu, et l'erreur commence là. Un hook nommé Stop évoque une fin de session ; il se déclenche après chaque tour. Cette fréquence décide ensuite de tout ce qui est soutenable : le modèle choisi, la durée acceptable, le budget par exécution. Un seuil négligeable — moins d'un dollar par mois — n'achète pas une économie, il achète la disparition d'une question, et une automatisation dont on discute à chaque échange finit coupée.
Quand on relit est la seule décision qui n'a pas été rendue. Écrire ne coûte rien à personne ; charger occupe la fenêtre d'une session, et injecter d'office la mémoire d'un projet dans une session ouverte pour trois lignes dégrade la réponse. D'où /memory_load à la main, qui ressemble à une limitation et qui est un arbitrage.
Restent les pannes propres à ce montage, et elles ne viennent pas du format non plus. Un automate qui appelle l'outil dont il surveille la fin se réveille lui-même. Un agent utilitaire lancé depuis le répertoire du projet hérite des règles de rédaction de ce projet et cesse de rendre la structure qu'on lui demande. Deux défauts de conception, deux décisions mal réparties entre ce que l'automate fait et ce qu'il doit reconnaître.
Ce que l'ensemble donne à voir : un système de mémoire ne se juge pas sur ce qu'il conserve, mais sur l'endroit où chaque décision a été placée — et il reste possible de tout déplacer sauf la dernière.
Tensions / contradictions
La contradiction principale porte sur qui désigne ce qui survit. Une position établie ailleurs pose que la valeur d'une persistance tient au geste par lequel un humain dit « ça compte », et qu'une conservation exhaustive ne désigne rien ; ce système délègue ce tri à un modèle, selon un critère rédigé une fois. La ligne de partage n'est pas tranchée : elle semble tenir au volume et à la tolérance à la perte silencieuse, mais rien ici ne dit où elle passe exactement.
Seconde tension, moins visible : la mémoire est écrite dans le dépôt pour être inspectable et corrigible à la main, et elle est produite à une cadence qui rend cette relecture improbable. L'inspectabilité est réelle comme propriété, incertaine comme pratique.
Questions
- Comment une répartition de ce type se transpose-t-elle à une équipe, où la mémoire écrite par l'un devient le contexte rechargé par l'autre ?
- Quel signal permettrait de savoir qu'un critère de tri délégué s'est mis à écarter ce qui comptait ?