Pourquoi vos branches d'environnement vous ralentissent, comment les équipes les plus rapides du monde s'en sont débarrassées, et ce que ça change concrètement dans votre code.
L'article progresse en trois parties, de plus en plus profondes : les experts sont servis à la fin.
Il est 18 h 47, un jeudi La feature est prête depuis neuf jours.
Testée, validée, approuvée.
Mais elle ne partira pas en production ce soir, ni demain : elle est coincée sur la branche , mélangée à deux autres features qui, elles, ne sont pas prêtes.
Impossible de livrer l'une sans embarquer les autres.
Alors on attend.
Ou pire : on tente un cherry-pick chirurgical vers , en croisant les doigts pour que les commits ne se marchent pas dessus.
Si cette scène vous parle, votre équipe utilise des branches d'environnement : une branche ou qui accumule les features en test, une branche qui représente la production, et des merges rituels entre les deux.
C'est le modèle le plus répandu du monde.
C'est aussi celui que Google, Meta, Netflix et toutes les équipes mesurées comme les plus performantes ont abandonné il y a quinze ans.
Le problème n'est pas votre équipe.
Le problème est qu'une branche Git est un très mauvais outil pour répondre à la question « qu'est-ce qui est activé, pour qui, en ce moment ? » L'anatomie du mal Le modèle à branches d'environnement repose sur une équivalence séduisante, une branche = un environnement = un état du produit, qui se dégrade pour trois raisons mécaniques.
D'abord, la branche d'intégration dérive.
Chaque feature mergée dans mais pas encore en prod creuse l'écart avec : features abandonnées, correctifs en double, conflits résolus différemment de chaque côté.
Ce qu'on teste n'est plus ce qu'on livrera.
Ensuite, livrer devient un problème de soustraction.
Sortir la feature A sans la B exige de l'extraire de la masse : cherry-picks, merges sélectifs, et un code en prod qui n'est jamais exactement celui qui a été validé.
Enfin, déployer et livrer sont le même geste.
Activer une feature exige de pousser du code ; la désactiver aussi.
Chaque mise en prod devient un événement qu'on espace, donc qui grossit, donc qui fait peur, donc qu'on espace encore.
Le cercle est vicieux et bien documenté.
Ce que disent les chiffres Le programme de recherche DORA (Google Cloud) mesure depuis 2014 la performance de milliers d'équipes, et son résultat le plus contre-intuitif est solide : les équipes qui déploient le plus souvent sont aussi celles qui ont le moins d'incidents.
La sécurité ne vient pas de la prudence des gros déploiements espacés ; elle vient de la petitesse de chaque changement.
Les solutions, dans l'ordre où on les découvre Il n'y a pas un modèle à adopter d'un bloc, et c'est le point que la plupart des articles ratent.
Le chemin passe par des solutions intermédiaires, et chacune est un état stable où une équipe peut s'installer durablement.
Ce qui pousse à la suivante n'est pas la mode ; c'est un échec précis, qu'on va raconter à chaque fois.
Une seule branche de vérité La première réponse à la dérive des branches d'environnement ne demande aucun outillage nouveau, seulement trois règles.
La branche principale est protégée : push direct interdit, merge request obligatoire, pipeline vert requis.
Les branches de feature sont courtes : quelques jours au plus, une feature = une branche = une MR.
Et les environnements se déploient depuis des tags, jamais depuis des branches dédiées : staging redevient un endroit où l'on déploie un commit précis de , pas une branche qui accumule.
La règle de livraison est alors simple : on ne merge que ce qu'on est prêt à livrer.
La validation se fait avant le merge, sur la branche de feature.
C'est le « GitHub Flow » classique, et il résout déjà le cœur du problème : plus de dérive, ce qu'on teste est ce qu'on livre.
Vous pouvez vous arrêter ici si vous livrez une feature à la fois et que la validation est rapide.
Beaucoup de petites équipes vivent très bien avec ce modèle, et n'ont besoin de rien de plus.
Trois mois plus tard, mardi, 9 h
05.
Le tableau des merge requests affiche quatre features « en attente de validation ».
La QA n'a pas fini la première.
La quatrième a déjà deux conflits avec la branche principale ; son auteur passera la matinée à rebaser du code validé la semaine dernière.
En rétrospective, quelqu'un propose : « et si on avait une branche commune où on merge tout ce qui est à tester ? » Silence gêné.
C'est la branche qui frappe à la porte, sous un faux nom.
L'échec est instructif : le problème n'est pas de savoir où poser le code à tester, c'est que la validation bloque le merge.
Tant qu'une seule scène de test existe, les features font la queue devant, ou s'y mélangent.
La réponse n'est pas une branche commune ; c'est de donner à chaque feature sa propre scène.
Le même artefact, des scènes jetables Deux mécanismes s'ajoutent, toujours sans toucher au code applicatif.
Le premier : build once, promote everywhere.
Un artefact unique par commit de ; dev, staging et prod reçoivent ce même binaire, promu par tag, jamais reconstruit.
Ce qui a été validé est, bit à bit, ce qui part en prod.
Le second : des environnements éphémères par MR, les « review apps ».
Chaque branche de feature est déployée sur une URL jetable, détruite au merge.
La QA valide chaque feature isolément, avant le merge, sans qu'une branche d'intégration mélange tout.
Concrètement, en GitLab CI (l'équivalent existe chez GitHub Actions et les autres), l'essentiel tient en trois jobs : C'est la réponse « sans flags » au besoin qui pousse les équipes vers les branches d'environnement : tester plusieurs features en parallèle.
Chacune a son environnement, aucune ne bloque les autres.
Vous pouvez vous arrêter ici si déployer et livrer peuvent rester le même geste chez vous : pas besoin d'activer une feature client par client, ni de l'éteindre en urgence sans redéployer.
C'est le régime de croisière de très nombreuses équipes produit, et il est déjà excellent.
Six mois plus tard, vendredi, 16 h
40.
La release de mardi contenait quatre features, validées une à une sur leurs environnements éphémères, irréprochables.
Mais l'une d'elles touche au même cache que le module de facturation, et sous le trafic réel du vendredi, ça casse.
Le seul levier disponible est brutal : redéployer l'image précédente, en emportant les trois features innocentes.
Pendant l'incident, un commercial passe une tête : « on peut activer la nouveauté seulement pour le client pilote qui l'a demandée ? » Non.
On ne peut pas.
Le déploiement est le seul interrupteur de la maison, et il éteint tout en même temps.
Deuxième échec instructif : la validation isolée ne prouve pas le comportement en conditions réelles, et le déploiement est un interrupteur trop gros, qui allume et éteint tout d'un bloc.
Il manque un levier plus fin que le déploiement.
C'est exactement ce qu'est un feature flag.
L'interrupteur : découpler livrer de déployer La dernière marche renverse la logique : on merge avant que la feature soit finie, masquée par un interrupteur, et c'est l'interrupteur qui livre.
Déployer et livrer deviennent deux gestes distincts.
Déployer, c'est pousser du code en production, éteint ; c'est le geste technique, fréquent, automatisé, sans enjeu produit, qui peut arriver dix fois par jour.
Livrer, c'est allumer : le geste produit, une feature, un client, un instant choisi, réversible en secondes, sans redéploiement.
Au fond, un flag est trivial : une condition qui lit une configuration au moment de l'exécution.
Toute la valeur tient dans une question : d'où vient la valeur du flag ?
Trois réponses, du plus simple au plus puissant, chacune légitime à son échelle : Niveau Source des valeurs Un « flip » c'est… Granularité
1.
Config runtime Un fichier de config chargé au démarrage Changer une variable du déploiement, redémarrer le pod Par environnement
2.
Backend Un objet servi par votre API Un appel d'API ou un champ en base Par client, par compte
3.
Service dédié Unleash, LaunchDarkly, Fl