Crontab Linux : planifier des tâches automatiques fiables

Crontab est l’outil classique de Linux et des systèmes de type Unix pour lancer automatiquement des commandes à des dates ou à des heures définies. Il permet, par exemple, de produire une sauvegarde chaque nuit, de supprimer des fichiers temporaires, d’envoyer un rapport quotidien ou de déclencher un script de maintenance à intervalle régulier.

Planifier une commande paraît simple : il suffit d’écrire une ligne contenant une date et une commande. Pourtant, les incidents les plus fréquents viennent rarement de la planification elle-même. Ils proviennent plutôt d’un chemin de fichier relatif, d’une variable d’environnement absente, de droits insuffisants, d’un script non exécutable, d’une sortie non journalisée ou de plusieurs exécutions qui se chevauchent.

Ce tutoriel explique la syntaxe de crontab, la différence entre les crontabs utilisateur et système, la création de scripts adaptés à cron, la journalisation, les tests et le diagnostic. Les exemples privilégient des pratiques reproductibles : chemins absolus, redirections explicites, contrôle des permissions et prévention des exécutions simultanées.

Le mot « cron » désigne habituellement le service d’arrière-plan qui examine les planifications, tandis que « crontab » désigne le fichier de table de planification ou la commande servant à le modifier. Dans l’usage courant, on dit aussi « ajouter un cron » pour désigner l’ajout d’une entrée dans une crontab.

Prérequis

• Un système Linux disposant d’un service cron compatible avec la commande crontab.
• Un compte utilisateur autorisé à créer sa crontab. Pour des tâches système, un accès administrateur peut être nécessaire.
• Des notions élémentaires de terminal : changer de répertoire, créer un fichier, modifier des permissions et consulter un journal.
• Un éditeur de texte en terminal, par exemple nano ou vi.

Avant de planifier une action destructive, telle qu’une suppression de fichiers ou une rotation de sauvegardes, testez toujours la commande à la main sur un jeu de données non critique.

Matériel nécessaire

• Terminal Linux
• Éditeur de texte en ligne de commande
• Un script ou une commande à automatiser

Étapes

1. 1

   Comprendre le rôle de cron et les types de crontab

   Le démon cron se réveille régulièrement, consulte les planifications qui lui sont accessibles et lance les commandes dont l’horaire correspond. Les planifications sont généralement séparées selon l’utilisateur : chaque compte peut posséder sa propre crontab. Cette séparation est utile, car une tâche créée avec votre compte s’exécute avec vos droits et accède à vos fichiers, sans obtenir automatiquement des privilèges d’administration.

   Pour afficher la crontab de l’utilisateur courant, utilisez :

   bash

   crontab -l

   Si aucune crontab n’existe encore, la commande peut l’indiquer par un message. Ce n’est pas une erreur de fonctionnement : cela signifie simplement qu’aucune planification personnelle n’a été enregistrée.

   Pour modifier ou créer votre crontab, utilisez :

   bash

   crontab -e

   Cette commande ouvre un éditeur puis installe la nouvelle table après l’enregistrement et la fermeture du fichier. C’est la méthode recommandée. Évitez de rechercher et de modifier directement un fichier interne de cron : son emplacement dépend de l’implémentation et de la distribution, et une modification directe peut être ignorée ou écrasée.

   Une crontab utilisateur contient normalement six parties : cinq champs de temps, puis la commande. Les crontabs système, notamment celles placées dans certains répertoires d’administration, peuvent avoir un champ supplémentaire indiquant l’utilisateur qui doit exécuter la commande. Cette différence est importante : copier une ligne prévue pour une crontab système dans crontab -e ajoute un mot inattendu au début de la commande et la rend incorrecte.

   Pour administrer la crontab d’un autre compte, on emploie généralement une commande exécutée avec des privilèges d’administration, par exemple :

   bash

   sudo crontab -u alice -l

   N’utilisez cette possibilité que lorsque vous savez quel compte doit posséder la tâche. Une sauvegarde de fichiers appartenant à alice est souvent plus sûre et plus simple à exécuter dans la crontab de alice que dans celle de l’administrateur.

