SimpleMem : mémoire persistante pour agents LLM, du texte à la vidéo

Le problème que SimpleMem attaque

Un agent LLM oublie tout entre deux sessions. La fenêtre de contexte grandit, mais elle reste finie, et y entasser des historiques entiers coûte cher en tokens. SimpleMem se présente comme une couche qui stocke, compresse et retrouve des souvenirs à long terme, avec ce que le README appelle une compression sémantique sans perte. La cible est claire : un développeur qui écrit un agent en Python et veut lui donner une mémoire qui survit à la fin de la conversation, sans monter lui-même un pipeline d'embedding, de découpage et de recherche. Le paquet couvre aussi bien la mémoire textuelle que les images, l'audio et la vidéo depuis la version 0.2.0. Ce périmètre large est à la fois l'argument principal du projet et la source de sa complexité.

Trois projets fusionnés dans un seul import

L'historique des versions raconte une consolidation. La v0.1.0 (mars 2026) était textuelle. La v0.2.0 (avril 2026), baptisée Omni-SimpleMem, a ajouté le multimodal. La v0.3.0 (mai 2026) a réuni SimpleMem, Omni-SimpleMem et EvolveMem dans un paquet unique. Le README décrit le mécanisme : from simplemem import SimpleMem sélectionne automatiquement le backend texte ou multimodal selon la première méthode appelée, et simplemem.optimize(...) branche la boucle d'auto-évolution d'EvolveMem. C'est un choix d'ergonomie assumé, mais il déplace la question ailleurs : l'utilisateur ne choisit plus explicitement son backend, il le découvre à l'exécution. Pour un prototype, c'est agréable. Pour un service en production, cela veut dire que le comportement dépend de l'ordre des appels, ce qui mérite un test dédié avant déploiement.

Deux modes d'intégration, deux périmètres différents

Le README pose une distinction nette. La mémoire textuelle passe par MCP et fonctionne avec n'importe quel client compatible : Claude Desktop, Cursor, LM Studio, Cherry Studio sont cités, plus un serveur hébergé à l'adresse mcp.simplemem.cloud. Le multimodal complet, lui, exige une intégration Python. Autrement dit, si vous voulez que votre agent se souvienne d'une capture d'écran ou d'un extrait audio, le chemin MCP ne suffit pas selon la documentation. Cette asymétrie n'est pas un détail d'implémentation, c'est une contrainte d'architecture qui décide de votre mode de déploiement avant même que vous ayez écrit une ligne de code.

Installation et configuration

Le paquet est publié sur PyPI : pip install simplemem. Pour travailler depuis les sources, le README indique pip install -e . après clonage. La configuration des modèles passe par des variables d'environnement, dont OPENAI_BASE_URL, ce qui laisse brancher n'importe quel service compatible OpenAI. Le README cite nommément Atlas Cloud comme backend possible, avec DeepSeek, Qwen, GLM, Kimi et MiniMax derrière une seule API. Ce point a une conséquence pratique : SimpleMem ne fait pas d'inférence lui-même. Il faut un fournisseur de modèles joignable, et le coût de construction de la mémoire suit le tarif de ce fournisseur. Le dépôt mentionne aussi un support des Claude Skills et un serveur Discord, sans que le README détaille la procédure d'enregistrement du serveur MCP auprès de chaque client.

Ce que le README ne dit pas

Les chiffres annoncés sont précis : F1=0.613 sur LoCoMo, F1=0.810 sur Mem-Gallery, plus 47 pour cent et plus 51 pour cent par rapport aux meilleurs résultats antérieurs selon les notes de version. EvolveMem est crédité de plus 25,7 pour cent relatifs sur LoCoMo et plus 18,9 pour cent sur MemBench. Ces nombres viennent du projet lui-même et renvoient à un article arXiv. Rien dans le matériel fourni ne décrit le format de stockage sur disque, la stratégie d'indexation, le coût en tokens d'une session de construction de mémoire, ni le comportement quand la base grossit. Le README renvoie à une section Reproduce, ce qui suggère que la reproductibilité est prise au sérieux, mais je ne peux pas confirmer ce que contient cette section à partir des éléments disponibles. Un adoptant sérieux doit lire le code de stockage avant de s'engager.

La limite structurelle : la mémoire dépend d'un LLM

SimpleMem construit et juge ses souvenirs avec des modèles. Le README parle de mémoire construction, retrieval et judging passant par le même point d'accès compatible OpenAI. C'est le pari du projet, et c'est aussi son point faible. Un système de mémoire qui s'appuie sur un LLM pour décider quoi retenir hérite de ses erreurs : une décision de compression malheureuse peut supprimer une information que l'agent devait retrouver six mois plus tard. La boucle EvolveMem, qui fait évoluer l'infrastructure de récupération par diagnostic en boucle fermée, amplifie ce risque en modifiant le système lui-même. Pour des souvenirs factuels et stables, une base vectorielle classique avec des embeddings figés reste plus prévisible. SimpleMem est le bon outil quand les souvenirs sont conversationnels, hétérogènes et changeants, pas quand ils doivent être audités ligne par ligne.

Face à une base vectorielle classique

La différence d'approche est nette. Une base comme FAISS ou pgvector stocke des vecteurs que vous produisez vous-même et retrouve les plus proches voisins selon une métrique que vous fixez. Vous contrôlez le découpage, le modèle d'embedding et la requête. SimpleMem prend le problème à un niveau au-dessus : il décide quoi stocker, sous quelle forme compressée, et comment retrouver l'information pertinente, en s'appuyant sur des LLM à chaque étape. Le premier outil vous donne des briques, le second vous donne un pipeline complet avec ses choix déjà faits. Le coût de cette délégation, c'est la perte de contrôle sur les détails et une dépendance à un fournisseur d'inférence. L'avantage, c'est qu'un agent fonctionnel sort de la boîte là où une base vectorielle demande des semaines de plomberie.

Maintenance, licence et coût réel

Le dépôt est actif : dernier push en juillet 2026, trois versions publiées entre mars et mai 2026, licence MIT. Cette licence est permissive et n'impose pas de publier vos modifications, ce qui est confortable pour un usage interne. Elle ne dit rien, en revanche, du coût d'exploitation. Chaque souvenir construit, chaque récupération et chaque cycle d'auto-évolution consomme des appels à un modèle externe. Sur un agent à forte fréquence, cette facture peut dépasser celle du stockage lui-même. Le rythme de publication, trois versions majeures en trois mois avec une fusion de paquets, indique aussi que l'API peut bouger. Épingler une version dans votre requirements.txt n'est pas un excès de prudence ici, c'est une nécessité tant que l'interface unifiée de la v0.3.0 n'a pas quelques mois de stabilité derrière elle.

Conclusion éditoriale

SimpleMem convient aux équipes qui construisent un agent Python et veulent une couche mémoire locale, sous licence MIT, avec un point d'entrée unique et un serveur MCP déjà décrit dans le README. Il ne convient pas à qui cherche une base de données vectorielle mature avec des années de recul opérationnel, ni à qui refuse de dépendre d'un LLM externe pour construire ses souvenirs. Avant d'adopter, vérifiez trois choses concrètes : le contenu réel de simplemem.optimize et son coût en appels, le schéma de stockage produit par le backend multimodal sur vos propres fichiers audio ou vidéo, et la compatibilité de votre client MCP avec l'URL mcp.simplemem.cloud si vous optez pour l'hébergement distant.

Sources officielles

1. aiming-lab/SimpleMem on GitHub
2. Issues
3. License: MIT
4. README
5. Releases