Versioning (ou Gestion de versions)

Le versioning, ou gestion de versions, est la pratique consistant à enregistrer l'historique des modifications d'un ensemble de fichiers — le plus souvent du code — afin de savoir qui a changé quoi, quand et pourquoi, de revenir à un état antérieur et de travailler à plusieurs sans s'écraser mutuellement.

L'alternative se reconnaît immédiatement : un dossier contenant site_v2, site_v2_corrigé et site_v2_final_ok, dont plus personne ne sait lequel est en ligne. Un système de gestion de versions remplace cette accumulation par un historique structuré, où chaque état passé reste accessible et explicable.

Comment ça marche

Git s'est imposé comme le standard. Chaque développeur dispose d'une copie complète du dépôt et de son historique, ce qui permet de travailler hors ligne. On enregistre un instantané du travail, appelé commit, accompagné d'un message qui en explique l'intention. On isole un travail en cours sur une branche, puis on la fusionne dans la branche principale, en résolvant les éventuels conflits. Un dépôt distant, hébergé sur une plateforme comme GitHub ou GitLab, sert de point de synchronisation et de lieu de relecture via des demandes de fusion. Une étiquette marque les versions livrées.

Le mot recouvre aussi la numérotation des versions publiées. La convention la plus répandue, dite versionnage sémantique, utilise trois nombres : le premier change en cas de rupture de compatibilité, le deuxième pour un ajout compatible, le troisième pour une correction.

À quoi ça sert concrètement

• Revenir à un état fonctionnel en quelques secondes après une régression en production
• Permettre à plusieurs personnes de modifier le même projet en parallèle
• Faire relire le code avant intégration, ce qui reste le meilleur filtre à défauts
• Retrouver par recherche dichotomique le changement exact qui a introduit un bug
• Fournir une traçabilité exploitable en audit et déclencher l'automatisation des tests et déploiements

Les pièges

Le plus grave est la fuite de secrets. Un fichier d'environnement ou une clé d'API poussés une seule fois restent dans l'historique même après suppression : il faut révoquer la clé, pas seulement effacer la ligne.

Viennent ensuite les commits fourre-tout accompagnés d'un message « fix », qui rendent l'historique inutilisable et annulent l'intérêt de l'outil ; les branches maintenues des semaines, dont la fusion devient un chantier ; les fichiers binaires lourds qui font gonfler le dépôt indéfiniment ; et la réécriture d'historique forcée sur une branche partagée, qui fait perdre du travail aux autres.

Quand l'adopter, quand s'en passer

Toujours, y compris seul et y compris pour un site vitrine : aucun projet ne justifie l'absence de gestion de versions. La vraie question n'est pas s'il en faut une, mais quelle stratégie de branches adopter — un modèle simple centré sur la branche principale pour les équipes qui déploient souvent, un modèle plus formel quand les livraisons suivent des cycles espacés.