2. 2

   Lire précisément les cinq champs de planification

   

   

   

   Une ligne classique de crontab utilisateur suit cette forme :

   bash

   minute heure jour-du-mois mois jour-de-la-semaine commande

   Les cinq champs temporels, de gauche à droite, sont les suivants :

   1. Minute : de 0 à 59.
   2. Heure : de 0 à 23, selon une horloge de 24 heures.
   3. Jour du mois : généralement de 1 à 31.
   4. Mois : généralement de 1 à 12.
   5. Jour de la semaine : la représentation numérique dépend de l’implémentation ; évitez les valeurs ambiguës lorsque vous écrivez une planification destinée à plusieurs systèmes.

   Un astérisque signifie « toutes les valeurs admises ». Ainsi, la ligne suivante lance le script chaque jour à 03 h 15 :

   bash

   15 3 * * * /home/alice/bin/sauvegarde.sh

   Vous pouvez utiliser une virgule pour une liste, un tiret pour une plage et une barre oblique pour un pas. Voici une tâche lancée à 08 h 00 et 18 h 00, du lundi au vendredi :

   bash

   0 8,18 * * 1-5 /home/alice/bin/rapport.sh

   Voici une commande prévue toutes les quinze minutes :

   bash

   */15 * * * * /home/alice/bin/verifier.sh

   Le pas s’applique au champ concerné. Par exemple, */15 dans le champ des minutes correspond aux minutes 0, 15, 30 et 45 de chaque heure. Ce n’est pas un minuteur mesurant quinze minutes après la fin de la commande. Si le système est arrêté ou si le service cron ne fonctionne pas au moment attendu, l’exécution manquée n’est pas automatiquement rattrapée par une crontab classique.

   Le champ du jour du mois et celui du jour de la semaine exigent une attention particulière. Dans des implémentations courantes de cron, lorsque ces deux champs sont restreints, une commande peut être exécutée si l’un des deux correspond, plutôt que seulement lorsque les deux correspondent. Pour exprimer une règle de calendrier complexe, il est plus fiable de planifier un lancement quotidien puis de vérifier la date dans un script, ou d’utiliser un outil de calendrier conçu pour ce besoin.

   Ajoutez un commentaire sur une ligne distincte pour documenter l’intention :

   bash

   # Rapport deux fois par jour, jours ouvrés
   0 8,18 * * 1-5 /home/alice/bin/rapport.sh

   Un commentaire commence par #. Ne placez pas un commentaire arbitraire à la fin d’une commande en supposant que toutes les interprétations de cron le traiteront de la même manière ; gardez les commentaires sur leur propre ligne.

3. 3

   Créer un script adapté à une exécution non interactive

   Une commande courte peut être placée directement dans la crontab. Dès qu’une tâche comporte plusieurs actions, des tests, des variables ou une gestion d’erreur, créez plutôt un script. Le script devient alors un fichier que vous pouvez lire, versionner, tester et exécuter manuellement avant de le confier à cron.

   Créez un répertoire personnel destiné aux scripts si nécessaire :

   bash

   mkdir -p /home/alice/bin

   Créez ensuite un script de démonstration :

   bash

   nano /home/alice/bin/rapport.sh

   Son contenu peut être le suivant :

   bash

   #!/bin/sh
   set -eu
   
   date >> /home/alice/logs/rapport.log
   echo "Le rapport planifié a démarré" >> /home/alice/logs/rapport.log

   La première ligne, appelée shebang, indique l’interpréteur à utiliser. La commande set -e demande au shell d’arrêter le script lorsqu’une commande échoue, dans les cas pris en charge par ce mécanisme. La commande set -u aide à détecter l’usage de variables non définies. Ces options ne remplacent pas des tests explicites, mais elles réduisent le risque qu’un script poursuive silencieusement son travail après une erreur simple.

   Créez le répertoire de journaux avant la première exécution :

   bash

   mkdir -p /home/alice/logs

   Rendez le script exécutable :

   bash

   chmod 700 /home/alice/bin/rapport.sh

   Le mode 700 réserve lecture, écriture et exécution au propriétaire. Adaptez les permissions si d’autres comptes doivent réellement lire ou exécuter le fichier. Ne donnez pas des permissions plus larges par défaut sans raison.

   Testez exactement le script avant de le planifier :

   bash

   /home/alice/bin/rapport.sh

   Puis consultez le résultat :

   bash

   cat /home/alice/logs/rapport.log

   Un script cron ne doit pas supposer qu’un terminal est présent, qu’un mot de passe peut être saisi, qu’un répertoire courant particulier existe ou qu’un profil interactif a été chargé. Il doit aussi produire un code de sortie cohérent : zéro en cas de succès, une valeur non nulle en cas d’échec. C’est ce comportement qui facilite la supervision et le diagnostic.

