Mémoire dans les agents : Simple/Postgres Memory, clés de session, « pourquoi le chat oublie-t-il »

Lorsqu'un chatbot n8n ne se souvient plus, après la première réponse, du nom de l'utilisateur ou des questions précédentes, cela tient presque toujours à la configuration de la mémoire du AI Agent Node et non au modèle de langage lui-même. n8n n'enregistre pas automatiquement un historique de conversation : ce n'est que lorsque vous connectez un nœud de mémoire tel que Simple Memory ou Postgres Chat Memory à l'agent, et que ce nœud dispose d'une clé de session unique par conversation, que l'agent peut retrouver les messages précédents. Si la clé de session est absente, si elle est identique à chaque exécution, ou si le Chat Trigger n'est pas réglé sur "From Memory", l'agent se comporte comme si chaque message débutait une nouvelle conversation. État : juillet 2026.

Pourquoi le chat "oublie" : les causes les plus fréquentes

Avant de modifier le nœud de mémoire lui-même, il vaut la peine d'examiner les sources d'erreur typiques qui conduisent, dans la pratique, toujours au même symptôme.

• Aucun nœud de mémoire connecté : Sans sous-nœud de mémoire connecté, l'AI Agent Node n'a aucune mémoire, chaque requête est traitée de manière isolée.
• Clé de session constante ou vide : Si la clé de session a la même valeur fixe à chaque requête, ou si elle est absente, toutes les conversations finissent dans le même pot de mémoire ou ne sont pas du tout attribuées.
• Chat Trigger non réglé sur "From Memory" : Selon la documentation n8n sur le Chat Trigger Node vous devez régler l'option "Load Previous Session" sur "From Memory" et connecter le trigger ainsi que l'agent au même nœud de mémoire, sinon l'agent ne charge aucun historique précédent.
• Simple Memory en mode queue : Si vous exploitez n8n en mode queue avec plusieurs workers, selon la documentation du nœud Simple Memory vous ne pouvez pas vous y fier, car n8n ne garantit pas que des appels consécutifs soient traités par le même worker.

La clé de session : le cœur de l'attribution de la mémoire

La clé de session est la clé sous laquelle n8n enregistre une conversation donnée dans la mémoire. Selon la documentation n8n, Simple Memory comme Postgres Chat Memory exigent précisément ce seul paramètre obligatoire pour définir "the key to use to store the memory in the workflow data", ou, dans le cas de Postgres, dans la table de la base de données. En pratique, cela signifie que chaque conversation a besoin de sa propre valeur stable, par exemple l'ID de chat issu du Chat Trigger, un numéro de téléphone dans des scénarios de téléphonie, ou un ID client de votre CRM. Si vous utilisez à la place une expression qui change à chaque exécution, une nouvelle mémoire vide est créée à chaque message. Un détail facilement négligé : les sous-nœuds tels que les nœuds de mémoire, selon la documentation, ne résolvent les expressions que pour le premier élément, et non pour chaque élément individuellement comme les nœuds réguliers. Si vous traitez plusieurs messages de chat dans un lot, cela peut entraîner une clé de session incorrecte ou mélangée.

Simple Memory vs. Postgres Memory : la différence essentielle

Simple Memory, répertorié dans la liste des nœuds sous le nom Window Buffer Memory, conserve l'historique de conversation, selon la documentation, directement dans les données du workflow de l'instance n8n en cours d'exécution, ce qui en fait le moyen le plus rapide de doter un agent d'une mémoire. Le hic : cette mémoire n'est pas liée durablement à une base de données et, selon n8n, ne fonctionne explicitement pas de manière fiable dans un workflow de production s'exécutant en mode queue. Postgres Chat Memory écrit en revanche chaque message dans une table de votre propre base de données Postgres, que n8n crée automatiquement si nécessaire. L'historique survit ainsi aux redémarrages, aux déploiements et à plusieurs processus workers. Les deux types de nœuds partagent le paramètre "Context Window Length", qui définit le nombre d'interactions précédentes que l'agent prend en compte comme contexte : une valeur trop élevée augmente inutilement la consommation de tokens et le temps de réponse. Point important avec Postgres : si vous connectez plusieurs nœuds Postgres Chat Memory dans le même workflow, ils accèdent par défaut, selon la documentation, à la même instance de mémoire. Des conversations séparées nécessitent donc des clés de session différentes, pas des nœuds différents.

Bien connecter le Chat Trigger et l'agent

Une étape souvent négligée concerne le Chat Trigger Node lui-même. Ce n'est que lorsque vous y basculez "Load Previous Session" de "Off" à "From Memory" que la possibilité de connecter un nœud de mémoire apparaît, et que n8n charge l'historique précédent au démarrage d'une session. n8n recommande également explicitement de connecter le Chat Trigger et l'agent au même nœud de mémoire, afin que les deux composants utilisent la même source de vérité. Sinon, deux nœuds de mémoire séparés avec des clés de session différentes créent deux mémoires parallèles et incohérentes pour une seule et même conversation, ce qui se traduit par un comportement de réponse erratique ou contradictoire.

En pratique : quand l'effort en vaut la peine

Pour un bot de test interne ou une preuve de concept, Simple Memory suffit généralement. Dès qu'un agent travaille en production avec de véritables données clients, sert plusieurs utilisateurs simultanément, ou doit permettre de retracer qui a dit quoi à l'agent et quand, un stockage durable dans une base de données propre comme Postgres Chat Memory est le choix le plus robuste, notamment parce que l'historique peut y être exporté, vérifié et supprimé si nécessaire. Quiconque souhaite construire une telle architecture accompagnée d'un concept de clé de session propre trouvera un point de départ dans les services d'agents IA de NordFlux, ainsi que dans l'automatisation n8n en général.

Questions fréquentes sur la mémoire dans les agents n8n

Qu'est-ce exactement qu'une clé de session dans n8n ?

La clé de session est l'identifiant sous lequel un nœud de mémoire enregistre et retrouve un historique de conversation. Elle doit être stable et unique par conversation, par exemple l'ID de chat issu du Chat Trigger, sinon l'agent ne peut plus associer les messages précédents.

Pourquoi Simple Memory ne suffit-il parfois pas ?

Selon la documentation n8n, Simple Memory conserve l'historique dans les données du workflow de l'instance en cours d'exécution et n'est donc pas lié à une base de données. Dans des workflows de production en mode queue avec plusieurs workers, le nœud ne fonctionne donc explicitement pas de manière fiable, car il n'est pas garanti que les appels suivants atteignent le même worker.

Puis-je utiliser plusieurs nœuds de mémoire dans un même workflow ?

Oui, mais plusieurs nœuds Postgres Chat Memory accèdent par défaut, selon la documentation, à la même instance de mémoire. Pour des conversations séparées, vous avez besoin de clés de session différentes, pas nécessairement de nœuds différents.

Dois-je configurer quelque chose de particulier sur le Chat Trigger pour que la mémoire fonctionne ?

Oui. L'option "Load Previous Session" doit être réglée sur "From Memory", sinon n8n ne connecte pas le trigger à un nœud de mémoire et ne charge aucun historique précédent. De plus, le Chat Trigger et l'agent doivent être connectés au même nœud de mémoire.