Versioning – gestion de versions

Pratique qui consiste à attribuer des identifiants uniques (numéros, dates, tags) aux différentes versions d’un fichier, d’un logiciel, d’une API ou d’un jeu de données, afin de suivre les évolutions dans le temps.

Le versioning permet de :

• Conserver l’historique des modifications,
• Revenir à une version antérieure en cas d’erreur,
• Travailler en parallèle sur plusieurs évolutions (ex. : correctifs vs nouvelles fonctionnalités),
• Garantir la compatibilité (ex. : une API en v1 ne casse pas les apps conçues pour elle),
• Documenter les changements (via des fichiers CHANGELOG.md, des tags Git, etc.).

Il est au cœur des pratiques modernes :

• Développement logiciel (Git, GitHub, GitLab),
• Infrastructures (Terraform avec version de modules),
• Données (datasets versionnés avec DVC ou Git LFS),
• API (/api/v1/, /api/v2/),
• Packages (package.json, composer.json).

Exemples concrets

• Git : chaque commit est une version ; les tags comme v2.1.0 marquent des versions stables.
• API REST : https://api.monsite.fr/v1/utilisateurs
• Packages npm : "express": "^4.18.2" → version contrôlée via SemVer.
• Données ouvertes : un jeu de données mis à jour mensuellement avec un numéro de version (population_insee_2025_v3.csv).

Schéma de versioning : SemVer (Semantic Versioning)

La norme la plus utilisée : MAJOR.MINOR.PATCH

• PATCH (1.0.1) : correction de bug, rétrocompatible
• MINOR (1.1.0) : nouvelles fonctionnalités, rétrocompatible
• MAJOR (2.0.0) : modifications non rétrocompatibles