OneMemory propose un magasin SQLite partagé pour les agents IA via MCP et REST
Un nouvel outil auto-hébergé appelé OneMemory permet aux développeurs de partager la mémoire entre plusieurs agents IA à l'aide d'un seul fichier SQLite, accessible via le Model Context Protocol ou une API REST.
Traduit automatiquement depuis l’original en anglais.
Un nouveau projet open-source nommé OneMemory fournit un magasin de mémoire léger et auto-hébergé, conçu pour être partagé entre plusieurs agents IA et interfaces. Publié fin octobre 2026, cet outil utilise un unique fichier de base de données SQLite pour persister les notes, les tâches et le contexte, rendant ces éléments accessibles simultanément depuis des assistants de codage sur bureau, des applications mobiles et des interfaces web.
Le projet s'adresse aux développeurs qui utilisent divers outils IA comme Claude Code, Cursor ou Copilot et souhaitent conserver un contexte unifié entre les sessions et les appareils, sans dépendre de services cloud externes ni de bases de données vectorielles complexes.
Ce qui s'est passé
Le dépôt, publié sous le nom calasdan-sketch/onememory, introduit un serveur basé sur Node.js qui agit comme un centre de mémoire centralisé. Il nécessite Node.js version 24 ou plus récente, en tirant parti du module intégré node:sqlite pour éviter toute dépendance à une base de données externe. Le processus d'installation est conçu pour ne pas être destructif, offrant des modes d'exécution simulée (dry-run) et des sauvegardes automatiques des fichiers de configuration avant toute modification des paramètres clients.
OneMemory se connecte aux clients IA par deux méthodes principales : le Model Context Protocol (MCP) via les entrées/sorties standard pour les applications locales sur bureau, et une API REST simple pour l'accès à distance. Cette double approche permet à un développeur de rédiger une note sur sa machine locale à l'aide d'un agent de codage local, puis de la récupérer peu après sur son téléphone ou via une interface de chat web. Le système prend en charge les jetons porteurs avec portée limitée (scoped bearer tokens), garantissant que les connexions à distance peuvent être restreintes à un accès en lecture seule si nécessaire.
L'architecture est volontairement minimale. Elle fonctionne comme un seul processus Node avec seulement deux dépendances directes au moment de l'exécution, évitant ainsi le besoin d'environnements Python, de modules natifs ou de moteurs de recherche vectorielle séparés. Toutes les données, y compris le fichier de base de données, les clés de chiffrement et la configuration, résident dans un répertoire contrôlé par l'utilisateur, situé hors du paquet installé, ce qui simplifie les sauvegardes et les mises à niveau.
Détails clés
- Stockage en fichier unique : L'intégralité de l'état est conservée dans un seul fichier SQLite, rendant les sauvegardes aussi simples que la copie d'un fichier unique pendant que le serveur tourne.
- Protocoles d'accès doubles : Prend en charge à la fois MCP pour l'intégration locale sur bureau et une API REST pour l'accès à distance via des tunnels ou des connexions réseau directes.
- Fonctionnalités de sécurité : Inclut un vérificateur de mémoire qui scanne les écritures à la recherche de secrets tels que les clés API et bloque les tentatives d'injection de prompt avant qu'elles ne soient stockées.
- Flux de modifications : Fournit un mécanisme d'attente en temps réel permettant aux clients de vérifier efficacement les changements, recevant les mises à jour en quelques secondes plutôt que d'attendre de longs intervalles de polling.
- Gestion des tâches : Prise en charge intégrée d'un tableau de tâches partagé, permettant aux agents de revendiquer, compléter et transférer des tâches entre différentes sessions et appareils.
- Portabilité des données : Les notes peuvent être exportées vers des fichiers Markdown avec front-matter YAML pour le contrôle de version via Git ou synchronisées entre machines à l'aide d'outils comme Syncthing.
Contexte
Pour les équipes gérant plusieurs assistants IA, la fragmentation du contexte est un défi courant. Un agent travaillant sur une base de code locale peut ignorer les décisions prises lors d'une session de chat web, entraînant des explications redondantes ou des conseils incohérents. Les solutions traditionnelles impliquent souvent des bases de données vectorielles complexes ou des services de mémoire cloud propriétaires, pouvant introduire de la latence, des coûts et des problèmes de confidentialité.
Le Model Context Protocol (MCP) s'est imposé comme un standard pour connecter les modèles IA aux données et outils locaux. OneMemory tire parti de ce protocole pour permettre aux applications de bureau de lire et écrire dans un magasin partagé de manière transparente. En combinant MCP avec une API REST standard, l'outil comble le fossé entre les environnements de développement locaux et les interfaces distantes ou mobiles, garantissant que tous les agents fonctionnent avec le même ensemble de faits et d'historique.
Pourquoi c'est important
Pour les équipes d'ingénierie et les développeurs individuels qui auto-hébergent leurs outils, OneMemory offre un moyen de maintenir la continuité à travers des flux de travail fragmentés. Au lieu de traiter chaque interaction IA comme un événement isolé, les utilisateurs peuvent construire une base de connaissances persistante qui évolue avec leurs projets. Cela est particulièrement précieux pour les sessions de débogage complexes ou les tâches de développement à long terme où le contexte des jours précédents est crucial.
L'accent mis sur le stockage local et les dépendances simples réduit la charge opérationnelle. Il n'est pas nécessaire de gérer un cluster PostgreSQL ni de configurer des pipelines d'indexation vectorielle intriqués. La capacité de sauvegarder l'intégralité de l'état de la mémoire en copiant un seul fichier s'aligne bien avec les pratiques existantes de reprise après sinistre pour les petites infrastructures. De plus, la détection intégrée des secrets aide à prévenir la fuite accidentelle d'identifiants dans les contextes IA, un risque croissant à mesure que les agents gagnent en accès aux systèmes locaux.
Cependant, les utilisateurs doivent être conscients des compromis. Le système ne fournit pas de snapshots historiques par modification dans sa sauvegarde standard, ce qui signifie que les restaurations ne récupéreront que la dernière version de chaque note. Les équipes nécessitant des pistes d'audit détaillées de chaque changement devront compléter cela avec une journalisation externe ou s'appuyer sur la fonctionnalité d'export Markdown pour le contrôle de version.
Ce que vous pouvez faire
- Tester l'installation en toute sécurité : Utilisez le flag
--dry-runlors de l'installation pour voir exactement quels fichiers de configuration seront modifiés avant de valider les changements. - Sécuriser l'accès à distance : Si vous exposez l'API REST à des appareils mobiles, placez un tunnel authentifié tel que Cloudflare Tunnel ou Tailscale devant le service pour appliquer des contrôles d'accès.
- Mettre en œuvre des sauvegardes régulières : Planifiez des copies automatisées du fichier de base de données SQLite et stockez la clé de chiffrement séparément de la sauvegarde pour assurer la récupérabilité des données.
- Auditer les données stockées : Revoyez périodiquement la file d'attente de quarantaine pour tout contenu signalé et utilisez les jetons à portée limitée pour restreindre l'accès en écriture depuis des appareils moins fiables.
- Intégrer avec le contrôle de version : Exportez les notes au format Markdown et commitez-les dans un dépôt Git privé pour maintenir un historique lisible par humain de vos décisions assistées par IA.
- Surveiller l'utilisation des ressources : Gardez un œil sur les reconstructions du graphe de similarité après de grandes importations, car ces opérations peuvent être intensives en calcul, bien qu'elles soient différées pour maintenir l'interface réactive.



