Système de mémoire locale OpenClaw : stocker la mémoire IA en Markdown

La semaine dernière, l’architecture que l’IA avait analysée avait déjà disparu de l’historique du chat. Les assistants IA résolvent des problèmes, mais leur mémoire est courte : à la fin d’une conversation, presque tout est oublié. Et surtout — où vont ces données ? Sur un serveur cloud ? Qui peut les voir ?

OpenClaw stocke toute la mémoire de l’IA dans des fichiers Markdown sur le disque local. Cela règle deux problèmes : l’IA garde une mémoire à long terme, et les données ne partent pas automatiquement vers le cloud.

Cet article décortique le système de mémoire d’OpenClaw : architecture à deux niveaux (journaux temporaires + connaissances persistantes), recherche hybride (BM25 + sémantique vectorielle) et mécanismes de confidentialité locale. Données sous votre contrôle, édition dans VSCode, versionnement Git.

Guide « élevage de homard » à petit budget : ArkClaw démocratise l’agent IA

OpenClaw (« homard ») est puissant mais la configuration rebute ? ArkClaw de ByteDance Volcano Engine abaisse fortement la barrière : sans serveur ni configuration de tokens, un « assistant IA » en ligne 24 h/24, navigateur, scripts et calendrier.

Le prix compte : environ 9,9 ¥/mois ; avec le code d’invitation ZLKUK54M (inscription ici) environ 8,9 ¥. Développeurs : le plan Coding Plan Pro peut être inclus.

Pourquoi Markdown : la philosophie file-first

La première fois qu’OpenClaw m’a montré des fichiers Markdown pour la mémoire IA, j’étais sceptique. Markdown, ce n’est pas pour la doc ?

En y réfléchissant, le choix est malin.

Si tout est dans PostgreSQL, pour voir ce que l’IA retient, il faut un client SQL… En Markdown, VSCode suffit. Modifier ? Sauvegarder. Sauvegarder ? Copier le dossier. Revenir à la semaine dernière ? Un git checkout.

Les auteurs appellent cela file-first : le Markdown est la source de vérité unique ; la base sert surtout à l’index et à accélérer la recherche.

C’est proche du modèle NOTES.md recommandé par Anthropic pour Claude : un fichier de décisions et de contexte. OpenClaw pousse la logique plus loin — tout le système de mémoire repose sur Markdown.

Comparaison rapide :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

• Redis / mémoire : rapide, volatile sans persistance dédiée
• PostgreSQL / MySQL : puissant, lourd, données peu lisibles
• Base vectorielle cloud (ex. Pinecone) : adaptée à l’IA, souvent hors machine

Avantages Markdown :

1. Lisible : vous voyez ce que l’IA retient
2. Contrôlable : backup, suppression, chiffrement à votre guise
3. Compatible Git : historique des changements, collaboration possible
4. Sans dépendance lourde : pas de service base de données obligatoire

Limite principale : comment retrouver vite le bon passage dans des centaines de fichiers ? Nous y venons.

Architecture à deux niveaux : temporaire et persistant

Le design ressemble à la mémoire humaine : journaux quotidiens (Daily Logs) et connaissances curatées (Curated Knowledge).

Les journaux sont la mémoire de court terme — activité du jour, conversations récentes — dans memory/YYYY-MM-DD.md. Le 5 février 2026, OpenClaw crée memory/2026-02-05.md et y ajoute en append-only.

Point clé : au démarrage, OpenClaw charge le jour courant et la veille. Deux jours pour la continuité récente ; au-delà, pas de chargement automatique (sinon la fenêtre de contexte explose).

Les connaissances persistantes vivent dans MEMORY/ : architecture projet, décisions, snippets utiles — saisis ou extraits manuellement ou automatiquement.

Exemple de structure :

memory/
├── 2026-02-01.md          # ancien journal, non chargé auto
├── 2026-02-04.md          # hier, chargé auto
├── 2026-02-05.md          # aujourd'hui, chargé auto
└── MEMORY/
    ├── project-architecture.md
    ├── deployment-notes.md
    └── troubleshooting-guide.md

Au lancement, les deux derniers journaux entrent dans le contexte ; pour un fait d’il y a un mois, il faut la recherche dans MEMORY/.

Archivage automatique : trop de journaux → flush, compression ou archivage ; l’important migre vers le stockage durable.

Cela rappelle la courbe d’oubli : tout n’a pas besoin d’être gardé ; l’essentiel se fixe dans la mémoire longue.

Recherche efficace : SQLite et approche hybride

Des centaines de fichiers Markdown : grep seul ne suffit pas. Vous cherchez « déployer une app conteneurisée » alors que la note dit « construction d’image Docker et déploiement K8s » — pas de correspondance lexicale.

