🚩
methodologie

Feature Flag

Technique permettant d'activer ou desactiver des fonctionnalites sans redeployer l'application.

Qu'est-ce qu'un feature flag ?

Un feature flag (ou feature toggle) est une technique de developpement qui permet d'activer ou de desactiver des fonctionnalites dans une application sans modifier le code ni redeployer. Le code de la nouvelle fonctionnalite est deploye en production mais "cache" derriere un flag conditionnel. Un systeme de configuration (base de donnees, service dedie) controle l'etat de chaque flag.

Types de feature flags

Release flags : activer progressivement une fonctionnalite en production (canary release). Temporaires, retires apres la generalisation. Experiment flags : tests A/B, montrer des variantes differentes a des segments d'utilisateurs pour mesurer l'impact. Ops flags : desactiver rapidement une fonctionnalite en cas de probleme de performance ou de bug (kill switch). Permission flags : activer des fonctionnalites pour certains utilisateurs (beta testeurs, clients premium).

Avantages

Deploiement continu : le code est merge et deploye en continu sans attendre que la fonctionnalite soit complete (trunk-based development). Releases progressives : deployer a 1% des utilisateurs, monitorer, puis augmenter progressivement. Rollback instantane : desactiver un flag est immediat, pas besoin de redeployer. Tests en production : tester avec de vrais utilisateurs et de vraies donnees. Decouplage deploy/release : deployer le code (technique) est separe de la release (metier).

Outils et implementation

Les plateformes dediees offrent des fonctionnalites avancees : LaunchDarkly (leader, targeting avance, analytics), Unleash (open-source, auto-heberge), Flagsmith (open-source, cloud ou auto-heberge), PostHog (feature flags + analytics), Split (experimentation avancee). L'implementation minimale est un simple if/else avec un flag en configuration, mais les plateformes ajoutent le ciblage par segment, les pourcentages de rollout, les metriques, et les SDK multi-langages.

Bonnes pratiques et dette technique

Les feature flags creent une forme de dette technique s'ils ne sont pas geres. Bonnes pratiques : nommer clairement chaque flag avec une date de creation, documenter l'objectif et la condition de retrait, nettoyer les flags obsoletes regulierement (sprint de nettoyage), limiter le nombre de flags actifs simultanement. Un flag devrait avoir une duree de vie definie. Les release flags sont retires apres generalisation. Les flags permanents (permissions, ops) doivent etre documentes et audites.

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

Les feature flags remplacent-ils les branches Git ?
Pas exactement, mais ils changent la strategie de branching. Avec les feature flags, le code incomplet peut etre merge sur main car il est desactive par defaut. Cela favorise le trunk-based development (branches courtes) et reduit les conflits de merge. Les feature branches restent utiles pour les changements structurels importants.
Comment eviter la complexite des feature flags ?
Limitez le nombre de flags actifs (moins de 20), definissez une date d'expiration pour chaque flag, automatisez le nettoyage (alertes quand un flag depasse sa duree prevue), evitez les flags imbriques (if flag A et if flag B), et designez un responsable pour chaque flag. Les outils comme LaunchDarkly offrent un suivi du cycle de vie des flags.

Pages liees

Chaque semaine, le meilleur de la tech francaise

Tendances, salaires, outils et opportunites — directement dans votre boite mail.

Gratuit. Desabonnement en un clic. Pas de spam.