Cron : automatiser des tâches planifiées sous Linux

Cron est le planificateur de tâches historique des systèmes Unix et Linux. Son rôle : exécuter automatiquement une commande à une date et une heure données, ou à intervalle régulier — toutes les nuits, tous les lundis, toutes les cinq minutes. Sauvegardes, envoi de rapports, nettoyage de fichiers temporaires, renouvellement de certificats : dès qu’une action doit se répéter sans intervention humaine, cron est l’outil. Ce guide décortique sa syntaxe parfois déroutante, donne des exemples réels et surtout démonte les pièges qui font qu’« une tâche cron ne se lance pas ».

Comprendre la syntaxe : cinq champs

Une ligne de crontab décrit quand lancer quoi. Le « quand » tient en cinq champs séparés par des espaces, suivis de la commande :

┌───────── minute        (0 - 59)
│ ┌─────── heure         (0 - 23)
│ │ ┌───── jour du mois  (1 - 31)
│ │ │ ┌─── mois          (1 - 12)
│ │ │ │ ┌─ jour semaine  (0 - 7, dimanche = 0 ou 7)
│ │ │ │ │
* * * * * commande à exécuter

Un * signifie « toutes les valeurs ». Plusieurs opérateurs enrichissent chaque champ :

* : chaque unité (chaque minute, chaque heure…).
, : une liste — 1,15,30.
- : une plage — 9-17 (de 9h à 17h).
/ : un pas — */5 (tous les 5), 0-30/10 (0, 10, 20, 30).

Lire quelques exemples

30 2 * * *      # tous les jours à 2h30 du matin
0 * * * *       # au début de chaque heure
*/15 * * * *    # toutes les 15 minutes
0 9 * * 1       # chaque lundi à 9h00
0 0 1 * *       # le 1er de chaque mois à minuit
0 8-18 * * 1-5  # à chaque heure pleine, 8h→18h, du lundi au vendredi

Cron propose aussi des raccourcis lisibles, à mettre à la place des cinq champs : @daily, @hourly, @weekly, @monthly, @reboot (au démarrage de la machine).

@daily /usr/local/bin/sauvegarde.sh

Éditer sa crontab

Chaque utilisateur possède sa propre table de tâches. On l’édite avec :

crontab -e

La première fois, le système demande quel éditeur utiliser (nano est le plus simple). Les commandes voisines sont utiles au quotidien :

crontab -l          # afficher les tâches actuelles
crontab -r          # tout supprimer (prudence, pas de confirmation)
sudo crontab -e -u www-data   # éditer la crontab d'un autre utilisateur

Une tâche typique, avec un commentaire pour se souvenir de son intention :

# Sauvegarde de la base chaque nuit à 3h15
15 3 * * * /usr/local/bin/backup-db.sh

Enregistrez, quittez : cron affiche « installing new crontab » et la tâche est active immédiatement, sans redémarrage.

Le piège numéro un : chemins et environnement

C’est LA cause de 90 % des « ça marche à la main mais pas dans cron ». Cron s’exécute dans un environnement minimal : le PATH est réduit (souvent /usr/bin:/bin), aucun de vos alias, et le répertoire courant n’est pas celui que vous croyez.

Toujours des chemins absolus

python mon_script.py échouera si python n’est pas dans le PATH réduit de cron. Utilisez le chemin complet, des deux côtés :

0 6 * * * /usr/bin/python3 /home/alice/scripts/rapport.py

Pour trouver le chemin absolu d’une commande, which python3 en session normale.

Définir l’environnement dans la crontab

On peut poser des variables en tête de crontab. Elles s’appliquent à toutes les lignes suivantes :

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
[email protected]

0 6 * * * rapport.py

Si votre tâche dépend de variables métier (clés d’API, connexion à une base), ne les codez pas en dur : faites-les charger par le script. Le sujet mérite un article dédié — voir les variables d’environnement expliquées. Une astuce robuste consiste à sourcer un fichier avant d’agir :

0 6 * * * . /home/alice/.env && /home/alice/scripts/rapport.py

Se placer dans le bon dossier

Beaucoup de scripts supposent un répertoire courant. Rendez-le explicite :

0 4 * * * cd /var/www/site && /usr/bin/php artisan backup:run

Récupérer la sortie et les logs

Par défaut, cron envoie tout ce qu’écrit la tâche (sortie standard et erreurs) par mail local à l’utilisateur. Sur un serveur sans messagerie, cette sortie est perdue. Redirigez-la vers un fichier pour pouvoir diagnostiquer :

30 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1

>> ajoute à la fin du fichier (> écraserait à chaque fois).
2>&1 redirige aussi les erreurs vers ce même fichier — indispensable.

Pour ne garder que les erreurs et rester silencieux en cas de succès :

30 2 * * * /usr/local/bin/backup-db.sh > /dev/null 2>&1

Cron lui-même journalise ses déclenchements. Selon la distribution :

grep CRON /var/log/syslog        # Debian / Ubuntu
journalctl -u cron --since today # systèmes avec journald

Ces lignes prouvent que cron a lancé la tâche — même si celle-ci a ensuite échoué.

Dépanner une tâche qui ne part pas

Une méthode fiable, dans l’ordre :

Le service tourne-t-il ? systemctl status cron (ou crond sur Red Hat/Fedora).
La ligne est-elle valide ? Chaque tâche doit finir par un saut de ligne ; une crontab dont la dernière ligne n’a pas de retour chariot peut être ignorée.
Reproduire l’environnement de cron pour révéler les problèmes de PATH :

env -i /bin/bash -c '/usr/bin/python3 /home/alice/scripts/rapport.py'

env -i vide l’environnement, comme le fait cron. Si la commande casse ici alors qu’elle marche dans votre shell, le coupable est un chemin ou une variable manquante.

Vérifier les permissions : le script doit être exécutable (chmod +x) et appartenir au bon utilisateur.
Consulter les logs créés au point précédent.

Alternative moderne : les systemd timers

Sur les systèmes récents, systemd propose les timers, une alternative à cron. C’est plus verbeux (deux fichiers, un .service et un .timer) mais plus puissant : logs centralisés dans journalctl, dépendances entre unités, exécution rattrapée si la machine était éteinte (Persistent=true), et déclencheurs relatifs comme « 15 minutes après le démarrage ».

Un timer minimal, dans /etc/systemd/system/backup.timer :

[Unit]
Description=Sauvegarde quotidienne

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target

Activation :

sudo systemctl enable --now backup.timer
systemctl list-timers        # voir les prochains déclenchements

Pour une tâche simple et personnelle, cron reste imbattable de concision. Pour du service critique sur un serveur, les timers offrent une meilleure traçabilité.

En résumé

Cron tient en une règle mentale : cinq champs (minute, heure, jour du mois, mois, jour de semaine) puis une commande. Le reste n’est que rigueur — chemins absolus, environnement explicite, sortie redirigée vers un log. La majorité des « bugs cron » ne sont pas des bugs de cron mais des différences d’environnement, que la commande env -i révèle en dix secondes. Commencez par planifier votre tâche la plus répétitive, vérifiez son log le lendemain, et étendez au fil de vos besoins.