Cron est le plus ancien ordonnanceur de tâches informatiques et l’un des plus répandus : la version originale d’Unix date de 1975 et sa syntaxe d’expression a été reprise presque sans changement par les systèmes modernes, des crontabs Unix aux CronJobs Kubernetes, en passant par les ordonnanceurs cloud d’AWS, GCP et Azure. Malgré cette omniprésence, les expressions cron sont réputées faciles à mal écrire ; un seul caractère erroné peut transformer une tâche quotidienne en tâche horaire et mettre un système de production hors service. Les sections suivantes présentent la structure à 5 champs, les caractères spéciaux qui l’étendent et les pièges pratiques qui surprennent même les ingénieurs expérimentés.
Structure à 5 champs et rôle de chacun
Une expression cron standard comporte exactement 5 champs séparés par des espaces, dans un ordre fixe : minute, heure, jour du mois, mois, jour de la semaine. Chaque champ accepte un nombre dans sa plage valide (minute 0–59, heure 0–23, jour du mois 1–31, mois 1–12, jour de la semaine 0–6 avec 0 = dimanche), le joker `*` qui signifie « toute valeur », ou l’une des syntaxes spéciales présentées dans la section suivante. Les champs vont du plus précis au plus général : la minute est la valeur la plus précise, tandis que le jour de la semaine décrit les motifs hebdomadaires les plus généraux. Le champ du jour de la semaine peut prêter à confusion : historiquement, les variantes Unix ne s’accordaient pas sur le fait que dimanche corresponde à 0 ou à 7 ; la norme actuelle accepte les deux pour assurer la compatibilité. Les champs du mois et du jour de la semaine acceptent aussi des abréviations de trois lettres (`JAN`–`DEC`, `SUN`–`SAT`), insensibles à la casse et souvent plus lisibles que les valeurs numériques. Lorsque le jour du mois et le jour de la semaine sont tous deux précisés, la plupart des implémentations cron appliquent une logique OU : la tâche s’exécute si l’un ou l’autre correspond, et non uniquement si les deux correspondent. C’est une source fréquente de confusion : `0 0 15 * FRI` s’exécute à minuit le 15 de chaque mois ET chaque vendredi, et pas seulement les vendredis qui tombent le 15.
Caractères spéciaux : pas, plage, liste et jokers
Quatre caractères spéciaux étendent la syntaxe cron de base et répondent à la plupart des besoins de planification réels. L’astérisque `*` est le joker « chaque valeur » : `* * * * *` déclenche la tâche chaque minute, à toute heure et chaque jour. La barre oblique `/` introduit un pas : `*/15` dans le champ des minutes déclenche la tâche aux minutes 0, 15, 30 et 45, soit toutes les 15 minutes. Les pas peuvent être combinés à des plages : `9-17/2` déclenche la tâche à 9, 11, 13, 15 et 17 h. Le trait d’union `-` indique une plage : `9-17` couvre les heures de 9 h à 17 h incluses. La virgule `,` indique une liste : `1.3,5` dans le champ du jour de la semaine désigne lundi, mercredi et vendredi. Les éléments se combinent librement : `0 9.12,17 * * 1-5` déclenche la tâche à 9 h, midi et 17 h les jours de semaine. Certaines implémentations cron proposent d’autres caractères spéciaux. Quartz (utilisé par de nombreuses bibliothèques de planification Java) ajoute `L` (dernier jour du mois ou de la semaine), `W` (jour ouvrable le plus proche) et `#` (nième occurrence d’un jour dans le mois). Jenkins ajoute `H`, qui répartit dans le temps des programmations identiques à l’aide de valeurs hachées afin d’éviter les effets de surcharge simultanée. Cet outil cible le format standard à 5 champs utilisé par le crontab Unix, AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps et des bibliothèques populaires comme node-cron et python-crontab.
Pièges pratiques qui surprennent même les ingénieurs expérimentés
Plusieurs pièges liés à cron provoquent régulièrement des incidents de production, même dans les équipes qui l’utilisent tous les jours. Premièrement, la gestion des fuseaux horaires : par défaut, les expressions cron s’exécutent dans le fuseau local du système. Les changements d’heure de mars et novembre peuvent alors faire manquer une exécution ou en provoquer deux, selon le sens du changement. Configurez si possible les tâches cron en UTC, ou testez explicitement les fins de semaine du changement d’heure avant de déployer des programmations sensibles au temps. Deuxièmement, la logique OU entre le jour du mois et le jour de la semaine, décrite plus haut, surprend les ingénieurs qui s’attendent à une logique ET. Pour exécuter une tâche uniquement les vendredis qui tombent le 15, cron standard ne suffit pas : vous devez appliquer la logique ET dans le code de l’application après le déclenchement. Troisièmement, les années bissextiles posent des cas particuliers : `0 0 29 2 *` ne s’exécute que le 29 février, une fois tous les 4 ans. Il est facile de le tester une fois, puis de croire qu’il ne fonctionne pas. Quatrièmement, `@reboot` et d’autres formes comme `@daily` ou `@hourly` sont prises en charge par de nombreuses implémentations, mais ne sont pas portables ; les ordonnanceurs cloud ne les acceptent généralement pas. Pour assurer la portabilité, utilisez toujours le format explicite à 5 champs. Enfin, les tâches longues peuvent se chevaucher : si une tâche s’exécute toutes les 5 minutes mais dure 7 minutes, deux instances tourneront en même temps. Utilisez un fichier de verrouillage (`flock` sous Linux) ou une coordination au niveau de l’application pour éviter ce chevauchement.