Claude Code, Cursor, et les autres assistants de code se ressemblent sur un point souvent passé sous silence : ils oublient. Chacun a ses qualités propres, mais tous partagent le même angle mort, l'amnésie entre sessions. La bonne nouvelle, c'est que la solution est elle aussi commune, et qu'elle ne dépend pas de l'outil que tu préfères.
Un angle mort partagé
Quel que soit l'assistant, le moteur est un modèle de langage qui raisonne sur une fenêtre de contexte. Cette fenêtre est volatile : remplie pendant la session, vidée à la fin. Aucun de ces outils ne « retient » ton projet d'une fois sur l'autre, c'est structurel, comme expliqué dans pourquoi ton IA oublie tout.
Les fonctions de contexte intégrées varient d'un outil à l'autre et évoluent vite, mais le besoin de fond reste : une mémoire de tes décisions, conventions et notes, qui dure. On en discute, côté mémoires intégrées, dans la mémoire de Cursor / ChatGPT suffit-elle ?.
Le principe commun : une mémoire externe
La solution durable ne consiste pas à attendre une fonctionnalité par outil, mais à appliquer un principe d'architecture indépendant de l'assistant :
- ta connaissance vit à l'extérieur de la conversation, dans une source stable ;
- elle est interrogeable par un retrieval qui sert le bon passage ;
- l'assistant la consulte à la demande, au lieu que tu la recolles.
Ce principe est le même pour Claude Code, Cursor ou un autre. Ce qui change d'un outil à l'autre, c'est la façon de connecter cette mémoire. Et là, un standard ouvert fait toute la différence.
MCP : un branchement indépendant de l'outil
MCP, pour Model Context Protocol, est le standard ouvert qui permet à un assistant de se brancher sur des sources externes. Au lieu d'une intégration propriétaire par outil, c'est une prise commune : une mémoire exposée via MCP peut être interrogée par un client compatible. On le détaille dans MCP + mémoire.
L'intérêt : ta mémoire ne dépend pas d'un éditeur. Elle vit à part, et c'est l'assistant qui vient la consulter.
Où en est le produit, sans rien inventer
Soyons précis pour ne pas survendre. Smart Brain est un moteur de mémoire local : il indexe ton vault (recherche hybride, graphe, reranking, mesuré à Hit@1 de 0,909, voir la page technique) et l'expose via MCP. Le chemin documenté de bout en bout aujourd'hui est l'usage depuis Claude Code, dans ton éditeur.
Pour les autres assistants, je reste sur le principe et non sur une promesse d'intégration native : le pattern est le même, une mémoire externe interrogeable via un standard ouvert. Si ton flux passe par Cursor ou un autre, c'est ce principe que tu cherches à mettre en place, comme discuté dans contexte persistant pour Cursor. Vérifie toujours la compatibilité concrète côté client.
Local, par principe
Quel que soit l'assistant, garder la mémoire en local change la nature du montage : ta connaissance ne part pas dans un cloud, le retrieval tourne chez toi (Ollama plus base vectorielle ChromaDB). MCP transmet la requête, mais ta connaissance reste sur ta machine. On développe ce point dans IA 100% locale.
Ce qu'il faut retenir
Ne choisis pas ta mémoire en fonction de ton assistant du moment. Choisis le principe : une mémoire externe, interrogeable, branchée via un standard ouvert, en local. Il survit aux changements d'outil et te rend indépendant.
Pour mettre ça en place, vois comment donner une mémoire à un agent IA, la page technique et les offres.