Système de mémoire (memory) : lui permettre de se souvenir de vous d'une session à l'autre

📚 Navigation de la série : L'article précédent [24 Plugins] vous a appris à empaqueter un ensemble de configurations éparses en un plugin installable et désactivable en un clic. Cet article traite d'un sujet encore plus fondamental — comment faire en sorte que Claude se souvienne de vous d'une session à l'autre. Il ne s'agit pas seulement du fichier CLAUDE.md que vous écrivez à la main, mais aussi des « notes personnelles » qu'il accumule lui-même au fil de son travail : si vous le corrigez sur un point, il le note discrètement pour s'en rappeler automatiquement lors de la prochaine session.

Commençons par un piège dans lequel les débutants tombent très facilement.

Lorsque l'on découvre pour la première fois la fonctionnalité permettant à Claude de mémoriser des informations, on a tendance à la considérer comme une mine d'or et à y insérer tout et n'importe quoi : un numéro de port configuré aujourd'hui, le nom d'une variable temporaire modifiée, ou même des détails éphémères comme « pour cette fois utilise le port 8081 au lieu du 8080 ». La logique sous-jacente est souvent « plus il se souvient de choses, plus il sera intelligent ».

Le résultat ? Deux semaines plus tard, en réouvrant le projet, il vous parle d'emblée de ce port 8081 pourtant abandonné depuis longtemps, ainsi que de préférences dont vous avez vous-même oublié la raison d'être. Il s'est encombrer l'esprit de détails inutiles, masquant les informations réellement importantes.

C'est alors que l'on comprend : la mémoire n'est pas plus efficace si on la sature ; l'important est de retenir précisément ce qui doit l'être et de laisser le reste de côté. Une information erronée en mémoire est plus problématique que pas d'information du tout — il risque de vous induire en erreur avec le plus grand sérieux en s'appuyant sur des données obsolètes.

Nous avons déjà vu en détail comment rédiger le CLAUDE.md au 18e article, et le 19e sur la gestion du contexte a rappelé plusieurs fois que « la mémoire automatique consomme du contexte ». Cependant, la façon dont ces deux briques s'assemblent pour former un « système de mémoire » complet et le fonctionnement des notes rédigées par Claude lui-même n'avaient pas encore été détaillés. C'est ce que nous allons voir aujourd'hui.

Après avoir lu cet article, vous saurez :

• Les deux systèmes de mémoire distincts de Claude Code : le fichier CLAUDE.md rédigé par vos soins par rapport à la « mémoire automatique » écrite par l'assistant, résumés dans un tableau comparatif clair.
• Le fichier dans lequel est stockée la « mémoire automatique », comment elle est injectée dans le contexte, et comment l'inspecter et la modifier à l'aide de la commande /memory.
• La procédure pas à pas pour lui faire mémoriser une information, identifier son lieu d'enregistrement et vérifier sa prise en compte automatique à la session suivante.
• Une liste comparative « ce qui doit être mémorisé par rapport à ce qui doit être évité » pour ne pas tomber dans le piège de la saturation de la mémoire.
• Si le raccourci historique # est toujours d'actualité et quelle est la recommandation officielle actuelle.

---

01 Distinguer d'abord : il existe deux systèmes de mémoire, et non un seul

Pour commencer par la conclusion : la « mémoire » de Claude Code repose sur deux systèmes parallèles indépendants, l'un rédigé par vous, l'autre par lui. On a souvent tendance à n'associer la mémoire qu'au seul fichier CLAUDE.md, alors que ce dernier n'en représente que la moitié.

