Une expression cron est une façon compacte de décrire l'horaire d'exécution récurrente d'une tâche, utilisée dans les systèmes de type Unix depuis les années 1970. Cinq champs séparés par des espaces peuvent exprimer pratiquement n'importe quel horaire régulier.
Les cinq champs de l'expression
Une expression cron standard se présente sous la forme minute heure jour-du-mois mois jour-de-la-semaine. Par exemple, 30 14 * * 1 signifie « à 14h30 chaque lundi » — les astérisques signifient « n'importe quelle valeur » pour le jour du mois et le mois.
La signification des barres obliques et des virgules
Une barre oblique après un astérisque, comme dans */15 * * * *, signifie « toutes les 15 unités » — dans ce cas, toutes les 15 minutes. Une virgule permet d'énumérer plusieurs valeurs précises ; par exemple, 0 9,18 * * * exécute la tâche deux fois par jour : à 9h00 et à 18h00.
Pourquoi le champ « jour de la semaine » prête le plus à confusion
Dans le cron standard, les champs « jour du mois » et « jour de la semaine » peuvent tous deux être renseignés en même temps sans être un astérisque — dans ce cas, la tâche s'exécute si l'une des deux conditions est remplie (un OU logique, pas un ET), ce qui contredit l'attente intuitive de la plupart des gens.
La même syntaxe, du crontab au CronJob Kubernetes
Un demi-siècle après ses débuts sous Unix, cette même syntaxe à cinq champs est reprise telle quelle par l'objet CronJob de Kubernetes, largement utilisé par les entreprises françaises hébergeant leurs services chez des fournisseurs cloud comme OVHcloud. Une planification comme 0 3 * * * dans un manifeste CronJob signifie exactement la même chose que dans un crontab Unix des années 1980.
Pourquoi c'est utile
- Déchiffrer l'expression cron de quelqu'un d'autre dans une configuration serveur ou un pipeline CI/CD.
- Vérifier qu'un horaire écrit est correct avant de le déployer en production.
- Planifier le moment exact des prochaines exécutions d'une tâche.
Le changement d'heure d'été/hiver et cron
Si le planificateur fonctionne dans un fuseau avec passage à l'heure d'été/hiver, une tâche prévue à une heure inexistante (par exemple 2h30 la nuit où les horloges avancent) peut ne pas s'exécuter ce jour-là, tandis qu'une tâche prévue à une heure qui se répète lors du recul des horloges peut s'exécuter deux fois. C'est pourquoi, pour les tâches critiques, on choisit souvent un horaire en dehors de la fenêtre de transition habituelle (par exemple minuit ou 3-4 heures du matin), ou on fixe explicitement le fuseau UTC.