Docker versioning : gérer les versions de vos images

Quand j’ai commencé à utiliser Docker en 2016, je taguais mes images avec latest et je passais à autre chose. Ça marchait, jusqu’au jour où un déploiement en production a ramené une version précédente sans que personne ne comprenne pourquoi. Depuis, le docker versioning est devenu un réflexe aussi naturel que le commit message dans mon workflow quotidien.

Dans ce guide, je vous partage tout ce que j’ai appris en dix ans de pratique : les conventions, les pièges, les automatisations qui changent la donne. Que vous soyez développeur solo ou que vous gériez une équipe, une stratégie de versioning claire pour vos images Docker vous évitera des heures de debugging et des sueurs froides en production.

Qu’est-ce que le docker versioning et pourquoi c’est indispensable

Le docker versioning désigne l’ensemble des pratiques qui permettent d’identifier de manière unique chaque version d’une image Docker. Concrètement, il s’agit d’attribuer des tags cohérents et prédictibles à vos images pour savoir exactement ce qui tourne sur chaque environnement.

Sans stratégie de versioning, vous naviguez à l’aveugle. Imaginez trois développeurs qui poussent chacun une image avec le tag latest dans la même journée. Laquelle tourne en staging ? Laquelle a été validée par la QA ? Impossible de le savoir. Le versioning résout ce problème en créant une correspondance univoque entre un tag et un état précis du code.

Les bénéfices concrets sont nombreux :

• Rollback instantané : en cas de bug, vous redéployez la version précédente en une commande
• Traçabilité complète : chaque image est liée à un commit, une branche, un pipeline
• Reproductibilité : un environnement de développement identique pour toute l’équipe
• Conformité : dans les secteurs réglementés, pouvoir prouver quelle version tournait à quel moment est obligatoire

Si vous travaillez déjà avec Git pour versionner votre code source, le docker versioning est la suite logique de cette démarche appliquée à vos artefacts de déploiement.

Les bases du tagging : comprendre les tags Docker

Un tag Docker est une étiquette textuelle attachée à une image. La syntaxe complète d’une référence d’image suit ce format : registry/repository:tag. Par exemple : ghcr.io/monprojet/api:2.4.1.

Quand vous exécutez docker build -t monapp:1.0.0 ., vous créez une image et lui attribuez le tag 1.0.0. Une même image peut porter plusieurs tags simultanément, ce qui est fondamental pour une bonne stratégie de versioning.

docker build -t monapp:2.1.0 -t monapp:2.1 -t monapp:2 -t monapp:latest .

Cette commande attribue quatre tags à la même image. L’utilisateur qui tire monapp:2 obtient toujours la dernière version 2.x.x, tandis que celui qui tire monapp:2.1.0 obtient une version figée. C’est le principe du tag flottant versus le tag fixe.

Quelques règles techniques à connaître :

• Un tag peut contenir des lettres, des chiffres, des points, des tirets et des underscores
• La longueur maximale est de 128 caractères
• Si vous ne spécifiez pas de tag, Docker utilise latest par défaut
• Un tag est un pointeur mutable : rien n’empêche de réassigner un tag existant à une nouvelle image

C’est cette mutabilité qui rend le versioning si important. Contrairement à un hash SHA256 (le digest de l’image), un tag peut changer de cible à tout moment. Pour une immutabilité totale, vous pouvez référencer une image par son digest : monapp@sha256:abc123....

Semantic versioning appliqué aux images Docker

Le semantic versioning (SemVer) est la convention la plus répandue pour versionner les images Docker. Le format est MAJOR.MINOR.PATCH, où chaque segment a une signification précise :

En pratique, je combine systématiquement le SemVer avec des tags de commodité. Quand je publie la version 3.2.1, je pousse les tags suivants :

# Tag fixe (immutable en pratique)
monapp:3.2.1

# Tags flottants (mis à jour à chaque release)
monapp:3.2
monapp:3
monapp:latest

Cette approche permet à chaque utilisateur de choisir son niveau de stabilité. Un environnement de production critique tirera 3.2.1 (version figée), tandis qu’un environnement de développement pourra utiliser 3 pour recevoir automatiquement les mises à jour mineures.

Le semantic versioning fonctionne particulièrement bien pour les images publiques et les bibliothèques partagées. Pour des applications internes, j’utilise souvent une variante qui inclut le numéro de build ou le hash de commit pour une traçabilité maximale.

Docker versioning : les best practices pour la production

Après des années à déployer des conteneurs en production, voici les règles que j’applique systématiquement et que je recommande à toutes les équipes.

