Feature flags : livrer progressivement sans transformer le code en labyrinthe

Comparer les options avant d’ajouter un drapeau

Un feature flag n’est pas une réponse automatique à toute incertitude. Il faut le comparer aux autres façons de gérer une livraison progressive. La bonne décision dépend du type de changement, de sa durée probable et du niveau de contrôle attendu.

| Option | Quand l’utiliser | Risque principal | Signal de sortie | | --- | --- | --- | --- | | Branche courte | Changement isolé, livré rapidement, sans exposition partielle nécessaire | Accumuler les écarts avec la branche principale | Fusion réalisée et tests passés | | Paramètre de configuration | Comportement stable, piloté par environnement ou par installation | Confondre configuration durable et expérimentation temporaire | Valeur documentée comme réglage produit ou exploitation | | Feature flag | Activation progressive, test ciblé, bascule rapide ou validation par segment | Laisser des chemins morts et des conditions dispersées | Décision prise : généraliser, retirer ou remplacer | | Déploiement séparé | Composant indépendant, service activable sans condition dans le code appelant | Multiplier les intégrations et les états intermédiaires | Service exposé avec contrat stable |

Cette comparaison évite de faire du feature flag un réflexe. Si le comportement doit rester paramétrable dans le temps, il s’agit plutôt d’une configuration produit ou d’exploitation. Si le besoin est de masquer un développement pendant quelques jours, le flag peut être adapté, à condition de prévoir sa suppression dès sa création.

Nommer le flag comme une décision métier

Un mauvais nom oblige à relire le code pour comprendre ce qui est activé. Un bon nom explique la décision qu’il porte : activer un nouveau parcours de paiement, autoriser une synchronisation fournisseur, utiliser un calcul tarifaire révisé, ouvrir une interface à un groupe pilote.

La liste minimale à définir avant d’ajouter un flag tient en quelques points :

• un nom explicite, stable et compréhensible hors du code ;
• un propriétaire capable de décider de l’activation et du retrait ;
• un périmètre d’application : environnement, client, rôle, équipe, région ou pourcentage ;
• une durée prévue, même approximative ;
• un comportement par défaut en cas d’erreur de lecture du flag ;
• les métriques ou observations qui permettront de trancher.

Sans ces éléments, le flag devient une condition technique de plus. Avec eux, il devient un outil de pilotage visible par le développement, l’exploitation, le support et le projet.

Distinguer les familles de flags

Tous les flags ne demandent pas le même niveau de gouvernance. Un flag de lancement commercial, un flag de migration technique et un flag de contournement incident n’ont pas la même durée de vie. Les mélanger dans une même logique rend le système confus.

Les flags de livraison servent à cacher temporairement du code déjà déployé. Leur durée doit être courte. Les flags d’expérimentation permettent de comparer deux variantes ou d’exposer une fonction à un groupe limité. Les flags opérationnels servent à réduire une charge, couper une intégration ou changer un mode de fonctionnement sous contrôle. Les flags de permission, eux, ressemblent davantage à des règles d’accès et doivent rejoindre le modèle d’autorisation plutôt que rester dispersés dans le code applicatif.

Cette classification aide à fixer les exigences. Un flag opérationnel doit être observable et actionnable rapidement. Un flag de livraison doit surtout être retiré vite. Un flag de permission doit être audité comme une règle de sécurité.

Prévoir la chronologie de la bascule

Le moment dangereux n’est pas seulement l’activation. Il commence au premier commit et se termine quand le vieux chemin a disparu. Une chronologie simple permet de réduire les angles morts.

1. **Cadrage.** L’équipe décrit ce que le flag contrôle, qui peut le modifier et quelle décision mettra fin à son existence. 2. **Implémentation.** Le code limite la condition à un point lisible, avec un comportement par défaut explicite et des tests pour les deux chemins tant qu’ils coexistent. 3. **Déploiement fermé.** Le code arrive en production avec le flag désactivé ou limité à un périmètre interne. 4. **Activation ciblée.** Le périmètre s’élargit par étape : équipe pilote, client volontaire, segment métier ou faible pourcentage du trafic. 5. **Observation.** L’équipe regarde les erreurs, les performances, les retours support et les indicateurs fonctionnels prévus. 6. **Décision.** Le flag est généralisé, ajusté, désactivé ou abandonné. La décision doit être datée. 7. **Nettoyage.** Le code de l’ancien chemin, les tests associés et la configuration temporaire sont retirés.