4. 4

   Utiliser des chemins absolus et maîtriser l’environnement

   Cron lance les commandes avec un environnement plus réduit que celui de votre session de terminal. Dans un terminal interactif, votre shell peut charger des fichiers de configuration qui définissent des variables, modifient PATH, activent un environnement logiciel ou changent le répertoire courant. Une tâche cron ne doit pas dépendre implicitement de ces réglages.

   La règle la plus importante consiste à employer des chemins absolus. Préférez :

   bash

   /usr/bin/find /home/alice/documents -type f

   à :

   bash

   find documents -type f

   Dans le premier cas, le programme et le répertoire ciblé sont explicitement identifiés. Dans le second, l’exécution dépend du chemin de recherche et du répertoire courant, qui peuvent être différents sous cron.

   Vous pouvez connaître le chemin d’un programme dans votre terminal avec :

   bash

   command -v find

   Pour une tâche qui doit travailler dans un répertoire donné, changez explicitement de répertoire dans le script :

   bash

   #!/bin/sh
   set -eu
   cd /home/alice/projet
   /usr/bin/make archive

   Vous pouvez également définir des variables d’environnement au début de la crontab. Par exemple :

   bash

   SHELL=/bin/sh
   PATH=/usr/local/bin:/usr/bin:/bin
   MAILTO=alice

   Ces lignes sont des réglages de la crontab, et non des tâches. La variable MAILTO peut demander l’envoi de la sortie produite par cron vers une boîte locale ou une adresse gérée par la configuration du système. Cependant, le courrier local n’est pas toujours configuré ni consulté. Pour une tâche importante, écrivez aussi un journal dans un emplacement que vous contrôlez.

   Évitez de charger aveuglément les fichiers de configuration de votre shell interactif. Ils peuvent afficher du texte, demander une interaction ou contenir des réglages inadaptés à une tâche automatisée. Définissez uniquement les variables réellement nécessaires dans le script ou dans la crontab.

5. 5

   Ajouter une première tâche et journaliser sa sortie

   Ouvrez votre crontab avec crontab -e et ajoutez une tâche simple. Pour lancer le script de rapport chaque jour à 08 h 10 et conserver à la fois la sortie standard et les erreurs dans un fichier, utilisez :

   bash

   10 8 * * * /home/alice/bin/rapport.sh >> /home/alice/logs/rapport-cron.log 2>&1

   L’opérateur >> ajoute la sortie standard à la fin du fichier. La partie 2>&1 redirige la sortie d’erreur vers la même destination. La présence des deux flux dans un seul journal rend le diagnostic plus simple : un message d’erreur produit par un programme ne disparaît pas dans une sortie séparée.

   Pour un premier test, choisissez temporairement une fréquence courte, par exemple toutes les cinq minutes :

   bash

   */5 * * * * /home/alice/bin/rapport.sh >> /home/alice/logs/rapport-cron.log 2>&1

   Après avoir constaté plusieurs exécutions correctes, remplacez cette ligne par l’horaire définitif. N’oubliez pas que chaque ligne active entraîne une exécution indépendante : laissez une seule planification lorsqu’une seule est voulue.

   Après l’enregistrement, vérifiez la table installée :

   bash

   crontab -l

   Surveillez le journal applicatif pendant le test :

   bash

   tail -f /home/alice/logs/rapport-cron.log

   Cette approche permet de répondre rapidement à trois questions : la tâche a-t-elle démarré, a-t-elle affiché une erreur et a-t-elle produit le résultat attendu ? Un fichier journal peut grandir avec le temps ; prévoyez une rotation ou une conservation adaptée à la fréquence et au volume de vos tâches.

   Si une commande n’a pas besoin de produire de sortie en cas de succès, mais que vous voulez conserver les erreurs, utilisez deux redirections distinctes :

   bash

   10 8 * * * /home/alice/bin/rapport.sh >> /dev/null 2>> /home/alice/logs/rapport-erreurs.log

   Ne masquez pas les erreurs sans avoir une autre méthode fiable de les détecter. Rediriger les deux flux vers /dev/null est pratique pour une commande mineure et éprouvée, mais rend une panne beaucoup plus difficile à comprendre.

