Votre prochain agent de code ne devrait pas repartir de zéro

Ce qui coûte le plus cher quand on change d'agent de code, ce n'est pas l'abonnement. C'est l'heure passée à réexpliquer le projet depuis le début.

Quels fichiers comptent, quelle approche a déjà échoué, pourquoi les tests sont organisés comme ça, ce que fabrique cette branche laissée à moitié terminée. Claude Code n'en sait rien. Codex, Cursor et Gemini CLI non plus. Chacun démarre avec une fenêtre de contexte vide et une politesse sincère.

ai-memory est un binaire Rust qui essaie de corriger ça, et ses choix de conception sont plus intéressants que sa liste de fonctionnalités.

Une mémoire, plusieurs harness

L'argument de vente : une vingtaine de harness d'agents — Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, Kiro et les autres — lisent dans un même magasin de mémoire partagé. Vous travaillez dans l'un, vous vous arrêtez en pleine tâche, vous en ouvrez un autre dans le même répertoire, et il reprend là où le premier s'est arrêté.

Le mécanisme, c'est une passation typée. Pas un résumé que l'agent génère en espérant qu'il soit juste, mais un enregistrement explicite avec un propriétaire qui ne peut être revendiqué qu'une fois. Cette dernière contrainte est le point clé : deux agents ne peuvent pas croire en même temps qu'ils poursuivent le travail, et une passation abandonnée reste visible au lieu de disparaître en silence.

Il y a aussi une couche inter-projets. Vos préférences de travail — gestionnaire de paquets, organisation des tests, façon de découper les modules — vous suivent dans les nouveaux dépôts, pour qu'un checkout tout frais ne reparte pas de zéro sur tout ce qui vaut partout.

Le Markdown comme source de vérité

Voilà le choix de conception qui mérite débat.

Les systèmes de mémoire pour agents, c'est généralement des embeddings. On découpe l'historique, on l'embedde, on le stocke dans une base vectorielle, on récupère par similarité. Ça marche, avec trois problèmes : on ne peut pas le lire, on ne peut pas en faire un diff, et la récupération est assez opaque pour qu'en cas de mauvais résultat, on n'ait aucune idée du pourquoi.

ai-memory inverse la logique. La source de vérité est un simple wiki Markdown, versionné avec git. L'index SQLite — recherche plein texte, entités, embeddings — est dérivé et reconstructible. Supprimez la base, vous ne perdez rien.

Ce seul choix rapporte gros. Vous pouvez faire un grep du wiki. L'ouvrir dans Obsidian. Corriger à la main une entrée fausse. Le rsync. Lire un diff et constater que la compréhension de votre architecture par l'agent a changé mardi. Et aucun vector store dans lequel s'enfermer.

Ça veut aussi dire que la mémoire est auditable, ce qui compte pour une équipe. À la question « pourquoi l'agent croit qu'on utilise pnpm », la réponse est un fichier.

Vieillir sans supprimer

Le projet décrit un système de vieillissement de la mémoire : décroissance par paliers, rétention pondérée par les accès, déduplication et signalement des contradictions. Les notes inutilisées perdent en priorité sans disparaître, et les entrées contradictoires sont marquées plutôt qu'écrasées en silence.

Le détail qui compte : rien n'est supprimé définitivement. Les vieilles pages restent dans git, et une commande de restauration les ramène. Vu la fréquence à laquelle une note « obsolète » d'un agent se révèle être la seule trace du pourquoi d'une décision, c'est le bon défaut.

Une fonctionnalité optionnelle, dreaming, utilise un LLM pour réécrire des groupes de notes froides pendant les temps morts. Elle est désactivée par défaut, et le README précise clairement qu'elle ne supprime jamais le matériau d'origine. Désactivé par défaut, c'est le bon réglage pour tout ce qui réécrit vos notes avec un modèle.

L'installation est vraiment courte

