Accueil › OpenClaw › Automatisation

OpenClaw Automatisation : le guide complet des cron jobs, heartbeat, hooks et webhooks

L’automatisation dans OpenClaw repose sur trois piliers : le heartbeat (surveillance périodique), les cron jobs (tâches planifiées) et les hooks (réactions événementielles). Ensemble, ils transforment un simple chatbot en agent autonome capable d’agir 24h/24 sans intervention humaine.

Comprendre l’architecture d’automatisation d’OpenClaw

Avant de plonger dans les commandes, vous devez comprendre comment les trois mécanismes d’automatisation s’articulent. Chacun répond à un besoin différent, et c’est leur combinaison qui rend OpenClaw réellement autonome.

Le heartbeat est le mécanisme de surveillance passive. À intervalles réguliers, l’agent se réveille, consulte un fichier de consignes (HEARTBEAT.md), et décide s’il doit agir ou se rendormir. Pensez-y comme un vigile qui fait une ronde toutes les 30 minutes : la plupart du temps il ne trouve rien, mais quand il détecte quelque chose, il intervient.

Les cron jobs sont des tâches planifiées à heures fixes. Contrairement au heartbeat qui se contente de vérifier, un cron job exécute systématiquement une action précise au moment programmé. Votre briefing du matin à 7h, votre rapport hebdomadaire le vendredi à 17h, votre backup Git quotidien à minuit.

Les hooks sont des réactions événementielles. Ils se déclenchent quand quelque chose se passe à l’intérieur d’OpenClaw (un /new, un /reset, un démarrage du Gateway). Ce sont des scripts TypeScript légers qui modifient le comportement de l’agent en temps réel.

Les webhooks font le pont avec l’extérieur. Ils exposent un endpoint HTTP que des services tiers (GitHub, Stripe, Gmail) peuvent appeler pour déclencher une action dans OpenClaw.

Le Heartbeat : rendre l’agent proactif

Comment fonctionne le heartbeat

Le heartbeat est ce qui distingue fondamentalement OpenClaw d’un chatbot classique. Au lieu d’attendre que vous lui parliez, l’agent se réveille périodiquement, lit le fichier HEARTBEAT.md dans son workspace, et décide de l’action à entreprendre.

Le cycle est simple : réveil → lecture du fichier de consignes → décision (agir ou non) → rapport ou silence → retour en veille. Si l’agent ne détecte rien nécessitant une intervention, il répond HEARTBEAT_OK, un token spécial que le Gateway intercepte et supprime silencieusement. Pas de spam dans vos conversations.

Par défaut, le heartbeat s’exécute toutes les 30 minutes. Si vous utilisez OAuth Anthropic ou un setup-token, l’intervalle passe automatiquement à 1 heure. Vous pouvez ajuster ces valeurs via la configuration.

Configurer le heartbeat

La configuration du heartbeat se fait dans le fichier de config OpenClaw (généralement openclaw.json ou via la CLI) :

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "30m",
        "model": "anthropic/claude-sonnet-4-6",
        "lightContext": false,
        "isolatedSession": false,
        "includeReasoning": false,
        "target": "last"
      }
    }
  }
}

Les paramètres clés :

Pour modifier un paramètre via la CLI :

# Changer l'intervalle du heartbeat
openclaw config set agents.defaults.heartbeat.every "1h"

# Utiliser un modèle local pour économiser
openclaw config set agents.defaults.heartbeat.model "ollama/llama3.2:3b"

# Activer le mode léger
openclaw config set agents.defaults.heartbeat.lightContext true

Rédiger un bon fichier HEARTBEAT.md

Le fichier HEARTBEAT.md est le cerveau de vos heartbeats. Il se place dans le workspace de l’agent (par défaut ~/.openclaw/workspace/). Voici un exemple concret et fonctionnel :

# Heartbeat Checklist

## Emails (chaque heartbeat)
- Vérifier Gmail pour les emails non lus
- VIPs : boss@entreprise.com, cto@entreprise.com
- Emails VIP → m'envoyer un résumé WhatsApp immédiatement
- Autres → regrouper dans un digest
- Emails promotionnels → marquer comme lus automatiquement

