Les expressions cron, expliquées : le langage des planificateurs pour voyager dans le temps

En une phrase

Une expression cron est une chaîne de caractères compacte qui définit un planning récurrent, disant en gros à un ordinateur quand exécuter une tâche automatisée.

Le problème que ça résout

À l'âge sombre du numérique (les années 70), si vous vouliez qu'un ordinateur fasse quelque chose automatiquement — disons, nettoyer les fichiers temporaires à minuit — il fallait être créatif. Vous pouviez écrire un script bancal qui tournait en boucle, vérifiait l'heure, puis se mettait en veille pendant un moment. C'était bordélique, inefficace et sujet aux pannes.

Puis est arrivé cron, un daemon (un processus d'arrière-plan) né dans les couloirs des Bell Labs aux débuts d'Unix. Le nom est un clin d'œil à Chronos, la personnification grecque du temps, ce qui est à peu près le summum de la geekerie. Le boulot de cron était simple mais révolutionnaire : lire une liste de commandes et les heures auxquelles elles devaient s'exécuter, puis les lancer. C'était un système « configure-le et n'y pense plus » pour l'automatisation des tâches.

Pour dire à cron quand lancer les choses, il lui fallait un langage. Pas un langage verbeux, de type anglais, mais quelque chose qu'un ordinateur pourrait analyser instantanément. Ce langage, c'est l'expression cron. Il résout le problème fondamental de la description de n'importe quel planning récurrent imaginable — « tous les lundis à 9h », « le 1er et le 15 de chaque mois », « toutes les 10 minutes » — d'une manière standardisée et prévisible. Sans ça, chaque développeur réinventerait la roue de la planification, et votre serveur serait un bazar chaotique de commandes sleep() bricolées à la main.

Comment ça marche sous le capot

Pour les non-initiés, une expression cron ressemble à une chaîne de charabia, un truc comme */15 9-17 * * 1-5. Mais ce n'est pas de la magie ; c'est un mini-langage très structuré. Une fois que vous avez appris la syntaxe, vous pouvez lire et écrire des plannings comme un pro.

Les cinq champs de l'Apocalypse (et leurs potes)

Une expression cron standard est composée de cinq champs, séparés par des espaces. Chaque champ représente une unité de temps. Imaginez ça comme un ensemble de cinq cadrans que vous tournez pour aligner le bon moment.

Champ	Valeurs autorisées	Caractères spéciaux autorisés
Minute	0-59	`* , - /`
Heure	0-23	`* , - /`
Jour du mois	1-31	`* , - / ? L W`
Mois	1-12 ou JAN-DEC	`* , - /`
Jour de la semaine	0-7 ou SUN-SAT	`* , - / ? L #`

Certaines implémentations modernes de cron ajoutent un sixième champ pour l'année (1970-2099) ou même un premier champ pour les secondes (0-59), mais le format classique à cinq champs est le plus courant.

Une remarque sur le jour de la semaine : 0 et 7 sont souvent tous deux acceptés pour le dimanche. S'en tenir à une convention (comme 0=Dim, 6=Sam) est une bonne idée.

Caractères spéciaux : le langage secret

La vraie puissance des expressions cron vient d'une poignée de caractères spéciaux qui modifient les nombres.

* (Le « tous ») : C'est le joker. Un astérisque dans le champ Heure signifie « à chaque heure de la journée ». Un astérisque dans chaque champ (* * * * *) signifie « chaque minute de chaque heure de chaque jour de chaque mois... » Vous avez compris l'idée.
, (Le « et ») : La virgule sert de séparateur de liste. 1,15 dans le champ Jour du mois signifie « le 1er et le 15 du mois ».
- (Le « de... à ») : Le tiret définit une plage. 9-17 dans le champ Heure signifie « chaque heure de 9h à 17h incluses ».
/ (Le « pas ») : Le slash est utilisé pour spécifier des incréments. */10 dans le champ Minute signifie « toutes les 10 minutes ». Vous pouvez aussi le combiner avec une plage : 0-30/5 signifie « toutes les 5 minutes pendant les 30 premières minutes de l'heure » (donc à :00, :05, :10, :15, :20, :25, :30).
? (Le « peu importe ») : Celui-ci est délicat mais important. Vous ne pouvez pas toujours spécifier à la fois un Jour du mois et un Jour de la semaine car ils peuvent entrer en conflit. Que se passe-t-il si vous dites « lancer le 13 du mois et un vendredi », mais que le 13 tombe un mercredi ? Le ? résout ce problème en disant : « J'ai spécifié l'un de ces champs, alors ignore l'autre ». Vous définiriez le planning sur * * 13 * ? (lancer le 13, peu importe le jour de la semaine) ou * * ? * 5 (lancer tous les vendredis, peu importe le jour du mois).
L (Le « dernier ») : L dans le champ Jour du mois signifie « le dernier jour du mois » (donc le 31 janvier, le 28/29 février, etc.). Dans le champ Jour de la semaine, il signifie « le dernier X du mois ». Par exemple, 5L signifie « le dernier vendredi du mois ».
W (Le « jour de semaine ») : 15W dans le champ Jour du mois signifie « le jour de semaine le plus proche du 15 du mois ». Si le 15 est un samedi, la tâche s'exécutera le vendredi 14. Si le 15 est un dimanche, elle s'exécutera le lundi 16.
# (Le « nième ») : C'est pour trouver des choses comme « le troisième vendredi du mois ». L'expression pour cela serait * * ? * 5#3.

Assemblons le tout

Déchiffrons quelques expressions courantes :

# S'exécute chaque nuit à minuit
0 0 * * *

0 dans le champ minute : à la minute zéro (le début de l'heure).
0 dans le champ heure : à l'heure zéro (minuit).
* * * dans les autres champs : chaque jour de chaque mois de chaque semaine.

# S'exécute à 8h30 chaque jour de la semaine (Lun-Ven)
30 8 * * 1-5

30 dans le champ minute : à 30 minutes après l'heure.
8 dans le champ heure : à 8h.
* * pour le jour du mois et le mois : peu importe.
1-5 pour le jour de la semaine : du lundi au vendredi.

# S'exécute toutes les 15 minutes pendant les heures de bureau (9h-17h) les jours de semaine
*/15 9-17 * * 1-5

*/15 : toutes les 15 minutes.
9-17 : pour les heures 9, 10, 11, 12, 13, 14, 15, 16 et 17.
1-5 : du lundi au vendredi.

Histoires vécues

Le cas de la sauvegarde de minuit

La base de données d'une startup grandissait vite. L'admin sys principal savait qu'il fallait des sauvegardes quotidiennes, mais lancer le script de sauvegarde pendant la journée ralentissait toute l'application. Les utilisateurs se plaignaient et des ventes potentielles étaient perdues. La solution ? Une simple tâche cron. Elle a planifié l'exécution du script gourmand en ressources à 2h du matin, lorsque le trafic du site était quasi nul. L'expression 0 2 * * * est devenue le héros silencieux de l'entreprise, garantissant la sécurité des données sans déranger un seul utilisateur. Leçon : Planifiez les tâches gourmandes en ressources pendant les heures creuses pour maintenir les performances.

La newsletter oubliée

Un petit site e-commerce voulait envoyer un e-mail « Offres de la semaine » tous les mardis matin pour booster les ventes. Pendant des mois, un marketeux nommé Dave était chargé de cliquer manuellement sur « Envoyer » à 10h. Mais une semaine, Dave est tombé malade. La newsletter n'est jamais partie, et les ventes de ce mardi-là ont été lamentables. Le développeur principal est intervenu et a automatisé le processus. Il a écrit un script pour envoyer la newsletter et l'a branché sur une tâche cron : 0 10 * * 2. À partir de ce jour, la newsletter partait comme une horloge, peu importe qui était au bureau. Leçon : Automatisez les tâches répétitives et urgentes pour améliorer la fiabilité et éliminer l'erreur humaine.

Le cache périmé

Un site d'actualités se targuait de publier des scoops, mais sa page d'accueil semblait souvent lente. Leur contenu était mis en cache pour les performances, mais le cache n'était vidé que lorsqu'un développeur le faisait manuellement. Cela signifiait que les nouveaux articles mettaient parfois des heures à apparaître. Un développeur a mis en place une tâche cron pour vider et reconstruire automatiquement le cache du site toutes les cinq minutes. Avec l'expression */5 * * * *, le site est devenu considérablement plus rapide et plus à jour, car le nouveau contenu était garanti d'être visible en quelques minutes. Leçon : Utilisez cron pour des tâches de « maintenance » périodiques comme l'invalidation de cache pour garder les systèmes frais et performants.

Erreurs et pièges courants

Problèmes de fuseaux horaires : Le problème classique du « ça s'exécute au mauvais moment ». Les tâches cron s'exécutent presque toujours en utilisant l'heure système du serveur, qui peut être UTC ou un autre fuseau horaire dans lequel vous n'êtes pas. Planifier une tâche pour 9h du matin votre heure pourrait signifier qu'elle s'exécute à 14h heure du serveur. Soyez toujours conscient du fuseau horaire de votre serveur.
Le conflit Jour du mois vs. Jour de la semaine : Une erreur de débutant courante est de mettre une valeur à la fois dans les champs Jour du mois et Jour de la semaine (par ex., * * 1 FRI). La plupart des daemons cron interprètent cela avec une condition OU : « s'exécuter le 1er du mois OU n'importe quel vendredi ». C'est rarement ce que vous voulez. Si vous voulez « le premier vendredi du mois », vous devez utiliser * * ? * 5#1 ou un script plus complexe. Utilisez le caractère ? pour éviter toute ambiguïté.
Oublier la redirection de la sortie : Par défaut, tout ce que votre script imprime sur la sortie standard ou l'erreur standard est envoyé par e-mail à l'utilisateur propriétaire du crontab. Ça a l'air utile, mais ça peut rapidement remplir une boîte mail de notifications inutiles. La meilleure pratique est de gérer explicitement la sortie : envoyez-la dans un fichier de log (>> /var/log/myjob.log 2>&1) ou jetez-la si vous vous en fichez (> /dev/null 2>&1).
La tâche qui se chevauche : Configurer une tâche sur * * * * * signifie « démarrer une nouvelle instance de cette tâche au début de chaque minute ». Si votre tâche prend 90 secondes pour s'exécuter, vous aurez des exécutions qui se chevauchent, ce qui peut entraîner des conditions de concurrence (race conditions), un épuisement des ressources et toutes sortes de chaos.
L'environnement minimaliste : Votre shell interactif est plein de variables d'environnement utiles comme $PATH. Une tâche cron s'exécute dans un environnement dépouillé et minimaliste. Votre script qui fonctionne parfaitement depuis la ligne de commande pourrait échouer dans cron car il ne trouve pas des programmes comme node ou python. La solution est d'utiliser des chemins absolus pour toutes les commandes (par ex., /usr/bin/node au lieu de node) ou de définir la variable PATH en haut de votre fichier crontab.

Pourquoi vous devriez vous y intéresser

Vous pourriez penser que cron n'est que pour les administrateurs système de la vieille école, mais son ADN est partout.

Backend & DevOps : C'est le standard de facto pour planifier des tâches en arrière-plan, de la maintenance de base de données à la rotation des logs en passant par le déploiement de code.
Développement Web : Besoin d'envoyer des rapports quotidiens par e-mail, de vider un cache ou de générer un sitemap ? Cron est votre outil.
Plateformes Cloud : Des services comme AWS Lambda Scheduled Events et Google Cloud Scheduler utilisent des expressions cron pour définir leurs déclencheurs. La syntaxe est un langage universel pour la planification, même dans les environnements les plus modernes et « serverless ».

Apprendre à lire et à écrire des expressions cron est une compétence fondamentale. C'est la clé qui déverrouille l'automatisation, vous permettant de construire des systèmes plus robustes, fiables et autonomes. C'est un de ces petits trucs qui, une fois que vous le connaissez, vous en verrez l'utilité partout.

Pour aller plus loin

Wikipedia: cron - L'histoire et un aperçu de l'utilitaire cron lui-même.
crontab(5) - Page de manuel Linux - La référence technique canonique pour le format de fichier et sa syntaxe (en anglais).
Crontab Guru - Un éditeur en ligne interactif pour les expressions cron qui les traduit en anglais simple. Inestimable pour vérifier votre travail.
The Open Group Base Specifications: crontab - Le standard POSIX qui définit ce qu'un crontab doit faire (en anglais).
Quartz CronTrigger Tutorial - Une plongée en profondeur dans un planificateur populaire basé sur Java qui utilise un format d'expression cron étendu, incluant les secondes et plus de caractères spéciaux (en anglais).