Memory MCP : Donner une Mémoire Long-Terme aux Agents IA

Le Problème de l'Amnésie des Agents IA

Imaginez un collaborateur brillant — rapide, polyvalent, capable de lire 100 fichiers en quelques secondes. Mais chaque matin, il arrive au bureau sans aucun souvenir de la veille. Il relit les mêmes documents, redécouvre les mêmes bugs, pose les mêmes questions. C'est exactement ce que fait un agent IA sans mémoire persistante.

Chaque session de Claude Code commence tabula rasa. L'agent lit le CLAUDE.md, parcourt le dépôt, comprend le projet... puis la session se termine. Session suivante ? Amnésie totale. Les mêmes erreurs sont redécouvertes, les mêmes décisions sont re-prises, les mêmes leçons sont ré-apprises.

Le coût réel de l'amnésie

Sur le projet DailyTickers, une équipe de 5 agents travaille en parallèle : un pour le scanner nocturne, un pour le briefing quotidien, un pour l'hebdomadaire, un pour les analyses, et un pour la maintenance technique. Sans mémoire partagée, chacun redécouvrait indépendamment les mêmes pièges :

11 heures par mois perdues en redécouverte. Et ce ne sont que les 4 leçons les plus fréquentes — le projet en compte plus de 50.

La solution : une mémoire partagée

Memory MCP est un serveur MCP (Model Context Protocol) qui donne aux agents IA une mémoire long-terme persistante et partagée. Chaque leçon apprise, chaque décision prise, chaque règle établie est stockée une fois et accessible par tous les agents, dans toutes les sessions futures.

Source : Model Context Protocol — Introduction

Architecture du Système de Mémoire

Memory MCP s'insère dans l'écosystème MCP comme n'importe quel autre serveur d'outils. La différence : au lieu de fournir des données de marché ou des capacités de calcul, il fournit de la mémoire — la capacité de se souvenir et de partager des connaissances entre sessions.

Vue d'ensemble

Le graphe de mémoire

Les mémoires ne sont pas de simples documents isolés — elles forment un graphe de connaissances. Chaque mémoire est un nœud, et les liens entre mémoires sont des arêtes. Ce graphe permet de naviguer par contexte :

Workspaces : isolation par projet

Chaque projet a son propre workspace. Les mémoires d'un workspace sont invisibles pour les autres — sauf le workspace global qui est partagé transversalement.

Quand un agent appelle get_context(), il reçoit les mémoires pertinentes de son workspace plus les règles CRITICAL du workspace global. L'isolation empêche les fuites de contexte entre projets indépendants.

Source : MCP — Architecture

Le Protocole de Session : 3 Appels Obligatoires

Chaque session d'un agent connecté à Memory MCP commence par une séquence de 3 appels. Cet ordre n'est pas arbitraire — chaque étape dépend de la précédente.

Étape 1 : get_context — « Qu'est-ce que je dois savoir ? »

// L'agent décrit sa tâche — Memory MCP retourne les mémoires pertinentes
const context = await mcp.call('get_context', {
  query: 'scanner pipeline nocturne, risk gating, anti-dilution',
  workspace: 'dailystocks'
});

// Résultat : les mémoires les plus pertinentes, triées par score sémantique
// Les règles CRITICAL sont TOUJOURS incluses, quel que soit le query
// → "MCP Hard Stop", "No Hallucination", "Scanner Date Convention", etc.

La recherche sémantique utilise des embeddings vectoriels pour trouver les mémoires les plus proches du contexte de la tâche. Un agent qui travaille sur le scanner reçoit automatiquement les mémoires sur le pipeline, le risk gating, l'anti-dilution — sans avoir à les demander explicitement.

Étape 2 : get_delta — « Qu'est-ce qui a changé ? »

// Voir les changements depuis la dernière session
const delta = await mcp.call('get_delta', {
  workspace: 'dailystocks',
  since: '2026-06-21T18:00:00Z'  // dernière session
});

// Résultat : liste des mémoires créées, modifiées, ou supprimées
// → "project/orbit-mode: status changed to pausing"
// → "feedback/tiered-mcap: nouveau seuil $2B reject"
// → "rule/mcp-hard-stop: NOUVELLE RÈGLE CRITIQUE"

Sans le delta, un agent pourrait travailler avec des hypothèses périmées. Par exemple, si le mode Orbit est passé de live à pausing entre deux sessions, un agent qui ne consulte pas le delta continuerait à générer des entrées pour ce mode.

Étape 3 : get_inbox — « Est-ce qu'on me parle ? »

// Vérifier les messages et votes en attente
const inbox = await mcp.call('get_inbox', {
  workspace: 'dailystocks',
  agent_id: 'scanner-agent'
});

