Feature flags : puissance réelle et complexité cachée

Le concept de feature flag est élégant dans sa simplicité : une condition dans le code qui détermine si une fonctionnalité est active ou non, contrôlée depuis l’extérieur du code. Déployez le code, activez la fonctionnalité quand vous êtes prêts. Désactivez-la instantanément si un problème apparaît.

Cette élégance cache une réalité opérationnelle plus compliquée. Les feature flags sont un outil puissant, mais ils s’accumulent, ils interagissent, ils créent du code conditionnel qui devient difficile à lire et à tester, et ils finissent par coûter plus qu’ils ne rapportent si on ne les gère pas activement.

Ce que les feature flags permettent vraiment

Les cas d’usage légitimes des feature flags sont bien définis, et les distinguer des usages qui créent plus de problèmes qu’ils n’en résolvent est la première étape d’une utilisation raisonnée.

La séparation déploiement / livraison. C’est le cas d’usage le plus puissant. Déployer du code en production sans l’activer permet de valider que le déploiement est sain (pas de crash, pas de régression de performance) avant d’exposer la fonctionnalité aux utilisateurs. Les équipes avec des pipelines CI/CD matures utilisent les feature flags pour rendre leurs déploiements quasi-ininterruptus.

Le canary release. Activer une fonctionnalité pour un sous-ensemble d’utilisateurs (1 %, 10 %, 50 %) permet de mesurer son impact réel avant un rollout complet. Si les métriques montrent un problème, on réduit le pourcentage ou on désactive. C’est du rollback sans rollback.

Les tests A/B. Proposer deux versions d’une fonctionnalité à deux groupes d’utilisateurs et mesurer les différences de comportement. Utile pour les décisions de design et d’UX avec un volume d’utilisateurs suffisant pour avoir une signification statistique.

La configuration par environnement. Activer certaines fonctionnalités uniquement en développement ou en staging, désactiver les intégrations externes coûteuses en local. C’est une utilisation simple et à faible risque.

Les feature switches pour clients enterprise. Certains clients ont des contrats qui incluent des fonctionnalités spécifiques. Les feature flags permettent d’activer ces fonctionnalités par compte ou par organisation sans maintenir des branches séparées.

La dette des flags qui s’accumule

Le problème des feature flags est qu’ils sont faciles à créer et difficiles à supprimer.

Créer un feature flag prend deux minutes. Supprimer un feature flag une fois la fonctionnalité complètement déployée demande : vérifier que le flag est actif pour 100 % des utilisateurs, supprimer toutes les branches conditionnelles dans le code, supprimer la configuration du flag, tester que le comportement sans flag est identique au comportement avec flag activé. C’est du travail, et c’est du travail qui n’apporte pas de fonctionnalité visible.

Résultat prévisible : les flags s’accumulent. Trois mois après la livraison d’une fonctionnalité, le flag correspondant est toujours là. Un an après, personne ne sait si c’est dangereux de le supprimer. Deux ans après, le code conditionnel est tellement enchevêtré avec le reste qu’on ne touche plus à ce fichier.

Les recherches sur les codebases de grande taille montrent régulièrement que les feature flags obsolètes sont une source significative de dette technique. Ils augmentent la surface de code à maintenir, compliquent la lecture du flux logique et créent des états impossibles à tester exhaustivement.

L’explosion combinatoire des états

Un feature flag crée deux états : activé ou désactivé. Deux feature flags créent quatre états possibles. Dix feature flags créent 1024 états possibles. Cinquante feature flags créent plus d’états que vous ne pouvez en tester dans une vie.

En pratique, la plupart de ces combinaisons ne se produisent pas. Mais certaines le font, et les interactions entre flags peuvent produire des comportements inattendus qui ne se manifestent que pour des configurations spécifiques.

Les tests automatisés couvrent généralement les états principaux (tout activé, tout désactivé) et peut-être quelques combinaisons importantes. Ils couvrent rarement l’espace combinatoire complet. Les bugs qui vivent dans des combinaisons de flags spécifiques sont difficiles à trouver et difficiles à reproduire.