## GitHub (chaque heartbeat)
- Vérifier github.com/mon-org/mon-repo pour nouvelles issues et PRs
- PRs : vérifier si la CI passe, résumer le diff
- CI en échec sur main → m'alerter sur Discord

## Rappels
- Vérifier les tâches en retard dans Notion
- Si une deadline est dans moins de 2h, m'envoyer un rappel

## Règle de silence
- Si rien ne nécessite attention, répondre HEARTBEAT_OK
- Ne pas inventer des tâches, ne pas répéter d'anciennes conversations

Optimiser le coût des heartbeats

Chaque heartbeat consomme des tokens LLM. Avec un intervalle de 30 minutes, c’est 48 appels par jour. Si vous utilisez Claude Opus 4.6 pour chaque heartbeat, la facture grimpe vite.

La stratégie la plus efficace : utiliser un modèle léger et bon marché pour les heartbeats, et réserver le modèle puissant pour les tâches réelles. En pratique, les heartbeats ne font que de la classification simple (« il y a du travail » vs « rien à signaler »), ce qui ne nécessite pas un modèle frontier.

Vous pouvez combiner lightContext: true (le heartbeat ne charge que HEARTBEAT.md au lieu de l’intégralité du workspace) et isolatedSession: true (pas d’historique de conversation, soit environ 2-5K tokens au lieu de 100K+). Cette combinaison réduit drastiquement la consommation de tokens par heartbeat.

Autre approche : utiliser un modèle local via Ollama. Un modèle de 3-4B paramètres (comme Llama 3.2) gère parfaitement les heartbeats simples, et le coût en tokens est nul. Vous ne payez que l’électricité.

Les cron jobs : tâches planifiées à heures fixes

Syntaxe et création

Les cron jobs OpenClaw utilisent la syntaxe cron Unix standard à 5 champs : minute, heure, jour du mois, mois, jour de la semaine. Ils sont créés via la CLI avec la commande openclaw cron add.

Trois modes de planification sont disponibles :

# 1. Exécution unique à une date précise (--at)
openclaw cron add 
  --name "rappel-reunion" 
  --at "2026-03-25T09:00:00+01:00" 
  --message "Me rappeler la réunion budget dans 30 minutes"

# 2. Exécution récurrente à intervalle fixe (--every)
openclaw cron add 
  --name "check-api" 
  --every "2h" 
  --message "Vérifier que l'API https://mon-service.com/health répond 200"

# 3. Expression cron classique (--cron)
openclaw cron add 
  --name "briefing-matin" 
  --cron "0 7 * * 1-5" 
  --tz "Europe/Paris" 
  --message "Préparer mon briefing matinal : météo Paris, premiers événements agenda, emails prioritaires"

Exemples concrets de cron jobs

Voici des templates prêts à copier-coller pour les cas d’usage les plus courants :

Briefing matinal quotidien :

openclaw cron add 
  --name "briefing-matin" 
  --cron "0 7 * * *" 
  --tz "Europe/Paris" 
  --session isolated 
  --message "Préparer un briefing concis : 1) Météo Paris aujourd'hui 2) Mes 3 premiers événements agenda 3) Emails non lus importants 4) Tâches en retard" 
  --announce 
  --channel whatsapp 
  --to "+33612345678" 
  --timeout 120

Rapport hebdomadaire automatique :

openclaw cron add 
  --name "rapport-hebdo" 
  --cron "0 17 * * 5" 
  --tz "Europe/Paris" 
  --session isolated 
  --message "Générer le rapport hebdomadaire : 1) Résumé des événements de la semaine 2) PRs mergées sur GitHub 3) Tâches complétées dans Notion 4) Points bloquants à escalader" 
  --announce 
  --channel slack 
  --to "channel:C1234567890"

Monitoring serveur toutes les 5 minutes :

openclaw cron add 
  --name "monitoring-serveur" 
  --every "5m" 
  --session isolated 
  --message "Vérifier : 1) Usage CPU (alerter si > 85%) 2) RAM (alerter si > 90%) 3) Espace disque (alerter si > 85%) 4) Status des containers Docker. Si tout est OK, ne rien envoyer." 
  --timeout 60

Veille concurrentielle quotidienne :

openclaw cron add 
  --name "veille-concurrence" 
  --cron "0 10 * * 1-5" 
  --tz "Europe/Paris" 
  --session isolated 
  --message "Chercher sur le web les dernières actualités de [concurrent1], [concurrent2], [concurrent3]. Résumer les annonces produit, levées de fonds, ou changements de prix. Ne m'envoyer que s'il y a du nouveau." 
  --announce 
  --channel telegram

Gérer les cron jobs existants

La CLI fournit toutes les commandes nécessaires pour piloter vos jobs :

# Lister tous les jobs planifiés
openclaw cron list

# Voir les détails d'un job
openclaw cron show briefing-matin

# Mettre un job en pause
openclaw cron pause briefing-matin

# Reprendre un job en pause
openclaw cron resume briefing-matin

# Exécuter un job immédiatement (test)
openclaw cron run briefing-matin

# Supprimer un job
openclaw cron delete briefing-matin

# Voir l'historique d'exécution
openclaw cron runs --id briefing-matin

Les jobs sont persistés dans ~/.openclaw/cron/jobs.json. Vous pouvez éditer ce fichier manuellement, mais uniquement quand le Gateway est arrêté. En fonctionnement normal, passez toujours par la CLI.

Sessions isolées vs contextuelles

Un paramètre crucial pour les cron jobs est le choix de session :

Le mode --session isolated démarre chaque exécution dans une session vierge, sans historique de conversation. C’est le mode recommandé pour la plupart des cron jobs : rapports, monitoring, vérifications. L’avantage est un contexte léger (2-5K tokens au lieu de 100K+), donc moins de coûts et moins de risques de confusion.

Le mode --session session:mon-id permet de persister le contexte entre les exécutions. Utile pour des workflows qui construisent progressivement de l’information, comme un standup quotidien qui se base sur le résumé de la veille, ou un suivi de projet qui accumule des données sur plusieurs jours.

Gestion des erreurs et retry

OpenClaw applique un backoff exponentiel en cas d’erreurs :

Pour les jobs récurrents (cron/every) : en cas d’erreur, le backoff s’applique progressivement (30s → 1m → 5m → 15m → 60m) avant la prochaine exécution. Le job reste actif. Le backoff se réinitialise après une exécution réussie.

Pour les jobs ponctuels (at) : en cas d’erreur transitoire (rate limit, réseau, surcharge), jusqu’à 3 retries avec backoff. Les erreurs permanentes désactivent immédiatement le job.

Les erreurs transitoires incluent les codes 429 (rate limit), les erreurs réseau (timeout, ECONNRESET), et les erreurs de surcharge des fournisseurs (comme le 529 d’Anthropic). Les erreurs permanentes (prompt invalide, modèle inexistant) causent une désactivation immédiate.

Les Hooks : automatisation événementielle

Le concept des hooks

Les hooks sont des scripts TypeScript légers qui réagissent aux événements internes du Gateway OpenClaw. Contrairement aux cron jobs déclenchés par le temps, les hooks se déclenchent quand quelque chose se passe : une nouvelle session démarre, le Gateway redémarre, un message est envoyé.

Le modèle mental est celui des event listeners : « Si X se passe → exécuter Y ». Si vous avez déjà utilisé des GitHub Actions ou des event listeners en JavaScript, les hooks OpenClaw vous sembleront familiers.

Types d’événements disponibles

Les hooks intégrés

OpenClaw est livré avec plusieurs hooks prêts à l’emploi :

session-memory : sauvegarde automatiquement le contexte de session dans ~/.openclaw/workspace/memory/ quand vous lancez /new. Sans ce hook, vous perdez tout le contexte de votre conversation précédente.

command-logger : écrit un journal de toutes les commandes exécutées dans ~/.openclaw/logs/commands.log au format JSON. Indispensable pour l’audit et le debug.

boot-md : exécute le fichier BOOT.md au démarrage du Gateway. Permet d’initialiser des variables, charger des configurations, ou lancer des vérifications au boot.

bootstrap-extra-files : injecte des fichiers additionnels (comme AGENTS.md ou TOOLS.md) pendant la phase de bootstrap de l’agent. Utile pour les monorepos.

Activer et gérer les hooks

# Lister tous les hooks découverts
openclaw hooks list

# Voir les détails d'un hook
openclaw hooks info session-memory

# Activer un hook
openclaw hooks enable session-memory

# Désactiver un hook
openclaw hooks disable session-memory

# Mettre à jour les hook packs installés
openclaw hooks update

Les hooks sont automatiquement découverts dans trois répertoires, par ordre de priorité : les hooks du workspace (<workspace>/hooks/), les hooks managés (~/.openclaw/hooks/), et les hooks intégrés (<openclaw>/dist/hooks/bundled/).

Pendant l’onboarding (openclaw onboard), l’assistant vous propose d’activer les hooks recommandés. Si vous avez sauté cette étape, vous pouvez toujours les activer manuellement avec la commande ci-dessus.

Créer un hook personnalisé

Un hook personnalisé se compose de deux fichiers dans un répertoire : un fichier de métadonnées HOOK.md et un handler TypeScript.

Le fichier HOOK.md avec son frontmatter YAML :

---
name: notify-on-error
description: "Envoie une notification Telegram quand un outil échoue"
metadata:
  openclaw:
    emoji: "🚨"
    events: ["tool_result_persist"]
    requires:
      bins: ["node"]
---

# Notify on Error

Surveille les résultats d'outils et envoie une alerte
quand un outil retourne une erreur.

Le handler TypeScript (handler.ts) :

import type { HookHandler } from "../../src/hooks/hooks.js";

const handler: HookHandler = {
  events: ["tool_result_persist"],
  async handle(event) {
    if (event.payload?.error) {
      console.log(`[notify-on-error] Outil en erreur: ${event.payload.toolName}`);
      // Logique de notification ici
    }
    return event.payload; // Retourner le payload intact
  }
};

export default handler;

Placez le répertoire du hook dans ~/.openclaw/hooks/notify-on-error/, puis activez-le avec openclaw hooks enable notify-on-error. Les hook packs (packages npm qui regroupent plusieurs hooks) s’installent avec openclaw hooks install <nom-du-pack>.

Les Webhooks : connecter l’extérieur

Configuration des webhooks

Les webhooks permettent à des services externes d’envoyer des événements à OpenClaw via HTTP. La configuration se fait dans le bloc hooks de votre config :

{
  "hooks": {
    "enabled": true,
    "path": "/hooks",
    "token": "votre-secret-tres-long-et-aleatoire"
  }
}

Le token sert d’authentification. Chaque requête entrante doit inclure ce token dans un header Authorization: Bearer <token>. Ne réutilisez jamais un token d’API existant pour vos webhooks.

Cas d’usage courants

GitHub → OpenClaw (review automatique de PR) : configurez un webhook GitHub qui envoie les événements pull_request à votre endpoint OpenClaw. L’agent peut alors résumer le diff, vérifier le statut CI, et poster un commentaire de review préliminaire.

Sentry → OpenClaw (alertes d’erreurs) : quand Sentry détecte une nouvelle erreur en production, le webhook déclenche un agent OpenClaw qui analyse la stack trace, cherche des solutions dans la documentation, et vous envoie un résumé avec des pistes de résolution sur Slack.

Stripe → OpenClaw (suivi de paiements) : les événements Stripe (payment_intent.succeeded, invoice.payment_failed) déclenchent des actions dans OpenClaw : mise à jour d’un tableau de bord, notification client, ou escalade en cas d’échec.

Workflows d’automatisation avancés

Triage d’emails intelligent

Ce workflow combine heartbeat et skills pour gérer automatiquement votre boîte mail. L’agent vérifie Gmail à chaque heartbeat, classe les emails par priorité, et vous alerte instantanément pour les messages urgents tout en regroupant le reste dans un digest.

Dans votre HEARTBEAT.md :

