Hardcoding des feature flags simplifie la gestion et réduit les risques

Contexte et enjeux des feature flags

Les feature flags, ou bascules fonctionnelles, permettent de masquer ou d’activer des fonctionnalités sans modifier le code source. Les éditeurs proposent des plateformes dédiées qui promettent le contrôle à chaud, la mise à l’échelle à des milliers de drapeaux et l’absence de redéploiement. L’article souligne que ces promesses sont souvent accompagnées d’une complexité opérationnelle accrue : chaque service de gestion requiert son propre hébergement, son monitoring et ses procédures de mise à jour.

Cette complexité se traduit par un risque d’erreur supplémentaire dans le pipeline CI/CD, ainsi qu’une surface d’attaque élargie, car chaque composant expose des API et des bases de données de configuration.

Architecture des systèmes de gestion de flags

Dans une implémentation classique, les flags sont stockés dans un service externe (ex. Redis, base SQL) et récupérés à chaque requête ou via un cache dynamique. Cette approche implique un processus séparé qui doit être synchronisé avec les déploiements, ce qui nécessite des scripts de migration, des stratégies de cache invalidation et des tests de cohérence à chaque modification. Le coût en ressources augmente proportionnellement au nombre de flags, comme le souligne l’auteur lorsqu’il mentionne la nécessité de « thousands of feature flags ».

Le modèle impose également une dépendance temporelle : la disponibilité du service de flags devient critique pour le bon fonctionnement de l’application, introduisant un point de défaillance unique.

Analyse des flags hardcodés

Le texte propose une alternative : coder les drapeaux directement dans le code ou les charger depuis un fichier JSON lu au démarrage. Cette méthode élimine les composants dynamiques et les exigences de monitoring, réduisant ainsi le nombre de points de défaillance. Le fichier JSON agit comme une source de vérité statique ; toute modification nécessite un nouveau déploiement, ce qui garantit que chaque version du code est associée à un état de configuration connu et déterministe.

Le risque de dette technique existe également avec les drapeaux hardcodés, mais il est plus visible : les développeurs peuvent identifier rapidement les sections conditionnelles et les supprimer lorsqu’elles ne sont plus utiles. L’article recommande de « supprimer les flags lorsqu’ils ne sont plus nécessaires », ce qui limite l’accumulation de code mort.

{
  "newHomepage": false,
  "betaSearch": true,
  "enableLogging": true
}

En Python, la lecture se fait en une ligne :

import json, pathlib
flags = json.loads(pathlib.Path('flags.json').read_text())
if flags["newHomepage"]:
    render_new_homepage()

Implications sécuritaires et techniques

Du point de vue de la sécurité, chaque service de gestion de flags expose une API qui peut être ciblée par des attaques d’injection ou de contournement. En contrast, un fichier JSON statique, intégré au dépôt, bénéficie des mêmes contrôles d’accès que le code source : revue de code, signatures Git et audits de dépendances. Ainsi, la surface d’attaque diminue sensiblement.

Techniquement, le hardcoding impose une contrainte de déploiement pour tout changement. Cette contrainte est souvent acceptable pour la majorité des équipes, comme le souligne l’auteur : « pour la plupart des produits, cela suffit largement ». Lorsque le besoin de modification à chaud devient réel, il faut alors envisager une solution plus sophistiquée, mais uniquement après une évaluation rigoureuse du coût opérationnel.