La mémoire d'OpenClaw : comment elle fonctionne, pourquoi elle est importante et comment vous la contrôlez

La montée des agents IA autonomes a introduit un nouveau paradigme dans les systèmes logiciels : la cognition machinique persistante. Contrairement aux chatbots traditionnels qui fonctionnent sans état, les frameworks d’agents modernes tels que OpenClaw permettent des flux de travail IA continus et sensibles au contexte. Au cœur de cette capacité se trouve le système de mémoire d’OpenClaw, qui permet à l’agent de stocker, de récupérer et de faire évoluer des connaissances d’une session à l’autre.

La mémoire persistante transforme les assistants IA de simples outils de conversation éphémères en systèmes avec état capables de se souvenir des décisions, d’apprendre des préférences et de maintenir des connaissances au niveau projet dans le temps. En pratique, cela signifie que les développeurs n’ont plus besoin d’expliquer à répétition le contexte ni de réinitialiser les flux de travail à chaque interaction avec l’agent ( If you are still wondering how to get started and configure OpenClaw, this is Tutoriel de cinq minutes pour configurer OpenClaw avec CometAPI).

Cependant, ce changement architectural introduit également des défis d’ingénierie complexes :

• Comment la mémoire est-elle stockée et récupérée ?
• Comment les développeurs contrôlent-ils le comportement de la mémoire ?
• Quelles sont les implications de sécurité d’une mémoire d’agent persistante ?
• Comment la mémoire peut-elle évoluer sans saturer les fenêtres de contexte des LLM ?

Cet article propose une exploration technique approfondie du système de mémoire d’OpenClaw, notamment son architecture, son modèle de stockage, son pipeline de récupération, ses mécanismes de contrôle et ses considérations de sécurité.

Qu’est-ce qu’OpenClaw ?

OpenClaw est un assistant IA personnel open source, axé sur l’espace de travail, que vous exécutez sur vos propres appareils. Il se connecte aux plateformes de chat (WhatsApp, Telegram, Slack, Discord, etc.), expose un plan de contrôle Gateway et — point crucial pour cet article — conserve ce qu’il « retient » sous forme de fichiers en clair dans un répertoire d’espace de travail. Cette conception rend la mémoire à la fois transparente et directement contrôlable : la mémoire n’est pas une base de données cachée à l’intérieur du modèle ; les fichiers dans l’espace de travail de l’agent sont la source de vérité.

Systèmes IA sans état vs avec état

Les systèmes de conversation IA traditionnels fonctionnent en mode sans état. Chaque interaction est traitée indépendamment, sans connaissance des sessions précédentes à moins qu’elles ne soient fournies explicitement dans le prompt.

Cela entraîne plusieurs limites :

• Le contexte est réinitialisé entre les sessions
• Les utilisateurs doivent répéter des informations
• L’apprentissage à long terme est impossible
• Les flux de travail ne peuvent pas persister

OpenClaw répond à cette limite en introduisant une mémoire persistante stockée directement dans l’espace de travail de l’agent.

Au lieu de s’appuyer uniquement sur la fenêtre de contexte du modèle de langage, OpenClaw maintient une couche de mémoire locale stockée sous forme de fichiers structurés que l’agent peut lire et mettre à jour.

Cela permet :

• La continuité du contexte d’une session à l’autre
• Le stockage de connaissances à long terme
• Des assistants IA personnalisés
• L’automatisation de flux de travail sur des horizons prolongés

Ainsi, OpenClaw fait évoluer les assistants IA de répondeurs sans état à des agents porteurs de connaissances.

Architecture de la mémoire — les quatre couches qui comptent

Le runtime d’OpenClaw organise l’information en couches. Comprendre ces couches est la clé pour contrôler ce dont l’agent se souvient et ce à quoi il peut accéder.

1) Fichiers d’amorçage de l’espace de travail — le noyau durable

Des fichiers comme SOUL.md, AGENTS.md, IDENTITY.md, TOOLS.md et MEMORY.md résident à la racine de l’espace de travail et sont considérés comme du matériel d’amorçage. Ils sont rechargés depuis le disque au démarrage de la session et constituent la mémoire la plus durable : ils survivent au compactage de jetons et sont réintroduits dans chaque assemblage de prompt depuis le disque plutôt que depuis l’historique de session éphémère. Utilisez ces fichiers pour des faits de longue durée (préférences utilisateur, contraintes légales, décisions de projet).

2) Fichiers quotidiens/de session — contexte à court et moyen terme

