Que sont les Feature Flags ?

Que sont les feature flags ?

Les feature flags (aussi appelés feature toggles, feature gates ou release toggles) sont des vérifications conditionnelles dans le code qui activent ou désactivent le comportement de l'application en production sans redéploiement. La vérification ressemble à if (featureFlags.newCheckoutFlow) { /* nouveau code */ } else { /* ancien code */ }. La valeur de newCheckoutFlow est récupérée au runtime depuis un service de flags — LaunchDarkly, ConfigCat, GrowthBook ou votre propre système maison — et peut changer instantanément pour n'importe quel utilisateur, pourcentage de trafic ou cohorte spécifique.

L'idée centrale : déploiement ≠ release. Sans flags, expédier du code signifie le rendre vivant pour tout le monde. Avec les flags, le code peut être expédié en production derrière un flag, rester sombre pendant des semaines pendant que vous l'ajustez en interne, puis progressivement déployé à 1%, 5%, 50%, 100% des utilisateurs. Si quelque chose casse, retournez le flag. Pas de redéploiement, pas de rollback, pas de panique.

Les quatre cas d'usage canoniques

1. Toggles de release (rollout graduel)

Expédier du code en production derrière un flag, désactivé par défaut. Activer graduellement pour utilisateurs internes → cohorte bêta → canary 1% → 10% → 100%. Si les métriques se dégradent à n'importe quelle étape (erreurs en pic, conversion en chute, latence p95 en hausse), retournez le flag instantanément. Sans flags, vous auriez besoin de redéployer ou de faire git-revert pour récupérer.

2. Toggles d'expérience / test A/B

50% des utilisateurs voient la version A, 50% voient la version B. Le service de flags trace quel utilisateur a obtenu quelle variante. L'analytique corrèle les actions utilisateur avec la variante. L'analyse statistique décide du gagnant. Les grandes plateformes d'expérimentation (Optimizely, LaunchDarkly Experiments) se construisent entièrement sur cette primitive.

3. Toggles de permissions / entitlements

Différents utilisateurs voient différentes fonctionnalités selon leur palier de plan, organisation ou rôle. Les fonctionnalités "plan Pro uniquement" sont gatées par flags ; la valeur du flag dépend de l'état du compte de l'utilisateur. Fonctionnellement similaire à l'autorisation traditionnelle mais gérée dans le même dashboard de flags que les releases.

4. Kill switches (toggles opérationnels)

