Versioning sémantique

Le versioning sémantique (SemVer) numérote les versions en MAJOR.MINOR.PATCH pour signaler un changement majeur, un ajout de fonction ou une correction.
Webapp
Created on
23.09.2026

Résumer avec

Le versioning sémantique, souvent abrégé SemVer, est une convention de numérotation de version pour les logiciels : MAJOR.MINOR.PATCH (par exemple 2.4.1), où chaque partie signale un type de changement précis.

Qu'est-ce que le versioning sémantique ?

Un développeur ou un gestionnaire de paquets peut savoir, rien qu'en lisant une chaîne de version, si une mise à jour de dépendance est sûre ou risque de casser quelque chose. Le SemVer a été formalisé par Tom Preston-Werner et constitue aujourd'hui le standard de facto sur npm, Composer, Cargo et la plupart des écosystèmes de paquets modernes.

Comment fonctionnent les numéros de version

Pour une version MAJOR.MINOR.PATCH :

  • MAJOR s'incrémente lors d'un changement incompatible qui casse la compatibilité (1.9.0 vers 2.0.0).
  • MINOR s'incrémente quand une fonctionnalité est ajoutée de façon rétrocompatible (2.0.0 vers 2.1.0).
  • PATCH s'incrémente pour une correction de bug rétrocompatible (2.1.0 vers 2.1.1).

Une dépendance déclarée ^2.1.0 dans un package.json indique à un gestionnaire de paquets qu'il peut installer sans risque toute version 2.x.x, mais jamais 3.0.0, puisque cela signalerait un changement majeur.

Pré-versions et métadonnées de build

Le SemVer définit aussi des suffixes optionnels pour les versions qui ne sont pas encore stables :

  • 1.0.0-alpha, 1.0.0-beta.2, 1.0.0-rc.1 : identifiants de pré-version, classés avant la version finale.
  • 1.0.0+20260923 : métadonnées de build, ignorées lors de la comparaison de priorité entre versions.

Versioning sémantique vs versioning calendaire

AspectSemVerCalVer (versioning calendaire)
FormatMAJOR.MINOR.PATCHAAAA.MM ou AA.MM.JJ
SignaleLa compatibilité de l'APILa date de sortie
Idéal pourBibliothèques, API, paquetsProduits à sorties fréquentes rythmées par le calendrier

Bonnes pratiques et pièges courants

Incrémentez le MAJOR pour chaque changement cassant, même minime, car les consommateurs du paquet se fient à ce signal pour décider de mettre à jour automatiquement ou non. Une erreur fréquente consiste à livrer un changement cassant dans une version MINOR ou PATCH, ce qui casse silencieusement les projets en aval qui faisaient confiance à la plage de version. Utilisez des tags de pré-version comme -beta ou -rc pour laisser les premiers utilisateurs tester les changements avant une version stable, et documentez les changements cassants dans un changelog à chaque incrément MAJOR.

Impact sur la compatibilité

Le versioning sémantique influence directement la sécurité avec laquelle un projet peut automatiser ses mises à jour de dépendances. Des outils comme Dependabot ou Renovate s'appuient sur le signal MAJOR.MINOR.PATCH pour décider quelles mises à jour peuvent être fusionnées automatiquement et lesquelles nécessitent une revue manuelle : un projet qui ne respecte pas correctement le SemVer fragilise cette automatisation et augmente le risque qu'un changement cassant atteigne la production sans être détecté.

Le versioning sémantique chez BeBranded

Nous appliquons le versioning sémantique sur les applications web et intégrations que nous construisons et maintenons, afin que les mises à jour de dépendances restent prévisibles et qu'un changement cassant ne surprenne jamais un client en production.

FAQ

SemVer est l'abréviation de semantic versioning (versioning sémantique), un système de numérotation MAJOR.MINOR.PATCH pour les versions logicielles.
Dès qu'un changement casse la compatibilité ascendante, même un petit changement d'API dont dépendent des consommateurs existants.
MINOR ajoute une nouvelle fonctionnalité rétrocompatible ; PATCH ne fait que corriger des bugs, sans ajouter de fonctionnalité ni rien casser.
Il indique au gestionnaire de paquets d'accepter toute version dans la même release MAJOR, par exemple ^2.1.0 autorise 2.x.x mais pas 3.0.0.
Une version marquée d'un suffixe comme -beta ou -rc, utilisée pour tester des changements à venir avant une version stable, classée avant la version finale.
Non, c'est une convention. Les projets choisissent de la suivre, et des écosystèmes comme npm dépendent du respect de cette convention par les mainteneurs pour que les mises à jour automatiques fonctionnent en toute sécurité.

Prêt à booster vos conversions ?

Notre équipe est là pour comprendre vos besoins et travailler avec vous pour créer vos prochains projets.
Recevez des news et des ressources.
Des conseils pratiques directement dans votre boîte mail.
Merci ! Votre demande a bien été reçue.
Oups ! Une erreur est survenue lors de l'envoi du formulaire.