Programmer une tâche Cron sous Linux : automatiser vos commandes pas à pas

Pour programmer une tâche Cron sous Linux, ouvrez la crontab avec crontab -e, puis ajoutez une ligne composée de 5 champs de date et d’heure suivis de la commande à lancer. Une tâche Cron Linux peut exécuter un script toutes les cinq minutes, chaque nuit ou au démarrage, tant que la machine et le service Cron sont actifs.

Cron convient aux actions répétitives et prévisibles : lancer une sauvegarde, produire un rapport ou nettoyer un dossier. Ce tutoriel explique le mécanisme, les commandes à saisir, la syntaxe Cron, les différences entre tâches utilisateur et système, puis les contrôles à effectuer lorsque l’automatisation ne produit pas le résultat attendu.

Qu’est-ce que Cron et à quoi sert-il sous Linux ?

Cron est un planificateur de tâches Linux qui exécute automatiquement une commande ou un script à une date, une heure ou une fréquence définie. Le démon Cron consulte régulièrement les règles enregistrées et déclenche les commandes dont le calendrier correspond à l’heure du système.

La crontab, contraction de « cron table », contient les règles d’un utilisateur. Une crontab personnelle permet d’automatiser des tâches sans modifier la configuration globale de la machine. Une tâche système relève plutôt de fichiers tels que /etc/crontab ou de fichiers placés dans /etc/cron.d/, qui demandent des droits administrateur.

Une tâche planifiée fiable ne se limite pas à une heure d’exécution : elle précise aussi qui lance la commande, avec quel chemin et où vont les erreurs.

Pour une machine qui fonctionne en continu, Cron est adapté aux actions périodiques. Anacron répond à un autre besoin : il peut être utilisé sur des machines qui ne restent pas allumées en permanence, sous réserve qu’il soit installé et configuré par la distribution. Une tâche Cron ordinaire prévue pendant un arrêt n’est pas exécutée rétroactivement au redémarrage.

Préparer une commande ou un script avant l’automatisation

Une commande qui échoue dans un terminal échouera aussi dans une tâche planifiée Linux. Commencez donc par isoler une action simple, sans mot de passe interactif ni dépendance implicite à votre session. Le résultat attendu doit pouvoir être vérifié : création d’un fichier, ajout d’une ligne dans un journal ou génération d’une archive.

Étape 1 : tester la commande manuellement

Exécutez la commande dans le terminal avec le même compte utilisateur que celui qui possédera la crontab. Par exemple, cette commande ajoute une date dans un fichier de test :

/bin/date >> /home/votre_utilisateur/cron-test.log

Vérifiez ensuite le contenu du fichier avec cat /home/votre_utilisateur/cron-test.log. Le résultat attendu est une nouvelle ligne contenant la date et l’heure ; cette vérification sépare un problème de commande d’un problème de planification.

Étape 2 : utiliser des chemins absolus et un script explicite

Cron lance les commandes dans un environnement minimal, sans reprendre nécessairement votre variable PATH habituelle ni votre dossier courant. Écrivez donc /usr/bin/python3 plutôt que python3, et /home/votre_utilisateur/scripts/rapport.sh plutôt que ./rapport.sh.

Pour un script shell lancé directement, ajoutez une ligne d’interpréteur en première ligne, par exemple #!/bin/sh, puis accordez seulement le droit d’exécution nécessaire avec chmod u+x /home/votre_utilisateur/scripts/rapport.sh. Un script peut aussi être appelé explicitement par /bin/sh, ce qui évite de dépendre du bit exécutable.

Étape 3 : définir un résultat contrôlable

Ajoutez un fichier journal ou une sortie de test avant de planifier une action utile. Une écriture dans /home/votre_utilisateur/logs/rapport.log permet de constater l’heure réelle d’exécution sans supposer que Cron a fonctionné.

Les scripts qui manipulent des accents ou d’autres caractères UTF-8 gagnent à définir une locale explicite, par exemple LANG=C.UTF-8 si cette locale est disponible sur la machine. Le bon réglage dépend de la distribution et des locales installées ; vérifiez-le avec locale -a.

Comment créer et gérer une tâche Cron avec crontab ?

