Une mise en production qui plante à 2h du matin ne devrait pas nécessiter un redéploiement de 20 minutes pour être corrigée. Les feature flags vous offrent un interrupteur pour désactiver instantanément une fonctionnalité défectueuse, sans toucher au pipeline de déploiement. La question n'est pas de savoir s'il faut en utiliser, mais quelle version construire : un flag écrit par vos soins, une plateforme open source que vous hébergez sur votre propre serveur, ou un service managé payé au siège ou à la requête. Chaque option entraîne une facture différente, en argent, en temps, ou les deux.
Faites-le vous-même : un flag construit en une après-midi
Un flag « maison » est généralement un booléen dans un fichier de configuration, une variable d'environnement ou une ligne dans une table de base de données que votre application vérifie avant d'exécuter une fonctionnalité. Cela ne coûte rien en frais de licence. Le vrai coût est le temps d'ingénierie : une version basique prend un jour ou deux à construire, et elle devient de plus en plus coûteuse à chaque fois que vous ajoutez des règles de ciblage, des déploiements progressifs ou une piste d'audit.
La mise en place consiste à choisir un endroit pour stocker l'état du flag là où votre application peut l'atteindre sans redémarrage, généralement une ligne de base de données, une clé Redis ou un fichier JSON distant que l'application interroge via un minuteur. La vitesse de retour arrière dépend entièrement de cet intervalle d'interrogation. Si votre application vérifie le flag toutes les 30 secondes, le retour arrière prend jusqu'à 30 secondes ; si vous construisez un mécanisme de push, c'est presque instantané, mais ce mécanisme de push représente du code supplémentaire dont vous êtes responsable.
La maintenance repose entièrement sur votre équipe. Aucun fournisseur ne corrige la bibliothèque cliente, aucun journal d'audit intégré ne montre qui a activé quoi et quand, et aucune logique de déploiement progressif n'existe à moins de la coder vous-même. Le vrai inconvénient apparaît à grande échelle : un stockage de flags qui tombe peut entraîner l'échec des vérifications de fonctionnalités de votre application, et déboguer un flag bloqué signifie lire votre propre code à minuit au lieu de la documentation d'un fournisseur.
Open source auto-hébergé : Unleash ou Flagsmith sur votre propre serveur
La version open source auto-hébergée d'Unleash est gratuite avec un nombre illimité de feature flags. La version open source auto-hébergée de Flagsmith est gratuite, sans limite d'utilisation. Les deux projets placent la logique des feature flags derrière une véritable API plutôt que dans une table de configuration maison, avec des SDK, des règles de ciblage et des pourcentages de déploiement déjà intégrés.
La configuration est plus lourde que le fait-maison, mais moins pire qu'il n'y paraît. Unleash est simple à auto-héberger avec un composant serveur et une base de données Postgres, tandis que Flagsmith fonctionne sur une stack Django et Postgres, ce qui demande un vrai travail en production. Le retour arrière est rapide une fois le système en marche : les deux plateformes sont conçues pour une évaluation instantanée des flags, ce qui est le but même d'un interrupteur d'urgence, désactiver une fonctionnalité sans redéployer de code.
Le niveau gratuit comporte de vraies limites. L'édition open source d'Unleash couvre les fonctionnalités de base mais vous limite à 1 projet, 2 environnements et 5,000 feature flags par instance. La maintenance est le prix à payer pour cette licence gratuite : vous l'exploitez vous-même, y compris la base de données, les mises à jour et la couverture d'astreinte. Si vous dépassez le niveau gratuit plus tard, le plan Enterprise d'Unleash commence à $75 par siège et par mois, disponible en cloud ou auto-hébergé avec un minimum de cinq sièges, ce qui transforme un outil gratuit en un véritable poste de dépense.
SaaS managé : LaunchDarkly, Flagsmith Cloud et similaires
Une plateforme managée élimine complètement la question de l'infrastructure. Vous installez un SDK, et le fournisseur gère le service d'évaluation des flags, le tableau de bord et le journal d'audit. Sur LaunchDarkly, cette installation prend environ une heure ou deux pour intégrer le SDK et créer un premier flag, et la maintenance continue du côté du fournisseur est pratiquement nulle du point de vue de votre équipe.
Le coût est là où la comparaison se complique. LaunchDarkly commence à $12 par utilisateur et par mois sur son plan Foundation, qui inclut le SSO, des environnements illimités et des projets illimités. Les tarifs plus récents sont passés à une facturation basée sur l'utilisation : le plan payant facture désormais $10 par connexion de service par mois plus $8.33 par 1,000 utilisateurs actifs mensuels côté client, ce qui signifie qu'un mois calme coûte peu, mais qu'un pic de trafic coûte cher. Le niveau cloud de Flagsmith est plus simple à prévoir : le plan Start-Up est à $45 par mois pour jusqu'à 1 millions de requêtes et 3 utilisateurs.
L'écart entre le prix annoncé et la facture réelle est le principal inconvénient ici. Les données Vendr montrent que les contrats annuels médians pour LaunchDarkly sont de $72,000, avec des fourchettes documentées de $19,500 à $165,700, bien au-dessus du prix catalogue par siège. La vitesse de retour arrière est excellente sur toutes les plateformes managées ; le risque n'est pas que l'interrupteur d'urgence échoue, c'est que la facture arrive plus élevée que prévu.
À qui chaque option convient-elle ?
Un flag maison convient à une petite équipe avec une seule application et une ou deux fonctionnalités qui ont occasionnellement besoin d'un interrupteur d'arrêt, où construire un tableau de bord serait excessif. Cela perd son sens dès que deux équipes doivent coordonner des flags, ou que l'entreprise demande un déploiement progressif pour 10 % des utilisateurs.
Unleash ou Flagsmith auto-hébergés conviennent aux équipes qui gèrent déjà leur propre infrastructure, se soucient de la résidence des données ou souhaitent éviter les frais récurrents et ont la capacité opérationnelle de corriger et de sauvegarder une base de données. Cela convient aux secteurs réglementés et aux équipes ayant un ingénieur plateforme qui gère déjà des services similaires.
Une plateforme SaaS managée convient aux équipes qui veulent que les changements de flags fonctionnent dès le premier jour sans embaucher quelqu'un pour gérer un serveur, et qui valorisent un temps d'ingénierie prévisible plutôt qu'une facturation prévisible. C'est le bon choix pour une petite équipe produit qui livre à une base d'utilisateurs importante et en croissance, à condition que quelqu'un vérifie le tableau de bord d'utilisation chaque mois au lieu de le faire uniquement au moment du renouvellement.
Le facteur décisionnel
La vraie décision n'est pas de savoir quelle plateforme possède le meilleur tableau de bord. C'est de savoir si votre équipe paie déjà quelqu'un pour gérer des bases de données et appliquer des correctifs de sécurité, car cette capacité est ce qui rend le niveau auto-hébergé gratuit réellement gratuit. Si personne dans l'équipe ne veut ce travail, le prix de départ mensuel de $12 à $45 d'un plan SaaS managé est moins coûteux que les heures d'ingénierie passées à déboguer un flag maison à 2h du matin. Commencez avec le niveau gratuit d'Unleash ou de Flagsmith si vous gérez déjà une instance Postgres pour autre chose ; choisissez un plan managé dès l'instant où la question « qui corrige ce serveur » n'a pas de réponse claire dans votre équipe.
