Vos agents oublient tout.
Ça s'arrête ici.
Une base de connaissances persistante et partagée que vos agents de code IA écrivent eux-mêmes en travaillant. Décisions, architecture, pièges et conventions survivent à la session, au redémarrage et au changement de machine.
Tu fermes une session, la fenêtre de contexte disparaît. Project Memory, c'est la partie qui reste : une mémoire longue pour agents IA, stockée par projet, relue par chaque agent et chaque coéquipier qui ouvre le repo. Pas d'appli de notes à côté, pas de copier-coller, pas de codebase à réexpliquer tous les matins.
Tous les agents de code IA ont le même trou. L'agent lit ta codebase, comprend pourquoi le module d'auth est fichu comme ça, se prend le piège de migration qui t'a coûté un week-end l'an dernier, et puis la session se termine et tout s'évapore. Demain il repart de zéro et redécouvre les mêmes choses, en rebrûlant les mêmes tokens.
Tu peux en coller une partie dans un CLAUDE.md et espérer que ça reste à jour. Ça marche pour les règles que tu connais déjà. Ça ne marche pas pour le savoir que tes agents produisent en travaillant : la décision qu'ils viennent de prendre avec toi, l'impasse qu'ils ont explorée, le truc sur ton build qui ne devient évident qu'à 2h du matin.
Project Memory referme cette boucle. Tes agents écrivent ce qu'ils apprennent dans une base de connaissances persistante, via des outils MCP, comme un geste normal de travail. Elle vit avec le projet, pas avec ton compte : l'agent suivant la lit, et celui de ton coéquipier sur sa machine aussi.
L'amnésie de session, et ce qu'elle coûte vraiment
Les symptômes sont tellement familiers que la plupart des gens ont arrêté de les voir.
Tu réexpliques la même architecture
Chaque nouvelle session commence par les trois mêmes paragraphes sur la façon dont le projet est câblé. C'est le prompt le plus répété du coding agentique.
Les agents paient pour réapprendre
Un agent qui doit relire la moitié du repo avant d'agir dépense de vrais tokens et de vraies minutes à redécouvrir ce qu'il savait déjà hier.
Le même piège se déclenche deux fois
Un piège que ton agent a rencontré et corrigé en juin est invisible en juillet. Rien ne l'a consigné, donc rien n'empêche le suivant de retomber dedans.
Le savoir reste sur une seule machine
Ce que ton agent a appris vit dans ta session, sur ton laptop. L'agent de ton coéquipier n'en sait rien et démarre le projet de zéro.
Ce que Project Memory t'apporte
Une couche de mémoire longue pour agents IA, intégrée à l'IDE où ces agents tournent déjà.
Un savoir qui survit à la session
Les notes sont stockées côté serveur, par projet. Ferme l'agent, quitte l'app, redémarre le Mac, change de laptop : la mémoire est toujours là au retour.
Écrite par les agents, pas par toi
Les agents enregistrent via l'outil MCP memory_save comme un geste de travail normal, sans demander confirmation. Tu obtiens une base qui se remplit toute seule au lieu d'une doc que personne ne met à jour.
Partagée avec tout le projet
La mémoire est indexée sur le projet, pas sur ton compte. Clone le repo, ouvre-le dans AgentsRoom, et tu lis la même mémoire que celle que les agents de tes coéquipiers alimentent.
Cinq dossiers qui se créent seuls
architecture, decisions, conventions, pitfalls, features. Les dossiers naissent au premier usage, donc la structure apparaît en même temps que le savoir. Rien à configurer.
Mise à jour plutôt que création
Enregistrer une note sous un nom existant met cette note à jour sur place. La mémoire s'approfondit au lieu de s'étaler en quarante entrées quasi identiques.
Un vrai graphe de connaissances
Les notes se lient entre elles par [[wiki-links]]. La vue graphe dessine ces liens, regroupe les notes par dossier et estompe celles qui se périment : tu vois ce que ton projet sait vraiment.
Recherche floue sur tout
La recherche balaie d'un coup les noms de notes, les indices de récupération, les corps entiers et les tags : tu retrouves la décision dont tu te souviens à moitié avec deux mots.
Gratuit, sans limite de notes
Project Memory n'est pas une option payante et n'a aucun quota. Pas d'abonnement de sync à acheter à côté : la mémoire et son graphe font simplement partie d'AgentsRoom.
Les cinq dossiers que ton projet remplit
Structure canonique, créée automatiquement à la première écriture. Un sujet par note, une note par idée.
architectureComment un module marche vraiment et où vit son code. La note qu'un agent lit au lieu de re-crawler douze fichiers.
decisionsUne note par décision : le contexte, le choix, et pourquoi. C'est ce qui empêche quelqu'un de la défaire discrètement six mois plus tard.
conventionsLes règles découvertes en travaillant, pas celles que tu as écrites au départ. Nommage, patterns, la façon dont cette codebase fait les choses.
pitfallsPièges, incidents passés, plus-jamais-ça. Un bug corrigé une fois ne devrait jamais être payé deux fois.
featuresL'état fonctionnel de chaque feature : ce qui est livré aujourd'hui, ce qui est à moitié construit, ce qui a été délibérément laissé de côté.
Trois moments où le savoir se capture
Le plus dur, dans une base de connaissances, c'est d'y écrire quoi que ce soit. Project Memory attaque ça par trois côtés.
Au fil de l'eau, par défaut
Chaque agent d'AgentsRoom reçoit l'instruction mémoire dans son system prompt : après un résultat significatif, une décision prise, un piège rencontré, un module compris, une feature livrée, il l'écrit. Contrairement à l'enregistrement d'un skill ou d'un prompt, une écriture mémoire ne demande aucune confirmation. C'est un geste de travail normal, donc ça arrive vraiment.
Toujours mémoriser, par agent
Active le toggle Toujours mémoriser sur n'importe quel agent et il passe sous une règle plus stricte : à la fin de chaque tour ayant produit un apprentissage durable, il le persiste avant de terminer. Utile sur les rôles qui génèrent beaucoup de savoir, comme un architecte au milieu d'un refactor ou un agent QA qui cartographie les modes de panne.
Au moment de partir
Quand tu fermes un agent dont la session est encore vivante, AgentsRoom demande s'il faut mémoriser d'abord. Choisis Mémoriser et l'instruction part dans la session en cours pour que l'agent écrive ce qu'il a appris avant que tu fermes l'onglet. Le moment où le savoir se perd d'habitude devient celui où il se sauvegarde. Les sessions courtes sont ignorées automatiquement, parce qu'une course de deux minutes ne mérite pas un souvenir, et tu peux désactiver la question pour un agent, pour un projet ou partout.
Vois ce que ton projet sait
La vue graphe transforme la mémoire en carte plutôt qu'en liste.
Chaque note est un nœud. Les dossiers forment des clusters. Les [[wiki-links]] que les agents écrivent dans le corps des notes deviennent les arêtes : le graphe dessine la forme réelle du savoir de ton projet, pas une arborescence de dossiers.
La fraîcheur pilote le rendu. Une note mise à jour récemment est plus grosse et plus lumineuse ; une note qu'on n'a pas touchée depuis des semaines rétrécit et s'estompe, sur un horizon de soixante jours. Le savoir périmé a l'air périmé, ce qui est exactement le moment où tu veux le remarquer. Clique sur un nœud pour ouvrir la note.
Une mémoire par projet, pas par personne
C'est le point que la plupart des outils de mémoire prennent à l'envers.
La plupart des outils de connaissance rattachent tout à un compte utilisateur : tes notes, ton coffre, ta sync. Ce modèle casse dès qu'une deuxième personne arrive, parce que le savoir qui compte porte sur le projet, pas sur toi.
AgentsRoom indexe Project Memory sur l'identifiant de projet commité dans le repo. Tous ceux qui ouvrent ce projet lisent et écrivent la même mémoire. Un coéquipier clone le repo, l'ouvre, et ses agents héritent de tout ce que les tiens ont appris. Aucune invitation à envoyer, aucun coffre à partager, aucun export puis réimport.
Une conséquence à connaître : l'accès est par capacité. Être connecté et disposer de l'identifiant de projet suffit, donc traite la mémoire d'un dépôt public comme publique. Les agents ont pour consigne de ne jamais y stocker de secrets ni de chemins spécifiques à une machine, et tu devrais faire pareil.
Trois outils, et les agents font le reste
Project Memory est exposée aux agents via MCP : n'importe quel agent CLI connecté utilise la même interface.
memory_listListe les dossiers et les notes avec leur indice de récupération et un aperçu du contenu. Les agents ont pour consigne de l'appeler au début de toute tâche non triviale, avant d'explorer la codebase : le module est peut-être déjà expliqué.
memory_getRetourne le corps markdown complet d'une note, par id ou par nom exact. Les noms sont ce qui résout les wiki-links, donc un agent peut suivre un [[lien]] d'une note directement vers la suivante.
memory_saveCrée ou met à jour une note. Même nom veut dire mise à jour sur place. Prend un nom, un indice de récupération, le corps markdown, un dossier optionnel et des tags.
Provider-agnostic par construction : les outils sont servis par le serveur MCP d'AgentsRoom, donc Claude Code, Codex CLI et les autres agents CLI que tu lances dans AgentsRoom lisent et écrivent tous la même mémoire de projet.
Comment ça marche
Il n'y a aucune étape de configuration. La mémoire démarre vide et se remplit toute seule.
Tes agents se mettent à lire
Dès la première session, chaque agent a pour consigne de consulter la mémoire du projet avant d'aller fouiller le code. Au début il ne trouve rien et passe au travail.
Tes agents se mettent à écrire
La première vraie décision, le premier piège, le premier module vraiment compris : l'agent enregistre une note. Les dossiers apparaissent au fur et à mesure. Tu peux voir le compteur grimper sur l'icône cerveau du dock.
Toutes les sessions suivantes sont plus courtes
Les nouveaux agents démarrent avec une compréhension réelle du projet. Tu arrêtes d'écrire les trois mêmes paragraphes de contexte, et l'agent arrête de payer des tokens pour redécouvrir ce qu'il avait déjà compris.
Là où ça paie
Le savoir qui vivait dans la tête d'une seule personne, ou nulle part.
Les agences qui jonglent avec les codebases clients
Douze projets clients, chacun avec ses bizarreries. Chaque projet porte sa propre mémoire : reprendre l'un d'eux après trois mois ne veut plus dire le réapprendre depuis le journal de commits.
L'onboarding, humain ou agent
Un nouveau développeur clone le repo et ses agents connaissent déjà l'architecture, les conventions et les pièges. La mémoire est le document d'onboarding, sauf qu'il est à jour parce qu'il a été écrit pendant le travail.
Le code legacy dont personne ne se souvient
Envoie un agent sur le module poussiéreux, laisse-le comprendre comment il fonctionne, et fais-lui écrire ça dans architecture. La personne suivante démarre sur une explication au lieu d'un mystère.
Les passages de relais entre agents
Un agent PM cadre, un agent dev construit, un agent QA vérifie. Chacun écrit ce qu'il a appris et le suivant le lit, donc la chaîne ne perd pas le fil entre les étapes.
Mémoire, skills et prompts ne sont pas la même chose
AgentsRoom garde trois bibliothèques parce qu'elles répondent à trois questions différentes.
Project Memory
Qu'est-ce qui est vrai sur ce projet ?
Les faits que les agents ont découverts : décisions, architecture, pièges, conventions, état des features. Écrite par les agents, partagée avec tout le projet, spécifique à cette codebase.
Skills Library
Comment fait-on ce type de tâche ?
Des procédures réutilisables qui se chargent quand elles sont pertinentes : checklist de revue, pattern de migration, audit d'accessibilité. Portables d'un projet à l'autre et exportables vers d'autres outils.
Découvrir la Skills LibraryPrompt Library
Qu'est-ce que je veux redemander ?
Les instructions que tu envoies souvent, enregistrées et organisées pour arrêter de les retaper. Écrites par toi, envoyées par toi.
Découvrir la Prompt LibraryProject Memory est une réponse à la mémoire des agents, pas la seule. Les fichiers CLAUDE.md, mem0, Letta, Zep, basic-memory et Obsidian avec MCP résolvent chacun une part différente du problème.
Comparer les outils de mémoire IAQuestions fréquentes
Qu'est-ce que Project Memory dans AgentsRoom ?
Project Memory est une base de connaissances persistante et partagée rattachée à un projet. Vos agents de code IA y écrivent des notes en travaillant, via l'outil MCP memory_save, et la relisent avec memory_list et memory_get. Les notes couvrent l'architecture, les décisions, les conventions, les pièges et l'état des features. Contrairement à la fenêtre de contexte d'un agent, effacée à la fin de la session, la mémoire est stockée côté serveur et survit aux sessions, aux redémarrages et aux changements de machine.
En quoi est-ce différent d'un fichier CLAUDE.md ou AGENTS.md ?
Les deux se complètent. Un CLAUDE.md est un fichier d'instructions statique que vous écrivez et maintenez à la main : les règles que vous connaissez déjà, chargées au début de chaque session. Project Memory est dynamique et écrite par les agents : elle capture ce qu'ils apprennent en travaillant, note par note, et grossit sans que vous la mainteniez. En pratique, le CLAUDE.md porte vos conventions et vos commandes, la mémoire porte la compréhension accumulée de la codebase, les décisions et les pièges. AgentsRoom permet aussi d'éditer votre CLAUDE.md depuis l'interface.
Mes coéquipiers voient-ils la même mémoire ?
Oui. Project Memory est indexée sur l'identifiant de projet stocké dans le repo, pas sur votre compte utilisateur : tous ceux qui ouvrent le projet dans AgentsRoom lisent et écrivent la même mémoire. Votre coéquipier clone le repo, l'ouvre, et ses agents héritent de tout ce que les vôtres ont appris. Rien à inviter, exporter ou importer. L'accès est par capacité : être connecté et disposer de l'identifiant de projet suffit, donc traitez la mémoire d'un repo public comme publique et gardez les secrets en dehors.
Project Memory est-elle gratuite ?
Oui. Project Memory est incluse dans AgentsRoom sans surcoût et sans limite de notes. Il n'y a pas d'abonnement de synchronisation séparé ni d'option payante pour le graphe de connaissances. Vous devez en revanche être connecté, puisque la mémoire est stockée côté serveur pour pouvoir être partagée entre les utilisateurs du projet.
Quels agents IA peuvent utiliser la mémoire du projet ?
Tous les agents CLI que vous lancez dans AgentsRoom. Les outils de mémoire sont servis par le serveur MCP d'AgentsRoom plutôt que rattachés à un éditeur unique : Claude Code, Codex CLI et les autres CLI supportés lisent et écrivent donc les mêmes notes. C'est tout l'intérêt de mettre la mémoire dans l'IDE plutôt que dans un seul fournisseur : changer d'agent ne fait pas perdre le savoir accumulé du projet.
Dois-je demander aux agents d'enregistrer les choses ?
Non, même si vous pouvez le faire. Chaque agent reçoit l'instruction mémoire dans son system prompt et enregistre de lui-même après un résultat significatif, sans demander confirmation. En plus de ça, vous pouvez activer Toujours mémoriser sur un agent précis, ce qui le pousse à persister un apprentissage à la fin de chaque tour qui en a produit un, et quand vous fermez un agent dont la session est vivante, AgentsRoom propose de lui faire mémoriser la session avant de fermer l'onglet.
Puis-je lire et modifier la mémoire moi-même ?
Oui. L'icône cerveau du dock ouvre la mémoire, avec un badge indiquant le nombre de notes. Vous disposez d'une barre latérale de dossiers, d'une recherche floue sur les noms, les indices, les corps et les tags, et d'un éditeur complet pour créer, renommer, dupliquer ou supprimer des notes et les déplacer entre dossiers. Il y a aussi une vue graphe qui dessine les notes en nœuds, les wiki-links en arêtes, et estompe les notes qui se périment.
Project Memory fonctionne-t-elle hors ligne ?
En partie. L'application desktop garde un cache local de la mémoire dans le dossier du projet, donc l'interface d'AgentsRoom continue d'afficher vos notes sans connexion. Les outils mémoire des agents, eux, appellent le serveur à chaque fois : les agents ont besoin de connectivité pour lire ou écrire. Le fichier de cache est gitignoré, il ne pollue donc jamais votre dépôt.
Qu'est-ce qui n'a pas sa place dans la mémoire du projet ?
Les secrets, les identifiants, les tokens et les chemins spécifiques à une machine. La description d'outil que reçoivent les agents leur interdit explicitement de les stocker, et vous devriez suivre la même règle en écrivant des notes à la main. La mémoire est faite pour du savoir distillé et durable sur le projet : les décisions et leurs raisons, le fonctionnement des modules, les pièges à éviter, les conventions en vigueur. Le bavardage de session et les détails ponctuels n'y ont pas leur place.
Peut-on désactiver Project Memory ?
Oui, à plusieurs niveaux. La mémoire est active par défaut, et un simple toggle dans les réglages d'agents du projet la coupe pour ce projet : plus de question au moment de fermer un agent, plus d'instruction mémoire dans les system prompts, et les agents sont informés que les outils de mémoire sont indisponibles. Vous pouvez aussi garder la mémoire active et désactiver seulement la question de fermeture, pour un agent, pour un projet ou globalement. Rien n'est supprimé quand vous la coupez : la réactiver vous rend les notes que vous aviez déjà.
Ça peut aussi vous intéresser
Skills Library
Des procédures réutilisables que vos agents suivent, attachables aux tâches et aux agents.
AgentsRoom MCP
Le serveur MCP qui expose le backlog, les prompts, les skills et la mémoire à vos agents.
Détection de dérive de contexte
Repérez le moment où le contexte d'un agent se dégrade, avant qu'il invente.
Guide CLAUDE.md
Comment écrire le fichier d'instructions statique qui complète votre mémoire de projet.
Arrêtez de réexpliquer votre codebase
Téléchargez AgentsRoom et laissez vos agents commencer à se souvenir. Gratuit, sans limite de notes.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Aperçu d'AgentsRoom en action.