Automatiser les opérations avec OpenClaw : crons, triggers, files de tâches et escalades

Répondre à des questions, c'est 10 % de la valeur d'OpenClaw. Les 90 % restants se trouvent dans l'automatisation — les workflows qui tournent sans intervention humaine, les agents qui se déclenchent sur des événements, les tâches qui s'enchaînent de façon orchestrée. Ce billet couvre l'architecture d'automatisation complète.

1. Le vrai ROI d'OpenClaw : l'automatisation, pas la conversation

Une confusion fréquente chez les équipes qui évaluent OpenClaw : elles le testent comme un chatbot avancé — posent des questions, obtiennent des réponses, mesurent la qualité des réponses. C'est passer à côté de l'essentiel.

La valeur opérationnelle d'OpenClaw ne se mesure pas à la qualité d'une réponse ponctuelle. Elle se mesure au nombre de tâches qui s'exécutent sans qu'on les demande : le rapport matinal qui arrive avant que l'équipe soit au bureau, le monitoring qui détecte une anomalie à 3h du matin et escalade immédiatement, la facture qui se génère automatiquement quand un projet est marqué terminé.

Pour y arriver, OpenClaw offre plusieurs mécanismes d'automatisation qu'il faut connaître et combiner intelligemment. Leur usage n'est pas interchangeable — choisir le mauvais mécanisme, c'est soit perdre de l'argent (coûts API), soit rater des événements importants.

Règle fondamentale : toute tâche qui peut être planifiée sans intelligence artificielle devrait l'être via le cron système Linux. L'IA intervient uniquement là où le raisonnement est nécessaire.

2. Crons : système Linux vs crons OpenClaw

La distinction est fondamentale et souvent ignorée. Il existe deux types de planification dans un déploiement OpenClaw, avec des coûts et des usages radicalement différents.

Cron système Linux (0 coût API)

Le cron système Linux exécute des scripts shell ou Python directement sur le serveur, sans passer par le runtime OpenClaw. Coût API : zéro. Ces crons sont parfaits pour toutes les tâches mécaniques et déterministes :

• Sauvegardes et rotations de logs
• Rapprochements de données (import CSV, sync base de données)
• Nettoyage de fichiers temporaires
• Envoi d'emails de rapport formatés (template fixe, aucune génération IA)
• Monitoring ping et alertes binaires (up/down)
• Commits Git automatiques du workspace

Un cron système qui tourne toutes les 5 minutes pour vérifier la santé d'un service coûte 0€ en API et ne consomme aucun token. Il faut systématiquement se poser la question : est-ce que ce job nécessite du raisonnement ou de la génération de texte ? Si non → cron système.

Crons OpenClaw (coût API — parcimonie obligatoire)

Un cron OpenClaw déclenche une session de l'agent — ce qui signifie un appel API au LLM, avec un coût en tokens. Ces crons sont justifiés pour les tâches qui nécessitent :

• Lecture et résumé de contenu non structuré (emails, tickets, logs)
• Prise de décision contextuelle (prioriser, classer, recommander)
• Génération de contenu variable (rapports rédigés, digests personnalisés)
• Actions conditionnelles complexes (si X et Y et non Z → faire W)
• Coordination entre agents (orchestration)

La règle opérationnelle : les crons OpenClaw ne doivent pas tourner plus souvent que nécessaire. Un digest email quotidien à 8h → 1 session/jour. Un rapport hebdomadaire → 1 session/semaine. Éviter à tout prix les intervalles courts (toutes les heures ou moins) pour des tâches d'agrégation qui pourraient être batchées.

Exemple de configuration

Crontab système (pas d'API) :

# Backup workspace Git toutes les heures
0 * * * * cd /workspace && git add -A && git commit -m "auto: hourly checkpoint" 2>/dev/null

# Nettoyage logs > 30 jours
0 2 * * * find /var/log/app/ -mtime +30 -delete

# Rapport CSV quotidien — script Python déterministe
30 7 * * * python3 /scripts/gen_daily_csv.py

Cron OpenClaw (avec appel API) :

# Digest email intelligent — 1x/jour à 8h (via openclaw schedule)
# schedule: "0 8 * * *"
# prompt: "Lire les emails des 24h, rédiger un digest priorisé"

# Rapport hebdomadaire — vendredi 16h
# schedule: "0 16 * * 5"
# prompt: "Analyser les métriques de la semaine et rédiger le rapport"

3. Triggers et événements

Les crons déclenchent des agents à intervalles fixes. Les triggers déclenchent des agents sur des événements — c'est plus réactif et souvent plus efficace.

Heartbeat

Le heartbeat est un mécanisme OpenClaw qui réveille l'agent à intervalles réguliers pour effectuer des vérifications légères. Contrairement au cron qui exécute une tâche précise, le heartbeat permet à l'agent de consulter son état et de décider s'il y a quelque chose à faire.

Bonne utilisation : vérifier les emails urgents 2-3 fois par jour, contrôler le calendrier pour les événements imminents, valider la santé du workspace.

Mauvaise utilisation : heartbeats toutes les 15 minutes pour ne rien trouver → coût API inutile. Un heartbeat inactif doit retourner HEARTBEAT_OK sans traitement supplémentaire.

Messages entrants comme déclencheurs

Un message reçu sur le canal de l'agent (Telegram, Discord, etc.) est lui-même un trigger. L'agent peut recevoir :

• Des instructions directes depuis l'humain
• Des notifications automatiques depuis d'autres systèmes (webhooks)
• Des messages d'autres agents dans un workflow multi-agents

Ce mécanisme est particulièrement utile pour les escalades (voir section 5) : un agent qui détecte une anomalie peut notifier l'humain via message, et l'humain peut répondre pour autoriser une action.

Événements planifiés dans le workspace

L'agent peut maintenir un fichier d'événements planifiés dans son workspace — un registre de tâches futures avec leur date d'exécution cible. À chaque heartbeat ou cron, l'agent consulte ce registre et exécute les tâches dont l'heure est venue.

# events/scheduled.json
{
  "tasks": [
    {
      "id": "facture-Q1-2026",
      "due": "2026-03-31T09:00:00",
      "type": "billing",
      "payload": {"client": "Acme Corp", "period": "Q1-2026"}
    },
    {
      "id": "review-hebdo",
      "due": "2026-03-21T16:00:00",
      "type": "report",
      "payload": {"scope": "weekly-metrics"}
    }
  ]
}

4. Files de tâches (task queues)

Quand plusieurs agents travaillent ensemble, il faut un mécanisme pour passer le travail de l'un à l'autre de façon ordonnée et traçable. Le pattern JSON queue est simple et efficace.

Pattern JSON queue

Un fichier JSON dans le workspace partagé fait office de queue. L'agent producteur y ajoute des tâches, l'agent consommateur les lit, les traite, et met à jour leur statut.

# queues/content-queue.json
{
  "items": [
    {
      "id": "post-openclaw-b9",
      "status": "pending",
      "type": "blog_post",
      "created_by": "JARVIS",
      "created_at": "2026-03-14T08:00:00",
      "payload": {
        "title": "Mémoire et contexte dans OpenClaw",
        "deadline": "2026-03-21",
        "brief": "memory/b9-brief.md"
      }
    }
  ]
}

Workflow agent → agent

Un workflow typique dans un réseau d'agents BOTUM :

1. Agent JARVIS (système) détecte qu'une deadline de publication approche → ajoute une tâche dans queues/content-queue.json
2. Agent CYRANO (rédaction) lit la queue à son prochain heartbeat → traite la tâche → produit le billet → marque status: done
3. Agent JARVIS détecte le statut done → déclenche la publication Ghost → notifie via Telegram

Ce pattern offre une traçabilité complète : chaque changement de statut est committé dans Git, chaque handoff est horodaté et auditables.

Handoffs entre agents

Au-delà de la queue simple, les handoffs peuvent inclure des artefacts — fichiers produits par un agent et consommés par le suivant :

• Agent HERMÈS produit outputs/email-digest-2026-03-14.md → JARVIS l'inclut dans le briefing matinal
• Agent LEDGER produit outputs/timesheet-march.csv → CYRANO le formate en rapport client
• Agent ARGUS produit outputs/veille-tech-semaine-11.md → NEXUS sélectionne les sujets pour LinkedIn

5. Escalades

L'automatisation ne supprime pas le besoin de jugement humain — elle le concentre là où il est vraiment nécessaire. Un agent bien conçu sait reconnaître les situations qui dépassent son périmètre de décision et escalade de façon structurée.

Quand escalader ?

• Décision irréversible à fort impact : envoyer un email à un client important, supprimer des données, déclencher une dépense
• Ambiguïté de la demande : plusieurs interprétations plausibles avec des conséquences différentes
• Situation inconnue : l'agent rencontre un cas que ses règles ne couvrent pas
• Timeout : une tâche prend trop de temps sans résultat → notification à l'humain
• Erreur répétée : 3 tentatives échouées sur la même tâche → escalade automatique

Mécanisme d'escalade

L'agent envoie une notification structurée via le canal de messagerie configuré, avec contexte et options d'action :

🚨 ESCALADE — Agent LEDGER
Tâche : Génération facture Acme Corp Q1-2026
Montant : 8 400 $
Problème : Taux horaire non confirmé (contrat ambigu)
Options :
  [A] Utiliser 125$/h (dernier taux confirmé)
  [B] Attendre confirmation client
  [C] Suspendre — je traite manuellement
Timeout : 4h → action A par défaut

L'humain répond, l'agent reprend. Si aucune réponse dans le délai imparti, un fallback défini s'applique — jamais d'inaction indéfinie.

Timeouts et fallbacks

Chaque escalade doit avoir un timeout explicite et un comportement de fallback documenté. Les options courantes :

• Action conservative par défaut : si pas de réponse, prendre l'action la moins risquée
• Suspension de la tâche : mettre en attente avec log dans la queue
• Re-escalade à un niveau supérieur : après N heures, escalade vers un canal de supervision

6. Orchestration multi-agents

L'orchestration multi-agents est le niveau supérieur de l'automatisation OpenClaw — un agent coordinateur qui délègue à des agents spécialisés, agrège leurs résultats et prend des décisions de haut niveau.

Architecture chef-délégués

L'agent JARVIS (système) joue le rôle de coordinateur dans l'infrastructure BOTUM. Il ne traite pas les données lui-même — il orchestre :

• Il surveille le workspace et détecte les déclencheurs (deadline, anomalie, queue non vide)
• Il spawn des sous-agents avec des contextes légers et des missions précises
• Il attend leurs résultats (push-based, pas de polling)
• Il agrège et prend des décisions sur la base des résultats
• Il notifie l'humain si nécessaire

Isolation des contextes

Chaque sous-agent reçoit un contexte minimal — uniquement ce dont il a besoin pour sa tâche. Cette isolation est à la fois une mesure de sécurité (un sous-agent compromis n'expose qu'une partie du contexte) et une optimisation des coûts (contexte léger = moins de tokens).

Monitoring des résultats

Les sous-agents écrivent leurs résultats dans des fichiers partagés dans le workspace. L'agent coordinateur n'a pas besoin de rester actif pendant leur exécution — il lit les résultats quand ils sont disponibles. Ce pattern évite les blocages et permet une parallélisation naturelle.

# Exemple : résultat d'un sous-agent
# outputs/subagent-results/email-digest-20260314.json
{
  "agent": "hermes",
  "task": "email-digest",
  "status": "done",
  "completed_at": "2026-03-14T08:12:33",
  "output_file": "outputs/email-digest-2026-03-14.md",
  "summary": "23 emails traités, 3 urgents identifiés",
  "escalations": ["email:facture-impayée-client-X"]
}

7. Patterns d'automatisation concrets

Quatre patterns en production chez BOTUM — documentés avec leur architecture réelle.

Pattern 1 : Digest email quotidien

Fréquence : Tous les matins à 7h45 (cron OpenClaw)
Agent : HERMÈS
Fonctionnement :

1. Lit les emails des 24h via himalaya CLI
2. Classe par priorité (urgent / à traiter / FYI / newsletter)
3. Rédige un digest structuré en markdown
4. Écrit dans outputs/email-digest-YYYY-MM-DD.md
5. Notifie JARVIS → inclusion dans le briefing 8h15

Coût : ~2 000 tokens/jour (une session légère)

Pattern 2 : Rapport hebdomadaire

Fréquence : Vendredi 16h (cron OpenClaw)
Agents : LEDGER + JARVIS + CYRANO
Fonctionnement :

1. LEDGER compile les timesheets de la semaine → outputs/timesheet-week-NN.csv
2. JARVIS aggrège métriques infrastructure + git activity
3. CYRANO rédige le rapport client avec les données compilées
4. PDF généré → envoyé au client

Coût : ~8 000 tokens/semaine (3 sessions coordonnées)

Pattern 3 : Facturation automatique

Déclencheur : Marquage d'un projet comme "terminé" dans le workspace
Agent : LEDGER
Fonctionnement :

1. Détection du changement de statut via monitoring de fichier
2. Calcul du montant (heures × taux contractuel)
3. Vérification : montant > seuil de validation → escalade humaine
4. Si validé ou sous le seuil : génération de la facture PDF
5. Envoi automatique ou mise en queue selon préférence client

Pattern 4 : Alerte monitoring infrastructure

Fréquence : Cron système toutes les 5 minutes (0 coût API)
Escalade : Cron OpenClaw si anomalie détectée
Fonctionnement :

1. Script bash vérifie les services (ping, HTTP 200, espace disque)
2. Si tout OK → log silencieux, 0 coût API
3. Si anomalie → écriture dans alerts/pending.json
4. Agent JARVIS lit le fichier à son prochain heartbeat → analyse contexte
5. Si critique → notification immédiate avec contexte enrichi
6. Si non-critique → agrégé dans le digest matinal

8. Anti-patterns à éviter

Les erreurs d'automatisation les plus coûteuses — documentées pour que personne n'ait à les reproduire.

❌ Boucles infinies d'agents

Agent A crée une tâche pour agent B, agent B crée une tâche pour agent A, sans condition de terminaison. Résultat : boucle infinie, coûts API explosifs. Règle : tout workflow doit avoir une condition de terminaison explicite et un compteur de max-iterations.

❌ Heartbeats trop fréquents

Un heartbeat toutes les 15 minutes génère 96 sessions/jour. Même si chaque session est légère (500 tokens), c'est 48 000 tokens/jour de coût de base avant d'avoir fait quoi que ce soit d'utile. Calibrer les heartbeats selon la latence acceptable pour la tâche — la plupart des tâches supportent 2-4 heartbeats par jour.

❌ Agents trop larges

Un agent qui tente de tout faire dans une seule session — lire les emails, analyser les métriques, rédiger un rapport, vérifier le calendrier — accumule un contexte énorme, prend des décisions de moins en moins cohérentes, et coûte cher. Découper en agents spécialisés avec des sessions courtes et focalisées.

❌ Automatisation sans logs ni traçabilité

Un workflow qui s'exécute sans laisser de trace dans Git ou dans un fichier de log est impossible à auditer et à déboguer. Chaque action automatique significative doit être loggée avec timestamp, agent responsable, décision prise et résultat.

❌ Escalades sans timeout

Une escalade sans timeout peut bloquer un workflow indéfiniment. Si l'humain ne répond pas, le système est gelé. Toujours définir un comportement de fallback clair avec un délai explicite.

❌ Crons OpenClaw pour du travail mécanique

Utiliser un cron OpenClaw pour générer un rapport CSV à partir de données structurées (zéro intelligence artificielle requise) est un gaspillage pur. Le cron système Linux suffit — économie de 100 % sur ce job.

9. Checklist automatisation

• ✅ Chaque tâche planifiée est classifiée : cron système (0 coût) ou cron OpenClaw (coût justifié)
• ✅ Fréquence calibrée à la latence acceptable : pas de cron OpenClaw toutes les heures pour une tâche qui peut attendre la nuit
• ✅ Chaque workflow a une condition de terminaison : impossibilité de boucle infinie
• ✅ Chaque escalade a un timeout et un fallback explicites : jamais d'inaction indéfinie
• ✅ Chaque action automatique est loggée : timestamp, agent, décision, résultat
• ✅ Contextes des sous-agents minimaux : uniquement ce qui est nécessaire à la tâche
• ✅ Résultats des sous-agents en push : pas de polling actif
• ✅ Seuils d'escalade documentés : montant, impact, irréversibilité
• ✅ Tests de workflow réguliers : vérifier que l'automatisation fonctionne toujours après chaque changement de configuration
• ✅ Budget tokens mensuel estimé : chaque workflow automatisé doit avoir une estimation de son coût API

Conclusion

L'automatisation avec OpenClaw n'est pas une question de technologie — c'est une question d'architecture. Savoir quel mécanisme utiliser (cron système vs OpenClaw), comment structurer les files de tâches, quand escalader et comment, comment orchestrer plusieurs agents en parallèle : ces décisions déterminent si l'automatisation tient à l'échelle ou s'effondre sous sa propre complexité.

Les patterns présentés dans ce billet ne sont pas théoriques. Ils tournent en production. Les anti-patterns non plus — ils ont tous été rencontrés et corrigés.

→ Billet 9 : Mémoire et contexte dans OpenClaw — comment les agents se souviennent, apprennent et maintiennent leur état entre les sessions.