Comment j'ai donné une mémoire persistante à Claude : du bricolage markdown au MCP
En 2025 j'ai bricolé une solution avec des fichiers markdown pour éviter de réexpliquer mon contexte à chaque session. Ca marchait, jusqu'à un point. Voici ce que j'ai appris, les limites que j'ai atteintes, et ce que j'ai finalement construit.
Comment j'ai donné une mémoire persistante à Claude
> Mise à jour juin 2026 : cet article a été réécrit. En 2025 j'avais publié une méthode avec des fichiers markdown. Elle fonctionnait, jusqu'à un point. La suite explique pourquoi j'ai fini par construire quelque chose de différent.
Le problème, toujours d'actualité
Tu connais ce scénario.
Session 1 avec Claude :
- Toi : "Je travaille sur une API FastAPI avec MySQL, déployée sur un VPS..."
- Claude : comprend tout, code parfaitement
Session 2, le lendemain :
- Toi : "Continue le travail d'hier"
- Claude : "Je n'ai pas de contexte sur votre projet. Pouvez-vous me décrire..."
- Toi : 😤
Ce n'est pas un bug. C'est la nature des LLMs : pas de mémoire entre sessions. Chaque conversation repart de zéro.
Avec un projet complexe (API, frontend, Docker, VPS), réexpliquer le contexte à chaque session prend 10 à 15 minutes. Sur une semaine, c'est une heure perdue.
La méthode markdown (2025)
Ma première réponse : un dossier /AI/memory/ dans chaque projet, avec des fichiers markdown lus par l'IA en début de session.
mon-projet/
├── AI/
│ └── memory/
│ ├── project_context.md
│ ├── tech_stack.md
│ └── code_registry.jsonEn début de session : "Lis les fichiers dans /AI/memory/ pour charger le contexte."
En 30 secondes, Claude connaissait le projet, les conventions, les décisions d'architecture. Ca marchait.
Les limites que j'ai atteintes
Après quelques mois d'usage intensif, les failles sont apparues.
Maintenance manuelle. Chaque nouveau endpoint, chaque décision d'architecture : il fallait penser à mettre à jour les fichiers. Pour un cerveau TDA, "ne pas oublier de mettre à jour" est précisément le problème de départ.
Désynchronisation. Quelques semaines après, les fichiers markdown décrivaient une architecture qui avait évolué. L'IA travaillait parfois avec des infos périmées sans que je m'en aperçoive.
Le copier-coller persistait. Il fallait encore copier le contenu dans la session, ou demander à l'IA de lire les fichiers locaux. Ce n'était pas fluide.
Fragmentation. Plusieurs projets, plusieurs dossiers /AI/memory/, aucune vue d'ensemble. Impossible de basculer entre contextes sans recharger manuellement.
La méthode traitait le symptôme, pas la cause.
MCP change les règles du jeu
En 2025, Anthropic a publié le Model Context Protocol (MCP), un standard ouvert qui définit comment un outil IA peut interagir avec des sources de données externes de façon structurée.
Concrètement : au lieu de copier-coller des fichiers markdown, l'IA dispose d'outils standardisés pour lire et écrire dans une base de données persistante. Elle appelle un outil, obtient le contexte. Elle appelle un autre, crée une note. Sans que tu interviennes.
Ce n'est plus "l'IA lit des fichiers que j'ai préparés". C'est "l'IA interagit directement avec ma base de connaissances."
La différence est fondamentale.
Ce que j'ai construit : DockSky
J'ai répondu à ce problème en construisant DockSky : une application de bureau avec un serveur MCP intégré.
Quand Claude (ou Cursor, ou Copilot) se connecte à DockSky via MCP, il dispose de 17 outils natifs :
- lire la liste de mes projets
- charger le contexte d'un projet spécifique
- lire mes facettes (décisions, patterns, infos techniques)
- créer une entrée dans mon journal
- mettre à jour une action ou une étape
La base est persistante. Rien à copier. Rien à maintenir manuellement : quand je demande à l'IA de noter quelque chose, elle l'écrit directement dans ma structure DockSky. Et le contexte est toujours à jour, parce que c'est la même base que j'utilise au quotidien.
Résultats concrets
Ce que j'observe après plusieurs mois de dogfooding :
- Démarrer une session sur un projet en cours prend moins de 30 secondes
- L'IA ne me redemande jamais "rappelle-moi l'architecture"
- Les décisions notées dans une session sont disponibles à la suivante
- Plus aucun fichier markdown à maintenir
La méthode markdown de 2025 était une bonne réponse au mauvais niveau. Le bon niveau, c'est la persistance native.
Si tu veux tester
DockSky est en beta fermée. La liste d'attente est ouverte sur [docksky.fr](https://docksky.fr). La page [MCP](/mcp) détaille les 17 outils disponibles et comment connecter Claude ou Cursor en moins de 5 minutes.