Mémoire Agent Portable : Transportez le Contexte entre Claude Code, Cursor, Codex et Gemini

Passez de Claude Code à Cursor en cours de projet et votre agent oublie tout : la décision d'architecture prise la semaine dernière, le bug que vous avez déjà corrigé, la façon dont vous aimez rédiger vos commits. Le contexte n'a pas voyagé — il est resté bloqué dans le premier outil. La mémoire agent portable est le modèle qui résout ce problème : une couche mémoire unique partagée par vos agents, pour que le contexte vous suive entre Claude Code, Cursor, Codex et Gemini CLI au lieu de repartir de zéro à chaque changement d'outil.

Ce guide explique ce qu'est la mémoire agent portable, les principales approches pour la construire, leurs compromis respectifs, et comment éviter de vous retrouver à nouveau enfermé dans une dépendance propriétaire.

Qu'est-ce que la mémoire agent portable ?

La mémoire agent portable est un référentiel de contexte de projet durable — décisions, correctifs, conventions et faits — qui vit en dehors de tout agent unique et est lisible par tous. Au lieu que chaque outil conserve ses propres notes cloisonnées, vos agents lisent et écrivent dans un pool partagé.

Le problème qu'elle résout est la dépendance propriétaire. La mémoire intégrée lie votre contexte à un seul agent de développement, et il reste en arrière quand vous changez d'outil. Un excellent CLAUDE.md ne sert à rien pour Cursor ; les blocs-notes de Cursor ne servent à rien pour Codex. La plupart des équipes utilisent désormais plus d'un agent, ce contexte perdu représente donc une charge réelle et récurrente.

La portabilité signifie deux choses :

• Multi-outils : la même mémoire fonctionne dans Claude Code, Codex, Cursor, Gemini CLI, et tout autre outil capable de la lire.
• Sans dépendance propriétaire : vous pouvez quitter un outil — ou la couche mémoire elle-même — sans reconstruire votre base de connaissances.

Pourquoi le contexte se perd lors d'un changement d'outil

Chaque agent stocke la mémoire dans son propre format et emplacement. Claude Code dispose d'un système de mémoire ; Cursor en a un autre. Quand différents agents savent des choses différentes, la session suivante repose une question à laquelle vous avez déjà répondu, ou répète une erreur déjà commise.

Le problème fondamental est que la mémoire plate et spécifique à un outil ne passe pas à l'échelle entre agents. Une note écrite pour un client est invisible pour le suivant. Multipliez cela par chaque changement d'outil, chaque nouvelle fenêtre de chat et chaque membre de l'équipe avec une configuration différente, et vous obtenez le même contexte reconstruit encore et encore.

Les principales approches de la mémoire portable

Il existe trois grands modèles utilisés aujourd'hui. Ils diffèrent principalement dans la façon dont ils stockent le contexte et comment ils se connectent aux agents.

1. Serveurs de mémoire basés sur MCP

L'approche la plus courante connecte un serveur de mémoire à chaque agent via le Model Context Protocol (MCP). MCP offre à tout outil un moyen standard de se connecter à n'importe quel agent, de sorte qu'une seule couche mémoire peut servir de nombreux clients via le même protocole.

Des projets open-source comme agentmemory et Memorix empruntent cette voie. agentmemory se décrit comme une mémoire persistante pour Claude Code, Cursor, Gemini CLI, Codex CLI et tout client MCP, installé globalement et enregistré comme serveur MCP. Memorix est une couche mémoire partagée en local d'abord (local-first) qui conserve la mémoire du projet sous le projet Git plutôt qu'à l'intérieur d'une fenêtre de chat ou d'un outil.

L'avantage : configurez-le une fois, et chaque agent compatible MCP voit la même mémoire. Le compromis est un service en cours d'exécution et une dépendance au support MCP dans chaque client.

2. Coffres-forts de fichiers plats neutres vis-à-vis des fournisseurs

Une approche plus légère supprime entièrement les bases de données et les serveurs. Agent Memory OS est un système de mémoire portable construit à partir de fichiers Markdown simples et de quelques petits scripts, sans base de données ni service à exécuter. Il fonctionne avec Claude Code, Codex, Gemini CLI, Cursor, ou tout autre outil capable de lire des fichiers, et conserve un fichier d'identité délibérément neutre vis-à-vis des fournisseurs pour que changer d'outil ne signifie pas reconstruire votre configuration.

La récupération ici est généralement lexicale — un routeur classe les notes Markdown par rapport à votre requête et renvoie les plus pertinentes — plutôt que par embeddings (représentations vectorielles). L'avantage est la simplicité, la portabilité et l'absence d'infrastructure. Le compromis est un rappel moins sophistiqué qu'un système basé sur des vecteurs pour les grandes bases de connaissances.

3. Couches mémoire hébergées / basées sur des protocoles

Un troisième groupe propose une mémoire gérée avec des fonctionnalités comme le chiffrement, le stockage vérifiable et des SDK. Ces solutions visent à être la couche durable et portable à laquelle les agents se connectent, souvent avec à la fois un SDK et une intégration MCP pour que le contexte voyage entre les applications et les sessions.

L'avantage est moins de travail opérationnel et plus de fonctionnalités intégrées ; le compromis est de faire confiance à un service externe avec votre contexte et de surveiller un nouveau type de dépendance propriétaire — cette fois au niveau de la couche mémoire elle-même.

Comment choisir — et éviter de vous enfermer à nouveau

L'objectif de la portabilité est la liberté de changer. Préservez-la :

• Privilégiez les formats ouverts. Les coffres-forts Markdown et les schémas documentés sont faciles à lire, migrer et inspecter. Les formats propriétaires opaques ne le sont pas.
• Conservez un chemin d'exportation. Quelle que soit la solution adoptée, confirmez que vous pouvez exporter votre mémoire et la déplacer ailleurs.
• Rattachez la mémoire au projet, pas à l'outil. La mémoire qui vit sous votre projet Git voyage avec le dépôt et survit aux changements d'outil, aux changements d'IDE et aux nouvelles fenêtres de chat.
• Traitez la règle du « troisième fois » comme un signal. Quand un agent fait la même erreur une troisième fois, c'est une note de mémoire manquante, pas un mauvais modèle. Intégrez les décisions et correctifs récurrents dans la mémoire durable.
• Ne stockez pas de secrets. Enregistrez où un secret se trouve et comment il est utilisé — jamais la valeur elle-même.

Un moyen rapide de comparer les options :

Vers quoi cela se dirige

La mémoire portable devient rapidement une attente de base plutôt qu'une nouveauté. À mesure que les équipes font tourner plusieurs agents côte à côte — un pour le travail en terminal, un dans l'IDE, un pour les scripts — la couche mémoire se transforme en infrastructure partagée, un peu comme le contrôle de version. Les gagnants seront les couches qui restent ouvertes, portables et faciles à quitter.

Construisez un workflow multi-agents qui se souvient

La mémoire portable est plus importante quand vous faites tourner plusieurs agents simultanément — ce qui est exactement ce que fait une équipe d'agents multi-agents. Eigent est une application de bureau "Cowork" open-source et locale qui coordonne une équipe d'agents IA sur des workflows réels. Elle ajoute une Mémoire que vous pouvez délimiter à l'utilisateur, à l'espace de travail ou à la session, ainsi que des exécutions durables multi-tours, pour que le contexte qui mérite d'être conservé soit transmis intentionnellement plutôt que de se perdre en chemin. Si vous en avez assez de réexpliquer votre projet à chaque changement d'outil, téléchargez Eigent et offrez à vos agents un espace partagé pour se souvenir.