Les Feature Flags ne sont pas le seul levier de release dont vous avez besoin
Une équipe avec laquelle j'ai travaillé a passé trois mois à construire un nouveau tunnel de commande. Le code était terminé, testé en staging, et fusionné dans la branche principale derrière un feature flag. Quand ils ont finalement activé le flag pour 5 % des utilisateurs, le fournisseur de paiement a renvoyé des erreurs jamais vues en staging. Le flag leur a permis de tout désactiver en quelques secondes. Mais la vraie question était : ce code aurait-il dû être en production ?
Les feature flags sont puissants. Ils permettent de déployer du code inactif, de tester en production avec du trafic réel, et de déployer progressivement. Mais ce n'est pas une solution universelle. Parfois, une branche est plus adaptée. Parfois, un environnement séparé a plus de sens. Et parfois, les trois doivent fonctionner ensemble.
La première question à se poser est : que cherchez-vous réellement à accomplir en retardant ou en limitant l'accès à une nouvelle fonctionnalité ?
Quand utiliser une branche
Les branches existent pour isoler le travail en cours. Si une fonctionnalité n'est pas terminée et ne peut pas fonctionner sans casser l'application, gardez-la dans une branche. Le code reste en dehors de la branche principale. Personne ne le déploie accidentellement. Personne n'a à se souvenir qu'un flag existe.
C'est la forme de contrôle la plus simple. Elle fonctionne bien pour les fonctionnalités encore en développement, surtout quand plusieurs développeurs travaillent sur des parties différentes. La branche principale reste propre. L'équipe fusionne uniquement quand la fonctionnalité est terminée et revue.
Mais les branches ont une limite. Une fois le code fusionné, vous perdez la capacité de contrôler son activation. La fonctionnalité est soit dans la branche principale, soit elle ne l'est pas. Il n'y a pas de juste milieu. C'est là que les feature flags entrent en jeu.
Quand utiliser un feature flag
Les feature flags contrôlent le comportement après la fusion du code. Le code est dans la branche principale, déployé en production, mais pas actif pour tous les utilisateurs. Vous pouvez l'activer pour un petit pourcentage, pour des testeurs internes, ou pour des conditions spécifiques.
C'est utile quand la fonctionnalité est fonctionnellement complète mais que vous n'êtes pas prêt à l'exposer à tout le monde. Peut-être voulez-vous valider la stabilité sous trafic réel. Peut-être devez-vous surveiller les taux d'erreur avant un déploiement complet. Peut-être voulez-vous faire une montée en charge progressive sur plusieurs jours.
Les feature flags aident aussi pour le rollback. Si quelque chose tourne mal, vous désactivez le flag au lieu d'annuler le déploiement. C'est plus rapide et plus sûr que de revenir en arrière, surtout quand le déploiement inclut des migrations de base de données ou d'autres changements irréversibles.
Mais les feature flags ne sont pas gratuits. Ils ajoutent de la complexité au code. Chaque flag est une branche conditionnelle qui doit être maintenue, testée et finalement supprimée. Trop de flags qui restent trop longtemps créent de la dette technique. Les équipes qui accumulent des centaines de flags obsolètes se retrouvent avec un code difficile à lire et encore plus difficile à déboguer.
Quand utiliser un environnement séparé
Un environnement de staging vous offre un espace de test avant la production. Il est isolé des utilisateurs réels. Vous pouvez exécuter des tests d'intégration, du QA manuel et des tests exploratoires sans impact sur personne.
Le problème est que le staging n'est jamais identique à la production. Les schémas de trafic sont différents. Les volumes de données sont plus petits. Le comportement réel des utilisateurs ne peut pas être reproduit. Certains problèmes n'apparaissent qu'en charge de production, avec des données de production, ou avec la configuration d'infrastructure exacte que le staging n'a pas.
C'est pourquoi les feature flags et les environnements se complètent. Utilisez le staging pour les tests précoces. Utilisez les feature flags pour la validation en production. Ils ne se remplacent pas. Ce sont deux couches de sécurité.
Une fonctionnalité importante qui modifie un flux central — comme remplacer un système de paiement ou redessiner la page de connexion — devrait probablement passer d'abord par le staging. Une fois qu'elle y est validée, vous pouvez la déployer derrière un flag en production et augmenter progressivement l'exposition.
Combiner branche, environnement et flag
En pratique, de nombreuses équipes utilisent les trois ensemble. Voici un schéma courant :
- Travaillez sur une fonctionnalité importante dans une branche séparée.
- Fusionnez la branche dans la branche principale avec le flag désactivé.
- Déployez en staging, testez la fonctionnalité en activant le flag en staging.
- Déployez en production avec le flag toujours désactivé.
- Activez le flag pour les utilisateurs internes ou un petit pourcentage.
- Augmentez progressivement le pourcentage en fonction de la surveillance.
- Supprimez le flag une fois la fonctionnalité entièrement déployée et stable.
Ce schéma est courant dans les équipes qui pratiquent le trunk-based development. La branche principale est toujours déployable. Les fonctionnalités importantes sont découpées en morceaux plus petits, chacun contrôlé par un flag. L'équipe fusionne fréquemment, déploie souvent et utilise les flags pour contrôler ce que les utilisateurs voient.
Quand les feature flags sont un mauvais choix
Les feature flags ne sont pas toujours le meilleur outil. Considérez ces situations :
- La fonctionnalité n'est pas exécutable. Si le code ne compile pas, échoue aux tests ou plante au démarrage, ne le fusionnez pas. Gardez-le dans une branche jusqu'à ce qu'il fonctionne.
- Le changement est trop important pour être contrôlé par un seul flag. Un flag qui active ou désactive tout un sous-système est difficile à tester et risqué à basculer. Découpez la fonctionnalité en morceaux plus petits, chacun avec son propre flag, ou utilisez un environnement pour la validation initiale.
- L'équipe utilise les flags pour éviter les décisions. Si un flag existe parce que personne ne veut décider si la fonctionnalité est prête, c'est un problème de processus, pas d'outil. Les flags doivent permettre un retour plus rapide, pas retarder les conversations difficiles.
- Le flag restera pour toujours. Certaines équipes conservent les flags indéfiniment parce que les supprimer semble risqué. C'est le signe que le flag a été mal conçu ou que l'équipe manque de confiance dans son processus de release. Chaque flag doit avoir une date de suppression planifiée.
Une checklist pratique pour choisir ses contrôles de release
| Situation | Contrôle recommandé |
|---|---|
| La fonctionnalité est incomplète et ne peut pas fonctionner | Branche |
| La fonctionnalité est complète mais nécessite une validation en production | Feature flag |
| La fonctionnalité nécessite des tests isolés avant la production | Environnement de staging |
| La fonctionnalité est importante et modifie un comportement central | Staging d'abord, puis flag |
| L'équipe pratique le trunk-based development | Combinaison branche + flag |
| La fonctionnalité est petite et à faible risque | Feature flag ou déploiement direct |
Ce n'est pas un tableau rigide. Chaque équipe a une tolérance au risque et une infrastructure différentes. Utilisez-le comme point de départ pour la discussion, pas comme un règlement.
L'arbre de décision ci-dessous résume les questions clés et les contrôles recommandés.
Le véritable objectif
Les feature flags, les branches et les environnements sont des outils. L'objectif n'est pas de tous les utiliser. L'objectif est de livrer des logiciels en toute sécurité et d'obtenir des retours rapidement.
Une bonne stratégie de release vous permet de déployer souvent, de tester en production avec un risque contrôlé, et de désactiver les choses quand quelque chose tourne mal. Elle ne vous permet pas de reporter les décisions ou d'accumuler des fonctionnalités à moitié terminées en production.
Commencez par comprendre ce que vous essayez de contrôler. Choisissez ensuite l'outil adapté. Et quand vous utilisez un feature flag, n'oubliez pas de le supprimer. Le meilleur flag est celui qui n'existe plus.