Un feature flag permet de dissocier le déploiement du code de l’activation d’une fonctionnalité. Cette séparation est utile pendant la validation ou la coordination d’un changement. Mais, sans révision, un flag peut laisser des branches de code oubliées et compliquer chaque opération de maintenance. Le retirer ne consiste pas simplement à supprimer une condition : il faut décider quel comportement conserver, vérifier qui en dépend et s’assurer que le nettoyage ne modifie pas d’autres parcours.
En pratique, chaque flag temporaire doit avoir un objectif, un responsable et un critère de sortie. L’équipe peut ainsi conserver ceux qui remplissent encore une fonction et supprimer ceux qui ne représentent plus qu’une dette technique.
Identifiez le type de flag et sa fonction
Avant de modifier le code, déterminez à quoi sert le flag. Tous ne doivent pas être retirés selon le même calendrier, et certains ne sont pas temporaires. Une classification simple aide à éviter aussi bien les suppressions prématurées que le maintien par inertie :
- Flag de lancement : il contrôle l’accès à une fonctionnalité en cours d’intégration. Si le nouveau comportement est désormais celui retenu pour le produit et qu’il n’est plus nécessaire de revenir à l’ancien au moyen du flag, celui-ci peut généralement être retiré.
- Flag d’expérimentation : il permet de comparer des variantes ou de limiter un test. Il doit être réexaminé à la fin de l’expérience, une fois la variante à conserver choisie. Garder ses conditions sans hypothèse active peut rendre les résultats et les parcours ambigus.
- Configuration permanente : elle permet d’ajuster durablement un comportement opérationnel ou une option du produit. Il ne s’agit pas nécessairement d’une dette temporaire : comme toute configuration maintenue, elle nécessite une documentation, des contrôles et un responsable.
Il peut également exister des flags d’urgence ou d’exploitation permettant de désactiver une fonctionnalité dans certaines circonstances. Ne les retirez pas uniquement parce qu’ils sont présents depuis longtemps : vérifiez d’abord si un besoin existe toujours et si un autre mécanisme assure la même fonction. La question essentielle n’est pas de savoir depuis combien de temps le flag existe, mais quelle décision ou capacité il permet aujourd’hui.
Définissez un responsable et une condition de retrait dès le départ
Le moyen le plus efficace de réduire l’inventaire oublié consiste à consigner le cycle de vie du flag dès sa création. Indiquez au minimum son objectif, un responsable clairement identifié, le comportement qui doit rester actif et une date ou un événement déclenchant sa révision. Cette date n’implique pas forcément une suppression automatique : elle évite simplement que la décision reste sans responsable.
Formulez la condition de sortie de manière vérifiable. Par exemple, l’équipe peut convenir de réexaminer le flag à la fin d’un test, après une migration ou lorsque l’adoption du nouveau comportement est confirmée. Évitez les indications vagues comme « à retirer quand ce sera possible ». Si le critère dépend d’une décision produit, précisez qui doit la prendre et de quelles informations cette personne a besoin.
Une fiche minimale peut contenir :
- Le nom et l’emplacement du flag.
- Son type et la raison de sa création.
- La personne responsable de la décision et de la modification du code.
- Les utilisateurs, environnements ou services potentiellement concernés.
- La condition de retrait et la date de révision.
Si un flag n’a pas de responsable, ne commencez pas par le supprimer à l’aveugle. Désignez quelqu’un qui pourra vérifier son objectif et ses dépendances, ou soumettez la décision à l’équipe responsable de cette partie du produit.
Vérifiez qui dépend du flag
Avant de consolider un parcours, examinez tous les endroits où le flag est évalué ou configuré. Une recherche dans le dépôt peut révéler des références directes, mais pas toujours les consommateurs indirects, les règles stockées hors du code ou les différences entre environnements. Comparez les résultats avec le système de configuration et les procédures de l’équipe.
Procédez à ces vérifications dans l’ordre :
- Références dans le code : repérez les conditions, fonctions auxiliaires, tests et composants qui consultent le flag. Recherchez également ses anciens noms s’il a été renommé.
- Configuration par environnement : vérifiez si les valeurs diffèrent entre le développement, les tests et la production. Ne supposez pas que l’état observé dans un environnement s’applique aux autres.
- Périmètre des utilisateurs : confirmez si la condition concerne l’ensemble du public ou des segments, des comptes ou des rôles particuliers. Un parcours encore actif pour un groupe peut passer inaperçu lors de tests généraux.
- Dépendances externes : examinez la documentation opérationnelle, les tâches automatisées et les autres composants qui lisent ou modifient l’état du flag.
- Utilisation observée : si la télémétrie est disponible, vérifiez si le flag est évalué et dans quel contexte. L’absence d’événements n’est significative que si l’instrumentation couvre les parcours concernés.
La télémétrie fournit des éléments utiles, mais ne remplace pas l’examen de la conception. Un parcours peu fréquent, un environnement sans trafic ou une métrique incomplète peuvent laisser croire à tort que personne ne dépend du flag.
Supprimez les branches alternatives dans le cadre d’un changement maîtrisé
Une fois le comportement définitif convenu, simplifiez la logique afin que l’application exprime directement cette décision. Si la nouvelle variante est conservée, retirez l’ancienne branche ainsi que la condition devenue inutile. Si l’ancienne est retenue, supprimez l’alternative écartée. Évitez de remplacer un ancien flag par un autre sans nécessité opérationnelle clairement établie : cela déplace la dette au lieu de la résoudre.
Effectuez la modification par étapes compréhensibles. Commencez par supprimer les références dans le code et les tests qui ne concernaient que l’option écartée, puis retirez la définition du flag et ses valeurs de configuration. S’il concerne plusieurs services ou dépôts, coordonnez l’ordre des changements afin qu’une mise à jour ne laisse pas de composants dépendre d’une option qui n’existe plus. Si une modification unique n’est pas possible, documentez les dépendances restantes et désignez la personne chargée de chacune.
Les tests doivent couvrir le comportement conservé, et pas seulement démontrer que le flag a disparu. Exécutez les tests pertinents pour les parcours modifiés et ajoutez ou adaptez des cas couvrant les limites qui dépendaient de la condition : autorisations, erreurs, états vides ou différences entre environnements, selon le système concerné. Examinez le changement pour repérer les conditions redondantes, le code inatteignable et les hypothèses qui ne sont plus vérifiées.
Validez la clôture à l’aide de signaux et de la documentation
Avant de terminer la tâche, vérifiez que le code compilé ou exécuté ne consulte plus le flag et que sa configuration a été supprimée des environnements concernés. Assurez-vous également que les tableaux de bord, les alertes, les instructions d’assistance et la documentation n’indiquent pas qu’il est encore possible de le modifier. Si le changement modifie un parcours visible, validez le résultat selon les critères habituels du produit et observez les signaux disponibles après sa livraison.
Déterminez à l’avance les éléments à surveiller et pendant combien de temps, en fonction du risque associé au changement. Il peut suffire de vérifier les erreurs, l’achèvement des tâches ou les incidents liés au parcours ; n’inventez pas de seuil si l’équipe ne dispose pas d’une valeur de référence. En cas de régression, cherchez si elle est due à la décision fonctionnelle, à une dépendance non détectée ou à la suppression d’une protection opérationnelle.
Si le risque justifie de conserver une possibilité de retour, choisissez explicitement laquelle. Garder pendant une durée limitée une option de retour documentée peut être raisonnable ; laisser indéfiniment le flag sans responsable ni critère d’utilisation ne l’est pas. Consignez la décision et planifiez une nouvelle révision si le retrait est reporté.
Quand conserver le flag et liste de vérification
Il est judicieux de conserver un flag s’il contrôle encore une configuration nécessaire, une expérience en cours ou une capacité de réponse qui n’a pas de substitut. À l’inverse, la décision produit est prise, l’alternative n’est ni utilisée ni nécessaire, et aucune équipe ou procédure n’en dépend : autant de signes qu’un retrait est possible. Le fait qu’un flag soit toujours activé est un indice, pas une preuve. Vérifiez d’abord que cet état s’applique à tous les utilisateurs et environnements concernés.
Intégrez le nettoyage aux revues habituelles de l’équipe. À chaque revue produit ou opération de maintenance, recherchez les flags arrivés à échéance, sans responsable, sans condition de sortie ou associés à des expériences terminées. Donnez la priorité à ceux qui multiplient les embranchements dans les parcours fréquents ou compliquent des changements à venir. Une courte liste évite de transformer le nettoyage en initiative distincte, toujours reportée.
- L’objectif et le type du flag sont-ils clairs ?
- Un responsable et une condition de retrait sont-ils documentés ?
- Le code, la configuration, les environnements et les consommateurs ont-ils été examinés ?
- Le comportement à conserver a-t-il été choisi et les branches écartées supprimées ?
- Les tests couvrent-ils les parcours concernés et les signaux après livraison seront-ils suivis ?
- La documentation et les procédures ont-elles été mises à jour, et la configuration obsolète supprimée ?
Un retrait bien mené réduit le nombre de parcours possibles et rend la décision plus visible dans le code. Si une réponse de la liste reste en suspens, transformez cette incertitude en tâche concrète, avec un responsable et une date de révision. Les feature flags temporaires remplissent ainsi leur rôle sans devenir des branches cachées permanentes.