Cron sous Linux : tâches planifiées avec crontab

Une tâche cron sous Linux est une tâche planifiée qui exécute une commande ou un script en arrière-plan selon un calendrier que vous définissez. Lorsque vous voulez que des travaux répétitifs — sauvegardes, nettoyage de logs, interrogation d'une API ou déclenchement du planificateur de Laravel — soient lancés par le système plutôt qu'à la main, cron est précisément l'outil qu'il vous faut. Dans ce guide, je détaille la syntaxe de crontab, des exemples concrets, la journalisation et les pièges les plus fréquents.

cron, crontab et le démon cron

Distinguer trois notions rend tout plus clair :

• cron : le service en arrière-plan toujours actif qui surveille l'horloge et déclenche les tâches (le démon, appelé cron ou crond sur la plupart des distributions).
• crontab : la « table cron », le fichier de configuration où sont listées les tâches. Chaque utilisateur a sa propre crontab.
• tâche cron : une seule ligne de cette table — un planning et une commande à exécuter.

Pour modifier votre propre crontab :

crontab -e      # éditer
crontab -l      # lister les tâches existantes
crontab -r      # tout supprimer (prudence !)

Syntaxe de crontab : les cinq champs

Chaque ligne comporte cinq champs de temps suivis de la commande :

# ┌───────── minute        (0-59)
# │ ┌─────── heure         (0-23)
# │ │ ┌───── jour du mois  (1-31)
# │ │ │ ┌─── mois          (1-12)
# │ │ │ │ ┌─ jour semaine  (0-7, 0 et 7 = dimanche)
# │ │ │ │ │
# * * * * *  commande-a-executer

Des caractères spéciaux fonctionnent dans chaque champ :

• * — toute valeur (« chaque minute », « chaque heure »).
• , — une liste : 0,15,30,45.
• - — une plage : 1-5 (lundi–vendredi).
• / — un pas : */10 (toutes les 10 unités).

Exemples cron utiles

La syntaxe peut sembler abstraite ; des exemples concrets l'éclaircissent :

# Script de sauvegarde chaque jour à 02h30
30 2 * * * /home/aslain/scripts/backup.sh

# Contrôle de santé toutes les 5 minutes
*/5 * * * * /usr/bin/curl -fsS https://aslain.dev/health

# Rapport à 09h00 en semaine
0 9 * * 1-5 /home/aslain/scripts/report.sh

# Rotation des logs à minuit le 1er de chaque mois
0 0 1 * * /home/aslain/scripts/rotate-logs.sh

# Planificateur Laravel toutes les 15 minutes
*/15 * * * * cd /var/www/site && php artisan schedule:run

Pas besoin de mémoriser la syntaxe : des outils comme crontab.guru traduisent une expression en langage clair. Comprendre la logique reste toutefois un gain de temps lors du débogage.

Variables d'environnement et chemins absolus

Le piège le plus sournois de cron, c'est que les tâches s'exécutent dans un environnement très dépouillé. Le PATH, les alias et les réglages de profil de votre terminal n'existent pas dans cron. D'où la plainte si fréquente : « ça marchait dans mon shell mais pas dans cron ».

• Écrivez les commandes et fichiers en chemins absolus : /usr/bin/php plutôt que php, des chemins complets plutôt que ./script.sh.
• Si votre script en a besoin, faites un cd vers le bon répertoire ou fixez les chemins en dur.
• Déclarez les variables nécessaires en tête de la crontab :

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
MAILTO=hello@aslain.dev

30 2 * * * /home/aslain/scripts/backup.sh

Pour trouver le bon chemin, lancez which php ou command -v node dans votre terminal et utilisez le chemin complet affiché.

Journaliser la sortie et capturer les erreurs

Par défaut, cron tente d'envoyer la sortie d'une tâche par e-mail à l'utilisateur. Si le mail n'est pas configuré, la sortie disparaît et vous ne voyez pas ce qui a échoué. La solution : rediriger la sortie vers un fichier.

# écrire stdout et stderr dans un fichier de log
30 2 * * * /home/aslain/scripts/backup.sh >> /var/log/backup.log 2>&1

Ici, 2>&1 envoie le flux d'erreurs (stderr) dans le même fichier que la sortie standard (stdout), et >> ajoute au lieu d'écraser. Pour une tâche silencieuse dont la sortie vous indiffère, utilisez > /dev/null 2>&1 — mais seulement une fois le débogage terminé.

Vous pouvez aussi vérifier dans les logs système si les tâches se sont bien déclenchées :

grep CRON /var/log/syslog        # Debian/Ubuntu
journalctl -u cron --since today # systèmes à base de systemd

Erreurs fréquentes

• Le signe pourcent. Dans crontab, % a une signification spéciale (saut de ligne) et coupe la commande. Échappez tout % dans les formats de date avec \%.
• Exécutions qui se chevauchent. Une tâche plus longue que son intervalle peut chevaucher la suivante. Verrouillez-la avec flock : flock -n /tmp/job.lock /home/aslain/scripts/job.sh.
• Droit d'exécution. Vérifiez que le script est exécutable : chmod +x script.sh, avec un shebang (#!/bin/bash) en première ligne.
• Mauvais utilisateur. Placez la tâche dans la crontab de l'utilisateur ayant les bons droits ; pour les tâches root, utilisez sudo crontab -e.

Questions fréquentes

Quand préférer un timer systemd à cron ?

Sur les distributions modernes basées sur systemd, les timers sont plus puissants pour les dépendances, le démarrage différé, le rattrapage des exécutions manquées (Persistent=true) et la journalisation détaillée. Pour des tâches périodiques simples, cron suffit largement et est disponible partout ; pour des plannings complexes proches d'un service, envisagez un timer systemd.

Puis-je exécuter quelque chose chaque seconde ?

Non — l'unité minimale de cron est la minute. Pour aller plus vite, utilisez une boucle avec sleep dans un script, ou passez à un timer systemd avec OnUnitActiveSec.

Que deviennent les tâches manquées pendant que le serveur est éteint ?

Le cron classique ne rattrape pas les exécutions manquées ; le créneau est sauté quand la machine est hors ligne. Pour lancer des tâches différées au démarrage, utilisez anacron ou l'option Persistent d'un timer systemd.

Vos tâches planifiées partent dans tous les sens ? Si vous voulez relier sauvegardes, déploiements et scripts de maintenance de votre serveur à des tâches cron fiables, contactez-moi — montons ensemble une configuration propre et journalisée.