Deux commandes sous Linux ou macOS : un installeur curl-to-shell qui vérifie une somme SHA-256, puis ai-memory setup, qui crée le répertoire de données, démarre un service au niveau utilisateur et branche les agents qu'il détecte. Il existe un équivalent PowerShell pour Windows, plus AUR, RPM, Nix, Docker et des entrées de marketplace de plugins pour Claude Code et Codex.

L'usage quotidien tourne autour d'un wrapper : ai-memory run claude au lieu de claude. Il installe les bons hooks et le serveur MCP au premier lancement et limite la session au projet courant. Ensuite, ai-memory continue reprend le dernier checkout géré, et resume --search auth choisit parmi vos workflows par nom.

Il y a une commande bootstrap qui importe l'historique existant d'un projet en une passe : c'est la différence entre un outil qu'on adopte et un outil qu'on compte adopter un jour.

Les côtés inconfortables

La capture silencieuse via les hooks de cycle de vie signifie que le système enregistre vos prompts, vos appels d'outils et les frontières de session pendant que vous travaillez. C'est la seule façon que ça puisse fonctionner — vous n'allez pas tenir un journal à la main — mais autant le dire clairement. Le relevé de chaque prompt tapé contre le code d'un client est un matériau sensible, et il se retrouve dans un répertoire versionné avec git.

Les atténuations sont raisonnables : l'écoute est limitée à loopback par défaut, et setup génère un bearer token écrit dans un fichier lisible par le seul propriétaire, pas dans la config de votre agent. Mais le quickstart Docker tourne sans authentification, ce que le README signale comme réservé à un usage local. Si vous exposez ce port sans reverse proxy TLS, vous publiez votre historique de travail.

Le volet équipe est plus mûr que je ne l'attendais pour un projet aussi jeune : serveur partagé, partage par projet, passations privées, authentification multi-utilisateurs, attribution et journal d'audit, tout hors de l'offre payante. C'est cet ensemble qui décidera si le projet survit au contact d'une vraie organisation d'ingénierie.

Si vous ne voulez pas faire tourner un serveur

Objection légitime : « mon propre serveur » est une expression qui perd la moitié de son public instantanément.

Pas besoin d'un serveur. La commande setup démarre un service au niveau utilisateur sur la même machine, lié à loopback, et c'est le chemin par défaut — pas de homelab, pas de VPS, pas de DNS. Les fonctions multi-machines et équipe ne comptent que le jour où vous les voulez, et elles se détachent de la boucle principale.

Il existe aussi une app de barre de menus macOS construite depuis le dépôt, et une vue web en lecture seule si vous préférez parcourir votre wiki dans un navigateur plutôt que dans un éditeur. La voie Docker existe surtout pour ceux qui pensent déjà en conteneurs.

Donc l'échelle d'adoption honnête est celle-ci : installez-le sur votre portable, laissez-le capturer un projet, et voyez si le wiki produit est quelque chose que vous liriez vraiment. Si oui, le reste suivra. Si le wiki n'est que du bruit, aucune fonctionnalité d'équipe ne le sauvera.

Pourquoi c'est plus important que ça en a l'air

Le marché des agents est aujourd'hui organisé par éditeurs, et aucun éditeur n'a intérêt à rendre le départ facile. Votre contexte, c'est le verrou. C'est pourquoi le coût de changement paraît plus élevé que ne le suggère le prix de l'abonnement.

Un outil qui se place sous tous les autres et garde la mémoire dans un format qui vous appartient, c'est un petit acte de standardisation côté utilisateur. Que ai-memory soit celui qui gagne est presque secondaire : la forme de la solution — du texte brut portable avec un index reconstructible — est évidemment la bonne, et c'est la forme contre laquelle toute fonctionnalité de mémoire propriétaire devra finir par se battre.

Et c'est un binaire unique, sans clé API pour la boucle principale. Chose rare dans une catégorie où « mémoire » veut généralement dire « un abonnement de plus ».