Les feature flags codés en dur, c'est OK (et même malin)
Pourquoi ça compte pour toi
Tu crois que tu as besoin d'une plateforme de gestion de drapeaux sophistiquée ? Probablement pas. Les outils marketing te vendent de la complexité quand une variable de configuration suffit. Cet article remet les pendules à l'heure : coder tes drapeaux en dur, c'est simple, sûr, et ça réduit les risques de sécurité et de maintenance.
Ce qu'il faut retenir
- 1.Les drapeaux codés en dur (JSON + relecture/déploiement) couvrent 95% des besoins réels sans infrastructure supplémentaire.
- 2.Les suites de gestion de drapeaux ajoutent surveillance, hébergement, surface d'attaque et dette technique pour un besoin rarement urgent.
- 3.Drapeaux à longue durée de vie = poison : transforme-les en comportement réel ou supprime-les, sinon tu rigidifies ton code.
- 4.Seules les équipes qui gèrent des milliers de drapeaux et modifient les fonctionnalités en direct sans redémarrage ont besoin d'outils plus complexes — c'est rare.
Tu galères avec le jargon ?
Lis la version réécrite en mode débutant — toutes les idées, sans le jargon.
Pourquoi les drapeaux codés en dur gagnent
Un feature flag, c'est juste une condition : if (feature_enabled) { ... }. Rien de plus.
Mais quelque part, le marketing s'en est emparé et t'a convaincu que tu avais besoin d'une plateforme entière avec API, cache distribué, surveillance temps réel et tout le reste. Résultat : tu traînes une dépendance externe, des SLA à respecter, et une surface d'attaque nouvelle.
Le coût caché des outils de gestion
- ▸Infrastructure : un service de plus à héberger, surveiller, faire évoluer.
- ▸Comportement non-déterministe : ton code dépend désormais d'un état externe, plus difficile à tester et à déboguer.
- ▸Dette technique : les drapeaux "temporaires" traînent pendant des mois, ton code devient un labyrinthe.
- ▸Sécurité : chaque outil externe, c'est une API, une authentification, des clés — autant de portes d'entrée.
La solution ennuyeuse (qui marche)
- ▸Un fichier JSON avec tes drapeaux.
- ▸Lis-le au démarrage de l'application.
- ▸Utilise-les comme des variables normales.
- ▸Quand tu dois changer un drapeau : pull request → relecture → test → déploiement.
- ▸Quand un drapeau n'est plus utile : supprime-le du code ET du JSON.
C'est tout. Pas de magie, pas de magie à l'exécution, pas de cache à invalider.
Quand faut-il franchir le cap ?
Quand tu sais que tu as besoin de modifier une fonctionnalité en direct sans redémarrage, sans test, sans relecture, à l'échelle de milliers de drapeaux — à ce moment, envisage un outil. Mais avant ? Tu optimises prématurément. Et ça, c'est du mauvais design.
Le fait est : si tu dois vraiment changer la couleur d'un bouton en direct parce que "le business brûle", ton problème n'est pas tes drapeaux, c'est ton processus de déploiement. Règle ça d'abord.
Et concrètement pour toi ?
Choisis ton profil — la lecture de l'article change selon qui tu es.
Pour toi, sache que même chez les géants, 90% des feature flags n'ont rien de magique — ce sont juste des if/else stockés dans du JSON. Les vendeurs te vendent des usines à gaz pour transformer du simple en complexe lucratif.
Source
📊 Cours en bourse
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :