Feature flags : le levier tech qui découple votre vitesse de livraison de votre vitesse de décision produit

Votre équipe a fini une fonctionnalité vendredi. Elle sera en production dans deux semaines, parce que le commercial veut la présenter à un gros prospect le même jour, parce que le marketing prépare une annonce, et parce que personne n’ose déployer avant d’être sûr que tout est aligné. Pendant ce temps, le code prend la poussière dans une branche, se désynchronise du reste, et le mérite d’avoir livré vite disparaît dans l’attente.

Ce goulot n’est pas un problème de développement. C’est un problème de couplage : dans la plupart des jeunes startups, déployer du code et rendre une fonctionnalité visible sont un seul et même acte. Les feature flags cassent ce couplage. Et derrière ce qui ressemble à une astuce technique se cache une décision d’organisation qui touche vos ventes, votre gestion du risque et la vitesse à laquelle vous apprenez de vos utilisateurs.

Le vrai problème : vous confondez « livrer » et « décider »

Livrer du code, c’est une décision d’ingénierie : le code est prêt, testé, il part en production. Décider qu’une fonctionnalité est visible pour tel utilisateur, c’est une décision produit ou commerciale. Ce sont deux temporalités différentes, portées par des personnes différentes, avec des contraintes différentes.

Quand ces deux décisions sont fusionnées, chacune bloque l’autre. Le produit attend que la tech déploie ; la tech attend que le produit valide le timing. Résultat : des grosses branches qui vivent trois semaines, des « big bang releases » risquées où dix changements partent en même temps, et une incapacité à répondre vite à un client qui demande « est-ce qu’on peut désactiver ce truc juste pour nous ? ».

Un feature flag, c’est simplement un interrupteur dans le code : if (flags.nouveauCheckout) { ... }. Le code de la nouvelle fonctionnalité part en production, mais reste éteint. On l’allume quand on veut, pour qui on veut, sans redéployer. La conséquence est plus profonde qu’elle n’en a l’air : la tech peut fusionner et déployer en continu (petits incréments, moins de risque), pendant que le produit garde la main sur le « quand » et le « pour qui ».

Trois usages, souvent confondus, à ne surtout pas mélanger

Le mot « feature flag » recouvre au moins trois choses qui n’ont ni la même durée de vie ni les mêmes exigences. Les confondre est la première erreur.

Le flag de release

Il sert à cacher une fonctionnalité pas encore finie ou pas encore annoncée. Sa durée de vie est courte : quelques jours à quelques semaines. Dès que la fonctionnalité est allumée pour tout le monde et stable, le flag doit être retiré du code. C’est le point que tout le monde oublie, et c’est là que la dette s’accumule : un an plus tard, vous avez 80 flags dont personne ne sait s’ils sont encore actifs, avec des if imbriqués qui rendent le code illisible. Un flag de release qui traîne est une dette technique, pas une fonctionnalité.

Le flag d’expérimentation

Il sert à tester : A/B testing, rollout progressif (5 % des utilisateurs, puis 25 %, puis 100 % en surveillant les métriques et les erreurs). Sa valeur est de dérisquer. Si le nouveau tunnel de paiement fait chuter la conversion, vous le voyez sur 5 % des utilisateurs et vous coupez en une seconde — sans rollback, sans redéploiement, sans incident. Pour une startup avec peu de marge d’erreur, c’est ce qui transforme un déploiement stressant en non-événement.

Le flag de permission

Il sert à activer une fonctionnalité selon le plan tarifaire ou le client (« la feature X n’est dispo qu’en offre Business »). Celui-là ne disparaîtra jamais : c’est de la logique métier permanente. Il ne devrait donc pas vivre dans le même système que vos flags de release. Le mélanger avec le reste, c’est se retrouver incapable de faire le ménage, parce qu’on n’ose plus supprimer un flag de peur de casser la facturation d’un client.

La règle simple : un flag temporaire et un flag permanent ne se gèrent pas au même endroit, et ne se nomment pas pareil. Si vous ne devez retenir qu’une chose, c’est celle-là.

Le lien business qu’on ne voit pas venir

