Niveau 🟡 intermédiaire
Durée estimée : 15 min · Prérequis : Logs : Loki et Promtail
Mettre à jour un service sans filet, c'est changer une pièce de moteur en pleine route sans
savoir comment remonter l'ancienne si la nouvelle ne convient pas. Un tag figé, déjà vu en M4,
c'est garder l'ancienne pièce à portée de main : si la nouvelle pose problème, le retour en
arrière est une simple question de la remettre en place.
Le point de départ : le tag figé (vu en M4).
Puisqu'aucun service de ce wiki n'utilise latest, une mise à jour n'est jamais accidentelle —
elle correspond toujours à un changement de tag décidé explicitement dans un compose.yaml. Ce
choix, déjà présenté comme une bonne pratique en M4, se révèle être ici la base même d'une
procédure de mise à jour sans surprise.
Une procédure de mise à jour en quatre étapes, qui s'appuie directement sur cette convention :
compose.yaml, d'une version précise à une autre version préciselatest, qui romprait la traçabilité de ce qui tourne réellement.docker compose up -d, puis contrôler que le service redémarrecompose.yaml et relancer.⚠️ Ce que le tag figé ne remplace pas. Revenir à un ancien tag d'image ne restaure pas
automatiquement les données d'un service (vues en M5)
si la nouvelle version a modifié leur format de façon incompatible (une migration de base de
données, par exemple). Pour un service dont les données évoluent de façon significative entre
deux versions, une sauvegarde avant la mise à jour reste le seul vrai filet de sécurité
complet — le tag figé protège le code, pas nécessairement les données qu'il a déjà
transformées.
Choisir un rythme de mise à jour réaliste : attendre indéfiniment expose plus longtemps à des
failles de sécurité déjà corrigées ailleurs ; mettre à jour au jour le jour, sans lire aucune
note de version, expose à des changements cassants non anticipés. Un rythme régulier mais
espacé (mensuel, par exemple, sauf correctif de sécurité urgent à appliquer sans délai) est un
compromis raisonnable pour un homelab personnel — à ajuster selon l'importance de chaque
service.
🧪 Honnêtement, sur notre exemple : la convention du tag figé est appliquée de façon
systématique sur l'ensemble des services de ce dépôt (déjà vu en M4). En revanche, aucune
procédure de mise à jour avec test préalable et rollback n'a encore été mise en pratique et
documentée — un manque assumé, comme d'autres déjà signalés dans ce wiki (sauvegarde en M5,
alertes en page précédente), plutôt qu'une pratique inventée pour
les besoins de cette page.
Le tag figé rend chaque étape réversible : à tout moment, revenir en arrière consiste à
réutiliser une valeur déjà connue, pas à deviner quelle version fonctionnait avant.
# Avant -- version actuelle connue
services:
mon-service:
image: organisation/mon-service:1.23.4
# Après -- changement de tag explicite, décidé après lecture des notes de version
services:
mon-service:
image: organisation/mon-service:1.24.0
docker compose up -d
# Applique le changement de tag
docker compose logs -f mon-service
# Vérifie que le service redémarre et fonctionne normalement
# En cas de problème, retour en arrière : remettre l'ancien tag
# (1.23.4) dans le compose.yaml, puis :
docker compose up -d
Après toute mise à jour, vérifier explicitement que le service répond comme avant (via
Uptime Kuma si un moniteur existe déjà pour ce
service) et consulter ses logs à la recherche d'erreurs inhabituelles dans les minutes qui
suivent le redémarrage.
| Symptôme | Cause probable | Solution |
|---|---|---|
Mise à jour vers latest qui casse un service sans prévenir |
Non-respect de la convention du tag figé | Toujours choisir une version précise, jamais latest, pour garder une mise à jour traçable et réversible |
| Retour en arrière du tag qui ne résout pas le problème | Les données ont déjà été modifiées par la nouvelle version, de façon incompatible avec l'ancienne | Restaurer une sauvegarde des données antérieure à la mise à jour, pas seulement revenir au tag précédent |
| Mises à jour repoussées indéfiniment | Peur de casser quelque chose, sans procédure claire pour limiter le risque | S'appuyer sur la procédure en quatre étapes de cette page, qui rend chaque mise à jour réversible |
Parce qu'elle rend chaque mise à jour explicite et réversible : l'ancienne version reste
identifiée avec précision, un retour en arrière consiste simplement à la remettre en place.
Parce que les données du service peuvent avoir été modifiées par la nouvelle version de façon
incompatible avec l'ancienne — le tag figé protège le code, pas nécessairement les données déjà
transformées.
Les notes de version de la nouvelle version, en particulier toute mention de changement cassant
qui demanderait d'adapter la configuration avant la mise à jour.
Pour un service que tu fais tourner (ou un service fictif), rédige les quatre étapes concrètes
que tu suivrais pour le mettre à jour d'une version à une autre, en précisant à quel moment tu
ferais une sauvegarde de ses données.
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.