./maintenance.sh --site=cabinet-central : cette seule ligne, tapée depuis un poste de travail, déclenche la sauvegarde puis la mise à jour d’un des trois sites d’un réseau de cliniques vétérinaires. Aucune plateforme de supervision, aucun tableau de bord web, aucun abonnement à un service tiers de gestion de parc. Un fichier bash d’une quarantaine de lignes, et rien d’autre.
Ce choix n’est pas un renoncement à la qualité, mais une adaptation à l’échelle réelle du besoin. Trois sites vitrines pour un réseau de trois cliniques, un contenu qui change peu, un budget de maintenance limité : l’infrastructure pensée pour un parc de cinquante sites aurait été disproportionnée. Ce billet ne traite pas de la prise de rendez-vous en ligne, absente de ces sites, mais uniquement de l’outillage de maintenance mis en place.
Pourquoi un script unique plutôt que trois configurations séparées
Les trois sites partagent la même base : même thème, mêmes extensions, seule la charte graphique et les coordonnées changent d’un cabinet à l’autre. Dupliquer la configuration de maintenance pour chacun aurait multiplié les points de défaillance sans apporter de bénéfice réel. Le script accepte donc un paramètre d’identification du site et va chercher, dans un fichier de configuration séparé, les informations propres à chacun : chemin sur le serveur, alias WP-CLI, dossier de destination des sauvegardes.
#!/usr/bin/env bash
set -euo pipefail
SITE="${1#--site=}"
source "/etc/maintenance/${SITE}.conf"
wp --path="$WP_PATH" db export "$BACKUP_DIR/$(date +%Y%m%d)-${SITE}.sql"
wp --path="$WP_PATH" plugin update --all
wp --path="$WP_PATH" core update
wp --path="$WP_PATH" cache flush
echo "Maintenance terminée pour ${SITE}"
Ce que la sauvegarde couvre, et ce qu’elle ne couvre pas
La commande wp db export capture la base de données avant toute mise à jour, avec un nom de fichier daté qui évite d’écraser la sauvegarde de la veille. Les fichiers médias, eux, sont synchronisés séparément une fois par semaine vers un espace de stockage distant, via une tâche planifiée distincte de ce script. Séparer les deux évite qu’une sauvegarde de fichiers volumineux ne ralentisse la routine de mise à jour, qui doit rester rapide pour être exécutée sans réticence.
- La base de données est sauvegardée avant chaque mise à jour, jamais après.
- Les fichiers de sauvegarde sont datés pour permettre de revenir en arrière sur plusieurs jours.
- Le script s’arrête à la première erreur grâce à
set -euo pipefail, plutôt que de continuer en silence.
La discipline plutôt que la sophistication
Ce script ne notifie personne en cas d’échec, ne journalise pas dans un système centralisé, ne propose aucune interface. Ce dénuement est un choix assumé : la personne qui l’exécute lit directement la sortie de la commande dans son terminal, et une erreur s’affiche immédiatement plutôt que de se perdre dans un journal jamais consulté. Pour trois sites exécutés une fois par semaine, cette simplicité réduit le risque d’erreur bien mieux qu’une automatisation plus ambitieuse mais mal surveillée.
Un fichier de configuration par site, pas de duplication de logique
Chaque fichier .conf tient en quatre lignes : chemin d’installation, alias WP-CLI éventuel, dossier de sauvegarde, adresse de messagerie pour l’alerte. Ajouter un quatrième site au réseau, si le client en ouvre un nouveau, se limite à créer un nouveau fichier de configuration, sans toucher au script lui-même.
Les limites assumées de cette approche
Ce script ne gère ni les montées de version majeure de WordPress, qui restent traitées manuellement après lecture des notes de version, ni les conflits d’extensions, qui nécessitent un test humain. Il ne remplace pas une politique de sauvegarde externalisée pour les cas de défaillance complète du serveur. Il couvre uniquement la routine récurrente, celle qui doit être fiable et rapide, pas les décisions qui demandent un jugement.
Un script maison n’a pas vocation à tout automatiser, seulement à rendre fiable ce qui se répète.
Pour aller plus loin
Ce type d’outillage minimal convient tant que le nombre de sites reste faible et que leur base technique reste homogène. Passé une dizaine de sites, ou dès qu’apparaissent des configurations réellement différentes les unes des autres, la logique conditionnelle du script commence à devenir plus difficile à maintenir qu’un outil dédié. Pour trois sites d’un même réseau de cliniques, en revanche, ce niveau de simplicité reste largement suffisant, et surtout entièrement compris par la personne qui l’exécute.