Là où les feature flags deviennent stratégiques, c’est au contact du commercial et du support.

Un prospect B2B important demande une fonctionnalité en avant-première, ou veut au contraire désactiver un comportement qui perturbe son équipe. Sans flags, votre seule réponse est « on va voir dans la roadmap », ce qui veut dire « dans six semaines et un déploiement ». Avec des flags par client (ou par organisation), votre commercial peut promettre un pilote sur mesure sans mobiliser l’équipe tech pour chaque cas. C’est la différence entre un deal qui se signe cette semaine et un deal qui refroidit.

Le revers existe, et il faut le nommer : chaque flag par client est une variante de votre produit. Multipliez-les et vous obtenez une matrice combinatoire impossible à tester, où « ça marche » ne veut plus rien dire car ça dépend de quels flags sont allumés chez qui. Le même outil qui accélère vos ventes peut fragmenter votre produit — exactement comme une feature sur-mesure accordée trop vite. Les flags rendent la promesse facile ; ils ne rendent pas la maintenance gratuite. Un flag client doit être une exception assumée et datée, pas la réponse par défaut du commercial.

Ce qu’il faut vraiment faire, selon votre stade

En pre-seed, n’installez pas de plateforme de feature flags. C’est de la sur-ingénierie. Un simple booléen dans votre configuration, ou une variable d’environnement, suffit largement pour cacher une fonctionnalité en cours. À ce stade, votre contrainte n’est pas la sophistication de vos déploiements, c’est de trouver ce que les gens veulent. Un const SHOW_NEW_X = false dans le code fait le travail. Ne payez pas pour un problème que vous n’avez pas encore.

En seed, quand vous avez une petite équipe qui déploie plusieurs fois par semaine et de vrais clients en production, adoptez une convention légère. Une table en base ou un fichier de config centralisé listant vos flags, avec une règle non négociable : chaque flag de release a une date d’expiration et un propriétaire. Passé cette date, soit on l’allume définitivement et on retire le code, soit on l’abandonne. C’est le moment aussi de séparer clairement les flags temporaires (release, test) des flags permanents (permissions, pricing), qui eux relèvent de votre logique de facturation. Vous n’avez pas encore besoin d’un outil externe.

Vers la série A, quand plusieurs équipes déploient en parallèle et que le rollout progressif devient un besoin de fiabilité (vous ne pouvez plus vous permettre un incident qui touche 100 % des clients d’un coup), une solution dédiée — qu’elle soit open source comme Unleash ou managée comme LaunchDarkly — se justifie. Vous y gagnez le ciblage fin, l’historique des changements (précieux en cas de post-mortem), et surtout une gouvernance : qui a le droit d’allumer quoi, en production. À ce stade, un flag mal géré ne fait plus perdre du temps, il fait tomber le produit.

La discipline invisible qui fait toute la différence

L’outil compte moins que l’hygiène. Une startup avec trois flags bien tenus est en meilleure santé qu’une startup avec une plateforme flambant neuve et cent flags fantômes. La règle qui sépare les deux tient en une phrase : un flag temporaire qu’on ne retire pas devient de la dette technique déguisée en fonctionnalité.

Concrètement, ajoutez le nettoyage des flags à votre routine — une revue mensuelle de dix minutes suffit. Chaque flag doit répondre à trois questions : est-il encore utile, qui en est responsable, et quelle est sa date de sortie ? Ceux qui ne répondent pas disparaissent. Cette discipline coûte peu et vous évite le scénario où, dans dix-huit mois, personne n’ose plus toucher au code parce qu’on ne comprend plus quel if fait quoi.

Les feature flags ne rendent pas votre équipe plus rapide par magie. Ils déplacent le pouvoir de décision : la tech reprend la main sur le rythme de déploiement, le produit reprend la main sur le rythme de visibilité, et le commercial gagne une marge de manœuvre réelle. Reste une question que peu de fondateurs se posent avant qu’il ne soit trop tard : dans votre équipe, qui a aujourd’hui le droit d’allumer une fonctionnalité en production pour un vrai client — et est-ce vraiment la bonne personne ?