Expressions Cron Une référence pratique avec des exemples concrets

Une expression cron est composée de cinq champs espacés qui indiquent à un planificateur Unix quand exécuter une commande. Cinq champs, un petit nombre de caractères spéciaux et quelques motifs courants — c’est tout le modèle mental. Cette référence couvre la syntaxe, les caractères qui dérangent les utilisateurs, et les calendriers que les développeurs utilisent effectivement.

Les cinq champs

Le cron standard utilise cinq champs positionnels :

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridge et le planificateur Quartz en Java ajoutent un des secondes champ au début, ce qui fait un total de six champs. Tous les autres champs se déplacent à droite. Cela dérange les développeurs qui passent d’un environnement à un autre — une expression Quartz collée dans un crontab standard sera exécutée selon un emploi du temps incorrect sans aucune alerte.

Restez dans le cadre des cinq champs POSIX cron sauf si votre plateforme exige explicitement six.

Caractères spéciaux

Caractère	Signification	Exemple
*	Toute valeur — correspond à chaque unité	* * * * * — chaque minute
,	Liste de valeurs	0 9,17 * * * — à 9h et 17h
-	Gamme	0 9-17 * * * — chaque heure de 9h à 17h
/	Intervalle de pas	*/15 * * * * — toutes les 15 minutes
?	Aucune valeur spécifique (seulement Quartz/AWS)	0 0 15 * ? — le 15e jour de chaque mois, quel que soit le jour de la semaine
L	Dernier (seulement Quartz/AWS)	0 0 L * ? — dernier jour de chaque mois
W	Jour de semaine le plus proche (seulement Quartz/AWS)	0 0 15W * ? — jour de semaine le plus proche du 15e

Standard crontab reconnaît uniquement *, ,, -et /. Si vous voyez ?, L, ou W dans une expression, elle a été écrite pour Quartz ou AWS EventBridge — ne la collez pas dans un crontab Linux sans modification.

Le tableau de référence : les calendriers utilisés par les développeurs

C’est la partie à sauvegarder. Construisez et validez n’importe quelle expression avec le Générateur d’expression cron IO Tools.

Description	Expression Cron	Remarques
Chaque minute	* * * * *	Rarement approprié en production
Toutes les 5 minutes	*/5 * * * *	Vérifications de santé, cycles de polling courts
Toutes les 15 minutes	*/15 * * * *	Chauffage du cache, synchronisation des flux
Toutes les 30 minutes	*/30 * * * *	Équivalent à 0,30 * * * *
Toutes les heures (à l’heure)	0 * * * *	Exécution à :00 de chaque heure
Toutes les 6 heures	0 */6 * * *	Synchronisation des données, exports incrémentaux
Tous les jours à minuit UTC	0 0 * * *	Déclencheur quotidien standard
Tous les jours à 9h UTC	0 9 * * *	Génération des rapports matinaux
Les jours ouvrés à 9h UTC	0 9 * * 1-5	Tâches limitées aux heures d’affaires (lundi à vendredi)
Les jours ouvrés à 8h30 UTC	30 8 * * 1-5	Livraison des rapports avant le point de départ
Tous les dimanches à 2h	0 2 * * 0	Entretiens hebdomadaires, sauvegardes en dehors des heures de pointe
Premier jour de chaque mois	0 0 1 * *	Exécutions mensuelles de facturation, rapports récurrents
Le 1er janvier à minuit	0 0 1 1 *	Réinitialisations annuelles, tâches de début d’année

Le problème de la zone horaire

Le cron n’a pas de conscience horaire. Il s’exécute dans la zone horaire configurée sur le serveur — sur la plupart des systèmes Linux, cela correspond à UTC. Cela est généralement acceptable jusqu’à ce que vous ayez des tâches liées aux heures d’affaires ou des utilisateurs dans plusieurs régions qui se demandent pourquoi le « rapport à 9h » arrive à 14h.

Les réglages les plus sûrs :

• Configurez votre serveur en UTC. Convertissez en heure locale dans la logique de l’application, et non dans le planificateur cron.
• Commentez chaque tâche cron avec l’heure locale effective, afin que la personne suivante lisant le crontab ne doive pas deviner.
• Lors de l’utilisation de planificateurs cloud (AWS EventBridge, Google Cloud Scheduler), vérifiez le champ de zone horaire — la plupart prennent directement les noms de zones IANA, ce qui élimine l’ambiguïté.

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

Test : Calculez les prochaines exécutions avant de déployer

Déployer une tâche cron pour découvrir qu’elle s’exécute toutes les minutes au lieu de toutes les heures est une étape incontournable. Évitez-la.

Le Calculateur des prochaines exécutions IO Tools Cron affiche exactement quand votre expression va être exécutée — collez votre expression et obtenez les dix prochaines exécutions avant de toucher un serveur.

Pour la validation en ligne de commande :

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

Ajout d’une tâche cron sur Linux

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

Le 2>&1 à la fin de la ligne de sauvegarde redirige l’erreur standard vers la sortie standard, afin que les deux soient enregistrés dans le fichier de log. Sans cela, les erreurs cron vont dans le spool de courrier — et personne ne les vérifie.

Workflow planifié dans GitHub Actions

GitHub Actions utilise la même syntaxe cron à cinq champs, toujours en UTC. Il n’y a pas de surcharge horaire.

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

Une restriction : les workflows planifiés dans GitHub Actions peuvent être retardés de jusqu’à 15 minutes pendant les périodes de forte charge. Ne comptez pas sur eux pour des tâches nécessitant une précision exacte.

Quand le cron n’est pas suffisant

Le cron standard gère la plupart des cas sur un seul serveur. Ses limites deviennent des problèmes à l’échelle :

• Pas de reprise en cas d’échec. Si la tâche échoue, le prochain lancement est le prochain moment prévus — il n’y a pas de reprise automatique.
• Pas de verrouillage distribué. Plusieurs serveurs exécutant le même crontab déclenchent la même tâche simultanément.
• Pas d’observabilité. Il n’y a pas de tableau intégré pour l’historique des exécutions, les alertes en cas d’échec ou le suivi de la durée.

Problème	Alternative meilleure
Logique de reprise et files de tâches	Celery Beat (Python), Sidekiq-Cron (Ruby)
Planification native dans le cloud avec reprise	AWS EventBridge + Lambda, Google Cloud Scheduler
Déclencheurs de pipelines CI/CD	Planification dans GitHub Actions
Orchestration observable des tâches	Airflow, Prefect, Temporal

Pour les scripts sur un seul serveur, le cron reste l’outil approprié — il est simple, fiable et n’a pas de dépendances. Pour tout ce qui nécessite des garanties de reprise, une exécution distribuée ou une visibilité en cas d’échec, une file de tâches se justifie rapidement.

Utilisez le Générateur d'expression Cron pour construire votre prochaine planification sans avoir à mémoriser la syntaxe, et le Calculateur des prochaines exécutions Cron pour vérifier qu’il s’exécute quand vous l’attendez.

Vous aimerez peut-être aussi