OpenClaw collecte les transcriptions de conversation et enregistre des fichiers de session (par exemple, des notes quotidiennes dans un dossier memory/). Ils sont utiles pour le contexte récent et la continuité de session, mais peuvent être élagués ou compactés lorsque la fenêtre de contexte de votre agent devient trop grande. De nombreux utilisateurs s’appuient sur des fichiers de notes quotidiennes comme memory/2026-03-10.md pour capturer des faits ad hoc.

3) Fenêtre de contexte du LLM — éphémère mais décisive

Le prompt de chaque tour est construit à partir d’une combinaison de fichiers d’amorçage, d’historique récent de session et de résultats de mémoire récupérés. Ce contexte in-prompt est ce que le LLM « voit » réellement lorsqu’il produit une réponse ; il est éphémère (limité par les budgets de jetons) et reconstruit à chaque tour. Si vous voulez que l’agent agisse de manière cohérente, placez les directives essentielles dans les fichiers d’amorçage — et pas uniquement dans des messages éphémères.

4) Index sémantique / plugin de mémoire — récupération rapide

Pour permettre à l’agent de retrouver des notes passées pertinentes, OpenClaw utilise un plugin de mémoire (par défaut : memory-core) qui offre une recherche sémantique sur les fichiers Markdown et des bases vectorielles externes optionnelles (sqlite-vec, LanceDB, QMD, etc.). L’index est séparé des fichiers : les fichiers sont la source de vérité ; l’index accélère la récupération. Vous pouvez changer de plugin pour modifier le comportement du backend (fournisseur d’embeddings, algorithme de récupération, persistance).

Comment fonctionne la mémoire d’OpenClaw ?

Architecture d’agent basée sur une Gateway

OpenClaw utilise une architecture centrée sur une gateway qui orchestre la communication entre plusieurs composants du système.

Composants principaux :

Au sein de cette architecture, la mémoire agit comme la couche de stockage long terme des connaissances de l’agent.

Mémoire sous forme de fichiers (la source de vérité canonique)

OpenClaw place des fichiers Markdown en clair dans l’espace de travail de l’agent au centre de son modèle de mémoire. L’agent écrit dans ces fichiers et les lit ; ils constituent le stockage persistant, éditable par l’humain. Le LLM ne « se souvient » que de ce qui a été écrit sur le disque — le contexte de session volatile est séparé. Fichiers et conventions typiques :

• MEMORY.md — éléments de mémoire durables et organisés (décisions, faits du profil utilisateur, préférences persistantes).
• memory/YYYY-MM-DD.md — journaux quotidiens en ajout uniquement utilisés comme mémoire éphémère/quotidienne.
• USER.md, SOUL.md, AGENTS.md — autres fichiers d’espace de travail qui influencent la personnalité ou le comportement de l’agent.
  Ces fichiers résident dans l’espace de travail de l’agent (par défaut ~/.openclaw/workspace) et peuvent être lus ou modifiés par vous à tout moment.

Deux voies d’accès : par fichier + par index

Parce que les fichiers en clair sont inefficaces à rechercher sémantiquement à grande échelle, OpenClaw associe la source Markdown à un index (une base vectorielle plus un index texte BM25 optionnel). L’index est utilisé par l’outil memory_search côté agent ; les lectures ciblées utilisent memory_get, qui lit directement une plage de lignes d’un fichier. L’approche d’indexation hybride — embeddings (vecteur) + BM25 (mot-clé) — fournit à la fois un rappel sémantique et une fiabilité d’exact match. Le stockage d’index typique est un fichier SQLite local étendu pour la recherche vectorielle (par ex. ~/.openclaw/agents/<agentId>/index.sqlite).

• memory_search(query, topK) — renvoie une liste classée d’extraits correspondants avec des métadonnées (chemin, lignes, score). À utiliser lorsque vous souhaitez que l’agent « cherche d’abord » une mémoire pertinente avant de répondre.
• memory_get(path, startLine, endLine) — renvoie une tranche brute d’un fichier Markdown ; à utiliser quand vous savez déjà où se trouve la mémoire.
  Ce sont des outils intégrés de l’agent ; les skills et le code personnalisé peuvent les appeler selon les besoins.

Cycle de vie : écriture, indexation, rappel, vidage, compactage

OpenClaw implémente un cycle de vie explicite de la mémoire :

