Planification (cron)

Le canal schedule déclenche un pipeline selon un calendrier défini. C'est l'équivalent d'un cron, mais configuré dans l'éditeur du modèle et journalisé comme tous les autres exchanges.

Pourquoi ce canal

Tous les pipelines ne sont pas réactifs (à un email, un appel, un webhook). Beaucoup sont proactifs : rapport quotidien, relance hebdomadaire, vérification horaire d'un système externe. C'est ce que couvre le canal schedule.

Configuration

1. Dans l'éditeur du modèle, configurez le nœud Start avec un récepteur Déclencheur planifié.
2. Choisissez :
   • Calendrier — composez-le visuellement avec le CronBuilder (quotidien, hebdomadaire ou mensuel, à l'heure de votre choix), ou passez en mode avancé pour saisir une expression cron classique à 5 champs (0 8 * * 1-5 = 8h en semaine). Aucune connaissance de la syntaxe cron requise.
   • Fuseau horaire — nom IANA (Europe/Paris, UTC…) dans lequel le calendrier est interprété. Par défaut : UTC.
   • Objectif — une étiquette libre (ex. briefing_hebdo, alerte_impayes) passée au pipeline pour le router.
   • Si un tick est manqué — la politique de rattrapage (catchup), voir plus bas. Par défaut : tout rattraper.

Ce que le pipeline reçoit

À chaque déclenchement, un exchange est créé avec :

• schedule.objectif — l'étiquette d'objectif configurée (pour le routage multi-déclencheurs)
• schedule.cron — l'expression cron configurée
• schedule.occurrence — l'horodatage prévu (UTC)
• schedule.fired_at — l'horodatage réel du déclenchement (UTC)
• schedule.catchup — true si ce déclenchement est un rattrapage

Tolérance & rattrapage

Chaque déclenchement est mis en file durable avant d'être exécuté : un redémarrage pendant l'exécution ne le perd pas.

Si betool est indisponible au moment d'un déclenchement (maintenance, incident), le sort des occurrences manquées dépend du réglage Si un tick est manqué (catchup) du déclencheur :

Une occurrence rattrapée est exécutée une seule fois et marquée schedule.catchup = true, ce qui permet au pipeline de signaler un rapport produit en retard. Une occurrence volontairement sautée (run_once, skip) l'est définitivement : elle ne ressort pas plus tard, même si vous changez ensuite de politique.

Au-delà de la fenêtre de 24 heures, rien n'est rejoué : mieux vaut un rapport manquant qu'une avalanche de rapports tardifs. Un déclencheur qui ne s'est encore jamais exécuté n'a rien à rattraper.

Cas d'usage typiques

• Rapport quotidien 8h — agent qui interroge plusieurs systèmes, synthétise et envoie un brief par email.
• Sync horaire — pipeline qui pull les nouveaux items d'un système externe, les passe à un agent classifier, et pousse les résultats dans votre CRM.
• Vérification hebdomadaire — agent qui audite l'état d'une infrastructure et signale les écarts.
• Relance J+7 — sur les leads soumis il y a une semaine et toujours sans réponse.

Bonnes pratiques

• Évitez les démarrages de minute pile — beaucoup de systèmes pulsent à 0 * * * *. Préférez 7 * * * * pour répartir la charge.
• Loggez les tâches qui n'ont rien à faire. Une tâche qui s'exécute mais ne fait rien (parce qu'aucun item à traiter) doit le tracer explicitement. Sinon, vous ne saurez pas distinguer « tout va bien » de « la tâche ne s'exécute plus ».