Analyser une expression cron _

Qu’est-ce qu’une expression cron ?

Une expression cron est une chaîne de planification compacte qui indique à un planificateur de tâches exactement quand déclencher une tâche. Le format est né en 1975 dans le démon Unix V7 cron et a très peu changé depuis — la même grammaire à cinq champs se retrouve aujourd’hui dans Kubernetes CronJobs, AWS EventBridge, les workflows GitHub Actions, Google Cloud Scheduler, GitLab CI, les pipelines Jenkins, et le binaire crontab encore livré avec chaque distribution Linux. Cette grammaire condense beaucoup de sens en une treizaine de caractères, c’est pourquoi un analyseur qui la convertit en français clair fait la différence entre un déploiement serein et un rollback à 3h du matin.

Comment fonctionne une expression cron ?

Une expression cron standard comporte cinq champs séparés par des espaces qui définissent ensemble un planning récurrent. Le moteur compare l’horloge courante à l’expression chaque minute et déclenche la tâche quand les cinq champs correspondent. Les champs, de gauche à droite :

1. Minute (0–59). La minute dans l’heure où la tâche s’exécute. 0 signifie pile à l’heure, 30 à la demie, */5 toutes les cinq minutes (00, 05, 10, …), et 15,45 au quart et aux trois quarts.
2. Heure (0–23). L’heure de la journée sur l’horloge 24h. 0 est minuit, 9 est 9h, 17 est 17h. Les plages (9-17 pour les heures ouvrées) et les valeurs de pas (*/2 pour toutes les deux heures) fonctionnent de la même façon que pour les minutes.
3. Jour du mois (1–31). Quel jour du calendrier exécuter. 1 signifie le 1er du mois, * chaque jour, 1,15 le 1er et le 15. Attention avec 31 — il saute silencieusement les mois qui n’ont pas de 31e jour.
4. Mois (1–12 ou JAN–DEC). Quels mois exécuter. * signifie chaque mois, 1,7 janvier et juillet, 1-3 le premier trimestre seulement. Les noms de mois à trois lettres ne tiennent pas compte de la casse dans la plupart des implémentations.
5. Jour de la semaine (0–7, où 0 et 7 signifient tous les deux dimanche). Restreint le déclenchement à des jours spécifiques. 1-5 du lundi au vendredi, 0,6 le week-end, MON-FRI fonctionne dans la plupart des parseurs. Quand le jour du mois et le jour de la semaine sont tous deux définis, le cron classique se déclenche sur l’une ou l’autre correspondance (OR logique), ce qui surprend toujours.

Pourquoi utiliser un analyseur d’expressions cron ?

• Repérez la mauvaise interprétation silencieuse avant le déploiement. L’expression `0 2 */3 * *` se déclenche à 2h du matin tous les trois jours, pas toutes les trois minutes — collez-la ici et vous le verrez en français clair avant qu’elle parte en production.
• La plupart des planificateurs cloud fonctionnent en UTC par défaut. Prévisualiser les dix prochaines exécutions dans votre fuseau horaire local révèle le décalage d’heure dû à l’heure d’été avant qu’il ne réveille quelqu’un à 3h du matin.
• Les raccourcis `@daily`, `@weekly` et `@monthly` sont pratiques mais ambigus. L’analyseur affiche la forme à cinq champs sous-jacente pour que vous sachiez exactement ce qui a été planifié.
• Le constructeur champ par champ vous permet de composer un planning colonne par colonne et de voir la description en langage clair se mettre à jour en direct, ce qui est beaucoup plus rapide que de relire la page de manuel cron pour la dixième fois.

Où les expressions cron sont-elles utilisées ?

La syntaxe cron apparaît partout où une tâche doit se répéter selon une horloge. Trois des surfaces les plus courantes, avec le piège exact dont chacune est connue :

