Feature flags et déploiement progressif : livrer plus vite et réduire les risques en production
Obtenez un résumé intelligent et des insights personnalisés
Un feature flag est un interrupteur placé dans le code. Il active ou désactive une fonctionnalité sans nouveau déploiement. Le déploiement progressif expose une nouvelle version à une part croissante des utilisateurs. Ensemble, ces deux techniques séparent la mise en production de la mise à disposition aux utilisateurs.
Une mise en production « tout ou rien » expose 100 % des utilisateurs au moindre défaut. Le 1er août 2012, Knight Capital a perdu environ 440 millions de dollars après un problème d’installation logicielle. Alors, nous vous aidons à éviter ce scénario. Voyons ensemble trouverez les types de flags, les stratégies de déploiement, les outils et les règles d’hygiène. AquilApp vous applique ces pratiques pour aider ses clients à réussir le déploiement logiciel.
Qu’est-ce qu’un feature flag et pourquoi en utiliser ?
Un feature flag (ou feature toggle) est une condition dans le code qui décide si une fonctionnalité est visible. L’équipe change sa valeur depuis une console, sans redéployer.
Pourquoi l’utiliser ? Voici quatre raisons valables :
- Déployer sans exposer : le code part en production, mais reste désactivé.
- Couper en quelques secondes : le flag sert d’interrupteur d’urgence en cas d’incident.
- Tester sur un segment : vous activez la fonction pour vos collaborateurs, puis pour 5 % des clients.
- Fusionner plus souvent : les branches de code restent courtes, ce qui limite les conflits.
Ces pratiques accompagnent les équipes les plus performantes. Selon le rapport DORA (DevOps Research and Assessment) 2025 de Google Cloud, 16,2 % des équipes déploient à la demande, en continu.
Le sujet est encore plus sensible sur mobile. Les stores valident chaque version. Donc, vous ne pouvez pas annuler une mise à jour en quelques minutes. Par exemple, un flag distant, via Firebase Remote Config, désactive une fonctionnalité défaillante sans publier de nouvelle version.
Quels sont les types de feature flags ?
La classification de référence vient de Pete Hodgson. Elle distingue quatre types selon l’objectif et la durée de vie.
| Type | Usage | Durée de vie | Exemple |
|---|---|---|---|
| Release | Livrer du code inachevé, masqué | Jours à semaines | Nouveau tunnel de paiement caché |
| Experiment | Comparer deux variantes | Semaines | Deux versions d’un bouton |
| Ops | Couper une fonction sous forte charge | Courte à longue | Désactiver les recommandations lors d’un pic |
| Permission | Réserver une fonction à un segment | Longue | Option réservée aux abonnés premium |
Source : Pete Hodgson, « Feature Toggles (aka Feature Flags) », martinfowler.com, 2017.
Les flags de release sont temporaires. D’un autre côté, les flags ops et permission peuvent durer des années. Cette différence structure la gouvernance, détaillée plus bas.
Déploiement progressif : quelle différence entre canary, blue-green et rolling update ?
Un déploiement progressif remplace ou expose une nouvelle version par étapes. De quoi limiter le nombre d’utilisateurs touchés en cas de défaut. Trois stratégies dominent.
| Critère | Canary | Blue-green | Rolling update |
|---|---|---|---|
| Principe | Petit pourcentage du trafic vers la nouvelle version | Deux environnements identiques, bascule du trafic | Remplacement progressif des instances |
| Retour arrière | Rapide | Quasi instantané | Plus lent |
| Coût d’infrastructure | Faible à moyen | Élevé (environnement doublé) | Faible |
| Cas idéal | Valider sous trafic réel | Mise à jour critique | Mise à jour courante sur Kubernetes |
Sources : Google SRE Workbook, « Canarying Releases » (sre.google) ; Kubernetes, documentation « Deployments » (kubernetes.io) ; Martin Fowler, « BlueGreenDeployment » (martinfowler.com).
Nous recommandons le canary dans la majorité des projets. Le blue-green convient quand le retour arrière doit être immédiat, à condition d’accepter le surcoût.
Le flag et le canary ne jouent pas le même rôle. En effet, le flag agit sur une fonctionnalité. D’un autre côté, le canary agit sur une version déployée. Vous pouvez donc les combiner.
Sur mobile, les stores proposent déjà un déploiement par paliers. En effet :
- Apple offre une « phased release » sur 7 jours.
- Google Play propose des « staged rollouts » par pourcentage
Quels outils choisir pour votre feature flags : LaunchDarkly, Unleash, Flagsmith ou Statsig ?
Choisissez selon quatre critères : hébergement, open source, expérimentation intégrée et SDK (Software Development Kit) mobile.
| Outil | Modèle | Open source | A/B testing | SDK mobile |
|---|---|---|---|---|
| LaunchDarkly | SaaS | Non | Oui, intégré | Oui |
| Unleash | Auto-hébergé ou SaaS | Oui | Limité (variantes) | Oui |
| Flagsmith | Auto-hébergé ou SaaS | Oui | Via outils d’analyse tiers | Oui |
| Statsig | SaaS | Non | Oui, cœur de l’offre | Oui |
Source : documentations officielles des éditeurs, consultées en [date de rédaction]. Vérifiez les offres et les prix à cette date.
Le standard OpenFeature limite la dépendance à un éditeur. Ce projet propose une API neutre pour évaluer les flags. La CNCF (Cloud Native Computing Foundation) l’a accepté comme projet « incubating » en décembre 2023.
Notre avis : une PME choisit Unleash ou Flagsmith pour maîtriser ses coûts. Une ETI ou un grand compte qui veut de l’expérimentation intégrée choisit LaunchDarkly ou Statsig. Vérifiez aussi où vos données de ciblage sont hébergées, au regard du RGPD (Règlement général sur la protection des données). Notre article sur la sécurité à la mise en production détaille ce point.
Comment intégrer les feature flags dans votre pipeline CI/CD ?
La CI/CD (intégration et livraison continues) est la chaîne automatisée qui teste et déploie votre code. Les flags s’y intègrent en cinq étapes :
- Fusionnez le code sur la branche principale, flag désactivé.
- Déployez en production.
- Activez le flag pour l’équipe interne.
- Élargissez par paliers : 1 %, 10 %, 50 %, puis 100 %.
- Supprimez le flag une fois la fonction stabilisée.
Fixez des critères d’arrêt avant chaque palier : taux d’erreur, latence, taux de sessions sans plantage sur mobile. Un dépassement déclenche la désactivation. Cette discipline s’inscrit dans la méthode DevOps.
Quelles bonnes pratiques adopter pour votre feature flags : nommage, nettoyage et gouvernance ?
Un flag oublié devient une dette technique. Appliquez ces règles :
- Adoptez une convention de nommage (équipe, fonction, date).
- Attribuez un propriétaire et une date d’expiration à chaque flag.
- Supprimez les flags de release dès 100 % d’exposition.
- Testez les deux chemins : flag actif et flag inactif.
- Tracez qui modifie quoi dans un journal d’audit.
Le cas Knight Capital l’illustre. Selon l’ordonnance de la SEC (2013), un ancien code dormant a été réactivé par un flag réutilisé. Le déploiement incomplet a fait le reste.
Comment mesurer l’impact réel de votre feature flags avec l’A/B testing ?
Un test A/B compare deux variantes auprès de groupes d’utilisateurs distincts. De quoi vous permettre de mesurer laquelle produit le meilleur résultat. Le flag répartit le trafic entre les variantes.
Suivez quatre étapes :
- Formulez une hypothèse.
- Choisissez une seule métrique principale.
- Fixez une durée minimale avant de lancer.
- Définissez un seuil de significativité statistique.
Néanmoins, faites attention à deux erreurs : arrêter le test trop tôt et suivre trop de métriques. Mesurez aussi l’effet technique avec les indicateurs DORA, comme le taux d’échec des changements.
FAQ sur les feature flags
Conclusion
Les feature flags et le déploiement progressif réduisent le risque de chaque mise en production. Commencez petit : un flag de release et un canary sur une seule fonctionnalité. Étendez ensuite la pratique, avec des règles de nettoyage claires.
Pour cadrer l’ensemble, consultez notre guide de gestion de projet informatique. Pour être accompagné, contactez notre agence de développement logiciel à Nantes.
