Qu'est-ce qu'un feature flag ? Définition, cas d'usage, pièges

Qu'est-ce qu'un feature flag ?

Un feature flag (aussi appelé feature toggle, feature gate ou interrupteur de fonctionnalité) est une condition dans le code qui active ou désactive un comportement à l'exécution, sans nouveau déploiement. La valeur provient d'un service de flags ou d'un stockage de configuration et peut varier selon l'utilisateur, la part de trafic ou la cohorte. L'idée centrale : séparer le déploiement de la mise en production d'une fonctionnalité. Le code arrive en production masqué derrière un flag, puis on l'active progressivement.

if (flags.isEnabled("new-checkout", user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Les quatre cas d'usage courants

Toggles de livraison

Le code est livré désactivé, puis activé pour l'équipe, un groupe bêta, 1 % du trafic, 10 % et enfin tout le monde. Si les erreurs ou la latence grimpent à une étape, on remet le flag en arrière au lieu d'annuler une version. C'est la forme à base de flags du déploiement progressif de fonctionnalités, qui s'associe bien à un déploiement canary (article en anglais).

Toggles d'expérimentation

La moitié des utilisateurs voit la variante A, l'autre la variante B ; on note qui a vu quoi et on compare les indicateurs qui comptent.

Toggles de permissions

On n'expose une fonctionnalité qu'à certains forfaits, organisations ou rôles. Pratique pour une limitation simple par forfait ; pour des modèles de droits complexes, utilisez un système d'autorisation dédié.

Kill switches

On encapsule les chemins risqués ou coûteux, comme un appel à un tiers ou une étape de recommandation gourmande, pour pouvoir les couper pendant un incident et se rabattre sur quelque chose de plus simple.

Comment fonctionne un système de flags

• Des définitions centralisées. Un tableau de bord ou une API conserve chaque flag et ses règles de ciblage.
• Un SDK dans votre application. Il récupère les valeurs au démarrage ou à chaque requête et les garde dans un cache local, si bien qu'une vérification coûte très peu.
• Les mises à jour. Les changements parviennent aux applications en cours d'exécution par interrogation régulière ou par un flux poussé, selon l'outil.
• Une piste d'audit. Les bons outils consignent qui a modifié quel flag et quand, et quelle variante chaque requête a reçue.

Vous pouvez l'acheter chez un éditeur, utiliser un outil open source ou construire un petit service maison. Le choix dépend des besoins de ciblage, de la résidence des données et de la maintenance que votre équipe accepte de porter.

Pièges courants

• Des flags jamais supprimés. Chaque flag a besoin d'un responsable et d'une date d'expiration, et retirer le chemin de code mort fait partie de la fin de la fonctionnalité.
• Des dépendances cachées entre flags. Le flag A ne marche que si le flag B est actif. Documentez-le ou modélisez-le comme prérequis.
• Trop de combinaisons à tester. Dix flags booléens indépendants donnent 1 024 combinaisons. Testez chaque flag activé et désactivé, plus les combinaisons réellement présentes en production.
• Le service de flags comme point de défaillance unique. Votre application doit continuer à fonctionner avec des valeurs en cache ou par défaut si le service est injoignable. Vérifiez-le en le bloquant, ne le supposez pas.
• Une première récupération lente. Évaluez les flags depuis un cache local, pas avec un appel réseau par requête.
• Des flags confondus avec la configuration. Les feature flags portent des décisions de produit et de livraison et changent à l'exécution. La configuration (délais d'attente, chaînes de connexion) et les variables d'environnement sont des réglages d'exploitation qui changent en général avec un déploiement ou un redémarrage.

Feature flags, tests de charge et monitoring

Basculer un flag change le code exécuté, donc potentiellement la charge : un nouveau chemin peut solliciter une base de données ou un endpoint très différemment de l'ancien. Lancez un test de charge sur le nouveau chemin avant d'augmenter le pourcentage ; LoadFocus exécute des tests JMeter et k6 depuis 25 régions cloud, et l'offre gratuite inclut jusqu'à 10 utilisateurs virtuels. Pendant le déploiement, le monitoring d'API vérifie à intervalle régulier le code de statut, le corps et le temps de réponse (toutes les 5 minutes sur l'offre gratuite), de sorte qu'une régression apparaît tant que vous pouvez encore remettre le flag en arrière. Surveillez la latence par variante, pas seulement globalement.

Questions fréquentes sur les feature flags

Les feature flags sont-ils excessifs pour une petite équipe ?

En général non. Même une équipe d'une personne profite d'un kill switch et d'activer d'abord une fonctionnalité pour elle seule. Un flag simple piloté par la configuration suffit pour démarrer ; passez à un vrai service de flags quand il vous faut du ciblage et un audit.

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

Ils se complètent. Avec le trunk-based development, les petits changements sont intégrés en continu dans la branche principale ; les feature flags permettent d'y laisser du travail inachevé sans que les utilisateurs le voient.

Quel impact sur les tests ?

Testez le chemin activé et désactivé de chaque flag, ainsi que les combinaisons présentes en production. Faites de l'état du flag une entrée explicite des tests pour que les résultats soient reproductibles.

Les feature flags peuvent-ils ralentir mon application ?

Seulement s'ils sont mal implémentés, par exemple avec un appel réseau à chaque requête. Évaluez depuis un cache en mémoire rafraîchi en arrière-plan et prévoyez une valeur par défaut sûre si le service tombe.

Faut-il utiliser des feature flags pour les permissions ?

Pour un accès simple par forfait, oui. Pour un contrôle d'accès fin avec des exigences d'audit, utilisez un système d'autorisation dédié et gardez les flags pour les décisions de déploiement.

Faut-il envoyer l'état des flags à l'analytique ?

Oui. Joignez le flag ou la variante active à vos événements pour comparer les indicateurs par variante et distinguer l'effet du flag du bruit de fond.