Jusqu’à l’AFUP Day 2025, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Les feature flags : le couteau suisse de votre flow de développement Les features flags sont une technique permettant d'activer ou désactiver à la demande certaines fonctionnalités d'une application. Ils permettent non seulement de rendre les mises en production moins effrayantes, séparant le déploiement du livrable et l'activation des nouvelles fonctionnalités mais aussi de simplifier le flow de développement, en permettant de livrer des features non finalisées. Au travers d'exemples concrets, nous verrons comment mettre en place les features flags, ce qu'ils peuvent apporter, mais également les dérives auxquels ils peuvent aboutir et les manières de les éviter.

Maurice 16/05/2025 11:15-11:55

On peut imaginer des usages purement techniques des feature flags, tel qu’interdire une feature en pre-production mais l’autoriser en production. Recommandes-tu ce genre de pratique ?

Oui ! Activer un flag ou non en fonction des environnements est très utile, par exemple pour prototyper une fonctionnalité en développement sans qu’elle soit visible en production. Utiliser des feature flags pour masquer des features en cours de développement ou de test permet d’éviter une gestion de branches qui peut parfois être laborieuse.

On peut même aller plus loin en activant des flags uniquement pour certains utilisateurs sur un environnement donné, pour faire en sorte qu’une partie de l’équipe travaille sur une version « iso-production », tandis que l’autre prépare déjà les fonctionnalités de demain.

De ton point de vue et avec ton expérience, dirais-tu qu’un feature flag est quelque chose de très temporaire ou bien peut-il être maintenu dans le temps ?

Selon moi, les features flags doivent généralement avoir une durée de vie très limitée. Si l’on ne s’astreint pas à les supprimer régulièrement, on peut vite aboutir à un code truffé de if / else très difficile à comprendre, à maintenir et à tester.

Il existe cependant quelques exceptions, par exemple un flag permettant la mise en maintenance de tout ou partie d’une application, qui peut être activé dès que l’on détecte un problème technique impactant trop fortement l’expérience utilisateur.

Après ton talk, on va certainement tous faire des feature flags dans nos applications et la liste peut rapidement s’agrandir ! As-tu des recommandations concernant la documentation de ces feature flags ? Qui fait quoi, etc ?

Ma première recommandation serait de commencer doucement en n’introduisant que quelques flags d’un coup pour éprouver l’usage et l’apport de cette technique.

Dans un second temps, si le nombre de flags est amené à se multiplier, l’utilisation d’une brique dédiée pour gérer les flags peut aider.

Des briques de ce type aident non seulement à garder une trace des flags existants et les organiser, mais également à suivre leur usage et à gérer les droits (qui peut créer / modifier quels flags).

Enfin, il est très important de définir un process de décommissionnement rigoureux, par exemple en définissant à la création du flag un ticket prévoyant sa suppression.

Concernant le « qui fait quoi », ça dépend beaucoup de l’usage prévu pour le flag et de la maturité de l’équipe !

Une conférence présentée par

Benjamin CAVY

Lead dev à la MAIF, il travaille dans l'équipe qui gère les produits open source.

Autres intervenants