Feature flags : déployer n’est pas livrer

Dans beaucoup d'équipes, deux mots sont utilisés comme synonymes : déployer et livrer. On « met en prod » une fonctionnalité, et à la seconde où le code arrive sur les serveurs, les utilisateurs la voient. C'est simple, c'est intuitif. Et c'est la source d'une bonne partie du stress des jours de mise en production. Et si ces deux moments n'avaient aucune raison d'être le même ?

Deux gestes, deux décisions

Déployer, c'est un acte technique : faire tourner une nouvelle version du code en production. Livrer, c'est un acte produit : rendre une fonctionnalité accessible à des utilisateurs. Le premier regarde l'équipe technique. Le second regarde le métier, le marketing, parfois le service client. Les feature flags (ou feature toggles) permettent de séparer les deux. Le principe tient en une ligne : le nouveau code est bien en production, mais enveloppé dans une condition qu'on peut activer ou désactiver sans redéployer.

Quatre lignes, et tout change.

Ce que ça débloque

Le déploiement devient banal. Si le code nouveau est éteint par défaut, le mettre en production ne présente presque plus de risque. On peut déployer le mardi à 15 h, plusieurs fois par jour, sans cellule de crise ni astreinte renforcée. Le retour arrière prend une seconde. Un problème sur la nouvelle fonctionnalité ? On coupe le flag. Pas de rollback, pas de pipeline à relancer, pas de hotfix en urgence. L'ancienne version reprend la main instantanément. On livre progressivement. D'abord l'équipe interne, puis 5 % des utilisateurs, puis 25 %, puis tout le monde. Si les indicateurs se dégradent à 5 %, on a protégé les 95 % restants. On fusionne tôt. Une fonctionnalité qui prend trois semaines n'a plus besoin de vivre sur une branche à part qui diverge chaque jour un peu plus. Elle avance dans la branche principale, cachée derrière son flag, et les conflits de fusion géants disparaissent. Le métier reprend la main sur le calendrier. La fonctionnalité est prête depuis jeudi, mais le lancement commercial est lundi ? Aucun problème : elle attend, éteinte, en production, testée.

Tous les flags ne se ressemblent pas

Ranger tous les flags dans le même sac est l'erreur la plus courante. Il en existe en réalité quatre familles, avec des durées de vie très différentes :

Les deux premiers sont temporaires par nature. Les deux derniers sont des éléments de configuration à part entière. Les confondre, c'est garantir que les temporaires deviendront permanents.

Le revers : la dette de flags

Car voilà le piège. Un flag de livraison qu'on oublie de retirer après le lancement ne disparaît pas. Il reste là, avec ses deux branches de code, dont une morte. Multipliez par cinquante, et vous obtenez un code où personne ne sait plus quel chemin est réellement emprunté, ni ce qui se passerait si l'on basculait tel interrupteur. Quelques règles simples évitent la dérive :

Une date de péremption à la création. Chaque flag temporaire naît avec un propriétaire et une date de retrait prévue.
Le retrait fait partie de la fonctionnalité. Le ticket n'est pas terminé tant que le flag et l'ancien code n'ont pas été supprimés.
Un inventaire visible. Une liste des flags actifs, revue régulièrement, avec ceux qui ont dépassé leur date en tête.
Tester les deux états. Tant que le flag existe, les deux chemins doivent rester couverts par les tests.

Outil maison ou solution du marché ?

Un flag peut commencer comme une simple propriété de configuration. Mais dès qu'on veut cibler des utilisateurs, déployer par pourcentage ou couper un interrupteur sans redémarrer, mieux vaut un outil dédié. Il existe des solutions open source et des services hébergés ; le standard ouvert OpenFeature permet aussi d'écrire son code une fois, indépendamment du fournisseur choisi. Le bon choix dépend surtout du nombre d'équipes et du besoin de ciblage.

Ce qu'on en retient

Les feature flags ne sont pas une technique de développeur de plus. Ils changent la nature même d'une mise en production : d'un événement risqué qu'on redoute, à un geste routinier qu'on ne remarque plus. À une condition, les traiter comme ce qu'ils sont, du code temporaire avec une date de fin. Chez Olympp, on accompagne les équipes qui veulent livrer plus souvent sans livrer plus de stress. Et si vos jours de mise en prod ressemblent encore à des opérations commando, c'est une conversation qu'on aime avoir. Olympp, ingénierie augmentée. Déployer le mardi, livrer quand le métier le décide.