Enveloppez les chemins de code risqués ou coûteux (appels d'API tiers, moteurs de recommandation, inférence ML) dans des flags pour pouvoir les désactiver sous charge ou pendant des incidents. Le site échoue parce que l'API de recommandations timeout ? Retournez le flag, repliez-vous sur une expérience plus simple, gérez le tiers en calme.

Comment fonctionnent les systèmes de feature flags

L'architecture sous le capot :

• Définitions de flags stockées centralement. Un dashboard web permet aux équipes produit/ingénierie de définir des flags, configurer des règles de ciblage ("100% des utilisateurs en UE", "10% des utilisateurs avec plan=pro", "cette liste spécifique d'user_id") et activer/désactiver.
• SDKs clients dans votre application. Votre app récupère les valeurs de flags depuis le service soit au démarrage (caché en mémoire) soit par requête (typiquement avec un cache local agressif). Des SDKs existent pour chaque langage et framework majeur.
• Mises à jour streaming. Les services de flags modernes utilisent WebSockets ou Server-Sent Events pour pousser les changements de valeurs de flag vers les clients en cours d'exécution en quelques millisecondes. Basculez le flag dans le dashboard ; le trafic de production se déplace quelques secondes plus tard.
• Télémétrie en retour. Les services de flags capturent quelles valeurs de flag ont servi quelles requêtes, permettant l'audit ("qui a basculé ce flag à 03:42 ?") et l'expérimentation (corréler le comportement utilisateur avec la variante).

Build vs buy : les quatre vraies options

• Buy : LaunchDarkly. Le leader du marché. Écosystème SDK mature, ciblage sophistiqué, cher à l'échelle (1k-50k+ $/an). Option pay-for-confidence.
• Buy : ConfigCat / Flagsmith / Statsig. Alternatives moins chères, ensembles de fonctionnalités décents, plus rapides à évaluer. ConfigCat a un palier gratuit généreux ; Flagsmith est open-source-et-self-host-friendly.
• Buy : GrowthBook (open source). Particulièrement fort pour les cas d'usage d'expérimentation. Self-host ou utilisez la version SaaS.
• Build : en interne. Un service de flags simple fait ~500 lignes de code : définitions de flags dans une base de données, une API pour les récupérer, un dashboard, règles de ciblage basiques. Vaut la peine de construire si vous avez des exigences de conformité spécifiques (les données doivent rester dans votre VPC) ou si les besoins de votre équipe sont étroits. La plupart des équipes sous-estiment la maintenance à long terme.

Pièges courants des feature flags

• Explosion de flags. Sans gouvernance, les équipes expédient des flags mais ne les suppriment jamais. Après un an, le codebase a 200 flags, dont la moitié ne sont plus nécessaires. Définissez une politique : chaque flag a une date d'expiration et un owner ; le nettoyage fait partie de la définition-of-done du release.
• Couplage caché entre flags. Le Flag A n'a de sens que quand le Flag B est activé. Sans dépendances explicites, un coéquipier désactive B et casse A. Gardez les relations entre flags documentées ; envisagez une fonctionnalité de "flag composé" dans le service.
• Explosion de la matrice de tests. 10 flags booléens indépendants = 1024 chemins de code possibles. Vous ne ferez pas la QA de tous. Utilisez des flags prérequis, testez les combinaisons les plus utilisées et fiez-vous à l'observabilité production pour attraper le reste.
• Latence sur cache froid. Le premier fetch de flag au démarrage de l'app bloque la requête. Pré-chauffez le cache, utilisez des SDKs streaming ou repliez-vous sur des defaults sûrs si le service de flags est inaccessible.
• Service de flags comme single point of failure. Si le service de flags tombe, votre app doit continuer à fonctionner. Les SDKs cachent typiquement les dernières valeurs connues bonnes et se replient gracieusement — mais vérifiez que c'est vrai et testez-le (lancez une expérience de chaos qui bloque les appels réseau au service de flags).
• Coincé dans le flag-purgatoire. Le flag passe de 0% → 50% → bloqué. Le owner change d'équipe, le flag n'atteint jamais 100%. La moitié nettoyage est plus dure que la moitié rollout. Construisez-le dans votre processus ou vous noierez dans le cruft.

Feature flags vs config flags vs environment variables

Trois concepts liés :

• Feature flags : Mutables au runtime, souvent ciblés par utilisateur, parfois A/B testés. Alimentés par un service de flags.
• Config flags : Configuration d'application (chaînes de connexion à la base de données, clés API, timeouts). Habituellement définis par environnement, changés via redéploiement ou config-reload.
• Environment variables : Configuration au niveau OS. Fondamental mais inflexible — les changements nécessitent un redémarrage de processus.

Ne les confondez pas. Les feature flags sont pour les décisions produit/release ; le config est pour les paramètres opérationnels ; les environment variables sont pour le bootstrap système.

FAQ : Feature Flags

Les feature flags sont-ils excessifs pour les petites équipes ?

Plus maintenant. Des outils comme ConfigCat ont des paliers gratuits utilisables pour les petites équipes. Même un dev shop unique bénéficie des kill switches et des rollouts graduels. Le overhead d'un service de flags est petit comparé au coût de pompiers d'un mauvais release.

Quelle est la différence entre feature flags et trunk-based development ?

Ils sont complémentaires. Le trunk-based development signifie que chaque commit va à main ; les feature flags vous permettent de garder du code incomplet en main en toute sécurité sans que les utilisateurs le voient. Ensemble ils permettent l'intégration continue sans branches longue durée.

Comment les feature flags affectent-ils les tests ?

Testez le chemin flag-on ET le chemin flag-off. Builds matrix CI avec les deux états. Pour les systèmes multi-flags, priorisez les combinaisons réellement utilisées en production. Certains services de flags (LaunchDarkly, Statsig) s'intègrent avec les test runners pour injecter des états spécifiques de flag pour les tests.

Les feature flags peuvent-ils nuire aux performances ?

Si mal implémentés, oui — récupérer une valeur de flag à chaque requête sans caching ajoute de la latence. Les SDKs modernes cachent agressivement (en mémoire) et mettent à jour via streaming, donc le coût par requête est en microsecondes, pas en millisecondes. Auditez votre setup SDK si la latence de flag semble élevée.

Devrais-je utiliser les feature flags pour les permissions ?

Avis partagé. Pour : le même dashboard pour releases + entitlements. Contre : les services de flags ne sont typiquement pas construits pour de l'ACL fine avec pistes d'audit. Pour les modèles de permissions complexes, utilisez un service authz dédié (Permit.io, OpenFGA, AWS Cedar). Pour le gating simple par palier de plan, les flags sont bien.

Comment les feature flags interagissent-ils avec l'analytique ?

Meilleure pratique : envoyez l'état actif du flag (ou la variante d'expérience) comme propriété d'événement à votre outil d'analytique. Cela vous permet de découper les métriques par variante et de confirmer que les expériences sont statistiquement valides. Sans ça, vous ne pouvez pas dire si une chute de métrique est due à un changement de flag ou à du bruit organique.

Comment LoadFocus se rapporte aux rollouts de feature flags

Les rollouts de feature flags sont exactement quand les tests de charge comptent le plus. Les nouveaux chemins de code basculés pour 10% du trafic pourraient soudainement marteler des endpoints coûteux différemment du vieux code. Les tests de charge LoadFocus contre le nouveau chemin de code avant le flip de flag valident qu'il tient à l'échelle. Le monitoring d'API pendant le rollout attrape les régressions de latence en temps réel pour que vous puissiez retourner le flag avant que les utilisateurs ne le remarquent.