// Résultat possible :
// → vote: "Approuver le nouveau seuil mcap $2B ?" (2 pour, 1 contre, ton vote manque)
// → notify: "Agent daily a trouvé un conflit dans radar.json"
// → conflict: "Deux agents ont modifié data/analyses.json simultanément"

L'ordre compte

Contexte d'abord (savoir les règles), puis delta (savoir ce qui a changé), puis inbox (traiter la coordination). Inverser l'ordre — par exemple, traiter un vote avant de connaître le contexte — peut mener à des décisions incohérentes.

Ce protocole en 3 étapes prend moins de 2 secondes. Le coût est négligeable comparé aux minutes (ou heures) économisées en évitant la redécouverte.

Source : MCP — Transports (SSE)

Types de Mémoire : Rules, Feedback, Project, Reference

Toutes les mémoires ne se valent pas. Une règle immuable sur la sécurité des données n'a pas la même durée de vie qu'une note sur un bug en cours de résolution. Memory MCP distingue 4 types principaux, chacun avec son propre cycle de vie.

1. Rules — Les contraintes immuables

Les règles sont des mémoires qui s'appliquent dans toutes les sessions, quelles que soient la tâche ou l'agent. Elles sont injectées automatiquement par get_context(), marquées comme CRITICAL.

// Exemple réel — DailyTickers
await mcp.call('remember', {
  workspace: 'dailystocks',
  type: 'rule',
  title: 'MCP Hard Stop',
  content: `Si le MCP DailyTickers bloque (auth expirée, timeout, erreur réseau)
ou renvoie des données incohérentes (prix aberrants, NaN, valeurs stale > 48h) :
1. STOP IMMÉDIAT — ne pas continuer la génération
2. Ne JAMAIS substituer par des données inventées
3. Signaler au user : « MCP indisponible, tâche suspendue »
4. Reprendre uniquement quand le MCP est reconnecté`,
  tags: ['critical-rule', 'mcp', 'data-integrity']
});

Cette règle est née d'un incident réel : le 21 juin 2026, un agent fork a halluciné 100% des données d'une rétrospective H1 (META +32% au lieu de -15%, palmarès entièrement inversé). Le MCP était down, l'agent a inventé tous les chiffres. La règle a été écrite une seule fois. Depuis, aucun agent ne l'a enfreinte.

2. Feedback — Les leçons apprises

