Interrupteurs de fonctionnalités : types, durée de vie et nettoyage

Ce que c'est

Un interrupteur de fonctionnalité (feature toggle, feature flag) est une condition dans le code dont la valeur provient d'une configuration à l'exécution, et non de la construction (« build »). L'article cité distingue quatre catégories selon leur durée de vie et leur dynamique : les interrupteurs de release masquent un travail inachevé dans la branche principale (courte durée de vie, statiques) ; les interrupteurs d'expérimentation répartissent les utilisateurs entre des variantes (de quelques heures à quelques semaines, décidés par requête) ; les interrupteurs d'exploitation (« ops ») limitent ou désactivent des fonctionnalités sous charge (activés manuellement, le plus souvent de courte durée, quelques-uns servant d'interrupteurs d'urgence permanents) ; les interrupteurs de permission (« permissioning toggles ») ouvrent des fonctionnalités à certains groupes d'utilisateurs (permanents, par utilisateur). L'article recommande de regrouper la décision dans un « routeur d'interrupteurs » (« toggle router ») plutôt que de disséminer des if flag dans tout le code.

Pourquoi c'est important

Les interrupteurs permettent le développement en tronc commun (« trunk-based development »), un déploiement progressif et un retour en arrière rapide sans nouveau déploiement. Mais ils multiplient les états dans lesquels le système peut se trouver : avec dix interrupteurs indépendants, cela fait 1024 combinaisons, dont les tests n'en couvrent que quelques-unes. Les interrupteurs de release oubliés deviennent des branches permanentes que plus personne ne comprend.

Comment l'appliquer

• Pour chaque interrupteur, consigner à sa création : catégorie, objectif, personne responsable, date de création, date de retrait planifiée. Les interrupteurs de release reçoivent une date d'expiration peu après le déploiement complet.
• Centraliser la logique de décision en un seul endroit : le code demande « la fonctionnalité X est-elle active dans ce contexte ? », pas « quelle valeur figure dans la configuration ? ». La réponse est transmise comme une dépendance, afin que les tests puissent forcer les deux états.
• Tester les deux états d'un interrupteur de release dans le pipeline jusqu'à son retrait : au minimum le chemin par défaut et le chemin avec tous les interrupteurs dans leur position cible.
• Rendre visibles les états des interrupteurs par environnement (une page ou un point d'accès qui liste tous les interrupteurs avec leur valeur et leur origine) et journaliser les changements.
• Planifier le retrait comme une tâche à part entière : supprimer la condition, effacer la branche morte, adapter les tests, nettoyer la configuration. Les interrupteurs en retard apparaissent dans le backlog comme toute autre dette technique.
• Concevoir délibérément comme de la configuration les interrupteurs d'exploitation et de permission destinés à rester : documentés, avec une valeur par défaut, avec un contrôle d'accès.

Pièges

Un interrupteur qui change des formats de données ne peut pas simplement être remis en arrière une fois que des données ont été écrites dans le nouveau format ; il faut alors une démarche d'expansion puis de contraction (« expand and contract »). Des états d'interrupteurs maintenus dans plusieurs systèmes rendent les incidents impossibles à reproduire. Des interrupteurs interrogés via une chaîne de caractères comme nom renvoient silencieusement la valeur par défaut en cas de faute de frappe. Un interrupteur d'expérimentation qui subsiste après l'expérience maintient les deux variantes en vie.