Ne jamais utiliser latest en production

Le tag latest n’a aucune garantie de stabilité. Il pointe simplement vers la dernière image poussée, qui peut être une version de développement, un hotfix non testé ou une version complètement différente de ce que vous attendez. En production, utilisez toujours un tag explicite et versionné.

Adopter une convention de nommage cohérente

Votre équipe doit s’accorder sur un format unique. Voici les trois stratégies les plus courantes :

• SemVer pur : 3.2.1 pour les projets open source et les images publiques
• SemVer + hash : 3.2.1-a1b2c3d pour lier chaque image à un commit Git précis
• Date + hash : 20260506-a1b2c3d pour les déploiements continus où le SemVer serait artificiel

Utiliser les labels OCI pour enrichir les métadonnées

Les labels Docker permettent d’embarquer des métadonnées directement dans l’image. La spécification OCI Image Spec définit des labels standards :

LABEL org.opencontainers.image.version="3.2.1"
LABEL org.opencontainers.image.revision="a1b2c3d"
LABEL org.opencontainers.image.created="2026-05-06T10:30:00Z"
LABEL org.opencontainers.image.source="https://github.com/monorg/monapp"

Ces labels sont consultables avec docker inspect et permettent de retrouver l’origine exacte d’une image même si le tag a été réassigné.

Signer vos images

Le versioning ne sert à rien si quelqu’un peut remplacer une image signée par une version malveillante. Utilisez Docker Content Trust (Notary) ou cosign de Sigstore pour signer cryptographiquement vos images. C’est une pratique devenue standard dans les entreprises soucieuses de la sécurité de leur chaîne logicielle.

Documenter votre stratégie

Écrivez votre convention de versioning dans un fichier VERSIONING.md ou dans le README du dépôt. Incluez des exemples concrets de tags valides et invalides. Une convention non documentée est une convention qui sera ignorée.

Automatiser le versioning avec CI/CD et GitHub Actions

Le versioning manuel est une source d’erreurs. En automatisant via votre pipeline CI/CD, vous garantissez que chaque image est taguée de manière cohérente et reproductible. Voici un exemple concret avec GitHub Actions que j’utilise sur mes projets.

name: Build and Push Docker Image
on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ghcr.io/monorg/monapp
          tags: |
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=semver,pattern={{major}}
            type=sha,prefix=

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

L’action docker/metadata-action est un outil puissant qui génère automatiquement les tags en fonction du contexte Git. Quand vous poussez le tag v3.2.1, elle produit les tags 3.2.1, 3.2, 3 et le hash SHA du commit. Plus besoin de calculer quoi que ce soit manuellement.

Pour les projets qui n’utilisent pas le SemVer, vous pouvez configurer des tags basés sur la branche ou la date :

tags: |
  type=ref,event=branch
  type=raw,value={{date 'YYYYMMDD'}}-{{sha}}
  type=raw,value=latest,enable={{is_default_branch}}

L’automatisation du versioning s’intègre parfaitement dans une démarche DevOps complète où le pipeline gère le build, le test, le tagging et le déploiement sans intervention humaine.

Des outils comme Renovate ou Dependabot peuvent aussi surveiller les nouvelles versions de vos images de base et créer automatiquement des pull requests de mise à jour. Renovate utilise d’ailleurs son propre module de versioning Docker pour comprendre et comparer les tags d’images.

Docker est-il encore pertinent en 2026 ?

C’est une question que je vois revenir régulièrement dans les discussions techniques. La réponse courte : oui, Docker reste pertinent, mais le paysage a évolué.

Docker Desktop a connu des controverses liées à son modèle de licence payante pour les entreprises, ce qui a poussé certaines équipes vers des alternatives. Mais il faut distinguer Docker l’outil de Docker l’écosystème. Le format d’image Docker (désormais standardisé par l’OCI), les Dockerfiles et les registries restent la norme de l’industrie.

Voici où en sont les alternatives en 2026 :

• Podman : alternative rootless et daemonless, compatible avec les commandes Docker, populaire dans les environnements Red Hat et les contextes où la sécurité est prioritaire
• containerd : le runtime utilisé par Kubernetes en coulisses, suffisant si vous n’avez pas besoin des fonctionnalités haut niveau de Docker
• nerdctl : une CLI compatible Docker qui s’appuie sur containerd
• Buildah/Skopeo : outils spécialisés pour construire et manipuler des images sans démon Docker

Le point crucial : quelle que soit l’alternative choisie, les pratiques de versioning restent identiques. Le format OCI est commun à tous ces outils. Apprendre le docker versioning aujourd’hui vous servira même si vous migrez vers Podman demain.

