Feature flags : types, cycle de vie et gouvernance pour les équipes

Feature flags : types, cycle de vie et gouvernance pour les équipes

Les feature flags vous permettent de déployer du code en production sans l’exposer, de l’activer pour quelques utilisateurs et de le désactiver en quelques secondes en cas de problème, le tout sans redéployer. Les adopter est la partie facile. Les gérer correctement, avec des types clairs, des responsables, des dates d’expiration et l’habitude de supprimer ce dont vous n’avez plus besoin, voilà ce qui fait la différence entre un filet de sécurité et une seconde base de code non documentée.

Cet article traite les feature flags comme une discipline. Il ne s’agit pas d’une comparaison des stratégies de déploiement. Pour une vue d’ensemble plus large des mises en production, consultez notre guide sur les gestion des mises en production. Nous nous concentrons ici sur les décisions à prendre avant de déployer le premier indicateur et sur les règles à appliquer après le centième.

Points clés à retenir

• Un feature flag sépare le déploiement (le code atteint la production) de la mise à disposition (les utilisateurs peuvent le voir). Cette séparation constitue toute sa valeur.
• Les flags ne se ressemblent pas tous. Les flags de mise en production, d’expérimentation, opérationnels et d’autorisation ont des durées de vie et des responsables différents, et doivent être gérés différemment.
• Chaque flag a besoin d’un responsable, d’un objectif et d’un plan de suppression dès le jour de sa création. Les flags obsolètes deviennent une dette technique et, dans le pire des cas, provoquent une interruption de service.
• Traitez les modifications de flags en production comme des modifications de code : contrôle des accès, revue, journaux d’audit et supervision.
• Le service de gestion des indicateurs est lui-même une dépendance. Concevez votre système pour le jour où il sera indisponible.

Table des matières

• Ce que font les indicateurs et ce qu’ils ne font pas
• Quatre types d’indicateurs, quatre durées de vie
• Le cycle de vie d’un feature flag, de sa création à sa suppression
• Gouvernance : qui peut modifier quoi en production
• stratégies de déploiement progressif et déploiement par pourcentage
• Quand les feature flags posent problème
• Choisir des outils de gestion des feature flags
• Comment nous accompagnons les programmes de feature flags
• Les feature flags sont une discipline, pas un simple interrupteur
• FAQ
• Sources

Ce que font les indicateurs de fonctionnalité et ce qu’ils ne font pas

Un indicateur de fonctionnalité, également appelé feature flag, est une logique conditionnelle évaluée lors de l’exécution qui détermine si un bloc de code s’exécute pour un utilisateur donné. Son état peut être modifié via une configuration externe, sans modifier ni redéployer l’application.

Cela offre une séparation nette. Le déploiement place le code en production. La mise à disposition rend la fonctionnalité accessible aux utilisateurs. Avec les indicateurs, les équipes peuvent placer du code en production tout en restreignant sa disponibilité, puis l’activer pour certains utilisateurs sans redémarrage ni nouveau déploiement. Les équipes utilisent cette séparation pour le développement fondé sur le tronc, les déploiements progressifs, les expérimentations, l’accès premium et le contrôle opérationnel.

Le développement fondé sur le tronc mérite qu’on s’y attarde. Comme les travaux inachevés peuvent être fusionnés derrière un indicateur désactivé, les branches restent courtes et les difficultés d’intégration diminuent. En contrepartie, votre branche principale contient désormais des chemins de code qui ne sont pas actifs, et quelqu’un doit en assurer le suivi.

Ce que les indicateurs ne sont pas : de la configuration. La configuration statique d’une application est généralement durable et chargée au démarrage, tandis que les indicateurs sont dynamiques, de courte durée et mis à jour lors de l’exécution. Confondre les deux est la meilleure façon de retrouver une chaîne de connexion à une base de données dans un tableau de bord d’indicateurs que trente personnes peuvent modifier.