La lisibilité du code conditionnel

Un code sans feature flags a un flux logique lisible : la fonctionnalité est là, elle fonctionne de telle façon.

Un code avec plusieurs feature flags sur les mêmes chemins de code devient difficile à lire. Chaque branche conditionnelle interrompt le flux narratif. Les développeurs qui lisent le code doivent garder en tête l’état des flags pour comprendre ce qui s’exécute réellement dans chaque configuration.

Ce problème s’aggrave avec le temps parce que les développeurs qui ont créé les flags comprennent leur signification, mais ceux qui arrivent ensuite doivent reconstruire ce contexte à chaque lecture.

Les règles qui limitent la dette

Les équipes qui utilisent les feature flags avec succès à grande échelle ont généralement des règles explicites pour limiter leur accumulation.

Date d’expiration obligatoire. Chaque feature flag créé a une date d’expiration. Passée cette date, soit le flag est supprimé, soit la date est explicitement repoussée avec une justification. Ce processus force à une décision consciente sur la durée de vie du flag.

Propriétaire assigné. Chaque feature flag a un propriétaire responsable de sa suppression une fois la fonctionnalité déployée. Sans propriétaire, les flags sont orphelins dès leur création.

Inventaire régulier. Une revue périodique (mensuelle ou trimestrielle) de tous les flags actifs, avec pour chaque flag la question : est-il encore nécessaire ? Si non, quand est-il supprimé ?

Limite sur le nombre total. Certaines équipes se fixent une limite absolue : pas plus de X flags actifs en même temps. Créer un nouveau flag nécessite d’en supprimer un ancien. Cette contrainte force à traiter les flags comme une ressource à gérer activement.

Les alternatives sous-utilisées

Les feature flags sont parfois utilisés pour résoudre des problèmes qui ont de meilleures solutions.

Les feature flags pour éviter les branches git. Certaines équipes utilisent les feature flags pour permettre à plusieurs développeurs de travailler sur des fonctionnalités interdépendantes sans utiliser de branches longues. C’est une solution qui déplace la complexité de git vers le code applicatif. Les techniques de trunk-based development combinées à des petits commits sont souvent une meilleure réponse.

Les feature flags pour la configuration d’environnement. Les variables d’environnement sont souvent plus appropriées pour les différences entre développement, staging et production. Les feature flags ajoutent une couche de gestion inutile pour ce cas d’usage.

Les feature flags comme substitut à une vraie gestion de version. Si une API change de manière incompatible, la bonne réponse est la gestion de version (v1, v2) pas un feature flag. Les feature flags pour les changements d’API créent une prolifération de conditions dans les couches de service.

Quand ne pas utiliser les feature flags

Il y a des contextes où les feature flags ne sont pas le bon outil malgré leur popularité.

Les projets petits et à faible fréquence de déploiement. Si vous déployez une fois par mois et que votre équipe est petite, la valeur des feature flags ne justifie pas le coût de leur gestion. Un déploiement propre avec rollback manuel est plus simple.

Les fonctionnalités avec de fortes contraintes de cohérence. Si une fonctionnalité nécessite des migrations de base de données ou des changements d’API qui ne peuvent pas coexister avec l’ancienne version, un feature flag ne vous protège pas vraiment. Le rollback reste complexe même avec le flag.

Les domaines où l’état partiel est dangereux. Dans les systèmes financiers ou de conformité, exposer une fonctionnalité partiellement implémentée à certains utilisateurs peut créer des incohérences de données difficiles à corriger. La précaution supplémentaire des feature flags ne compense pas le risque d’états partiels.

Les feature flags sont un outil précieux pour les équipes avec des pipelines de déploiement matures, des équipes larges et des besoins de déploiement progressif. Leur valeur est réelle et mesurable.

Leur coût est tout aussi réel. Le traiter comme tel - avec des règles explicites de suppression, des propriétaires assignés et un inventaire régulier - est la différence entre un outil qui accélère le travail et une dette de complexité qui finit par le ralentir.