1. Écriture — l’agent écrit la mémoire dans des fichiers Markdown lorsqu’un événement digne de mémoire se produit (demande explicite, décision consignée ou vidage automatique de la mémoire).
2. Indexation — un watcher de fichiers et une tâche par lots indexent de manière incrémentale les fichiers nouveaux/modifiés dans la base vectorielle + l’index BM25.
3. Rappel — l’agent invoque memory_search (sémantique) ou memory_get (ciblé) pendant une session.
4. Vidage de mémoire (pré-compactage) — lorsque le contexte de la session approche de la limite de fenêtre du modèle, OpenClaw déclenche un tour silencieux de l’agent pour écrire sur disque tout ce que l’agent estime devoir être préservé avant compactage (paramétrable).
5. Compactage — le système compresse ou résume le contexte pour garder la session active réduite ; les fichiers de mémoire constituent le repli durable.

Pipeline de segmentation et d’embeddings (détail technique)

Lors de l’indexation, les fichiers sont segmentés (heuristiques courantes : ~300–500 jetons par segment avec recouvrement), puis chaque segment est converti en embedding via un fournisseur de votre choix (OpenAI, Gemini, embeddings locaux GGUF, etc.). Les vecteurs résultants sont stockés avec des métadonnées sources (chemin du fichier, lignes début/fin, horodatage) pour la récupération. La récupération s’effectue en calculant l’embedding de la requête, en réalisant une recherche du plus proche voisin dans l’espace vectoriel, puis en combinant éventuellement avec des scores BM25 et un reranker. Cette approche hybride améliore la précision pour les requêtes factuelles tout en préservant le rappel sémantique pour le contenu paraphrasé.

Concret : comment contrôler la mémoire (commandes, fichiers, configuration)

Ci-dessous, des actions pratiques et pas à pas que les opérateurs et développeurs doivent utiliser pour inspecter, modifier et contrôler la mémoire d’OpenClaw. Les exemples supposent une installation locale standard où l’espace de travail par défaut est ~/.openclaw/workspace (vous pouvez le remplacer via agents.defaults.workspace).

Inspecter et sauvegarder les fichiers mémoire bruts

La mémoire est du Markdown. Sauvegardez l’espace de travail ou, au minimum, copiez MEMORY.md et le dossier memory/.

Exemple Shell :

# show workspace location (recommended)openclaw config get agents.defaults.workspace# copy memory files to a timestamped backupcp -r ~/.openclaw/workspace ~/.openclaw/workspace-backup-$(date +%F-%H%M)# or only memory files:cp ~/.openclaw/workspace/MEMORY.md ~/backups/opencaw-MEMORY-$(date +%F).mdcp -r ~/.openclaw/workspace/memory ~/backups/opencaw-memory-$(date +%F)/

La documentation et les guides communautaires recommandent explicitement de copier MEMORY.md + memory/ pour l’export/sauvegarde.

Modifier MEMORY.md — la méthode recommandée pour encoder des faits long terme

Placez des préférences et faits stables dans MEMORY.md. Ce fichier est lu au démarrage de la session pour une injection directe dans le contexte.

Extrait d’exemple MEMORY.md :

# MEMORY.md## User preferences- timezone: Asia/Tokyo- prefers_brief_responses: true- default_calendar: personal@gmail.com## Projects- acme-internal: deploy target Cloudflare Workers, main repo: github.com/org/acme

Après modification, aucun redémarrage n’est nécessaire pour les lectures de fichiers dans les nouvelles sessions ; toutefois, pour les index des plugins, il peut être nécessaire de réindexer (voir ci-dessous).

Écriture programmatique de mémoire (exemple Node.js)

Comme la mémoire est constituée de fichiers, de simples scripts peuvent ajouter ou créer des éléments de mémoire. Utile lorsqu’un système externe souhaite journaliser des faits dans l’espace de travail de l’agent.

// append-memory.js (Node.js)import {writeFileSync, appendFileSync} from 'fs';import {homedir} from 'os';import path from 'path';const ws = path.join(homedir(), '.openclaw', 'workspace');const mdPath = path.join(ws, 'memory', `${new Date().toISOString().slice(0,10)}.md`);// ensure folder exists and append a factappendFileSync(mdPath, `\n- ${new Date().toISOString()}: Completed deployment for project X\n`);console.log(`Wrote to ${mdPath}`);

Astuce : utilisez openclaw config get agents.defaults.workspace pour confirmer le chemin de l’espace de travail avant d’écrire.

Réindexation et contrôle des plugins

Si vous modifiez des fichiers de mémoire et que vous dépendez de la recherche sémantique, une réindexation (ou l’attente de l’indexeur automatique du plugin) est nécessaire.

