Release

Une release est la publication d’une nouvelle version d’un logiciel auprès de ses utilisateurs. En français, on parle aussi de mise en production, de livraison ou simplement de « nouvelle version ». Pour un produit SaaS, c’est le moment où le travail réalisé pendant un ou plusieurs sprints cesse d’être une ligne dans un outil de suivi et devient quelque chose que les clients voient, utilisent et, parfois, cassent.

Le mot désigne à la fois un objet (la version 2.4.0) et un processus : choisir ce qui part, le valider, le mettre en ligne par étapes, le surveiller et savoir revenir en arrière. Une équipe qui maîtrise ce processus livre souvent et sans drame. Une équipe qui ne le maîtrise pas livre rarement, avec appréhension, et chaque mise en ligne devient une soirée à risque. Pour un fondateur non technique, la qualité du processus de release est l’un des indicateurs les plus lisibles de la santé de son équipe de développement.

Release, déploiement, sprint : ce que chaque mot recouvre

Le déploiement est l’acte technique de copier du code sur les serveurs de production. Avec une chaîne CI/CD, il peut se produire dix fois par jour sans que personne à l’extérieur s’en aperçoive, parce que le code déployé n’est pas encore activé.

La release est la décision de rendre un ensemble de changements visible, de lui donner un numéro et de l’annoncer. Elle peut regrouper plusieurs jours de déploiements. Une release est une décision produit avant d’être une opération technique.

Le sprint est une unité de temps de travail, en général deux semaines. Il fixe le rythme des décisions, pas celui des mises en ligne : une équipe peut déployer chaque jour et publier une release par mois, ou l’inverse. Les feature flags rendent cette séparation possible : le code part en production quand il est prêt, la fonctionnalité s’allume quand le produit le décide.

Le versioning sémantique (semver)

La convention la plus répandue pour numéroter les releases est le versioning sémantique, ou semver, formalisé dans une spécification publiée en 2013 : MAJEURE.MINEURE.CORRECTIF.

Le chiffre majeur change quand la nouvelle version casse la compatibilité avec la précédente. En SaaS, où l’éditeur contrôle le serveur, c’est rare et cela concerne surtout les API exposées à des clients. Le chiffre mineur change quand des fonctionnalités s’ajoutent sans rien casser. Le correctif (patch) change pour une correction de bug. Passer de 1.4.2 à 1.5.0 annonce une nouveauté, passer à 1.5.1 annonce une réparation, passer à 2.0.0 prévient qu’il faudra peut-être adapter quelque chose de son côté.

Ce numéro est posé sur le dépôt de code sous forme de tag, ce qui relie chaque version à un état précis de l’historique Git. Des outils lisent les messages de commit rédigés selon la convention Conventional Commits et en déduisent seuls le numéro de version suivant et un brouillon de notes de version. Un hotfix est une release de correctif publiée en urgence, hors calendrier, pour réparer un problème bloquant en production.

Les trois stratégies de release

À intervalle fixe

Une nouvelle version sort chaque semaine, toutes les deux semaines ou chaque mois, avec ce qui est prêt à ce moment-là. Ce qui n’est pas prêt attend la suivante, et personne ne retarde le train pour un retardataire. Chrome fonctionne ainsi et publie une version majeure toutes les quatre semaines depuis 2021. Pour la plupart des SaaS en croissance, c’est le compromis le plus sain : le rythme est prévisible pour le support et les commerciaux, et chaque release reste assez petite pour qu’on sache d’où vient un problème.

En continu

Chaque changement validé part en production dans l’heure, parfois des dizaines de fois par jour. C’est le fonctionnement des grandes plateformes web, et il exige des tests automatisés très couvrants, une surveillance fine et des feature flags partout. Dans ce modèle, la release au sens de « version communiquée » devient une couche éditoriale posée sur un flux technique permanent : on regroupe les nouveautés du mois dans une annonce alors que le code est en ligne depuis des semaines.

En bloc (big bang)

Plusieurs mois de travail sont accumulés puis publiés d’un coup, souvent pour coïncider avec un lancement marketing. L’effet d’annonce est maximal, le risque aussi : plus une release contient de changements, plus il est long de trouver celui qui casse, et plus le retour arrière coûte cher. Les rapports du programme DORA de Google montrent depuis des années que les équipes qui livrent en petits lots ont moins d’incidents et les résolvent plus vite. Les retours des utilisateurs arrivent aussi des mois après les décisions qu’ils auraient dû corriger, ce qui alimente la dette technique.

Les étapes d’une release maîtrisée

Figer le périmètre

Quelques jours avant la date, l’équipe arrête la liste de ce qui part : les éléments du backlog terminés et validés, les corrections incluses, les dépendances entre eux. Ce qui arrive après cette date attend la release suivante. Sans ce gel, la release grossit jusqu’au dernier moment et la validation ne teste jamais la version qui part vraiment.

Valider

Les tests automatisés vérifient que les nouveautés fonctionnent et que l’existant n’a pas régressé. Une passe manuelle sur les parcours qui font vivre le produit (inscription, paiement, fonction principale) complète le filet. La code review intervient en amont, changement par changement. Avec la part croissante de code écrit par des assistants IA, cette relecture avant mise en production pèse plus qu’avant : notre article sur l’impact de l’IA sur la productivité des développeurs explique pourquoi. À la fin de cette étape, quelqu’un décide : on publie, ou on reporte.

Passer par la pré-production

L’environnement de pré-production (staging) est une copie de la production avec des données de test. On y rejoue la release dans des conditions réalistes, y compris les migrations de base de données. Publier sans staging revient à faire découvrir les bugs aux clients.

Déployer par paliers

