Feature flags

Les feature flags (aussi appelés feature toggles ou feature switches) sont des interrupteurs placés dans le code qui permettent d’activer ou de désactiver une fonctionnalité sans redéployer l’application. Le code de la fonctionnalité est bien présent en production, mais il ne s’exécute que si son flag est activé.

Tout l’intérêt tient dans cette séparation : déployer du code et activer une fonctionnalité deviennent deux décisions distinctes. Une équipe peut déployer le code le lundi, tester la fonctionnalité en interne le mardi, l’ouvrir à 10 % des utilisateurs le mercredi et la généraliser le jeudi. Si un problème apparaît en route, elle désactive le flag en quelques secondes, sans redéploiement.

Pourquoi utiliser des feature flags

Déployer sans risque

Dans le modèle classique, la mise en ligne d’une fonctionnalité est un événement stressant. On choisit un créneau, on déploie, on surveille, et si quelque chose casse, on lance un rollback qui peut prendre de longues minutes pendant lesquelles les utilisateurs subissent le problème.

Avec un feature flag, il suffit de désactiver la fonctionnalité fautive : quelques secondes, sans redéploiement ni interruption de service. C’est ce qu’on appelle un kill switch, sans doute l’usage le plus précieux des feature flags pour un produit SaaS en production.

Déployer progressivement

Au lieu d’ouvrir une fonctionnalité à tout le monde d’un coup, on l’active pour 1 % des utilisateurs, on observe les KPI et les métriques de performance, puis on élargit par paliers : 5 %, 20 %, 50 %, 100 %. C’est ce qu’on appelle un déploiement progressif, ou canary release. Un bug détecté à 5 % du trafic n’affecte que 5 % des utilisateurs.

Cette approche vaut surtout pour les fonctionnalités qui touchent aux composants critiques, comme le paiement ou l’authentification, où un incident en production coûte cher.

Expérimenter en production

Les feature flags sont le socle technique de l’A/B testing : on active la version A pour un groupe d’utilisateurs, la version B pour un autre, et on mesure l’impact sur le taux de conversion, la rétention ou l’engagement.

Dans une stratégie de Product-Led Growth, cette capacité à tester des hypothèses en production, avec de vrais utilisateurs et sans attendre un cycle de développement complet, est un avantage considérable.

Les types de feature flags

Tous les flags ne servent pas le même objectif, et la distinction compte pour bien les gérer.

Les flags de release contrôlent le déploiement progressif d’une nouvelle fonctionnalité. Ils sont temporaires : une fois la fonctionnalité validée et ouverte à tous, le flag doit disparaître du code.

Les flags d’expérimentation servent aux tests A/B. Temporaires eux aussi : l’expérience se termine, la décision est prise, le flag est retiré.

Les flags opérationnels aident à gérer la charge ou les incidents, par exemple en coupant temporairement une fonctionnalité gourmande en ressources quand le système est sous pression. Ils peuvent rester en place durablement, car ils participent à la résilience du produit.

Les flags de permission contrôlent l’accès aux fonctionnalités selon le plan ou le rôle de l’utilisateur : le plan gratuit voit certaines fonctionnalités, le plan premium en voit d’autres. Ceux-là sont permanents et font partie de la logique métier.

Comment fonctionne un feature flag

L’implémentation de base tient en une condition dans le code :

si le flag "nouvelle-recherche" est activé pour cet utilisateur
    → afficher la nouvelle interface de recherche
sinon
    → afficher l'ancienne interface

Le service de feature flags évalue cette condition en temps réel : le flag est-il activé globalement ? Pour ce segment d’utilisateurs ? Pour ce pourcentage de trafic ? La réponse détermine quelle version du code s’exécute.

Les outils du marché permettent un ciblage fin : par utilisateur individuel (pour les bêta-testeurs), par segment (les clients du plan Enterprise), par pourcentage de trafic, par zone géographique, ou en combinant ces critères.

Les outils de feature flags les plus courants

LaunchDarkly reste la référence du marché, avec des SDK pour tous les langages et un ciblage très complet. Son prix le destine plutôt aux équipes établies qu’aux petites structures.

