Quand utiliser un autre planificateur à la place de crontab
crontab a été pendant des décennies la norme de la planification sous Unix, mais il existe aujourd'hui de nombreuses alternatives à choisir selon l'objectif. L'essentiel à retenir : l'expression de planning elle-même utilise le plus souvent la même syntaxe cron à 5 champs. Quelle que soit la plateforme, vous pouvez donc d'abord valider l'expression avec cet outil.
Les timers systemd sont l'alternative par défaut sur les Linux récents. Contrairement à cron, ils permettent de consulter directement les journaux d'exécution avec journalctl, de gérer les dépendances avec les unités de service, et prennent en charge l'option Persistent=true qui exécute au démarrage les tâches manquées pendant que le système était éteint. En revanche, la notation temporelle n'est pas la syntaxe cron mais le format OnCalendar, qu'il faut apprendre à part.
Les planificateurs cloud et serverless sont populaires en environnement managé. AWS EventBridge Scheduler, GCP Cloud Scheduler, Vercel Cron, Cloudflare Cron Triggers, etc., acceptent pour la plupart directement les expressions cron standard sans que vous ayez à gérer vous-même un serveur. Vérifiez toutefois impérativement que le fuseau horaire de référence de l'exécution est généralement l'UTC.
Le planning des pipelines CI est également très utilisé. Le on: schedule de GitHub Actions ou les plannings de pipeline de GitLab CI conviennent bien pour exécuter périodiquement des tâches liées au dépôt (tests, déploiements, rapports). Ils utilisent la syntaxe cron mais en UTC, et l'exécution peut être retardée de quelques minutes à cause de l'attente d'un runner.
Les critères de choix sont simples. Pour une tâche tournant sur un seul serveur Linux, cron ou un timer systemd ; pour un fonctionnement managé sans serveur, un planificateur cloud ; pour une tâche liée à un dépôt, un planning CI est le plus naturel. Dans tous les cas, vérifiez les prochaines exécutions de la chaîne de planning avec cet interpréteur avant de la coller.