Mémoire de conversation dans un AI Agent n8n : Simple Memory vs Postgres Chat Memory

Un chatbot n8n qui répond parfaitement à la première question, puis qui semble perdre le fil dès la deuxième ou troisième relance, n'a presque jamais un problème de prompt. Le problème est presque toujours la mémoire : soit elle n'est pas configurée, soit elle est configurée d'une façon qui ne survit pas à un redémarrage de l'instance n8n, soit elle mélange les conversations de deux utilisateurs différents. Ces trois pannes ont chacune une cause précise et une correction simple une fois qu'on sait où regarder.

Ce que fait réellement la mémoire d'un AI Agent

Le node AI Agent de n8n ne « se souvient » de rien par lui-même : chaque exécution de workflow part d'un contexte vide. Ce qui donne l'illusion d'une conversation suivie, c'est un sous-node de mémoire branché sur l'agent, qui réinjecte l'historique des échanges précédents dans le prompt envoyé au modèle avant chaque nouvelle question. Sans ce sous-node, un agent conversationnel répond à chaque message comme si c'était le premier — y compris dans un pipeline construit sur le chatbot RAG WhatsApp ou l'API question-réponse de notre guide RAG avec Supabase.

Deux sous-nodes de mémoire couvrent l'essentiel des cas d'usage : Simple Memory (anciennement Window Buffer Memory), qui garde l'historique en mémoire vive le temps de l'exécution, et Postgres Chat Memory, qui l'écrit dans une table SQL persistante.

Pourquoi Simple Memory suffit… jusqu'à ce qu'il ne suffise plus

Simple Memory stocke les derniers échanges directement dans la mémoire du process n8n. Pour un test dans l'éditeur ou une démo, c'est amplement suffisant : zéro configuration, zéro dépendance externe. Le problème apparaît en production, sur trois scénarios très courants :

