Les feature flags permettent aux équipes de dissocier le déploiement de la mise en production. Le code peut atteindre la production avant que chaque utilisateur ne le voie, ce qui rend les mises en production plus petites, les déploiements plus sereins et la récupération plus rapide en cas de problème.
Le principe est simple : encapsuler un nouveau comportement derrière une décision à l’exécution, déployer le code en toute sécurité, puis l’activer pour le bon public lorsque l’équipe est prête.
Quand les flags sont les plus utiles
Les feature flags sont utiles lorsqu’un changement présente un risque métier, une incertitude technique ou un public échelonné. Les cas courants incluent :
- Lancer un parcours de paiement repensé pour un pour cent des utilisateurs
- Donner aux équipes internes un accès anticipé à un nouveau tableau de bord
- Masquer un travail inachevé tout en gardant la branche principale déployable
- Désactiver des intégrations coûteuses pendant un incident
- Comparer deux algorithmes en production avec du trafic réel
Les flags ne remplacent pas les tests. Ils constituent une surface de contrôle du comportement en production.
Une structure de flag minimale
Commencez par une interface simple. L’implémentation pourra évoluer plus tard.
if Feature.enabled?(:new_invoice_summary, user)
render NewInvoiceSummary.new(invoice)
else
render LegacyInvoiceSummary.new(invoice)
end
L’important est que le flag accepte un contexte. Une décision de flag dépend généralement de l’utilisateur, du compte, du forfait, de la région ou de l’environnement.
Étapes de déploiement
Traitez le déploiement comme un processus :
| Étape | Public | Objectif |
|---|---|---|
| Interne | Employés uniquement | Repérer les problèmes évidents |
| Bêta | Clients sélectionnés | Valider l’adéquation du workflow |
| Pourcentage | Petite portion de trafic | Surveiller les métriques sous charge |
| Général | Tout le monde | Finaliser le lancement |
Chaque étape doit avoir une condition de sortie. N’avancez pas parce que le calendrier le dit. Avancez parce que les métriques et les canaux de support sont calmes.
Éviter la dette de flags
Les flags sont temporaires par défaut. Chaque flag de longue durée ajoute une branche au comportement de votre système, et chaque branche doit être testée.
Ajoutez des champs de responsabilité et de nettoyage à vos enregistrements de flags :
- Responsable
- Date de création
- Date de suppression prévue
- Statut de déploiement
- Issue ou pull request liée
Examinez les anciens flags lors de la planification des sprints ou du nettoyage des versions. Si un flag est entièrement activé depuis des semaines, supprimez l’ancien chemin.
Récupération après incident
Le flag le plus précieux est souvent celui que personne ne remarque. Un interrupteur d’arrêt pour une dépendance risquée peut transformer un incident majeur en une simple fonctionnalité dégradée.
Les bons interrupteurs d’arrêt sont rapides, documentés et observables. L’équipe doit savoir qui peut les activer, ce que devient l’expérience utilisateur et quel tableau de bord confirme que le changement a fonctionné.
Rester compréhensible
Les feature flags fonctionnent mieux lorsqu’ils sont visibles pour l’ingénierie, le produit, le support et les opérations. Un flag nommé new_ui_v2_final ne dit à personne ce qu’il contrôle. Un flag nommé invoice_summary_redesign est plus facile à comprendre lors d’une réunion de mise en production.
Des noms courts, des responsables clairs et des durées de vie brèves permettent de garder cette pratique saine.
Comments