Feature flags expliqués :livrer masqué, lancer d'un clic

Feature flags expliqués : un feature flag est un interrupteur on/off stocké dans votre base de données plutôt que dans votre code. La fonctionnalité part en production masquée (déployée mais invisible), et vous la lancez plus tard en basculant l'interrupteur pour un client bêta, 10 % des utilisateurs ou tout le monde. Pas de redéploiement, pas de modification de code, pas de panique le jour du lancement.

Pour un fondateur solo, les flags font la différence entre un « lancement » qui est un déploiement terrifiant et un « lancement » qui est une décision que l'on prend autour d'un café. Voici comment ils fonctionnent, les quatre usages que vous en aurez vraiment, et les erreurs qui les font se retourner contre vous.

Feature flags expliqués : ce qu'est vraiment un feature flag

Sans flags, contrôler qui voit une fonctionnalité revient à modifier du code. Le bricolage classique ressemble à ceci : « si l'e-mail de l'utilisateur se termine par le domaine du client bêta, afficher la nouvelle fonctionnalité ». Chaque changement de cette règle est une modification de code, et chaque modification de code est un déploiement. La configuration vit à cinq endroits différents, rien n'a de piste d'audit, et la personne qui peut basculer l'interrupteur est celle qui sait où se cache le bricolage.

Un feature flag déplace cette décision dans les données. Le flag est un interrupteur nommé (« new_dashboard: off ») stocké dans votre système de paramètres, à côté de choses comme le fuseau horaire et le thème. Votre code pose une seule question : ce flag est-il activé pour cet utilisateur ? Changez la réponse dans un tableau de bord et le produit change de comportement instantanément, sans déploiement. Les flags s'inscrivent dans la même hiérarchie que le reste de vos paramètres : une valeur par défaut globale, modifiable par organisation, modifiable par utilisateur.

Livrer masqué, lancer d'un interrupteur

Le grand déclic mental, c'est que déployer et lancer sont deux événements différents, et que les flags sont ce qui les sépare.

Déployer, c'est que votre code a atteint le serveur. Lancer, c'est que les utilisateurs peuvent le voir. Sans flags, c'est le même instant, ce qui explique pourquoi les lancements paraissent dangereux et pourquoi des fondateurs gardent du travail terminé pendant des semaines en attendant le « bon » jour. Avec les flags, vous déployez la fonctionnalité à moitié construite, masquée, dix fois si vous voulez. Elle voyage avec chaque version, testée en production, visible de vous seul. Quand elle est prête, lancer est un interrupteur, et si déployer vous fait encore peur, c'est le schéma qui supprime l'essentiel de cette peur.

Cela change aussi votre marketing. Quand lancer ne coûte rien, vous cessez de tout parier sur un grand jour et commencez à livrer un flux de petites versions protégées par des flags, le moteur des micro-lancements.

Les quatre usages que les fondateurs en font vraiment

Remarquez que ce sont des outils de produit et de marketing autant que d'ingénierie. L'accès bêta est une conversation commerciale (« envie d'un accès anticipé ? »). Le déploiement progressif est de la gestion du risque. Le test A/B est de l'optimisation de page de tarifs. Le coupe-circuit est une assurance sommeil.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

L'argument de 2 h 47 du matin pour les flags

Une histoire vraie de mon propre système en production : 2 h 47 du matin, mon téléphone vibre avec une alerte de taux d'erreur. Un endpoint échoue, des utilisateurs sont touchés. Deux options : déboguer à moitié endormi, ou revenir à la version précédente en deux clics. J'ai fait le retour arrière. Réglé en 90 secondes, retour au lit, débogage en bonne et due forme le matin.

Un retour arrière est un instrument grossier : il annule tout dans cette version, la fonctionnalité cassée et les trois bonnes livrées avec elle. Un feature flag est chirurgical. Si l'élément cassé est derrière un flag, vous coupez uniquement cette fonctionnalité et laissez le reste de la version tourner. Dans le meilleur des cas, vous n'avez jamais à faire le choix de 2 h 47 : grâce au déploiement progressif, seuls 10 % des utilisateurs ont vu le bug, le flag a été coupé, et la plupart de vos clients n'ont jamais su qu'il s'était passé quelque chose.

Les erreurs qui font se retourner les flags contre vous

• Pas de valeur par défaut. Vous ajoutez un nouveau flag sans jamais définir ce qu'il signifie pour les utilisateurs existants : ils reçoivent une réponse indéfinie et l'application se comporte de façons que vous ne pouvez pas reproduire. Chaque flag part avec une valeur par défaut explicite.
• Pas de piste d'audit. Le produit se comporte soudain différemment et personne ne sait qui a basculé quoi, ni quand. Chaque changement de flag doit enregistrer qui, quoi, ancienne valeur, nouvelle valeur, horodatage : des flags sans historique sont un cauchemar de débogage.
• N'importe qui peut tout basculer. Les flags sont des commandes de production. Modifier un flag au niveau de l'organisation doit exiger des droits d'administrateur, exactement comme modifier la facturation de l'organisation.
• Vérifier le flag par une requête en base à chaque requête. Les vérifications de flags ont lieu en permanence ; elles doivent venir d'un cache qui se rafraîchit quand le flag change, pas d'une nouvelle requête à chaque chargement de page.

Faut-il des flags dès le premier jour ?

Plus tôt qu'on ne le croit. Vous n'avez pas besoin d'un produit de flags sophistiqué : une table de flags dans votre propre base de données, gérée depuis un écran d'administration simple, est le schéma qui fait tourner cela à n'importe quelle échelle. Cela fait partie de votre système de paramètres, que l'IA construit vite à partir d'une bonne spécification ; la mécanique des flags elle-même représente quelques heures de travail, pas un projet.

Le bénéfice commence dès votre première fonctionnalité qui fait peur. La première fois que vous livrez quelque chose masqué un mardi, le testez en production toute la semaine et le « lancez » le lundi en basculant un interrupteur, vous vous demanderez comment on peut construire seul sans cela.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Questions fréquentes

Quelle est la différence entre un feature flag et un paramètre ?

Un paramètre stocke une préférence : fuseau horaire, thème, devise. Un feature flag stocke une décision de disponibilité : cette fonctionnalité est-elle activée, et pour qui ? Ils vivent dans le même système hiérarchique (valeur par défaut globale, surcharge par organisation, surcharge par utilisateur), c'est pourquoi la mécanique des flags est généralement construite comme partie de votre système de paramètres.

Quelle est la différence entre un feature flag et un retour arrière ?

Un retour arrière ramène tout votre déploiement à la version précédente : efficace, mais il emporte les bons changements avec les mauvais. Un flag coupe une fonctionnalité précise et laisse tout le reste tourner. Il vous faut les deux : le retour arrière comme frein d'urgence, les flags comme commande de précision à laquelle on recourt en premier.

Les feature flags ralentissent-ils l'application ?

Pas s'ils sont mis en cache. La vérification du flag a lieu en permanence, donc la réponse doit venir d'un cache qui se rafraîchit quand un flag change, jamais d'une nouvelle requête en base à chaque chargement de page. Bien fait, le coût est quasi nul.

Un fondateur non technique peut-il gérer des feature flags ?

C'est tout l'intérêt. Les flags sortent les décisions de lancement du code pour les mettre dans un tableau de bord : vous décidez qui voit quoi, et quand, sans toucher à un déploiement. Vous pilotez le déploiement (10 % aujourd'hui, tout le monde lundi) comme vous programmeriez une newsletter.