Les feature flags sont des interrupteurs placés dans le code qui activent ou désactivent une fonctionnalité sans redéployer l'application. Cette page explique, pour un public débutant à intermédiaire, comment ils permettent de découpler le déploiement de la release, quels sont leurs quatre types et leurs durées de vie, comment gérer la dette de flags, et quel outillage choisir en 2026 (OpenFeature, Unleash, Flagsmith, GrowthBook, LaunchDarkly ou le fait-maison). L'objectif : livrer plus souvent tout en gardant la main sur ce que vos utilisateurs voient réellement.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer déploiement et release, et pourquoi ce découplage change tout.
- Identifier les quatre types de flags et leur durée de vie attendue.
- Piloter le cycle de vie d'un flag pour éviter la dette de flags.
- Mettre en oeuvre un dark launch et une activation progressive par cohorte.
- Choisir entre OpenFeature, un serveur open source et le fait-maison.
Qu'est-ce qu'un feature flag (ou feature toggle)
Section intitulée « Qu'est-ce qu'un feature flag (ou feature toggle) »Un feature flag, aussi appelé feature toggle, est une condition dans le code qui décide, à l'exécution, si un morceau de fonctionnalité s'active ou non. Concrètement, au lieu de livrer directement un nouveau tunnel de paiement, vous l'enveloppez dans un test du style « si le flag nouveau-paiement est activé, montre la nouvelle version, sinon garde l'ancienne ». Le code des deux versions cohabite en production, et c'est la valeur du flag qui tranche.
Martin Fowler, sur son site de référence, décompose ce mécanisme en trois briques utiles à connaître. Le toggle point est l'endroit précis du code où la décision est prise. Le toggle router est ce qui fournit la réponse, depuis une simple variable d'environnement jusqu'à un serveur distant qui évalue des règles. Le toggle context regroupe les informations qui alimentent la décision, comme l'identité de l'utilisateur ou sa région. Cette séparation compte : plus votre logique de décision est isolée du toggle point, plus le code reste lisible.
L'intérêt premier est de fusionner du code inachevé dans la branche principale sans casser la production. C'est la clé du trunk-based development, une stratégie de branches très courtes détaillée dans le guide des workflows Git. Le code part en production, mais reste invisible tant que le flag est éteint.
Deployer n'est pas livrer : le decouplage deploiement / activation
Section intitulée « Deployer n'est pas livrer : le decouplage deploiement / activation »
Le principe fondateur des feature flags tient en une phrase : déployer n'est pas livrer. Le déploiement est un acte technique, vous poussez un artefact sur les serveurs de production. La release est un acte produit, vous décidez qu'une fonctionnalité devient visible pour tout ou partie de vos utilisateurs. Sans flags, ces deux événements sont soudés : dès que le code arrive, il est actif. Avec des flags, vous séparez le risque technique du risque produit.
Prenons un exemple concret. Votre équipe déploie chaque jour, y compris du code d'une refonte de recherche encore en chantier. Ce code voyage jusqu'en production derrière un flag éteint. Le jour du lancement, le chef de produit active le flag depuis une interface, sans attendre un déploiement, sans fenêtre de maintenance nocturne. Si un problème surgit, il rebascule le flag en quelques secondes. Le déploiement a eu lieu il y a trois semaines, la release a lieu maintenant, et le rollback ne repasse pas par un pipeline.
Ce découplage nourrit directement plusieurs métriques DORA. Il augmente la fréquence de déploiement (on livre du code inachevé sans attendre), il réduit le délai de restauration (couper un flag est plus rapide qu'un rollback d'image), et il fait baisser le taux d'échec des changements en limitant l'exposition. Les feature flags complètent ainsi les stratégies de déploiement d'un pipeline CI/CD : là où un canary joue au niveau de l'infrastructure, un flag joue au niveau applicatif, cohorte par cohorte.
Les types de flags (release, ops / kill switch, experiment, permission) et leur duree de vie
Section intitulée « Les types de flags (release, ops / kill switch, experiment, permission) et leur duree de vie »
Tous les flags ne se ressemblent pas. Pete Hodgson, dans l'article de référence publié sur martinfowler.com, en distingue quatre catégories dont la propriété la plus importante est la durée de vie attendue. Confondre ces catégories est la cause numéro un de la dette de flags : un flag de release traité comme un interrupteur permanent ne se nettoie jamais.
Les flags de release cachent du code inachevé en production le temps de le terminer. Ils sont statiques (la même valeur pour tout le monde) et éphémères : Fowler estime qu'ils ne devraient pas survivre plus d'une semaine ou deux. Exemple : le flag qui masque la refonte du panier jusqu'à sa finalisation. Une fois la fonctionnalité livrée, le flag et son ancien chemin de code doivent disparaître.
Les flags ops, souvent appelés kill switch, donnent aux équipes d'exploitation un moyen de couper ou dégrader une fonctionnalité en cas d'incident. On les introduit quand une nouveauté a des implications de performance incertaines. Exemple : un flag qui désactive instantanément un nouveau système de recommandations si la base de données sature un soir de forte charge. La plupart sont courts, mais certains kill switches restent en place indéfiniment comme filet de sécurité.
Les flags d'experiment servent à l'A/B testing ou aux tests multivariés. Chaque utilisateur est placé dans une cohorte et suit un chemin de code différent, puis on mesure lequel performe le mieux. Exemple : 50 % des visiteurs voient un bouton d'achat vert, l'autre moitié un bouton bleu, et on compare le taux de conversion. Ils sont très dynamiques et vivent le temps d'atteindre une significativité statistique, de quelques heures à quelques semaines.
Les flags de permission réservent une fonctionnalité à une catégorie d'utilisateurs selon un attribut : offre payante, ancienneté du compte, appartenance à un programme bêta. Exemple : un éditeur SaaS ouvre une fonctionnalité avancée aux seuls clients de l'offre entreprise. Ce sont les plus durables : ils peuvent rester des années, car ils font partie de la logique métier. Les traiter comme du code temporaire serait une erreur.
Le cycle de vie d'un flag et la dette de flags (flags zombies, nettoyage)
Section intitulée « Le cycle de vie d'un flag et la dette de flags (flags zombies, nettoyage) »
Un flag n'est pas éternel, il suit un cycle de vie. Il naît quand vous enveloppez une fonctionnalité, il vit pendant que vous pilotez son activation, puis, pour la plupart des types, il doit mourir. C'est cette dernière étape que les équipes oublient, et c'est de cet oubli que naît la dette de flags.
-
Création : le flag est ajouté au code, éteint par défaut, avec un nom explicite et un propriétaire identifié.
-
Activation progressive : on l'ouvre à une cohorte, puis on élargit en surveillant les métriques d'observabilité.
-
Généralisation : le flag est activé pour 100 % des utilisateurs, la fonctionnalité est validée.
-
Retrait : on supprime le flag et l'ancien chemin de code, puis on nettoie la configuration côté serveur.
La dette de flags est l'accumulation de flags obsolètes laissés dans le code après le lancement. On parle de flags zombies : ils ne servent plus, mais leur condition reste dans le code. Le coût est réel. Chaque flag ajoute un chemin d'exécution à tester, ce qui provoque une explosion combinatoire des cas. Un flag oublié peut aussi réactiver du code mort par erreur, ou pire, un flag de permission mal nettoyé ouvre un accès non prévu. L'incident Knight Capital de 2012, où un ancien flag réutilisé a déclenché du code obsolète et coûté 440 millions de dollars en 45 minutes, reste l'illustration extrême de ce risque.
Fowler propose une image efficace : voyez vos flags comme un stock (inventory) avec un coût de possession. La discipline consiste à poser une date d'expiration sur chaque flag temporaire, à plafonner le nombre de flags actifs par équipe, et à créer une tâche de retrait dès qu'un flag est généralisé. Certaines équipes ajoutent un test qui échoue automatiquement quand un flag dépasse sa date, forçant le nettoyage.
Dark launching et activation progressive par cohorte
Section intitulée « Dark launching et activation progressive par cohorte »
Le dark launch (lancement dans le noir) consiste à envoyer du vrai trafic de production vers une nouvelle fonctionnalité sans montrer le résultat aux utilisateurs. On active le nouveau code en arrière-plan, on mesure son comportement réel, mais l'interface reste inchangée. Exemple : votre nouveau moteur de recherche traite en douce toutes les requêtes réelles et vous comparez ses temps de réponse et ses résultats à l'ancien, sans qu'aucun visiteur ne voie la différence. Vous validez la charge et la justesse avant d'exposer quoi que ce soit.
Vient ensuite l'activation progressive par cohorte (progressive rollout). Plutôt que d'ouvrir la fonctionnalité à tout le monde d'un coup, vous l'ouvrez à des cohortes de taille croissante. Une cohorte est un sous-ensemble d'utilisateurs défini par une règle : un pourcentage aléatoire, les employés internes, une région, ou une liste de comptes. La progression typique ressemble à ceci : d'abord les équipes internes, puis 1 % des utilisateurs, puis 10 %, 50 %, et enfin 100 %.
À chaque palier, vous surveillez vos indicateurs. Si le taux d'erreur grimpe ou qu'un SLO se dégrade, vous stoppez ou reculez sans redéployer. Ce mécanisme applicatif se marie bien avec les rolling updates et rollbacks Kubernetes : l'orchestrateur gère le remplacement progressif des pods, le flag gère l'exposition fine de la fonctionnalité à l'intérieur de ces pods. Les deux couches se complètent au lieu de se concurrencer.
Cas d'usage concrets : kill switch, canary applicatif, A/B testing, acces anticipe
Section intitulée « Cas d'usage concrets : kill switch, canary applicatif, A/B testing, acces anticipe »
Les feature flags brillent sur des situations très concrètes. Les décrire aide à choisir le bon type de flag pour le bon besoin.
Le kill switch est le premier réflexe de sécurité. Vous déployez une intégration avec un service de paiement tiers réputé instable. Vous l'enveloppez dans un flag ops. Le jour où ce service tombe, l'astreinte coupe le flag et bascule sur un mode dégradé, sans réveiller personne pour un rollback complet. La fonctionnalité redevient active d'un clic une fois le tiers rétabli.
Le canary applicatif consiste à faire cohabiter deux versions d'une même logique et à n'en exposer une qu'à une petite fraction du trafic. Contrairement au canary d'infrastructure qui route des requêtes vers des serveurs différents, ici tout tourne sur les mêmes serveurs et c'est le flag qui décide. Exemple : votre nouvel algorithme de calcul de frais de port ne s'applique qu'à 5 % des commandes, le temps de vérifier qu'il ne facture pas de montants aberrants.
L'A/B testing transforme le flag en outil de décision produit. Vous confrontez deux variantes d'une page et vous laissez les chiffres trancher. Exemple : deux formulations pour votre offre d'essai gratuit, et vous conservez celle qui génère le plus d'inscriptions. GrowthBook, décrit plus bas, est spécialisé dans ce cas.
L'accès anticipé (early access) réserve une nouveauté à une cohorte de bêta-testeurs. Exemple : vous ouvrez un tableau de bord repensé aux clients volontaires d'un programme bêta, vous récoltez leurs retours, puis vous généralisez. C'est un usage typique du flag de permission.
Outillage : OpenFeature comme standard, Unleash, Flagsmith, GrowthBook, et le fait-maison
Section intitulée « Outillage : OpenFeature comme standard, Unleash, Flagsmith, GrowthBook, et le fait-maison »L'écosystème des feature flags s'est structuré autour d'un standard. OpenFeature est un projet de la CNCF (Cloud Native Computing Foundation), en maturité incubating en 2026. Attention au contresens fréquent : OpenFeature n'est pas un serveur de flags, c'est une API unifiée et un ensemble de SDK (JavaScript, Go, Java, Python, .NET, PHP, Ruby). Votre code appelle toujours la même API, et vous branchez derrière un provider qui parle à l'outil de votre choix. L'intérêt : éviter le verrouillage fournisseur. Vous pouvez démarrer avec un provider local comme flagd (le démon de référence du projet) puis migrer vers un serveur commercial sans réécrire vos toggle points.
Côté serveurs open source auto-hébergeables, trois noms reviennent. Unleash est un serveur mûr et modulaire, avec des stratégies d'activation riches et une console d'administration, adapté aux organisations qui veulent tout héberger. Flagsmith couvre les flags mais aussi la gestion de configuration à distance, et c'est d'ailleurs l'entreprise qui a soumis OpenFeature à la CNCF. GrowthBook se distingue par son orientation A/B testing et expérimentation : au-delà de l'interrupteur, il fournit l'analyse statistique des résultats. Ces trois outils exposent un provider OpenFeature, ce qui garde votre code portable.
Du côté commercial SaaS, LaunchDarkly reste la référence historique, avec un ciblage très fin, de l'audit et une gestion à grande échelle, moyennant un abonnement. C'est souvent le choix des grandes organisations qui veulent externaliser toute la plateforme.
Enfin, le fait-maison garde sa place. Pour un ou deux flags de release à durée de vie courte, une simple variable de configuration lue au démarrage suffit largement, sans introduire de dépendance. La bascule devient nécessaire dès que vous avez besoin de changement à chaud sans redéploiement, de ciblage par cohorte, d'audit des activations ou d'un kill switch fiable. La stratégie la plus sûre en 2026 : coder contre l'API OpenFeature dès le départ, avec un provider minimal, pour vous laisser la liberté de brancher un vrai serveur le jour où le besoin grandit.
Bonnes pratiques et pieges (nommage, explosion combinatoire des tests, securite, nettoyage)
Section intitulée « Bonnes pratiques et pieges (nommage, explosion combinatoire des tests, securite, nettoyage) »Les feature flags sont puissants mais se retournent contre vous s'ils sont mal gérés. Quelques principes évitent les pièges les plus courants et coûteux.
Soignez le nommage. Un nom comme flag1 ou test ne dit rien six mois plus tard. Préférez un nom qui porte l'intention et le type, par exemple release-refonte-panier ou ops-kill-recommandations. Documentez le propriétaire et la date de retrait prévue. Un flag anonyme est un futur zombie.
Maîtrisez l'explosion combinatoire des tests. Chaque flag double, en théorie, le nombre de combinaisons à valider. Avec dix flags indépendants, vous ne testerez jamais les 1024 combinaisons. La parade : limiter le nombre de flags actifs simultanément, tester en priorité les combinaisons on/on et off/off qui correspondent aux états réels de production, et retirer les flags dès qu'ils sont généralisés. Un pipeline discipliné, tel que décrit dans le guide CI/CD, aide à garder ce nombre bas.
Traitez la sécurité au sérieux. Un flag de permission est un contrôle d'accès : s'il est mal évalué ou oublié, il expose une fonctionnalité à des utilisateurs non prévus. Ne mettez jamais de secret dans la valeur d'un flag, et journalisez les changements d'un kill switch pour l'audit. Un flag mal nettoyé qui réactive du vieux code est un risque opérationnel réel, comme l'a montré l'incident Knight Capital.
Faites du nettoyage une routine, pas une bonne résolution. Intégrez le retrait des flags au Definition of Done de la fonctionnalité, créez une tâche de suppression dès la généralisation, et envisagez un test qui échoue quand un flag dépasse sa date d'expiration. C'est la seule façon de garder la dette de flags sous contrôle sur la durée.
À retenir
Section intitulée « À retenir »- Un feature flag est un interrupteur qui active une fonctionnalité sans redéployer.
- Il découple le déploiement (technique) de la release (produit), et réduit le risque.
- Il existe quatre types : release, ops (kill switch), experiment, permission, aux durées de vie très différentes.
- Confondre ces durées de vie crée la dette de flags et ses flags zombies.
- Le dark launch et l'activation progressive par cohorte exposent une nouveauté sans big bang.
- OpenFeature (CNCF) est le standard d'API qui évite le verrouillage ; Unleash, Flagsmith et GrowthBook sont des serveurs open source.
- Le fait-maison suffit pour un ou deux flags courts ; passez à un outil dès le ciblage et le changement à chaud.
- Nommez, datez et nettoyez chaque flag pour éviter l'explosion combinatoire et les risques de sécurité.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Les questions ci-dessous reprennent les points sur lesquels les équipes hésitent le plus quand elles adoptent les feature flags.