Quand les Feature Flags Deviennent une Dette Technique

Vous avez livré une nouvelle fonctionnalité en utilisant un feature flag. Ça a fonctionné. Les utilisateurs l'ont adoptée. Le flag est resté activé pour tout le monde. Des mois ont passé. Maintenant, ce flag est toujours dans le code, à côté de trois autres flags du trimestre dernier, deux d'il y a six mois, et un dont personne ne se souvient ce qu'il contrôle.

Ce n'est pas inhabituel. De nombreuses équipes commencent à utiliser les feature flags avec de bonnes intentions : des livraisons plus sûres, des déploiements progressifs, des interrupteurs d'urgence. Mais les flags qui ne sont jamais supprimés se transforment lentement en un problème différent. Ils cessent d'être un outil de contrôle des livraisons et deviennent une dette technique qui ralentit tout le monde.

Le Coût Réel des Flags Abandonnés

Chaque flag que vous laissez dans le code ajoute un point de décision. Quand un développeur lit une fonction, il doit se demander : cette branche est-elle encore utilisée ? Celle-ci peut-elle être supprimée en toute sécurité ? Puis-je effacer l'ancien chemin de code, ou un utilisateur l'emprunte-t-il encore ?

Avec un ou deux flags, c'est gérable. Avec des dizaines, lire le code devient un jeu de devinettes. Vous vous retrouvez avec des blocs if-else où personne n'est sûr du chemin actif. Le code qui était autrefois simple se transforme en un labyrinthe de logique conditionnelle que tout le monde a peur de toucher.

Il y a aussi un coût d'exécution. Chaque fois que l'application s'exécute, elle évalue chaque flag. Un seul contrôle de flag est peu coûteux. Des centaines de contrôles de flags dans des chemins de code chauds s'accumulent. Les cycles CPU dépensés à évaluer des flags qui retournent toujours la même valeur sont gaspillés. La mémoire utilisée pour stocker des configurations de flags qui ne changent jamais est gaspillée. Avec le temps, cette surcharge devient mesurable, en particulier dans les services à fort trafic.

Chaque Flag a Besoin d'un Cycle de Vie

La solution n'est pas d'arrêter d'utiliser les feature flags. La solution est de traiter chaque flag comme quelque chose qui doit éventuellement être supprimé. Un feature flag doit avoir un cycle de vie clair dès sa création :

Le diagramme suivant montre le cycle de vie prévu d'un feature flag et ce qui se passe lorsque la suppression est ignorée :

flowchart TD A[Flag Créé] --> B[Tests Internes] B --> C[Déploiement Progressif] C --> D[Déploiement Complet] D --> E[Fonctionnalité Stable] E --> F[Flag Supprimé] E -.-> G[Flag Non Supprimé] G --> H[Dette Technique S'accumule] H --> I[Complexité du Code Augmente] H --> J[Surcharge d'Exécution] H --> K[Confusion des Développeurs] F --> L[Code Propre]
  1. Le flag est ajouté lorsque le travail sur une nouvelle fonctionnalité commence.
  2. Il est activé pour les tests internes.
  3. Il est déployé progressivement à un sous-ensemble d'utilisateurs.
  4. Il est activé pour tous les utilisateurs.
  5. La fonctionnalité est vérifiée comme stable en production.
  6. Le flag est supprimé.

L'étape six est celle que la plupart des équipes sautent. La fonctionnalité fonctionne. Tout le monde l'utilise. Le flag est toujours activé, alors pourquoi s'embêter à le supprimer ? Parce que chaque jour où le flag reste, il ajoute des frictions. Le code est plus difficile à lire. La prochaine modification prend plus de temps. Le risque d'introduire un bug augmente car personne n'est sûr des chemins de code réellement actifs.

Quand Supprimer un Flag