6. 6

   Planifier des exemples utiles et sûrs

   Voici plusieurs modèles courants. Adaptez toujours les chemins, les droits et les commandes à votre machine avant de les installer.

   Créer une liste quotidienne de fichiers. Cette tâche écrit chaque nuit une liste dans un fichier daté. Le caractère pourcentage a une signification spéciale dans de nombreuses implémentations de cron : lorsqu’il n’est pas échappé, il peut être transformé en saut de ligne et le reste de la ligne peut être envoyé sur l’entrée standard de la commande. Dans une commande crontab qui utilise un format de date avec %, échappez donc ce caractère avec une barre oblique inverse :

   bash

   0 2 * * * /usr/bin/find /home/alice/documents -type f -print > /home/alice/logs/fichiers-$(/usr/bin/date +\%F).txt 2>> /home/alice/logs/find-erreurs.log

   Nettoyer des fichiers anciens. Avant d’utiliser une suppression automatique, commencez par retirer l’action destructive afin d’inspecter la liste. La commande suivante affiche les fichiers de plus de trente jours :

   bash

   /usr/bin/find /home/alice/tmp -type f -mtime +30 -print

   Après validation attentive du chemin et des résultats, vous pouvez envisager une tâche de nettoyage. Gardez un journal :

   bash

   30 3 * * 6 /usr/bin/find /home/alice/tmp -type f -mtime +30 -delete >> /home/alice/logs/nettoyage.log 2>&1

   Le risque principal de ce type de commande est un mauvais chemin. Vérifiez notamment que le répertoire ciblé n’est pas vide dans votre variable ou votre script, et testez d’abord avec -print.

   Exécuter une sauvegarde hebdomadaire. Si votre script de sauvegarde est autonome, une ligne claire suffit :

   bash

   0 1 * * 0 /home/alice/bin/sauvegarde.sh >> /home/alice/logs/sauvegarde.log 2>&1

   Le script devrait vérifier l’existence de sa destination, arrêter l’exécution en cas d’échec significatif et écrire des messages compréhensibles dans son journal. Une planification ne garantit pas qu’une sauvegarde est exploitable : testez aussi la restauration de données non critiques selon votre procédure.

   Lancer une vérification fréquente. Une vérification toutes les dix minutes peut être exprimée ainsi :

   bash

   */10 * * * * /home/alice/bin/verifier.sh >> /home/alice/logs/verifier.log 2>&1

   Assurez-vous que la durée maximale du script est compatible avec la fréquence retenue. Sinon, une nouvelle instance peut démarrer alors que la précédente n’est pas terminée.

7. 7

   Éviter les exécutions simultanées avec un verrou

   Une tâche planifiée toutes les cinq minutes peut durer plus de cinq minutes à cause d’un volume inhabituel, d’un ralentissement du disque, d’un réseau indisponible ou d’un processus externe. Sans protection, plusieurs instances du même script peuvent travailler en même temps. Cela peut dupliquer un envoi, écrire simultanément dans le même fichier ou supprimer des données de manière imprévisible.

   Sur les systèmes où la commande flock est disponible, elle peut fournir un verrou simple. Vérifiez sa présence :

   bash

   command -v flock

   La ligne suivante essaie d’acquérir un verrou non bloquant. Si une autre instance possède déjà ce verrou, la nouvelle exécution se termine immédiatement :

   bash

   */5 * * * * /usr/bin/flock -n /tmp/alice-verifier.lock /home/alice/bin/verifier.sh >> /home/alice/logs/verifier.log 2>&1

   Le chemin de flock doit être vérifié sur votre système avec command -v flock, puis remplacé dans la crontab si nécessaire. Le fichier de verrou peut être situé dans un répertoire adapté aux droits du compte qui exécute la tâche. Le nom doit être spécifique à votre tâche afin de ne pas entrer en conflit avec une autre automatisation.

   Pour distinguer une exécution refusée par verrou d’une erreur applicative, vous pouvez gérer le verrou dans un script plus complet et écrire un message explicite. L’essentiel est de choisir une politique : ignorer le nouveau lancement, attendre la fin de l’instance existante, ou concevoir la tâche pour accepter plusieurs instances. Pour une sauvegarde, un nettoyage ou un traitement d’un même lot de fichiers, ignorer ou sérialiser est souvent plus prudent que paralléliser.

   Ne confondez pas verrou et fichier témoin créé manuellement. Un simple fichier indiquant « en cours » peut rester présent après un arrêt brutal et bloquer indéfiniment les lancements futurs s’il n’est pas géré avec soin. Un mécanisme de verrouillage lié au processus est préférable lorsqu’il est disponible.

