Une feature flag permet d’activer ou de désactiver un comportement sans republier tout le code. Elle réduit certains risques, mais ajoute une configuration qui doit avoir un propriétaire, une durée de vie et un test.
Définir le rôle du flag
Indiquez si le flag sert à tester, à déployer progressivement, à désactiver une fonction en urgence ou à gérer un plan commercial. Le type détermine les personnes autorisées et la date de suppression. Un flag permanent devient une branche cachée difficile à comprendre.
Nommez le flag selon le comportement et documentez sa valeur par défaut. Les conditions doivent rester lisibles dans le code. Évitez plusieurs flags imbriqués dans un même parcours critique quand une configuration plus simple suffit.
Préparer les valeurs de secours
Chaque état doit avoir un comportement testé. Si le service de configuration est indisponible, choisissez une valeur par défaut sûre et documentez-la. Un changement de flag ne doit pas exposer une opération à moitié terminée ou créer deux formats de données incompatibles.
Les flags liés à une migration de base doivent suivre une période de compatibilité. Notre article sur la migration sans interruption explique cette séparation.
Activer par étapes
Commencez avec un environnement de test puis une petite part du trafic ou un groupe interne. Comparez erreurs, latence et parcours métier. Définissez une condition de pause avant l’activation suivante.
Un groupe doit être stable pendant la mesure. Si les utilisateurs changent à chaque requête, les résultats sont difficiles à interpréter. Respectez aussi les règles de confidentialité lorsque le ciblage repose sur un attribut utilisateur.
Contrôler les accès et les changements
Les changements de flag doivent être authentifiés et journalisés. Séparez les personnes qui peuvent modifier une valeur de celles qui peuvent déployer le code. Une activation urgente doit afficher l’auteur, l’heure, la raison et la valeur précédente.
Surveillez l’utilisation du flag. Si une configuration est rarement lue ou si le code ancien n’est plus nécessaire, planifiez sa suppression. Le pipeline peut refuser une date dépassée pour éviter les flags oubliés.
Prévoir le retour
Une désactivation permet de réduire l’exposition, mais elle ne répare pas une donnée déjà modifiée. Documentez les opérations qui demandent une correction séparée. Testez la combinaison entre retour de code, retour de flag et version du schéma.
Le déploiement blue green présente une autre façon de limiter une bascule complète. Sources : Martin Fowler, feature toggles, LaunchDarkly, feature flag best practices.