Plutôt que d’exposer tous les utilisateurs d’un coup, le déploiement canary commence par une petite fraction du trafic, entre 1 et 10 %, et l’élargit palier par palier tant que les indicateurs restent normaux. Le blue-green maintient deux environnements de production identiques et bascule le trafic de l’un à l’autre ; revenir en arrière consiste à rebasculer. Les feature flags produisent le même effet à l’échelle d’une fonctionnalité, par segment de clients.

L’exemple qui a fait comprendre l’intérêt des paliers bien au-delà des équipes techniques date du 19 juillet 2024. CrowdStrike a poussé une mise à jour de configuration à l’ensemble de ses clients Windows en une seule fois. Microsoft a estimé à 8,5 millions le nombre de machines tombées en panne, avec des aéroports et des hôpitaux à l’arrêt. Le rapport d’incident de l’éditeur s’est conclu par la mise en place d’un déploiement progressif pour ce type de contenu.

Surveiller

Les premières heures décident du sort de la release. L’équipe suit le taux d’erreurs, les temps de réponse, les paiements et les parcours critiques, et compare avec la veille. Une version publiée à 18 h sans personne pour la regarder ensuite n’est pas une release surveillée. Le vieux débat sur le déploiement du vendredi se règle ainsi : la question porte moins sur le jour que sur la présence de quelqu’un pendant les heures qui suivent.

Savoir revenir en arrière

Le rollback est le retour à la version précédente. Il doit prendre quelques minutes et avoir été répété avant d’être nécessaire. La difficulté se cache presque toujours dans la base de données : le code se rembobine facilement, les données transformées par une migration beaucoup moins. Les équipes expérimentées écrivent leurs migrations pour que l’ancienne version du code continue de fonctionner sur le nouveau schéma, ce qui garde le rollback possible.

Le cas particulier des applications mobiles

Sur le web, l’éditeur contrôle ce que l’utilisateur voit. Sur mobile, non. Une release passe par la validation de l’App Store ou de Google Play, puis les utilisateurs mettent à jour quand ils le veulent, ce qui fait coexister plusieurs versions pendant des semaines. On ne peut pas retirer une version déjà installée : la seule correction est une nouvelle version, elle aussi soumise à validation. Les deux magasins proposent un déploiement progressif (la publication par phases d’Apple s’étale sur sept jours), et le serveur doit rester compatible avec les anciennes versions de l’application. Cela pousse les équipes mobiles à placer le maximum de logique côté serveur, où un correctif se publie en quelques minutes.

Les notes de version

Les notes de version (release notes ou changelog) sont ce que les utilisateurs lisent d’une release. Elles se rédigent pour eux, en partant du bénéfice et non de la technique. « Refonte de la couche d’authentification pour supporter OAuth2 » ne dit rien à un client. « Connectez-vous avec votre compte Google ou Microsoft » lui parle.

La convention Keep a Changelog propose un classement par catégories : ajouts, modifications, dépréciations, retraits, corrections, sécurité. Ce classement fait le lien avec semver et permet au lecteur de repérer en quelques secondes ce qui le concerne. Un changelog public qui précise quelles améliorations viennent de retours d’utilisateurs montre aux clients que signaler un problème sert à quelque chose, et ils continuent de le faire.

Les erreurs les plus fréquentes

Publier sans pré-production. Les bugs qu’un staging aurait révélés arrivent chez les clients.

Laisser grossir la release. Cinquante changements dans une version rendent le diagnostic d’une panne presque impossible. Il vaut mieux publier trois fois plus souvent des versions trois fois plus petites.

Ne pas prévenir en interne. Le support, les commerciaux et le product owner doivent connaître le contenu de la release avant les clients. Un client qui apprend une nouveauté à un conseiller support qui l’ignorait perd confiance dans les deux.

Découvrir le rollback dans l’urgence. Un plan de retour arrière qui n’a jamais été exécuté n’est pas un plan.

FAQ release

Quelle différence entre une release et un déploiement ?

Le déploiement est technique : du code est copié sur les serveurs. La release est la décision de rendre des changements visibles, de les numéroter et de les annoncer. Une release peut réunir plusieurs déploiements, et un déploiement peut ne contenir aucune nouveauté visible.

À quelle fréquence un SaaS doit-il publier des releases ?

Pour un produit en croissance avec une petite équipe, une à deux releases par semaine est un rythme sain : assez fréquent pour corriger vite et intégrer les retours, assez espacé pour valider et communiquer chaque version. Les équipes plus mûres déploient en continu et gardent une release annoncée par mois. Ce qui compte est la taille de chaque release, plus que son rythme.

Qu’est-ce qu’un hotfix ?

Un hotfix est une release corrective publiée en urgence, hors calendrier, pour réparer un problème bloquant en production. Elle ne contient que la correction, passe par une validation raccourcie et incrémente le troisième chiffre de la version.

Comment Polara Studio gère les releases

Chez Polara Studio, le processus de release se met en place pendant la première semaine d’un projet, avant la première fonctionnalité : pipeline CI/CD, environnement de pré-production, versioning sémantique et feature flags. Attendre d’avoir « quelque chose à publier » pour s’en occuper revient à improviser la première mise en ligne.

Nous recommandons à nos clients une à deux releases par semaine, avec un déploiement continu du code derrière des flags. La distinction entre code déployé et fonctionnalité visible permet de tenir ce rythme sans prendre de risque, et de choisir la date d’une annonce commerciale sans que ce choix pèse sur l’équipe technique.

Nous demandons enfin qu’un rollback soit exécuté au moins une fois en pré-production avant la première release publique, et que chaque mise en ligne soit suivie par quelqu’un qui sait quoi regarder pendant les heures qui suivent.