Comment un indicateur est-il réellement évalué ? Un SDK intégré à votre application récupère les règles, les évalue en fonction de l’utilisateur et du contexte, puis applique le résultat. Un exemple documenté : un SDK serveur met en cache la configuration et interroge le service pour rechercher les mises à jour toutes les 60 secondes, les évaluations prenant généralement moins d’une milliseconde. La récupération et la résolution sont deux étapes distinctes, et les SDK peuvent récupérer les données au démarrage, en arrière-plan ou au cours d’une session. Ce détail prendra toute son importance lorsque nous aborderons les modes de défaillance.

Quatre types d’indicateurs de fonctionnalité, quatre durées de vie

La plupart des problèmes liés aux indicateurs commencent lorsqu’une équipe traite tous les indicateurs de la même manière. La taxonomie des indicateurs largement citée de Martin Fowler les distingue selon leur durée de vie et leur degré de dynamisme. En pratique, quatre catégories opérationnelles nous semblent utiles :

Indicateurs de mise en production

Ce sont les indicateurs les plus couramment utilisés. Ils existent pour permettre la fusion de code incomplet et faire du lancement une décision métier plutôt qu’un événement de déploiement. Ils doivent être les indicateurs dont la durée de vie est la plus courte. Si un indicateur de mise en production est plus ancien que la fonctionnalité elle-même, c’est qu’un problème est survenu.

Interrupteurs d’arrêt

Un interrupteur d’arrêt est un contrôle instantané, activable ou désactivable pour tous les utilisateurs, qui permet de désactiver en quelques secondes une fonctionnalité ou une dépendance qui se comporte mal, sans redéploiement. Les recommandations DevOps de Microsoft indiquent qu’un indicateur de désactivation rapide peut rétablir un comportement fiable et contrôler les changements d’architecture ou d’infrastructure, tout comme les fonctionnalités de l’interface utilisateur.

Les interrupteurs d’arrêt constituent l’exception légitime à la règle des courtes durées de vie. Fowler les décrit comme des indicateurs opérationnels de longue durée qui permettent aux opérateurs de dégrader progressivement les fonctionnalités non essentielles en cas de charge exceptionnellement élevée. C’est son observation sur la rapidité qu’il faut retenir : si la désactivation d’un élément nécessite une nouvelle version, l’indicateur a échoué dans son seul objectif. Placez un interrupteur d’arrêt autour de chaque appel coûteux à un service tiers, de chaque nouveau pipeline de données et de chaque fonctionnalité qui touche aux paiements ou aux e-mails, puis entraînez-vous à les utiliser.

Indicateurs d’expérimentation et indicateurs d’autorisation

Les indicateurs d’expérimentation restent actifs exactement pendant la durée du test. Déterminez la métrique et la date de fin avant d’activer l’indicateur. Les indicateurs d’autorisation sont en réalité des droits produit déguisés en indicateurs. Si l’accès dépend du forfait d’un client, modélisez-le comme un droit avec ses propres tests, et non comme une option que quelqu’un pourrait supprimer lors du nettoyage.

Le cycle de vie d’un indicateur, de sa création à sa suppression

La documentation d’Atlassian décrit un cycle de vie type composé de la création, de la configuration du ciblage, de l’évaluation à l’exécution et du nettoyage. La plupart des équipes maîtrisent bien les trois premières étapes et ignorent la quatrième. Un cycle de vie viable comporte six étapes :

