2026 : OpenClaw sur Mac Mini loué — chaîne HTTP façon DAG nocturne, sans Airflow complet (checkpoints, ordre des déclencheurs, webhooks d’alerte)

Public : exploitants de batchs nocturnes sans plateforme lourde ni équipe dédiée. Apport : matrice, freins, étapes, FAQ timeouts. Voir cron et webhooks backoff, n8n OpenClaw, OpenClaw sur le blog.

Pourquoi un script unique de nuit casse encore sur un hôte loué

1. Délais implicites. Un seul processus traverse souvent les limites proxy inverse, SSH ou TLS et s’interrompt après des heures sans signal clair pour l’équipe.
2. Coût caché des reprises. Sans checkpoint, une panne tardive oblige à rejouer des volumes entiers, accélère l’usure du SSD et gonfle la facture réseau.
3. Signal faible pour l’astreinte. Les courriels cron passent inaperçus ; personne ne voit le blocage avant les tableaux de bord du matin ni les écarts métier.

Matrice décisionnelle : Apache Airflow complet sur un Mini versus chaîne HTTP OpenClaw

Objectif : un plan de contrôle sobre sur un Mini colocalisé, auditable pour des tâches longues récurrentes.

Installation et démon OpenClaw

Installez selon l’hébergeur ; exécutez sous launchd ou utilisateur dédié pour survivre aux redémarrages système. Écoute localhost d’abord ; proxy ou tunnel SSH si opérateurs distants. curl de santé dans le même plist que le batch nocturne ; stdout et stderr vers fichiers rotatifs. Surveillez inodes et espace comme sur tout hôte 7×24 — repères Node Exporter.

1. Binaire et variables documentées OK.
2. Service launchd avec RunAtLoad et redémarrage raisonnable.
3. curl santé avant fenêtre de nuit.
4. Journaux par run ou segment.
5. Arrêt d’urgence documenté sans impacter d’autres charges sur le Mini.

Segmentation des tâches et checkpoints idempotents

Coupez en ETL avec budget temps clair pour chaque boîte du graphe logique. État dans SQLite ou JSON par run ; reprise partielle seulement sans doubler les commits. Hash d’entrée pour détecter la dérive avant entrepôt ou API payante.

• Noms de segment stables dans logs et alertes.
• Pas d’écriture distante avant lecture checkpoint.
• Dernier état OK conservé pour astreinte.

Ordre des déclenchements HTTP

cron ou launchd lance A ; enveloppe shell propage l’en-tête RUN_ID sur chaque POST aval. Après 200 et JSON valide, enchaîner B puis C avec timeouts par étape au lieu d’un délai global unique. Convergence : n8n ou petite file pour fusionner branches parallèles sans scheduler lourd.

Webhooks d’alerte

JSON vers Slack, Discord ou OpenClaw entrant si code non nul ou 5xx. Champs : run, segment, durée, extrait log. Cooldown obligatoire : escalade après deux échecs du même segment dans la fenêtre nocturne pour limiter le bruit.

FAQ : délais et timeouts courants

curl coupe mon extract ?

Découper ou worker avec statut HTTP lu par le déclencheur.

SSH inactif pendant la chaîne ?

Keep-alive ; lancer depuis launchd sur le Mini, pas un laptop tunnelé.

Compte pour louer ?

Souvent non : forfaits, achat sans compte, aide SSH/VNC.

Checklist reproductible avant la première nuit

1. DAG papier : nom et durée max par nœud.
2. Checkpoints avant écritures payantes.
3. launchd avec ThrottleInterval anti-rafale reboot.
4. Succès → POST local suivant, en-têtes partagés.
5. Échec → webhook ; schéma JSON testé de jour.
6. Dry-run sur sous-jeu avant prod.

Repères citables

• Un segment = une unité qui tient dans un timeout client explicite et un fichier journal dédié, traçable de bout en bout.
• RUN_ID : identifiant unique par nuit pour corréler alertes, checkpoints et journaux sans ambiguïté.
• Double échec : règle d’escalade simple avant bruit excessif dans le canal d’astreinte et la fatigue des équipes.