Analogie : les post-its collés sur le bord de l'écran. Vous avez généralement deux types de notes sur votre bureau. Le premier est une « feuille de route » officielle imprimée et épinglée au panneau d'affichage — les consignes du projet, les étapes de validation, rédigées proprement pour s'appliquer à tous : c'est le fichier CLAUDE.md. Le second est un post-it griffonné à la hâte, indiquant par exemple « le bug de la dernière fois venait d'un problème de cache non vidé », que vous collez sur le bord de votre écran pour vous en rappeler au premier coup d'œil : ces petits billets qu'il note de lui-même correspondent à la « mémoire automatique (auto-memory) ». Les deux types de notes sont sous vos yeux, mais l'un représente « les règles que j'ai établies », tandis que l'autre correspond aux « enseignements que j'ai notés au fil de l'eau ».

La documentation officielle présente clairement la répartition des rôles entre ces deux systèmes, résumée dans ce tableau comparatif — le plus important à retenir dans cet article :

Dimension	Fichier CLAUDE.md	Mémoire automatique (auto-memory)
Rédigé par	Vous (manuellement)	Claude (lui-même)
Contenu	Instructions et règles	Expériences et modèles appris
Exemples types	Normes de codage, flux de travail, architecture du projet	Commandes de build, retours de débogage, préférences utilisateur détectées
Moment du chargement	À chaque session, chargement complet	À chaque session, mais limité aux 200 premières lignes ou 25 Ko
Portée	Niveau utilisateur / projet / local	Une copie par dépôt git (partagée entre tous les worktrees)

Vous voyez la différence majeure ? Le CLAUDE.md correspond à « ce que vous voulez qu'il fasse », tandis que la mémoire automatique est « ce qu'il a appris de lui-même sur la façon de faire ». Si vous lui signalez que « pour lancer les tests sur ce projet, il faut d'abord démarrer une instance locale Redis », il s'en souviendra la prochaine fois — cette consigne n'a pas besoin d'être saisie manuellement dans un fichier, il l'enregistre de lui-même.

Il y a également une règle essentielle sur laquelle la documentation insiste particulièrement :

Claude considère ces éléments comme du contexte et non comme des configurations obligatoires. Pour bloquer une action, quelles que soient les décisions de Claude, utilisez plutôt un hook PreToolUse.

Qu'est-ce que cela signifie ? La mémoire (quel que soit le système concerné) n'est qu'une indication souple influençant son comportement, et non une contrainte stricte verrouillant ses actions. Cela fait écho aux conclusions du 20e article sur la configuration des autorisations — pour interdire fermement une opération, il faut s'appuyer sur des règles de permissions ou des hooks ; inscrire simplement « ne pas push » en mémoire ne suffira pas à l'empêcher. La mémoire sert à « l'aider à mieux vous comprendre », elle n'a pas de rôle de garde-fou restrictif.

💡 En résumé : Le mémoire se divise en deux systèmes — CLAUDE.md pour vos règles écrites, la mémoire automatique pour ses propres notes d'apprentissage ; tous deux constituent des indications souples, et pour restreindre fermement des actions, il convient d'utiliser les règles de permissions ou les hooks.

Ce schéma présente en parallèle les deux circuits de mémoire : à gauche, le fichier CLAUDE.md (consignes du projet) écrit par vos soins et chargé dans son intégralité dans le contexte ; à droite, la mémoire automatique (notes personnelles) que Claude rédige de lui-même dans MEMORY.md au fil de son travail et dont les 200 premières lignes sont relues au démarrage de la session suivante. Ces deux flux convergent vers la fenêtre de contexte de la nouvelle session pour qu'il « se souvienne de vous » dès le démarrage.

---

02 La place du fichier CLAUDE.md dans l'architecture de la mémoire

La rédaction du fichier CLAUDE.md a déjà été détaillée au 18e article, nous rappellerons simplement ici son rôle au sein du système de mémoire — il s'agit de la « feuille de route » officielle, visible par tous et solidement fixée.

