L'article précédent soutenait que CLAUDE.md ne sert qu'aux invariants. Alors que mettre dans memory ? J'ai ouvert les 5 fichiers memory actifs dans ce projet et les ai audités un par un — ce qui reste, ce qui doit partir, et où passe vraiment la ligne entre CLAUDE.md et memory.
L'article précédent soutenait que CLAUDE.md ne devait contenir que ce que Claude ne peut pas voir en lisant le code. Un lecteur a demandé aussitôt : et memory ? Memory est aussi du contexte — quelle est la vraie différence ?
Beaucoup finissent par traiter memory comme une « extension de sauvegarde » de CLAUDE.md — ils y fourrent tout ce qui leur passe par la tête. Avec le temps, memory gonfle, Claude le lit à chaque session, et les décisions se prennent sur des informations périmées.
Cet article saute les définitions abstraites. J'ai ouvert les 5 fichiers memory actuellement actifs dans ce projet et je les ai audités un par un — lesquels restent, lesquels dégagent, lesquels n'auraient jamais dû être écrits. Chemin faisant, la question CLAUDE.md vs memory se répond d'elle-même.
La bonne question n'est pas « où mettre ça » — mais « combien de temps vit cette information, et qui la met à jour ».
feedback_commits — attendre que je dise "commit" avant de committer
feedback_article_authenticity — les articles pratiques ne s'inventent pas
project_i18n_strategy — la décision de « sortir toutes les langues d'un coup »
project_howdev_plan — plan inachevé pour how2claude.dev
project_article_workflow — le pipeline de publication d'articles
Groupés par type.
Le corps est court : "don't auto-commit, wait for user to confirm."
C'est le type de memory au ROI le plus élevé. Une correction → permanente dans toutes les sessions futures.
Pourquoi pas dans CLAUDE.md ? Parce que ce n'est pas une règle de projet — c'est mon habitude de travail personnelle. Si un autre contributeur rejoignait le projet, il n'aurait pas forcément à suivre la même règle. CLAUDE.md est au niveau équipe. Memory est « entre Claude et moi ».
Pourquoi ne pas le redire au début de chaque conversation ? Parce que memory persiste entre les sessions. Quand Claude m'aidera la semaine prochaine, il s'en souviendra encore.
Le déclencheur est clair : j'ai corrigé quelque chose une fois et je veux que la correction dure à jamais.
Le corps de ce memory est anormalement spécifique :
Le 2026-04-16, en écrivant le dernier article de la série multi-agent, j'ai inventé une histoire sur « trois Agents construisant une feature de webhook »... tout inventé. L'utilisateur a demandé « est-ce réel ou inventé » — ce qui est un critère différent des deux articles précédents (méthodologiques)...
Le point clé : le champ Why n'est pas un principe abstrait — c'est un événement précis + date + ce qui s'est passé.
Pourquoi l'écrire ainsi ? Dans six mois, « les articles pratiques ont besoin de matière réelle » comme règle abstraite va me laisser perplexe — quand a-t-on fixé ça, pourquoi ? Mais « 4-16, j'ai inventé une histoire d'agent et je me suis fait prendre » déclenche un souvenir instantané, et me permet de juger sur le champ si la règle s'applique encore.
C'est l'entrée la plus « lourde » de mes 5. Ce n'est pas qu'une règle — c'est un dossier d'incident que Claude et moi pouvons consulter.
Le contenu : pourquoi ce projet a sorti agressivement toutes les langues d'un coup — coût de traduction via Claude ~0 $, et documentation officielle en anglais seulement comme fenêtre d'opportunité centrale.
On ne voit pas ça dans le code. Le code ne montre que 19 fichiers de locale. Pourquoi 19, pourquoi d'un coup, pourquoi le japonais et le coréen sont prioritaires — tout ça vit dans ma tête.
Memory cristallise cette « décision mentale » en quelque chose de durable, pour que lorsque Claude suggérera une fonctionnalité plus tard, il puisse se demander : est-ce que ça rentre en conflit avec la stratégie i18n ?
Ce n'est pas une règle opérationnelle (pas dans CLAUDE.md). C'est un fond stratégique (dans memory).
Le plus temporaire du lot : un plan d'implémentation de 9 fichiers pour le site développeurs how2claude.dev, se terminant par « à poursuivre à la prochaine session ».
Le type de memory le plus dangereux — il se transforme facilement en memory zombie. Vous finissez le travail, oubliez de le supprimer ; la fois suivante, Claude le traite comme toujours actif et conseille sur la base d'un plan périmé (« vous n'avez pas fait le step 3 »).
Ce type de memory a besoin d'un mécanisme de sortie explicite : au moment où how2claude.dev est lancé, je dois supprimer cette entrée manuellement.
Celle-ci a la plus forte densité d'information. Je croyais au début que c'était la plus utile — jusqu'à la lire attentivement :
/write-article et /publish-article → regarder .claude/commands/, finidocs/drafts/ rend ça évident.claude/publish-config.jsonClaude peut tout déduire en lisant le code.
La seule chose que memory apporte réellement est le dernier bloc : "Accounts (production): zh → @how2claude, en → @howtoclaude" — et c'est déjà périmé. La dernière session a montré que la prod est en fait zh=@howtoclaude. Memory a capturé un instantané d'il y a quelques jours ; il a déjà dérivé.
Conclusion : 90 % de ce memory devrait partir. Le bout qui mérite d'être gardé (« utiliser kamal pour interroger les comptes en direct ») a plutôt sa place dans CLAUDE.md — ou mieux encore, nulle part, puisque des comptes codés en dur dans memory dériveront de nouveau.
1. Le vrai rôle de memory est d'ouvrir les pièces où Claude ne peut pas entrer.
2. Si Claude peut le lire dans le code, ne le mettez pas dans memory.
Même principe que l'article précédent sur CLAUDE.md. Chemins de fichiers, URLs d'API, structure de dossiers — tout ça se répond avec le code. Le mettre dans memory parce qu'on n'a pas envie de faire un grep, c'est parier que l'information ne changera jamais.
3. Memory se dégrade.
project_article_workflow en est la preuve — écrit il y a quelques jours, l'info sur les comptes est déjà fausse. Plus memory est vieux, moins il est fiable. Auditer régulièrement > ajouter sans fin.
4. Le champ Why est ce qui vous sauve.
Comparez mes deux feedback :
feedback_article_authenticity : « 4-16, j'ai inventé une histoire dans l'article multi-agent » → six mois plus tard, je peux juger instantanément si ça s'applique toujours.feedback_commits : juste « user wants to review » → six mois plus tard, je ne sais pas quelle correction spécifique l'a engendré.Le second est bien plus faible. Les principes abstraits ne survivent pas — personne ne se souvient de leur raison d'être.
Quand une nouvelle information apparaît, posez-vous trois questions :
La troisième question est le piège. La plupart des « choses qui ne changent pas » que vous voulez noter sont en fait déductibles du code — vous ne voulez simplement pas que Claude refasse un grep.
Après un tour complet, quelques choses ressortent :
project_article_workflow est déductible du code. C'est celle qui a le plus besoin de chirurgie.project_howdev_plan est un passage temporaire — en théorie il devrait avoir un mécanisme de sortie.project_i18n_strategy est une décision stratégique — ça vaut la peine de la revoir dans quelques mois.feedback_commits est faible ; y attacher un événement précis le rendrait plus solide.Observation annexe : ma distribution de types est feedback×2 + project×3, zéro type user ou reference. Ça veut dire que je n'ai pas encore dit à Claude « qui je suis » ni « de quels systèmes externes je lis l'état ». Probablement le prochain lot à écrire.
Le plus gros piège avec memory n'est pas « ce que j'aurais dû écrire et que je n'ai pas écrit ». C'est « ce que j'ai écrit et qui est maintenant périmé ». Avec 5 entrées, une seule dérive suffit — Claude utilise silencieusement une info vieille pour décider, et il ne vous signalera pas la dérive.
Dans mes 5, je vois déjà deux ou trois choses à bouger. Et dans les vôtres ?