Memori : mémoire d'agent persistante, entre SDK embarqué et service hébergé
Memori is agent-native memory infrastructure. A LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems. Built for enterprise, Memori works with the data infrastructure you already run, no rip-and-replace, and deploys across managed cloud, single-tenant cloud, VPC, and on-premises.
En bref
- De quoi s’agit-il ?
- Memori transforme les échanges et l'exécution d'un agent en état persistant, avec un SDK Python et TypeScript qui s'enregistre sur un client LLM existant. Le point à trancher n'est pas la fonctionnalité, mais le partage entre ce que vous hébergez et ce qui passe par Memori Cloud.
- À qui s’adresse-t-il ?
- Memori convient à une équipe qui veut de la mémoire d'agent sans écrire sa propre couche de persistance, et qui accepte soit un service hébergé, soit une base qu'elle fournit elle-même via le mode BYODB. Il ne convient pas à qui veut une mémoire entièrement locale et sans clé d'API, ni à qui refuse de faire transiter ses conversations par un tiers.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 12 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un agent qui oublie entre deux appels
Un agent qui appelle un modèle sans couche de mémoire repart de zéro à chaque requête. Le README résume la situation pour OpenClaw en une phrase : par défaut, les agents oublient tout entre les sessions. La réponse habituelle consiste à recoller l'historique dans le prompt, ce qui fait grossir la requête à chaque tour. Memori prend le problème par l'autre bout : il conserve l'état en dehors du prompt et ne réinjecte que ce qui est nécessaire. Le projet vise les systèmes en production, avec un positionnement explicite vers l'entreprise : déploiement en cloud managé, en cloud mono-locataire, en VPC ou sur site. Le public visé n'est donc pas celui qui prototypise une boucle de chat, mais celui qui doit garder un historique exploitable pour un agent déjà en service, sur une infrastructure qu'il ne veut pas remplacer.
Ce que fait register() sur un client OpenAI
Le mécanisme tient en deux appels. On construit d'abord un client LLM classique, puis on l'enregistre auprès de Memori. En Python, cela donne client = OpenAI() puis mem = Memori().llm.register(client). En TypeScript, l'enchaînement est new Memori().llm.register(client).attribution('user_123', 'support_agent'). Une fois cet enregistrement fait, les appels passent par le client habituel, et le README indique que les conversations sont persistées et rappelées automatiquement en arrière-plan. Le second appel, qui demande la couleur préférée de l'utilisateur, retrouve l'information donnée au premier. L'attribution est la pièce qui rend la mémoire exploitable : elle associe les échanges à une entité et à un processus, entity_id et process_id côté Python, deux chaînes côté TypeScript. C'est ce couple qui délimite ce qu'un agent peut rappeler. Le SDK s'installe par pip install memori ou npm install @memorilabs/memori, et le projet revendique l'absence de dépendance à un LLM, à un datastore ou à un framework particuliers.
Un service hébergé au centre du dispositif
Le quickstart ne démarre pas sans une clé obtenue sur app.memorilabs.ai. Il faut définir MEMORI_API_KEY en plus de la clé du fournisseur de modèle, par exemple OPENAI_API_KEY. Le tableau de bord donne accès aux mémoires, aux analytiques, à un playground et à la gestion des clés. C'est le point de conception le plus lourd du projet, et il mérite d'être dit sans détour : la voie par défaut fait transiter les conversations par un service tiers. Le mode BYODB existe précisément pour répondre à cette objection, puisque le README renvoie vers une documentation dédiée pour utiliser sa propre base de données. Il faut noter que cette documentation n'est pas incluse dans le matériel fourni : on sait que le mode existe et qu'un guide TiDB Zero est mentionné pour les bases de développement jetables, mais pas quelles bases sont prises en charge ni comment la configuration se présente. C'est une vérification à faire avant de s'engager.
Deux intégrations prêtes à l'emploi : OpenClaw et Hermes
Memori ne se limite pas au SDK. Le projet fournit un plugin OpenClaw et un fournisseur de mémoire pour Hermes Agent. Dans le premier cas, l'installation se fait par openclaw plugins install @memorilabs/openclaw-memori puis openclaw plugins enable openclaw-memori, avant une initialisation qui prend une clé d'API, un entity-id et un project-id, et un redémarrage de la passerelle. Le README précise que le plugin se branche sur le cycle de vie d'OpenClaw et capture, après chaque tour, les appels d'outils, les décisions et les résultats, sans modification du code ni des prompts de l'agent. Pour Hermes, l'installation passe par pip install hermes-memori et hermes-memori install, puis hermes config set memory.provider memori. Les identifiants se placent dans un fichier .env sous HERMES_HOME, avec MEMORI_API_KEY et MEMORI_ENTITY_ID. MEMORI_PROJECT_ID reste optionnel : sans lui, le fournisseur utilise le contexte de projet actif d'Hermes. Ces deux intégrations exposent des outils de rappel explicites côté Hermes, memori_recall et memori_recall_summary, ce qui laisse l'agent décider quand consulter sa mémoire.
Le chiffre du benchmark LoCoMo et ce qu'il ne dit pas
Le projet publie un résultat sur LoCoMo, un benchmark de mémoire sur conversations longues : 87 % de précision globale pour une moyenne de 721 tokens par requête, soit 2,8 % de l'empreinte d'un contexte complet. Le README indique que Memori dépasse Zep, LangMem et Mem0 sur ce même benchmark, avec environ 67 % de réduction de prompt face à Zep. Ces chiffres proviennent du projet lui-même et renvoient à un article sur arXiv ainsi qu'à des pages de résultats. Ils décrivent une configuration précise, celle du benchmark, et ne préjugent pas du comportement sur un corpus métier réel. Un point pratique compte davantage pour l'adoption : la consommation de tokens par requête dépend de ce que la couche de mémoire décide de rappeler, et le README ne détaille pas les paramètres qui gouvernent cette sélection. C'est la première chose à mesurer sur vos propres conversations.
Là où Memori n'est pas le bon outil
Le mode hébergé impose une clé et un service externe. Une équipe qui doit garder toutes les conversations sur son propre réseau, sans appel sortant, n'a pas de chemin documenté ici en dehors du mode BYODB, dont la configuration n'est pas fournie dans le matériel. Autre cas défavorable : un projet qui a besoin d'une mémoire strictement locale et hors ligne. Memori n'est pas présenté comme tel, et le quickstart suppose une clé d'API et un fournisseur de modèle distant. Le dépôt affiche par ailleurs une licence NOASSERTION, alors que le badge du README renvoie vers Apache 2.0. Les deux ne concordent pas dans les informations disponibles, et cette divergence doit être levée avant toute utilisation en production. Enfin, le rythme des versions récentes, trois publications en mai 2026, suggère une API encore mouvante : le code d'intégration mérite d'être isolé derrière une couche mince plutôt que dispersé dans l'application.
Face à une base vectorielle et à une couche de récupération maison
L'alternative la plus courante n'est pas un concurrent nommé, c'est un assemblage : une base vectorielle, un découpage de l'historique et une étape de récupération avant l'appel au modèle. La différence de conception est nette. Dans cet assemblage, vous décidez du schéma, des règles de découpage et du classement des extraits, et vous portez la maintenance de l'ensemble. Memori place cette logique derrière un enregistrement de client et une attribution, ce qui réduit le code à écrire mais déplace la responsabilité de la sélection vers le composant. Zep, LangMem et Mem0 sont cités dans le README comme points de comparaison sur LoCoMo, mais le matériel ne décrit pas leur approche interne, seulement leurs scores relatifs dans cette évaluation. Le choix se joue donc moins sur la fonctionnalité que sur ce que vous acceptez de ne plus contrôler.
Coût de maintenance et effets de licence
Le projet publie des versions fréquentes : v3.3.4, v3.3.5 et v3.3.6 entre le 20 et le 28 mai 2026. Une telle cadence signifie des mises à jour régulières du SDK, et donc une surface de régression à surveiller à chaque montée de version. Le dépôt n'est pas archivé et le dernier envoi date du 3 septembre 2026. Sur le plan juridique, le champ de licence du dépôt indique NOASSERTION tandis que le README affiche un badge Apache 2.0. Je ne peux pas trancher entre les deux à partir de ces éléments, et je ne donne pas d'avis juridique : il faut lire le fichier de licence du dépôt et, si l'écart persiste, demander une clarification à l'éditeur avant un usage commercial. Le mode hébergé ajoute une dimension contractuelle, puisque les données passent par un service tiers, ce que le mode BYODB vise justement à éviter.
Conclusion éditoriale
Memori convient à une équipe qui veut de la mémoire d'agent sans écrire sa propre couche de persistance, et qui accepte soit un service hébergé, soit une base qu'elle fournit elle-même via le mode BYODB. Il ne convient pas à qui veut une mémoire entièrement locale et sans clé d'API, ni à qui refuse de faire transiter ses conversations par un tiers. Avant d'adopter, vérifiez deux choses dans les sources : la licence exacte derrière le champ NOASSERTION du dépôt, et le contenu réel de la page BYODB, notamment la liste des bases prises en charge.
Notes de la communauté