Beaucoup de gens lisent « 2.10 » comme « deux virgule dix » et en concluent qu'il s'agit d'une édition plus ancienne que la 2.9. C'est l'inverse : la 2.10 vient après la 2.9, parce qu'un numéro de version n'est pas un nombre décimal. Le point sépare des compteurs indépendants, et le deuxième compteur est simplement passé de 9 à 10.
L'Office québécois de la langue française le rappelle dans sa fiche terminologique : on numérote une version avec le point et non avec la virgule, selon la logique des divisions d'un texte (1.1, 1.2.1), justement parce que la virgule marque en français une valeur décimale. Une fois cette idée reçue écartée, le reste de la numérotation devient beaucoup plus lisible.
Ce que désigne le mot version en informatique
Le Grand dictionnaire terminologique définit la version comme l'édition d'un logiciel. Le mot recouvre pourtant deux réalités que l'anglais distingue : la version, édition publiée et identifiée par un numéro, et le build, c'est-à-dire chaque compilation produite par l'équipe de développement, parfois plusieurs par jour. Quand un éditeur parle de « nouvelle version », il s'agit presque toujours du premier sens.
La même fiche signale le terme « mouture », employé à tort comme synonyme : il désigne plutôt un logiciel encore en développement, pas encore distribué. Elle note aussi que l'anglais release renvoie le plus souvent à la dernière version disponible, ou à une mise à jour.
Retenir ces nuances aide à lire une note de mise à jour : « build 4512 » renvoie à une compilation interne, tandis que « version 3.2 » désigne ce que l'utilisateur installe.
Les trois chiffres d'un numéro de version
Le système le plus répandu chez les développeurs est la gestion sémantique de version, publiée sous le nom Semantic Versioning (SemVer), dont la spécification 2.0.0 existe en français. Elle impose un format à trois entiers, MAJEUR.MINEUR.CORRECTIF, sans zéro en tête : on écrit 1.4.0, jamais 01.04.00.
Le premier chiffre : rupture de compatibilité
Le numéro majeur augmente lorsqu'un changement n'est pas rétrocompatible avec l'interface publique du logiciel. Concrètement, ce qui fonctionnait avec la 2.x risque de ne plus fonctionner tel quel avec la 3.0 : une fonction supprimée, un format de fichier modifié, une option renommée. Quand le majeur augmente, les deux autres chiffres repartent à zéro : après 2.7.4 vient 3.0.0.
La fiche de l'OQLF décrit la même logique pour les logiciels grand public, avec un exemple daté : une modification majeure, comme un changement d'architecture, fait passer WordPerfect de 6.1 à 7.0.
Le deuxième chiffre : ajouts compatibles
Le numéro mineur augmente quand le logiciel gagne des fonctionnalités sans casser l'existant. SemVer y range aussi l'annonce qu'une fonctionnalité deviendra obsolète : on la signale dans une version mineure, avec la documentation correspondante, avant de la retirer lors d'un passage de version majeure. Le chiffre correctif revient alors à zéro : après 2.7.4 vient 2.8.0.
Le troisième chiffre : corrections
Le numéro correctif, souvent appelé patch, signale des corrections de bogues rétrocompatibles, sans nouvelle fonction. Passer de 2.8.0 à 2.8.1 ne change rien à l'usage, mais corrige un défaut, parfois une faille de sécurité. C'est en général la mise à jour la moins risquée à installer.
| Changement | Chiffre qui augmente | Exemple | Effet attendu pour l'utilisateur |
|---|---|---|---|
| Rupture de compatibilité | Majeur | 2.7.4 → 3.0.0 | Vérifier ses habitudes, fichiers ou extensions |
| Nouvelle fonction compatible | Mineur | 2.7.4 → 2.8.0 | Nouveautés sans perte |
| Correction de bogue | Correctif | 2.8.0 → 2.8.1 | Même usage, défaut corrigé |
La phase 0.y.z et le cap de la version 1.0.0
Un logiciel en développement initial porte un numéro qui commence par zéro, par exemple 0.3.2. Selon la spécification, tout peut changer à tout moment pendant cette phase : l'interface publique n'est pas considérée comme stable. La FAQ de SemVer conseille de démarrer à 0.1.0 et d'augmenter le chiffre mineur à chaque publication.
La version 1.0.0 marque le moment où l'interface publique est fixée. La même FAQ est explicite : un logiciel déjà utilisé en production, ou dont d'autres programmes dépendent, devrait déjà être en 1.0.0. Un projet qui reste des années en 0.x signale donc, au sens strict, qu'il ne s'engage pas encore sur sa compatibilité.
Alpha, beta, rc : lire les suffixes
Un tiret placé après les trois chiffres introduit une préversion, c'est-à-dire une édition jugée instable qui ne remplit peut-être pas encore toutes les exigences de la version finale. La spécification donne notamment 1.0.0-alpha, 1.0.0-alpha.1 ou 1.0.0-0.3.7 comme exemples. Les identifiants n'utilisent que des lettres et chiffres ASCII et des tirets.
Les étiquettes les plus courantes suivent l'avancement du travail :
- alpha : premières éditions, fonctionnalités encore incomplètes ;
- beta : fonctionnalités en place, phase de test plus large ;
- rc (release candidate, version candidate) : édition qui deviendra la version finale si aucun défaut bloquant n'apparaît.
Point essentiel : une préversion passe toujours avant la version normale de même numéro. La 1.0.0-rc.1 est antérieure à la 1.0.0. Installer une beta revient donc à accepter une édition provisoire, ce qui se justifie pour tester, beaucoup moins pour un poste de travail dont on dépend.
Le signe plus et les métadonnées de build
Un signe « + » introduit des métadonnées de build, par exemple 1.0.0+20130313144700 dans la spécification. Ces informations (date de compilation, identifiant interne) servent à tracer une édition, mais elles sont ignorées quand on compare deux versions : deux éditions qui ne diffèrent que par ce suffixe ont la même priorité.
Comparer deux versions sans se tromper
La règle de précédence de SemVer tient en quelques étapes. On compare d'abord le majeur, puis le mineur, puis le correctif, chacun numériquement. C'est ce qui place 2.10.0 après 2.9.0 : 10 est plus grand que 9. Si les trois chiffres sont égaux, l'édition sans suffixe l'emporte sur la préversion.
Entre deux préversions, les identifiants séparés par des points se comparent de gauche à droite : ceux qui ne contiennent que des chiffres se comparent comme des nombres, les autres par ordre alphabétique ASCII, et un identifiant numérique passe avant un identifiant alphabétique. La spécification donne cette suite complète, de la plus ancienne à la plus récente :
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
On y voit que beta.11 suit beta.2 : là encore, 11 se lit comme un nombre et non comme du texte.
Autres façons de numéroter
SemVer n'est pas une obligation. Certains éditeurs utilisent une numérotation calendaire, fondée sur l'année et le mois de sortie, d'autres un nom commercial ajouté au numéro, d'autres encore une numérotation interne distincte de celle affichée au public. Le premier réflexe face à un numéro inhabituel consiste à chercher la page de notes de version de l'éditeur, qui explique son propre système.
Le numéro peut aussi se trouver accompagné d'un numéro de build plus long, utile au support technique. Pour connaître la version d'un programme installé, le chemin le plus courant reste le menu Aide, rubrique « À propos », ou la page d'informations dans les paramètres de l'application ou de l'appareil.
Les services utilisés directement dans le navigateur, comme un espace numérique de travail scolaire, se mettent en général à jour côté serveur : l'utilisateur n'a rien à installer et travaille sur l'édition en ligne du moment, souvent sans numéro visible.
Pourquoi les éditeurs tiennent à ces numéros
Un numéro bien tenu remplit plusieurs fonctions. Il identifie sans ambiguïté ce qui est installé, ce qui permet au support de reproduire un problème. Il annonce le risque d'une mise à jour : un saut de majeur appelle une lecture attentive des notes, un correctif se pose en général sans inquiétude. Il permet enfin aux programmes qui dépendent d'une bibliothèque de fixer une plage acceptable, par exemple « toute 2.x à partir de 2.4 ».
La spécification ajoute une règle de discipline : une fois publiée, une version ne doit plus être modifiée. Si une rupture s'est glissée par erreur dans une version mineure, il faut publier une nouvelle version qui rétablit la compatibilité, et non retoucher l'ancienne. C'est cette stabilité qui donne sa valeur au numéro.
Le journal des modifications
Les numéros vont de pair avec un journal des modifications (changelog) qui liste, version par version, les ajouts, les corrections et les retraits. Il permet de savoir si une mise à jour corrige un défaut rencontré, ou si elle modifie une fonction utilisée tous les jours.
Questions fréquentes
La version 2.10 est-elle plus récente que la 2.9 ?
Oui. Chaque chiffre se compare séparément et numériquement : 10 étant supérieur à 9, la 2.10 vient après la 2.9. Le point n'est pas une virgule décimale.
Quelle différence entre version majeure et version mineure ?
Une version majeure introduit des changements non rétrocompatibles ; une version mineure ajoute des fonctionnalités en conservant la compatibilité avec l'existant.
Que veut dire rc dans un numéro de version ?
Rc signifie release candidate, version candidate : une préversion proche de l'édition finale. Elle reste antérieure à la version sans suffixe portant le même numéro.
Pourquoi certains logiciels restent-ils en version 0.x ?
Le zéro initial indique un développement initial dans lequel l'interface publique n'est pas stable. Le passage à 1.0.0 marque l'engagement sur cette interface.
Version et build, est-ce la même chose ?
Non. La version est l'édition publiée et numérotée ; le build est une compilation produite pendant le développement. En gestion sémantique, des métadonnées de build peuvent suivre un « + », sans compter dans la comparaison.
Sources et références
- Semantic Versioning, Gestion sémantique de version 2.0.0 (traduction française) — semver.org
- Office québécois de la langue française, Grand dictionnaire terminologique, fiche « version » — vitrinelinguistique.oqlf.gouv.qc.ca
