Les expressions cron expliquées : comment lire et écrire des planifications cron

Si vous avez déjà déployé une application web, configuré un pipeline CI/CD ou administré un serveur Linux, vous avez presque certainement rencontré une expression cron. Cinq astérisques vous fixant depuis un fichier de configuration. Une chaîne cryptique comme 0 2 * * 0 enfouie dans un workflow GitHub Actions. Une planification AWS EventBridge que plus personne dans l'équipe ne comprend totalement. Les expressions cron sont partout — et elles sont réellement déroutantes si vous n'avez pas pris le temps d'apprendre le système qui les sous-tend.

Ce guide est la référence que vous devriez mettre en favori. Il couvre tout, de l'histoire de cron et de l'endroit où il apparaît dans l'infrastructure moderne, à chaque caractère spécial, 10 exemples concrets annotés, les erreurs courantes et un tableau de référence complet. À la fin, vous serez capable de lire n'importe quelle expression cron d'un coup d'œil et d'en écrire de nouvelles avec confiance.

Qu'est-ce que cron ?

Cron est un planificateur de tâches basé sur Unix qui exécute des commandes ou des scripts automatiquement à des heures et intervalles spécifiés. Le nom vient de Chronos, la personnification grecque du temps — un choix judicieux pour un outil dont le but entier est l'automatisation basée sur le temps. Le cron d'origine a été introduit dans Unix Version 7 en 1979, écrit par Ken Thompson chez Bell Labs, et il est depuis un pilier des systèmes d'exploitation de type Unix.

Le planificateur fonctionne en lisant des fichiers de configuration appelés crontabs (tables cron) — de simples fichiers texte où chaque ligne définit une tâche planifiée. Un processus démon en arrière-plan (crond) se réveille chaque minute, vérifie tous les crontabs actifs et exécute toute tâche dont la planification correspond à l'heure actuelle. C'est une conception magnifiquement simple qui est restée fondamentalement inchangée depuis plus de quatre décennies.

Où vous rencontrez cron aujourd'hui

Cron n'est pas qu'une relique du passé d'Unix. La syntaxe des expressions cron est la norme de facto pour exprimer des planifications récurrentes à travers la pile logicielle moderne :

• crontab Linux et macOS : le cas d'usage d'origine. Exécutez crontab -e sur n'importe quelle machine Linux ou macOS pour modifier votre planification cron personnelle.
• GitHub Actions : les fichiers de workflow utilisent la syntaxe cron sous le déclencheur schedule:pour exécuter des pipelines CI/CD de façon récurrente.
• AWS EventBridge (anciennement CloudWatch Events) : déclenche des fonctions Lambda, des tâches ECS et d'autres services AWS sur une planification en utilisant une variante cron à 6 champs.
• CronJobs Kubernetes : la ressource CronJob exécute des charges de travail par lots à l'intérieur d'un cluster sur une planification cron.
• Pipelines CI/CD : GitLab CI, CircleCI, Jenkins et Bitbucket Pipelines prennent tous en charge les exécutions planifiées à l'aide d'expressions cron.
• Vercel et Netlify : les deux plateformes prennent en charge les fonctions serverless déclenchées par cron pour des tâches comme l'invalidation de cache, la récupération de données et les builds nocturnes.
• Maintenance de base de données : l'extension pg_cron de PostgreSQL, le planificateur d'événements MySQL, et les services de bases de données managées utilisent la syntaxe cron pour les tâches de nettoyage, d'indexation et de sauvegarde.
• Planificateurs au niveau applicatif : des bibliothèques comme node-cron, APScheduler (Python), Quartz (Java) et Sidekiq (Ruby) utilisent toutes des expressions cron pour définir des tâches d'arrière-plan récurrentes.

En bref : si vous travaillez dans un domaine du développement logiciel ou de l'administration système, les expressions cron sont quelque chose que vous rencontrerez régulièrement. Les apprendre une fois rapporte des dividendes partout.

La structure à cinq champs

Une expression cron standard se compose d'exactement cinq champs séparés par des espaces, chacun représentant une unité de temps. Ensemble, ils définissent quand une tâche doit s'exécuter. Voici la représentation visuelle canonique :

┌───────────── minute (0–59)
│ ┌─────────── heure (0–23)
│ │ ┌───────── jour du mois (1–31)
│ │ │ ┌─────── mois (1–12)
│ │ │ │ ┌───── jour de la semaine (0–7)
│ │ │ │ │
* * * * *

