Feature flag : définition, 4 usages et coût caché

Un feature flag, aussi appelé feature toggle ou interrupteur de fonctionnalité, est une condition placée dans le code d’une application qui décide, à l’exécution, si une fonctionnalité s’active ou non. Il permet d’activer ou de désactiver cette fonctionnalité sans redéployer le code, pour tous les utilisateurs ou pour un groupe choisi.

La technique est simple à décrire et redoutablement structurante dans la pratique : elle dissocie deux gestes que les équipes ont longtemps confondus, mettre du code en production et ouvrir une fonctionnalité au public. Voyons précisément ce qu’est un feature flag, à quoi il sert réellement, ce qu’il coûte à long terme, et où s’arrête sa frontière avec le déploiement progressif — le point le plus souvent survolé.

Feature flag : définition et fonctionnement

Un feature flag est une condition, au sens le plus banal du terme : un test dans le code qui oriente l’exécution vers un chemin ou vers un autre. Ce qui le distingue d’un simple if, c’est l’origine de la valeur testée. Elle n’est pas écrite dans le code livré : elle est lue à l’extérieur, dans une configuration que l’on peut modifier sans reconstruire ni redéployer l’application.

Comment fonctionne un feature flag ?

Le code contient les deux chemins : l’ancien comportement et le nouveau. À chaque appel, l’application interroge la source de vérité du flag — un fichier de configuration, une variable côté serveur, une table en base de données ou un service dédié — et exécute le chemin correspondant. La décision peut être globale, ou calculée par utilisateur en fonction d’un identifiant, d’un pays ou d’un type de compte.

Un flag peut vivre côté serveur comme côté navigateur, avec des conséquences très différentes : un flag évalué en backend ne laisse rien fuiter du code non activé, tandis qu’un flag évalué côté frontend expose le code de la fonctionnalité dans le navigateur, même éteinte. Ce détail d’implémentation devient un vrai sujet dès qu’une fonctionnalité est confidentielle avant son annonce.

Déployer n’est pas activer

C’est le principe fondateur, et il mérite d’être énoncé seul : un feature flag découple le déploiement de l’activation. Le code part en production sans être visible, puis la décision d’ouvrir la fonctionnalité devient un geste de configuration, réversible en quelques secondes. Une feature release cesse alors d’être un événement technique risqué pour devenir une décision produit.

Ce découplage explique pourquoi la pratique s’est diffusée avec la culture DevOps et l’intégration continue. Livrer plusieurs fois par jour suppose de pouvoir livrer du code inachevé sans le montrer ; sans flag, il faut maintenir des branches longues et douloureuses à fusionner.

• Mettre en production à tout moment — le code inachevé cohabite avec le reste, éteint, au lieu de vivre dans une branche isolée.
• Choisir la date d’ouverture — l’activation peut s’aligner sur une campagne marketing plutôt que sur un cycle de sprint.
• Revenir en arrière sans redéployer — on éteint l’interrupteur, on ne rejoue pas une livraison.
• Cibler une population — un pays, un segment de clients, les comptes internes, un panel de testeurs.

Sans feature flag, une mise en production est une promesse irréversible. Avec, c’est un interrupteur que l’on peut rallumer ou éteindre.

En vidéo : « C’est quoi une Feature Flag ? » (Javascript Academy) — le mécanisme expliqué en quelques minutes, exemple de code à l’appui.

Les 4 grands usages d’un feature flag

Parler « des » feature flags au singulier entretient une confusion utile à dissiper : sous le même mécanisme technique se cachent quatre usages aux exigences opposées. La référence sur le sujet reste l’article Feature Toggles (aka Feature Flags) de Pete Hodgson, publié sur le site de Martin Fowler, qui classe les flags selon deux axes : leur durée de vie et leur dynamisme, c’est-à-dire la finesse avec laquelle la décision est prise.

Type de flag	Ce qu’il pilote	Durée de vie	Dynamisme
Release toggle	La visibilité d’une fonctionnalité en cours de construction	Transitoire : quelques jours à quelques semaines	Faible — souvent une valeur globale
Experiment toggle	La répartition des utilisateurs entre deux variantes	Transitoire : le temps d’obtenir un résultat	Élevé — décision par utilisateur, stable dans le temps
Ops toggle / kill switch	Un comportement technique coûteux ou risqué	Court, sauf les kill switches conservés durablement	Élevé — activable en urgence, en production
Permissioning toggle	L’accès à une fonctionnalité selon le profil du compte	Durable : des mois, parfois des années	Élevé — décision par utilisateur

1. Piloter une mise en production (release toggle)

C’est l’usage le plus répandu. La fonctionnalité est développée par petits incréments, tous mis en production au fil de l’eau, mais restés invisibles. L’équipe travaille ainsi sur une seule branche partagée, sans accumuler de code en attente, et l’ouverture se fait le jour choisi. Cette approche s’accorde particulièrement bien avec la logique d’un MVP, ou Minimum Viable Product : on ouvre une première version réduite, on observe, on élargit.