La dernière étape est souvent celle qui disparaît du planning. Pourtant, c’est elle qui évite d’accumuler des branches invisibles dans le produit.

Limiter la dispersion dans le code

Un flag devient coûteux lorsqu’il apparaît dans vingt fichiers, avec des conditions légèrement différentes. L’objectif n’est pas seulement de basculer un comportement, mais de garder la lecture du système possible.

Pour une interface, le flag peut décider de l’accès à un écran ou à une action, mais le cœur du comportement doit rester testable. Pour une règle métier, il vaut mieux isoler l’ancien et le nouveau calcul derrière une fonction claire que parsemer des conditions dans chaque étape. Pour une intégration externe, le flag doit être proche du point d’appel ou du routeur de flux, pas caché dans des traitements secondaires.

Cette discipline rejoint les pratiques de documentation des choix techniques. Lorsqu’un flag matérialise un compromis durable ou risqué, il peut être utile de le relier à une courte note de décision, dans l’esprit des décisions d’architecture documentées.

Rendre l’activation visible en exploitation

Un flag modifie le comportement d’un service. L’exploitation doit donc pouvoir savoir quel état était actif au moment d’un incident. Sans cette visibilité, l’équipe perd du temps à comparer des environnements qui n’ont pas réellement le même comportement.

Les journaux applicatifs peuvent inclure l’état d’un flag important lorsqu’un événement métier ou une erreur dépend de ce choix. Il ne s’agit pas de tout tracer partout, mais de rendre l’enquête possible lorsqu’une activation progressive produit un signal inattendu. Cette approche complète une journalisation applicative utile au diagnostic.

La supervision peut également suivre quelques indicateurs simples : taux d’erreur sur le nouveau parcours, volume traité par l’ancien et le nouveau chemin, temps de réponse, annulations, retours support ou désactivations manuelles. Le flag devient alors un levier contrôlé, pas une option cachée.

Installer une checklist avant mise en production

Avant de livrer un changement sous feature flag, l’équipe peut passer une checklist courte. Elle doit être assez légère pour être utilisée, mais assez concrète pour éviter les oublis classiques.

• Le flag a un propriétaire identifié.
• Son objectif est compréhensible sans ouvrir le code.
• Le comportement par défaut est défini si le service de flags est indisponible.
• Les deux chemins sont testés tant qu’ils coexistent.
• Le support sait reconnaître les utilisateurs ou clients concernés.
• Les métriques nécessaires à la décision sont disponibles.
• La procédure de désactivation est connue.
• Une date de revue ou de suppression est inscrite dans le backlog.
• Le nettoyage du code est traité comme une tâche de livraison, pas comme une amélioration facultative.

Cette checklist évite de réduire le sujet à un interrupteur technique. Elle force à penser au cycle complet : décision, activation, observation, retour arrière et retrait.

Choisir un niveau d’outillage proportionné

Une petite équipe peut commencer avec une configuration centralisée et une convention stricte. Une organisation plus exposée aura besoin d’un outil qui gère les droits, l’historique des changements, les segments d’utilisateurs, les validations et les environnements. Le bon seuil dépend du nombre de flags actifs, du risque métier et du besoin d’audit.

Un signe de maturité n’est pas d’avoir beaucoup de flags. C’est de savoir lesquels existent, pourquoi ils existent, qui peut les changer et quand ils doivent disparaître. Si personne ne peut répondre rapidement, le système de flags est déjà devenu une dette opérationnelle.

Les feature flags sont utiles lorsqu’ils servent une livraison plus progressive et plus observable. Ils deviennent dangereux lorsqu’ils remplacent la décision. La règle la plus saine reste simple : chaque flag doit naître avec une raison, vivre avec un propriétaire et mourir avec une tâche de nettoyage.