Un script de déploiement qui fonctionne à la perfection sur les huit premiers projets d’une agence, puis qui échoue brutalement sur le neuvième, révèle presque toujours le même problème sous-jacent : le script suppose une arborescence de fichiers qu’il n’a jamais vérifiée. Ce constat, observé sur plusieurs scripts maison différents au fil des années, mérite d’être détaillé une fois pour toutes, tant il revient régulièrement sous des formes légèrement différentes.
Ce qu’on observe : un script qui échoue sans message clair
Le script en question, écrit initialement pour un projet utilisant Bedrock comme structure de dépôt, copiait le contenu du dossier web/app/themes/ vers le serveur cible. Ce chemin, correct pour ce projet précis, était codé en dur dans le script, sans aucune vérification de son existence préalable. Sur un projet suivant, structuré de manière classique sans Bedrock, ce dossier n’existait tout simplement pas, et la commande de copie échouait avec un message d’erreur générique du système de fichiers, sans rapport apparent avec la cause réelle du problème.
# Extrait du script fautif
rsync -avz web/app/themes/mon-theme/ \
utilisateur@serveur:/var/www/site/wp-content/themes/mon-theme/
Sur quatre des douze projets où ce script a été réutilisé tel quel, une adaptation manuelle du chemin a été nécessaire avant la première exécution réussie, une friction que personne n’avait anticipée au moment d’écrire le script pour son usage initial.
Pourquoi c’est un problème récurrent en agence
Une agence qui maintient plusieurs projets simultanément accumule presque inévitablement des variations d’arborescence : certains projets utilisent Bedrock, d’autres une installation classique de WordPress, d’autres encore une structure personnalisée héritée d’un prestataire précédent. Un script écrit pour le premier projet rencontré tend à généraliser implicitement cette structure particulière comme si elle était universelle, ce qui fonctionne par coïncidence tant que les projets suivants partagent la même structure, puis casse dès que ce n’est plus le cas.
Ce problème ne se limite pas aux scripts de déploiement : la même logique défaillante touche aussi les scripts de sauvegarde, les scripts d’import de base de données, ou tout script qui manipule des chemins de fichiers sans jamais vérifier leur existence préalable.
Comment le rendre générique
La correction consiste à ne plus supposer un chemin, mais à le découvrir ou à le déclarer explicitement pour chaque projet, dans un petit fichier de configuration versionné à la racine de chaque dépôt.
# .deploiement.conf, à la racine de chaque projet
CHEMIN_THEME="web/app/themes/mon-theme"
#!/usr/bin/env bash
set -euo pipefail
if [ ! -f ".deploiement.conf" ]; then
echo "Fichier .deploiement.conf introuvable, déploiement annulé." >&2
exit 1
fi
source .deploiement.conf
if [ ! -d "$CHEMIN_THEME" ]; then
echo "Le chemin $CHEMIN_THEME n'existe pas dans ce projet." >&2
exit 1
fi
rsync -avz "$CHEMIN_THEME/" \
utilisateur@serveur:/var/www/site/wp-content/themes/mon-theme/
Cette version vérifie l’existence du fichier de configuration avant toute opération, puis celle du chemin qu’il déclare, avec un message d’erreur explicite dans les deux cas. Le script reste unique et partagé entre tous les projets, seule sa configuration varie d’un dépôt à l’autre.
Ce que cette correction évite
- Un échec du script se traduit désormais par un message compréhensible, pas par une erreur système générique
- Aucune modification du script lui-même n’est nécessaire pour l’adapter à une nouvelle structure de projet
- Le fichier de configuration documente implicitement la structure du projet pour toute personne qui le découvre
Un bénéfice supplémentaire, non anticipé initialement, concerne l’intégration de nouvelles recrues : le fichier de configuration sert désormais de repère rapide pour comprendre la structure d’un projet inconnu, sans avoir à explorer manuellement l’arborescence complète du dépôt.
Quoi faire à l’avenir
Tout script destiné à être réutilisé au-delà du projet pour lequel il a été écrit à l’origine mérite une règle simple : aucun chemin ne devrait être codé en dur sans une vérification préalable de son existence, ni sans une possibilité explicite de le redéfinir par projet. Cette règle, appliquée systématiquement depuis cet incident, a évité au moins deux répétitions similaires sur des scripts écrits depuis.
