Un feature flag active ou désactive une fonction selon une règle connue, afin de séparer la mise en production du moment où les utilisateurs la découvrent.
Un déploiement progressif peut réduire l’exposition d’une modification. L’équipe installe le code, vérifie son fonctionnement avec un groupe limité, puis élargit l’accès. Le flag ajoute cependant une règle d’exécution qui doit être sécurisée, testée et retirée quand elle ne sert plus.
Commencez par écrire la décision que le flag contrôle. Une fonction peut être réservée aux utilisateurs internes, à une entreprise pilote ou à une version de compte. La règle doit avoir un propriétaire, une date de revue et une procédure de désactivation.
Choisir le bon périmètre
Un flag global est simple, mais une erreur peut toucher tous les utilisateurs. Un flag par entreprise facilite une activation progressive, à condition de conserver l’identifiant de l’espace dans la règle. Un flag par utilisateur est utile pour un test ciblé, mais il peut rendre le diagnostic plus difficile.
Le système doit produire la même décision pendant une session lorsque le parcours l’exige. Si une page utilise l’ancienne fonction et l’écran suivant la nouvelle sans explication, l’utilisateur peut perdre son contexte. Documentez la durée et le moment où la décision est évaluée.
Les règles doivent rester hors du contrôle de l’utilisateur si la fonction influence la sécurité, la facturation ou les autorisations. Une préférence d’interface n’a pas le même niveau de risque qu’une fonction qui modifie des données.
Prévoir le schéma et les données
Un flag ne protège pas automatiquement une migration. Si la nouvelle fonction exige une colonne ou un format différent, déployez une structure compatible avec l’ancien code avant l’activation. Le retour arrière d’un déploiement doit inclure les données créées par la nouvelle version.
Une écriture produite par le nouveau parcours peut être illisible par l’ancien code. Utilisez une période de compatibilité ou gardez l’activation désactivée jusqu’à ce que toutes les instances puissent lire le format. Les traitements différés et les applications mobiles compliquent souvent cette coexistence.
Une fonction désactivée peut avoir laissé des enregistrements. Décidez s’ils restent valides, s’ils doivent être migrés ou s’ils doivent être supprimés. Le flag ne doit pas devenir un moyen d’oublier des données abandonnées.
Tester chaque état
Testez le flag désactivé, activé, mal configuré et indisponible. Une valeur par défaut sûre doit exister lorsque le service de configuration ne répond pas. Le choix dépend de l’opération : un écran de présentation peut rester indisponible, alors qu’un contrôle de sécurité doit conserver sa protection.
Les tests de recette doivent couvrir la règle d’éligibilité, les droits, les erreurs et le changement d’état pendant une session. Vérifiez aussi les caches. Une décision mise en cache trop longtemps peut maintenir une ancienne fonction après une désactivation d’urgence.
Les tests automatisés peuvent lire une configuration fixe pour rester déterministes. Ajoutez ensuite quelques tests d’intégration avec le vrai mécanisme de décision. Une suite qui teste seulement l’état activé donne une fausse impression de couverture.
Surveiller l’activation
Suivez les erreurs, les temps de réponse et les résultats métier pour chaque état. Un écart entre les groupes peut venir du code, des données ou du parcours d’activation. Les logs doivent indiquer la version de l’application et la décision du flag sans exposer les informations personnelles.
Une activation progressive doit avoir un seuil et une action. Si le taux d’erreur dépasse le seuil, désactivez, réduisez le groupe ou revenez au parcours précédent. Le seuil doit être défini avant le lancement pour éviter une décision improvisée sous pression.
Les utilisateurs pilotes doivent savoir ce qui change et comment signaler un problème. Ne collectez que les informations nécessaires au diagnostic. Un parcours de feedback simple aide à distinguer un défaut de la fonction d’une demande d’évolution.
Retirer les flags anciens
Un flag permanent crée deux chemins de code et multiplie les cas à tester. Après l’activation complète, supprimez la branche inutile, la configuration, la documentation et les tests spécifiques. Planifiez cette suppression dans le même travail ou dans une tâche attribuée à une personne.
Avant de retirer un flag, recherchez les appels côté serveur, interface, scripts et traitements différés. Vérifiez les anciennes versions qui peuvent encore être utilisées. Une application mobile non mise à jour peut conserver une branche plusieurs semaines.
Le dossier de transfert de maintenance doit indiquer les flags encore actifs, leur propriétaire et leur date de revue. Cette information évite qu’une équipe découvre une règle cachée lors d’un incident.
Éviter l’usage comme permission
Un feature flag contrôle une disponibilité, pas un droit. Les autorisations doivent rester vérifiées par le système de sécurité et par le serveur. Un utilisateur qui connaît l’URL ou modifie un paramètre ne doit pas accéder à une fonction réservée.
Dans un environnement multi entreprise, testez que le flag ne permet pas de traverser une frontière de données. Une entreprise pilote peut activer une fonction, mais elle ne doit pas voir les ressources d’une autre entreprise. Les règles d’isolation SaaS restent applicables.
Un feature flag est utile lorsque la décision d’activation est explicite, mesurée et réversible. Sa valeur diminue quand il reste sans propriétaire ou quand il remplace une règle d’accès. L’équipe doit donc traiter sa configuration comme du code qui a un cycle de vie.
Sources : Martin Fowler, techniques de déploiement, Microsoft, déploiement progressif.