La plupart des LLM oublient tout dès qu’une session se termine. Fermez l’onglet, démarrez une nouvelle conversation, et le modèle n’a aucune idée de qui vous êtes, de ce que vous construisez ou de ce que vous avez décidé la semaine dernière. Un serveur MCP de mémoire résout ce problème précis, mais uniquement celui-là. Comprendre la différence entre ce qu’il résout et ce qu’il ne résout pas est ce que la plupart des premières configurations interprètent mal.
Ce qui se casse généralement en premier
- La mémoire MCP est un serveur externe, pas une mise à jour du modèle : le LLM lui-même ne change pas.
- Elle utilise un graphe de connaissances pour stocker et récupérer des faits entre les sessions.
- Elle résout l’oubli des faits, pas la compréhension contextuelle approfondie des bases de code ou des normes d’équipe.
- Chaque session supporte un coût en tokens pour charger les faits stockés, que ces faits soient nécessaires ou non.
Ce qu’est réellement Memory MCP
Le Model Context Protocol définit une manière standard pour les serveurs externes de communiquer avec les clients LLM. Un serveur MCP de mémoire est un type spécifique : son rôle est de conserver le contexte entre les sessions. Ce n’est pas du stockage de fichiers. Ce n’est pas de la recherche Web. C’est une mémoire persistante, celle qui survit lorsque vous fermez Claude Desktop et le rouvrez trois jours plus tard.
L’implémentation de référence, @modelcontextprotocol/server-memory, se décrit comme un système de mémoire persistante basé sur un graphe de connaissances. Cette formulation est importante. Il ne s’agit pas d’une simple liste de notes. C’est un graphe structuré d’entités et de leurs relations, stocké localement et interrogé au début de chaque nouvelle session.
L’expression « mémoire mcp » est utilisée de manière assez large pour désigner plusieurs choses : le serveur de référence, des alternatives tierces et le concept général de stockage persistant de mémoire pour les assistants IA. Dans cet article, nous parlons de la catégorie dans son ensemble, en nous appuyant sur ce que répertorie le registre MCP officiel et sur le comportement réel des implémentations en production.
Comment fonctionne le modèle de récupération par graphe de connaissances
Voici ce qui se passe réellement en coulisses lorsqu’un serveur MCP de mémoire fait son travail.
Les faits sont stockés sous forme d’entités et de relations dans un graphe de connaissances. Une entité peut être un nom de projet, une personne, une décision technologique ou une préférence. Une relation relie deux entités : « Le projet X utilise PostgreSQL », « Arjun préfère TypeScript », « Le service Y dépend du service Z ». Au fil du temps, ces éléments s’accumulent pour former une carte structurée de tout ce que l’assistant a reçu comme information à mémoriser.
Lorsqu’une nouvelle session démarre, le serveur interroge ce graphe et récupère les entrées pertinentes afin de les injecter dans le contexte du modèle. Les implémentations simples utilisent la correspondance par mots-clés. Mais la recherche par mots-clés manque certains éléments. Demandez des informations sur « le choix de base de données pour le backend » et une recherche par mots-clés risque de ne pas faire ressortir l’entité étiquetée « décision d’architecture de la couche de stockage ».
C’est là qu’intervient la récupération hybride. Des implémentations plus sophistiquées, dont certaines sont répertoriées dans la collection Awesome MCP Servers, combinent la recherche vectorielle avec le classement BM25 et des passes de reranking. La recherche vectorielle détecte la similarité sémantique : le modèle comprend que « stockage backend » et « choix de base de données » renvoient au même concept, même sans mots-clés communs. BM25 capte les correspondances de termes précises. Le reranker ordonne les résultats selon leur pertinence pour la requête actuelle.
La conséquence pratique : avec une récupération basique par mots-clés, l’assistant peut ne pas faire ressortir une décision d’architecture cruciale parce que vous avez formulé la question différemment dans cette session. Avec une recherche sémantique soutenue par un graphe de connaissances, il a davantage de chances de relier les informations entre elles.
Un point que le travail sur l’ingénierie du contexte en 2026 a clairement établi : les systèmes de mémoire sérieux reposent rarement sur un seul stockage. Ils superposent du contexte à court terme, de la mémoire vectorielle à long terme et de la récupération externe. MCP s’impose comme le connecteur standard entre ces couches et l’agent. L’implémentation de référence représente la version la plus simple de cette architecture. Les configurations de production comportent généralement davantage de couches.
Ce qui est stocké et comment la récupération est déclenchée
Ce qui est stocké dépend fortement de la configuration du serveur. Préférences utilisateur, détails de projet, décisions d’architecture, conventions de code, notes sur des incidents passés : tous ces éléments peuvent vivre dans le stockage de mémoire s’ils sont correctement capturés.
Le mot critique est « s’ils ». L’implémentation doobidoo/mcp-memory-service documente deux modes : les appels de stockage explicites, où l’utilisateur ou l’agent IA appelle un outil spécifique pour enregistrer un fait, et la capture automatique pilotée par événements, où des hooks déclenchent une mise à jour de la mémoire selon les événements de conversation. La plupart des configurations débutantes utilisent le premier mode, ce qui signifie que si personne ne dit explicitement « mémorise ceci », rien n’est sauvegardé.
C’est ainsi que les agents IA accumulent au fil du temps une mémoire partagée réellement utile. L’agent stocke des faits lorsqu’il les rencontre, puis les récupère lors de sessions ultérieures sans que l’utilisateur ait à tout réexpliquer.
Le mécanisme de déclenchement compte tout autant. La récupération peut être lancée au début de la session, en chargeant les N souvenirs les plus pertinents, à la demande au milieu d’une conversation en interrogeant le graphe, ou selon les deux approches. Bien le configurer implique des décisions que la plupart des guides d’installation ignorent.
Le coût en tokens que la plupart des configurations ignorent
C’est la partie qui a tendance à surprendre après quelques semaines d’utilisation d’un serveur MCP de mémoire.
Chaque session qui utilise la récupération de mémoire paie un coût initial en tokens. Selon l’analyse d’Unblocked sur l’empreinte mémoire de Claude Code, les préchargements de mémoire MCP typiques consomment entre 2 000 et 5 000 tokens par session dans les implémentations courantes, et le README de doobidoo/mcp-memory-service documente des empreintes dépassant 500 000 tokens après environ 50 utilisations d’outils. Ce préchargement a lieu avant le début de toute tâche réelle, avant même que vous ayez saisi une seule question.
Le coût est payé, que les faits stockés soient pertinents pour le travail du jour ou non. Si vous travaillez sur un projet totalement différent de celui présent dans le stockage de mémoire, vous chargez quand même du contexte que vous n’utiliserez pas. C’est cela, en pratique, la gestion des couches de mémoire : pas seulement ce que vous stockez, mais la quantité que vous chargez et à quel moment.
📊 En pratique :
Un préchargement de 2 000 à 5 000 tokens par session paraît modeste pour un usage occasionnel. Aux tarifs des modèles GPT-4o ou Claude Sonnet, un stockage de mémoire fortement chargé utilisé sur des dizaines de sessions quotidiennes commence à générer un coût mensuel mesurable, avant l’exécution de toute tâche réelle. Prévoyez ce budget avant de commencer à tout stocker.
Ce que Memory MCP peut et ne peut pas mémoriser
C’est ici que les premières impressions sur Memory MCP divergent le plus de la réalité.
Memory MCP gère bien l’oubli des faits. Si vous indiquez à l’assistant que votre API utilise l’authentification JWT, que le pipeline de déploiement s’exécute sur GitHub Actions et que Priya est l’ingénieure d’astreinte pour le service de paiements, ces faits peuvent être stockés, récupérés et injectés dans de futures sessions. L’IA n’a pas besoin d’être réentraînée. Elle dispose simplement des faits lorsque la nouvelle session démarre.
Ce qu’il ne fait pas : donner au LLM une compréhension contextuelle plus large. Si votre base de code suit une convention implicite selon laquelle toutes les limites de service sont définies dans un modèle de fichiers particulier, ce n’est pas un fait que vous avez explicitement stocké : c’est une propriété structurelle du code. Memory MCP ne lit pas votre dépôt. Il lit ce qui y a été placé. Les LLM eux-mêmes ne changent pas ; c’est le même modèle qui s’exécute à chaque session. Le serveur de mémoire injecte simplement dans la session actuelle le contexte pertinent stocké lors des sessions précédentes.
La distinction est la suivante : les faits explicites persistent bien ; la structure implicite ne persiste pas, sauf si elle est explicitement capturée ; les conventions d’équipe ne persistent que si quelqu’un a décidé de les rédiger et de les stocker. La plupart des bases de code réelles contiennent d’énormes quantités d’informations pertinentes que personne n’a jamais formulées explicitement.
Cette même limite s’applique aux agents IA qui utilisent une mémoire partagée entre plusieurs workflows. Un agent peut savoir que « le client X préfère les rapports PDF » parce que cela a été stocké. Il ne peut pas savoir que votre équipe s’en remet toujours à l’ingénieur senior pour les décisions d’infrastructure, à moins que quelqu’un ait explicitement stocké ce fait.
L’écart entre ce que Memory MCP semble faire et ce qu’il fait réellement est à l’origine de la plupart des demandes de support sur ce sujet. « Pourquoi ne se souvient-il pas de nos conventions ? » Parce que les conventions n’ont jamais été saisies. Les capacités de mémoire sont réelles, mais elles se limitent aux informations délibérément stockées.
L’idée reçue qui fait échouer les premières configurations
Je vois sans cesse ce schéma : une personne configure un serveur MCP de mémoire, échange quelques conversations avec son assistant IA, puis rouvre le client en s’attendant à ce qu’il se souvienne parfaitement de tout ce dont ils ont parlé. Rien ne revient. Le stockage de mémoire est soit vide, soit il renvoie des entrées non pertinentes.
L’hypothèse est que le LLM capture automatiquement les détails importants en arrière-plan. La plupart des implémentations ne fonctionnent pas ainsi. Le serveur de référence exige des appels de stockage explicites. Vous ou l’agent devez invoquer l’outil de mémoire pour dire « enregistre ceci ». Si ces appels ne sont pas déclenchés, rien n’est ajouté.
La capture entièrement automatique, où le serveur s’intègre au flux de conversation et décide quoi sauvegarder sans instruction explicite, existe dans certains serveurs tiers, mais elle exige une configuration utilisateur définissant ce qui mérite d’être sauvegardé. Les instructions personnalisées sont importantes ici : vous devez indiquer au système quelles catégories de faits capturer, quels modèles de mémoire basés sur les fichiers surveiller et dans quelles conditions écrire un nouveau souvenir plutôt que mettre à jour un souvenir existant.
La mémoire des assistants IA n’est pas préconfigurée pour votre contexte spécifique. Ce travail de conception vous revient.
Cas d’usage réels de Memory MCP pour les agents IA et les workflows LLM
Quatre cas d’usage reviennent systématiquement en pratique, et il est utile de les distinguer car ils n’ont pas les mêmes exigences de configuration.
La mémoire persistante de profil personnel ou d’équipe est la plus simple. Stockez les préférences, les styles de travail, les normes de communication et les choix d’outils. Un assistant IA qui sait que vous préférez des explications concises à des explications détaillées, ou que votre équipe utilise Jira plutôt que Linear, devient rapidement beaucoup plus utile.
La mémoire de projet à long terme est le domaine où Memory MCP démontre sa valeur pour les développeurs. Décisions d’architecture, justifications de conception, alternatives rejetées, anciens parcours de débogage : ce sont les faits réexpliqués des dizaines de fois sans stockage de mémoire. Avec un tel stockage, un workflow d’assistant de code peut reprendre là où il s’était arrêté au lieu de repartir de zéro à chaque session.
Les graphes de connaissances spécifiques à un domaine vont plus loin. Une équipe de conformité peut maintenir un stockage de mémoire contenant les interprétations de décisions passées. Une équipe support peut stocker des modèles de résolution pour les problèmes récurrents. L’implémentation MCP Market prend en charge des stockages de mémoire par projet, limités à des workflows précis, afin que la base de connaissances d’un projet ne se mélange pas avec celle d’un autre.
La continuité entre plusieurs sessions est particulièrement importante pour les agents IA exécutant des workflows de longue durée. Un agent chargé d’une tâche de recherche sur plusieurs jours doit se souvenir de ce qu’il a déjà couvert. Sans mémoire entre les sessions, chaque redémarrage repart d’une feuille blanche : parfois utile, mais désastreux pour les tâches complexes.
Utiliser la mémoire de graphe de connaissances pour les sessions de développeurs et d’assistants de code
Pour Claude Desktop, Cursor, VS Code et les outils de développement similaires, la proposition de valeur est précise : vous cessez de réexpliquer le même contexte architectural à chaque fois.
Les sessions Claude Code, par exemple, démarrent sans contexte par défaut. Ajoutez un serveur MCP de mémoire limité à un dépôt et l’assistant connaît soudainement les choix techniques sans qu’il soit nécessaire de les lui rappeler : « Nous utilisons Prisma, pas du SQL brut. La couche d’authentification se trouve dans /lib/auth, pas dans les gestionnaires de routes. Le pipeline CI échoue si la couverture tombe sous 80 %. »
Les stockages de mémoire par projet, un par dépôt ou service, empêchent les faits d’architecture d’une base de code de contaminer les recommandations pour une autre. C’est le modèle de conception autour duquel l’implémentation MCP Market a été conçue pour les agents de code.
Si vous utilisez quelque chose comme AI Agent Builder de Latenode pour orchestrer des workflows de code en plusieurs étapes, vous pouvez notamment connecter automatiquement les registres de décisions d’architecture et les résumés de PR fusionnées à un stockage de mémoire centralisé, afin que l’assistant dispose d’un contexte à jour sans mises à jour manuelles. Le RAG intégré de Latenode indexe les documents d’architecture Markdown et PDF sans devoir déployer une base de données vectorielle distincte, ce qui élimine l’une des étapes de configuration les plus pénibles de ce type de pipeline.
Cela dit, même les configurations bien conçues ne capturent pas tout ce qui compte dans une base de code. Memory MCP gère bien les décisions explicites. Les modèles implicites nécessitent toujours davantage.
La mémoire était au vert. L’assistant ne savait toujours pas reconnaître l’odeur de la base de code à 2 heures du matin.
Choisir un serveur MCP de mémoire : les vraies différences entre API et concepts fondamentaux
Le choix entre l’implémentation de référence et les serveurs tiers repose sur quelques critères concrets. Voici ce qui diffère réellement selon les options :
- Méthode de récupération : mots-clés ou hybride
La référence @modelcontextprotocol/server-memory utilise une navigation de graphe basique. Les serveurs tiers, comme ceux de Awesome MCP Servers, combinent la recherche vectorielle sémantique avec le classement BM25. Si votre stockage de mémoire contient des faits liés conceptuellement mais ne partageant pas les mêmes mots-clés, la récupération hybride détecte beaucoup plus de contexte pertinent. C’est la plus grande différence de qualité entre les implémentations.
- Backend de stockage : local ou partagé
Le serveur de référence stocke le graphe de connaissances localement. Cela signifie un appareil, un utilisateur. Si vous avez besoin d’une mémoire partagée au sein d’une équipe ou entre plusieurs appareils, vous avez besoin d’un serveur avec un backend centralisé ou une synchronisation explicite. Certaines implémentations tierces prennent en charge SQLite avec un chemin configurable, ce qui permet un partage simple via un volume réseau ; d’autres proposent un véritable stockage distant avec authentification.
- Mode de capture : manuel ou automatique
La plupart des implémentations, y compris le serveur de référence, nécessitent des appels de stockage explicites via l’API MCP. Certains serveurs tiers prennent en charge la capture automatique pilotée par événements, mais cela exige une configuration pour définir les règles de capture. La mémoire « configurez et oubliez » n’est pas l’état par défaut : elle demande un travail de configuration volontaire, quel que soit le serveur choisi.
- Surface API et déploiement auto-hébergé
L’implémentation de référence possède une API minimale avec un petit ensemble d’outils : créer des entités, créer des relations, ajouter des observations et rechercher. Les serveurs plus avancés exposent des API plus riches, incluant des contrôles de décroissance, du scoring de mémoire et des opérations groupées. Les configurations auto-hébergées varient : certaines se limitent à un seul processus Node.js, tandis que d’autres exigent qu’un service de base de données fonctionne en parallèle. Évaluez honnêtement la charge de maintenance avant de choisir.
- Modèle d’authentification
Les implémentations locales ne nécessitent généralement aucune configuration d’authentification au-delà de ce que votre client MCP gère déjà. Les implémentations distantes ou partagées peuvent exiger une gestion de clés API ou des flux OAuth, selon le backend. Cela compte surtout si plusieurs personnes ou agents lisent et écrivent dans le même stockage.
- Surcharge en tokens par session
Les différentes implémentations renvoient des charges utiles de tailles différentes. Le serveur ai-memory-mcp documente des charges utiles de rappel jusqu’à 79 % plus petites que des exports JSON naïfs grâce à son système de scoring multifactoriel. Des charges utiles plus petites signifient moins de surcharge en tokens par session. Si vous exécutez des dizaines de sessions par jour, cette différence s’accumule.
🤔 Attendez.
Dans la plupart des descriptions produit, la « mémoire pour l’IA » évoque un rappel fluide et automatique de tout ce qui est pertinent. En pratique, elle exige des choix de schéma explicites sur ce qu’il faut stocker, une planification active du budget de tokens afin que le préchargement ne consume pas votre contexte de travail, ainsi qu’un plan de secours pour les sessions où aucune information utile n’a jamais été sauvegardée. Le marketing et la checklist de configuration décrivent deux réalités différentes.
