Des projets de code qui survivent à la fenêtre de contexte.
La dixième fois que vous expliquez pourquoi vous avez abandonné Redis, ce n'est pas de l'ingénierie. C'est de la surcharge — et elle s'accumule à chaque session que vous démarrez.
Le problème, précisément
Chaque conversation avec un assistant part de rien. Le début de chaque session de travail est donc le même récital : la stack, les contraintes, la décision prise en mars et la raison pour laquelle vous l'avez prise. Sautez le récital et l'assistant propose gaiement ce que vous aviez déjà rejeté — rouvrir des questions tranchées, c'est ce qu'un contexte vierge fait de mieux.
La plupart des gens s'en sortent en collant un document vivant dans chaque session. Ce document, c'est de la mémoire, gérée à la main, qui se périme exactement de la façon que personne ne remarque avant que ça morde.
Ce que Varven fait d'une décision
Quand quelque chose qui mérite d'être gardé se produit dans une session — une décision et son raisonnement, une contrainte découverte à la dure, une correction que vous avez faite quand l'assistant s'est trompé — c'est déposé comme une couche dans votre coffre : du Markdown simple, sur votre machine, avec son origine et sa date intactes.
---
type: decision
scope: atlas
trust: trusted
created: 2026-03-14
---
SQLite over Postgres for the API. One writer by design,
and litestream covers replication. Revisit only if a
second writer ever actually exists.Six mois plus tard, « pourquoi pas Postgres ? » trouve sa réponse dans l'archive — avec la date, le raisonnement, et la condition qui justifierait de rouvrir la décision. Ce dernier point fait la différence entre mémoire et dogme.
Les corrections tiennent
La mémoire la plus utile dans un projet de code, c'est la correction : on a essayé, ça a cassé, voilà ce qui a cassé. Dans Varven, les corrections ne se périment jamais — elles sont vraies du seul fait d'avoir été dites — et l'assistant arrête donc de reproposer la stratégie de migration qui a mis staging à terre.
Un projet ou douze
Chaque projet est un périmètre. Une recherche peut rester à l'intérieur d'un seul, pour que les conventions de votre projet perso ne débordent jamais sur les réponses du travail. Les préférences valables partout — des diffs plutôt que des fichiers entiers, expliquer le pourquoi — vivent dans un périmètre global dont chaque projet hérite. Quand une information en remplace une plus ancienne, l'ancienne couche est marquée comme remplacée plutôt que supprimée : toujours interrogeable, donc « quand est-ce qu'on a changé ça ? » a une réponse.
À quoi ça ressemble en pratique
Vous connectez votre assistant une fois, via MCP. Au début d'une session, il récupère un briefing : contraintes épinglées, préférences permanentes, corrections récentes. En cours de session, il cherche quand une question touche au passé, et lit la chronologie quand vous demandez ce qui a changé depuis mardi. Vous continuez à travailler ; l'archive s'accumule en dessous.
Le plan qu'il faut
Tout ce qui est sur cette page tourne sur le plan gratuit : mémoire illimitée, une machine, clients IA de bureau. Ajoutez Sync si vous voulez que l'archive soit lisible PC éteint, ou depuis une deuxième machine.
Questions
Est-ce que ça marche avec des assistants de code comme Cursor ou Claude ?
Oui. Varven parle le Model Context Protocol, donc la même mémoire est lisible par Claude, Cursor, VS Code, ChatGPT et Gemini. Voir la doc pour la configuration du connecteur.
Je travaille sur plusieurs projets. Partagent-ils une seule mémoire ?
Ils partagent un coffre et y restent séparés — c'est à ça que servent les périmètres. Les préférences globales sont l'exception voulue.
Dois-je écrire les notes moi-même ?
Non. Votre assistant écrit la mémoire pendant que vous travaillez, et un petit modèle local fait le tri sur votre propre matériel. Comme le résultat est du Markdown simple, vous pouvez aussi ouvrir n'importe quelle note et la modifier à la main — votre modification l'emporte.