# Pack Memory : Zecher et le cerveau persistant

> Zecher conserve décisions, leçons et passations de session dans des fichiers simples, entre sessions et projets. Installation, détection du cerveau, huit exemples, sorties, commandes CLI, limites.

Canonical: https://bmad-plus.rochetta.fr/fr/docs/packs/memory-pack/
Language: fr
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentation BMAD+ › [Packs](https://bmad-plus.rochetta.fr/fr/docs/packs/) › Pack Memory : Zecher et le cerveau persistant

Un assistant IA commence chaque session sans rien savoir d’hier. Le pack Memory y remédie avec de simples fichiers Markdown : ce qui a été décidé et pourquoi, ce qui a mal tourné, quels motifs ont fonctionné, où en est le projet, et une note de passation à la fin de chaque session. Zecher est l’agent qui entretient ces fichiers : il les consolide, parcourt votre machine à la recherche de projets, reconstruit le contexte d’une session à froid et contrôle la santé de la mémoire. Il existe deux niveaux de mémoire, l’un par projet et l’autre partagé entre projets (un cerveau global).

<a id="when-to-use"></a>
## Quand l’utiliser

- Vous travaillez sur le même projet pendant de nombreuses sessions et réexpliquez sans cesse les décisions déjà prises.
- Vous jonglez avec plusieurs projets et voulez un index unique, avec leur stack, leur statut et leur dernière activité.
- Vous tenez déjà un dossier de notes (`_brain/` ou `~/.claude/memory/`) : le pack s’y relie au lieu d’en créer un second.

<a id="installed"></a>
## Ce qui est installé

Le pack est empaqueté dans `.agents/skills/pack-memory/` : l’orchestrateur `memory-orchestrator.md`, l’agent `zecher-agent.md`, deux documents partagés (`shared/memory-protocol.md` et `shared/karpathy-guardrails.md`) et des modèles pour `decisions.md`, `lessons.md`, `patterns.md`, `context.md`, `session-handoff.md` et `identity.yaml`. À l’installation, il crée aussi la mémoire de votre projet et la relie à un cerveau ; si aucun cerveau n’est trouvé, un nouveau cerveau global est créé dans `~/.bmad-plus/brain/`, hors du projet. Si cette étape échoue, l’installation se poursuit.

**Les deux niveaux de mémoire**

| Niveau | Emplacement | Contient |
| --- | --- | --- |
| Mémoire du projet | `.agents/memory/` | `decisions.md`, `lessons.md`, `patterns.md`, `context.md`, `sessions/YYYY-MM-DD-<topic>.md` |
| Cerveau global | `~/.bmad-plus/brain/` | `identity.yaml`, décisions, leçons et motifs communs aux projets, `stack-preferences.md`, `projects/<hash>.yaml` et `projects-index.md` |
| Cerveau de portefeuille | `_brain/` dans le projet ou un dossier parent | Votre propre organisation de notes ; il prime sur le cerveau global et garde ses conventions |

La règle d’or : ce qui concerne un seul projet va dans la mémoire du projet ; ce qui concerne deux projets ou plus est candidat au cerveau global, et seulement avec votre accord.

<a id="brain-detection"></a>
### Comment un cerveau est trouvé

1. La variable d’environnement `BMAD_PLUS_BRAIN`, si elle désigne un dossier, l’emporte sur tout.
2. Un dossier `_brain/` dans le projet ou dans un dossier parent (un cerveau de portefeuille).
3. Le cerveau global `~/.bmad-plus/brain/`, seulement s’il existe déjà (les fichiers manquants sont complétés, rien n’est écrasé).
4. Le dossier de mémoire propre de Claude `~/.claude/memory/`, seulement s’il n’est pas vide ; il est lié, pas copié.
5. Rien de trouvé : un nouveau cerveau global est créé dans `~/.bmad-plus/brain/` (avec `identity.yaml`, les trois fichiers de notes partagés et `projects/`) puis lié.

**.agents/memory/.brain-link consigne le cerveau qui a été lié**

```json
{ "linked_brain": "D:\\workspace\\_brain", "brain_type": "portfolio", "linked_at": "2026-05-17T09:00:00Z" }

```

`brain_type` vaut `portfolio` (un `_brain/` d’espace de travail ou la variable d’environnement), `bmad-global` (`~/.bmad-plus/brain`) ou `claude-memory` (`~/.claude/memory`). Un cerveau de portefeuille garde sa propre organisation : les agents lisent d’abord son point d’entrée et n’y créent pas `identity.yaml` ni `projects/` sans y avoir été invités.

<a id="quick-start"></a>
## Démarrage rapide

1. **Installer le pack** Core est ajouté automatiquement. Seul Node.js 20 est nécessaire : la mémoire, ce sont des fichiers, sans base de données ni service vectoriel.

   ```sh
   npx bmad-plus install --packs memory
   ```
2. **Laisser Zecher indexer vos projets une fois** Zecher parcourt un dossier, détecte la stack et le statut de chaque projet et vous demande de confirmer, modifier ou ignorer chaque entrée avant de l’écrire.

   ```sh
   Zecher, scanne les projets dans ~/dev
   ```
3. **Commencer chaque session suivante par un rappel** Demandez l’état du projet avant de demander du travail.

   ```sh
   Zecher, où en étions-nous ?
   ```

<a id="examples"></a>
## Exemples à copier

<a id="example-memory-pack-scan"></a>
### Indexer vos projets

À lancer une fois après l’installation, puis à nouveau quand vous ajoutez des projets.

**Dans votre assistant IA**

```text
Zecher, scanne les projets dans ~/dev
```

**Ce que vous devriez obtenir** Zecher trouve les racines de projets grâce aux fichiers marqueurs (`package.json`, `Cargo.toml`, `go.mod`, `.git` et d’autres), en ignorant `node_modules`, `vendor`, `dist` et similaires, puis affiche un tableau : projet, stack, statut (actif sous 30 jours, en pause de 30 à 180, archivé au-delà), présence de BMAD+ et dernière modification. Pour chaque ligne vous choisissez confirmer, modifier, ignorer ou installer BMAD+ ; seuls les projets confirmés sont écrits dans `~/.bmad-plus/brain/projects/<hash>.yaml` et dans le lisible `projects-index.md`.

<a id="example-memory-pack-where-were-we"></a>
### Reconstruire le contexte d’une session à froid

À utiliser au début d’une session, dans un projet auquel vous n’avez pas touché depuis un moment.

**Dans votre assistant IA**

```text
Zecher, où en étions-nous ?
```

**Ce que vous devriez obtenir** Zecher lit `.agents/memory/context.md`, la dernière passation dans `.agents/memory/sessions/`, l’entrée du projet dans le cerveau global, les dix derniers commits git et `AGENTS.md` ou `CLAUDE.md`, puis donne un bref « état du projet » : ce qu’il est, sa stack, le dernier sujet traité, les questions ouvertes de la session précédente, les problèmes connus et les leçons.

<a id="example-memory-pack-handoff"></a>
### Clore une session par une passation

À utiliser avant de vous arrêter. « Passation » ne fait pas partie des formules fixes de Zecher : décrivez ce que vous voulez consigner et demandez vous-même la distinction entre fait et prévu.

**Dans votre assistant IA**

```text
Zecher, mets à jour la mémoire de ce projet à partir des changements et des vérifications réellement effectués. Distingue ce qui est développé, testé, publié et encore en attente. Consigne les décisions et les preuves utiles, archive les notes remplacées sans les supprimer et écris une courte consigne pour la prochaine session. Garde la mémoire dans ce projet et exclus les secrets.
```

**Ce que vous devriez obtenir** Zecher met à jour `context.md`, écrit un fichier de passation daté `.agents/memory/sessions/YYYY-MM-DD-<topic>.md` et une consigne de reprise. Le modèle de passation (`session-handoff.md`) a les rubriques What changed, Decisions made, Open questions, Next steps et Files modified ; la distinction entre développé, testé, publié et en attente, et la consigne de reprise qui nomme la prochaine tâche inachevée, viennent de votre demande, pas du modèle. Aucune entrée n’est détruite : les entrées remplacées sont archivées.

<a id="example-memory-pack-health-check"></a>
### Contrôler la santé de la mémoire

À utiliser quand les notes ont pu s’éloigner du code.

**Dans votre assistant IA**

```text
Zecher, contrôle de santé
```

**Ce que vous devriez obtenir** Un rapport : si les fichiers de mémoire existent et sont bien formés, les décisions encore marquées actives après plus de 90 jours (à revoir), les leçons qui reviennent (donc non apprises) et des statistiques comme les entrées par fichier et les dates de dernière mise à jour.

<a id="example-memory-pack-consolidate"></a>
### Consolider doublons et entrées périmées

Rien n’est modifié avant que vous approuviez chaque proposition.

**Dans votre assistant IA**

```text
Zecher, consolide la mémoire
```

**Ce que vous devriez obtenir** Trois phases. Audit : Zecher lit chaque fichier de mémoire et chaque note de session. Proposition : il indique combien de doublons, d’entrées périmées et de candidats à la remontée vers le cerveau global il a trouvés et vous demande d’approuver chaque changement. Exécution : les fusions approuvées gardent la version la plus riche, les entrées périmées sont déplacées en bas avec le préfixe `[ARCHIVED]`, et les entrées approuvées remontent vers le cerveau global.

<a id="example-memory-pack-what-do-we-know"></a>
### Demander ce que disent les notes sur un sujet

À utiliser avant de redécider quelque chose : il recoupe décisions, leçons, motifs et notes de session.

**Dans votre assistant IA**

```text
Zecher, qu’avons-nous décidé pour la stratégie d’authentification, et qu’est-ce qui s’est mal passé la dernière fois ?
```

**Ce que vous devriez obtenir** Une réponse tirée des fichiers de mémoire en recoupant décisions, leçons, motifs et notes de session. Les règles de Zecher demandent des dates ISO et des liens entre une leçon et la décision qu’elle mentionne. Vérifiez les entrées citées : si les notes ne disent rien du sujet, un assistant peut tout de même combler le vide, alors demandez-lui de nommer sa source.

<a id="example-memory-pack-promote-lesson"></a>
### Remonter une leçon vers le cerveau global

À utiliser quand une leçon s’est confirmée dans un second projet. Zecher demande toujours avant de déplacer quoi que ce soit.

**Dans votre assistant IA**

```text
Zecher, remonte la leçon « ne jamais lancer les migrations au démarrage » de ce projet vers le cerveau global.
```

**Ce que vous devriez obtenir** Zecher montre l’entrée et le fichier cible puis attend votre accord, avant de la déplacer dans le `lessons.md` global. Si votre cerveau est un cerveau de portefeuille, le déplacement suit sa propre gouvernance et ses conventions plutôt que l’organisation globale.

<a id="example-memory-pack-outcome-evidence"></a>
### Relier une note à un résultat vérifié

Avancé : seulement après qu’une tâche Nexus a été vérifiée de façon indépendante et acceptée. Cela consigne la provenance ; cela ne prouve pas que la note a causé le succès.

**Dans votre assistant IA**

```text
Zecher, consigne que la leçon sous « Cache invalidation » dans .agents/memory/lessons.md s’est appliquée à la tâche Nexus acceptée cache-fix de l’exécution small-change. Écris le fichier d’observation, lance bmad-plus mem observe dessus, puis montre bmad-plus mem outcomes.
```

**Ce que vous devriez obtenir** Le JSON d’observation nomme l’exécution, la tâche, une section de mémoire (fichier et titre), ses chemins de portée et votre interprétation. `mem observe` écrit un reçu dans `.bmad/memory/outcomes.ndjson` (pas dans le journal d’événements) ; `mem outcomes` liste les reçus encore éligibles, en excluant les périmés, remplacés ou contredits. Un `mem recall --ranking evidence` ultérieur donne un avantage borné aux preuves éligibles ; le rappel lexical par défaut ne change pas.

<a id="cli-companions"></a>
## Commandes CLI associées

**Commandes qui lisent ou écrivent la mémoire**

| Commande | Ce qu’elle fait |
| --- | --- |
| `bmad-plus memory status` | Santé de la mémoire du projet et du cerveau global |
| `bmad-plus memory export` | Écrit `bmad-brain-export-<YYYY-MM-DD>.md` dans le dossier du projet |
| `bmad-plus scan <path>` | Le scanner de projets en ligne de commande ; profondeur par défaut 4, actif sous 30 jours, en pause sous 180 |
| `bmad-plus mem recall`, `write`, `reinforce`, `observe`, `outcomes` | Interroger et mettre à jour le journal du projet ; le classement par preuves est facultatif avec `--ranking evidence` |

<a id="outputs"></a>
## Ce qu’il écrit et où

- Dans le projet : `.agents/memory/` (les quatre fichiers Markdown, `sessions/`, `.brain-link`) et, pour le journal de la CLI, `.bmad/memory/journal.ndjson` et `.bmad/memory/pattern-scores.json`, plus `.bmad/memory/outcomes.ndjson` pour les reçus de résultat.
- Dans votre dossier personnel, seulement si le cerveau global est utilisé : `~/.bmad-plus/brain/` avec `identity.yaml`, les notes partagées et l’index des projets.
- Réinstaller ou mettre à jour n’écrase jamais `decisions.md`, `lessons.md` ni `patterns.md` et ne supprime jamais `sessions/`.

<a id="data-and-prerequisites"></a>
## Flux de données et prérequis

Node.js 20 seulement. La mémoire est faite de fichiers locaux : le pack n’ouvre aucune connexion réseau et n’a aucun flux hors machine propre. Un service de rappel vectoriel ou RAG est un ajout facultatif, local et déployé séparément, qui ne fait pas partie du paquet npm, et `--provision-python` ne l’installe pas ; la mémoire Markdown et le scanner fonctionnent sans lui. Ce que votre assistant lit dans la mémoire part vers son modèle comme n’importe quel contexte : gardez les secrets hors des notes.

<a id="limits"></a>
## Limites et pièges

> **Attention · Rien ne s’exécute tout seul** Le pack fournit des instructions et des fichiers que votre assistant doit suivre. Aucun crochet n’est installé au début ni à la fin d’une session : une session qui s’arrête sans tour d’agent n’a pas de passation garantie. Demandez la passation avant de vous arrêter.

> **Remarque · Profondeur du scan** La commande `bmad-plus scan` descend de 4 niveaux par défaut (`--depth <n>` le change). Quand vous demandez un scan à Zecher dans la conversation, précisez la profondeur voulue pour obtenir le même résultat.

> **Remarque · La mémoire n’est pas une preuve** Les notes sont un contexte à confronter au code actuel, pas des faits. Les enregistrements de résultat relient une note à une tâche acceptée ; ils ne montrent pas que la note a amélioré les résultats de l’assistant, et la seule persistance non plus.

> **Remarque · Provenance** L’architecture de la mémoire s’inspire de la méthode de notes de portefeuille de l’auteur. Les quatre garde-fous de comportement (réfléchir avant de coder, simplicité d’abord, changements chirurgicaux, exécution guidée par l’objectif) sont adaptés d’un projet communautaire de conseils inspirés de Karpathy ; voir THIRD-PARTY-LICENSES.md.

**Voir aussi**

- [Les dix packs côte à côte](https://bmad-plus.rochetta.fr/fr/docs/packs/packs-overview/)
- [La mémoire, comment ça marche](https://bmad-plus.rochetta.fr/fr/docs/concepts/how-memory-works/)
- [Référence de la commande memory](https://bmad-plus.rochetta.fr/fr/docs/reference/cli-memory/)
- [Référence de la commande mem](https://bmad-plus.rochetta.fr/fr/docs/reference/cli-mem/)
- [Référence de la commande scan](https://bmad-plus.rochetta.fr/fr/docs/reference/cli-scan/)

[Documentation BMAD+](https://bmad-plus.rochetta.fr/fr/docs/) · [Packs](https://bmad-plus.rochetta.fr/fr/docs/packs/)

[Code sur GitHub](https://github.com/lrochetta/BMAD-PLUS)