La numérotation de version n’est pas qu’un détail esthétique : c’est un outil de communication entre développeurs, testeurs, clients et machines. Bien choisie, elle permet de savoir en un coup d’œil :
- La stabilité du logiciel
- Le type de changements apportés
- La compatibilité avec les versions précédentes
Il existe plusieurs conventions, mais trois se démarquent dans l’industrie : Semantic Versioning (SemVer), Calendar Versioning (CalVer) et numérotation incrémentale.
Introduction au versionning
Qu’appelle‑t‑on “versionning” du code ?
Le versionning (ou versionning de code, parfois “versionnage” ^^) est l’ensemble des règles et outils qui permettent d’identifier l’état d’un logiciel à un instant T à l’aide d’un numéro de version (ex. 1.4.2), de tags Git, d’un CHANGELOG et d’un processus de publication cohérent.
Objectif : rendre traçables les changements, prévisibles les mises à jour, et maîtrisés les impacts sur la production.
Pourquoi c’est crucial (et trop souvent sous‑estimé)
Bien trop souvent, la numérotation de version est reléguée au second rang par les équipes logicielle alors qu'elle apporte beaucoup d'informations majeures :
- Lisibilité produit : un numéro encode l’ampleur des changements. Vos parties prenantes comprennent le risque sans lire tout le code.
- Compatibilité & SLA : savoir si une mise à jour casse des API évite des incidents coûteux.
- Audit & conformité : tags, notes de release et artefacts versionnés simplifient audits et support.
- Déploiements sûrs : l’intégration du versionning en CI/CD permet des rollbacks rapides et des releases reproductibles.
- Écosystème : pour des bibliothèques internes/externes, des versions claires construisent la confiance des équipes consommatrices et clients.
Numérotation incrémentale
La numérotation incrémentale est surement l'une des plus simple et qui vient souvent en premier dans l'esprit des développeurs. Mais c'est aussi la numérotation qui apporte le moins d'informations
Comment ça marche la numérotation incrémentale ?
Le format est le suivant: vN.M:
- On incrémente le numéro principal à chaque version
- Optionnellement, un numéro secondaire pour des petites évolutions
- L'incrémentation est au jugement de l'équipe de développement
Exemple concret pour la numérotation incrémentale
Voici l'exemple d'un projet qui utilise la numérotation incrémentale:
- v1 : Première version publique
- v2 : Ajout de fonctionnalités
- v2.1 : Mise à jour mineure ou correction de bug
- v3.0 : Révision majeure du produit
Avantages de la numérotation incrémentale
- Simple et rapide à mettre en place
- Pas de règle complexe à retenir
Limites de la numérotation incrémentale
- Ne donne aucune indication sur la compatibilité ou la nature du changement
- Moins précis pour les projets avec beaucoup de mises à jour
Calendar Versioning (CalVer)
Le calendar versioning est un système de numérotation de version très utilisé, notamment sur les logiciels à mises à jour fréquentes ou cycliques. Pour donner un exemple, nous pouvons évoquer Ubuntu (25.04, 22.10, ...). Comme son nom l'indique, la version est basée sur la date de sortie
Comment ça marche le calendar versioning ?
Le format est le suivant: AAAA.MM.PATCH-PHASE+BUILD:
- AAAA : Année de sortie de la version
- MM : Mois de sortie de la version
- PATCH : Patch ou numéro supplémentaire possible pour plusieurs sorties dans un même mois
- PHASE : Optionnel, pour indiquer la phase de production (ex: RC, release, dev, ...)
- BUILD : Optionnel, numéro du build associé a cette version
Exemple concret pour le calendar versioning
Voici l'exemple d'un projet qui utilise le calendar versionning :
- 2025.01 : Version de janvier 2025
- 2025.01.1 : Correctif publié quelques jours plus tard (on a oublié de tester son code ? ^^)
- 2025.08 : Nouvelle version majeure publiée en août 2025
Avantages du calendar versioning
- Lisible immédiatement (on sait quand la version est sortie)
- Utile pour les logiciels à mises à jour fréquentes ou cycliques
Limites du calendar versioning
- Ne donne pas d’information explicite sur la compatibilité ou l’importance des changements
Semantic Versioning (SemVer)
Le semantic versioning est surement le plus connus des systèmes de version. Parmi les 3 présentés dans cet article, c'est clairement celui qui apporte le plus d'informations sur les changements apportés au code source.
Comment ça marche le semantic versioning ?
Le format est le suivant: MAJEUR.MINOR.PATCH-PHASE+BUILD :
- MAJEUR : Changements incompatibles avec les versions précédentes (breaking changes)
- MINOR : Nouvelles fonctionnalités compatibles avec les versions existantes
- PATCH : Corrections de bugs ou ajustements mineurs sans impact sur la compatibilité
- PHASE : Optionnel, pour indiquer la phase de production (ex: RC, release, dev, ...)
- BUILD : Optionnel, numéro du build associé a cette version
Exemple concret du semantic versioning
Imaginons une application de gestion de tâches :
- 1.0.0 : Première version stable
- 1.1.0 : Ajout d’un module de statistiques
- 1.1.1 : Correction d’un bug d’affichage
- 2.0.0 : Réécriture complète du moteur, incompatibilité avec les anciennes sauvegardes
Avantages du semantic versioning
- Très clair pour les développeurs et utilisateurs
- Aide à la gestion des dépendances dans les projets complexes
Limites du semantic versioning
- Demande de la discipline : il faut respecter la signification des numéros, sinon on donne une fausse information
Les conseil et bonnes pratiques HexoTech
Relier versions, Git et CI/CD
Versionner son code, c’est une bonne pratique universelle.
Mais ce geste devient réellement puissant lorsqu’il est parfaitement intégré à votre usine logicielle, c’est-à-dire à vos processus Git, à vos pipelines CI/CD et à votre gestion des releases.
Chez HexoTech, nous recommandons par exemple :
Chaque release doit être associée à un tag Git immuable (par exemple v1.6.0), idéalement signé avec GPG pour certifier son authenticité. Avant ce tag, il est préférable de stabiliser le code dans une branche dédiée puis de générer les artefacts correspondants : binaires, images Docker, charts Helm, etc.
Un CHANGELOG clair peut ensuite être produit automatiquement à partir de messages de commit normalisés (Conventional Commits). Cette approche évite d’oublier des changements et garantit un format homogène.
Bien sûr, avant toute publication, un gate de qualité doit bloquer la release si les tests, les analyses de sécurité (SAST/DAST) ou les métriques de qualité ne sont pas satisfaisants. Enfin, un même artefact doit pouvoir être promu d’un environnement staging à la production sans modification, assurant ainsi que ce qui a été testé est exactement ce qui est déployé.
Monorepo et Multi-repo : comment gérer les versions ?
Le choix entre un monorepo (plusieurs projets dans un même dépôt) et un polyrepo (un dépôt par projet) a un impact direct sur la stratégie de versioning.
Dans un monorepo, on peut opter pour une version globale — toutes les bibliothèques partagent la même version (1.8.0). C’est simple, mais cela génère parfois du bruit inutile côté consommateurs : certaines mises à jour ne les concernent pas.
L’alternative est de gérer une version par package, plus précise mais demandant des outils spécialisés comme Lerna, Nx ou Changesets pour automatiser le processus.
En polyrepo, chaque dépôt gère sa propre version, ce qui simplifie la maintenance individuelle. Cependant, si plusieurs projets doivent évoluer ensemble, il faut prévoir un mécanisme d’orchestration pour coordonner les releases.
Les bonnes pratiques autour du versioning
Au fil de nos interventions, nous avons identifié un socle de pratiques efficaces pour fiabiliser le versioning :
Nous conseillons de partir sur SemVer par défaut, que ce soit pour vos services, applications ou bibliothèques internes. Les messages de commit devraient être normalisés (Conventional Commits) et contrôlés automatiquement dans la CI.
Le bump de version et la création des tags doivent être entièrement automatisés à partir de l’historique Git. À chaque release, générez un CHANGELOG lisible par tous — pas seulement par les développeurs — et conservez une archive signée des artefacts produits.
Les ruptures de compatibilité doivent toujours être documentées dans une section “Breaking Changes” dédiée. Enfin, votre politique de support (versions maintenues, LTS, délais de correction de failles) doit être clairement communiquée et vos équipes formées pour que cette rigueur devienne un réflexe partagé.
Les erreurs fréquentes à éviter avec le versioning
Certaines mauvaises pratiques reviennent souvent chez nos clients, avec des conséquences coûteuses.
Par exemple, sauter des versions sans explication claire peut faire perdre confiance aux utilisateurs.
Publier des patchs non tagués rend parfois impossible la reconstruction d’un build précis.
Autre piège : laisser passer des pré-releases en production par accident — une séparation stricte des droits et des canaux de déploiement est indispensable.
Un CHANGELOG purement marketing prive les intégrateurs des détails techniques dont ils ont besoin. Et lors d’une mise à jour majeure (MAJEUR), il est impératif de prévenir les consommateurs d’API et de fournir un guide de migration précis.
Comment HexoTech peut vous accompagner
Chez HexoTech, nous aidons des organisations technologiques et industrielles — comme Safran, ArcelorMittal, Pasqal ou Damae Medical — à mettre en place des conventions de version solides et à les intégrer dans des pipelines CI/CD modernes.
Nos experts (10 à 15 ans d’expérience) interviennent du cadrage à l’automatisation complète, puis transmettent leurs pratiques pour garantir l’autonomie de vos équipes.
📩 Vous souhaitez structurer votre versioning ou former vos équipes ?
Contactez-nous : contact@hexotech.com
Conclusion : sur le versioning de votre code
Bien gérer les numéros de version, c’est industrialiser la confiance : vos équipes livrent plus vite, vos utilisateurs mettent à jour sereinement, et votre dette technique baisse. En adoptant SemVer + Conventional Commits, un CHANGELOG automatique et un pipeline CI/CD rigoureux, vous obtenez des releases prédictibles, auditées et sûres.
HexoTech peut vous accompagner pour concevoir vos conventions, outiller vos pipelines et former vos équipes — de la définition à l’exécution. Parlons‑en.
FAQ – Versionning du code source
1) SemVer ou CalVer : comment choisir ?
Si vous exposez des API et tenez à la compatibilité, choisissez SemVer. Si votre enjeu principal est le rythme (produit cloud avec releases fréquentes), CalVer + canaux peut être pertinent.
2) Comment gérer les breaking changes sans bloquer les clients ?
Annoncez tôt, offrez une coexistence temporaire (dépréciation), fournissez guides de migration, et planifiez la fenêtre de bascule. Évitez les ruptures surprises.
3) Faut‑il tagger chaque build ?
Taggez chaque release destinée aux utilisateurs. Les builds intermédiaires restent identifiables via metadata (+build.N) et le SHA Git.
4) Comment tenir un bon CHANGELOG ?
Automatisez le à partir des commits, regroupez par feat/fix/perf/refactor, mettez en avant les breaking changes et les impacts pour les intégrateurs.
5) Que faire dans un monorepo avec plusieurs packages ?
Soit une version globale si vos modules évoluent ensemble, soit des versions indépendantes par package avec un outil (Changesets, Nx, Lerna) pour ne publier que ce qui a changé.
6) Comment éviter les versions “fantômes” ?
Interdisez les commits directement sur main, forcez le merge via PR, et laissez la CI produire la version et le tag. Tout artefact release doit être traçable à un tag.
7) HexoTech peut elle nous accompagner dans la mise en place de notre gestion de version ?
Oui, et nous pouvons en parallèle vous former. Contactez nous !
