Feature Toggle — bases, types d'interrupteurs et application
Feature Toggle est un mécanisme d'exécution permettant d'activer et de désactiver des fonctionnalités de l'application, permettant aux développeurs de gérer la disponibilité des fonctions sans modifier le code ni redéployer. Contrairement à la compilation conditionnelle (ifdef), le toggle fonctionne au niveau de l'exécution et peut être modifié dynamiquement. Selon Martin Fowler (2024), les feature toggles sont un élément clé du trunk-based development et de la livraison continue. Feature toggle donne aux équipes de la flexibilité dans la gestion des versions et des expériences.
Points clés
- Feature Toggle — un interrupteur dynamique qui contrôle le comportement de l'application via la configuration
- Types principaux : business toggles, release toggles, experiment toggles et infrastructure toggles
- Feature Toggle vs Flag — toggle fait généralement référence à de simples interrupteurs binaires, flag — à des plateformes complètes
- Intégration CI/CD permet de vérifier et tester automatiquement les toggles à chaque étape du pipeline
- Problème principal — accumulation de stale toggles, qui doivent être audités et supprimés régulièrement
Qu'est-ce qu'un Feature Toggle
Feature Toggle est une technique où le code d'une nouvelle fonctionnalité est encapsulé dans une construction conditionnelle qui vérifie la valeur d'un paramètre de configuration. Si le paramètre est vrai — la nouvelle fonctionnalité est active, s'il est faux — l'ancien code s'exécute. La principale différence avec un feature flag est qu'un toggle est un interrupteur binaire fonctionnant sur le principe marche/arrêt, sans règles de ciblage complexes ni distribution de trafic.
Définition et principe de fonctionnement
Un feature toggle est implémenté comme une simple construction if autour d'une nouvelle fonctionnalité. La valeur du toggle est stockée dans la configuration de l'application — variables d'environnement, fichier JSON ou base de données. Au démarrage, l'application charge la configuration et l'utilise pour prendre des décisions sur la visibilité des fonctionnalités. Dans le cas le plus simple, modifier la valeur d'un toggle nécessite de redémarrer l'application, mais dans les systèmes de production, les toggles prennent généralement en charge le rechargement à chaud via un serveur de configuration externe ou une API.
Exemple de toggle simple
Regardons une implémentation de feature toggle en JavaScript (Node.js). Le toggle est stocké dans un fichier JSON de configuration et chargé au démarrage du serveur. Le middleware vérifie la valeur du toggle avant d'acheminer la requête vers le nouveau ou l'ancien gestionnaire. Cette implémentation permet d'ajouter de nouvelles fonctionnalités à la branche principale du code sans casser la version actuelle de l'API.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Types de Feature Toggles
Pete Hodgson de ThoughtWorks identifie trois types principaux de feature toggles, les classifiant par durée de vie et objectif d'utilisation. Identifier correctement le type de toggle aide à choisir le mécanisme de stockage et le processus de gestion appropriés. Regardons chaque type dans le contexte du développement mobile.
Business et Release Toggles
Les Business toggles sont les interrupteurs les plus durables. Ils gèrent des règles métier disponibles uniquement pour certaines catégories d'utilisateurs (fonctionnalités premium, particularités régionales). Ces toggles peuvent vivre pendant des années et ont généralement une logique plus complexe qu'un simple marche/arrêt binaire. Les Release toggles sont des interrupteurs temporaires pour masquer des fonctionnalités incomplètes. Leur cycle de vie va de quelques jours à quelques semaines. Une fois la fonctionnalité terminée, le release toggle est supprimé du code. Ces toggles sont le fondement du trunk-based development, permettant aux développeurs de commiter sur la branche principale sans attendre que toutes les fonctionnalités soient terminées.
Experiment et Infrastructure Toggles
Les Experiment toggles sont utilisés pour les tests A/B et le déploiement progressif. Contrairement aux release toggles, les experiment toggles prennent en charge la répartition en pourcentage des utilisateurs et l'intégration avec les systèmes d'analyse. Ils peuvent vivre plus longtemps que les release toggles (jusqu'à plusieurs mois), mais doivent également être supprimés après la fin de l'expérience. Les Infrastructure toggles sont des interrupteurs pour gérer les changements d'infrastructure : migration de base de données, changement de fournisseur d'API, modification des algorithmes de cache. Ces toggles nécessitent une attention particulière aux tests, car leur activation affecte la stabilité de l'ensemble du service.
| Type de toggle | Durée | Public | Exemple |
|---|---|---|---|
| Business | Mois-années | Par rôles/régions | Fonctionnalités premium |
| Release | Jours-semaines | Développeurs/QA | Écran incomplet |
| Experiment | Semaines-mois | % d'utilisateurs | Test A/B d'interface |
| Infrastructure | Jours-semaines | Interne | Migration BD |
Feature Toggle vs Feature Flag
Bien que les termes « feature toggle » et « feature flag » soient souvent utilisés de manière interchangeable, il existe des différences conceptuelles entre eux. Comprendre ces différences aide à choisir le bon outil pour une tâche spécifique et à éviter la confusion dans l'équipe. Regardons les principales différences et cas d'utilisation de chaque approche.
Différences d'approche
Feature toggle est avant tout un mécanisme technique : un interrupteur binaire intégré dans le code de l'application. Le toggle est géré via la configuration et ne nécessite pas d'infrastructure externe. Feature flag est un concept plus large qui inclut une plateforme de gestion : interface utilisateur pour la configuration, SDK pour l'intégration, surveillance d'utilisation, analyses et audit. Les flags prennent en charge des règles de ciblage complexes (par région, version, appareil), des expériences A/B et la suppression automatique. On peut dire que le feature flag est l'évolution du feature toggle : les équipes commencent avec de simples interrupteurs de configuration et passent à une plateforme spécialisée à mesure qu'elles grandissent.
Quand un toggle suffit
Pour les petites équipes et les projets avec un service unique ou un monolithe, de simples toggles de configuration sont parfaitement suffisants. Si vous avez 5–10 développeurs et 1–2 toggles actifs à la fois, une plateforme externe serait excessive. Les plateformes de feature flags (LaunchDarkly, Unleash) deviennent nécessaires lorsque le nombre de flags actifs dépasse 20–30, que l'équipe compte 20+ développeurs, ou qu'un contrôle d'accès fin pour différents segments d'utilisateurs est requis. Pour les applications mobiles, où les mises à jour client prennent des jours, les plateformes de feature flags offrent un avantage supplémentaire — la possibilité de modifier le comportement de l'application sans publier une nouvelle version.
Outils de gestion
Le choix d'un outil de gestion des feature toggles dépend de la taille de l'équipe, de la pile technologique et des exigences de sécurité. Regardons les options, des simples fichiers de configuration aux plateformes de gestion d'entreprise, y compris les alternatives open-source.
Intégration dans CI/CD
Les feature toggles doivent être des citoyens de première classe du pipeline CI/CD. À l'étape de construction, le pipeline vérifie que tous les release toggles prévus pour suppression dans le sprint actuel sont effectivement supprimés du code. À l'étape de test, des tests matriciels sont exécutés avec différentes combinaisons de toggles. À l'étape de déploiement, le système synchronise automatiquement la configuration des toggles avec l'environnement de production. L'intégration avec PagerDuty ou Opsgenie permet de créer des alertes lorsque des stale toggles sont détectés ou lorsque le nombre autorisé de toggles actifs est dépassé.
Solutions populaires
Pour les scénarios simples, un fichier JSON de configuration dans Git avec révision de code sur les modifications est suffisant. Une option plus avancée est Togglz (Java) ou Gofeature (Go) — des bibliothèques qui ajoutent une interface utilisateur minimale pour la gestion des toggles. Pour les systèmes de production, Unleash (open-source) avec des SDK pour tous les langages et le support de stratégies d'activation est recommandé, ou Flagsmith avec des tests A/B intégrés. LaunchDarkly reste la norme pour les projets d'entreprise avec des exigences élevées d'audit et de conformité. Pour les applications mobiles, toutes les solutions fournissent des SDK natifs avec mise en cache et mode hors ligne.
Dette technique et suppression
Les feature toggles sont une arme à double tranchant. Sans discipline de gestion, ils se transforment en dette technique qui ralentit le développement et augmente la complexité du code. Selon une étude de CodeScene (2024), 35–50% des bases de code contiennent des stale toggles — des interrupteurs qui restent dans le code après la fin du déploiement. Regardons les stratégies pour prévenir et éliminer cette dette.
Suppression des toggles
Le processus de suppression d'un feature toggle comprend quatre étapes. Premièrement : s'assurer que le toggle est activé pour 100% de l'audience ou désactivé pour 0% (selon la branche de code qui doit rester). Deuxièmement : supprimer toutes les vérifications conditionnelles du toggle du code, en ne laissant que la branche qui doit être le comportement de production. Troisièmement : supprimer la définition du toggle du système de stockage (configuration, base de données ou plateforme). Quatrièmement : exécuter des tests pour confirmer que la suppression n'a pas cassé la fonctionnalité. Chaque toggle doit avoir un propriétaire et une date de suppression planifiée, enregistrés lors de la création de l'interrupteur.
Automatisation de l'audit
L'audit manuel des toggles est inefficace à des échelles dépassant 50 interrupteurs. L'automatisation repose sur trois principes : vérification CI (les stale toggles bloquent le merge), surveillance (un tableau de bord montrant l'âge et le statut de chaque toggle), alertes (notifier le propriétaire si un toggle n'a pas été modifié depuis N jours). Les outils d'analyse statique de code (SonarQube, plugin ESLint) peuvent détecter les toggles qui sont toujours activés ou toujours désactivés dans le code — un signe clair de stale toggle. La vérification finale est la revue de code, où le réviseur doit s'assurer que le nouveau toggle est réellement nécessaire et que l'ancienne branche de code sera supprimée.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Questions fréquentes
En quoi un feature toggle diffère-t-il d'un feature flag ?
Les termes sont souvent utilisés de manière interchangeable, mais techniquement feature toggle est un interrupteur binaire dans le code (une condition if vérifiant une valeur de configuration). Feature flag est un concept plus large qui inclut une plateforme de gestion avec interface utilisateur, SDK, analyses et règles de ciblage complexes. Un toggle ne nécessite pas d'infrastructure externe ; un flag en nécessite généralement.
À quelle fréquence les anciens toggles doivent-ils être supprimés ?
Les release toggles doivent être supprimés dans les 1–2 semaines suivant la fin du déploiement. Les experiment toggles — immédiatement après la fin du test A/B. Les business toggles nécessitent un audit régulier (trimestriel). Il est recommandé de configurer une vérification CI qui bloque le merge si une PR ajoute un nouveau toggle sans tâche de suppression dans le gestionnaire de tâches.
Peut-on utiliser des toggles pour les applications mobiles ?
Oui, les feature toggles sont activement utilisés dans le développement mobile. L'outil principal est Firebase Remote Config, qui permet de gérer dynamiquement les interrupteurs sans publier une nouvelle version de l'application. Alternatives : SDK LaunchDarkly pour iOS/Android, SDK Unleash, un serveur de toggle personnalisé avec API REST. Il est important d'implémenter la mise en cache des valeurs pour le mode hors ligne.
Comment tester du code avec des feature toggles ?
La méthode principale est le test matriciel : exécuter tous les tests avec le toggle activé et désactivé. Pour N toggles, le test matriciel complet nécessite 2^n exécutions, donc en pratique, des combinaisons critiques sont sélectionnées. Les tests unitaires doivent simuler la valeur du toggle. Les tests d'intégration vérifient des scénarios spécifiques. Une étape est ajoutée au CI qui exécute des tests avec une combinaison aléatoire de toggles pour détecter des interactions inattendues.
Quels sont les risques des feature toggles ?
Risques principaux : 1) stale toggles — le code avec les deux branches (activé/désactivé) devient complexe et difficile à maintenir ; 2) complexité combinatoire des tests — chaque toggle double le nombre d'états ; 3) code mort — l'ancienne branche reste dans le code après que le toggle a été définitivement activé ; 4) sécurité — les interrupteurs contrôlant l'accès créent des vulnérabilités en cas de mauvaise configuration. Tous les risques sont gérables avec de la discipline et de l'automatisation.
Résumé
- Feature Toggle — un interrupteur binaire de fonctionnalité contrôlé via la configuration de l'application
- Types principaux : business (mois-années), release (jours-semaines), experiment (semaines-mois), infrastructure (jours-semaines)
- Feature Toggle vs Flag — toggle est plus simple (condition if + configuration), flag inclut une plateforme de gestion complète
- Intégration CI/CD obligatoire : vérification des stale toggles, tests matriciels, synchronisation de la configuration
- Stale toggles — le risque principal : 35–50% des bases de code contiennent des interrupteurs inutilisés
- Suppression de toggle nécessite un processus : confirmer l'état, supprimer le code, supprimer la config, exécuter les tests
- Automatisation de l'audit via CI, tableaux de bord et analyse statique de code prévient l'accumulation de dette technique
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