Recherche hybride : BM25 (mots-clés) + similarité vectorielle (sémantique).

Mécanisme :

1. Index : à chaque écriture, découpage en chunks puis :

   • FTS5 SQLite pour le texte intégral (BM25)
   • embedding via API, vecteurs stockés dans SQLite

2. Requête : pour « déployer conteneurs » :

   • BM25 sur « déploiement », « conteneur »
   • recherche vectorielle sur le sens
   • fusion des scores, top-K

Résultat : rapidité des mots-clés + pertinence sémantique.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Modèles d’embedding :

• Local : hors ligne, données locales, qualité parfois inférieure
• OpenAI Embedding API : efficace, cloud, clé requise
• Gemini Embedding API : quota gratuit souvent plus large

Choix selon confidentialité ou qualité. En pratique, une note « proxy inverse Nginx » remonte quand on demande « équilibrage de charge », sans ce mot dans la note — effet de la sémantique.

Confidentialité et sécurité : priorité au local

Beaucoup évitent les infos sensibles avec les assistants IA : architecture interne, clients, vie privée — on ne sait pas si les échanges partent au cloud ou servent à l’entraînement.

OpenClaw local-first : fichiers sur le disque, pas d’upload automatique. Cloud ? Dropbox ou Git à vous. Chiffrement ? VeraCrypt, FileVault. Vous décidez.

Aligné avec le mouvement Local-first Software : souveraineté des données chez l’utilisateur.

Le local n’est pas invulnérable :

1. Clés API dans un fichier puis dépôt Git public
2. Permissions : accès lecture/écriture à memory/ mal configuré
3. Skills malveillants : extensions pouvant exfiltrer
4. Instances exposées : centaines d’OpenClaw sur Internet sans auth (Cisco, Vectra AI)

Bonnes pratiques :

• Sandbox Docker : limiter les chemins accessibles
• Moindre privilège : pas root
• Chiffrement des fichiers sensibles
• Auth obligatoire si exposition (Nginx + basic auth ou OAuth)
• Audit : contenu de memory/, liste des skills

DigitalOcean propose un guide de durcissement détaillé.

Le stockage local offre la possibilité de confidentialité ; la sécurité réelle dépend de votre configuration — comme une serrure qu’il faut fermer.

Guide pratique : gérer et optimiser les données mémoire

Organisation des fichiers

Structure par défaut :

memory/
├── 2026-02-05.md
├── MEMORY/
│   ├── projects/
│   │   ├── project-a.md
│   │   └── project-b.md
│   ├── reference/
│   └── troubleshooting/
└── .memory_index.db

Personnalisation possible, par exemple :

MEMORY/
├── work/
│   ├── backend-api-design.md
│   └── database-migration-notes.md
├── learning/
│   ├── rust-ownership-model.md
│   └── kubernetes-networking.md
└── personal/
    └── recipe-collection.md

Maintenance

1. Nettoyage mensuel : vieux journaux ; l’important va dans MEMORY/
2. Édition manuelle : corriger une erreur directement dans le Markdown
3. Git : memory/ versionné = historique de la mémoire
4. Sauvegarde : cloud ou disque externe

Performance

• Fichier Markdown < 1 Mo ; sinon découper
• Fenêtre de contexte : par défaut 2 jours ; réduire à 1 si trop lent
• Reconstruire l’index : supprimer .memory_index.db et redémarrer
• Archivage auto après ~30 jours de journaux

Astuce : un INDEX.md dans MEMORY/ avec résumés et liens — filet de secours si la recherche échoue.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Gérer la mémoire, c’est un peu ranger un carnet : discipline et habitudes. Une fois le flux en place, le contrôle local rassure plus qu’un cloud opaque.

Synthèse

Où stocker la mémoire d’un assistant IA ?

OpenClaw répond : Markdown local. « Rétro », mais cela adresse confidentialité et maîtrise des données.

Deux niveaux (journaux + persistant), recherche hybride (BM25 + vecteurs), philosophie file-first : éditeur, Git, gestionnaire de fichiers — outils familiers.

Ce n’est pas universel : multi-appareils sans effort, équipe sans Git, zéro ops → le cloud peut convenir mieux.

Pour moi, l’enseignement est clair : la mémoire IA peut être transparente, contrôlable et à vous.

Si vous développez un agent, essayez depuis un simple NOTES.md. L’enjeu n’est pas la sophistication technique, mais qui possède les données.

Documentation et code sources officiels ; communauté active.

Et surtout : configurez la sécurité — ne laissez pas votre mémoire devenir celle d’un autre.