Méthodologie — Mémoire persistante de Claude¶

Comment Claude se souvient du contexte LObsTer entre les sessions.

Pourquoi une mémoire ?¶

Claude est stateless par défaut : à chaque nouvelle session, il oublie tout.

Pour un projet continu comme LObsTer (multi-semaines, multi-sessions, règles spécifiques), c'est inacceptable. Claude doit se souvenir :

Qui sont Marc et Cyrille
Ce qui a été fait, ce qui est en cours
Les règles validées (ex : "étude Cyrille = source de vérité")
Les corrections déjà reçues (ex : "ne jamais extrapoler une valeur")
Les pointeurs vers les systèmes externes (ex : "ANIL est dans raw/ANIL/")

Architecture de la mémoire¶

flowchart TB
    subgraph "~/.claude/"
        CLAUDE_MD[CLAUDE.md
instructions globales]
        PROJECTS[projects/-home-datadactu/
memory/]
        WORK[MEMORY/WORK/
PRDs actifs]
        LEARNING[MEMORY/LEARNING/
reflections.jsonl]
    end

    subgraph "memory/"
        INDEX[MEMORY.md
index chargé à chaque session]
        USER[user_*.md
rôle, préférences Marc]
        FEEDBACK[feedback_*.md
corrections reçues]
        PROJECT[project_*.md
état projet, uploads]
        REFERENCE[reference_*.md
liens externes]
    end

    PROJECTS --> INDEX
    INDEX --> USER
    INDEX --> FEEDBACK
    INDEX --> PROJECT
    INDEX --> REFERENCE

    CLAUDE_MD -.->|loaded every session| SESSION[Session Claude]
    INDEX -.->|loaded every session| SESSION
    WORK -.->|PRD courant| SESSION

    classDef global fill:#0d1f3c,stroke:#e87722,color:#fff
    classDef mem fill:#e87722,stroke:#0d1f3c,color:#fff
    classDef session fill:#2a7f7f,stroke:#0d1f3c,color:#fff

    class CLAUDE_MD,WORK,LEARNING global
    class INDEX,USER,FEEDBACK,PROJECT,REFERENCE mem
    class SESSION session

Les 4 types de mémoire¶

1. User memories¶

Contenu : rôle, métier, préférences de Marc et Cyrille.

Quand écrite : quand Claude apprend un détail sur qui est l'utilisateur.

Exemples : - "Marc est un data scientist actuellement focus sur l'observatoire territorial" - "Marc utilise un PC, le serveur est un Proxmox" - "Cyrille est co-fondateur et urbaniste-data expert"

2. Feedback memories¶

Contenu : corrections reçues + validations de choix non évidents.

Quand écrite : - Quand Marc corrige Claude ("non, pas comme ça") - Quand Marc valide un choix surprenant ("oui exactement, continue comme ça")

Format obligatoire : ``` Règle exprimée.

Why: raison (souvent incident passé ou préférence forte) How to apply: quand/où la règle s'applique ```

Exemples : - "DVF import batch size = 50 000 max (crash à 100K)" - "Proposer proactivement les worktrees multi-agents sur refonte frontend" - "Cyrille = source de vérité pour toute étude" - "Red-team : sécu/perf = ISC, stratégie = questions ouvertes"

3. Project memories¶

Contenu : état projet qui change rapidement (qui fait quoi, uploads, décisions).

Quand écrite : quand Claude apprend qui fait quoi, pourquoi, avant quand.

Exemples : - "ANIL uploaded 2026-04-24 at raw/ANIL/ (4 CSV + 2 PDF)" - "Sprint 6 études prioritaires mai 2026 : DEM01, LOG01, SOC02, LOG05, DEM02, SOC06" - "Data reorg 2026-03-22 : nouvelle structure thématique raw/"

Dates absolues

Claude convertit toujours les dates relatives en absolues ("jeudi" → "2026-03-05") pour rester interprétable après le temps.

4. Reference memories¶

Contenu : pointeurs vers systèmes externes.

Quand écrite : quand Marc mentionne un outil externe utilisé par l'équipe.

Exemples : - "Bugs tracking : Linear project 'INGEST'" - "Dashboard ops : grafana.internal/d/api-latency"

MEMORY.md — l'index¶

Fichier toujours chargé en session (plafond 200 lignes).

Contient une ligne par mémoire, format :

markdown - [fichier.md](fichier.md) — description courte 150 chars max

Exemple actuel (extrait) :

markdown - [project_anil_uploaded.md](project_anil_uploaded.md) — ANIL MEF-DHUP uploaded 2026-04-24 - [feedback_cyrille_studies_source_of_truth.md](feedback_cyrille_studies_source_of_truth.md) — Cyrille HTML = spec - [feedback_red_team_hybrid_handling.md](feedback_red_team_hybrid_handling.md) — Red-team : ISC vs questions - [project_sprint_6_etudes.md](project_sprint_6_etudes.md) — Sprint 6 études prioritaires mai 2026

Ce qui n'est JAMAIS sauvegardé¶

Code conventions / architecture / paths → dérivables en lisant le code
Git history / blame → git log est autorité
Debugging fixes → le fix est dans le code, le commit explique
Contenu déjà dans CLAUDE.md
Détails éphémères de session en cours

Cette règle est stricte — même si Marc demande "sauvegarde ça", Claude pose la question : qu'est-ce qui est surprenant / non-évident là-dedans ?

Gestion du temps¶

Les mémoires ont une date. Elles peuvent vieillir.

Avant d'agir sur une mémoire, Claude vérifie si elle est toujours valide :

Si la mémoire cite un fichier : vérifier qu'il existe
Si la mémoire cite une fonction/flag : grep
Si l'utilisateur va agir sur la reco : vérifier maintenant

"La mémoire dit que X existe" ≠ "X existe maintenant".

Réflexions (LEARNING)¶

À la fin de chaque session Standard+, Claude append une ligne JSONL :

json {"timestamp":"2026-04-24T15:32:00+02:00","effort_level":"deep","task_description":"...","criteria_count":51,"criteria_passed":51,"reflection_q1":"...","within_budget":true}

Ces réflexions alimentent :

MineReflections — pattern mining sur les succès/échecs
AlgorithmUpgrade — amélioration du cadre PAI

Claude apprend de ses propres erreurs en relisant ces JSONL périodiquement.

Pour Marc : comment interagir avec la mémoire¶

Demander de se souvenir¶

"Souviens-toi que X est le cas désormais"

Claude crée la mémoire appropriée (user/feedback/project/reference).

Demander d'oublier¶

"Oublie que Y"

Claude trouve la mémoire et la supprime (+ retire de MEMORY.md).

Inspecter¶

"Qu'est-ce que tu sais de moi ?" / "Qu'est-ce que tu te souviens de ce projet ?"