Pour créer une tâche Cron personnelle, lancez crontab -e, ajoutez une règle valide, enregistrez le fichier puis contrôlez son contenu avec crontab -l. Cette méthode modifie uniquement la planification de l’utilisateur courant et évite de donner des privilèges administrateur à une tâche qui n’en a pas besoin.

Étape 4 : ouvrir la crontab et ajouter une première règle

Saisissez la commande suivante dans le terminal. Lors de la première utilisation, le système peut demander de choisir un éditeur de texte.

crontab -e

Ajoutez une ligne de test qui exécute la commande chaque cinq minutes, puis enregistrez et fermez l’éditeur :

*/5 * * * * /bin/date >> /home/votre_utilisateur/cron-test.log 2>&1

La redirection 2>&1 ajoute les erreurs au même fichier que la sortie normale. Le résultat attendu après cinq minutes est une nouvelle date dans cron-test.log.

Étape 5 : lister, désactiver ou supprimer la planification

Contrôlez la règle enregistrée avec crontab -l. Pour suspendre une tâche sans l’effacer, placez un caractère # au début de sa ligne dans crontab -e ; cette solution conserve la règle pour une réactivation ultérieure.

La commande crontab -r supprime la crontab entière de l’utilisateur courant, pas une seule ligne. Exportez d’abord une copie avec crontab -l > ~/crontab-sauvegarde.txt ; la suppression globale est rapide, mais la restauration dépend de la sauvegarde que vous avez conservée.

Commande	Action	Point de vigilance
crontab -e	Créer ou modifier la crontab personnelle	Tester la commande avant de l’ajouter
crontab -l	Afficher les tâches de l’utilisateur courant	Vérifier la ligne réellement enregistrée
crontab -r	Supprimer toute la crontab personnelle	Sauvegarder avant cette commande
sudo crontab -u nom_utilisateur -e	Modifier la crontab d’un autre compte	Réserver cette action aux tâches qui le justifient

Une crontab système suit une syntaxe légèrement différente : dans /etc/crontab et les fichiers de /etc/cron.d/, un champ utilisateur est placé entre les cinq champs de calendrier et la commande. Consultez la documentation de votre distribution ou la page de manuel crontab(5) avant de modifier ces fichiers, car une erreur de portée peut affecter plusieurs comptes.

Comment lire la syntaxe Cron sans se tromper ?

La syntaxe Cron standard place cinq champs dans cet ordre : minute, heure, jour du mois, mois, jour de la semaine, puis la commande. La ligne 0 0 * * * /chemin/script.sh lance donc le script à minuit chaque jour, car les deux premiers champs valent zéro et les trois suivants acceptent toutes les valeurs.

Position	Valeurs habituelles	Exemple
Minute	0 à 59	15 pour la quinzième minute
Heure	0 à 23	2 pour 02 h 00
Jour du mois	1 à 31	1 pour le premier jour
Mois	1 à 12	1 pour janvier
Jour de la semaine	0 à 7 selon l’implémentation	1 pour lundi dans les usages courants

Les opérateurs raccourcissent les calendriers : * signifie toutes les valeurs, , crée une liste, - une plage et / un pas. Ainsi, */5 dans le champ des minutes signifie « toutes les cinq minutes », tandis que 1-5 dans le champ du jour de semaine cible habituellement les jours ouvrés.

Évitez de restreindre simultanément le jour du mois et le jour de la semaine sans avoir vérifié le comportement de votre implémentation Cron. La règle de correspondance entre ces deux champs peut surprendre ; une planification complexe mérite un test sur une date connue et une lecture de la documentation locale.

Une expression Cron doit être lue de gauche à droite : minute, heure, jour du mois, mois, jour de la semaine, puis commande.

Exemples concrets pour programmer une tâche Cron Linux

Les exemples suivants utilisent des chemins fictifs qu’il faut remplacer par ceux de votre compte. Chaque commande redirige sa sortie vers un fichier journal afin de rendre l’exécution observable plutôt que silencieuse.

Exécuter une commande toutes les cinq minutes

*/5 * * * * /usr/bin/curl -fsS https://exemple.invalid/health >> /home/votre_utilisateur/logs/verification.log 2>&1

