Idée principale
Claude Code tient déjà une mémoire de ce qu'on lui a dit, mais il la range sous ~/.claude/projects/ : elle appartient à l'installation, pas au projet. Changer d'ordinateur, la relire, savoir quand telle décision y est entrée, la partager avec un collègue — rien de tout cela n'est prévu, parce que le lieu de rangement n'a jamais été pensé comme un objet de travail.
Écrire la même mémoire dans des fichiers Markdown déposés au milieu du dépôt git du projet change quatre choses d'un coup, et toutes viennent du même geste. Elle se déplace avec le dépôt, donc un clone sur une autre machine la retrouve. Elle est versionnée, donc git log memory_sessions/ raconte l'évolution des décisions techniques. Elle s'ouvre dans l'éditeur, donc on peut la corriger à la main quand l'agent a mal compris. Et elle se découpe comme le dépôt se découpe.
Le format plat n'est pas un renoncement technique en attendant mieux : c'est ce qui rend la mémoire inspectable par un humain, et une mémoire qu'aucun humain ne relit ne se corrige jamais.
Couche apportée par « Les systèmes d'information ne vont pas disparaître. Leur forme va changer. » (2026-07-08). Le même partage vaut à l'échelle d'une entreprise, et le format y compte encore moins qu'on ne le croit : Markdown, JSON, base documentaire, graphe ou base vectorielle font également l'affaire, la ligne passe entre ce qui est déplaçable et ce qui ne l'est pas. Une intelligence de travail restée dans des historiques de conversation n'est utile que tant que l'interface existe, que l'abonnement court et qu'on retrouve la bonne conversation : c'est une trace d'usage, pas une mémoire d'entreprise. Le critère qui départage est une liste d'opérations, non une préférence esthétique — pouvoir être relue par un humain, reprise par une autre IA, déplacée, sauvegardée, enrichie, auditée.
Pourquoi c'est important
Cela déplace la question qu'on se pose devant un outil de mémoire. On demande d'ordinaire ce qu'il retient ; la question qui compte d'abord est où il l'écrit, parce que c'est ce choix-là qui décide de tout le reste — portabilité, historique, relecture, partage.
Cela explique aussi pourquoi une mémoire native, même bonne, laisse un manque : ce qui vit dans l'outil est hors de portée des outils avec lesquels on travaille réellement.
Nuances et limites
Poser la mémoire dans le dépôt la rend visible par tous ceux qui ont accès au dépôt. Ce qui s'y écrit automatiquement — le nom d'un client, une erreur commise, une hésitation — devient un contenu publié à l'échelle de l'équipe, sans que personne l'ait relu.
Et un fichier versionné se relit mal quand il grossit : l'inspectabilité tient à la taille autant qu'au format.
Questions ouvertes
- Que faire de la mémoire d'une branche abandonnée, qui a été écrite mais dont le travail n'a jamais été fusionné ?