Feature flags

Les feature flags (aussi appelés feature toggles ou feature switches) sont un mécanisme qui permet de contrôler la disponibilité d’une fonctionnalité dans une application via un simple interrupteur — sans toucher au code et sans redéployer. Le code de la fonctionnalité est présent en production, mais il ne s’exécute que si le flag est activé.

C’est une distinction fondamentale : déployer du code et activer une fonctionnalité deviennent deux actions séparées. On peut déployer le code d’une nouvelle fonctionnalité le lundi, la tester en interne le mardi, l’ouvrir à 10 % des utilisateurs le mercredi, et la généraliser le jeudi — ou la désactiver instantanément si un problème est détecté. Tout cela sans aucun redéploiement.

Pourquoi les feature flags changent la donne

Déployer sans risque

Dans le modèle classique, déployer une nouvelle fonctionnalité est un événement stressant. On prépare le code, on le teste, on choisit un créneau de déploiement, on croise les doigts, et si quelque chose ne va pas, on fait un rollback — un processus qui peut prendre des minutes précieuses pendant lesquelles les utilisateurs sont impactés.

Avec les feature flags, le risque est réduit à presque zéro. Si la fonctionnalité cause un problème, il suffit de désactiver le flag — en quelques secondes, sans redéploiement, sans interruption de service. C’est ce qu’on appelle un kill switch, et c’est probablement l’usage le plus précieux des feature flags pour les produits SaaS en production.

Déploiement progressif

Au lieu de tout ouvrir d’un coup à tous les utilisateurs, les feature flags permettent un déploiement progressif (ou canary release). On commence par activer la fonctionnalité pour 1 % des utilisateurs, on observe les KPI et les métriques de performance, puis on augmente progressivement — 5 %, 20 %, 50 %, 100 %. Si un problème apparaît à 5 %, il n’affecte que 5 % des utilisateurs au lieu de 100 %.

Cette approche est particulièrement pertinente pour les fonctionnalités qui touchent à des composants critiques — le paiement, l’authentification, le traitement de données — où un bug en production peut avoir des conséquences lourdes.

Expérimentation produit

Les feature flags sont le fondement technique de l’A/B testing. Pour comparer deux versions d’une fonctionnalité, il suffit d’activer la version A pour un groupe d’utilisateurs et la version B pour un autre, puis de mesurer l’impact sur les métriques qui comptent — taux de conversion, rétention, engagement.

Dans une stratégie de Product-Led Growth, cette capacité d’expérimentation rapide est un avantage compétitif majeur. L’équipe produit peut tester des hypothèses en production, avec de vrais utilisateurs, sans attendre un cycle de développement complet.

Les types de feature flags

Tous les feature flags ne servent pas le même objectif, et il est important de distinguer les types pour les gérer correctement.

Les flags de release contrôlent le déploiement progressif d’une nouvelle fonctionnalité. Ils sont temporaires par nature — une fois la fonctionnalité validée et activée pour tous les utilisateurs, le flag doit être supprimé du code.

Les flags d’expérimentation supportent les tests A/B et les expériences produit. Ils sont également temporaires — une fois l’expérience terminée et la décision prise, le flag est retiré.

Les flags opérationnels permettent de gérer des situations de charge ou de crise. Par exemple, désactiver temporairement une fonctionnalité gourmande en ressources quand le système est sous pression. Ils peuvent être permanents, car ils jouent un rôle dans la scalabilité et la résilience du système.

Les flags de permission contrôlent l’accès à des fonctionnalités en fonction du plan ou du rôle de l’utilisateur — un plan gratuit voit certaines fonctionnalités, un plan premium en voit d’autres. Ces flags sont permanents et font partie de la logique métier du produit.

Comment ça fonctionne techniquement

L’implémentation de base est simple. Dans le code, on encadre la fonctionnalité par une condition :

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 la condition en temps réel : le flag est-il activé globalement ? Est-il activé pour ce segment d’utilisateurs ? Pour ce pourcentage de trafic ? La réponse détermine quelle version du code s’exécute.

Les outils modernes permettent de cibler finement : par utilisateur individuel (pour les bêta-testeurs), par segment (les clients du plan Enterprise), par pourcentage (10 % du trafic), par géographie, ou par combinaison de critères.

Les outils les plus courants

LaunchDarkly est la référence du marché — complet, fiable, avec des SDK pour tous les langages et frameworks. C’est l’outil de choix pour les équipes qui font de l’expérimentation intensive, mais son prix peut être élevé pour les petites structures.

PostHog combine feature flags, analytics produit et A/B testing dans une seule plateforme open source. C’est un excellent choix pour les équipes qui veulent un outil tout-en-un sans dépendance à un service propriétaire.

Statsig se distingue par ses capacités statistiques avancées et son intégration native avec les métriques produit.

Unleash est une alternative open source populaire, auto-hébergeable, adaptée aux équipes qui veulent garder le contrôle total sur leurs données.

Les erreurs à éviter

Laisser les flags s’accumuler. C’est le piège le plus courant. Les flags temporaires (release et expérimentation) qui ne sont jamais supprimés transforment le code en un labyrinthe de conditions. Chaque flag non nettoyé est de la dette technique qui s’accumule. La bonne pratique est de fixer une date d’expiration à chaque flag temporaire et de le supprimer systématiquement une fois la décision prise.

Créer des combinaisons ingérables. Avec dix flags actifs, il existe potentiellement 1 024 combinaisons possibles de l’application. Certaines de ces combinaisons n’ont jamais été testées et peuvent produire des comportements inattendus. Il faut limiter le nombre de flags actifs simultanément et identifier les interactions critiques entre flags.

Utiliser les feature flags pour contourner un pipeline de CI/CD défaillant. Les feature flags ne sont pas un substitut à un processus de déploiement fiable — ils le complètent. Si l’équipe utilise les flags principalement pour « cacher du code qui n’est pas prêt », le vrai problème est ailleurs.

Négliger la performance. Chaque évaluation de flag ajoute un temps de traitement, même minime. Les outils modernes mettent en cache les évaluations localement, mais une implémentation naïve qui fait un appel réseau à chaque vérification de flag peut dégrader significativement la performance de l’application.

Feature flags et workflow d’équipe

Les feature flags transforment la manière dont une équipe planifie et livre ses fonctionnalités. Au lieu d’attendre qu’une fonctionnalité soit entièrement terminée pour la fusionner dans le code principal, les développeurs peuvent fusionner du code incomplet derrière un flag désactivé. Cela réduit les conflits de fusion, facilite les code reviews (les modifications sont plus petites et plus fréquentes), et aligne le code principal avec l’état réel du développement.

Pour l’équipe produit, les feature flags offrent une flexibilité inédite dans la gestion de la roadmap. Une fonctionnalité peut être prête techniquement mais retardée pour des raisons marketing ou commerciales — sans bloquer le travail de développement. Les sprints deviennent plus fluides, car le déploiement n’est plus un goulet d’étranglement.

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 le produit atteint un stade où les déploiements impactent des utilisateurs réels — ce qui arrive souvent plus tôt qu’on ne le pense.

Notre approche est pragmatique : nous utilisons les feature flags pour les déploiements progressifs des fonctionnalités à risque, pour l’expérimentation produit quand le volume d’utilisateurs le permet, et pour la gestion des plans tarifaires. Nous intégrons systématiquement une politique de nettoyage des flags temporaires dans notre processus de release, pour éviter que la dette s’accumule. L’objectif est de donner à nos clients la capacité de livrer vite sans sacrifier la stabilité.