Le bon moment pour supprimer un flag est dès que la fonctionnalité qu'il contrôle est stable et entièrement déployée. Certaines équipes fixent une règle stricte : supprimer le flag dans un ou deux sprints après que la fonctionnalité atteint 100 % des utilisateurs. D'autres utilisent des rappels automatisés qui signalent toute clé de configuration active au-delà d'une certaine période.

Supprimer un flag ne consiste pas seulement à effacer la vérification conditionnelle. Vous devez aussi nettoyer l'ancien code que le flag protégeait. Si la nouvelle fonctionnalité a remplacé une ancienne, supprimez entièrement l'ancien chemin de code. Ne laissez pas de code mort derrière vous. Le code mort n'est pas inoffensif. Il confond les développeurs, gaspille du temps de build et peut provoquer des bugs subtils si quelqu'un le modifie plus tard en pensant qu'il est toujours utilisé.

Du côté de la configuration, supprimez également le flag de votre système de gestion des flags. Un flag supprimé du code mais toujours visible dans un tableau de bord ou un fichier de configuration créera de la confusion. Quelqu'un finira par demander si ce flag est encore nécessaire, et personne n'aura de réponse claire.

Faire de la Suppression une Partie du Processus

La façon la plus efficace d'empêcher les flags de s'accumuler est d'exiger un plan de suppression lors de la création du flag. Quand un développeur ouvre une pull request qui ajoute un nouveau feature flag, la PR doit inclure une note sur quand et comment le flag sera supprimé. Cela peut être un commentaire dans le code, une tâche dans votre outil de gestion de projet, ou une date d'expiration automatique dans le système de flags lui-même.

Certaines équipes vont plus loin et imposent l'expiration des flags par programmation. Le système de flags rejette tout nouveau flag qui n'inclut pas une date d'expiration obligatoire. Lorsque la date passe, le système envoie une notification ou désactive même automatiquement le flag. Cela force l'équipe à soit supprimer le flag, soit prolonger explicitement sa durée de vie avec une justification.

Cela peut sembler être une surcharge pour une petite équipe qui livre une fonctionnalité par mois. Mais le modèle passe à l'échelle. Une fois que vous avez plusieurs équipes livrant plusieurs fonctionnalités en parallèle, la gestion manuelle des flags devient insoutenable. La discipline que vous construirez tôt vous évitera un nettoyage douloureux plus tard.

Une Liste de Vérification Pratique pour le Nettoyage des Flags

Si vous voulez commencer à nettoyer les flags aujourd'hui, voici un processus simple :

  • Identifiez tous les flags actuellement dans votre codebase et votre système de configuration.
  • Pour chaque flag, déterminez si la fonctionnalité qu'il contrôle est entièrement déployée et stable.
  • Si la fonctionnalité est stable, supprimez le flag du code et effacez l'ancien chemin de code.
  • Supprimez le flag de votre système de configuration ou de gestion des flags.
  • Mettez à jour toute documentation ou runbook qui référence le flag.
  • Pour tout nouveau flag, ajoutez un plan de suppression dans la pull request qui l'introduit.

Ce n'est pas un exercice ponctuel. Faites-en une pratique régulière. Certaines équipes consacrent un sprint par trimestre au nettoyage des flags. D'autres l'ajoutent à leur définition de fini pour chaque fonctionnalité. Trouvez un rythme qui fonctionne pour votre équipe et tenez-vous-y.

L'Essentiel

Les feature flags sont un outil puissant pour contrôler les livraisons et réduire les risques. Mais ils ne sont pas gratuits. Chaque flag que vous conservez au-delà de sa durée de vie utile ajoute de la complexité, ralentit le développement et augmente les risques d'erreurs. L'objectif n'est pas d'éviter les flags. L'objectif est de les utiliser avec discipline et de les supprimer lorsqu'ils ont rempli leur fonction.

Si vous laissez les flags s'accumuler, ils cessent d'être un mécanisme de contrôle des livraisons et deviennent un fardeau que votre équipe porte chaque jour. Nettoyez-les. Vous-même dans le futur, et le développeur qui devra lire votre code le mois prochain, vous en remerciera.