Avec le déploiement par image immuable, recréer le conteneur est un effet secondaire du changement de code, pas quelque chose que le déploiement fait exprès. Un changement qui ne touche que la configuration n'a donc plus rien pour l'appliquer. Il reste écrit sur le serveur, invisible, jusqu'au prochain déploiement de code, qui peut arriver des semaines plus tard.
C'est apparu en déplaçant un webhook d'alertes du mauvais canal vers le bon. Nous avons modifié le secret, redémarré le conteneur, et continué. Un redémarrage réutilise le processus avec l'environnement déjà chargé : la nouvelle variable n'est jamais entrée. Nous l'avons repéré avant que ça morde, en revérifiant le changement le jour même.
La règle qui en est sortie : ne jamais recréer à la main, même quand c'est plus rapide. Cela contourne le CI et ramène exactement la divergence entre le dépôt et le serveur que le processus existe pour éliminer. On force un déploiement par le chemin normal.
Et on vérifie l'effet, pas l'exécution. Qu'un conteneur tourne ne prouve pas qu'il a pris la variable. On compare le moment où le conteneur a été créé à celui où le fichier a été modifié, et on confirme que la variable est bien arrivée, sans en afficher la valeur.