8. 8

   Diagnostiquer une tâche qui ne semble pas s’exécuter

   Lorsqu’une tâche cron échoue, procédez dans un ordre stable. Commencez par vérifier la crontab effectivement installée :

   bash

   crontab -l

   Vérifiez ensuite que le script fonctionne sous le même compte que celui qui possède la crontab :

   bash

   /home/alice/bin/rapport.sh

   Contrôlez ses permissions et son propriétaire :

   bash

   ls -l /home/alice/bin/rapport.sh

   Si vous appelez le script directement, il doit être exécutable et son interpréteur doit être valide. Une autre option consiste à appeler explicitement l’interpréteur dans la crontab :

   bash

   10 8 * * * /bin/sh /home/alice/bin/rapport.sh >> /home/alice/logs/rapport-cron.log 2>&1

   Consultez ensuite le journal que vous avez redirigé. S’il n’existe pas, vérifiez que le répertoire parent existe et est inscriptible par l’utilisateur de la tâche. Une redirection vers un fichier impossible à ouvrir peut empêcher la commande attendue de démarrer.

   Le service cron écrit aussi parfois des traces dans les journaux du système. Le nom du service varie selon les distributions, souvent cron ou crond. Vous pouvez rechercher les unités disponibles :

   bash

   systemctl list-units --type=service --all | grep -E 'cron|crond'

   Si une unité appropriée est présente, consultez ses messages récents avec une commande adaptée à son nom, par exemple :

   bash

   journalctl -u cron

   ou :

   bash

   journalctl -u crond

   Sur certains systèmes, les traces peuvent aussi être envoyées à un journal système traditionnel. Leur emplacement et leur contenu relèvent de la configuration locale ; ne supposez donc pas qu’un fichier donné existe partout.

   Enfin, reproduisez autant que possible l’environnement limité de cron. Lancez le script avec un environnement vide et un chemin minimal :

   bash

   env -i HOME=/home/alice PATH=/usr/bin:/bin /bin/sh /home/alice/bin/rapport.sh

   Si ce test échoue alors que le lancement normal réussit, votre script dépend probablement d’une variable, d’un chemin ou d’un réglage chargé dans votre session interactive.

9. 9

   Gérer les raccourcis, les tâches système et les changements

   De nombreuses implémentations de cron proposent des raccourcis tels que @daily, @weekly, @monthly, @yearly et @reboot. Leur disponibilité et leur comportement précis doivent être vérifiés dans la documentation de cron installée sur votre machine. Lorsqu’ils sont pris en charge, ils rendent une intention simple plus lisible :

   bash

   @daily /home/alice/bin/sauvegarde.sh >> /home/alice/logs/sauvegarde.log 2>&1

   Une tâche @reboot ne doit pas être utilisée comme substitut à un service correctement géré. Elle est utile pour une action ponctuelle au démarrage, mais une application durable qui doit redémarrer, être supervisée et recevoir des dépendances explicites relève généralement d’un gestionnaire de services.

   Les crontabs système possèdent souvent une syntaxe comprenant un utilisateur entre le calendrier et la commande. Exemple conceptuel :

   bash

   15 4 * * * alice /home/alice/bin/maintenance.sh

   Cette ligne n’est pas une ligne à coller dans la crontab personnelle de alice. Dans une crontab utilisateur obtenue avec crontab -e, le nom alice n’a pas sa place : la tâche s’exécute déjà sous ce compte.

   Documentez chaque tâche avec son objectif, son propriétaire, son journal et sa procédure de vérification. Lors d’une modification, conservez une copie du contenu actuel :

   bash

   crontab -l > /home/alice/crontab-sauvegarde.txt

   Vous pouvez ensuite modifier la table avec crontab -e, contrôler le résultat avec crontab -l et observer au moins une exécution. Évitez la suppression globale de crontab comme méthode de nettoyage : une suppression peut enlever toutes les tâches du compte. Retirez plutôt uniquement la ligne concernée dans l’éditeur, après avoir sauvegardé la configuration.

Erreurs fréquentes & dépannage

Erreurs fréquentes et corrections