• Vérifiez quel plugin est actif : openclaw config get plugins.slots.memory
• Réindexez (selon le plugin — de nombreux plugins exposent une CLI comme openclaw memory reindex ou nécessitent de redémarrer la Gateway).

Exemple d’extrait de configuration pour désactiver les plugins de mémoire (forcer un comportement uniquement fichier) :

// ~/.openclaw/openclaw.json (partial){  "plugins": {    "slots": {      "memory": "none"    }  }}

Après modification des paramètres du plugin, redémarrez la Gateway pour appliquer la configuration :

openclaw gateway restart

Les docs et références de configuration mentionnent spécifiquement plugins.slots.memory et plugins.installs comme contrôles de gestion des plugins de mémoire.

Remplacer les backends de mémoire — exemple : ajouter un plugin LanceDB

Des plugins communautaires existent pour remplacer le backend mémoire par des bases vectorielles plus scalables. Schéma d’exemple (provenant d’un plugin communautaire largement utilisé) :

# from your workspace rootcd ~/.openclaw/workspacegit clone https://github.com/win4r/memory-lancedb-pro.git plugins/memory-lancedb-procd plugins/memory-lancedb-pronpm install# then update openclaw.json to activate the 'memory-lancedb-pro' plugin# and restart gateway:openclaw gateway restart

Le README du plugin et ses auteurs recommandent des chemins absolus dans plugins.load.paths et des variables d’environnement explicites pour les clés API d’embeddings.

Recherche mémoire en CLI et dépannage

OpenClaw expose des utilitaires CLI tels que openclaw memory pour rechercher ou gérer l’index sémantique. Surveillez les problèmes spécifiques aux plugins (par exemple, les utilisateurs du backend QMD ont signalé des décalages index/recherche qui ont nécessité une reconfiguration). En cas de résultats manquants, réindexez et consultez les journaux du plugin.

Mémoire sous forme de fichiers (la source de vérité canonique)

OpenClaw place des fichiers Markdown en clair dans l’espace de travail de l’agent au centre de son modèle de mémoire. L’agent écrit dans ces fichiers et les lit ; ils constituent le stockage persistant, éditable par l’humain. Le LLM ne « se souvient » que de ce qui a été écrit sur le disque — le contexte de session volatile est séparé. Fichiers et conventions typiques :

• MEMORY.md — éléments de mémoire durables et organisés (décisions, faits du profil utilisateur, préférences persistantes).
• memory/YYYY-MM-DD.md — journaux quotidiens en ajout uniquement utilisés comme mémoire éphémère/quotidienne.
• USER.md, SOUL.md, AGENTS.md — autres fichiers d’espace de travail qui influencent la personnalité ou le comportement de l’agent.
  Ces fichiers résident dans l’espace de travail de l’agent (par défaut ~/.openclaw/workspace) et peuvent être lus ou modifiés par vous à tout moment.

Conclusion

Le système de mémoire d’OpenClaw représente un changement fondamental dans l’architecture de l’IA.

Au lieu de conversations éphémères, la plateforme introduit des couches de mémoire persistantes et contrôlées par les développeurs qui permettent aux agents IA d’accumuler des connaissances au fil du temps.

Sa conception met l’accent sur :

• la transparence via un stockage basé sur des fichiers
• la scalabilité via une récupération basée sur des embeddings
• le contrôle développeur via la configuration
• l’extensibilité via des plugins

Cependant, la mémoire persistante introduit également de nouveaux défis d’ingénierie et de sécurité que les développeurs doivent gérer avec soin.

À mesure que les agents autonomes deviennent plus puissants et largement déployés, des systèmes de mémoire comme celui d’OpenClaw deviendront probablement un composant central de la prochaine génération de systèmes logiciels intelligents.

CometAPI s’intègre désormais avec openclaw. Si vous recherchez des API prenant en charge Claude, Gemini et la série GPT-5, CometAPI est le meilleur choix pour utiliser openclaw, et le prix de son API est continuellement remisé.). OpenClaw a récemment mis à jour sa compatibilité avec GPT-5.4 et optimisé son flux de travail. Vous pouvez désormais aussi configurer OpenClaw via le GPT-5.4 de CometAPI.

Prêt à démarrer ?→ Inscrivez-vous à openclaw dès aujourd’hui !

Si vous souhaitez plus d’astuces, de guides et d’actualités sur l’IA, suivez-nous sur VK, X et Discord !