# 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.

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