Feature flags : le levier qui découple votre déploiement de votre stratégie produit (et pourquoi vous en avez besoin plus tôt que vous ne le croyez)
Les feature flags séparent « mettre en production » de « rendre visible ». Un découplage technique qui devient vite une arme go-to-market — à condition de ne pas en faire une usine à gaz.
Un fondateur me raconte fièrement qu’il a « poussé la nouvelle feature en prod vendredi soir ». Le lundi, un client stratégique tombe dessus par accident, sans onboarding, sans contexte. La feature était à moitié finie. Le deal a pris trois semaines de retard.
Ce genre de scénario n’est pas un problème de code. C’est un problème de couplage : dans la plupart des startups early-stage, déployer et rendre visible sont la même action. On ne peut pas mettre du code en production sans que tout le monde le voie immédiatement. Et cette absence de découplage coûte bien plus cher qu’on ne le pense — pas en bugs, mais en options stratégiques perdues.
Le vrai problème : « en prod » ne devrait pas vouloir dire « visible »
Quand vous n’avez aucun mécanisme pour activer ou désactiver une fonctionnalité indépendamment du déploiement, chaque mise en production devient un événement à haut risque. Vous attendez que la feature soit « parfaite » avant de la merger, ce qui allonge les branches, multiplie les conflits Git, et repousse le moment de vérité. Résultat : vous testez vos hypothèses produit tard, sur un code que personne n’ose plus toucher.
Le feature flag — un simple interrupteur conditionnel dans votre code (if (flags.nouvelleUX) { ... }) — casse ce couplage. Le code part en production éteint. Vous l’allumez quand vous voulez, pour qui vous voulez. « Mettre en production » redevient une opération banale et fréquente. « Rendre visible » devient une décision produit, prise séparément, quand vous êtes prêt.
Cette distinction paraît technique. Elle est en réalité profondément stratégique, parce qu’elle vous rend trois capacités que la plupart des startups n’ont pas.
Trois capacités que le flag vous rend — et qui sont business, pas tech
1. Tester une hypothèse sur un sous-ensemble d’utilisateurs
Vous pensez qu’un nouveau parcours d’onboarding va améliorer l’activation. Sans flag, vous le déployez pour tout le monde et vous priez. Avec un flag, vous l’activez pour 10 % des nouveaux comptes, vous comparez les taux d’activation sur deux semaines, et vous décidez avec des chiffres. Ce n’est pas de l’A/B testing sophistiqué à la Booking.com — c’est simplement la différence entre décider à l’instinct et décider avec un signal.
Pour une startup en recherche de product-market fit, cette capacité change la nature du jeu : vous transformez chaque release en expérimentation, sans reconstruire votre produit à chaque itération.
2. Vendre une feature avant qu’elle soit finie (proprement)
C’est le cas d’usage que les fondateurs sous-estiment le plus. Un flag est aussi un mécanisme de provisionnement par client. Vous préparez une démo pour un prospect qui a besoin d’une intégration spécifique ? Vous l’activez uniquement pour son compte de démo. Un client B2B accepte de payer plus pour un accès anticipé à une fonctionnalité premium ? Le flag devient votre système d’entitlements, avant même que vous ayez construit un vrai module de facturation par plan.
La liaison stratégie/tech est directe ici : votre motion de vente early-stage repose souvent sur des promesses et des accès sur-mesure. Un système de flags simple vous permet de tenir ces promesses sans forker votre codebase pour chaque client — le piège qui fragmente votre produit et détruit votre marge.
3. Éteindre un incendie sans redéployer
À 22h, une feature récente génère des erreurs en cascade. Sans flag, votre seule option est un rollback complet ou un hotfix en urgence — avec toute la pression que ça implique sur une équipe de trois personnes. Avec un flag, vous coupez la fonctionnalité fautive en une requête, le reste du produit continue de tourner, et vous debuggez à froid le lendemain. C’est un « kill switch » qui transforme un incident P1 en non-événement. Sur un runway limité, ne pas cramer une nuit et le moral de l’équipe a une valeur concrète.
Le piège inverse : la plateforme de flags qui devient votre dette
Maintenant, le contre-argument honnête. Les feature flags ont un coût, et il est réel : chaque flag est une branche conditionnelle qui vit dans votre code. Multipliez les flags sans discipline, et vous obtenez un produit où le comportement dépend d’une combinatoire d’interrupteurs que plus personne ne comprend. Vous ne testez plus une seule application, mais 2^n applications potentielles.
Le pattern à éviter : la startup qui, séduite par le concept, adopte une plateforme de flags enterprise (LaunchDarkly et consorts) à trois développeurs, paie un abonnement qui pèse sur le runway, et se retrouve avec des centaines de flags morts jamais nettoyés. On a remplacé un problème de déploiement par un problème de gouvernance.
La nuance qui sauve : il faut distinguer les types de flags par leur durée de vie. Un flag de release (« ce code est-il actif ? ») doit mourir dès que la feature est stabilisée pour tous — sa suppression fait partie de la définition de « terminé ». Un flag d’expérimentation (« quel variant ? ») meurt quand l’expérience est conclue. Seuls les flags d’entitlement (« ce client a-t-il accès à ce plan ? ») ont vocation à rester longtemps — et ceux-là, à terme, migrent vers votre logique de facturation. Confondre ces trois natures, c’est comment on accumule la dette.
Ce qu’il faut vraiment faire, selon votre stade
En pre-seed, n’installez surtout pas de plateforme. Une simple colonne booléenne en base, ou même une variable d’environnement, suffit pour vos premiers kill switches et vos démos client. Le principe (« déployer ≠ visible ») compte infiniment plus que l’outil. La règle d’or : tout flag que vous créez, notez-vous quand vous le supprimerez.
En seed, quand vous commencez à faire des expérimentations d’activation et à gérer des accès différenciés par client, structurez un petit service maison : une table flags avec un ciblage par utilisateur, par compte, ou par pourcentage. Ajoutez une convention d’équipe stricte sur le nettoyage — un flag de release qui traîne plus de deux sprints après son déploiement à 100 % est un bug de process. C’est le moment où le flag devient aussi un levier commercial assumé.
En série A, avec une équipe produit multiple et des besoins d’A/B testing statistiquement sérieux, l’outil externe se justifie enfin. Vous avez le volume d’utilisateurs pour que les tests aient du sens, et le nombre de développeurs pour que la coordination via une plateforme dédiée rapporte plus qu’elle ne coûte. À ce stade, vous liez souvent les flags à votre product analytics pour mesurer l’impact réel de chaque variant sur vos métriques nord.
Dans tous les cas, un principe traverse les stades : un flag est une dette temporaire que vous contractez sciemment. Le flag lui-même n’est pas le livrable. Le livrable, c’est la décision qu’il vous permet de prendre — puis sa disparition.
La bonne question à se poser
La plupart des startups n’ont pas un problème de vitesse de code. Elles ont un problème de vitesse de décision : elles construisent longtemps avant de savoir si ça marche, et elles exposent trop tôt ce qui n’est pas prêt. Le feature flag, bien utilisé, attaque exactement cette contrainte-là — il vous donne le droit de mettre en production sans vous engager, et de décider plus tard avec des données.
Alors la question n’est pas « avons-nous besoin d’une plateforme de feature flags ? ». C’est : combien de vos décisions produit du trimestre dernier auriez-vous prises différemment si vous aviez pu les tester sur 10 % de vos utilisateurs avant de les généraliser ?