1. Proposer. Consignez le nom, le type, le responsable, l’objectif et la date de suppression prévue de l’indicateur. Les noms doivent être uniques et suffisamment descriptifs pour qu’une nouvelle recrue puisse deviner le rôle de l’indicateur.
2. Construire. Séparez l’évaluation de l’indicateur de la logique métier afin que la décision se trouve dans une seule couche légère, plutôt que d’être dispersée dans les fonctions. Définissez une valeur par défaut sûre lorsque le service d’indicateurs ne peut pas répondre.
3. Tester. Testez les deux chemins d’exécution. Un indicateur dont une seule branche est testée est un bogue qui n’attend que son tour.
4. Déployez progressivement. Suivez le modèle de déploiement progressif que vous avez choisi tout en surveillant les taux d’erreur, la latence et les métriques métier.
5. Stabilisez. Une fois la fonctionnalité activée à 100 % et restée stable, l’indicateur a rempli son rôle.
6. Supprimez. Supprimez l’indicateur, le chemin de code non retenu et les tests correspondants. Vérifiez ensuite qu’aucune référence à l’indicateur ne subsiste dans la base de code.

C’est dans les cinquième et sixième étapes que la rigueur est essentielle. Les recherches suggèrent que le problème est réel et pas seulement théorique. Une étude empirique menée en 2021 sur 12 projets open source Python, ainsi qu’une enquête auprès de 61 professionnels, ont révélé que 75 % des composants d’activation ont été supprimés dans les 49 semaines, ce qui signifie également qu’une part importante ne l’a pas été et que certains indicateurs restés longtemps actifs n’étaient jamais destinés à perdurer. Ce sont ces survivants qui ajoutent discrètement du risque.

Prévenir la dette liée aux indicateurs

La dette liée aux indicateurs correspond à l’accumulation d’options qui ne servent plus à rien, mais qui continuent d’influencer le comportement du code. Le modèle de qualité arc42 cite la dette liée aux options, les états de test obsolètes et les collisions entre options interdépendantes parmi les modes d’échec de cette approche. Quelques habitudes permettent de la contenir :

• Des dates d’expiration dans la fiche de l’indicateur. Alertez le responsable lorsqu’un indicateur dépasse sa date d’expiration, puis de nouveau lorsqu’il est en retard.
• Un ticket de nettoyage créé avec l’indicateur. Pas plus tard. Lorsque le ticket de déploiement est clôturé, le ticket de suppression est déjà en attente.
• Un plafond d’indicateurs de mise en production actifs par équipe. Un nombre visible par tous crée une pression saine.
• Une analyse périodique du code. Harness recommande des alertes concernant les indicateurs obsolètes et la vérification du code pour repérer les indicateurs restants, ce qu’un contrôle CI peut automatiser.

Si votre équipe gère déjà un stock de code mort, la même approche de priorisation s’applique. Notre guide consacré à la remédiation de la dette technique explique comment évaluer et séquencer ce travail.

Gouvernance : qui peut modifier quoi en production

Modifier un indicateur en production constitue une modification de la production. Harness conseille de traiter la configuration des indicateurs de fonctionnalité comme du code de production, avec des contrôles de revue comparables, une dégradation progressive au moyen de valeurs mises en cache ou par défaut, ainsi qu’une compatibilité descendante. Voici à quoi cela ressemble concrètement pour un responsable technique :

• Accès basé sur les rôles. Toute personne qui peut lire les indicateurs ne devrait pas nécessairement pouvoir les activer ou les désactiver en production. LaunchDarkly cite un contrôle d’accès granulaire basé sur les rôles et des journaux d’audit parmi les fonctionnalités de sécurité destinées aux modifications contrôlées en production.
• Approbations pour les indicateurs à haut risque. Les paiements, l’authentification et la suppression de données méritent un second regard avant toute modification d’un indicateur.
• Journaux d’audit. Vous devriez pouvoir répondre à la question de savoir qui a modifié quoi et quand, sans avoir à vous renseigner dans les discussions.
• Discipline des environnements. La divergence de configuration entre la préproduction et la production est un mode de défaillance documenté ; comparez-les donc selon un calendrier établi plutôt que de compter sur la chance.
• Nommage et responsabilité clairs. Un indicateur sans responsable est un incident futur sans personne à appeler.

La sécurité fait partie de la gouvernance