Cette tâche tente une requête toutes les cinq minutes. L’option -f demande à curl de signaler les erreurs HTTP ; adaptez l’URL, les options et la journalisation à votre propre service, sans placer de jeton ou de mot de passe directement dans la crontab.

Lancer un script chaque jour à minuit

0 0 * * * /home/votre_utilisateur/scripts/backup.sh >> /home/votre_utilisateur/logs/backup.log 2>&1

Cette règle lance backup.sh chaque jour à 00 h 00 selon le fuseau horaire système. La sauvegarde doit être testée manuellement, et sa restauration aussi : produire une archive ne prouve pas à elle seule que les données pourront être relues.

Planifier une tâche hebdomadaire, mensuelle ou au démarrage

• 30 7 * * 1 /home/votre_utilisateur/scripts/rapport.sh lance un rapport le lundi à 07 h 30.
• 0 3 1 * * /home/votre_utilisateur/scripts/rotation.sh lance une rotation le premier jour du mois à 03 h 00.
• @reboot /home/votre_utilisateur/scripts/demarrage.sh >> /home/votre_utilisateur/logs/demarrage.log 2>&1 tente de lancer un script au démarrage du service Cron.

Les raccourcis tels que @reboot, @daily ou @hourly sont pris en charge par de nombreuses implémentations, mais leur disponibilité mérite une vérification dans la page de manuel de votre système. Pour une tâche sensible, une expression à cinq champs est souvent plus explicite.

Journalisation Cron : comment vérifier l’exécution ?

La journalisation Cron consiste à conserver la sortie normale et les erreurs de chaque commande. Ajoutez >> /chemin/fichier.log 2>&1 à la fin d’une règle pour ajouter les messages successifs dans un même fichier, au lieu de perdre l’information au moment où elle est produite.

Les journaux système peuvent aussi contenir les passages de Cron, souvent dans /var/log/syslog ou /var/log/cron.log selon la distribution et sa configuration de journalisation. Une commande telle que grep CRON /var/log/syslog peut être utile si le fichier existe et si votre compte a le droit de le lire.

La variable MAILTO placée en tête de la crontab peut demander l’envoi par courriel de la sortie des commandes, si un système de messagerie local est correctement configuré. La réception dépend donc du serveur de courrier présent sur la machine ; pour comprendre les réglages d’une boîte webmail, consultez aussi ce guide de configuration Roundcube.

MAILTO="[email protected]"
0 2 * * * /home/votre_utilisateur/scripts/controle.sh

Un journal qui grossit sans limite finit par occuper de l’espace disque. Préférez un outil de rotation de journaux configuré par votre système, ou concevez le script pour produire des sorties courtes et utiles ; rediriger aveuglément vers /dev/null supprime aussi les indices nécessaires au dépannage.

Erreurs fréquentes avec une tâche Cron Linux

Une tâche Cron qui ne produit rien ne démontre pas forcément que le planificateur est arrêté. La cause se trouve souvent dans la commande, le compte utilisateur, les chemins ou l’heure utilisée par le système.

• Chemin relatif ou commande introuvable : Cron ne reprend pas nécessairement votre PATH. Indiquez /usr/bin/commande et les chemins complets vers les fichiers.
• Script non exécutable ou mauvais interpréteur : ajoutez un shebang valide ou appelez explicitement /bin/sh, puis testez le script avec le compte concerné.
• Erreur cachée par l’absence de journal : redirigez la sortie et les erreurs vers un fichier avant de conclure à une panne de Cron.
• Modification de la mauvaise crontab : sudo crontab -e modifie la crontab de root, qui est distincte de celle ouverte par crontab -e.
• Horaire décalé : vérifiez le fuseau du système avec timedatectl lorsque cette commande est disponible. Les changements d’heure peuvent aussi perturber les tâches programmées à une heure précise.

Les fichiers /etc/cron.allow et /etc/cron.deny peuvent contrôler l’accès à crontab sur certains systèmes. Leur présence et leur comportement dépendent de l’implémentation installée ; ne les modifiez pas sans comprendre la politique d’accès attendue sur la machine.

Cron, Anacron et minuteurs systemd : quelle solution choisir ?