En lisant de gauche à droite : minute, heure, jour du mois, mois, jour de la semaine. Un astérisque (*) dans n'importe quel champ signifie « toute valeur possible pour ce champ ». Ainsi * * * * * signifie « chaque minute de chaque heure de chaque jour » — la planification la plus permissive possible.

Champ 1 : minute (0–59)

Le champ minute contrôle à quelle(s) minute(s) au sein d'une heure une tâche se déclenche. Une valeur de 0 signifie à l'heure pile, 30 signifie à la demi-heure, et * signifie chaque minute. C'est le champ le plus granulaire du cron standard — la plus petite unité de planification est une minute.

Champ 2 : heure (0–23)

Le champ heure utilise le format 24 heures. 0 est minuit, 9 est 9 h, 17 est 17 h, et 23 est 23 h. Il n'y a pas d'AM/PM — tout est au format 24 heures. Rappelez-vous que cron s'exécute toujours dans le fuseau horaire du serveur sauf configuration explicite contraire.

Champ 3 : jour du mois (1–31)

Contrôle quel(s) jour(s) du mois une tâche s'exécute. 1 est le premier, 15 est le quinzième, 31 est le trente et unième. Soyez prudent avec des valeurs comme 31 — dans les mois comptant moins de jours (février, avril, juin, etc.), une tâche planifiée pour le 31 ne s'exécutera tout simplement pas ce mois-là. Certaines implémentations prennent en charge le caractère spécial L pour signifier « dernier jour du mois » quel que soit le nombre de jours du mois.

Champ 4 : mois (1–12)

Le champ mois utilise des valeurs numériques (1 pour janvier jusqu'à 12 pour décembre) ou des abréviations de trois lettres (JAN, FEB, MAR, APR, MAY, JUN,JUL, AUG, SEP, OCT, NOV, DEC) dans la plupart des implémentations. Un astérisque signifie « chaque mois ».

Champ 5 : jour de la semaine (0–7)

Ce champ spécifie quel(s) jour(s) de la semaine la tâche doit s'exécuter. La numérotation ici est une source courante de confusion : 0 et 7 représentent tous deux le dimanche dans la plupart des implémentations cron (une bizarrerie héritée de la conception Unix d'origine). Lundi est 1, mardi est 2, et samedi est 6. Les abréviations de trois lettres (SUN, MON, TUE, WED, THU, FRI,SAT) sont prises en charge dans la plupart des outils cron modernes.

Caractères spéciaux

La véritable puissance des expressions cron vient de six caractères spéciaux qui vous permettent d'exprimer des planifications complexes de façon concise. Les comprendre est la clé de la maîtrise.

* — Joker (toute valeur)

Un astérisque signifie « correspondre à toute valeur possible dans ce champ ». Dans le champ minute, * signifie chaque minute (0 à 59). Dans le champ mois, il signifie chaque mois. C'est la valeur par défaut « je me fiche de ce champ ».

* * * * *    # Runs every single minute, all day, every day

, — Liste (plusieurs valeurs)

Une virgule sépare une liste de valeurs spécifiques. Le champ correspond si l'heure actuelle correspond à n'importe quelle valeur de la liste. C'est ainsi que vous planifiez une tâche pour qu'elle s'exécute à plusieurs heures discrètes sans utiliser de plage.

0 9,13,17 * * *    # Runs at 9:00 AM, 1:00 PM, and 5:00 PM every day
0 0 1,15 * *       # Runs at midnight on the 1st and 15th of every month

- — Plage (de … à)

Un trait d'union définit une plage inclusive de valeurs. Le champ correspond à chaque valeur entre le début et la fin, inclus. C'est idéal pour exprimer des choses comme « pendant les heures de bureau » ou « en semaine ».

0 9-17 * * *      # Runs at the top of every hour from 9 AM through 5 PM
0 0 * * 1-5       # Runs at midnight every Monday through Friday

/ — Pas (toutes les N unités)