Les indicateurs peuvent affaiblir la sécurité si vous manquez de prudence. Le guide de test de l’OWASP avertit que des états incohérents des indicateurs peuvent affaiblir l’authentification, l’autorisation, la détection des fraudes et la limitation du débit entre les services, en particulier lors d’un déploiement partiel, d’une restauration ou d’une défaillance du service d’indicateurs. Il précise également que les indicateurs visibles côté client ne constituent pas des frontières de sécurité. Appliquez l’autorisation sur le serveur, évaluez les indicateurs sensibles côté serveur et ne comptez jamais sur un bouton masqué comme mécanisme de contrôle. Si votre application traite des données réglementées, impliquez votre responsable de la sécurité avant qu’un premier indicateur ne concerne un parcours d’accès.

Stratégies de déploiement progressif et déploiement par pourcentage

Les indicateurs rendent possibles plusieurs modèles de déploiement progressif, et le choix approprié dépend de votre base d’utilisateurs. La documentation de LaunchDarkly décrit les déploiements par anneaux, les déploiements par pourcentage, les canaris, les déploiements ciblés, les déploiements selon les droits et les lancements discrets. En termes simples :

• Déploiement par anneaux : d’abord le personnel interne, puis un groupe bêta, puis tout le monde. Adapté lorsque vous disposez d’un public bêta naturel.
• Déploiement par pourcentage : exposer 1 %, puis 5 %, puis 25 %, et ainsi de suite. Convient surtout lorsque la base d’utilisateurs présente peu de variations ou que vous n’avez pas de programme bêta.
• Canari : un petit groupe représentatif destiné à tester l’acceptation et la capacité.
• Déploiement ciblé : des comptes ou groupes spécifiques, utile lorsque les clients dépendent les uns des autres.
• Lancement discret : le code est déployé et exécuté, mais il n’est pas rendu public.

Le modèle de déploiement progressif d’Azure ajoute des dimensions utiles : un ciblage par utilisateur, groupe ou attributs personnalisés tels que la région, le type d’appareil ou le niveau d’abonnement, ainsi qu’une activation planifiée. AWS expose bien cette logique : limiter le rayon d’impact tout en testant dans des conditions réelles est préférable à une exposition simultanée de tous les utilisateurs.

Deux règles rendent le déploiement par pourcentage fiable. Premièrement, conservez une attribution cohérente afin qu’un utilisateur qui voit le nouveau processus de paiement aujourd’hui ne voie pas l’ancien demain. Deuxièmement, définissez à l’avance ce que vous surveillerez et quel résultat déclenchera le coupe-circuit. Un déploiement sans condition d’arrêt n’est qu’un lancement au ralenti.

GitHub décrit l’activation des modifications risquées pour tout le monde ou pour un pourcentage d’utilisateurs après le déploiement, puis leur désactivation en quelques secondes sans effectuer de restauration. Cela ne fonctionne que si vous pouvez observer rapidement l’effet, raison pour laquelle les indicateurs et la supervision vont de pair. Notre article sur l’ observabilité des applications explique quoi instrumenter.

Quand les indicateurs posent problème

Les inconvénients sont précis et il vaut mieux les connaître avant de vous engager.

Code obsolète et réutilisation dangereuse. Le récit d’InfoQ sur l’incident de Knight Capital en 2012 décrit la réutilisation d’un indicateur obsolète alors que du code mort subsistait. Le résultat a été environ 460 millions de dollars de pertes en près de 30 minutes. Deux leçons à retenir : supprimez le code mort et ne réutilisez jamais le nom d’un ancien indicateur pour un nouveau comportement.

Complexité combinatoire. Chaque indicateur double théoriquement le nombre de chemins d’exécution. Vous ne les testerez pas tous ; limitez donc au minimum les indicateurs qui interagissent et documentez leurs dépendances. GitHub répertorie également des risques précis, tels que des requêtes de base de données plus lentes, des cas limites logiques inattendus et des valeurs de base de données non valides.