Ce flag est temporaire par nature. Hodgson recommande de ne pas le laisser vivre plus d’une ou deux semaines au-delà de la généralisation de la fonctionnalité : passé ce délai, il ne pilote plus rien et ne fait qu’ajouter un chemin mort dans le code.

2. Mener une expérimentation (experiment toggle)

Ici, le flag ne sert plus à cacher mais à comparer. Deux variantes coexistent en production et les utilisateurs sont répartis entre elles de façon stable : un même visiteur doit toujours voir la même version, sinon la mesure ne veut plus rien dire. C’est le socle technique de l’A/B testing, et le prolongement naturel d’un travail de product discovery : l’hypothèse formulée en amont se tranche par une observation.

La difficulté n’est pas technique, elle est méthodologique. Un experiment toggle n’a de sens que si l’indicateur de succès a été choisi avant l’ouverture, et s’il mesure un effet réel plutôt qu’une vanity metric. Un test qui n’a pas de critère d’arrêt ne se termine jamais : la variante reste en place et le flag survit à l’expérience.

3. Couper un comportement technique (ops toggle et kill switch)

L’ops toggle est un outil d’exploitation, piloté par ceux qui tiennent la production. Il permet de désactiver une fonctionnalité gourmande en ressources pendant un pic de trafic, de contourner un service tiers en panne, ou de dégrader volontairement une partie de l’application pour préserver le reste. Sa variante la plus connue est le kill switch : l’interrupteur d’urgence que l’on garde à portée de main sur une fonctionnalité sensible, parfois pendant des années.

Cet usage impose une contrainte propre : le flag doit être actionnable immédiatement, sans déploiement et sans redémarrage. Un kill switch qui exige une livraison pour être basculé n’est pas un kill switch.

4. Activer une fonctionnalité pour un groupe (permissioning toggle)

Dernier usage, et le seul qui soit durable par construction : ouvrir une fonctionnalité à une population précise. Un plan tarifaire supérieur, les comptes d’une entreprise cliente, les collaborateurs internes, ou un panel de volontaires dans le cadre d’un beta testing. Le flag devient alors une règle métier permanente, et non un artifice de livraison.

Cette distinction a une conséquence pratique importante : un permissioning toggle n’est pas de la dette technique et n’a pas à être nettoyé. Le confondre avec un release toggle conduit soit à supprimer une règle métier utile, soit — plus souvent — à considérer que tous les flags sont légitimes et à ne jamais rien retirer.

Feature flag et déploiement progressif : où passe la frontière

C’est le point le plus mal traité sur le sujet, et pourtant le plus utile en pratique. Les deux notions se recouvrent partiellement, ce qui donne l’impression trompeuse qu’elles s’équivalent. La frontière est nette dès qu’on regarde sur quoi chacune agit : le déploiement progressif agit sur l’infrastructure, le feature flag agit à l’intérieur de l’application.

Le déploiement progressif : faire monter une version

Un déploiement progressif remplace une version du logiciel par une autre sans le faire d’un seul coup. Le canary release dirige une petite fraction du trafic vers la nouvelle version pour l’observer avant de généraliser ; le blue-green maintient deux environnements complets et bascule le trafic de l’un à l’autre ; le rolling update remplace les serveurs par vagues. Dans les trois cas, l’unité manipulée est la version déployée, et le levier est le routage du trafic.

Conséquence directe : un déploiement progressif expose l’ensemble des changements de la version, en bloc. Il ne sait pas ouvrir une fonctionnalité et en retenir une autre, ni cibler une catégorie de clients — il ne connaît que des requêtes et des serveurs.

Ce que le flag fait et que le déploiement progressif ne fait pas

• La granularité — le flag raisonne par fonctionnalité, le déploiement progressif par version entière.
• Le ciblage métier — un flag sait ouvrir pour « les comptes premium en Suisse », une bascule de trafic ne connaît pas cette notion.
• La durée — un déploiement progressif se termine forcément, un flag peut rester en place indéfiniment.
• La réversibilité — éteindre un flag est instantané et n’affecte qu’une fonctionnalité ; revenir en arrière sur une version annule tout le lot.
• Le prix à payer — le flag laisse des traces dans le code, la bascule d’infrastructure n’en laisse aucune.

Les deux approches ne sont donc pas concurrentes mais empilées. C’est exactement ce que désigne l’expression progressive delivery, décrite notamment dans la documentation d’Atlassian sur les feature flags : on déploie la version par vagues sur l’infrastructure, puis on ouvre les fonctionnalités une par une, à des populations croissantes, en surveillant les indicateurs à chaque palier.

Le coût caché : la dette de flags

Les articles sur le sujet s’arrêtent généralement aux bénéfices. Or un feature flag n’est pas gratuit : chaque interrupteur ajouté est une ligne de stock qu’il faut entretenir. Hodgson le formule dans ces termes — les équipes averties considèrent leurs flags comme un inventaire assorti d’un coût de possession, et cherchent à le maintenir aussi bas que possible.

Ce coût prend plusieurs formes. Chaque flag double un chemin d’exécution, donc les combinaisons possibles se multiplient : trois flags dans le même parcours produisent huit états théoriques, dont la plupart ne seront jamais testés. La lecture du code se dégrade, les tests automatisés couvrent une part décroissante des cas réels, et les nouveaux arrivants perdent du temps à comprendre quel chemin est effectivement emprunté en production.