Cron convient aux commandes périodiques simples sur une machine disponible à l’heure prévue. Anacron est généralement plus pertinent pour des actions quotidiennes ou hebdomadaires sur un ordinateur qui peut être éteint, tandis que les minuteurs systemd offrent une intégration plus étroite avec les services systemd et leurs journaux.

Solution	Cas d’usage adapté	Limite principale
Cron	Commande simple à une heure ou fréquence fixe	Une exécution manquée pendant un arrêt n’est pas rattrapée par Cron classique
Anacron	Tâche périodique sur un poste parfois éteint	Moins adapté à une précision à la minute
Minuteur systemd	Service Linux avec suivi par journal systemd	Demande de créer et gérer des unités systemd

Le choix dépend du mécanisme recherché, pas d’une préférence générale. Une sauvegarde nocturne qui doit absolument être traitée après un arrêt demande une conception de reprise ; une simple vérification toutes les cinq minutes sur un serveur actif se prête bien à une tâche Cron.

Bonnes pratiques de sécurité et de maintenance

Exécutez chaque script avec le compte le moins privilégié capable d’accomplir l’action. Une crontab root peut lancer des commandes puissantes, mais elle augmente l’impact d’une erreur de chemin, d’un script modifié ou d’une variable mal contrôlée.

Conservez les scripts dans un répertoire dont les droits sont cohérents avec leur rôle, et évitez les fichiers modifiables par des comptes non concernés. Les secrets doivent rester dans un mécanisme de configuration protégé, avec des permissions restrictives, plutôt que dans une ligne Cron lisible par erreur ou sauvegardée dans un historique.

1. Testez la commande manuellement avec le compte d’exécution.
2. Utilisez les chemins absolus vers l’interpréteur, le script et les fichiers.
3. Ajoutez une redirection de journal avant la mise en service.
4. Contrôlez la crontab enregistrée avec crontab -l.
5. Relisez périodiquement les journaux et supprimez les tâches devenues inutiles.

Les répertoires /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly et /etc/cron.monthly existent sur de nombreuses distributions pour des scripts périodiques gérés par le système. Leur horaire effectif dépend de la configuration locale ; une règle explicite dans votre crontab reste plus lisible lorsque vous avez besoin d’un calendrier précis.

Mettre votre première automatisation en service

La méthode la plus sûre consiste à commencer par une tâche sans effet destructeur, journalisée et lancée sous votre compte utilisateur. Une fois la date ajoutée au fichier de test à l’heure prévue, remplacez progressivement cette commande par le script réellement utile.

La syntaxe Cron est compacte, mais son mécanisme reste simple : un calendrier, une commande, un environnement limité et une trace à vérifier. Une tâche bien documentée et journalisée vaut mieux qu’une automatisation opaque exécutée avec des privilèges excessifs.

Questions fréquentes sur les tâches Cron Linux

Comment programmer une tâche Cron toutes les cinq minutes ?

Ajoutez la ligne */5 * * * * /chemin/commande dans la crontab ouverte avec crontab -e. Remplacez /chemin/commande par une commande ou un script testé manuellement.

Comment arrêter une tâche Cron sans la supprimer ?

Ouvrez la crontab avec crontab -e et ajoutez # au début de la ligne concernée. Cette mise en commentaire désactive la tâche tout en conservant sa configuration.

Comment vérifier qu’une tâche Cron fonctionne ?

Ajoutez une redirection vers un fichier journal, puis vérifiez ce fichier après l’heure prévue. Consultez aussi les journaux système, souvent /var/log/syslog ou /var/log/cron.log, selon la distribution.

Cron fonctionne-t-il lorsque l’ordinateur est éteint ?

Cron classique ne lance pas rétroactivement une tâche prévue pendant l’arrêt de la machine. Anacron ou un minuteur systemd peut répondre à ce besoin, selon la distribution et le calendrier souhaité.

Quelle différence existe entre la crontab utilisateur et /etc/crontab ?

La crontab utilisateur est gérée avec crontab -e et s’exécute avec les droits de ce compte. Le fichier /etc/crontab est une configuration système qui contient aussi un champ indiquant l’utilisateur qui exécutera la commande.