Agent IA n8n : la mémoire qui retient chaque client

Un agent IA n8n sans mémoire oublie tout d’un message à l’autre : chaque requête au modèle repart de zéro. Pour votre client, c’est la différence entre un support qui redemande trois fois le numéro de commande et un assistant qui reprend la discussion laissée il y a trois jours. Dans cette vidéo, je teste trois mémoires dans n8n (la mémoire simple, Postgres sur Supabase, puis une mémoire par utilisateur sur Telegram) et je présente Zep, la mémoire en graphe.

38:29

Pourquoi votre agent oublie tout

Sur l’interface de ChatGPT, la conversation reste en tête du modèle. Par l’API, ce n’est pas le cas : vous envoyez un prompt, il répond, et au deuxième appel il a tout oublié. Un agent dans n8n passe par l’API. Sans mémoire, il ne sait pas comment vous vous appelez, même si vous le lui avez dit dix secondes plus tôt.

La mémoire est le branchement qui corrige ça. À chaque message, n8n va chercher les derniers échanges stockés et les envoie au modèle avec le nouveau message. L’agent ne « se souvient » pas : on lui relit l’historique à chaque fois.

Je pars ici d’un agent déjà construit. Si vous n’en avez pas encore, le guide pour créer un agent IA dans n8n montre les quatre pièces (modèle, prompt, mémoire, outils) et un premier agent avec la mémoire la plus simple. Pour l’outil lui-même, voyez le guide n8n.

Les mémoires disponibles dans n8n en octobre 2026

J’ai revérifié la liste dans la documentation de n8n le 27 octobre 2026. Le nœud AI Agent accepte une mémoire, à choisir parmi :

Deux nœuds sont dépréciés : Zep depuis n8n 1.108.0, Motorhead depuis 2.8.0 (le projet n’est plus maintenu). Un nœud à part, Chat Memory Manager, sert à lire, réécrire ou compléter une mémoire existante. J’y reviens plus bas.

Les mémoires à base de données se règlent toutes de la même façon : une clé de session (qui identifie la conversation) et une longueur de contexte (combien d’échanges précédents on renvoie au modèle).

Simple Memory : pour tester, jamais pour livrer

Dans la vidéo, je demande d’abord à l’agent sans mémoire « comment je m’appelle ? ». Il ne sait pas. J’ajoute Simple Memory avec ses réglages par défaut : la clé est l’identifiant de session du chat de n8n, et la fenêtre est de 5 messages. Même question, et cette fois il répond.

Ses limites, pour un projet client :

• Les messages vivent dans n8n. Le serveur redémarre, l’historique est perdu. Vous changez de serveur, pareil.
• Le client ne peut rien relire. S’il veut retrouver les échanges entre son agent et ses propres clients, il n’y a rien à exporter.
• La documentation de n8n précise qu’elle ne marche pas en production sur une instance en queue mode, parce que deux messages peuvent arriver sur deux workers différents.

Dans la vraie vie d’une entreprise, on ne garde pas une conversation client dans la mémoire de n8n. On la persiste : on l’enregistre dans une base, pour pouvoir y revenir.

Postgres Chat Memory sur Supabase, pas à pas

Postgres est une base de données open source, légère et rapide. C’est la mémoire persistante la plus simple et la plus robuste à brancher. Pour en avoir une sans rien installer, j’utilise Supabase.

1. Créer la base

1. Créez un compte sur Supabase, puis un nouveau projet dans votre organisation.
2. Choisissez un mot de passe de base de données et gardez-le : c’est lui que n8n utilisera. Supabase ne pourra pas vous le réafficher. Si vous le perdez, réinitialisez-le dans Project Settings, puis Database.
3. Choisissez la région (la France, pour un client français) et lancez la création. Attendez que l’indicateur passe du orange au vert, quelques minutes.

Le plan gratuit de Supabase suffit pour tester : 500 Mo de base au 27 octobre 2026. Mais un projet gratuit est mis en pause après une semaine sans activité. Pour un agent livré, prenez un plan payant de Supabase, ou la base Postgres que le client possède déjà.

2. Brancher n8n

Dans Supabase, cliquez sur Connect, puis prenez les paramètres du Transaction pooler (le deuxième bloc, pas la connexion directe). Dans n8n, ajoutez Postgres Chat Memory sous l’agent et créez une connexion :

Bandeau vert à l’enregistrement : la connexion marche. Bandeau rouge : un paramètre est faux, le plus souvent le port ou l’utilisateur.

3. Laisser n8n créer la table

Vous n’avez rien à créer. Par défaut, le nœud propose une table n8n_chat_histories et la crée au premier message. Dans le Table Editor de Supabase, elle apparaît avec trois colonnes :

• id : le numéro de la ligne ;
• session_id : la clé de la conversation ;
• message : le message en JSON, avec son type (humain ou IA), son contenu et des métadonnées.

La fenêtre de contexte est encore à 5. Vous pouvez monter à 20, mais chaque message gardé est renvoyé au modèle à chaque appel : plus de tokens, donc plus de coût. Rien d’énorme, mais à régler selon l’usage du client.

À ce stade, la conversation survit au redémarrage de n8n. Il reste un problème : je rafraîchis le navigateur, l’identifiant de session change, et l’agent repart de zéro.

La mémoire par utilisateur : la clé qui change tout

Pour un agent de support, c’est rédhibitoire. Le client de votre client revient dans deux ou trois jours, repose sa question, et l’agent doit retrouver toute la discussion. La solution tient dans un réglage : au lieu de l’identifiant de session, on prend l’identifiant de la personne comme clé.

