Feature Flag : fonctionnement, types de flags et principes de gestion
Feature Flag est une technique de développement où la fonctionnalité d'une application est activée ou désactivée via des commutateurs conditionnels à l'exécution, sans déployer de nouveau code. Au lieu de l'approche traditionnelle « commit — déployer », les feature flags permettent de séparer le moment du déploiement du moment de l'activation de la fonctionnalité. Selon LaunchDarkly (2024), les équipes utilisant des feature flags réduisent le temps de déploiement des nouvelles fonctionnalités de 40 %. Les Feature flags sont devenus un élément essentiel de l'CI/CD pour les applications mobiles et web modernes.
Points clés
- Feature Flag — un commutateur conditionnel qui contrôle la disponibilité des fonctionnalités à l'exécution
- Quatre types de flags : release, experiment, ops et permission toggles avec différents objectifs et cycles de vie
- Gestion des flags nécessite un système de stockage, une UI de configuration et un suivi d'utilisation
- Plateformes LaunchDarkly, Unleash et Split fournissent des SDK pour tous les langages et plateformes populaires
- Dette technique des flags non supprimés — le risque principal : les flags obsolètes nécessitent un audit et une suppression réguliers
Qu'est-ce qu'un Feature Flag
Feature Flag (feature toggle) est un mécanisme qui permet de modifier le comportement d'une application sans modifier le code. Dans sa forme la plus simple, il s'agit d'une construction conditionnelle qui vérifie la valeur du flag avant d'exécuter une nouvelle fonctionnalité. Le flag peut être stocké dans un fichier de configuration, une base de données ou un service externe et modifié en temps réel. Cette approche donne aux équipes la possibilité de commiter du code inachevé dans la branche principale sans craindre qu'il n'atteigne les utilisateurs avant la fin du développement.
Définition et objectif
L'objectif principal des feature flags est de séparer le déploiement de la mise en production. Le déploiement est le processus de placement du code sur un serveur ou dans un magasin d'applications. La mise en production est le moment où la fonctionnalité devient disponible pour l'utilisateur. Sans feature flags, ces événements coïncident : le code va en production — les utilisateurs le voient. Avec les feature flags, le code peut être déployé en production des semaines avant la mise en production, activé pour des tests internes ou déployé progressivement auprès du public. Ceci est essentiel pour le trunk-based development et la livraison continue.
Exemple de flag simple
Considérez une implémentation de base d'un feature flag dans une application mobile Kotlin. Le flag est stocké dans Firebase Remote Config et chargé au démarrage de l'application. Selon la valeur du flag, l'écran de profil ancien ou nouveau est affiché. Cette implémentation permet de publier une nouvelle version du profil sans publier de mise à jour dans l'App Store — il suffit de modifier la valeur dans la console Firebase.
kotlin
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}Types de Feature Flags
Tous les feature flags ne sont pas identiques. La classification de Martin Fowler identifie quatre types de flags, qui diffèrent par leur objectif d'utilisation, leur durée de vie et leurs exigences de gestion. Une classification appropriée des flags aide à choisir l'infrastructure adaptée et à éviter les problèmes courants.
Release Toggles
Les Release toggles sont le type de flags le plus courant. Ils sont utilisés pour masquer les fonctionnalités inachevées en production. Le développeur commite du code enveloppé dans un flag dans la branche principale et termine progressivement la fonctionnalité. Après achèvement et tests, le flag est activé pour tous les utilisateurs. Le cycle de vie d'un tel flag varie de quelques jours à deux semaines. Après le déploiement complet, le flag est supprimé du code. Les Release toggles sont la base du trunk-based development.
Experiment et Ops Toggles
Les Experiment toggles fonctionnent en conjonction avec les tests A/B. Ils n'activent ou ne désactivent pas simplement une fonctionnalité, mais dirigent l'utilisateur vers l'un des groupes expérimentaux. Ces flags prennent souvent en charge des règles de ciblage complexes (par région, version d'OS, abonnement) et l'intégration avec des systèmes d'analyse. Les Ops toggles sont utilisés pour le contrôle opérationnel — par exemple, désactiver une fonction lourde sous forte charge ou éteindre temporairement un module problématique sans déploiement immédiat. Les Ops toggles doivent être aussi rapides et fiables que possible, car la stabilité du service en dépend.
| Type | Durée | Dynamique | Objectif |
|---|---|---|---|
| Release | Jours-semaines | Statique | Masquer le code inachevé |
| Experiment | Jours-mois | Dynamique | Tests A/B et déploiement |
| Ops | Heures-jours | Dynamique | Contrôle opérationnel |
| Permission | Mois+ | Statique | Contrôle d'accès |
Gestion des Feature Flags
La gestion des feature flags est une discipline distincte qui inclut le stockage, la configuration, la surveillance et l'audit des flags. Sans système de gestion, les flags se transforment en une dette technique incontrôlable qui ralentit le développement. Examinons les aspects clés de la gestion en prenant l'exemple d'un système de production.
Cycle de vie du flag
Chaque feature flag passe par quatre étapes : création, utilisation, stabilisation et suppression. Lors de la création, la clé du flag, le type et la valeur par défaut sont définis. Pendant l'utilisation, l'équipe surveille qui a activé le flag, pour quel public et dans quel but. Après la stabilisation (la fonctionnalité est complètement prête et testée), le flag doit être supprimé du code. Le processus de suppression est automatisé via la révision de code : le CI vérifie que tous les flags activés à 100 % pour les utilisateurs ont une tâche de suppression.
Stockage centralisé
Les feature flags doivent être stockés de manière centralisée, et non dispersés dans les fichiers de configuration de chaque service. Idéalement — un service dédié avec UI (LaunchDarkly, Unleash). Une option minimalement acceptable est un fichier JSON de configuration dans le référentiel avec révision de code pour les modifications. Une base de données pour stocker les flags est moins préférable car elle nécessite une interface de gestion séparée. Chaque flag doit avoir un propriétaire (équipe ou développeur spécifique), une description et une durée de vie (TTL). L'audit régulier des flags obsolètes est une pratique obligatoire, automatisée via une tâche CI qui vérifie les flags inchangés depuis plus de N jours.
Outils pour Feature Flags
Le marché des outils de gestion des feature flags comprend à la fois des plateformes commerciales avec un cycle de gestion complet et des solutions open-source pour l'auto-déploiement. Le choix de l'outil dépend de la taille de l'équipe, des exigences de latence et de la conformité.
Plateformes commerciales
LaunchDarkly est le leader du marché avec des SDK pour tous les langages et plateformes populaires (iOS, Android, Web, Backend). Il prend en charge le multi-environnement, le ciblage basé sur des règles, les expériences A/B et la suppression automatique des flags. Split est une alternative axée sur les fonctionnalités d'entreprise : accès basé sur les rôles, journaux d'audit et conformité (SOC2, HIPAA). ConfigCat est une solution plus légère et abordable adaptée aux petites équipes. Toutes les plateformes fournissent des SDK avec mise en cache des valeurs et un impact minimal sur la latence de l'application.
Solutions open-source
Unleash est la solution open-source la plus populaire avec une UI, une API et des SDK pour toutes les plateformes principales. Il prend en charge les stratégies d'activation, les contextes personnalisés et l'intégration avec Prometheus pour la surveillance. Flagsmith est une alternative avec des tests A/B intégrés et une gestion des environnements. Les solutions open-source nécessitent le déploiement et la maintenance de l'infrastructure, mais offrent un contrôle total sur les données et n'ont pas de restrictions de licence. Pour les applications mobiles, les deux solutions fournissent des SDK natifs avec mise en cache hors ligne des valeurs des flags.
Bonnes pratiques
Les feature flags sont un outil puissant, mais sans discipline, ils créent une dette technique et compliquent le code. Martin Fowler et les ingénieurs de LaunchDarkly ont formulé un ensemble de pratiques qui aident à tirer le meilleur parti des feature flags sans conséquences négatives. Passons en revue les principales recommandations pour les systèmes de production.
Éviter la dette technique
Chaque feature flag qui n'a pas été supprimé après la fin du déploiement devient une dette technique. Une étude de LaunchDarkly (2024) a montré qu'en moyenne 30 à 40 % des flags restent dans le code après avoir cessé d'être nécessaires. Solution : mettre en œuvre la règle « un flag — une tâche ». Lors de la création d'un flag, une tâche de suppression avec une date limite est créée dans le suivi des tâches. Le CI vérifie qu'aucun flag activé à 100 % n'existe depuis plus de 30 jours. La révision de code doit vérifier non seulement l'ajout mais aussi la suppression des flags.
Tests avec des flags
Les feature flags créent une complexité combinatoire pour les tests : chaque flag double le nombre d'états possibles de l'application. Pour gérer cette complexité, des tests matriciels qui vérifient toutes les combinaisons de flags et des tests d'intégration de basculement de flags sont utilisés. Une étape est ajoutée au pipeline CI qui exécute des tests avec différentes combinaisons de valeurs de flags. Pour les flags critiques (ops toggles), des tests de charge sont obligatoires pour vérifier que le basculement du flag ne provoque pas de pics de latence ou d'erreurs.
python
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)Questions fréquentes
Quelle est la différence entre un feature flag et un feature toggle ?
Les termes sont souvent utilisés comme synonymes, mais il y a une nuance : feature flag désigne généralement un système plus mature avec une gestion centralisée, une UI et des SDK, tandis que feature toggle est un simple commutateur binaire dans le code. Martin Fowler utilise feature toggle comme terme général, mais dans l'industrie, feature flag est plus souvent associé aux plateformes commerciales (LaunchDarkly, Split).
Comment les feature flags affectent-ils les performances ?
L'impact sur les performances est minime avec une implémentation correcte. Bonnes pratiques : mettre en cache les valeurs des flags en mémoire avec un TTL de 30 à 60 secondes, éviter les appels HTTP synchrones lors de la vérification d'un flag, utiliser des SDK avec cache local et synchronisation en arrière-plan. Selon LaunchDarkly, la latence p99 de leur SDK est inférieure à 5 ms, ce qui est négligeable pour la plupart des applications.
Quand ne pas utiliser les feature flags ?
Les feature flags ne sont pas recommandés pour modifier la logique métier dans les opérations financières critiques où il est important de savoir exactement quel code est exécuté. Évitez également les flags pour les fonctions de sécurité (autorisation, chiffrement) — la désactivation d'un tel flag crée une vulnérabilité. Pour les changements d'infrastructure (migration de base de données, migration vers une nouvelle architecture), les feature flags sont utiles mais nécessitent des tests particulièrement approfondis.
Comment tester du code avec des feature flags ?
L'approche principale est le test matriciel : exécuter des tests avec toutes les combinaisons de flags. Pour l'CI/CD, cela peut être trop coûteux (2^n combinaisons), donc en pratique, tous les flags sont testés individuellement dans les deux états (activé/désactivé), et seules les combinaisons critiques sont testées. Les tests unitaires doivent simuler la valeur du flag. Les tests d'intégration vérifient des scénarios spécifiques avec des valeurs de flags connues. Les tests E2E couvrent les combinaisons les plus probables.
Comment supprimer les anciens feature flags ?
Le processus de suppression : 1) assurez-vous que le flag est activé à 100 % pour tous les utilisateurs et n'est pas utilisé en mode expérience ; 2) supprimez toutes les vérifications conditionnelles du flag du code, en ne conservant que la branche « nouvelle » ; 3) supprimez la définition du flag du système de gestion ; 4) mettez à jour les tests en supprimant les mocks pour le flag supprimé. Il est recommandé d'automatiser ce processus via CI : les flags inchangés depuis plus de N jours sont marqués comme obsolètes et nécessitent une confirmation de suppression.
Résumé
- Feature Flag — un commutateur conditionnel qui sépare le moment du déploiement du moment de la mise en production de la fonctionnalité
- Quatre types de flags (release, experiment, ops, permission) ont des objectifs, des durées de vie et des exigences différents
- Gestion des flags nécessite un stockage centralisé, une UI de configuration et un audit régulier des flags obsolètes
- Outils : LaunchDarkly et Split pour les entreprises, Unleash et Flagsmith pour les projets open-source
- Dette technique des flags non supprimés est le risque principal ; les tâches de suppression sont obligatoires lors de la création de chaque flag
- Tests avec des flags nécessitent une approche matricielle et la simulation des valeurs des flags dans les tests unitaires
- Performance est minimalement affectée lors de l'utilisation du cache et des SDK locaux
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi