Les feature flags permettent d’activer ou de désactiver une fonctionnalité déjà présente dans une application, sans modifier son code à chaque bascule. Pour un SaaS B2B, notre recommandation est de commencer par une configuration simple si les besoins restent limités, puis d’adopter une solution dédiée lorsque le ciblage client, la traçabilité et l’exploitation deviennent critiques. Cette séparation entre livraison du code et activation fonctionnelle est décrite dans l’article de référence de Pete Hodgson sur les feature toggles. (martinfowler.com)
Le véritable arbitrage n’est pas « une condition dans le code ou un abonnement ». Il consiste à décider qui portera la responsabilité d’une commande capable de modifier le comportement de votre production. Voici comment comparer développement interne, solution auto-hébergée et service managé, sans construire une plateforme disproportionnée.
Quand les feature flags deviennent-ils utiles pour un SaaS ?
Les feature flags deviennent pertinents lorsque vous devez dissocier le déploiement technique de l’ouverture aux utilisateurs. Avant de choisir un outil, identifiez une décision d’activation concrète : ouvrir une nouveauté à un client pilote, interrompre une intégration défaillante ou remplacer progressivement un parcours.
Prenons un exemple fictif : un éditeur de logiciel de maintenance prépare une nouvelle planification des interventions. Un client accepte de la tester, tandis que les autres souhaitent conserver leur fonctionnement habituel. Le besoin n’est pas de maintenir deux versions de l’application, mais de sélectionner le parcours autorisé pour chaque organisation.
Nous conseillons de distinguer trois usages dès le cadrage :
- Livraison progressive : exposer une nouveauté à une population définie avant son ouverture générale.
- Commande opérationnelle : suspendre une fonction non indispensable, par exemple un enrichissement externe, tout en conservant le service principal.
- Expérimentation : comparer des variantes avec un protocole de mesure explicite.
Ces usages ne demandent pas nécessairement les mêmes outils. Si votre objectif consiste seulement à autoriser un parcours pour quelques clients pilotes, n’achetez pas une plateforme d’expérimentation statistique par anticipation.
Dans un projet de conception ou d’évolution d’un SaaS, inscrivez donc le besoin dans les critères de livraison : qui active, pour quelle population, avec quelle possibilité de retour et quelle preuve de bon fonctionnement ?
Développer, auto-héberger ou acheter : quelle option choisir ?
Privilégiez une configuration interne pour un besoin volontairement restreint, une solution auto-hébergée si vous souhaitez maîtriser l’infrastructure et pouvez l’exploiter, ou un service managé si votre priorité est de déléguer cette exploitation. La taille de l’équipe compte, mais la criticité et la diversité des usages doivent peser davantage.
| Option | Contexte favorable | Responsabilité à conserver | Limite à accepter |
|---|---|---|---|
| Configuration interne limitée | Une application, quelques activations techniques, règles simples | Conception, tests, administration, historique et maintenance | Refuser les demandes qui transformeraient le dispositif en produit interne |
| Solution dédiée auto-hébergée | Exigence de maîtrise de l’hébergement, équipe capable d’exploiter le service | Mises à jour, sauvegardes, supervision, disponibilité et contrôle des accès | Assumer une brique supplémentaire dans le système d’information |
| Service managé | Plusieurs équipes utilisatrices, délai contraint, faible capacité d’exploitation disponible | Intégration, règles de ciblage, sécurité applicative et gestion du contrat | Accepter une dépendance fournisseur et vérifier le coût à votre échelle |
Le développement interne doit avoir une frontière écrite
Une configuration versionnée ou une table de paramètres peut constituer un choix raisonnable. Notre conseil est de limiter explicitement le périmètre : valeurs booléennes, environnements séparés, ciblage par organisation et modification réservée aux personnes habilitées.
Fixez également les déclencheurs d’un nouvel arbitrage. Par exemple : le support doit pouvoir agir sans développeur, les modifications nécessitent une approbation ou plusieurs applications doivent partager les mêmes règles. Ces demandes signalent un changement de périmètre, pas simplement « un écran d’administration à ajouter ».
L’auto-hébergement ne dispense pas de vérifier l’édition
Pour une solution auto-hébergée, exigez une démonstration des fonctions nécessaires dans l’édition effectivement envisagée : droits d’administration, historique, restauration et séparation des environnements. Faites préciser les conditions de licence et de support dans votre comparaison, plutôt que de déduire les capacités disponibles d’une page de présentation générale.
Le service managé ne délègue pas votre décision produit
Même avec un fournisseur, votre équipe reste responsable du sens des règles. Un outil ne peut pas déterminer à votre place si une organisation est éligible à une bêta, si un traitement déjà engagé doit continuer ou si une activation nécessite l’accord du client.
Choisir l’architecture avant de comparer les tableaux de bord
Où la décision est-elle évaluée ?
Vérifiez si votre application évalue les règles localement à partir d’une configuration synchronisée, ou si elle sollicite un service distant. La documentation d’Unleash distingue notamment les SDK backend, qui évaluent localement, des SDK frontend, pour lesquels l’évaluation est réalisée par le serveur ou par Unleash Edge. Ce comportement doit être vérifié pour chaque SDK retenu, sans généraliser d’un environnement à l’autre. La documentation des SDK Unleash détaille cette architecture. (docs.getunleash.io)
Pour un parcours métier critique, nous recommandons d’éviter qu’une simple lecture de flag impose un appel réseau synchrone supplémentaire à chaque opération. Demandez en revanche quelle fraîcheur de configuration vous acceptez : un système qui continue à fonctionner avec une ancienne valeur peut ne pas appliquer immédiatement une désactivation d’urgence.
OpenFeature limite le couplage, pas le travail de migration
OpenFeature définit une interface d’évaluation et une abstraction de fournisseur appelée « provider ». L’application peut ainsi utiliser une API commune tandis que le provider assure la liaison avec le système de gestion des flags. C’est le rôle décrit dans la spécification officielle OpenFeature. (openfeature.dev)
Nous recommandons d’étudier cette abstraction lorsque plusieurs applications ou langages sont concernés. Ne la traitez toutefois pas comme une garantie de migration sans effort : exigez séparément un test de reprise des règles, des populations ciblées et des comportements de repli. Une API commune ne constitue pas, à elle seule, votre plan de sortie.
Dans un SaaS B2B, que faut-il cibler : utilisateur ou organisation ?
Pour une fonctionnalité qui modifie un processus partagé, privilégiez généralement un ciblage par organisation cliente. Réservez le ciblage individuel aux usages où deux collègues peuvent effectivement travailler avec des variantes différentes sans créer d’incohérence métier.
Dans notre exemple de planification, l’activation devrait concerner l’entreprise pilote plutôt qu’une sélection aléatoire de ses salariés. Le responsable d’exploitation et les techniciens doivent partager une compréhension cohérente du planning.
Écrivez avant l’intégration :
- La clé stable utilisée pour identifier l’organisation.
- Le traitement d’un utilisateur appartenant à plusieurs organisations.
- La règle appliquée aux tâches exécutées en arrière-plan.
- Le comportement attendu lorsque les attributs de ciblage manquent.
- La manière de conserver la même décision pendant une opération métier.
Unleash recommande notamment d’éviter les réévaluations incohérentes au cours d’une même requête et de centraliser autant que possible la décision. Utilisez cette recommandation comme point de contrôle pour vos parcours distribués, selon les bonnes pratiques de gestion des feature flags. (docs.getunleash.io)
Pour le contexte de ciblage, partez d’identifiants techniques et d’attributs strictement nécessaires. Demandez où ces données circulent et sont conservées : OpenFeature rappelle explicitement que le traitement du contexte dépend du provider utilisé dans sa documentation sur le contexte d’évaluation. (openfeature.dev)
Une désactivation n’est pas un retour arrière métier
Avant d’autoriser une bascule en production, demandez ce qu’elle annule réellement. Notre recommandation est de séparer l’arrêt des nouvelles opérations, le traitement des opérations engagées et la réparation éventuelle des données.
Dans le cas fictif du planning, revenir à l’ancien écran ne suffit pas si le nouveau moteur a déjà déplacé des interventions ou envoyé des notifications. Le mécanisme de désactivation doit donc être accompagné d’une procédure explicite :
- Empêcher l’entrée de nouvelles opérations dans le parcours concerné.
- Décider du sort des traitements en cours.
- Identifier les données déjà modifiées.
- Exécuter, si nécessaire, une correction ou une compensation métier.
Pour une évolution de schéma, exigez que l’ancien parcours reste compatible avec les données produites pendant le pilote. Le sujet rejoint alors la préparation d’une migration de base de données sans interruption, et ne doit plus être traité comme une simple option d’interface.
Testez une panne après synchronisation et un démarrage à froid
LaunchDarkly distingue les instances disposant déjà de valeurs en cache des nouvelles instances qui ne parviennent pas à récupérer leur configuration initiale. Sa documentation décrit l’usage du cache et des valeurs de repli, avec des particularités selon les SDK et les méthodes employées. Les recommandations de résilience de LaunchDarkly constituent une base utile pour construire vos essais. (support.launchdarkly.com)
Définissez une valeur sûre flag par flag. Pour une nouvelle interface, le repli peut être l’ancienne interface. Pour une fonction facultative dépendante d’un tiers, le repli peut être sa suspension. Évitez une convention globale « faux signifie sûr » : documentez le comportement métier attendu.
Combien coûte réellement une solution de feature flags ?
Comparez le coût total sur une durée commune, pas seulement l’abonnement ou la première implémentation. Le budget doit inclure l’intégration, les tests, l’exploitation, l’administration et la suppression des flags devenus inutiles.
Pour votre prévisionnel 2027, utilisez cette formule : coût total = mise en place + licence ou abonnement + infrastructure + temps récurrent + coût de sortie.
| Poste | Éléments à chiffrer | Facteurs de variation |
|---|---|---|
| Intégration | Applications, SDK, contexte client, valeurs de repli, instrumentation | Nombre de langages, architecture existante, criticité |
| Recette | Parcours actif et inactif, panne, ciblage, traitements asynchrones | Dépendances entre fonctions et effets sur les données |
| Exploitation | Supervision, mises à jour, sauvegardes, exercices de restauration | Responsabilités déléguées ou conservées |
| Administration | Gestion des accès, approbations, demandes du support, nettoyage | Nombre d’équipes et fréquence des changements |
| Sortie | Export, conversion des règles, validation et remplacement du SDK | Complexité du ciblage et couplage au fournisseur |
Voici un calcul illustratif, pas un tarif Novane ni une moyenne de marché. Avec une hypothèse de coût complet interne de 700 € par jour, une enveloppe de 5 à 10 jours de mise en place représente 3 500 à 7 000 €. Si vous provisionnez ensuite une demi-journée à une journée mensuelle, ajoutez 4 200 à 8 400 € par an, hors infrastructure et licence. Ces hypothèses doivent être remplacées par votre propre estimation de charge.
Pour une offre commerciale, demandez un chiffrage fondé sur vos volumes, vos environnements, vos utilisateurs administrateurs et les fonctions contractuellement nécessaires. Faites préciser l’unité facturée, les dépassements et le coût de croissance. Aucun tarif éditeur n’est repris ici : le montant pertinent est celui d’une offre vérifiée pour votre périmètre.
Qui doit pouvoir modifier les flags en production ?
Traitez une modification de flag comme un changement de production, avec un niveau de contrôle proportionné à son impact. Nous conseillons de distinguer l’activation d’une bêta, la suspension d’un service facultatif et le changement d’un traitement financier.
Attribuez à chaque flag un propriétaire, une finalité, une population cible, une valeur de repli et une condition de suppression. Pour un flag permanent d’exploitation, remplacez la date de suppression par une date de révision et un exercice périodique.
Un flag d’interface ne doit pas devenir votre contrôle d’accès. Conservez les vérifications d’autorisation côté serveur, y compris lorsque l’écran ou le bouton est masqué. Cette séparation suit les recommandations de l’OWASP : vérifier les permissions à chaque requête et ne pas dépendre des contrôles côté client. La fiche OWASP sur l’autorisation précise ces exigences. (cheatsheetseries.owasp.org)
Pour une activation sensible, exigez enfin une trace indiquant l’auteur, l’ancienne valeur, la nouvelle valeur, le périmètre et le motif. La question opérationnelle est simple : après un incident, pourrez-vous expliquer pourquoi ce client utilisait cette variante à cet instant ?
Valider la décision avec un pilote représentatif
Ne commencez pas par instrumenter toute l’application. Choisissez une fonction non critique, mais suffisamment représentative pour tester le ciblage par organisation, l’administration et le comportement en cas de panne.
Faites entrer les scénarios suivants dans votre plan de recette applicative :
- Seule l’organisation pilote accède au nouveau parcours.
- Le parcours historique fonctionne avec le flag désactivé.
- Un redémarrage sans accès au service de flags produit le comportement prévu.
- Une modification de règle n’altère pas une opération déjà engagée.
- Le support peut identifier la variante utilisée sans modifier les règles.
- Le flag et la branche temporaire peuvent être supprimés proprement.
Décidez ensuite sur des observations : temps réellement consacré à l’administration, capacité à diagnostiquer un problème et simplicité du nettoyage. Si le pilote révèle surtout un manque de tests ou une mauvaise séparation des parcours, corrigez ces problèmes avant de multiplier les flags.
Questions fréquentes
Faut-il utiliser les feature flags pour gérer les abonnements ?
Nous recommandons de conserver les droits souscrits dans une source de vérité commerciale distincte. Un flag peut servir à ouvrir progressivement une nouvelle offre, mais ne devrait pas constituer seul la preuve qu’un client a acheté une fonctionnalité.
Comment éviter les conflits entre plusieurs flags ?
Identifiez les fonctions qui partagent des données ou un même parcours. Pour celles-ci, définissez les combinaisons autorisées et refusez les états incompatibles. Si plusieurs flags doivent toujours évoluer ensemble, réexaminez leur découpage plutôt que d’ajouter des dépendances implicites.
Un déploiement progressif constitue-t-il automatiquement un test A/B ?
Non. Pour décider à partir d’un test A/B, prévoyez notamment une hypothèse, une répartition des populations, une métrique et une règle d’arrêt. Si votre objectif est seulement de limiter l’exposition à un défaut, présentez le dispositif comme un pilote de livraison, sans lui attribuer une conclusion expérimentale.
Choisir la responsabilité que votre équipe peut assumer
Pour vos feature flags SaaS, retenez la configuration interne tant que vous pouvez en maintenir une frontière simple. Préférez une solution dédiée lorsque le ciblage, la gouvernance et l’exploitation deviennent des besoins réguliers. Entre auto-hébergement et service managé, arbitrez sur la capacité opérationnelle disponible, pas seulement sur la facture visible.
Vous devez trancher pour une application existante ? La séance de consulting IT offerte par Novane permet d’examiner votre architecture et vos contraintes. Venez avec un parcours à déployer progressivement, vos exigences de repli et les personnes qui devront piloter les activations.