Un flag a un cycle de vie — et la plupart doivent mourir

Un flag naît quand on encapsule une fonctionnalité, vit le temps qu’on pilote son activation, puis — pour les release toggles et les experiment toggles — doit être retiré. C’est cette dernière étape que les équipes oublient, parce qu’elle n’apporte aucune fonctionnalité visible et arrive au moment où l’attention est déjà passée au sujet suivant. Un an plus tard, plus personne ne sait si un flag est encore utile, et le supprimer devient une opération risquée que personne ne veut assumer.

Les kill switches subissent une variante plus sournoise du même problème. Conservés par prudence, ils ne sont jamais actionnés, donc jamais éprouvés : le jour de l’incident, le code du chemin de secours a divergé et l’interrupteur ne coupe plus rien. Un kill switch qu’on ne teste pas est un extincteur périmé — rassurant sur le mur, inutile le jour du feu.

Comment garder la dette de flags sous contrôle

1. Décider du type à la création — release, expérimentation, ops ou permission. C’est ce choix qui dit si le flag est temporaire, et donc s’il faudra le retirer.
2. Nommer un responsable et une date d’expiration — un flag sans propriétaire ni échéance ne sera jamais supprimé par personne.
3. Inscrire le retrait dans la definition of done — la fonctionnalité n’est terminée que lorsque son flag et son chemin mort ont disparu du code.
4. Créer la tâche de suppression tout de suite — au moment de la généralisation, pas « plus tard ». Plus tard n’arrive jamais.
5. Faire échouer la construction sur un flag périmé — un test qui casse quand un flag dépasse sa date est le seul mécanisme qui résiste à l’oubli.
6. Répéter le déclenchement des kill switches — un interrupteur d’urgence se teste en conditions calmes, pas pendant l’incident.

Reste la question de l’outil. Un booléen dans un fichier de configuration suffit pour un premier release toggle ; le besoin d’une plateforme dédiée apparaît quand il faut cibler par utilisateur, tracer qui a basculé quoi et quand, et éviter que chaque équipe ne réinvente son propre mécanisme. À ce stade, le standard ouvert OpenFeature, hébergé par la CNCF (Cloud Native Computing Foundation), permet d’écrire le code d’évaluation une seule fois sans se lier à un fournisseur particulier.

S’il ne fallait retenir qu’une chose, ce serait celle-ci : poser un feature flag est facile, et c’est précisément ce qui rend la pratique dangereuse. Je considère qu’un flag n’est vraiment maîtrisé que lorsque la date et la condition de son retrait sont écrites au moment même de sa création — le reste n’est que de la dette différée.

FAQ — Tout savoir sur les feature flags

Feature flag et feature toggle : est-ce la même chose ?

Oui, ce sont deux noms pour le même mécanisme. « Feature toggle » est le terme historique employé dans la littérature technique, « feature flag » s’est imposé dans l’usage courant et chez les éditeurs d’outils. On rencontre aussi « feature switch » et « feature flipper », plus rares.

Comment traduire feature flag en français ?

Il n’existe pas de traduction officielle installée dans l’usage. « Interrupteur de fonctionnalité » et « indicateur de fonctionnalité » sont les formulations les plus fidèles ; « drapeau de fonctionnalité », traduction littérale, reste peu employée. Dans les équipes francophones, le terme anglais est conservé.

Quelle différence entre un feature flag et un kill switch ?

Le kill switch est un cas particulier de feature flag, dédié à l’exploitation. Là où un release toggle sert à ouvrir progressivement une fonctionnalité puis disparaît, le kill switch reste en place durablement dans un seul but : couper immédiatement une fonctionnalité en cas d’incident, sans déploiement.

Un feature flag remplace-t-il l’A/B testing ?

Non : il en est le support technique, pas la méthode. Le flag répartit les utilisateurs entre deux variantes de façon stable. L’A/B testing ajoute ce qui fait la validité du test : une hypothèse formulée à l’avance, un indicateur de succès, une taille d’échantillon et un critère d’arrêt.

Quelle différence avec un fichier de configuration classique ?

Une variable d’environnement se lit au démarrage et concerne l’ensemble de l’instance. Un feature flag est évalué à chaque appel, peut varier d’un utilisateur à l’autre et se modifie à chaud, sans redémarrage. La différence porte donc sur la finesse de la décision et sur l’instantanéité du changement.

Combien de temps faut-il garder un feature flag ?

Cela dépend de son type. Un release toggle se retire dans les jours ou les semaines qui suivent la généralisation de la fonctionnalité, un experiment toggle dès que le test est tranché. À l’inverse, un flag de permission ou un kill switch sont légitimement conservés sur le long terme.

Faut-il un outil dédié pour faire du feature flagging ?

Pas au départ : un paramètre de configuration suffit pour quelques flags globaux. Une plateforme devient utile quand il faut cibler par utilisateur, basculer sans intervention technique, tracer les changements et suivre l’inventaire des flags actifs afin de piloter leur retrait.