Comment donner une seule mémoire partagée à vos assistants IA

Vous expliquez votre stack, vos clients, vos contraintes à un assistant. Deux semaines plus tard vous passez à un autre modèle parce qu'il est meilleur sur ce dont vous avez besoin maintenant — et vous repartez de zéro. La mémoire que vous avez construite ne vous appartient pas : elle vit dans un produit.

C'est ça le vrai problème. Ce n'est pas que les assistants oublient : la plupart retiennent plutôt bien maintenant. C'est que chacun retient séparément, dans un stockage que vous ne pouvez ni lire, ni déplacer, ni brancher ailleurs.

Mémoire intégrée ou mémoire qui vous appartient

Les mémoires natives sont pratiques et gratuites. Elles ont aussi trois propriétés qu'il faut regarder en face : c'est l'éditeur qui décide de ce qui est retenu, les données restent chez lui, et rien ne vous suit quand vous partez. Pour un usage occasionnel, le marché est bon. Pour un travail que vous construisez sur des années, c'est un enfermement que vous avez choisi sans le voir.

L'alternative : garder la mémoire à l'extérieur des assistants et laisser chacun y lire. Il faut pour ça un protocole sur lequel les deux côtés s'accordent — c'est là qu'intervient MCP.

Ce qu'est réellement MCP

Le Model Context Protocol est un standard ouvert pour connecter un assistant à des outils et des données extérieurs. Anthropic l'a publié, et il a depuis été adopté bien au-delà de Claude. Du point de vue du modèle, un serveur MCP n'est qu'un jeu d'outils appelables : enregistre ceci, cherche cela.

Un serveur de mémoire expose une poignée d'outils — écrire un souvenir, chercher dans les souvenirs, lister un projet, faire remonter ce qui est pertinent maintenant — et l'assistant les appelle de lui-même quand la conversation en a besoin. Vous ne collez plus de contexte : le modèle va le chercher.

Les serveurs MCP existent sous deux formes, et cette différence compte plus que n'importe quel tableau de fonctionnalités :

• Local (stdio). Le serveur tourne comme un processus sur votre machine. Rapide, privé, gratuit — et invisible pour tout ce qui n'est pas une application de bureau sur cette machine. Ni votre téléphone, ni un onglet de navigateur.
• Distant (HTTP + OAuth). Le serveur vit à une URL. N'importe quel client qui gère les connecteurs distants peut s'y connecter, depuis n'importe quel appareil.

Si vous voulez une mémoire partagée entre assistants et appareils, c'est la seconde forme qu'il vous faut. Si vous voulez une mémoire sur un seul portable qui n'en sort jamais, la première est franchement le meilleur choix — et elle est gratuite.

Comment se branche une mémoire distante

Il n'y a rien à installer. Un serveur MCP distant, c'est une URL plus une connexion OAuth, exactement le même geste que brancher un agenda à une application :

1. Collez l'URL du serveur dans les réglages de connecteurs de votre client.
2. Le client récupère les métadonnées OAuth du serveur et s'enregistre tout seul.
3. Vous autorisez l'accès dans une fenêtre de navigateur, une fois.
4. Les outils apparaissent. L'assistant les appelle quand c'est pertinent.

Refaites l'étape une dans un deuxième client, et les deux lisent et écrivent désormais la même mémoire. Toute l'astuce est là : la mémoire est un service, pas un fichier. Notre version pas à pas, avec des captures par client, est dans le guide de connexion.

Stocker est facile. Le produit, c'est de retrouver.

N'importe quoi sait ajouter du texte dans une base. Le difficile, c'est de répondre, des mois plus tard et au milieu d'une conversation sans rapport, lesquels de vos quatre mille souvenirs comptent maintenant. Ratez ça et vous avez construit une archive que personne ne lit.

Deux façons d'échouer, les deux courantes :

• La recherche par mots-clés seule rate tout ce qui est formulé autrement que ce que vous avez écrit.
• La recherche vectorielle seule renvoie des choses vaguement dans le sujet et manque les noms exacts, les codes d'erreur et les identifiants — précisément les détails que vous cherchiez.

Les implémentations sérieuses font les deux et fusionnent les classements — la fusion de rangs réciproques est la méthode habituelle — puis réévaluent la liste courte avec un modèle de reclassement qui lit vraiment la question et le candidat ensemble. Ça coûte plus cher par requête, et c'est la différence entre une mémoire et un tas.

Si vous travaillez dans plus d'une langue, vérifiez ce point précisément. Une chaîne calibrée sur des embeddings anglais se dégrade silencieusement en français ou en allemand, et la panne est invisible : vous obtenez juste de moins bons résultats et vous vous dites que vous avez mal noté.

Cinq questions avant de s'engager

1. Local ou distant ? Tranchez ça d'abord : dans un sens comme dans l'autre, ça élimine la majorité du marché.
2. Où sont les données, et sous quelle juridiction ? Si la réponse n'est pas sur le site, partez du principe qu'elle ne vous plaira pas.
3. Pouvez-vous les ressortir ? Un export dans un format utilisable, à la demande, sans écrire au support.
4. Recherche hybride et reclassement, ou simple vectoriel ? Posez la question : c'est rarement mis en avant.
5. Que se passe-t-il au bord du palier gratuit ? Supprimé, gelé ou en lecture seule : trois issues très différentes.

Où se situe Pryzm

Pryzm Memory est de la seconde forme : un point d'entrée hébergé, une connexion OAuth, partagé par tous les clients que vous branchez. Ça tourne sur des serveurs en Allemagne, sous juridiction européenne, chiffré au repos, avec un schéma et un rôle de base de données par client imposés par PostgreSQL lui-même. La recherche est hybride, avec un reclasseur multilingue, sur huit langues.

Ce n'est pas non plus open source, et vous ne pouvez pas l'auto-héberger aujourd'hui — ce qui est disqualifiant pour certains, et on préfère l'écrire ici plutôt que vous le laissiez découvrir après l'inscription. On maintient un comparatif honnête avec les alternatives, y compris celles qui nous battent précisément sur ces deux points.