🔄 Cron classique vs Cron IA : deux philosophies
Le cron traditionnel : fiable mais aveugle
Le cron Unix existe depuis les années 1970. Son principe est simple : exécuter une commande à un moment précis, selon une expression temporelle (la fameuse syntaxe * * * * *).
Par exemple, on l'utilise couramment pour programmer des backups quotidiens à 3h du matin ou des vérifications de l'espace disque toutes les heures via des scripts shell dédiés.
Le problème ? Ce script s'exécute quoi qu'il arrive. Même si le backup est inutile (aucune modification), même si l'espace disque est parfait. Il ne sait pas adapter son comportement au contexte.
Le cron IA : contextuel et intelligent
Avec un agent IA, le paradigme change complètement. L'agent reçoit une instruction, mais il raisonne avant d'agir :
- Il vérifie si l'action est nécessaire
- Il adapte sa réponse au contexte
- Il peut escalader (alerter) ou ignorer selon la gravité
- Il produit des résumés lisibles pour l'humain
| Critère | Cron classique | Cron IA (OpenClaw) |
|---|---|---|
| Exécution | Aveugle, toujours | Contextuelle, intelligente |
| Réponse | Code retour (0/1) | Analyse en langage naturel |
| Adaptation | Aucune | Ajuste selon le contexte |
| Escalade | Script if/else manuel | Décision autonome |
| Coût | Quasi nul | Tokens LLM (optimisable) |
| Maintenance | Scripts à maintenir | Prompts en langage naturel |
| Monitoring | Logs bruts | Résumés intelligents |
| Multi-tâches | 1 cron = 1 script | 1 heartbeat = N vérifications |
🧠 Les deux mécanismes d'OpenClaw : Heartbeat et Cron
OpenClaw propose deux mécanismes complémentaires pour l'automatisation temporelle. Comprendre leurs différences est essentiel pour bien architecturer vos automatisations.
Le Heartbeat : le pouls de votre agent
Le heartbeat est un tour d'agent périodique dans la session principale. Par défaut, il se déclenche toutes les 30 minutes. L'agent "se réveille", consulte sa checklist (HEARTBEAT.md), et décide quoi faire.
La configuration s'effectue dans les paramètres d'OpenClaw, où l'on définit l'intervalle (par exemple "30m"), la cible de livraison, et les heures d'activité (comme de 08h00 à 22h00).
Points forts du heartbeat :
- Batch multiple checks : un seul tour d'agent peut vérifier l'email, le calendrier, les notifications et l'état d'un projet
- Contextuel : l'agent a accès à tout l'historique de la session principale
- Économique : un seul appel API au lieu de 5 cron jobs séparés
- Suppression intelligente : si rien ne nécessite attention, l'agent répond
HEARTBEAT_OKet aucun message n'est délivré
Le fichier HEARTBEAT.md sert de checklist au cœur de ce mécanisme : il contient les instructions comme scanner les emails urgents, vérifier le calendrier pour les 2 prochaines heures, résumer les résultats des tâches de fond terminées, vérifier l'état des services monitorés, ou faire un check-in léger en cas d'inactivité prolongée.
Le Cron OpenClaw : précision et isolation
Le cron OpenClaw est un scheduler intégré au Gateway. Il persiste les jobs, réveille l'agent au bon moment, et peut optionnellement délivrer le résultat dans un chat.
Deux modes d'exécution :
- Session principale (
main) : injecte un événement système traité au prochain heartbeat - Session isolée (
isolated) : lance un tour d'agent dédié danscron:<jobId>, sans polluer l'historique principal
Pour créer un job isolé récurrent avec livraison sur Telegram, on utilise la commande openclaw cron add en spécifiant le nom, l'expression cron, le fuseau horaire, le mode de session isolée, le prompt de la tâche, et le canal de destination.
Tableau de décision : Heartbeat ou Cron ?
| Cas d'usage | Recommandé | Pourquoi |
|---|---|---|
| Vérifier les emails toutes les 30 min | Heartbeat | Se combine avec d'autres checks |
| Rapport quotidien à 9h pile | Cron (isolated) | Timing exact nécessaire |
| Monitoring calendrier | Heartbeat | Adapté au check périodique |
| Analyse hebdomadaire approfondie | Cron (isolated) | Tâche autonome, peut utiliser un modèle différent |
| Rappel dans 20 minutes | Cron (main, --at) |
One-shot avec timing précis |
| Nettoyage de fichiers temporaires | Heartbeat | Piggyback sur le cycle existant |
| Génération de contenu nocturne | Cron (isolated) | Isolation + modèle dédié |
🛠️ Configurer ses premiers Cron Jobs IA
Prérequis
Avant de commencer, assurez-vous d'avoir :
- OpenClaw installé et le Gateway en fonctionnement
- Un provider LLM configuré (Claude, GPT, ou via OpenRouter)
- Un canal de communication configuré (Telegram, WhatsApp, Discord...)
Job 1 : Rappel one-shot
Le plus simple. Vous voulez un rappel dans 20 minutes. La commande openclaw cron add avec le flag --at "20m" permet de planifier un événement système dans la session principale. L'agent reçoit le rappel et, comme il tourne dans la session principale, il a tout le contexte de vos conversations récentes pour préparer le résumé. Le flag --delete-after-run assure que le job ne persiste pas.
Job 2 : Briefing matinal récurrent
Chaque matin à 7h30, un rapport complet est généré et envoyé sur Telegram via un cron isolé. On configure l'expression cron, le fuseau horaire Europe/Paris, et un prompt demandant la génération d'un briefing matinal (météo, emails, calendrier, actualités tech).
Pourquoi isolated ? Ce job n'a pas besoin du contexte de la session principale. Il effectue une tâche autonome et délivre le résultat directement.
Pourquoi --model opus ? Pour un briefing de qualité, on peut utiliser un modèle plus puissant. Les jobs isolés permettent de choisir le modèle indépendamment de la session principale.
Job 3 : Monitoring intelligent
Un job configuré toutes les 15 minutes vérifie l'état des services en interrogeant un fichier de configuration (comme /root/services.json). Si un service est down, l'agent analyse les logs récents et propose un diagnostic. Si tout est OK, il répond HEARTBEAT_OK. Contrairement à un script de monitoring classique, il analyse les logs en cas de problème et propose un diagnostic en langage naturel.
Job 4 : Revue hebdomadaire avec thinking élevé
Chaque lundi à 9h, un cron isolé lance une analyse approfondie de la semaine avec le modèle Opus. Le flag --thinking high active le raisonnement étendu du modèle, idéal pour des analyses complexes qui demandent de la réflexion (progression des projets, métriques clés, points de blocage, recommandations).
📋 Exemples concrets d'automatisation
Monitoring de site web intelligent
Au lieu d'un simple ping, l'agent IA peut :
- Vérifier le temps de réponse
- Comparer avec l'historique
- Détecter des tendances (dégradation progressive)
- Analyser le contenu de la page (erreurs visuelles, contenu manquant)
- Suggérer des actions correctives
Un cron isolé toutes les 30 minutes suffit pour vérifier un site web : temps de réponse, code HTTP, contenu, et comparaison avec les vérifications précédentes. L'agent alerte uniquement si une anomalie est détectée.
Génération de contenu planifiée
Chaque nuit à 2h du matin, l'agent consulte la base de données des articles en attente. Pour le prochain article en statut draft, il rédige le contenu complet en suivant le brief, puis met à jour le statut en need_review_human. Le modèle Opus est recommandé ici pour la qualité rédactionnelle.
Pour aller plus loin sur ce sujet, consultez notre guide Générer du contenu automatiquement avec l'IA.
Backups intelligents
Au lieu de sauvegarder aveuglément chaque nuit, un cron isolé à 3h du matin vérifie les fichiers modifiés depuis le dernier backup. Si des changements significatifs existent, il lance le backup incrémental, vérifie l'intégrité du backup, nettoie les backups de plus de 30 jours, et résume les actions effectuées. L'agent décide si un backup est nécessaire, vérifie son intégrité, et gère la rotation — le tout en un seul prompt.
Veille concurrentielle automatique
Un cron isolé configuré le lundi et jeudi à 10h effectue une veille concurrentielle : il visite les sites des concurrents listés dans un fichier JSON, détecte les changements de prix, nouvelles features, articles de blog, et résume les points importants avec le modèle Opus.
⚡ Combiner Heartbeat et Cron : la configuration optimale
La configuration la plus efficace utilise les deux mécanismes ensemble :
Architecture recommandée
Heartbeat (toutes les 30 min)
├── Scan emails urgents
├── Vérification calendrier (2h)
├── État des tâches en cours
└── Check-in léger si inactif
Cron isolé (timings précis)
├── 07:30 → Briefing matinal (Opus)
├── 02:00 → Génération contenu nocturne
├── */15 → Monitoring services
├── Lundi 09:00 → Revue hebdomadaire (Opus + thinking high)
└── One-shots → Rappels et deadlines
Configuration complète
La configuration s'effectue dans les paramètres d'OpenClaw. On y définit le heartbeat par défaut avec un intervalle de 30 minutes, une cible de livraison (comme Telegram), et des heures d'activité (par exemple de 07h00 à 23h00, fuseau Europe/Paris). On active également le module cron avec un nombre maximum de runs concurrents fixé à 1.
Le HEARTBEAT.md associé reste concis pour limiter les coûts : scan des emails urgents avec alerte si critique, vérification du calendrier sur les 2 prochaines heures, suivi de la progression des tâches en cours, et réponse HEARTBEAT_OK si rien d'urgent.
💰 Optimisation des coûts
Les cron jobs IA consomment des tokens. Voici comment optimiser :
| Stratégie | Économie estimée | Comment |
|---|---|---|
| Batching via heartbeat | ~70% | 1 heartbeat au lieu de 5 cron jobs |
HEARTBEAT_OK suppression |
~30% | Pas de livraison si rien à signaler |
| Modèle adapté par job | ~50% | Flash pour le monitoring, Opus pour l'analyse |
| Active hours | ~30-50% | Pas de heartbeat la nuit |
target: "none" |
~10% | Traitement interne uniquement |
| Prompts courts | ~20% | Moins de tokens en entrée |
Exemple de configuration économique
Pour le monitoring fréquent (toutes les 15 minutes), on utilise un modèle économique comme Flash avec un prompt ultra-court ("Ping services. OK ou alerte."). Pour l'analyse approfondie hebdomadaire (chaque lundi à 9h), on privilégie le modèle Opus avec un thinking élevé, la fréquence plus faible compensant le coût plus élevé du modèle.
🔧 Gestion et debugging
Commandes CLI essentielles
OpenClaw fournit plusieurs commandes pour gérer vos cron jobs : openclaw cron list pour lister tous les jobs, openclaw cron runs --id <jobId> --limit 50 pour voir l'historique d'exécution, openclaw cron run <jobId> pour forcer l'exécution immédiate, openclaw cron edit <jobId> pour modifier un job existant (prompt, activation, etc.), et openclaw cron remove <jobId> pour supprimer un job.
Retry et gestion des erreurs
OpenClaw gère automatiquement les erreurs avec un backoff exponentiel :
- 1ère erreur → retry après 30 secondes
- 2ème erreur → retry après 1 minute
- 3ème erreur → retry après 5 minutes
- 4ème erreur → retry après 15 minutes
- 5ème erreur+ → retry après 60 minutes
Le backoff se réinitialise automatiquement après un run réussi.
Stagger automatique
Pour les jobs récurrents planifiés en début d'heure (comme 0 * * * *), OpenClaw applique un décalage déterministe de 0 à 5 minutes pour éviter les pics de charge. Vous pouvez contrôler ce comportement avec le flag --exact pour forcer un timing exact (pas de stagger) ou --stagger 30s pour définir un décalage personnalisé.
🔒 Bonnes pratiques et sécurité
-
Ne mettez pas de secrets dans les prompts : les messages des jobs cron sont stockés en clair dans
~/.openclaw/cron/jobs.json. Référencez des fichiers de configuration à la place. -
Utilisez des sessions isolées pour les tâches sensibles : elles ne partagent pas l'historique de la session principale.
-
Limitez les active hours : pas besoin de heartbeat à 3h du matin si vous dormez (sauf pour le monitoring critique en cron isolé).
-
Gardez HEARTBEAT.md court : ce fichier est inclus dans le prompt à chaque heartbeat. Plus il est long, plus il coûte cher.
-
Monitorez vos coûts : vérifiez régulièrement
openclaw cron runspour identifier les jobs qui consomment trop. -
Pour envoyer un événement système immédiat sans créer de job persistant, utilisez la commande
openclaw system eventavec l'option--mode now.
❌ Erreurs courantes
- Laisser les secrets dans les prompts : c'est l'erreur la plus fréquente. Les prompts de cron sont stockés en clair. Utilisez toujours des variables d'environnement ou des fichiers de config externes.
- Utiliser uniquement des cron jobs pour tout : le heartbeat est plus économique pour les vérifications régulières groupées. Ne créez pas 5 cron jobs alors qu'un heartbeat suffit.
- Négliger les active hours : un heartbeat qui tourne 24h/24 sans raison multiplie les coûts par deux ou trois selon la plage inactive.
- Choisir le mauvais mode de session : un job qui n'a pas besoin de contexte principal doit être en
isolated, sinon il pollue l'historique et consomme plus de tokens. - Oublier le flag
--delete-after-runsur les one-shots : les rappels ponctuels s'accumulent dans la liste des jobs et compliquent la gestion.
🎯 L'essentiel
- Le cron IA d'OpenClaw remplace l'exécution aveugle par un raisonnement contextuel : l'agent décide si une action est nécessaire avant d'agir.
- Deux mécanismes complémentaires existent : le heartbeat (vérifications groupées et périodiques) et le cron (timings précis et tâches isolées).
- Les sessions isolées permettent de choisir un modèle différent par job et de ne pas polluer l'historique principal.
- L'optimisation des coûts passe par le batching (heartbeat), les prompts courts, les active hours, et le choix adapté du modèle (Flash pour le monitoring, Opus pour l'analyse).
- Commencez simple : un heartbeat avec quelques checks et un ou deux cron jobs, puis étendez progressivement.
❓ FAQ
Quelle est la différence entre un heartbeat et un cron ?
Le heartbeat est un tour d'agent périodique dans la session principale, idéal pour grouper plusieurs vérifications légères. Le cron est un scheduler qui déclenche des jobs à des timings précis, en session principale ou isolée.
Peut-on utiliser un modèle différent pour chaque cron job ?
Oui, avec les sessions isolées. Chaque job isolé peut spécifier son propre modèle via le flag --model, indépendamment de la session principale.
Que se passe-t-il si l'agent IA ne répond pas ?
OpenClaw applique un backoff exponentiel automatique : 30s, 1min, 5min, 15min, puis 60min entre chaque retry. Le backoff se réinitialise après un run réussi.
Est-ce que le heartbeat tourne 24h/24 ?
Non, on peut limiter les heures d'activité via le paramètre activeHours dans la configuration. Pour le monitoring nocturne, on utilise plutôt un cron isolé.
Combien coûte un cron IA par rapport à un cron classique ?
Un cron classique est quasi gratuit. Un cron IA consomme des tokens LLM, mais les stratégies d'optimisation (batching, HEARTBEAT_OK, modèle adapté) permettent de réduire la facture de 50 à 70% selon les cas.
🛒 Outils recommandés
- OpenClaw : plateforme d'orchestration pour configurer vos cron jobs IA, heartbeats et agents autonomes.
- Telegram / Discord / WhatsApp : canaux de livraison recommandés pour recevoir les alertes et rapports de vos cron jobs.
- Claude (Opus) / GPT : modèles LLM recommandés pour les tâches d'analyse complexes et la génération de contenu.
- OpenRouter : agrégateur de modèles permettant de switcher facilement entre modèles économiques (Flash) et premium (Opus) selon le job.
🎯 Conclusion
Le passage du cron classique au cron IA représente un changement de paradigme dans l'automatisation. Là où le cron traditionnel exécute mécaniquement des scripts, le cron IA d'OpenClaw raisonne, contextualise et s'adapte.
En combinant le heartbeat (pour les vérifications régulières et groupées) avec les cron jobs isolés (pour les tâches précises et autonomes), vous obtenez un système d'automatisation complet qui fonctionne 24h/24 avec un minimum d'intervention humaine.
La clé est de commencer simple — un heartbeat avec quelques checks et un ou deux cron jobs — puis d'étendre progressivement en fonction de vos besoins réels. L'avantage du prompt en langage naturel est que vous pouvez itérer rapidement sans réécrire de scripts.