Analogie : toujours nos deux types de notes à côté de l'écran, le CLAUDE.md étant la version officielle épinglée. Ce n'est pas un post-it griffonné à la va-vite, mais la feuille de route formelle que vous avez imprimée et solidement fixée. Il présente ainsi des caractéristiques opposées à celles de la mémoire automatique : rédigé par vos soins, intégré au contrôle de version pour être partagé par toute l'équipe, chargé intégralement à chaque session, son contenu se composant de « règles » et non de « retours d'expérience ».

La documentation officielle définit une hiérarchie claire pour le fichier CLAUDE.md, classée par ordre de chargement (du plus général au plus spécifique) :

Niveau	Emplacement	Portée
Politique managée	macOS: /Library/Application Support/ClaudeCode/CLAUDE.md Linux/WSL: /etc/claude-code/CLAUDE.md	Déployé de manière centralisée par le service informatique de l'entreprise, ne concerne généralement pas les particuliers
Utilisateur	~/.claude/CLAUDE.md	Préférences personnelles appliquées à l'ensemble de vos projets
Projet	./CLAUDE.md ou ./.claude/CLAUDE.md	Spécifique au projet, partagé par toute l'équipe (intégré à git)
Local	./CLAUDE.local.md	Spécifique au projet, réservé à votre usage personnel (ajouté au fichier .gitignore)

Voici une différence majeure avec la mémoire automatique, qu'il convient de garder à l'esprit :

Le fichier CLAUDE.md est chargé en totalité quelle que soit sa taille, tandis que la mémoire automatique est plafonnée. La documentation officielle indique clairement que « le fichier CLAUDE.md est chargé intégralement, quelle que soit sa longueur ». C'est pourquoi l'article [18] insistait pour que vous le limitiez à 200 lignes : ce n'est pas parce qu'il ne peut pas être chargé, mais plus il est long, plus il consomme de contexte et moins Claude parviendra à appliquer les règles. La mémoire automatique fonctionne à l'inverse : elle comporte un plafond strict (détaillé dans la section suivante) et tout contenu dépassant ce seuil n'est tout simplement pas pris en compte au démarrage.

En pratique, la répartition est simple : les « règles strictes imposées » vont dans CLAUDE.md, tandis que les « enseignements découverts par l'assistant » sont confiés à la mémoire automatique. Par exemple, une règle stricte comme « utiliser exclusivement pnpm pour les dépendances » doit être écrite dans le fichier CLAUDE.md ; en revanche, une information comme « l'exécution des tests requiert le démarrage local de Redis » peut être mémorisée automatiquement par Claude après que vous l'ayez corrigé une première fois, sans nécessiter d'intervention manuelle.

💡 En résumé : Le fichier CLAUDE.md correspond à la « feuille de route officielle et fixe » — rédigé par vous, partagé par toute l'équipe, chargé intégralement, il contient les règles ; son rôle est totalement distinct de la mémoire automatique qui recueille ses propres notes d'expérience.

---

03 La mémoire automatique : son propre carnet de notes

Nous en arrivons au sujet principal de cet article, annoncé dans le 18e — la mémoire automatique (auto-memory), qui correspond au carnet de notes que Claude tient à jour au fil de son travail.