Le service de gestion des indicateurs comme point unique de défaillance. Le rapport d’incident de PostHog indique que 78 % des demandes d’évaluation des feature flags dans sa région des États-Unis ont échoué pendant 1 heure et 48 minutes, l’amplification des nouvelles tentatives et des contrôles de bon fonctionnement insuffisants ayant prolongé l’incident. Une analyse rétrospective ultérieure couvre quatre incidents survenus en 10 jours qui ont affecté l’application principale ainsi que l’évaluation des feature flags. La leçon à retenir pour vos propres systèmes : les caches locaux et les valeurs par défaut de secours permettent aux applications de continuer à fonctionner lorsque le système de gestion des indicateurs est indisponible, comme le souligne une recommandation de bonnes pratiques. Testez le comportement de votre application lorsque l’évaluation d’un feature flag expire. Ne le découvrez pas en production.

Évaluation incohérente. Un même feature flag peut produire des résultats différents au sein d’une seule requête s’il est lu deux fois. Évaluez-le une seule fois au début de la requête, puis transmettez le résultat.

Choisir des outils de gestion des feature flags

Construire un système de feature flags élémentaire est un projet de week-end. L’exploiter en toute sécurité pendant des années ne l’est pas ; prenez donc votre décision en toute connaissance de cause. Lorsque vous évaluez des plateformes ou une solution développée en interne, la liste des fonctionnalités de LaunchDarkly constitue une checklist utile : couverture des SDK, feature flags booléens et multivariés, ciblage et segmentation, déploiements progressifs, contrôle par environnement, prérequis, mises à jour en temps réel, interrupteurs d’arrêt, RBAC, approbations, journaux d’audit et intégrations.

Au-delà de cette liste, posez-vous les questions suivantes :

1. Que se passe-t-il lorsque le service est indisponible ? Recherchez la mise en cache locale et un comportement de secours documenté. Par exemple, la page tarifaire d’un fournisseur décrit des SDK qui téléchargent et mettent en cache la configuration, puis l’évaluent depuis ce cache.
2. À quelle vitesse les modifications sont-elles propagées ? En quelques secondes ou en quelques minutes ? L’intervalle d’interrogation correspond-il à vos attentes concernant l’interrupteur d’arrêt ?
3. Pouvez-vous gérer les feature flags sous forme de code ? Les workflows via l’interface utilisateur, la CLI, l’API et Git deviennent importants dès que vous avez plus de quelques dizaines de feature flags.
4. Le système vous aide-t-il à faire le ménage ? Les rapports sur les feature flags obsolètes ont plus de valeur qu’une option de ciblage supplémentaire.
5. Où vont les données utilisateur ? Évaluer les feature flags côté serveur permet de conserver les données personnelles hors des systèmes tiers.

Pour les petites équipes qui disposent de quelques feature flags de mise en production, une approche interne simple, avec des règles strictes de nommage et d’expiration, peut suffire. À mesure que les équipes, les services et les exigences de conformité se développent, les plateformes gérées justifient leur coût. La bonne réponse dépend de votre architecture, et c’est une question qu’il vaut mieux trancher avant d’avoir deux cents feature flags.

Comment nous vous aidons à mettre en place des programmes de feature flags

Chez Ridiculous Engineering, des ingénieurs seniors travaillent avec votre équipe sur les décisions liées aux feature flags : les types de feature flags dont vous avez besoin, la manière d’intégrer leur évaluation à votre architecture, la gouvernance adaptée à votre profil de risque et la façon d’intégrer le nettoyage à votre pipeline de livraison. Que vous modernisiez un système existant ou construisiez quelque chose de nouveau, nos services de conseil et d’accompagnement à la livraison de logiciels et nos missions de développement logiciel sur mesure sont définis en fonction de votre situation, avec une tarification sur demande. Vous pouvez également consulter nos articles sur le DevOps pour les pratiques connexes.

Les feature flags sont une discipline, pas un simple interrupteur

