La mémoire d'un agent
n8n, Qdrant, PostgreSQL et Obsidian

Une mémoire d'agent n'est pas un historique de conversation

Un assistant qui oublie tout entre deux sessions n'est pas un assistant : c'est un moteur de recherche avec du style. Mais l'inverse est pire, un système qui garde tout devient un dépotoir où la bonne information est noyée dans le récit d'une réunion de mars.

Ce qui marche chez nous tient dans une distinction simple : trois mémoires, trois formats, trois outils. Chacune répond à une question différente.

Et une quatrième, qu'on oublie toujours : l'état d'exécution. Quels travaux ont tourné, lesquels ont échoué, ce qui a été envoyé et quand. Ce n'est pas de la mémoire d'agent, c'est de la comptabilité, et c'est PostgreSQL.

PostgreSQL : la source de vérité

Il y a une tentation, quand on découvre les bases vectorielles, de tout y mettre. C'est une erreur de conception, pas un choix d'outil : un index vectoriel ne sait pas faire de jointure, ne garantit pas une transaction, et ne répond pas à « quels travaux ont échoué cette nuit » sans bricolage.

Chez nous, PostgreSQL tient les tables qui ont une réalité vérifiable : tâches, exécutions, livrables, échéances, historique des interventions par client, références des documents indexés. Chaque ligne a un identifiant, une date, un auteur, et un état. C'est aussi la table que n8n interroge à chaque exécution, ce qui évite qu'un workflow « se souvienne » de quelque chose que la base ignore.

Règle simple : si la donnée doit être exacte, elle va dans PostgreSQL. Si elle doit être retrouvée par le sens, elle va dans Qdrant. Si elle doit être lue et corrigée par un humain, elle va dans un fichier.

Qdrant : chercher par le sens, pas par le mot

Une base vectorielle transforme un texte en une liste de nombres, un embedding de sorte que deux textes qui parlent de la même chose se retrouvent proches, même sans un mot en commun. « La ligne est saturée le soir » et « la bande passante sature entre 19 h et 21 h » se ressemblent pour la machine, pas pour un moteur de recherche classique.

Ce que nous stockons dans Qdrant n'est pas le document entier, mais des fragments (chunks) d'environ quelques centaines de mots, chacun avec ses métadonnées : client, date, type de document, source, version. Ces métadonnées ne sont pas décoratives, elles servent de filtre avant la recherche. Chercher dans tout le corpus est lent et bruité ; chercher dans les notes du client X, écrites après juin, donne une réponse utile.

• Le découpage décide de la qualité un fragment qui coupe une procédure en deux produit deux demi-réponses. Nous découpons par section, avec un chevauchement, jamais à la fin d'une phrase choisie par le compteur de caractères.
• Les embeddings viennent d'un modèle local ils sont calculés sur notre matériel, pas envoyés à un service tiers. Un dossier client ne sort pas de notre infrastructure pour être vectorisé.
• Une collection par usage, pas une par client sinon on multiplie les index à maintenir ; l'isolation se fait par le filtre, et la séparation stricte entre clients reste une décision d'architecture, pas un réglage.
• Réindexer est une opération normale un changement de modèle d'embedding invalide tout l'index. C'est prévu, scripté, et testé.

Markdown et HTML : les formats de la mémoire humaine

Le choix du format compte plus qu'on ne le croit, parce qu'il détermine qui peut intervenir. Un fichier Markdown s'ouvre dans n'importe quel éditeur, se lit sans outil, se compare entre deux versions et se corrige à la main. C'est la seule mémoire dont un humain reste propriétaire.

Nous écrivons donc deux choses différentes :

• Du Markdown pour la mémoire un fait par note, un en-tête structuré (client, date, sujet, source), des liens entre notes. Pas de mise en forme riche, pas de tableau à dix colonnes : ce qui doit être relu doit rester lisible.
• Du HTML pour les livrables les documents qui partent chez un client ou s'archivent. Le HTML est figé, imprimable, et survivra à l'outil qui l'a produit. La conversion se fait à la demande, jamais comme format de travail.

La règle qui en découle : ce qui est écrit dans un fichier doit pouvoir être compris sans l'agent. Si la mémoire n'est lisible que par le programme qui l'a écrite, ce n'est pas de la mémoire, c'est une sauvegarde opaque.

Obsidian : l'atelier, et non la cave

Obsidian est un éditeur de notes qui travaille sur un dossier de fichiers Markdown, sans base de données propriétaire, sans serveur. C'est exactement ce qui le rend compatible avec un agent : nous lisons et écrivons les mêmes fichiers.

Ce que son usage change concrètement :

Le point important n'est pas l'outil, c'est le rituel : une revue périodique où l'on relit, fusionne et supprime. Une mémoire sans revue se dégrade plus vite qu'elle ne s'enrichit, c'est vrai pour un humain, ça l'est pour un agent.

Où se place n8n, et pourquoi il n'est pas remplaçable

n8n ne réfléchit pas, et c'est sa qualité. Il tient les gestes répétables du système :

• Ingestion un document arrive par courriel ou par formulaire, un workflow le récupère, appelle l'extraction de texte, découpe, vectorise et pousse dans Qdrant, puis inscrit la référence dans PostgreSQL. Aucune décision : une chaîne.
• Planification la revue hebdomadaire, la relance des échéances, la synchronisation avec les outils métier. À heure fixe, avec journal d'exécution.
• Webhooks c'est par là que l'agent et le monde extérieur se parlent : un workflow prévient l'agent qu'un document est arrivé ; l'agent déclenche un workflow quand une action doit être exécutée proprement, avec relance et trace.

L'idempotence est le mot qui compte : un workflow qui réingère deux fois le même document produit des doublons dans l'index, donc des réponses en double et une confiance qui baisse. Chaque étape porte un identifiant d'entrée, et une réexécution ne crée rien de neuf.

Ce qu'on peut faire avec, concrètement

• Un dossier client vivant l'historique des interventions, les particularités du site, les décisions prises, et la réponse à « qu'est-ce qu'on a changé chez ce client en septembre ? »
• Une base de connaissances d'incidents chaque panne résolue laisse une note : symptômes, diagnostic, correctif. La fois suivante, on cherche par symptôme, pas par mot-clé.
• Un RAG sur documents techniques les centaines de pages de constructeur, de procédures et de rapports, interrogeables avec la source citée en regard de chaque réponse.
• Des comptes rendus qui se rédigent l'agent rassemble les faits de la journée depuis PostgreSQL, les relie aux notes, et produit un brouillon que l'humain corrige, jamais l'inverse.

Les garde-fous, sans lesquels rien de tout cela ne tient

• Aucun secret dans la mémoire ni mot de passe, ni clé, ni jeton. Ils vivent dans des fichiers protégés, jamais dans une note indexée.
• Chaque réponse cite sa source un fragment, un fichier, une date. Sans cela, l'agent complète les trous, et une mémoire qui invente est pire que pas de mémoire.
• Une durée de vie les notes opérationnelles périment ; les faits durables restent. Un index sans péremption finit par affirmer des choses qui ne sont plus vraies.
• Sauvegarder les trois la base, l'index et les fichiers. Un index vectoriel se reconstruit ; un dossier de notes perdues, non.

Ce que ça change, au fond

Un agent sans mémoire refait le même travail chaque matin. Un agent avec une mémoire bien tenue accumule : il connaît le client, reconnaît le symptôme, retrouve la procédure, sait ce qui a été tenté et ce qui a échoué. Ce n'est pas de l'intelligence supplémentaire, c'est de la continuité, et dans un métier de service, la continuité vaut plus que la virtuosité.