## Triage Email
- Vérifier Gmail (compte pro@entreprise.com) pour les non-lus
- Emails du CEO, CTO, ou clients VIP → résumé WhatsApp immédiat
- Emails internes non urgents → digest toutes les 4h
- Newsletters → marquer comme lus, stocker les liens intéressants
- Spam détecté → archiver silencieusement

Pipeline DevOps automatisé

Un cron job surveille vos repos GitHub et automatise les tâches répétitives de développement :

openclaw cron add 
  --name "devops-daily" 
  --cron "0 9 * * 1-5" 
  --tz "Europe/Paris" 
  --session "session:devops" 
  --message "1) Vérifier les PRs ouvertes depuis plus de 3 jours sur github.com/mon-org/mon-repo, envoyer un rappel aux auteurs. 2) Vérifier que la CI passe sur toutes les branches actives. 3) Résumer les issues créées hier, catégoriser en bug/feature/question. 4) Vérifier les dépendances npm/pip pour des vulnérabilités connues." 
  --announce 
  --channel slack 
  --to "channel:dev-ops"

Veille et curation de contenu

Ce workflow utilise un cron job quotidien pour transformer des newsletters en digest résumé, envoyé directement sur WhatsApp ou Telegram :

openclaw cron add 
  --name "veille-ia" 
  --cron "0 10 * * *" 
  --tz "Europe/Paris" 
  --session isolated 
  --message 'Vérifier Gmail label "Veille IA" pour les emails des dernières 24h. Extraire les actualités IA les plus importantes, dédupliquer les sujets récurrents, et envoyer un digest WhatsApp avec : (1) les 5 mises à jour majeures en bullets (2) pourquoi chacune est importante en une ligne (3) liens sources quand disponibles. Si aucun email pertinent, dire simplement qu il n y a pas de nouveauté majeure.' 
  --announce 
  --channel whatsapp 
  --to "+33612345678" 
  --timeout 180

Monitoring des réseaux sociaux

Automatisez la surveillance de votre marque ou de vos concurrents sur les réseaux sociaux :

openclaw cron add 
  --name "social-monitoring" 
  --cron "0 */3 * * *" 
  --tz "Europe/Paris" 
  --session isolated 
  --message "Chercher sur le web les mentions de [nom-de-marque] des 3 dernières heures. Résumer : nombre total de mentions, sentiment général (positif/neutre/négatif), les 3 posts les plus engagés, et toute plainte ou demande de support nécessitant une réponse." 
  --announce 
  --channel slack 
  --to "channel:social-media"

Combiner les trois mécanismes

La puissance réelle d’OpenClaw émerge quand vous combinez heartbeat, cron et hooks. Voici un schéma d’architecture typique pour un agent d’entreprise :

Les hooks gèrent la plomberie interne : sauvegarde de mémoire à chaque /new (session-memory), injection de fichiers de contexte au bootstrap (bootstrap-extra-files), logging de toutes les commandes (command-logger).

Le heartbeat assure la surveillance continue : vérification des emails urgents, monitoring de la santé des services, détection de changements nécessitant attention.

Les cron jobs gèrent les tâches à horaires fixes : briefing matinal, rapport hebdomadaire, backup nocturne, publication de contenu planifiée.

Les webhooks connectent l’écosystème externe : événements GitHub, alertes Sentry, notifications Stripe, déclencheurs n8n ou Zapier.

Maîtriser les coûts d’automatisation

L’automatisation OpenClaw est gratuite côté logiciel, mais chaque exécution qui invoque un LLM consomme des tokens facturés par le fournisseur. Voici comment garder le contrôle.

Les leviers d’optimisation principaux :

Modèle par tâche : utilisez un modèle économique pour les heartbeats et les cron jobs simples (Claude Haiku à environ 1 $/M tokens en input, ou un modèle local gratuit via Ollama), et réservez les modèles puissants comme Claude Sonnet 4.6 (3 $/M input) ou Opus 4.6 (5 $/M input) pour les tâches complexes.

Sessions isolées : un heartbeat avec historique complet peut consommer 100K+ tokens d’input. En mode isolé, c’est 2-5K. La différence sur 48 exécutions quotidiennes est massive.

