La mémoire n'est pas une base de données : comment OpenClaw se souvient de tout avec 4 fichiers texte

Par défaut, les agents IA sont amnésiques. Chaque conversation repart de zéro. C'est le problème du "Stateless".

Pour résoudre ça, la plupart des ingénieurs sortent l'artillerie lourde : bases de données vectorielles (Pinecone, Weaviate), pipelines RAG complexes, embeddings coûteux.

Ils ont tort.

OpenClaw a résolu le problème de la mémoire infinie sans une seule ligne de SQL et sans vecteur. Peter Steinberger a utilisé la technologie la plus ancienne et la plus ennuyeuse du monde : des fichiers Markdown.

Si vous pensez avoir besoin d'une infrastructure complexe pour donner une mémoire à long terme à une IA, vous n'avez pas regardé sous le capot. Voici comment OpenClaw transforme de simples fichiers texte en cerveau fonctionnel, et comment vous pouvez copier cette architecture dès ce soir.

Source : Google Research — "Context Engineering: Sessions and Memory" (novembre 2025) — Le livre blanc qui a théorisé cette approche en définissant les trois types de mémoire d'agent : épisodique, sémantique et procédurale.

I. Le mensonge de la "fenêtre de contexte"

Commençons par casser un mythe. Votre conversation avec ChatGPT n'est pas de la "mémoire". C'est un contexte glissant.

Imaginez que vous écrivez un roman, mais vous ne pouvez voir que les 50 dernières pages. Chaque fois que vous écrivez une nouvelle page, la page 1 disparaît dans le néant. C'est la Fenêtre de Contexte.

Quand la fenêtre est pleine, le couperet tombe. C'est la Compaction. Le système doit prendre votre historique, le découper, et ne garder que l'essentiel pour continuer.

Il existe trois façons de déclencher ce couperet :

• Par comptage — "Vous avez dépassé 8 000 tokens. Je coupe." La méthode brute.
• Par temps — "Vous n'avez rien dit depuis une heure. J'archive."
• Sémantique — "On a fini de parler de ce sujet. Je nettoie." La méthode intelligente, mais difficile à coder.

Le problème ? Si vous coupez, vous perdez les détails.

OpenClaw ne coupe pas. Il déplace.

II. L'architecture : le bureau et l'armoire

Pour comprendre la mémoire d'OpenClaw, oubliez l'informatique. Pensez à un bureau physique.

• La Session (Le Bureau) — C'est le bazar en cours. Des notes partout, des post-it, le projet en cours. C'est votre RAM. C'est éphémère.
• La Mémoire Long-Terme (L'Armoire) — C'est là que vous rangez les choses une fois le projet terminé. C'est organisé, c'est propre.

Le génie d'OpenClaw n'est pas dans l'armoire elle-même (ce ne sont que des fichiers), mais dans les mécanismes de transfert qui transportent l'information du bureau vers l'armoire au bon moment.

III. Les 3 fichiers qui composent le cerveau

Pas de base de données. Juste trois fichiers Markdown que l'agent lit et écrit comme un humain tenant un journal.

1. memory.md — L'identité

C'est la carte d'identité de l'utilisateur. Elle stocke les faits stables et les préférences.

Ce fichier est injecté dans chaque prompt. Il doit être court — moins de 200 lignes recommandées. C'est ce que Google appelle la "Mémoire Sémantique".

2. daily_logs.md — Le journal de bord

C'est la mémoire à court terme, organisée par jour.

Contenu : "Aujourd'hui on a débugué l'API Auth. On a corrigé le bug #402."

C'est un fichier en append-only. On ne supprime jamais, on ajoute à la fin. L'agent lit les logs d'aujourd'hui et d'hier pour savoir ce qui s'est passé récemment.

3. session_snapshots/ — Le snapshot

C'est la mémoire brute. Les 15 derniers messages significatifs d'une session, sauvegardés avant un reset.

OpenClaw ne sauvegarde pas le bruit. Les appels d'outils, les erreurs système et les commandes /slash sont filtrés. Seule la conversation "User ↔ Assistant" est conservée.

IV. Les 4 mécanismes de "flush"

Avoir des fichiers ne sert à rien si personne n'y écrit. OpenClaw utilise 4 déclencheurs précis pour sauvegarder la mémoire avant qu'elle ne soit perdue par la compaction.

Conclusion : la complexité est un piège

OpenClaw prouve qu'on n'a pas besoin de vecteurs pour avoir de la mémoire.

• Claude Code l'a copié — ils utilisent aussi des fichiers Markdown.
• Google l'a théorisé — Livre blanc "Context Engineering", nov. 2025.
• Peter Steinberger l'a codé.

L'architecture se résume à trois questions :

1. Quoi ? — Qu'est-ce qui mérite d'être noté ?
2. Où ? — Dans memory.md pour les faits, ou daily_logs pour les événements ?
3. Quand ? — Au démarrage, avant la coupure, ou à la demande ?