• Un redémarrage ou un redéploiement de l'instance efface tout l'historique en cours — l'utilisateur reprend une conversation entamée la veille et l'agent ne se souvient de rien.
• Un mode queue avec plusieurs workers (fréquent en self-hosted à partir d'un certain volume, voir notre comparatif n8n self-hosted vs cloud) répartit les exécutions entre plusieurs processus : rien ne garantit que le message suivant d'une même conversation soit traité par le worker qui a gardé l'historique en mémoire.
• Une longue conversation qui s'étale sur plusieurs heures : la mémoire vive ne survit pas à un webhook qui expire, à un sleep du conteneur, ou simplement au cycle de vie normal d'une exécution n8n déclenchée à la demande plutôt que maintenue en continu.

Dans les trois cas, la correction est la même : faire persister l'historique en dehors du process n8n.

La Session Key : la clé qui isole chaque conversation

Avant de parler de persistance, un point plus fondamental : que la mémoire soit en RAM ou en base, elle est toujours indexée par une Session Key. C'est cet identifiant qui dit au node « voici l'historique de cette conversation précise, pas d'une autre ». Une Session Key mal choisie — par exemple une valeur fixe, ou dérivée d'un champ qui n'identifie pas vraiment l'utilisateur — fait que deux personnes différentes peuvent se retrouver à partager le même historique, avec un agent qui répond à l'une en s'appuyant sur les messages de l'autre. C'est un vrai risque de confidentialité, pas seulement un bug cosmétique.

Les bons candidats pour la Session Key dépendent du canal :

• Chat n8n natif : l'ID de session généré automatiquement par le Chat Trigger.
• WhatsApp ou Telegram : le numéro de téléphone ou l'ID de l'expéditeur, stable d'un message à l'autre.
• Slack : l'identifiant du thread ou du canal, pour que chaque fil de discussion garde sa propre mémoire.
• Widget de chat sur un site : un UUID généré côté client au premier message et renvoyé à chaque appel suivant (stocké en localStorage ou en cookie de session).

Postgres Chat Memory : persister l'historique sans infrastructure supplémentaire

Le sous-node Postgres Chat Memory écrit chaque échange dans une table SQL, identifiée par credentials Postgres classiques — exactement les mêmes que celles utilisées pour un projet Supabase pgvector, comme décrit dans notre guide de connexion n8n-Supabase. Trois réglages suffisent :

1. Credentials Postgres — pointés vers votre instance Supabase existante ou une base dédiée.
2. Session Key — l'identifiant de conversation choisi selon le canal (voir ci-dessus).
3. Table Name — le node crée automatiquement la table si elle n'existe pas encore ; inutile d'écrire le SQL à la main pour démarrer, contrairement à la table pgvector qui, elle, nécessite l'extension et l'index décrits dans notre guide RAG.

L'avantage pour une équipe qui a déjà un Pack Assistant RAG en place : aucune brique d'infrastructure supplémentaire. Le même projet Supabase héberge à la fois les embeddings pour la recherche documentaire et l'historique de conversation — deux tables distinctes dans une seule base, un seul jeu de credentials à maintenir.

Le compromis fenêtre de contexte / coût

Chaque sous-node de mémoire expose un réglage de fenêtre de contexte (context window) : le nombre d'échanges passés réinjectés dans le prompt à chaque nouvelle question. Ce nombre a un impact direct sur la facture, un sujet détaillé dans notre article sur le suivi du coût des appels IA : plus la fenêtre est large, plus chaque appel au modèle consomme de tokens d'entrée, même si l'utilisateur ne pose qu'une question courte.

Une fenêtre trop étroite, à l'inverse, casse la cohérence dès qu'une conversation dépasse trois ou quatre échanges — l'agent « oublie » une préférence mentionnée deux messages plus tôt. En pratique, une fenêtre de 10 à 20 échanges couvre la grande majorité des usages support ou documentaire ; au-delà, mieux vaut résumer périodiquement l'historique ancien plutôt que de le renvoyer intégralement à chaque appel.

Redis Chat Memory : une alternative pour les gros volumes

Pour un agent à très fort trafic où la latence de lecture/écriture compte plus que la simplicité d'exploitation, Redis Chat Memory joue le même rôle que Postgres Chat Memory mais sur un store en mémoire, plus rapide en lecture. Le compromis : une brique d'infrastructure de plus à opérer et surveiller. Pour la grande majorité des chatbots n8n — support client, assistant documentaire interne, qualification de leads comme dans notre article sur la qualification des leads entrants par IA — Postgres Chat Memory reste le choix par défaut le plus simple, surtout quand une base Supabase existe déjà dans le pipeline.

Étapes pour brancher Postgres Chat Memory sur un agent existant

1. Ajoutez le sous-node Postgres Chat Memory et connectez-le à l'entrée « Memory » du node AI Agent.
2. Renseignez les credentials Postgres pointant vers votre projet Supabase.
3. Configurez la Session Key avec l'identifiant adapté au canal (voir plus haut) — c'est l'étape la plus souvent bâclée.
4. Fixez la fenêtre de contexte à une valeur raisonnable (10-20 échanges pour démarrer) et ajustez en observant le comportement réel.
5. Testez une conversation sur plusieurs échanges, redémarrez le workflow ou l'instance, puis reprenez la même conversation : l'historique doit être intact.

Pièges fréquents

• Session Key partagée par erreur entre deux canaux différents (par exemple le même identifiant pour le widget web et l'API), ce qui mélange deux historiques normalement indépendants.
• Historique jamais purgé : sur un usage soumis à des contraintes de conservation des données, une table de chat history qui grossit indéfiniment pose la même question de gouvernance que la piste d'audit décrite dans notre guide RGPD avec Supabase — prévoyez une purge périodique des conversations anciennes.
• Fenêtre de contexte laissée à une valeur par défaut sans jamais la reconsidérer une fois le volume réel de conversations connu.
• Confondre mémoire de conversation et base de connaissances : la mémoire de chat retient ce qui s'est dit dans cette conversation ; elle ne remplace pas un pipeline RAG pour interroger des documents.

Pour aller plus loin

La mémoire persistante n'est qu'une brique parmi d'autres pour fiabiliser un agent IA en production. Une fois l'historique de conversation sécurisé, les questions naturelles suivantes sont la gestion des erreurs et reprises, la limitation de débit des appels IA si le volume de conversations grimpe, et la mesure de la qualité des réponses avec notre article sur les évaluations de workflows IA. Le Pack Assistant RAG (119 €) inclut un chatbot avec citations déjà construit sur ce socle Supabase — sur lequel brancher Postgres Chat Memory ne demande aucune infrastructure supplémentaire. Pour un projet qui combine tri d'emails, assistant documentaire et rapports de conformité, le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit les trois packs sur la même base Supabase.