ℹ️ La mémoire automatique nécessite Claude Code v2.1.59 ou supérieur, et est activée par défaut. Saisissez claude --version pour vérifier votre version actuelle ; si elle est trop ancienne, mettez-la à jour (consultez les instructions d'installation au chapitre [02 Installation]).

Analogie : un collaborateur de longue date. Avec un collègue avec qui vous travaillez depuis un moment, vous n'avez plus besoin de répéter certaines consignes — il les a enregistrées de lui-même : « la build de ce projet se lance avec make build et non npm build », « ce bug aléatoire de la dernière fois venait d'un fuseau horaire mal configuré ». Face à une situation similaire, il s'en souvient immédiatement. Vous n'avez rien à lui dicter, il apprend au fil de l'eau — la mémoire automatique correspond à cette faculté d'apprentissage actif de Claude.

Qu'enregistre-t-il exactement ? La documentation officielle cite : les commandes de build, les enseignements de débogage, les notes d'architecture, les préférences de style de code et les habitudes de flux de travail. Notez un choix de conception important : il ne consigne pas tout à chaque session, mais il évalue si l'information sera utile pour les conversations futures avant de décider de la retenir. Les détails à usage unique ne sont généralement pas enregistrés (ce qui évite le piège de la saturation).

Comment ces informations y sont-elles concrètement écrites ? Il existe deux modes de déclenchement :

Première méthode : vous lui demandez explicitement de retenir. Si vous dites au cours de la discussion « utilise toujours pnpm plutôt que npm pour ce projet » ou « mémorise que les tests d'API nécessitent le lancement local de Redis », il enregistrera cette consigne en mémoire automatique. Extrait de la documentation officielle :

当你要求 Claude 记住某些内容时，如「总是使用 pnpm，而不是 npm」或「记住 API 测试需要本地 Redis 实例」，Claude 将其保存到自动记忆。

Deuxième méthode : il apprend de vos corrections. Vous n'avez pas besoin de lui dire explicitement « souviens-toi de », il vous suffit de le corriger une fois — par exemple, s'il tente d'exécuter npm test et que vous lui répondez « les tests sur ce projet se lancent avec pnpm test » — s'il estime que cette information sera à nouveau utile, il la mémorisera de lui-même. C'est le principal atout de la mémoire automatique : vous travaillez normalement, vous le corrigez au besoin, et il accumule ses connaissances en arrière-plan sans effort supplémentaire de votre part.

Comment savoir qu'il est en train d'enregistrer ? Vérifiez les indicateurs de l'interface. La documentation indique que lorsque les mentions « Writing memory » (Écriture en mémoire) ou « Recalled memory » (Rappel de la mémoire) apparaissent dans l'interface de Claude Code, cela signifie qu'il écrit ou lit dans son carnet de notes.

💡 En résumé : La mémoire automatique correspond aux post-its que Claude rédige lui-même — soit à votre demande, soit en apprenant de vos corrections, en ne conservant que les éléments utiles à l'avenir ; les mentions « Writing/Recalled memory » dans l'interface indiquent qu'il consulte ou met à jour ses notes.

---

04 Où est-elle stockée et comment est-elle chargée dans le contexte

Cette section répond à deux questions très concrètes : dans quel fichier ce carnet de notes est-il enregistré ? Et comment est-il injecté dans le contexte pour que Claude s'en souvienne ? La seconde partie fait écho à la gestion du contexte abordée au chapitre [19].

Emplacement de stockage : défini par le système, chaque projet dispose de son propre répertoire de mémoire :

~/.claude/projects/<project>/memory/
├── MEMORY.md          # 简洁索引，每次会话都加载
├── debugging.md       # 调试相关的详细笔记
├── api-conventions.md # API 设计决策
└── ...                # Claude 自己创建的其他主题文件

Quelques précisions importantes :

Le fichier MEMORY.md sert d'entrée et d'index. Il agit comme la « table des matières » de ses post-its, lui permettant de suivre ce qu'il a mémorisé. Les détails sont répartis dans des fichiers thématiques comme debugging.md ou api-conventions.md, afin d'éviter que MEMORY.md ne devienne trop volumineux.

Le nom <project> correspond au dépôt git. Par conséquent, l'ensemble des worktrees et sous-répertoires d'un même dépôt partagent la même mémoire automatique. C'est une différence majeure avec le fichier CLAUDE.md, dont le chargement dépend de l'arborescence des répertoires.

Cette mémoire est locale à la machine, elle n'est pas synchronisée entre vos différents postes. Ce qui est enregistré sur cet ordinateur n'apparaîtra pas sur un autre. Elle n'est pas non plus destinée à être intégrée à git, restant localisée sous votre répertoire ~/.claude.

Voyons maintenant le mécanisme clé : comment cette mémoire est-elle chargée dans le contexte ? Le fonctionnement défini par le système est très précis :

MEMORY.md 的前 200 行或前 25KB（以先到者为准）在每次对话开始时加载。超过该阈值的内容在会话开始时不加载。

En clair, cela implique trois règles :

1. À chaque nouvelle session, les 200 premières lignes de MEMORY.md (ou les 25 premiers Ko) sont automatiquement lues. C'est ce mécanisme qui lui permet de se souvenir d'une session à l'autre : les notes de la session précédente sont injectées d'emblée dans le contexte de la nouvelle.
2. Ce qui dépasse les 200 lignes ou 25 Ko n'est pas chargé au démarrage. C'est pourquoi Claude veille à maintenir MEMORY.md le plus concis possible, en déportant les détails dans des fichiers thématiques.
3. Les fichiers thématiques (like debugging.md) ne sont pas chargés au lancement. Il les consulte uniquement au besoin à l'aide de ses outils de lecture de fichiers, selon le même principe que le chargement à la demande des fichiers CLAUDE.md de sous-répertoires présenté au chapitre [18].

Comparons les règles de chargement de CLAUDE.md et de la mémoire automatique :

	Fichier CLAUDE.md	Mémoire automatique MEMORY.md
Volume chargé	Intégralité, quelle que soit la taille	Seulement les 200 premières lignes / 25 Ko
Dépassement	Chargé intégralement quand même (d'où l'importance de le faire court)	Non chargé au démarrage, consulté uniquement au besoin
Maintenance de la concision	Manuelle par vos soins	Automatique par Claude

En comprenant cette limite, vous saisissez pourquoi cette mémoire ne risque pas de saturer votre contexte — la mémoire automatique comporte une limite structurelle de 200 lignes, tandis que la taille du fichier CLAUDE.md dépend entièrement de votre discipline.

💡 En résumé : La mémoire automatique est stockée dans ~/.claude/projects/<project>/memory/MEMORY.md, par dépôt git, en local sur votre machine et partagée par tous les worktrees ; seules les 200 premières lignes ou 25 Ko sont chargés au démarrage, le reste étant réparti dans des fichiers thématiques consultés au besoin. Elle dispose donc d'un plafond naturel évitant la saturation du contexte.

---

05 /memory : inspecter, modifier, activer ou désactiver, une commande unique

L'une des principales préoccupations avec la mémoire automatique est de savoir comment réagir s'il enregistre une information erronée ou obsolète (comme le piège du port 8081 cité au début). La solution officielle consiste en une commande unique : /memory.

Analogie : pouvoir consulter la pile de post-its à tout moment. Les notes que l'assistant rédige ne sont pas une boîte noire ; vous pouvez les examiner ou les retirer à votre guise. La commande /memory correspond à cette action de consultation.

Saisir la commande /memory en session effectue trois actions :

1. Lister l'ensemble des fichiers de mémoire chargés dans la session en cours — y compris CLAUDE.md, CLAUDE.local.md, les fichiers de règles et la mémoire automatique. En cas de doute sur une information en mémoire, commencez par identifier les fichiers chargés.
2. Fournir un accès direct pour ouvrir le répertoire de mémoire automatique — vous pouvez ouvrir le dossier memory/ en un clic, ces fichiers étant au format markdown brut, lisibles, modifiables et supprimables à tout moment. Si une information est incorrecte, il vous suffit de la supprimer directement dans le fichier.
3. Activer ou désactiver la mémoire automatique — si vous ne souhaitez plus qu'il mémorise d'informations de lui-même, vous pouvez la couper ici.

En dehors de la commande /memory en session, deux méthodes officielles permettent de désactiver définitivement cette fonctionnalité :

Désactiver la mémoire automatique dans le fichier settings.json (niveau projet, persistant dans la configuration) :

{
  "autoMemoryEnabled": false
}

Ou utiliser une variable d'environnement pour la désactiver temporairement (en définissant CLAUDE_CODE_DISABLE_AUTO_MEMORY=1).

Il est recommandé de prendre cette habitude : de temps à autre, lancez la commande /memory pour jeter un coup d'œil aux notes de votre projet. Vous y découvrirez souvent des éléments obsolètes à retirer — un numéro de port qui a changé, une convention d'API abandonnée ou des préférences dont vous ne comprenez plus le sens. Cela prend deux minutes et évite que l'assistant ne vous égare plus tard avec des données périmées. C'est précisément la leçon à retenir du piège du port 8081.

💡 En résumé : La commande /memory affiche l'ensemble du système de mémoire — liste des fichiers chargés, ouverture du répertoire de mémoire pour consultation/édition, et activation/désactivation ; une inspection régulière pour supprimer les éléments obsolètes reste le moyen le plus simple d'éviter les erreurs de mémoire.

---

06 Que mémoriser et que laisser de côté : éviter le piège de la saturation

Maintenant que le fonctionnement est posé, passons aux critères de choix concrets — qu'est-ce qui mérite d'être retenu, et qu'est-ce qui doit être ignoré ? Ces retours s'appuient sur l'expérience acquise à la suite de réels écueils.

La bonne nouvelle est que la mémoire automatique est par défaut plutôt sélective (ne retenant que ce qui servira à l'avenir). Cependant, lorsque vous lui demandez activement de mémoriser quelque chose, c'est à vous de filtrer — si vous dites « souviens-toi de xxx », il l'enregistrera généralement, la responsabilité du tri vous incombant.

Voici un tableau comparatif, à gauche les éléments qu'il convient d'éviter, à droite ceux qui méritent réellement d'être mémorisés :

❌ À éviter (éphémère / changeant / sensible)	✅ À mémoriser (stable / réutilisable / propre au projet)
« Pour cette fois, utilise le port 8081 » (unique)	« La commande de build est make build et non npm build »
« Remplace temporairement cette variable par tmp » (temporaire)	« Les tests de ce projet nécessitent de démarrer Redis localement »
« Fais tourner cette version pour l'instant » (sujet à changement immédiat)	« Le bug aléatoire de la dernière fois venait d'un fuseau horaire non configuré » (débogage)
Mots de passe de base de données / clés API / tokens (sensible !)	« Formater systématiquement les dates au standard ISO 8601 » (conventions)
« Je suis en train de travailler sur la page de connexion » (état temporaire actuel)	« La logique d'authentification se situe dans src/auth/ » (architecture)

Trois critères de décision simples à retenir :

1. La stabilité : Ce qui est à usage unique, temporaire ou « pour le moment » ne doit pas être mémorisé — sa validité est plus courte que la session en cours, et l'enregistrer risque de compliquer la suite. L'exemple du port 8081 est typique : utile sur le moment, il induit en erreur quelques jours plus tard.

2. La réutilisabilité : Ce qui ne sert que pour la tâche en cours (comme « je travaille sur X ») ne doit pas être conservé ; seules les informations utiles lors des prochaines sessions (commandes de build, détails d'architecture, enseignements tirés) méritent d'être gardées.

3. La sensibilité : C'est une ligne rouge — les mots de passe, tokens et clés API ne doivent en aucun cas être inscrits en mémoire. La mémoire automatique est écrite en texte brut au format markdown sur votre disque dur ; y stocker des secrets équivaut à les laisser lisibles sur votre machine. C'est en accord avec les règles de sécurité générales : les données sensibles ne vont pas dans le code, pas dans les commits, pas dans les logs, et donc pas non plus dans la mémoire.

Avant de lui demander de retenir quelque chose, posez-vous ces trois questions : Est-ce sujet à changement ? Sera-ce utile plus tard ? Est-ce sensible ? Si l'information passe ces trois filtres, vous pouvez la mémoriser. En agissant ainsi, ses notes resteront bien plus propres et vous éviterez les erreurs dues à des données obsolètes.

---

07 Le raccourci # est-il toujours d'actualité ?

ℹ️ Le caractère # correspond à une ancienne pratique et n'est plus utilisé dans les versions récentes. Oubliez les tutoriels ou vidéos qui enseignent d'insérer des notes en commençant par #. Les approches recommandées actuelles sont : dire « souviens-toi de xxx » pour l'ajouter en mémoire automatique, dire « ajoute à CLAUDE.md » pour l'intégrer aux consignes du dépôt, et gérer le tout avec la commande /memory.

Un piège classique pour les débutants : dire simplement « souviens-toi de xxx » l'enregistre par défaut dans la mémoire automatique (locale à la machine), ce qui ne l'ajoute pas dans le fichier CLAUDE.md (partagé via git avec toute l'équipe). Pour qu'une règle soit visible de tous, vous devez explicitement demander « ajoute à CLAUDE.md ». Une nuance de formulation qui change totalement la portée du partage.

💡 En résumé : Le raccourci # est obsolète et à éviter ; « souviens-toi de xxx » va en mémoire automatique, tandis que « ajoute à CLAUDE.md » l'inscrit dans git. Ces deux mécanismes sont distincts, formulez clairement votre demande selon la portée souhaitée.

---

08 Exercice pratique : enregistrer une note, localiser son stockage et vérifier son application

Rien ne vaut la pratique. Suivons cette procédure pas à pas : mémoriser une note → identifier son fichier d'enregistrement → vérifier qu'elle est rappelée automatiquement à la session suivante. Il s'agit d'un exemple minimal sans prérequis de configuration.

ℹ️ Prérequis : Claude Code v2.1.59 ou supérieur, avec la mémoire automatique activée (par défaut).

Étape 1 : Créer un projet de test et lancer Claude (Mac / Linux)

mkdir memory-demo
cd memory-demo
claude

Résultat attendu : L'interface de session de Claude Code s'ouvre, avec la zone de saisie au bas de l'écran.

Étape 2 : Lui faire mémoriser une note

Saisissez dans la zone d'entrée (en utilisant un exemple classique de commande de build) :

记住：这个项目的构建命令是 make build，不是 npm build

Résultat attendu : Claude confirme qu'il a pris note de l'information, et la mention « Writing memory » apparaît brièvement dans l'interface — cet indicateur confirme qu'il est en train de mettre à jour son carnet de notes.

Étape 3 : Confirmer l'enregistrement à l'aide de la commande /memory

Saisissez ensuite :

/memory

Résultat attendu : L'interface de gestion de la mémoire s'affiche, listant tous les fichiers de mémoire chargés. Vous y trouverez l'accès à la mémoire automatique, et en consultant MEMORY.md, vous verrez l'enregistrement de la commande make build. Sa présence dans le fichier confirme que la consigne est passée d'un échange textuel à une note sauvegardée sur le disque.

Si vous préférez le vérifier directement en ligne de commande, ouvrez un autre terminal et saisissez :

cat ~/.claude/projects/*memory-demo*/memory/MEMORY.md

Résultat attendu : La commande affiche la consigne de build que vous venez d'enregistrer (le nom <project> dans le chemin dépend de votre répertoire, utilisez * comme caractère générique). C'est du markdown brut, parfaitement lisible.

Étape 4 : Vérifier l'application automatique à la session suivante

C'est l'étape essentielle — l'intérêt de la mémoire réside dans sa persistance d'une session à l'autre. Quittez la session en cours :

/exit

Puis relancez Claude et posez-lui une question faisant appel à cette information :

claude

Saisissez ensuite :

这个项目怎么构建？

Résultat attendu : Il vous répond directement d'utiliser make build (au lieu de supposer npm build) — et vous devriez voir s'afficher l'indicateur « Recalled memory », confirmant qu'il a chargé l'information depuis son carnet de notes. Le fait qu'il réponde correctement dans une nouvelle session démontre que la persistance de la mémoire fonctionne, félicitations !

Étape 5 (facultative) : Supprimer la note et vérifier la prise en compte

Lancez la commande /memory, accédez au répertoire de la mémoire automatique et supprimez la ligne concernant make build dans le fichier avant d'enregistrer. Si vous lui demandez à nouveau « comment compiler le projet ? », il ne vous répondra plus make build d'office — une information erronée en mémoire se supprime simplement, c'est tout l'intérêt de la gestion offerte par /memory.

En suivant ces cinq étapes, vous avez validé le cycle complet : « enregistrement → sauvegarde → rappel automatique en session suivante → inspection et modification ». L'ensemble du fonctionnement de la mémoire repose sur ce mécanisme.

💡 En résumé : Demander de « se souvenir de xxx » → repérer l'indicateur « Writing memory » → valider l'enregistrement dans MEMORY.md via /memory ou cat → relancer une session et constater le rappel automatique (« Recalled memory ») → modifier ou supprimer via /memory si nécessaire. Faire l'exercice en pratique est le meilleur moyen d'assimiler le concept.

---

09 Synthèse

Cet article a détaillé le fonctionnement du « système de mémoire » de Claude Code — constitué de deux canaux parallèles indépendants, l'efficacité repose sur le tri sélectif des informations plutôt que sur leur accumulation.

Synthèse des points clés à retenir :

Point clé	Conclusion
Les deux systèmes de mémoire	CLAUDE.md pour vos consignes et la mémoire automatique pour ses propres notes
Différences entre les deux	Distingués par l'auteur, le contenu (règles vs retours d'expérience) et les limites de chargement
Lieu de stockage de la mémoire automatique	Fichier ~/.claude/projects/<project>/memory/MEMORY.md, par dépôt git et local à la machine
Mode de chargement	Limité aux 200 premières lignes / 25 Ko de MEMORY.md au démarrage, le reste étant lu au besoin
Inspection et modification	Commande /memory : lister les fichiers, ouvrir le répertoire pour modification et activer/désactiver
Critères de sélection	Filtrer selon la stabilité, l'utilité future et la sensibilité (ne jamais stocker de secrets)
Raccourci #	Obsolète ; formulez « souviens-toi de xxx » pour la mémoire automatique ou « ajoute à CLAUDE.md »

Vous êtes désormais en mesure de : distinguer le rôle de CLAUDE.md et de la mémoire automatique, identifier leurs emplacements et modes de chargement, enregistrer une consigne et vérifier son fichier d'enregistrement, nettoyer les notes erronées ou obsolètes avec /memory, et évaluer si une information doit être conservée ou non. En somme, vous contrôlez ce que Claude doit retenir ou oublier afin de maintenir sa mémoire opérationnelle et pertinente.

La mémoire permet à Claude d'enregistrer passivement des faits au fil des échanges. Mais ses capacités d'adaptation vont bien au-delà.

---

Le prochain article 26 « Skills de l'agent (Agent Skills) » s'intéresse à la mise en œuvre de savoir-faire : alors que la mémoire enregistre passivement des faits, les skills consistent à formaliser des capacités opérationnelles. Il s'agit de décrire un enchaînement d'actions répétitives pour que l'assistant puisse l'exécuter à la demande. Si la mémoire l'aide à « mieux vous comprendre », les skills lui permettent de « faire plus de choses ». Question de réflexion : selon vous, dans quelles situations convient-il d'enregistrer une règle en mémoire par rapport à lui apprendre un skill ?

---

Lectures recommandées

• Configuration de l'API : abonnement ou clé API, comment choisir et basculer
• Prise en main pratique : de la spécification à la livraison pas à pas
• Guide d'utilisation de CLAUDE.md : inscrire les règles du projet dans sa mémoire