Le 14 août 2026, j’ai relié le déploiement de ce site à GitHub Actions. Le workflow devait transmettre les variables nécessaires au serveur, puis laisser mon script server-deploy.sh récupérer le code et poursuivre le déploiement.
Sur le papier, le changement était assez petit. Un fichier YAML, des permissions, un token et quelques variables d’environnement. Les workflows GitHub Actions sont justement des processus automatisés composés de jobs, définis dans un fichier YAML, comme l’explique leur documentation officielle. Pour les valeurs sensibles, GitHub demande de les exposer explicitement au workflow depuis les secrets Actions.
Cette partie fonctionnait. Le serveur recevait bien l’ordre de déployer. Le problème se trouvait après, dans un détail que je n’avais pas prévu : le script de déploiement pouvait se modifier lui-même.
## Le fichier avait changé, pas le processus
server-deploy.sh commence par récupérer les changements du dépôt. Ce git pull peut donc remplacer n’importe quel fichier du projet, y compris server-deploy.sh, alors même que celui-ci est en cours d’exécution.
Je m’attendais implicitement à ce que la suite du déploiement utilise la version qui venait d’arriver sur le disque. Ce n’était pas le cas.
Bash avait déjà chargé une partie du script. Après le git pull, le fichier visible dans le dépôt était bien à jour, mais le processus continuait avec les instructions de l’ancienne version. Le manuel Bash décrit un script comme un fichier que Bash lit et exécute. Remplacer ce fichier pendant son exécution ne demande pas au processus déjà lancé de revenir au début ni de relire automatiquement ce qui a changé.
C’est le genre de bug qui se voit mal parce que rien ne casse franchement. Le git pull réussit. Le fichier est correct sur le serveur. Le script poursuit son travail. Il exécute seulement une version qui n’existe déjà plus sur le disque.
Je pouvais donc ouvrir server-deploy.sh après le déploiement, constater que mon changement était présent, puis observer un comportement correspondant encore à l’ancien code. Les deux constats étaient vrais. Ils ne parlaient simplement pas du même état : l’un concernait le fichier, l’autre le processus.
## J’ai arrêté de mélanger mise à jour et exécution
La correction tient dans une règle : après avoir récupéré une nouvelle version du script, l’instance lancée avant le git pull ne doit pas continuer comme si rien n’avait changé.
J’ai donc ajouté une relance après la récupération du dépôt. Le premier passage met le code à jour. Le second repart depuis le fichier réellement présent sur le serveur. Les étapes suivantes ne dépendent plus du contenu que Bash avait chargé avant le pull.
Je ne voulais pas dupliquer toute la logique de déploiement dans le workflow GitHub Actions. Le YAML déclenche et transmet ce qui est nécessaire. Le serveur reste responsable de son propre déploiement. Mais cette séparation implique que le script côté serveur doit savoir gérer sa propre mise à jour proprement.
Le point important n’est pas seulement de « relancer pour être sûr ». Il est de reconnaître qu’un fichier et son exécution sont deux objets différents. Git peut remplacer le premier. Il ne remplace pas magiquement le second.
## Ce que le déploiement fait maintenant
Le déploiement peut désormais récupérer une modification de sa propre logique et l’utiliser pendant cette même exécution globale. Je n’ai plus un script à jour sur le disque piloté par une ancienne version encore en mémoire.
Ça rend aussi les prochains changements moins ambigus. Si je modifie l’ordre des opérations dans server-deploy.sh, je sais quelle version doit prendre la suite après le pull. Je n’ai pas à attendre le déploiement suivant pour que la nouvelle logique soit réellement exécutée.
Je garde pour l’instant ce script auto-hébergé plutôt que de déplacer toutes les commandes dans GitHub Actions. Il correspond à ma manière de gérer le VPS : GitHub déclenche, le serveur déploie. La limite est maintenant explicite. Dès qu’un script met à jour son propre fichier, il doit céder la place à la version qu’il vient de récupérer.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.