Le chat intégré de n8n ne connaît pas la personne : il n’envoie qu’un identifiant de session, une action et le message. Il faut un canal qui identifie l’utilisateur : WhatsApp (le numéro de téléphone ou un identifiant interne), Telegram, une messagerie de site connectée à un compte. Dans la vidéo, je prends Telegram, le plus rapide à monter.

Créer le bot Telegram

1. Dans Telegram, ouvrez une conversation avec BotFather, puis tapez /newbot.
2. Donnez un nom au bot, puis un nom d’utilisateur, attaché, qui finit par bot (les underscores sont permis).
3. BotFather vous donne un jeton d’API. Dans n8n, ajoutez le déclencheur Telegram Trigger (sur l’événement Message), créez une connexion et collez ce jeton.

Régler la clé et le prompt

Envoyez un premier message au bot et épinglez la donnée reçue dans n8n (la touche P sur le nœud) : vous testez ensuite sans repasser par Telegram. Telegram envoie l’identifiant du message, l’expéditeur (from, avec son identifiant, son nom et son nom d’utilisateur) et l’identifiant du chat.

Dans Postgres Chat Memory, passez la clé de session en Define below. Dans l’agent, faites de même pour le prompt, qui devient le texte envoyé par la personne. Puis ajoutez un nœud Telegram d’envoi de message (Send Message) pour répondre dans le bon chat :

Postgres Chat Memory > Session Key : {{ $('Telegram Trigger').item.json.message.from.id }}
AI Agent > Prompt (User Message)    : {{ $('Telegram Trigger').item.json.message.text }}
Telegram > Chat ID                  : {{ $('Telegram Trigger').item.json.message.chat.id }}
Telegram > Text                     : {{ $json.output }}

Pourquoi from.id et pas chat.id ? En conversation privée avec le bot, les deux sont égaux. Mais si le client ajoute son bot dans un groupe, l’identifiant du chat devient celui du groupe, partagé par tous ses membres : leurs conversations se mélangeraient dans la même mémoire. La personne, elle, garde le même identifiant partout.

Dans la vidéo, après avoir donné mon prénom, je rafraîchis la page et relance un message : l’agent répond « Vous m’avez dit que vous vous appelez Naier ». Dans Supabase, mes messages et ceux de l’agent sont rangés sous mon identifiant Telegram. Le serveur peut redémarrer, la personne peut revenir dans une semaine ou un mois : la conversation est là.

Ce que Postgres ne sait pas faire : relier les faits

Postgres garde une liste de messages, et l’agent la relit. Il n’y a aucun lien entre les informations, aucune notion de temps. Un cerveau humain sait que Paul est un ami, qu’il était marié depuis telle date, et que ce mariage s’est terminé à telle autre. Une liste de messages ne sait pas ça.

C’est l’idée des mémoires en graphe, dont Zep est l’outil le plus connu. Dans Zep, un projet contient des utilisateurs (si l’agent parle à 40 personnes, il y a 40 utilisateurs), chacun avec ses conversations et son graphe. Chaque discussion ajoute des entités (une personne, un produit) et des relations entre elles, avec une date de début et une date de fin de validité.

Surtout, le graphe se nourrit d’autres sources que la conversation. Pour l’agent de support d’un SaaS, vous y injectez les achats du client, son forfait, ce à quoi il a droit ou pas, ses préférences. L’agent répond avec une vue d’ensemble de la personne, pas seulement avec ses cinq derniers messages.

Zep dans n8n en 2026 : plus de nœud natif

Dans la vidéo, en octobre 2025, je disais que le nœud Zep de n8n avait disparu, sans savoir s’il reviendrait. Au 27 octobre 2026, la documentation de n8n le confirme : le nœud Zep est déprécié depuis la version 1.108.0. Il n’est pas revenu.

Zep, lui, existe toujours et s’est orienté vers les développeurs et l’entreprise : il se présente comme une couche de contexte qui réunit données métier, documents et conversations, avec une API et un serveur MCP. Dans n8n, vous y accédez donc comme à un outil (un nœud HTTP Request vers son API, ou le nœud MCP Client Tool), pas comme une mémoire qu’on branche en un clic. C’est du travail de développement, à réserver aux clients qui en ont vraiment besoin.

Pour la plupart des projets, deux solutions natives couvrent l’essentiel :

• Chat Memory Manager ajoute dans la mémoire des messages qui donnent du contexte à l’agent. Avant l’agent, vous lisez la fiche du client dans le CRM (forfait, dernières commandes) et vous l’injectez dans sa mémoire.
• Une table de faits : une table Postgres « client, fait, date » que l’agent lit et écrit par un outil. C’est moins élégant qu’un graphe, mais le client peut la lire et la corriger.

Si ce que l’agent doit retrouver, ce sont des documents (conditions générales, fiches produits, procédures), ce n’est plus de la mémoire : c’est un RAG, une base de connaissance que l’agent interroge.

Quelle mémoire livrer à quel client

Si plusieurs agents doivent partager ce qu’ils savent d’un même client, donnez-leur la même table et la même clé par utilisateur : c’est la base d’un système multi-agent qui tient la route. Et si vous hébergez n8n vous-même pour éviter l’abonnement, ce que coûte vraiment n8n gratuit vous dit où placer la base.

Côté Claude Code, la logique est la même : sa mémoire tient dans un fichier que vous écrivez, le CLAUDE.md, qu’il relit à chaque session.