« Mise à jour effectuée avec succès » affichait le script de maintenance dans les journaux d’exécution automatisée, alors que l’un des sites du parc tournait en réalité depuis trois semaines avec une extension restée bloquée sur une version vulnérable. Le message de succès n’était pas mensonger à proprement parler : il correspondait bien à la dernière commande du script, qui avait effectivement réussi. Le problème se situait une étape plus tôt.
Symptôme : un message de succès qui ne correspond pas à la réalité
Le script de maintenance enchaînait plusieurs commandes wp-cli pour chaque site du parc : mise à jour du cœur, mise à jour des extensions, purge du cache, puis affichage d’un message de confirmation. L’audit trimestriel des versions installées a révélé qu’un site affichait toujours une version d’extension obsolète, alors que le journal d’exécution du script indiquait un déroulement sans erreur pour ce site précis, jour après jour.
Diagnostic : une commande en échec silencieux au milieu du pipeline
Le script contenait bien set -euo pipefail en tête de fichier, ce qui aurait dû interrompre l’exécution au premier échec. L’inspection ligne par ligne a révélé la cause réelle : la commande de mise à jour des extensions était enchaînée avec un filtre grep destiné à ne conserver que les lignes pertinentes du résultat, et cette commande particulière voyait son code de sortie absorbé par la structure conditionnelle qui l’entourait.
# Version fautive
if wp plugin update --all --url="$SITE" | grep -q "Success"; then
echo "Mise à jour effectuée avec succès"
fi
Dans cette construction, le code de sortie testé par la condition if est celui de grep, pas celui de wp plugin update. Si la commande wp-cli échoue avant même de produire une ligne contenant « Success », grep renvoie simplement un résultat négatif, sans que l’échec réel de la mise à jour ne soit jamais remonté ni journalisé. Le message « Mise à jour effectuée avec succès » ne s’affichait certes pas dans ce cas précis, mais rien dans le script n’indiquait non plus clairement qu’une erreur s’était produite, la sortie restant silencieuse.
En rejouant manuellement la commande fautive sur le site concerné, le code de sortie retourné était 137, signe caractéristique d’un processus interrompu par le système, probablement à la suite d’une limite de mémoire dépassée pendant l’opération, sans qu’aucun message explicite n’ait été produit à ce sujet dans le journal du script.
Correctif : vérifier explicitement chaque code de sortie critique
La correction a consisté à séparer la commande wp-cli du filtre de lecture du résultat, en capturant explicitement son code de sortie dans une variable dédiée avant toute autre opération.
# Version corrigée
wp plugin update --all --url="$SITE" > /tmp/resultat_maj.log
CODE_SORTIE=$?
if [ "$CODE_SORTIE" -ne 0 ]; then
echo "Échec de la mise à jour sur $SITE (code $CODE_SORTIE)" >&2
exit 1
fi
grep -q "Success" /tmp/resultat_maj.log && echo "Mise à jour effectuée avec succès"
Cette réécriture rend le code de sortie de la commande critique explicitement testable, indépendamment du traitement fait ensuite sur sa sortie textuelle. L’échec provoque désormais l’arrêt du script avec un message clair, plutôt que de disparaître dans une structure conditionnelle qui en masquait la portée réelle.
Prévention : une règle simple pour les prochains scripts
- Ne jamais tester directement le résultat d’un pipe quand la commande d’origine importe plus que le filtre appliqué ensuite
- Capturer le code de sortie dans une variable immédiatement après chaque commande jugée critique
- Journaliser systématiquement un code de sortie non nul, même quand le script continue volontairement son exécution
Une revue rapide des autres scripts de maintenance de l’agence a permis de repérer deux constructions similaires, corrigées par précaution avant qu’un incident comparable ne se reproduise ailleurs sur le parc.
Pour aller plus loin
Ce type d’incident rappelle qu’un script protégé par set -euo pipefail n’est pas à l’abri de tout, en particulier dès qu’une commande est enchaînée dans un pipe avec un filtre de lecture. Vérifier explicitement le code de sortie d’une étape jugée critique reste la seule garantie fiable, indépendante de la structure du reste du script qui l’entoure.