• Plannings de sauvegarde. L’entrée classique `crontab -e` qui exporte une base de données vers S3 à 2h du matin quotidiennement, ou fait tourner une archive `pg_dump` le 1er de chaque mois. Une ligne comme `0 2 * * * /usr/local/bin/backup.sh` a été déployée sur plus de serveurs Linux qu’aucune autre ligne cron de l’histoire. Soignez la minute et l’heure, redirigez stderr quelque part de durable, et vous remplacez une checklist manuelle par un script autonome.
• Déclencheurs `schedule` GitHub Actions. La clé `on.schedule.cron` dans `.github/workflows/*.yml` accepte le cron standard à cinq champs, mais la tâche s’exécute toujours en UTC et GitHub ignorera silencieusement une exécution si la file de runners est occupée. Schéma courant : `cron: '0 9 * * 1-5'` pour envoyer un résumé du lundi au vendredi à 9h UTC. Prévisualisez-le ici dans votre fuseau local pour éviter de promettre un résumé à 9h Paris qui arrive en réalité à 10h en heure d’été.
• AWS EventBridge Scheduler. Les expressions cron EventBridge ajoutent un sixième champ pour l’année et exigent `?` à la place de `*` dans le champ jour du mois ou jour de la semaine — `cron(0 9 ? * MON-FRI *)` est la traduction EventBridge du classique 9h les jours ouvrés. Utilisé pour les invocations Lambda planifiées, les exécutions de tâches ECS et les démarrages de machines d’état Step Functions ; le désalignement avec la syntaxe cron classique est la principale source d’erreurs `ValidationException` dans les déploiements CloudFormation.

À quoi ressemble une vraie expression cron ?

Prenons 0 9 * * 1-5 — se déclenche à 9h00, tous les jours ouvrés. En lisant les champs de gauche à droite : 0 est la minute zéro de l’heure, 9 est 9h sur l’horloge 24h, * sur le jour du mois signifie chaque jour du calendrier, * sur le mois signifie chaque mois, et 1-5 sur le jour de la semaine restreint le déclenchement du lundi au vendredi (où 1 = lundi dans la numérotation cron standard). Collez cela dans le champ ci-dessus et l’analyseur confirme À 09:00, du lundi au vendredi avec les dix prochaines dates rendues dans la zone IANA sélectionnée. La même intention en syntaxe AWS EventBridge est cron(0 9 ? * MON-FRI *) — notez le champ année à la fin et le ? où le cron standard utiliserait *. La même intention en expression Quartz (six champs avec les secondes en tête) est 0 0 9 ? * MON-FRI. Trois plateformes différentes, trois formes de surface différentes, un seul planning sous-jacent.

Les expressions cron sont impitoyables sur un seul point : une faute de frappe produit un planning syntaxiquement valide qui se déclenche au mauvais moment, sans aucune erreur à détecter lors de la revue de code. Lire `0 0 1 * *` et savoir qu’il s’exécute à minuit le 1er de chaque mois, pas le 1er janvier, demande de la pratique. L’analyseur ci-dessus transforme cette pratique en une vérification de dix secondes — collez l’expression, lisez le français, parcourez les dix prochaines exécutions dans votre fuseau local, et poussez le YAML en sachant que la ligne cron fait vraiment ce que dit le message de commit.

Quelle est la différence entre le cron à 5 champs et à 6 champs ?

Le cron à cinq champs est la grammaire Unix classique avec une résolution à la minute. Le cron à six champs ajoute une colonne de secondes en tête pour la planification sous-minute — utilisé par Quartz et `@Scheduled` de Spring. AWS EventBridge utilise aussi six champs, mais sa colonne supplémentaire est une année en queue, pas les secondes.

Que signifient @hourly, @daily et @weekly ?

Alias Vixie-cron introduits en 1987. @hourly = 0 * * * *, @daily = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. @reboot se déclenche une fois au démarrage. GitHub Actions et EventBridge rejettent ces alias.

Le dimanche est-il le jour 0 ou le jour 7 dans cron ?

Les deux, dans le cron Vixie classique — 0 et 7 sont acceptés pour que les plages comme 5-7 se lisent naturellement comme vendredi-dimanche. Le lundi est toujours 1, le samedi toujours 6. Quartz et AWS EventBridge utilisent une convention différente : 1-7 avec le dimanche comme 1. Vérifiez la documentation de la plateforme avant de supposer.

Comment cron gère-t-il le changement d’heure ?

Cela dépend du fuseau horaire du moteur. En UTC (la valeur par défaut sur EventBridge, Kubernetes et GitHub Actions), le changement d’heure n’existe pas. Dans un fuseau horaire local avec heure d’été, le cron Vixie classique saute les tâches pendant le passage à l’heure d’été et les exécute deux fois lors du retour à l’heure standard ; les minuteries systemd se déclenchent exactement une fois.