Les feedbacks capturent les corrections et validations de l'utilisateur. Ils incluent le pourquoi (l'incident déclencheur) et le comment appliquer (quand et où cette leçon s'applique).

// Structure d'un feedback
{
  type: 'feedback',
  title: 'Ne jamais inventer de données financières',
  content: `Règle : toujours vérifier via MCP avant de publier des chiffres.
**Why:** Session du 2026-06-14 — un fork a halluciné 52W range, cash,
et market cap pour ALT, IOVA, ALLR. Publié sans vérification.
**How to apply:** Avant chaque publication contenant des prix, YTD,
ou performances : QueryData + cross-check. Jamais WebSearch pour les prix.`
}

Quelques feedbacks réels du projet DailyTickers :

3. Project — Les décisions en cours

Les mémoires de type project capturent les décisions, initiatives et bugs actifs. Elles sont plus éphémères que les rules et feedbacks — un mode en déploiement finira par être live, un bug sera fixé.

// Exemple de mémoire projet
{
  type: 'project',
  title: 'Orbit Mode — paper-ramp depuis le 3 juin',
  content: `H20/3.5×ATR swing mode remplaçant Secured. Internal ID=secured, label=Orbit.
**Why:** OOS PF=0.53 sur n=11 pour l'ancien Secured. Besoin d'un mode swing long.
**How to apply:** Mode en status 'deploying'. Entries en paper-ramp seulement.
Review prévue le 3 juillet 2026. Ne pas passer en live avant.`
}

Le why est crucial pour les mémoires projet : sans lui, un agent futur ne saurait pas pourquoi le mode est en deploying (est-ce un choix ou un problème ?). Le contexte permet de prendre des décisions éclairées.

4. Reference — Les pointeurs externes

Les références sont des pointeurs vers des ressources en dehors du projet : URLs, dashboards, canaux de communication, API endpoints.

// Exemples de références
{ type: 'reference', title: 'MCP Gateway URL',
  content: 'gateway.dailytickers.com/mcp — pour le risk pipeline' }

{ type: 'reference', title: 'Grafana latency dashboard',
  content: 'grafana.internal/d/api-latency — vérifié par oncall' }

{ type: 'reference', title: 'Bugs pipeline dans Linear',
  content: 'Projet INGEST — tous les bugs pipeline sont trackés ici' }

La règle de déduplication

Avant de créer une mémoire, toujours appeler find_similar(). Si une mémoire similaire existe déjà (cosine similarity > 0.92), il faut la mettre à jour plutôt que d'en créer une nouvelle.

// Avant d'écrire
const similar = await mcp.call('find_similar', {
  content: 'MCP hard stop rule when gateway is down',
  workspace: 'dailystocks'
});

if (similar.results[0]?.score > 0.92) {
  // Mettre à jour la mémoire existante
  await mcp.call('update_memory', { id: similar.results[0].id, ... });
} else {
  // Créer une nouvelle mémoire
  await mcp.call('remember', { ... });
}

Source : MCP — Tools specification

Coordination Multi-Agents : Claims, Votes et Notifications

La mémoire seule ne suffit pas quand plusieurs agents travaillent en parallèle. Deux agents qui éditent le même fichier simultanément produisent des conflits. Deux agents qui prennent des décisions contradictoires créent de l'incohérence. Memory MCP fournit des primitives de coordination pour résoudre ces problèmes.

claim_topic — Verrouillage de ressource

Avant de modifier un fichier ou un domaine partagé, un agent « réserve » le sujet. Les autres agents voient que c'est occupé et attendent ou travaillent ailleurs.

// Agent Scanner commence à travailler sur le scanner du jour
await mcp.call('claim_topic', {
  topic_name: 'scanner-20260622',
  agent_id: 'scanner-agent'
});

// ... le scanner travaille (screening, enrichment, publication) ...

// Travail terminé — relâcher le topic
await mcp.call('release_topic', {
  topic_name: 'scanner-20260622'
});

Si l'agent B essaie de claim_topic sur le même sujet pendant que A le détient, il reçoit une erreur explicite avec l'identité de l'agent qui le détient et depuis quand. Pas de course silencieuse, pas de données corrompues.

vote — Décisions collectives

Certaines décisions ne devraient pas être prises par un seul agent. Le mécanisme de vote permet de soumettre une proposition et de collecter les avis.

// Un agent propose un changement de configuration
await mcp.call('vote', {
  memory_id: 'mem_tiered_mcap_threshold',
  verdict: 'approve',
  comment: 'Le seuil $2B reject semble correct pour les sub-micro-caps'
});

// Résultat collecté : 3 pour, 1 contre → majorité atteinte → décision appliquée

notify — Communication inter-agents

Pour envoyer un message direct à un agent spécifique, sans que les autres ne le voient :

// L'agent scanner prévient l'agent daily
await mcp.call('notify', {
  agent_id: 'daily-agent',
  message: 'Scanner publié avec 8 setups. MRVL en tête, score 94. radar.json mis à jour.'
});

Scénario réel : scanner + daily en parallèle

Source : MCP — Tool invocation

Workflows et Tâches : Orchestration Persistante

Les tâches et workflows de Memory MCP se distinguent des outils natifs de Claude Code par une propriété essentielle : ils persistent entre les sessions et sont visibles par tous les agents.

Tâches persistantes

Une tâche créée dans la session 1 peut être reprise et complétée dans la session 5, par un agent différent. L'historique complet est conservé.

// Session 1 — Agent A crée une tâche
await mcp.call('create_task', {
  workspace: 'dailystocks',
  title: 'Migrer les 5 modes vers le broker-simulator',
  description: 'Backfill dynamic, balanced, bull, turbo, secured via export-to-simulator.js',
  assignee: 'infra-agent'
});

// Session 3 — Agent B reprend la tâche
await mcp.call('update_task', {
  task_id: 'task_migrate_modes',
  status: 'in_progress',
  comment: 'Dynamic et balanced backfillés. Bull en cours.'
});

// Session 5 — Agent C termine
await mcp.call('update_task', {
  task_id: 'task_migrate_modes',
  status: 'completed',
  comment: '5/5 modes migrés. Reconciliation 0% divergence.'
});

Claude Code Tasks vs Memory Tasks

Workflow DAGs

Pour les processus complexes avec des dépendances entre étapes, Memory MCP supporte les DAG (Directed Acyclic Graphs) :

// Définir un pipeline comme un DAG
await mcp.call('create_workflow_dag', {
  workspace: 'dailystocks',
  name: 'nightly-pipeline',
  nodes: [
    { id: 'scan', task: 'Scanner nocturne', deps: [] },
    { id: 'retro', task: 'Rétrospective', deps: ['scan'] },
    { id: 'daily', task: 'Daily briefing', deps: ['scan'] },
    { id: 'radar', task: 'Mise à jour radar', deps: ['scan', 'daily'] },
    { id: 'weekly', task: 'Weekly review', deps: ['scan', 'daily'] }
  ]
});

// Le workflow respecte les dépendances : radar attend scan + daily,
// weekly attend scan + daily. Scan est la racine de tout.

Skills : playbooks versionnés

Les skills sont des procédures stockées dans la mémoire. Quand un agent demande « comment lancer un scanner ? », Memory MCP retourne le playbook complet, versionné :

// Récupérer un skill
const skill = await mcp.call('render_skill', {
  slug: 'scanner-pipeline'
});

// Résultat : les 10 étapes du pipeline scanner, dans l'ordre,
// avec les commandes exactes, les gotchas connus, et les liens
// vers les mémoires pertinentes.

Les skills sont versionnés — quand le pipeline évolue, le skill est mis à jour une fois et tous les agents utilisent la nouvelle version.

Source : MCP — Resources

Les Gains Concrets

La théorie est élégante, mais les résultats sont-ils mesurables ? Sur DailyTickers, Memory MCP est actif depuis plusieurs mois. Voici ce que les données montrent.

Avant / Après

Gain #1 : Zéro redécouverte

Le gain le plus impactant est l'élimination de la redécouverte. Un bug trouvé une fois, documenté via remember(), n'est jamais re-trouvé. L'exemple emblématique : la règle MCP Hard Stop a été écrite le 21 juin 2026 après l'incident de la rétro H1. Depuis, aucun des 5+ agents n'a inventé de données quand le MCP était down. La règle est injectée dans chaque session, sans exception.

Gain #2 : Cohérence parfaite

Sur un projet comme DailyTickers avec des dizaines de conventions (format de date, structure HTML, convention de nommage des dossiers, taxonomie de tags), maintenir la cohérence entre 5 agents est un cauchemar sans mémoire partagée. Avec Memory MCP, les conventions sont des mémoires de type feedback : écrites une fois, appliquées partout.

Gain #3 : Onboarding instantané

Quand un nouvel agent se connecte au workspace, il appelle get_context() et reçoit immédiatement toutes les règles du projet, les décisions en cours, les conventions, et les feedbacks. Pas besoin de lire 60 KB de CLAUDE.md ni de parcourir l'historique git — la mémoire fournit le contexte pertinent, trié par pertinence.

Gain #4 : Audit trail

Chaque mémoire a un historique : date de création, dernière mise à jour, agent créateur, liens vers d'autres mémoires. Quand une décision est contestée, on peut remonter à la source : qui a décidé quoi, quand, et pourquoi.

Source : Model Context Protocol — Introduction

Intégrer Memory MCP dans votre Projet

Intégrer Memory MCP dans un projet existant prend quelques minutes. Le gain est immédiat dès la première mémoire enregistrée.

Setup en une commande

# Ajouter Memory MCP à votre configuration Claude Code
claude mcp add memory --transport sse --url https://memory.hbfs-cloud.com/mcp

# Ou en local pour le développement
claude mcp add memory-local --transport sse --url http://localhost:8083/mcp

# Vérifier que le serveur est connecté
claude mcp list

Une fois connecté, tous les outils de Memory MCP sont disponibles dans vos sessions Claude Code. L'agent peut appeler remember(), get_context(), claim_topic(), etc. — directement, sans configuration supplémentaire.

Premiers pas recommandés

Ne cherchez pas à tout documenter d'un coup. Commencez par les mémoires à plus fort impact :

Le protocole dans CLAUDE.md

Ajoutez le protocole de session à votre CLAUDE.md pour que chaque agent le suive automatiquement :

## Memory MCP
URL : memory.hbfs-cloud.com/mcp

**À chaque début de session :**
1. get_context(query=<tâche>, workspace=<projet>)
2. get_delta(workspace=<projet>, since=<dernière_session>)
3. get_inbox(workspace=<projet>, agent_id=<id>)

**Avant d'écrire :** find_similar() pour détecter les doublons.

Maintenance

Les mémoires ne sont pas éternelles. Les décisions projet deviennent obsolètes, les références changent. Memory MCP fournit get_stale_memories() pour identifier les mémoires qui n'ont pas été consultées depuis longtemps et qui pourraient être périmées. Nettoyez régulièrement pour garder un graphe pertinent.

La mémoire ne rend pas l'agent plus intelligent — elle le rend moins amnésique. Et dans un environnement où 5 agents travaillent en parallèle sur un projet financier complexe, l'amnésie est le défaut le plus coûteux qu'on puisse corriger.

Articles liés

Source : MCP — Server quickstart