Les raisons pour lesquelles certains quittent Docker sont principalement liées aux coûts de licence de Docker Desktop, à la surface d’attaque du démon Docker (qui tourne en root par défaut) et à la volonté de réduire les dépendances. Mais pour la majorité des équipes, Docker reste le choix le plus pragmatique et documenté.

Les erreurs courantes à éviter dans votre stratégie de versioning

En accompagnant des équipes sur leurs workflows Docker, je retrouve systématiquement les mêmes erreurs. Voici celles qui coûtent le plus cher.

Réutiliser un tag existant pour une image différente

Docker permet de réassigner un tag à une nouvelle image. Certaines équipes repoussent monapp:1.0.0 avec un contenu différent après un « petit fix ». C’est une violation du contrat de versioning qui détruit la confiance dans vos tags. Si 1.0.0 est publiée, le prochain fix doit être 1.0.1.

Ne pas versionner les images de base

Écrire FROM node:latest dans un Dockerfile revient à accepter n’importe quelle version de Node.js. Un jour vous compilez avec Node 20, le lendemain avec Node 22, et votre build casse mystérieusement. Spécifiez toujours une version précise :

# Mauvais
FROM node:latest
FROM python:3

# Bon
FROM node:20.12.2-alpine3.19
FROM python:3.12.3-slim-bookworm

Ignorer le multi-architecture

Avec la montée en puissance des processeurs ARM (Apple Silicon, AWS Graviton), vos images doivent souvent supporter plusieurs architectures. Votre stratégie de versioning doit en tenir compte avec des manifest lists qui regroupent les variantes sous un même tag.

Accumuler les images sans politique de rétention

Chaque pipeline qui pousse une image sans jamais en supprimer crée de la dette technique. Un registre qui stocke des milliers d’images obsolètes coûte cher en stockage et en temps de recherche. Définissez des règles de rétention : garder les 10 dernières versions de chaque branche, supprimer les images de branches mergées après 30 jours, conserver indéfiniment les releases taguées en SemVer.

Ne pas tester l’image avant de la taguer

Un tag de version implique que l’image a été validée. Votre pipeline devrait suivre cet ordre : build avec un tag temporaire, exécution des tests, puis promotion vers le tag définitif. Ce pattern de promotion d’image garantit que seules les images testées portent un tag de version.

Gérer le versioning dans Docker Hub et les registries privés

Le choix du registre influence directement votre stratégie de versioning. Docker Hub reste le registre public de référence, mais les registries privés offrent davantage de contrôle.

Docker Hub propose des fonctionnalités utiles pour le versioning : les automated builds liés à un dépôt Git, la visualisation des tags et de leur historique, et les webhooks pour déclencher des actions après un push. La limite du plan gratuit (un seul dépôt privé) pousse beaucoup d’équipes vers des alternatives.

Les registries privés les plus populaires en 2026 :

La fonctionnalité d’immutabilité des tags est particulièrement importante pour le versioning. Quand elle est activée, il devient impossible de pousser une nouvelle image sous un tag déjà existant. AWS ECR et Harbor proposent cette option nativement, ce qui renforce la fiabilité de votre convention de versioning.

Pour les équipes qui gèrent plusieurs projets, je recommande d’organiser les dépôts selon une convention de nommage claire : registry.exemple.com/equipe/projet/composant:version. Cette hiérarchie facilite la gestion des accès et la recherche d’images. Que vous utilisiez GitHub, GitLab ou un autre outil, intégrer le registre de conteneurs natif à votre plateforme simplifie considérablement le workflow.

Docker gère-t-il le contrôle de version à proprement parler ? Pas comme Git le fait pour le code. Docker n’a pas de notion de diff entre deux versions d’image ni de mécanisme de merge. Le versioning Docker est un système d’étiquetage, pas un système de contrôle de version. C’est pourquoi la combinaison avec Git est essentielle : Git versionne le code et le Dockerfile, Docker versionne l’artefact de build résultant.

Pour aller plus loin sur la conteneurisation et l’orchestration, je vous invite à consulter mon comparatif Kubernetes ou Docker qui détaille les cas d’usage de chaque outil. Et si le sujet du versioning d’outils frontend vous intéresse, mon article sur le versioning de React aborde des problématiques complémentaires.

Comprendre le logo Docker et son histoire peut sembler anecdotique, mais la baleine qui porte des conteneurs illustre parfaitement la philosophie de l’outil : transporter des paquets standardisés de manière fiable. Le versioning est ce qui garantit que le bon paquet arrive au bon endroit.