PostHog combine feature flags, analytics produit et A/B testing dans une seule plateforme open source. Un bon choix pour les équipes qui veulent un outil tout-en-un.

Statsig, connu pour ses capacités statistiques avancées, a été racheté par OpenAI fin 2025 pour 1,1 milliard de dollars. Le produit continue de fonctionner, et ce rachat montre à quel point l’expérimentation en production est devenue un enjeu stratégique.

Unleash est une alternative open source auto-hébergeable, adaptée aux équipes qui veulent garder leurs données chez elles.

À noter aussi : OpenFeature, un standard porté par la Cloud Native Computing Foundation, définit une API commune pour intégrer ces outils. Il permet de changer de fournisseur sans réécrire son code, un point à vérifier avant de s’engager avec un éditeur.

Les erreurs à éviter

Laisser les flags s’accumuler. C’est le piège le plus courant. Les flags temporaires jamais supprimés transforment le code en labyrinthe de conditions, et chaque flag oublié vient grossir la dette technique, un phénomène que nous détaillons dans notre article sur la dette technique. La bonne pratique consiste à fixer une date d’expiration à chaque flag temporaire et à le supprimer dès que la décision est prise.

Créer des combinaisons ingérables. Avec dix flags actifs, l’application compte en théorie 1 024 combinaisons possibles, dont la plupart n’ont jamais été couvertes par les tests automatisés. Il faut limiter le nombre de flags actifs simultanément et identifier les interactions à risque.

S’en servir pour masquer un pipeline de CI/CD défaillant. Les feature flags complètent un processus de déploiement fiable, ils ne le remplacent pas. Si l’équipe s’en sert surtout pour cacher du code qui n’est pas prêt, le vrai problème est ailleurs.

Négliger la performance. Chaque évaluation de flag a un coût, même minime. Les outils sérieux mettent les évaluations en cache localement ; une implémentation naïve qui fait un appel réseau à chaque vérification peut dégrader sensiblement les temps de réponse.

Feature flags et workflow d’équipe

Les feature flags changent la façon dont une équipe livre. Au lieu d’attendre qu’une fonctionnalité soit terminée pour la fusionner dans le code principal, les développeurs fusionnent du code incomplet derrière un flag désactivé. Résultat : moins de conflits de fusion, des code reviews plus courtes parce que les modifications sont plus petites, et un code principal qui reflète l’état réel du développement.

Côté produit, une fonctionnalité peut être prête techniquement mais retenue pour des raisons commerciales ou marketing, sans bloquer le travail des développeurs. La roadmap gagne en souplesse, et le déploiement cesse d’être un goulet d’étranglement en fin de sprint.

FAQ feature flags

Feature flag ou feature toggle : quelle différence ?

Aucune, les deux termes désignent le même mécanisme. « Feature flag » domine aujourd’hui chez les éditeurs d’outils, « feature toggle » reste courant dans la littérature technique.

Faut-il un outil dédié ou peut-on créer ses propres flags ?

Pour démarrer, une variable de configuration ou une colonne en base de données suffit largement. Un outil dédié devient utile quand on a besoin de cibler des segments, de déployer par pourcentage ou de donner la main aux équipes produit sans passer par un développeur. Beaucoup d’équipes commencent avec une solution maison et migrent quand elle atteint ses limites.

Combien de temps garder un feature flag ?

Un flag de release ou d’expérimentation devrait vivre quelques semaines, le temps de valider la fonctionnalité, puis être supprimé du code. Les flags de permission et les flags opérationnels, eux, font partie du produit et restent en place aussi longtemps que nécessaire.

Comment Polara Studio utilise les feature flags

Chez Polara Studio, les feature flags font partie de notre boîte à outils standard pour les projets SaaS. Nous les mettons en place dès que les déploiements touchent de vrais utilisateurs, ce qui arrive souvent plus tôt qu’on ne le pense.

Notre approche est pragmatique : déploiement progressif pour les fonctionnalités à risque, expérimentation quand le volume d’utilisateurs le permet, flags de permission pour la gestion des plans tarifaires. Et surtout, une politique de nettoyage des flags temporaires intégrée à notre processus de release, pour que la dette ne s’accumule pas. L’objectif est de permettre à nos clients de livrer vite sans sacrifier la stabilité.