OpenClaw est un plan de contrôle qui connecte des grands modèles de langage à un système d’exploitation et à des applications de messagerie, fonctionnant en continu comme un daemon en arrière-plan. L’architecture — Gateway, HEARTBEAT.md, planificateur cron, configuration en texte brut — détermine ce que l’outil peut faire et comment il se comporte.
Le Gateway
Le cœur d’OpenClaw est le Gateway — un daemon Node.js unique qui s’exécute comme un service en arrière-plan sur votre machine. Tout le reste de l’écosystème OpenClaw est un client du Gateway ou une extension de celui-ci.
Le rôle du Gateway est de s’intercaler entre vos LLM et vos canaux de communication. Il maintient des connexions persistantes avec les applications de messagerie que vous configurez (WhatsApp, Slack, Telegram, Discord, Signal, Microsoft Teams, et d’autres), reçoit les messages, les achemine vers le LLM approprié avec le bon contexte, exécute les appels d’outils ou commandes shell que le LLM demande, et renvoie la réponse vers le canal d’où provenait le message.
Vous interagissez avec votre agent OpenClaw comme vous enverriez un message à un collègue : ouvrez WhatsApp, envoyez un message, recevez une réponse. Le Gateway est l’infrastructure invisible qui rend cela possible.
Le daemon fonctionne de façon persistante — il ne démarre pas quand vous ouvrez une conversation et ne s’arrête pas quand vous la fermez. Il est toujours là, ce qui rend possible la surveillance planifiée et les comportements proactifs. Considérez-le comme un microservice que vous faites tourner sur votre propre matériel plutôt que dans le cloud.
Agnosticisme de modèle (BYOK)
OpenClaw est construit autour d’un modèle bring-your-own-keys. Vous le connectez aux LLM que vous souhaitez utiliser :
- Claude (Anthropic) — excellent pour le code et l’analyse
- GPT-4o / o3 (OpenAI) — capacités étendues
- Gemini (Google) — utile avec un niveau gratuit généreux
- DeepSeek — économique pour les tâches à fort volume
- Llama via Ollama — inférence locale, sans coûts d’API, sans données quittant votre machine
Vous n’êtes enfermé dans aucun fournisseur unique. Cela importe en pratique pour deux raisons. Premièrement, les différents modèles ont des profils de coût différents — vous pouvez router les tâches de surveillance peu complexes vers un modèle moins coûteux et les analyses complexes vers un modèle plus performant. Deuxièmement, les capacités des modèles évoluent encore rapidement ; le BYOK signifie que vous adoptez de nouveaux modèles dès qu’ils apparaissent sans attendre qu’OpenClaw mette à jour une intégration interne.
L’agnosticisme de modèle signifie aussi que vos données ne transitent jamais par les serveurs d’OpenClaw. L’appel API part de votre machine directement vers le fournisseur du LLM. OpenClaw route la conversation ; il n’en voit pas le contenu.
Le système HEARTBEAT.md
La fonctionnalité architecturalement la plus distinctive d’OpenClaw est le fichier HEARTBEAT.md et la boucle proactive qu’il permet.
Toutes les 30 minutes (configurable), le Gateway lit un fichier à ~/.openclaw/HEARTBEAT.md. Ce fichier est une checklist que vous rédigez vous-même — une liste de conditions que l’agent doit évaluer et d’actions à prendre si ces conditions sont remplies.
Un exemple simple :
# Checklist Heartbeat
- [ ] Vérifier s'il y a des messages Slack urgents de clients- [ ] Examiner si des tests dbt planifiés ont échoué dans la dernière heure- [ ] Signaler si des coûts d'API ont dépassé les seuils journaliersL’agent lit cette liste, évalue chaque condition en utilisant les outils et informations auxquels il a accès, et agit s’il trouve quelque chose qui justifie une action. Si un client a envoyé un message urgent, il le signale. Si un test dbt a échoué, il le rapporte. Si tout va bien, il ne fait rien.
C’est la couche proactive — ce qui distingue OpenClaw des outils qui ne répondent que lorsque vous posez une question. L’agent n’attend pas votre prompt. Il vérifie sa checklist, comme un collègue qui sait ce qu’il faut surveiller et vous prévient quand quelque chose ne va pas.
Pour les data engineers, le HEARTBEAT.md peut être ajusté aux éléments qui comptent : fraîcheur des sources, anomalies de coûts, statut des pipelines, échecs de tests. Le résultat est une boucle de surveillance qui s’exécute sans que vous le demandiez, avec des instructions en langage naturel plutôt que des scripts personnalisés.
Tout en texte brut
La configuration, l’historique des conversations et la mémoire d’OpenClaw sont stockés sous forme de fichiers Markdown et YAML locaux. Pas de base de données propriétaire, pas de formats binaires, pas de synchronisation cloud requise.
Les répertoires principaux :
~/.openclaw/├── config/ # Configuration YAML pour les canaux, modèles, clés API├── memory/ # Fichiers Markdown pour la mémoire persistante de l'agent├── cron/│ └── jobs.json # Définitions des tâches cron persistées├── skills/ # Répertoires de skills avec des fichiers SKILL.md└── HEARTBEAT.md # Checklist de surveillance proactiveChaque fichier dans cette structure est lisible et modifiable par un humain. Vous pouvez ouvrir jobs.json et modifier une expression cron directement. Vous pouvez lire les fichiers de mémoire de l’agent pour voir ce qu’il a stocké sur vos projets. Vous pouvez sauvegarder l’intégralité du répertoire avec Git et le restaurer sur une autre machine.
La configuration en texte suit le même pattern que dbt_project.yml, profiles.yml, et CLAUDE.md : le texte est auditable et versionnable.
L’avantage pratique s’étend au débogage. Quand une tâche cron OpenClaw se comporte de manière inattendue, vous n’avez pas besoin de décoder un fichier d’état binaire ou d’interroger une base de données. Vous faites cat du fichier Markdown concerné et vous lisez ce que l’agent a en mémoire. Le workflow de débogage est le même que celui que vous appliquez à n’importe quel outil basé sur du texte.
L’implication en matière de sécurité est un couteau à double tranchant. Les fichiers texte brut sont faciles à inspecter et auditer — mais les clés API stockées en YAML sont aussi faciles à exfiltrer si la machine est compromise. C’est le même profil de risque que toute approche credentials-dans-fichier-config ; la différence est que les attaquants ciblant spécifiquement les installations OpenClaw savent maintenant exactement quels chemins de fichiers chercher. Voir Risques de sécurité OpenClaw — Ce qui est documenté pour le paysage de menaces spécifique.
L’accès shell comme capacité de premier plan
Le Gateway peut exécuter des commandes shell. Ce n’est pas un add-on ; c’est fondamental à la façon dont OpenClaw fait quoi que ce soit sur votre système.
Quand vous demandez à OpenClaw de “lancer dbt test et me dire ce qui a échoué”, l’agent :
- Identifie qu’il doit exécuter une commande shell
- Appelle
dbt test --target prodvia l’outil d’exécution shell du Gateway - Capture stdout et stderr
- Analyse la sortie avec ses capacités LLM
- Renvoie un résumé formaté vers votre canal de messagerie
L’agent peut exécuter n’importe quelle commande CLI : dbt test, dbt run, bq query, snowsql, git status, psql. C’est ce qui rend possible la surveillance des pipelines et les requêtes de warehouse sans intégrations API personnalisées.
L’automatisation de navigateur est également disponible via un contrôle complet du Chrome DevTools Protocol — naviguer dans des pages, remplir des formulaires, prendre des captures d’écran, gérer les cookies. C’est pertinent pour les analytics engineers qui gèrent des dashboards clients exposant des données uniquement via une interface web sans API.
La couche cron
Au-dessus du Gateway se superpose un planificateur cron intégré. Expressions cron standard à cinq champs avec support des fuseaux horaires, tâches persistées entre les redémarrages, modes de session configurables (isolé ou principal), et ciblage de livraison vers des canaux de messagerie spécifiques.
Ceci est couvert en profondeur dans Mécanique du planificateur cron OpenClaw. Le point architectural est que le planificateur cron est natif au Gateway — pas un outil externe appelant le Gateway. Quand un cron se déclenche, il crée une session d’agent directement à l’intérieur du processus Gateway, ce qui signifie qu’il a un accès complet à la mémoire de l’agent, aux fichiers de skills, et aux capacités d’outils sans configuration supplémentaire.
Ce que cela signifie pour la propriété “toujours actif”
La combinaison Gateway-comme-daemon, boucle proactive HEARTBEAT.md, et planificateur cron crée la propriété toujours-actif qui distingue OpenClaw des outils basés sur des sessions comme Claude Code.
Claude Code est puissant mais transitoire. Vous l’ouvrez, travaillez sur quelque chose, le fermez. La session se termine. Pour la continuité entre les sessions, vous vous appuyez sur CLAUDE.md pour documenter l’état du projet que Claude peut lire au début de la session suivante.
OpenClaw ne se ferme jamais. Le Gateway fonctionne indéfiniment. La mémoire persiste entre les sessions automatiquement — dans des fichiers Markdown que l’agent peut lire et écrire. L’agent peut développer un modèle de vos projets, des préférences de vos clients, et de vos patterns d’échecs récurrents sur des jours et des semaines, pas seulement au sein d’une seule conversation.
Les résumés de tests planifiés dans Slack, la reconnaissance de patterns d’échecs récurrents, et les alertes proactives de fraîcheur des sources découlent tous de l’architecture daemon et de la mémoire persistante.
La contrepartie est la surface d’attaque que cela crée. Un processus toujours actif avec accès shell, accès aux credentials, et connexions à plusieurs canaux de messagerie est une frontière de sécurité significative à gérer. Voir Risques de sécurité OpenClaw — Ce qui est documenté et Posture de sécurité pour les agents IA pour ce que cela signifie en pratique.