Tu utilises Cursor pour coder. Au début d'une session, tu poses le décor : l'architecture, les choix faits, ce qu'il ne faut surtout pas casser. Quelques heures plus tard, nouvelle session, et il faut tout reposer. Le problème n'est pas Cursor en particulier : c'est la façon dont fonctionnent les assistants de code aujourd'hui.
Pourquoi Cursor oublie ton contexte entre les sessions
Comme tout assistant adossé à un modèle de langage, Cursor raisonne sur une fenêtre de contexte : le texte disponible à l'instant. Cette fenêtre est puissante mais éphémère. Elle se remplit pendant la session, puis se vide. Le modèle ne conserve pas ton projet d'une fois sur l'autre.
Les fonctions de contexte intégrées (indexation du repo, règles de projet) aident pour le code présent à l'écran, mais elles ne constituent pas une mémoire de tes décisions, de tes raisonnements, de ce que tu as écarté et pourquoi. Cette connaissance-là vit dans ta tête et dans tes notes, pas dans le code.
Les limites de la mémoire intégrée
Les mémoires intégrées aux outils ont trois limites récurrentes :
- Le périmètre. Elles connaissent surtout les fichiers, moins le pourquoi. Or l'essentiel de ton contexte, ce sont des décisions et des conventions, pas des lignes de code.
- La portabilité. Une mémoire enfermée dans un outil ne te suit pas ailleurs. Si tu changes d'assistant, tu repars de zéro.
- Le contrôle. Tu ne choisis ni ce qui est indexé, ni où ça part. Pour de la connaissance sensible, ce n'est pas neutre. On creuse ce point dans IA locale et confidentialité.
Le principe : une mémoire externe que ton assistant interroge
La solution durable ne dépend pas d'un outil précis. C'est un principe d'architecture : sors ta connaissance de la conversation, stocke-la dans un endroit stable, et rends-la interrogeable.
Cette mémoire externe a les mêmes propriétés que dans pourquoi ton IA oublie tout : elle persiste, elle est interrogeable, elle est sourcée. Un RAG local la construit à partir de tes notes et décisions, sur ta machine.
Reste à connecter cette mémoire à ton assistant. C'est là qu'intervient un standard ouvert : MCP.
MCP : le standard ouvert qui rend ça possible
MCP, pour Model Context Protocol, définit comment un assistant se branche sur des sources externes. Plutôt qu'une intégration propriétaire par outil, c'est un tuyau commun : une source de connaissance exposée via MCP peut être interrogée par n'importe quel client compatible. On détaille ce mécanisme dans MCP + mémoire.
L'intérêt pour toi : ta mémoire n'est pas prisonnière d'un éditeur. Elle vit à part, et c'est l'assistant qui vient la consulter.
Où en est Smart Brain
Soyons précis sur ce que fait réellement le produit, sans rien inventer. Smart Brain est un moteur de mémoire local : il indexe ton vault Obsidian (recherche hybride, graphe, reranking) et le rend interrogeable, en restant sur ta machine. Il s'expose via MCP, et le chemin aujourd'hui documenté de bout en bout est l'usage depuis Claude Code, dans ton éditeur.
Le principe, lui, est le même quel que soit le client : une mémoire externe, interrogeable, branchée via un standard ouvert. Si ton flux de travail passe par Cursor, c'est ce principe que tu cherches à mettre en place, plutôt que d'attendre que ta connaissance tienne dans une fenêtre de contexte.
Arrêter de réexpliquer
Le but n'est pas d'avoir une fenêtre toujours plus grande, mais de ne plus avoir à la remplir à la main. Le jour où ton assistant peut consulter tes décisions et tes conventions à la demande, tu cesses de payer le rituel de la recontextualisation.
Pour la mécanique complète d'une mémoire locale, vois la page technique et le silo RAG local.