La différence la plus distinctive d’OpenClaw par rapport aux outils d’IA à session unique n’est pas le système de planification ni l’interface via messagerie — c’est la mémoire. OpenClaw peut persister le contexte sur plusieurs jours et semaines automatiquement, sans action explicite de l’utilisateur.
Comment les outils à session unique gèrent la continuité
Claude Code se réinitialise entre les sessions. Chaque fois qu’une nouvelle session est ouverte, on repart de zéro : le modèle n’a aucun souvenir de ce qui a été traité la veille, des patterns détectés la semaine précédente, ni des questions posées auparavant. C’est une propriété fondamentale de l’inférence LLM sans état, pas une limitation propre à Claude Code.
La solution de contournement que la plupart des praticiens de la donnée utilisent est CLAUDE.md — un fichier de configuration au niveau du projet que l’on maintient manuellement. On y consigne les conventions du projet, le contexte important, les décisions prises. L’agent lit CLAUDE.md au début de chaque session et a accès à tout ce qui y est encodé.
Cela fonctionne bien pour la connaissance du projet : conventions de nommage, architecture des couches, stratégie de tests. Cela fonctionne moins bien pour l’historique opérationnel : quels tests ont échoué le mois dernier, quel est le problème récurrent de qualité de données sur le pipeline des commandes, quel entrepôt client a tendance à avoir des délais de fraîcheur le lundi matin. Ce type de mémoire opérationnelle exige que quelqu’un (ou quelque chose) mette à jour CLAUDE.md à chaque événement notable. En pratique, cela ne se produit pas de manière cohérente.
Comment OpenClaw gère la mémoire
OpenClaw stocke la mémoire dans des fichiers Markdown dans ~/.openclaw/memory/. L’agent peut lire et écrire ces fichiers de manière autonome lors de n’importe quelle conversation ou exécution cron. Il n’est pas nécessaire de lui dire de mémoriser quelque chose ; il peut décider de stocker les observations qui semblent mériter d’être conservées.
Un exemple simple : on demande à l’agent de vérifier un échec de test dbt. Il enquête, trouve la cause racine (une table source qui se charge tard le vendredi), et résout le problème. Sans aucune instruction, il peut écrire dans un fichier de mémoire :
# Notes de pipeline
## Client A - Pipeline des commandes- La table source `raw.shopify_orders` a un chargement tardif connu le vendredi- Les échecs de tests du vendredi matin sont généralement liés au timing, pas à la qualité des données- Vérifier la fraîcheur de la source avant d'escalader les échecs du vendredi matin- Documenté : 2026-03-14, 2026-03-21 (les deux résolus avant 9h)La prochaine fois qu’un échec de test dbt apparaît le vendredi matin, l’agent lit cette mémoire et dispose immédiatement du contexte qui nécessiterait autrement une explication : « ah, c’est encore le problème de fraîcheur du vendredi. » Au lieu de traiter cela comme un nouvel incident, il le reconnaît comme un pattern.
Ce que cela permet pour le monitoring
La mémoire persistante change ce qui est possible avec la surveillance autonome de plusieurs façons concrètes.
Reconnaissance de patterns dans le temps. Un agent qui voit le même type d’échec en semaine 1 et en semaine 3 peut indiquer qu’il est récurrent, pas nouveau. « C’est la troisième fois que l’export GA4 manque des enregistrements le premier du mois » est une information qualitativement différente de « l’export GA4 a manqué des enregistrements aujourd’hui. » La reconnaissance de patterns dans le temps nécessite une mémoire dans le temps.
Contexte opérationnel accumulé. Au fil de semaines de monitoring, l’agent construit un modèle de vos pipelines qui reflète comment ils se comportent réellement — pas seulement comment ils sont censés se comporter. Il sait quels tests échouent fréquemment et peuvent être déprioritisés, quels échecs sont urgents, et quelles sources sont peu fiables. C’est la connaissance opérationnelle qu’un analyste expérimenté accumule sur des mois de projet, et qui est actuellement perdue à chaque changement d’outil ou redémarrage de session.
Réduction du besoin de ré-expliquer. Un outil à session unique nécessite d’expliquer « le pipeline des commandes a une particularité où… » à chaque conversation à son sujet. Un agent OpenClaw avec un fichier de mémoire bien entretenu le sait déjà. Pour les consultants gérant plusieurs projets clients, la réduction des frais d’explication répétitive entre projets représente des économies de temps significatives.
Les fichiers de mémoire sont du texte brut
Le même principe de conception « plain text en premier » qui gouverne la configuration d’OpenClaw s’applique à la mémoire. Les fichiers de mémoire sont en Markdown. On peut les lire, les modifier, les compléter, supprimer des entrées incorrectes et les versionner avec Git.
Cela est significatif pour deux raisons. Premièrement, on peut auditer ce que l’agent a stocké — si l’on se demande si l’agent dispose du contexte correct sur son pipeline, on consulte le fichier de mémoire et on le lit soi-même. Il n’y a pas de système de récupération opaque ; la mémoire est exactement le texte dans le fichier.
Deuxièmement, on peut amorcer la mémoire. Si l’on configure OpenClaw pour un nouveau projet client et que l’on connaît déjà les particularités du pipeline, on les écrit dans un fichier de mémoire avant que l’agent ait eu l’occasion de les découvrir par observation. L’agent aura ce contexte dès le premier jour au lieu de l’accumuler sur des mois.
Un bon fichier de mémoire de départ pour un nouveau setup de monitoring pourrait inclure :
# [Nom du client] - Contexte de monitoring
## Planning du pipeline- Les syncs Fivetran s'exécutent la nuit à 2h EST- Le run de production dbt se termine avant 4h EST en semaine, 5h le week-end
## Patterns connus- [Notez les problèmes de timing récurrents, les particularités connues de qualité des données]- [Notez quels tests sont à fort signal vs. souvent faux positifs]
## Escalade- Contacter le client si des échecs de tests sur la couche mart persistent au-delà de 8h- Pas besoin d'escalader pour les avertissements de modèles intermédiaires
## Emplacement des credentials- Voir config/client-name-profile.yml (accès entrepôt en lecture seule)L’agent lit cela comme contexte opérationnel à chaque exécution, pas seulement lors de la configuration initiale.
Les limites de la mémoire autonome
L’accumulation automatique de mémoire a des modes d’échec qu’il convient de comprendre.
L’agent stocke des interprétations incorrectes. Si l’agent identifie mal la cause d’un échec et stocke cette interprétation incorrecte, il appliquera le mauvais contexte aux futurs échecs. Étant donné que l’on ne révise pas par défaut ce que l’agent écrit en mémoire, des croyances incorrectes peuvent persister jusqu’à ce que l’on remarque quelque chose d’anormal dans la sortie de monitoring et qu’on le trace jusqu’à une mauvaise entrée de mémoire.
La mémoire grossit sans nettoyage. Les fichiers de mémoire s’accumulent avec le temps. Après plusieurs mois de monitoring, on peut avoir un grand fichier de mémoire avec du contexte de projets terminés, de pipelines modifiés, et de patterns qui ne s’appliquent plus. Sans révision et nettoyage périodiques, une mémoire obsolète peut activement induire l’agent en erreur.
Contexte différent par client, pas partagé. Si l’on gère plusieurs clients, chacun devrait avoir des fichiers de mémoire séparés. Le contexte du pipeline du client A ne devrait pas contaminer le raisonnement de l’agent sur le pipeline du client B. La structure organisationnelle des fichiers de mémoire est importante.
La recommandation pratique est de traiter les fichiers de mémoire comme de la documentation vivante que l’on révise mensuellement — de la même façon que l’on réviserait et mettrait à jour un fichier CLAUDE.md. L’agent les maintient de manière autonome, mais on reste l’éditeur qui les maintient précis.
Comparaison avec CLAUDE.md
Ce qui suit décrit ce que la mémoire persistante d’OpenClaw et CLAUDE.md (utilisé avec Claude Code) ont en commun et en quoi ils diffèrent.
Les deux sont des fichiers Markdown que l’agent lit pour le contexte. Les deux encodent des connaissances sur les projets, les conventions et les patterns. Les deux sont lisibles et éditables par l’humain.
La différence clé est qui les maintient. CLAUDE.md est un fichier que l’on écrit et met à jour manuellement. Les fichiers de mémoire d’OpenClaw peuvent être mis à jour par l’agent de manière autonome pendant qu’il opère. Pour les conventions de projet et les décisions d’architecture, la maintenance manuelle (CLAUDE.md) est appropriée — c’est l’humain qui prend ces décisions. Pour les observations opérationnelles (ce test échoue le vendredi, cette source se charge tard le premier du mois), l’accumulation automatisée est plus pratique car c’est l’agent qui observe les patterns.
L’autre différence est la portée de persistance. CLAUDE.md est au niveau du projet — il existe dans le dépôt du projet dbt et est spécifique à Claude Code. La mémoire d’OpenClaw est au niveau de l’agent — elle vit dans ~/.openclaw/memory/ et persiste à travers toutes les conversations et exécutions cron, indépendamment du projet discuté.
Pour un consultant indépendant, les deux valent la peine d’être maintenus. CLAUDE.md capture la connaissance du projet qui guide la façon dont Claude Code construit les modèles. La mémoire d’OpenClaw capture la connaissance opérationnelle qui guide la façon dont l’agent de monitoring interprète ce qu’il trouve.