Jobs shell-only : les cron jobs qui n’ont besoin que de commandes shell (git commit, nettoyage de fichiers, vérification d’espace disque) ne consomment aucun token LLM. Utilisez des scripts bash quand la logique est déterministe.

Dépannage et debug

Le heartbeat ne se déclenche pas

Vérifiez d’abord que le Gateway est bien en cours d’exécution avec openclaw gateway status. Ensuite, contrôlez la configuration du heartbeat avec openclaw config get agents.defaults.heartbeat. Si every est à 0m, le heartbeat est désactivé. Vérifiez aussi les heures actives (activeHours) : si vous avez configuré « 08:00-22:00 » et qu’il est 23h, le heartbeat est en pause jusqu’au lendemain.

Pour forcer un heartbeat immédiat et voir ce qui se passe :

# Déclencher un heartbeat maintenant
openclaw heartbeat --now

# Dry run (voir ce qui se passerait sans exécuter)
openclaw heartbeat --dry-run

# Voir les logs du heartbeat
openclaw logs --filter heartbeat --follow

Un cron job échoue silencieusement

La cause la plus fréquente : un message trop vague. « Vérifier les choses » ne donne rien d’exploitable. Testez d’abord votre message manuellement en le collant dans le chat pour voir si l’agent comprend et exécute correctement.

Autres points de vérification : la timezone (--tz) est-elle correcte ? La session cible a-t-elle le contexte nécessaire ? Le canal de livraison (--channel et --to) est-il bien configuré ? Consultez l’historique avec openclaw cron runs --id <jobId> pour voir si le job a tourné et quel résultat il a produit.

Un hook ne se déclenche pas

Vérifiez que le hook est bien activé : openclaw hooks list doit le montrer avec un ✓. Vérifiez ses prérequis (certains hooks nécessitent des binaires spécifiques sur la machine). Redémarrez le Gateway après avoir activé un hook : les hooks sont chargés au démarrage.

Intégrations avec les outils d’automatisation externes

OpenClaw peut se combiner avec des plateformes d’automatisation dédiées pour des workflows encore plus complexes :

OpenClaw + n8n : n8n déclenche des workflows via webhook vers OpenClaw, ou OpenClaw lance des scénarios n8n via leur API. Idéal pour les traitements multi-étapes avec logique conditionnelle complexe. Il existe même un skill OpenClaw dédié à la génération de workflows n8n.

OpenClaw + Make : les scénarios Make peuvent envoyer des webhooks à OpenClaw quand un événement survient dans l’un des 1500+ services connectés. OpenClaw apporte l’intelligence (analyse, décision, rédaction) là où Make gère l’orchestration.

OpenClaw + Zapier : même principe, avec les 7000+ intégrations de Zapier. Un Zap détecte un événement → webhook vers OpenClaw → l’agent traite et répond → webhook retour vers Zapier pour distribuer le résultat.

Bonnes pratiques de sécurité

L’automatisation donne à votre agent IA la capacité d’agir sans supervision. C’est puissant, mais c’est aussi un vecteur de risque qu’il faut prendre au sérieux.

Principe du moindre privilège : ne donnez à l’agent que les permissions strictement nécessaires. Si un cron job n’a besoin que de lire Gmail, ne lui donnez pas accès au shell. Si un heartbeat ne surveille que le calendrier, pas besoin des permissions filesystem.

Isolation des environnements : exécutez OpenClaw dans un environnement isolé (container Docker, VM dédiée, ou VPS séparé). Si l’agent fait une erreur ou est compromis, les dégâts restent contenus.

Tokens et secrets : ne codez jamais vos clés API ou tokens webhook en dur dans les fichiers de configuration. Utilisez des variables d’environnement. Faites tourner (rotate) régulièrement vos tokens webhook.

Monitoring des coûts : un cron job mal configuré qui boucle ou un heartbeat trop fréquent avec un modèle cher peut faire exploser votre facture. Configurez des alertes de dépenses chez votre fournisseur LLM et surveillez régulièrement avec /status.