• Utiliser un chemin relatif. Une commande qui fonctionne dans votre terminal peut échouer sous cron. Employez le chemin absolu du programme, du script, des fichiers d’entrée et des fichiers de sortie.
• Oublier les droits. Le compte qui possède la crontab doit pouvoir exécuter le script et lire ou écrire les fichiers visés. Vérifiez avec ls -l et testez sous le bon compte.
• Ne pas conserver de journal. Sans redirection ni mécanisme de notification contrôlé, un échec devient difficile à constater. Ajoutez au moins >> fichier.log 2>&1 pendant la phase de mise au point.
• Coller une ligne système dans une crontab utilisateur. Dans une crontab utilisateur, il n’y a pas de colonne utilisateur entre le calendrier et la commande.
• Utiliser un pourcentage non échappé. Dans une commande écrite directement dans une crontab, un caractère % peut avoir une signification particulière. Écrivez \% lorsque vous en avez besoin, notamment dans un format de date.
• Planifier une suppression sans test. Lancez d’abord la recherche avec -print, vérifiez les résultats et seulement ensuite envisagez une option destructive.
• Ignorer les chevauchements. Si la durée de la tâche peut dépasser sa fréquence, utilisez un verrou ou revoyez la planification.
• Supposer que cron rattrape les exécutions manquées. Une crontab classique n’est pas un système de rattrapage. Pour un besoin où chaque exécution compte, concevez un contrôle d’état explicite ou choisissez un mécanisme adapté.

Astuces & pour aller plus loin

Bonnes pratiques pour des tâches durables

• Une tâche, un script, un journal. Cette convention rend l’exploitation et le dépannage plus simples.
• Ajoutez un horodatage. Inscrire la date de début et de fin dans le journal permet de distinguer une absence d’exécution d’un échec rapide.
• Testez la restauration, pas seulement la sauvegarde. Une sauvegarde utile est une sauvegarde dont la récupération a été vérifiée selon votre procédure.
• Limitez les privilèges. Exécutez la tâche avec le compte le moins privilégié compatible avec son objectif.
• Évitez les secrets dans la crontab. Une ligne de planification est une mauvaise place pour un mot de passe ou une clé. Utilisez une méthode de stockage et des permissions adaptées à votre environnement.
• Surveillez l’espace disque. Les journaux, archives et fichiers datés créés automatiquement doivent avoir une politique de conservation.
• Conservez la configuration. Versionner vos scripts et conserver une copie lisible de la crontab facilite les revues et les retours arrière.

Questions fréquentes

Quelle est la différence entre cron et crontab ?

Cron désigne le service qui déclenche les tâches planifiées. Crontab désigne la table de planification et la commande utilisée pour l’afficher ou la modifier, notamment avec crontab -l et crontab -e.

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

Exécutez d’abord le script manuellement avec le même compte, puis ajoutez temporairement une fréquence courte et consultez un fichier journal redirigé depuis la crontab. Vérifiez aussi la table réellement installée avec crontab -l.

Pourquoi ma commande fonctionne-t-elle dans le terminal mais pas dans crontab ?

Cron fournit un environnement plus limité qu’un shell interactif. Utilisez des chemins absolus, définissez les variables nécessaires, choisissez explicitement le répertoire de travail et journalisez les erreurs.

Comment lancer une tâche toutes les cinq minutes ?

Utilisez */5 dans le champ des minutes, par exemple : */5 * * * * suivi de la commande. Vérifiez que la tâche ne dure pas plus longtemps que l’intervalle, ou protégez-la avec un verrou.

Puis-je mettre plusieurs commandes sur une seule ligne crontab ?

Oui, le shell peut enchaîner des commandes, mais un script est préférable dès que la logique devient non triviale. Il est plus facile à tester, à relire, à journaliser et à sécuriser.

Comment supprimer une seule tâche cron ?

Ouvrez la table avec crontab -e, supprimez uniquement la ligne visée, enregistrez puis contrôlez le résultat avec crontab -l. Sauvegardez la table avant une modification importante.

Conclusion

Crontab est un outil efficace pour automatiser des tâches Linux répétitives, à condition de traiter chaque planification comme un élément d’exploitation : elle doit être lisible, testée, journalisée et exécutée avec des droits minimaux.

Commencez par un script simple que vous savez lancer manuellement. Ajoutez ensuite une ligne crontab avec des chemins absolus et un journal, testez-la à fréquence courte, puis appliquez l’horaire final. Pour les tâches récurrentes importantes, prévoyez aussi la gestion des chevauchements, la conservation des journaux et une méthode de vérification du résultat.

Cette discipline transforme une simple ligne de calendrier en automatisation fiable et maintenable.