# C'est quoi un feature flag ? Guide SRE avec code et runbook

URL: https://upstreamapi.com/fr/journal/c-est-quoi-un-feature-flag
Type: blog
Locale: fr
Published: 2026-10-17
Updated: 2026-10-17

---

> Un feature flag transforme une release en cadran réglable. Voici ce que c'est, les quatre types, comment les SRE réduisent le blast radius et comment la dette de flags finit par vous rattraper.

Il est 03:12 et le taux d'erreur du checkout vient de dépasser 4 %. Le changement responsable a été mis en prod il y a six heures. Personne ne veut revert toute la release, parce qu'elle embarque aussi deux correctifs sans rapport. Alors, c'est quoi un feature flag dans cette situation ? C'est une condition dans votre code, lue à l'exécution, qui décide si un chemin de code s'exécute. Vous la passez à off, le nouveau chemin cesse de tourner, sans build ni déploiement. L'idée tient en une phrase. Tout le reste relève de l'exploitation.

## Ce qu'est vraiment un feature flag (et ce qu'il n'est pas)

Un feature flag est un point de décision. Quelque part dans le code, il y a un `if`, et la valeur qu'il lit vient de l'extérieur du binaire : un service de configuration, une ligne en base, un SDK de fournisseur, une variable d'environnement modifiable sans redémarrage.

`const useNewPricing = await flags.isEnabled("new-pricing-engine", {
  userId: user.id,
  plan: user.plan,
  region: request.region,
});

return useNewPricing
  ? newPricingEngine.quote(cart)
  : legacyPricing.quote(cart);`Trois conséquences découlent de ce snippet. L'ancien chemin doit toujours exister et doit toujours fonctionner. Le flag a besoin d'un contexte (qui demande ?) si vous voulez mieux qu'un simple on ou off. Et l'évaluation se trouve sur le chemin chaud d'une requête : sa latence et son mode de défaillance deviennent votre problème.

On emploie indifféremment « feature toggle » et « feature flag ». Le mot compte peu, le comportement compte beaucoup : vous séparez le déploiement du code de sa mise à disposition. Le code part en prod dans l'ombre, et une personne ou un système décide plus tard qui le voit.

## Les quatre types de flag, et pourquoi les mélanger fait mal

Une bonne partie des problèmes vient du fait de traiter tous les flags comme une seule chose. La [taxonomie de Martin Fowler](https://martinfowler.com/articles/feature-toggles.html) les découpe selon leur durée de vie et la dynamique de leur décision. Elle tient bien en pratique.

Les release toggles sont transitoires. Ils masquent un travail inachevé pour que vous puissiez merger sur le trunk chaque jour. Selon Fowler, ils ne devraient guère survivre plus d'une ou deux semaines. La décision est statique : chaque requête d'une release donnée reçoit la même réponse.

Les experiment toggles répartissent des utilisateurs différents entre des variantes. Ils restent actifs le temps d'atteindre une significativité statistique, de quelques heures à quelques semaines, pas davantage. La décision se prend à chaque requête.

Les ops toggles pilotent le comportement opérationnel : couper une fonctionnalité non critique sous charge, basculer sur une dépendance de secours, désactiver une requête coûteuse. Certains deviennent des kill switches de longue durée. Ils doivent basculer en quelques secondes, ce qui exclut tout ce qui nécessite une release.

Les permission toggles conditionnent une fonctionnalité au plan ou à un droit. Ils peuvent vivre des années, et la décision se prend par utilisateur, à chaque requête.

L'erreur consiste à donner aux quatre le même cycle de vie. Un permission toggle a besoin d'un propriétaire et d'une trace d'audit pour toujours. Un release toggle a besoin d'une date de suppression le jour même de sa création. Si vous ne savez pas identifier le type d'un flag à partir de son nom, vous ne saurez pas non plus lesquels sont sûrs à retirer.

![Main tirant un levier rouge de kill switch sur une armoire de contrôle sombre](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/fa4827-i1.webp)

## Pourquoi les SRE s'y intéressent : le flag comme contrôle du blast radius

Pour une équipe plateforme, la propriété intéressante n'est pas le A/B testing. C'est qu'un flag transforme une release en événement en cadran réglable.

Sans flag, un déploiement expose 100 % du trafic au changement d'un coup. Le seul rollback possible est un autre déploiement, qui prend autant de temps que votre pipeline, plus le temps qu'un humain met à en être sûr. Avec un flag, vous exposez 1 % des utilisateurs, vous surveillez le taux d'erreur et le p99, puis vous passez à 5, 25, 50. Le blast radius est le pourcentage que vous avez choisi, et le revert est un changement de configuration qui se propage en quelques secondes.

Cela change votre MTTR plus que la plupart des investissements en outillage. La question du post-mortem n'est plus « pourquoi le rollback a-t-il pris 40 minutes ? » mais « pourquoi ce n'était pas derrière un flag ? »

Le cadran a un piège : il faut quelqu'un pour surveiller les signaux et le tourner. À 03:12, cette personne est fatiguée. La version utile d'un système de flags relie le cadran à un SLO : si le taux d'erreur consomme une part définie du budget d'erreur, le rollout s'arrête et revient en arrière sans humain dans la boucle. La plupart des équipes construisent cela à la main, avec un webhook qui relie leur outil d'alerte à l'API de flags. Cela représente quelques centaines de lignes, et cela se rentabilise la première nuit où ça se déclenche.

## La facture arrive : la dette des flags et la leçon Knight Capital

Chaque flag ajouté double, en théorie, le nombre de chemins possibles dans ce code. En pratique, vous testez quelques combinaisons et vous espérez. Fowler recommande de traiter les flags comme un inventaire qui a un coût de portage : créez une tâche de suppression dans le backlog au moment de la création, fixez des dates d'expiration et, dans les équipes les plus strictes, faites échouer le build quand un flag expiré est encore dans le code.

La version coûteuse de cette leçon, c'est Knight Capital. Le 1er août 2012, un nouveau déploiement a réutilisé un ancien flag qui avait contrôlé une fonctionnalité retirée. Un serveur a manqué le déploiement et exécutait toujours l'ancien code. Dans les 45 premières minutes après l'ouverture, le routeur de la société a envoyé plus de 4 millions d'ordres sur le marché pour exécuter 212 ordres de clients, comme le relève le [communiqué de la SEC contre Knight Capital](https://www.sec.gov/newsroom/press-releases/2013-222). L'article de Fowler cite la perte, d'environ 460 millions de $, comme mise en garde sur les flags qu'on ne gère pas.

Le flag n'était pas le seul point de défaillance. Le déploiement manuel, l'absence de kill switch et une détection lente ont tous pesé. Mais la réutilisation d'un nom de flag mort est le détail que chaque équipe plateforme devrait garder au mur. Ne réutilisez jamais un flag. Supprimez l'ancien, créez-en un nouveau, et faites de la suppression une étape à part entière.

![Carnet avec schémas de flux dessinés à la main, à côté d'un clavier et d'un ordinateur portable sur un bureau en bois](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/652884-i2.webp)

## Le construire soi-même ou acheter une plateforme de flags ?

Un système de flags maison commence par un fichier de configuration et un booléen. C'est suffisant pour la première dizaine de release toggles sur un service. Cela cesse de l'être quand vous avez besoin de rollouts en pourcentage stables par utilisateur, de règles de ciblage par segment, d'un journal d'audit de qui a changé quoi, et d'une modification qui atteint chaque instance en quelques secondes sans ruée sur votre store de configuration.

À ce stade, vous comparez des plateformes sur des critères mesurables : latence d'évaluation du SDK (évaluation locale ou appel réseau), streaming ou polling pour les mises à jour, granularité des règles de ciblage, support multi-environnements, et façon dont le compteur de facturation grandit avec votre trafic.

Les compteurs diffèrent davantage que les listes de fonctionnalités.

LaunchDarkly est l'implémentation de référence de la catégorie : ciblage mature, releases protégées et une surface d'intégration profonde. Ses formules à l'usage facturent par connexion de service et par millier d'utilisateurs actifs mensuels côté client. Une application grand public avec une large audience anonyme peut donc voir la facture bouger d'une façon qu'une équipe purement backend ne verra pas. L'argument en sa faveur est réel : si vous avez besoin de gouvernance et d'audit à l'échelle d'une entreprise, c'est la solution qui a eu le plus de temps pour se durcir.

Statsig regroupe flags, expérimentation et analytics produit, et facture à l'événement. Cela convient aux équipes qui considèrent les flags surtout comme une surface d'expérimentation. Si votre usage relève surtout des ops toggles et des kill switches, vous payez de l'analytics que vous ne lirez peut-être pas. Notez aussi que le fournisseur a changé de propriétaire à deux reprises depuis septembre 2025, ce qui mérite une ligne dans votre revue de risques fournisseurs.

Quel que soit votre choix, testez le mode de défaillance avant de signer. Coupez l'accès réseau du SDK en staging et regardez ce que fait l'application. Un bon SDK sert les dernières valeurs de flags connues depuis le cache et journalise bruyamment. Un mauvais bloque le chemin de la requête.

## L'observabilité est la moitié du système de flags

Un flag sans télémétrie reste une supposition. Le minimum utile consiste à attacher l'état du flag à chaque trace et à chaque ligne de log de la requête, pour qu'en cas de pic d'erreurs vous puissiez regrouper par variante et voir si le nouveau chemin en est la cause.

Datadog et les plateformes tout-en-un similaires rendent la ventilation par variante simple dès que votre SDK tague les spans. Attention toutefois : la facturation par hôte et par signal grimpe vite quand vous ajoutez des tags à forte cardinalité, comme la clé du flag combinée à la variante et au segment utilisateur. Choisissez délibérément les dimensions que vous taguez.

Grafana est la voie la moins chère si vous faites déjà tourner Prometheus et OpenTelemetry. Vous construirez vous-même les dashboards sensibles aux flags, ce qui coûte du temps d'ingénierie mais vous laisse le contrôle total des labels émis. Pour une équipe de 50 à 500 ingénieurs avec un groupe plateforme, ce compromis est souvent le bon.

![Ingénieur marchant dans une allée de baies serveurs éclairée en bleu et ambre](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/3ea456-i3.webp)

## Un runbook court pour votre premier flag en production

Si vous introduisez les flags dans une équipe qui n'en a pas, gardez le premier rollout ennuyeux.

- 
Choisissez un changement avec une métrique de succès claire, comme le taux d'erreur du checkout ou le p99 d'un endpoint.

- 
Nommez le flag avec son type et son propriétaire, par exemple `release.checkout.new-tax-calc.owner-payments`.

- 
Créez dès maintenant le ticket de suppression et fixez une date d'expiration à deux semaines au plus.

- 
Déployez à 1 %, maintenez un cycle de trafic complet, puis augmentez. Définissez à l'avance le seuil auquel vous revenez en arrière.

- 
Faites du revert une commande ou un bouton unique, et répétez-le une fois en staging avant d'en avoir besoin la nuit.

- 
Une fois que les 100 % ont tenu quelques jours, supprimez le flag et l'ancien chemin de code dans le même changement.

L'étape 6 n'a rien de glamour, et c'est pourtant celle que les équipes sautent. Elles finissent avec quelques centaines de flags, personne ne sait ce que fait la moitié d'entre eux, et un risque de type Knight planté au cœur du dépôt.

## Et si votre dernier incident s'était déroulé derrière un flag ?

Prenez le dernier incident de production que votre équipe a documenté. Posez-vous trois questions. Le changement aurait-il pu sortir dans l'ombre ? Une seule personne aurait-elle pu le désactiver en moins d'une minute, sans déploiement ? Une alerte vous aurait-elle indiqué quelle variante échouait ?

Si les réponses sont non, non et non, vous avez votre premier candidat au flag, et votre première estimation honnête de ce que coûte un revert aujourd'hui. Le post-mortem dira ce qu'il dira. La meilleure question est de savoir de combien vous auriez pu réduire l'ampleur de l'incident avant que le pager ne sonne.

## FAQ

### C'est quoi un feature flag, en clair ?

C'est une condition dans votre code, lue à l'exécution, qui décide si un chemin de code s'exécute. La valeur vient de l'extérieur du binaire, par exemple d'un service de configuration ou d'un SDK de fournisseur, ce qui permet de changer le comportement sans nouveau déploiement.

### Quelle différence entre un feature flag et un feature toggle ?

En pratique, aucune. Les deux termes décrivent le même mécanisme. Certains éditeurs réservent toggle à la pratique et flag à l'implémentation, mais les équipes les emploient indifféremment.

### Quels sont les principaux types de feature flags ?

On en distingue généralement quatre : les release toggles pour masquer un travail inachevé, les experiment toggles pour les tests A/B, les ops toggles pour le pilotage en production comme les kill switches, et les permission toggles pour conditionner au plan ou aux droits. Chacun a une durée de vie attendue différente.

### Combien de temps un feature flag doit-il vivre ?

Cela dépend du type. Un release toggle doit en général être retiré en une ou deux semaines. Un experiment toggle vit le temps d'atteindre la significativité. Les kill switches et les permission toggles peuvent vivre des années, à condition d'avoir un propriétaire clair.

### Qu'est-ce qu'un kill switch dans un logiciel ?

C'est un flag ops de longue durée qui permet à un opérateur de désactiver instantanément en production une fonctionnalité ou une dépendance, sans déploiement. On s'en sert pour dégrader proprement sous charge ou pour arrêter un changement défaillant.

### Faut-il construire notre propre système de flags ou en acheter un ?

Un fichier de configuration et un booléen suffisent pour quelques release toggles sur un service. Dès que vous avez besoin de rollouts en pourcentage stables, de ciblage par segment, de journaux d'audit et d'une propagation rapide entre instances, comparez les plateformes sur la latence du SDK, le mécanisme de mise à jour, la granularité du ciblage et la façon dont le compteur de facturation évolue.

### Les feature flags peuvent-ils provoquer des pannes ?

Oui. Réutiliser un ancien nom de flag, laisser des chemins de code morts en place et ne pas tester les combinaisons de flags sont des causes fréquentes. L'incident Knight Capital de 2012 impliquait un flag réutilisé. Traitez les flags comme un inventaire avec des dates d'expiration, et ne réutilisez jamais un flag.