# 12. Automatisation et planification

Cette section couvre la planification de tâches (cron et son successeur
systemd timers) et les principes de robustesse d'un script shell destiné à
tourner sans supervision humaine directe.

## cron — le planificateur historique

`cron` lit des fichiers crontab (syntaxe `minute heure jour mois
jour_semaine commande`) et déclenche les commandes correspondantes à
l'heure indiquée. Limites structurelles bien connues : aucune garantie de
rattrapage si la machine était éteinte au moment prévu (sauf variante
`anacron`, pensée justement pour ce cas sur des machines pas toujours
allumées), aucune gestion native des dépendances entre tâches, et une
sortie d'erreur envoyée par mail local par défaut — souvent jamais
consultée sur un serveur moderne sans MTA configuré.

## systemd timers — l'alternative moderne

Une unité `.timer` déclenche une unité `.service` associée, avec deux
familles d'expression temporelle :

- **`OnCalendar=`** : expression calendaire proche de la syntaxe cron mais
  plus lisible (`OnCalendar=Mon..Fri 09:00`), avec **rattrapage natif** via
  `Persistent=true` — si la machine était éteinte à l'heure prévue, la
  tâche se déclenche au prochain démarrage.
- **`OnBootSec=`/`OnUnitActiveSec=`** : délai relatif (depuis le
  démarrage, ou depuis la dernière exécution) plutôt qu'une heure fixe —
  utile pour un intervalle régulier indépendant de l'heure du jour.

Avantages structurels sur cron : les journaux d'exécution passent par
journald (section 2, historique interrogeable, pas seulement le dernier
run), le service déclenché bénéficie de toutes les protections
`systemd` habituelles (limites de ressources cgroup, isolation de
répertoire avec `ProtectSystem=`/`ProtectHome=`...), et les dépendances
(`After=`/`Requires=`) s'expriment avec le même langage que le reste du
système.

## Principes de robustesse d'un script d'automatisation

Un script destiné à tourner sans supervision doit respecter plusieurs
garde-fous, indépendamment de l'outil qui le déclenche :

- **Idempotence** : ré-exécuter le script une deuxième fois de suite (après
  un échec partiel, ou par accident) doit produire le même état final
  sans effet de bord cumulatif — ex. vérifier l'absence d'une ressource
  avant de la créer, plutôt que de supposer qu'elle n'existe jamais encore.
- **Verrouillage d'exécution** (`flock` sur un fichier dédié) : empêche
  deux instances du même script planifié de tourner simultanément si la
  précédente exécution dépasse l'intervalle de planification.
- **Codes de sortie explicites** et **journalisation systématique** : un
  script qui échoue silencieusement (code de sortie 0 malgré une erreur
  réelle) est le pire cas — le planificateur ne le signale jamais comme
  en échec.
- **Séparation configuration/code** : les paramètres variables (chemins,
  seuils, destinataires d'alerte) dans un fichier de configuration
  externe plutôt que codés en dur dans le script, pour permettre un
  ajustement sans modifier le code lui-même.

> ATTENTION : un script planifié qui échoue silencieusement (sortie
d'erreur perdue, jamais consultée) est pire qu'un script qui ne tourne
pas du tout — l'absence apparente de problème masque une tâche qui ne
s'exécute plus depuis un moment. Rediriger explicitement la sortie vers
un journal consulté régulièrement, ou vers une alerte active, plutôt que
de compter sur le mail local par défaut de cron.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*