Feature flags en startup : le levier de vélocité que vous confondez encore avec un outil de grosse boîte

Un fondateur technique me racontait récemment qu’il avait repoussé une release de deux jours parce qu’une fonctionnalité “presque finie” bloquait tout le reste de la branche. Le code était mergé, testé, prêt — sauf ce bout-là. Résultat : trois correctifs urgents coincés derrière une feature que personne n’attendait vraiment. Ce n’est pas un problème de code. C’est un problème de couplage entre déployer et exposer.

Le malentendu de départ

Beaucoup de fondateurs rangent les feature flags dans la même case que Kubernetes ou le monitoring APM : un truc qu’on met en place “quand on sera gros”. C’est une erreur de catégorie. Un flag, dans sa forme la plus simple, c’est un if piloté par une configuration : if (flags.nouvellePage) { ... }. Vous n’avez besoin ni d’un SaaS à 500 € par mois, ni d’une équipe plateforme pour ça.

Ce que le flag résout n’est pas un problème d’échelle, c’est un problème de découplage. Sans flag, déployer du code en production, c’est le montrer à vos utilisateurs au même instant. Ces deux actions — mettre le code sur le serveur et rendre la fonctionnalité visible — sont pourtant deux décisions distinctes, avec des risques distincts. Les fusionner, c’est se condamner à ne déployer que ce qui est parfaitement terminé, et à tout tester en une seule fois, sous pression, le jour de la mise en ligne.

La startup qui n’utilise pas de flags finit presque toujours par recréer le problème autrement : des branches Git qui vivent trois semaines, des “grosses releases” du vendredi, un environnement de staging qui diverge de la prod, et cette phrase qu’on entend partout — “on attend d’avoir fini la feature X pour déployer”. Chacun de ces symptômes est une conséquence directe du couplage entre déploiement et release.

Ce que ça change concrètement pour une équipe de trois personnes

Prenons un cas réaliste. Vous refondez votre onboarding. C’est un chantier de deux semaines qui touche l’inscription, les emails, l’écran d’accueil. Sans flag, vous avez deux mauvaises options : soit vous travaillez sur une longue branche isolée qui va devenir un enfer à merger, soit vous bloquez toute autre livraison pendant deux semaines.

Avec un flag, vous mergez votre code au fil de l’eau — incomplet, mais inerte, caché derrière flags.nouvelOnboarding qui vaut false en production. Vos correctifs et vos autres features continuent de partir en prod normalement. Le jour où l’onboarding est prêt, vous ne déployez rien : vous basculez une valeur. Et si ça casse, vous rebasculez en dix secondes — sans rollback de déploiement, sans revert Git en catastrophe à 22 h.

Ce dernier point est le plus sous-estimé. Un flag transforme un incident potentiel en non-événement. Le kill switch — un flag dédié à couper une fonctionnalité qui déraille — vaut à lui seul l’investissement. Quand votre intégration de paiement se met à renvoyer des erreurs à cause d’un changement d’API côté Stripe, désactiver la nouvelle logique d’un clic plutôt que de redéployer l’ancienne version fait la différence entre dix minutes de gêne et une soirée de guerre.

Les trois usages qui comptent (et celui à éviter)

Tous les flags ne se valent pas, et confondre leurs durées de vie est la principale source de dette.

Le premier usage, c’est le flag de release : il cache une fonctionnalité en cours jusqu’à ce qu’elle soit prête. Sa durée de vie est courte — quelques jours, quelques semaines — et il est fait pour mourir. Une fois la feature exposée à tous, on retire le flag et le code mort qui va avec.

Le deuxième, c’est le rollout progressif : vous exposez la nouveauté à 5 % des utilisateurs, vous regardez vos métriques et vos logs d’erreur, puis vous montez à 25 %, 50 %, 100 %. C’est votre filet de sécurité pour tout ce qui touche à la performance ou à un flux critique. En France, sur du B2B SaaS avec des clients qui ont des attentes de disponibilité fortes, c’est aussi une manière de tenir vos engagements sans jouer votre réputation à chaque déploiement.

Le troisième, c’est le flag de permission ou de plan : “cette fonctionnalité est réservée au plan Pro”, “ce client bêta a accès à l’export avancé”. Attention, celui-là n’est pas vraiment un flag de déploiement — c’est de la logique métier. À terme, il a vocation à vivre dans votre modèle de données (droits, plans, entitlements), pas dans un fichier de config. Le confondre avec un flag technique, c’est se retrouver avec des règles de facturation dispersées dans des if un peu partout.

L’anti-pattern à fuir : le flag qu’on n’enlève jamais. Chaque flag actif est un chemin de code en plus à tester, une branche conditionnelle qui complexifie le raisonnement. Cinquante flags oubliés, et votre base de code a 2⁵⁰ états théoriques possibles. Un flag sans date de mort programmée n’est pas un outil de vélocité, c’est de la dette technique déguisée.

Ce qu’il faut vraiment faire, selon votre stade

En pre-seed, ne sur-ingénierez rien. Un simple objet de configuration ou quelques variables d’environnement suffisent : NOUVEL_ONBOARDING=false. Ce que vous voulez, c’est la discipline de séparer déploiement et release, pas un outil. Mais posez dès maintenant une règle simple : tout flag est noté quelque part avec une date de suppression prévue. C’est du travail de tenue de maison qui coûte cinq minutes et évite des mois de confusion.

Au seed, quand vous commencez à avoir des utilisateurs qui comptent et une équipe qui livre plusieurs fois par semaine, industrialisez un minimum. Une petite couche maison qui lit les flags depuis votre base et permet un rollout par pourcentage d’utilisateurs couvre 90 % des besoins. Des solutions open source comme Unleash (que vous pouvez héberger vous-même, ce qui répond au passage à des exigences RGPD sur la localisation des données) évitent de réinventer la roue. Le critère de décision n’est pas “est-ce que c’est gros”, c’est “est-ce que gérer les flags à la main commence à me coûter du temps”.

En série A, les flags deviennent un outil d’organisation autant que de technique. Plusieurs équipes livrent en parallèle, et le trunk-based development couplé aux flags permet à tout le monde de merger sur la branche principale sans se marcher dessus. C’est aussi le moment où un SaaS dédié (LaunchDarkly et consorts) peut se justifier — pas pour le prestige, mais parce que le ciblage fin, l’audit et la gestion des permissions d’accès aux flags deviennent des vrais sujets. Faites ce calcul comme un arbitrage build vs buy, pas comme un réflexe.

Le vrai enjeu est culturel, pas technique

La liaison stratégique est là : votre vitesse de livraison conditionne votre capacité à apprendre de votre marché. Une startup qui ne peut tester une idée qu’à travers une grosse release mensuelle apprend douze fois par an. Une startup qui déploie en continu et bascule des flags à la demande peut tester une hypothèse, la mesurer, l’ajuster — plusieurs fois par semaine. À runway égal, ce n’est pas la même quantité d’apprentissage produit.

Mais les flags ne remplacent pas la discipline. Ils la rendent possible sans la garantir. Une équipe qui accumule les flags sans jamais les nettoyer se retrouve avec un produit plus fragile qu’avant. L’outil suit la rigueur ; il ne la crée pas.

La vraie question à vous poser n’est donc pas “ai-je besoin de feature flags ?” — vous en avez déjà besoin dès que vous avez des utilisateurs et un rythme de livraison régulier. Elle est plutôt : combien de fois, ce trimestre, avez-vous repoussé une mise en ligne parce que déployer signifiait exposer ? Chacune de ces fois est un signal que le couplage vous coûte déjà de la vélocité — bien avant d’être une “grosse boîte”.