Les feature flags vous offrent quelque chose de rare : la possibilité de déployer en continu tout en pouvant revenir en arrière en quelques secondes. Ils ne tiennent cette promesse que lorsque chacun possède un type, un responsable, un test pour les deux chemins, une piste d’audit et une date de fin. Traitez le système de feature flags comme une infrastructure de production, conservez des interrupteurs d’arrêt pour les situations qui le justifient et supprimez tout le reste selon le calendrier prévu.

Commencez modestement. Choisissez une fonctionnalité prévue prochainement, désignez un responsable, rédigez d’abord le ticket de suppression, puis faites-la passer par l’intégralité de son cycle de vie. Ce que votre équipe apprendra grâce à ce feature flag façonnera toutes les politiques qui suivront.

FAQ

Quelle est la différence entre les feature flags et les feature toggles ?

Aucune différence significative. Les deux termes sont utilisés indifféremment, et l’article bien connu de Martin Fowler emploie les deux. Certaines équipes réservent le terme « toggle » aux simples commutateurs marche/arrêt et « flag » à ceux qui appliquent des règles de ciblage, mais il s’agit d’une convention interne plutôt que d’une norme.

Les feature flags sont-ils identiques à la configuration ?

Non. La configuration est généralement durable et chargée au démarrage, tandis que les flags sont dynamiques, temporaires et modifiés à l’exécution. Les garder séparés évite que des paramètres sensibles ne se retrouvent dans un outil conçu pour des modifications fréquentes et faciles à effectuer.

Quels sont les inconvénients des feature flags ?

Les principaux sont les flags obsolètes qui deviennent une dette technique, les chemins de code supplémentaires qui multiplient les efforts de test et la dépendance au service de feature flags. La sécurité constitue une préoccupation supplémentaire si les flags protègent des contrôles d’accès. Des responsables, des dates d’expiration, des valeurs par défaut sûres et une évaluation côté serveur répondent à la plupart de ces problèmes.

Quand un kill switch doit-il rester en place de façon permanente ?

Conservez-le lorsqu’il protège contre un risque opérationnel récurrent, comme une dépendance tierce peu fiable ou une fonctionnalité coûteuse sous une charge de pointe. Documentez-le, testez-le régulièrement et désignez-lui un responsable, comme pour tout autre contrôle durable.

Sources

• Feature flags - .NET | Microsoft Learn
• Concepts fondamentaux des feature flags | Atlassian
• Que sont les feature flags ? | Documentation de Confidence
• Feature Toggles (également appelés Feature Flags) | Martin Fowler
• Comprendre la gestion des fonctionnalités avec Azure App Configuration | Microsoft Learn
• Expérimentation progressive avec des feature flags | Microsoft Learn
• 11 bonnes pratiques pour créer et faire évoluer des systèmes de feature flags | Unleash
• À propos de la suppression des Feature Toggles (2021)
• Feature Toggles | Modèle de qualité arc42
• Bonnes pratiques pour gérer les flags | Harness
• Bonnes pratiques pour une gestion efficace des feature flags | Harness
• Contournement de la sécurité des feature flags | Guide de test de la sécurité des applications web de l’OWASP
• Stratégies de déploiement et de mise en production | LaunchDarkly
• Fonctionnement des feature flags | LaunchDarkly
• Mettre en œuvre des techniques de mise en production progressive des fonctionnalités | AWS Well-Architected
• Comment nous livrons du code plus rapidement et plus sûrement grâce aux feature flags | GitHub
• Quand les feature flags posent problème | InfoQ
• Panne d’un service de feature flags | PostHog
• Pannes récurrentes liées aux feature flags | PostHog
• Tarification | ConfigCat

Recommandé

• Gestion des mises en production : comment les équipes d’ingénierie déploient les changements en toute sécurité
• Optimisez vos pratiques DevOps grâce aux conseils d’experts et à des outils adaptés