Une barre oblique définit une valeur de pas. */5 signifie « toutes les 5 unités à partir du minimum ». Vous pouvez aussi la combiner avec une plage : 0-30/10 signifie « toutes les 10 unités entre 0 et 30 » (c'est-à-dire 0, 10, 20, 30). Les pas font partie des caractères spéciaux les plus couramment utilisés.

*/5 * * * *       # Every 5 minutes (0, 5, 10, 15, ... 55)
*/15 * * * *      # Every 15 minutes (0, 15, 30, 45)
0 */6 * * *       # Every 6 hours (0:00, 6:00, 12:00, 18:00)
0/15 * * * *      # Same as */15 — starts from 0, every 15 minutes

L — Dernier (certaines implémentations uniquement)

Le caractère L est pris en charge dans certaines implémentations cron (notamment Quartz Scheduler en Java et certaines variantes de cron Linux) pour signifier « dernier ». Dans le champ jour du mois, L signifie le dernier jour du mois en cours — qu'il s'agisse du 28, 29, 30 ou 31. Il résout le problème de la planification de tâches de « fin de mois » sans connaître à l'avance la durée du mois.

0 0 L * *         # Midnight on the last day of every month (Quartz/some crons)

? — Aucune valeur spécifique (cron Quartz/Java)

Le point d'interrogation est utilisé dans Quartz Scheduler (Java) et certains autres outils lorsque vous voulez spécifier un jour de la semaine sans aussi spécifier un jour du mois, ou vice versa. Comme il n'a pas de sens logique de spécifier les deux (par exemple « le 15 ET un mercredi »), l'un d'eux doit être réglé sur ? pour indiquer « je m'en fiche ». Le cron Unix standard n'utilise pas ce caractère — vous utilisez * à la place.

0 9 15 * ?        # Quartz: 9 AM on the 15th, day-of-week unspecified
0 9 ? * MON       # Quartz: 9 AM every Monday, day-of-month unspecified

10 exemples concrets de cron

La meilleure façon de consolider votre compréhension est d'étudier de vrais exemples avec le contexte expliquant pourquoi chaque planification a été choisie. Voici dix schémas que vous rencontrerez (et utiliserez) régulièrement.

1. Tous les jours ouvrés à 9 h 00

0 9 * * 1-5

La minute est 0 (heure pile), l'heure est 9 (9 h), le jour du mois et le mois sont des jokers, et le jour de la semaine est 1-5 (du lundi au vendredi). Utilisé pour les rappels de stand-up quotidiens, les e-mails de rapport envoyés au début de la journée de travail, et les tâches de synchronisation de données matinales qui ne devraient pas s'exécuter le week-end.

2. Toutes les 15 minutes

*/15 * * * *

La syntaxe de pas */15 dans le champ minute vous donne des exécutions à 0, 15, 30 et 45 minutes après chaque heure, 24 h/24. Courant pour les pings de vérification d'état, le préchauffage de cache, les nouvelles tentatives de webhooks, et toute tâche de scrutation quasi en temps réel où vous avez besoin de fraîcheur mais où le vrai temps réel est excessif ou indisponible.

3. Tous les jours à minuit

0 0 * * *

Minute 0, heure 0, tout le reste en joker. C'est l'un des schémas cron les plus courants qui existent. Utilisé pour la génération de rapports quotidiens, la rotation des journaux, l'archivage de base de données, le nettoyage des fichiers temporaires, l'envoi d'e-mails de synthèse quotidiens, et toute tâche « une fois par jour » qui devrait s'exécuter en dehors des heures de bureau.

4. Le premier jour de chaque mois à minuit

0 0 1 * *

Le jour du mois est 1, tout le reste est en joker (sauf la minute/l'heure fixes). Cela s'exécute le 1er janvier, le 1er février, le 1er mars, et ainsi de suite. La planification de prédilection pour la génération de factures mensuelles, les déclencheurs de cycle de facturation, les renouvellements d'abonnements SaaS et les bilans analytiques mensuels.

5. Chaque dimanche à 2 h 00

0 2 * * 0

Le jour de la semaine 0 est le dimanche, et l'heure 2 est 2 h — un moment où le trafic est généralement au plus bas. Utilisé pour les sauvegardes complètes hebdomadaires de base de données, la régénération de sitemap, la réindexation de contenu pour la recherche, et les lourdes tâches de traitement par lots qui impacteraient les performances en semaine.

6. En semaine à 8 h 30, 12 h 30 et 17 h 30

30 8,12,17 * * 1-5

Ceci combine une liste dans le champ heure avec une plage dans le champ jour de la semaine. La minute 30signifie qu'elle se déclenche à la demi-heure. Utilisé pour les lots de notifications planifiées (notifications push, synthèses par e-mail), les tâches de synchronisation de données trois fois par jour, et tout flux de travail où vous voulez des points de contact réguliers tout au long de la journée de travail sans solliciter chaque heure.

7. Le 1er janvier à minuit

0 0 1 1 *

Le jour du mois 1 et le mois 1 (janvier) fixent ensemble cela au jour de l'An. Utilisé pour les tâches annuelles comme les renouvellements d'abonnements annuels, l'archivage des données de l'année précédente, la génération de rapports de conformité annuels, et la réinitialisation des quotas ou compteurs annuels dans les applications.

8. Toutes les 5 minutes pendant les heures de bureau en semaine

*/5 9-17 * * 1-5

Une expression composée combinant un pas (*/5), une plage d'heures (9-17) et une plage de jours de la semaine (1-5). Cela vous donne une surveillance ou une scrutation agressive — toutes les 5 minutes de 9 h à 17 h du lundi au vendredi — tout en restant silencieux la nuit et le week-end pour économiser des ressources et éviter la fatigue d'alerte.

9. Toutes les 6 heures

0 */6 * * *

Le pas dans le champ heure (*/6) donne quatre exécutions régulièrement espacées par jour : minuit, 6 h, midi et 18 h. Utilisé pour la synchronisation de données entre systèmes, le rafraîchissement de jetons d'API à longue durée de vie ou d'identifiants OAuth avant leur expiration, et l'invalidation périodique de cache pour du contenu qui change quelques fois par jour mais qui n'a pas besoin d'une fraîcheur à la minute près.

10. Le 15 et le dernier jour de chaque mois

0 0 15,L * *

Une liste à virgule dans le champ jour du mois combinant une date fixe (15) et le raccourci du dernier jour (L). C'est la planification classique de paie bimensuelle — des périodes de paie qui se terminent le 15 et le dernier jour du mois. Notez que L nécessite une implémentation qui le prend en charge (Quartz, certains crons Linux) ; le crontab standard ne prend pas en charge L.

Erreurs courantes et pièges

Les expressions cron présentent plusieurs pièges bien connus qui provoquent des incidents en production. Les comprendre à l'avance vous épargnera une douloureuse session de débogage à 2 h du matin.

La numérotation des jours de la semaine n'est pas universelle

La plupart des implémentations cron Unix traitent à la fois 0 et 7 comme dimanche. Mais certains outils (dont certaines bibliothèques au niveau applicatif) commencent la semaine le lundi, faisant de 1 = lundi et 7 = dimanche. Vérifiez toujours la convention de numérotation de l'outil spécifique que vous utilisez, et préférez utiliser des abréviations de trois lettres (MON, TUE, etc.) lorsque l'implémentation les prend en charge afin d'éliminer toute ambiguïté.

Cron s'exécute dans le fuseau horaire du serveur

C'est probablement la source la plus courante de bogues cron en production. 0 9 * * * signifie 9 h dans le fuseau horaire de la machine exécutant la tâche — qui peut être UTC, US/Eastern, ou tout autre. Documentez toujours l'hypothèse de fuseau horaire dans un commentaire à côté de l'expression cron. Pour les planificateurs basés sur le cloud, configurez explicitement le fuseau horaire si la plateforme le prend en charge.

# Good practice: always document the timezone
# Runs at 9 AM US/Eastern (UTC-5 or UTC-4 during DST)
0 14 * * 1-5   # 9 AM ET expressed in UTC

Le cron de GitHub Actions s'exécute toujours en UTC

GitHub Actions utilise la syntaxe cron standard à 5 champs sous la clé on: schedule:, mais le planificateur fonctionne toujours en UTC — il n'y a aucune option de configuration de fuseau horaire. Si vous voulez qu'une tâche s'exécute à 9 h heure de l'Est, vous devez la planifier à 0 14 * * * (UTC). Notez également que les workflows planifiés de GitHub Actions peuvent s'exécuter jusqu'à 15 minutes en retard pendant les périodes de forte demande.

La syntaxe de pas s'applique à son champ, pas aux minutes

Une mauvaise lecture courante : */5 dans le champ heure signifie toutes les 5 heures — pas toutes les 5 minutes. Le pas s'applique toujours à l'unité du champ dans lequel il se trouve. */5 dans le champ minute est toutes les 5 minutes ; dans le champ heure, toutes les 5 heures ; dans le champ mois, tous les 5 mois.

Les tâches qui durent plus longtemps que leur intervalle peuvent se chevaucher

Cron est un planificateur « lance et oublie ». Si vous planifiez une tâche toutes les 5 minutes et qu'une instance de la tâche prend 7 minutes à se terminer, une deuxième instance démarrera pendant que la première est encore en cours d'exécution. Cela peut provoquer des conditions de concurrence, des traitements en double et de la corruption de données. Utilisez un verrou de fichier ou un verrou consultatif dans votre base de données pour empêcher l'exécution concurrente de la même tâche.

Les champs manquants et les jokers ne sont pas toujours équivalents

Dans certaines implémentations cron étendues (en particulier Quartz), omettre un champ et utiliser *sont traités différemment. Utilisez toujours tous les champs requis de façon explicite et ne comptez jamais sur les valeurs par défaut pour les planifications de production critiques.

Extensions non standard : le cron à 6 champs

Le cron Unix standard a cinq champs, avec la minute comme granularité la plus fine. Plusieurs systèmes étendent cela avec des champs supplémentaires :

Champ secondes (ajouté au début)

De nombreux planificateurs au niveau applicatif (node-cron, Quartz, Spring Scheduler) ajoutent un champ secondes au début, donnant 6 champs. Cela permet une planification infra-minute jusqu'à la seconde. Les champs sont : seconde minute heure jour-du-mois mois jour-de-la-semaine.

# 6-field cron with seconds prepended (Quartz / node-cron)
0 */5 * * * *    # Every 5 minutes (second=0, minute=*/5, ...)
30 0 9 * * 1-5   # Weekdays at 9:00:30 AM

AWS EventBridge (6 champs avec année)

AWS EventBridge utilise un format à 6 champs où un champ année est ajouté à la fin :minute heure jour-du-mois mois jour-de-la-semaine année. Il exige également l'utilisation de ?pour le jour du mois ou le jour de la semaine (jamais les deux en jokers en même temps). AWS EventBridge ne prend pas en charge la syntaxe de pas */ de la même manière que le cron Unix.

# AWS EventBridge cron format (6 fields, year at end)
cron(0 9 ? * MON-FRI *)    # Weekdays at 9 AM UTC, any year
cron(0 0 1 * ? *)           # First day of every month at midnight

Comment utiliser l'Analyseur cron de BrowseryTools

Écrire une expression cron de toutes pièces est une compétence — vérifier que vous l'avez écrite correctement en est une autre. L'Analyseur cron de BrowseryTools rend trivial de vérifier n'importe quelle expression avant qu'elle n'approche de la production.

Collez n'importe quelle expression cron à 5 champs (ou 6 champs) dans l'outil et obtenez instantanément :

• Une description lisible par un humain de la planification (« Tous les jours ouvrés à 9 h 00 ») pour que vous puissiez vérifier d'un coup d'œil que votre intention correspond à votre expression.
• Les 5 à 10 prochaines heures d'exécution planifiées listées explicitement, pour que vous puissiez voir exactement quand la tâche se déclenchera et confirmer qu'il n'y a aucune surprise.
• Un retour instantané sur une syntaxe invalide — utile si vous avez une faute de frappe ou si vous travaillez avec une expression écrite par quelqu'un d'autre.

Tout s'exécute entièrement dans votre navigateur — aucune expression n'est envoyée à un serveur. C'est le moyen le plus rapide de vérifier la cohérence d'une planification avant de la déployer sur GitHub Actions, Kubernetes ou toute autre plateforme.

Tableau de référence des expressions cron

Utilisez ce tableau comme référence rapide. Mettez cette page en favori et revenez-y chaque fois que vous devez rechercher un schéma ou vérifier ce que signifie une expression.

Validez vos expressions cron avant de déployer

Les expressions cron sont compactes et puissantes, mais leur concision signifie qu'une seule faute de frappe peut produire silencieusement une planification complètement différente. Une tâche que vous vouliez exécuter mensuellement pourrait s'exécuter quotidiennement. Une sauvegarde que vous comptiez déclencher chaque dimanche pourrait ne jamais s'exécuter du tout. Le coût d'une mauvaise planification en production peut aller d'un rapport manqué à une tâche de facturation qui se déclenche des centaines de fois.

L'habitude de deux minutes consistant à coller votre expression dans un validateur et à examiner les prochaines heures d'exécution planifiées avant de déployer est l'une des pratiques à plus forte valeur en DevOps et en ingénierie backend. Elle attrape les erreurs avant qu'elles ne deviennent des incidents.