La mémoire des agents de zéro : du problème des tokens à votre propre second cerveau

La vidéo s'ouvre comme la suite d'une courte vidéo sur la mémoire publiée quatre mois plus tôt. Cette première vidéo proposait une solution rapide au problème de Claude Code lisant des fichiers inutiles et brûlant des tokens, mais sa brièveté laissait la plupart des questions des spectateurs sans réponse. La nouvelle vidéo vise à combler ce manque, arrivant juste au moment où les débats sur la mémoire des agents reprennent de l'ampleur. L'autrice pose le cadre d'emblée : toute l'explication repose sur Claude Code, à la fois largement utilisé et exemple concret dont la structure de fichiers et les outils de suivi rendent le sujet tangible.

Une feuille de route en six parties est déroulée. Viennent d'abord les origines du concept de mémoire et le problème des tokens, puis l'approche classique de récupération et les structures en graphe. La deuxième partie couvre le comportement mémoire par défaut de Claude Code, la troisième le format llm-wiki, et la quatrième le suivi avec Obsidian. La cinquième partie demande où les outils prêts à l'emploi comme NotebookLM s'insèrent dans ce tableau, et la dernière examine le système de mémoire intégré de Hermes Agent.

Le problème central est reconnu par tous : après avoir reçu un prompt, l'agent lit chaque fichier, pertinent ou non, brûle des tokens et ne conserve aucun registre séparé de l'utilisateur. Chaque nouvelle session relit les anciens fichiers. La thèse de la vidéo est que la mémoire d'un agent n'a qu'un seul sens pratique : lire le bon fichier au bon moment. Le système que l'utilisateur doit construire n'a donc rien de magique, c'est simplement une organisation de fichiers qui amène l'agent à lire les bons fichiers à chaque entrée.

Le cœur théorique tient en deux chemins et trois parties. Le chemin d'écriture synthétise la conversation terminée en fichiers ; le chemin de lecture trouve le bon fichier lorsqu'une question arrive et ramène son contenu dans le chat. Les trois parties sont le magasin de données, la carte et le fichier de règles : un stock de fichiers Markdown, une carte d'index indiquant à l'agent quel fichier consulter, et le fichier de règles côté Claude Code définissant comment lire la carte. La vidéo l'explique avec l'analogie d'un plan de ville : les magasins sont les boutiques, l'index est les indications, et le fichier de règles est le guide pour lire le plan.

La douleur des tokens vient du côté de la lecture. Si l'écriture est mal faite, l'agent lit tout et la facture grimpe. Le chemin de lecture existe déjà ; ce qu'il faut construire, c'est l'écriture des fichiers pour que la carte soit correcte. Un système de mémoire n'est donc rien de plus que des données correctement enregistrées et relues correctement par l'agent. Cette définition devient la règle d'évaluation de chaque choix d'outil dans le reste de la vidéo.

Vient ensuite l'origine du concept : l'approche de récupération. Dans le dispositif classique, les grands jeux de données étaient découpés en morceaux, convertis en vecteurs par des modèles d'embedding, et le morceau le plus proche était attaché à la réponse lorsqu'une question arrivait. C'est exactement la méthode que l'autrice utilisait autrefois pour d'imposants fichiers de coordonnées 3D dans un précédent emploi. Mais ce dispositif servait des jeux de données statiques et gigantesques, non un système personnel mis à jour chaque jour. Dans le dispositif actuel des agents, c'est le modèle lui-même qui fait la récupération, et le travail de l'humain consiste à construire correctement l'index et la carte.

Le concept de graphe devient concret à travers l'interface d'Obsidian. Les nœuds représentent des unités de travail et les arêtes des transferts d'informations et de résultats ; une arête ne compte que lorsqu'un véritable transfert a lieu. Le mécanisme de requête en découle : l'utilisateur demande, l'agent lit les fichiers pertinents, produit un résultat commun, et cette synthèse est enregistrée comme un nouveau document et mise à jour dans les sessions suivantes. L'agent est en quelque sorte entraîné de zéro en lui montrant comment utiliser le système.

La section la plus franche porte sur le comportement par défaut de Claude Code. L'agent ne se souvient pas vraiment ; un sous-système appelé auto memory prend des notes sur l'expertise, les corrections en cours de conversation, les projets en cours et les références externes. Un fichier d'index nommé MEMORY.md se charge partiellement au début de chaque session, tandis que les enregistrements de conversation restent dans les dossiers de projet pendant trente jours par défaut avant d'être supprimés. Le résultat est familier : l'agent sait qui vous êtes mais ne peut pas suivre un sujet d'il y a plusieurs mois, oublie le format du travail habituel, et le problème des tokens revient sur les grands projets.

Le format llm-wiki est présenté comme la couche de solution. Ce n'est qu'une norme de mise en page Markdown : structure du coffre, carte d'index, enregistrements de journal et liens croisés entre pages suivent un schéma fixe. L'autrice construit un exemple en direct à partir de sujets recueillis dans les commentaires des spectateurs, remettant à l'agent les commandes d'ingestion, de requête et de contrôle de santé à la main pendant que l'agent synthétise les fichiers et met à jour l'index et le journal. Le point frappant est qu'Obsidian n'apparaît nulle part à ce stade ; ce sont le format et les commandes qui font le travail de liaison.

Obsidian s'insère dans cette architecture comme une couche de surveillance et de visualisation, pas comme un stockage. Ouvrir le coffre révèle en vue graphe quelle page renvoie où et quels nœuds sont orphelins. Les fichiers de règles sans liens apparaissent comme des orphelins, tandis que les pages bien reliées deviennent des itinéraires que l'agent peut suivre. L'avertissement est sans détour : déverser des fichiers dans le visualiseur avant d'avoir construit des liens avec un agent ne montre rien d'autre que des nœuds orphelins. Pour les petits projets ponctuels, monter un coffre séparé est jugé inutile.

La cinquième partie aborde la question des outils prêts à l'emploi à travers NotebookLM. Partir d'un compte neuf, ajouter des sources, téléverser un fichier de conception et générer des résumés et des fiches d'information sont démontrés. Le verdict est nuancé : un outil tout fait suffit pour une recherche ponctuelle, mais la connaissance ne vit qu'à l'intérieur de cette application et y accéder coûte des tokens supplémentaires. Si le coffre est bien construit, l'agent n'a pas besoin de lire des dizaines de fichiers ; l'outil tout fait et le coffre personnel ne sont pas des rivaux mais des réponses à des échelles différentes.

La dernière partie porte sur Hermes Agent, et la différence tient en une phrase : Claude Code note des sujets, Hermes note des opérations. Un service fonctionnant en continu, une tâche déclenchée chaque matin et un fichier de compétences agissant comme le cerveau vérifient à chaque tour si la conversation contient quelque chose qui vaut la peine d'être appris, puis consignent de courtes notes sans toucher au chat principal. L'organisation des dossiers et le mécanisme de compétences ressemblent à Claude Code, mais la boucle écriture-lecture-nettoyage fonctionnant automatiquement dès l'installation le distingue du dispositif llm-wiki. En conclusion, l'autrice indique que les commandes qu'elle a utilisées sont partagées dans la description.