Feature Flags : comment faire évoluer un logiciel sans attendre la prochaine version ?

Nous avons l’habitude de voir une nouvelle fonctionnalité arriver avec une nouvelle version du logiciel. L’application est mise à jour, la version est publiée et le changement devient disponible.

Mais les logiciels modernes ne fonctionnent pas toujours de cette manière.

Une fonctionnalité peut déjà faire partie de la version déployée en production sans pour autant être active. Elle peut d’abord être activée uniquement pour l’équipe qui la développe, puis pour un petit groupe d’utilisateurs et, enfin, pour tout le monde.

Et si un problème survient, elle peut être désactivée sans qu’il soit toujours nécessaire de publier immédiatement une nouvelle version.

Derrière cette flexibilité se trouve un mécanisme appelé Feature Flags.

Le code peut être prêt. La mise à disposition peut attendre.

Le principe est relativement simple.

Un Feature Flag agit comme une couche de contrôle sur une fonctionnalité spécifique. Le code peut déjà avoir été déployé en production, mais le flag détermine si la fonctionnalité doit être active ou non.

Cela permet de dissocier deux étapes traditionnellement très liées : le déploiement du code en production et la mise à disposition de la fonctionnalité auprès des utilisateurs.

Pour les équipes de développement, cela apporte davantage de flexibilité. Une nouvelle version ne doit pas nécessairement attendre que toutes les fonctionnalités qu’elle contient soient prêtes à être accessibles à tous.

Et une fonctionnalité ne doit pas nécessairement attendre la version suivante simplement parce que le moment prévu pour sa mise à disposition a changé.

Tous les changements ne doivent pas être accessibles à tout le monde immédiatement

L’une des utilisations les plus pratiques des Feature Flags est l’activation progressive.

Une nouvelle fonctionnalité peut d’abord être activée pour l’équipe interne. Puis pour un nombre limité d’utilisateurs et, si tout fonctionne comme prévu, progressivement pour un groupe plus large.

Cela permet à l’équipe d’observer le comportement de la fonctionnalité dans des conditions réelles sans exposer immédiatement tous les utilisateurs au changement.

Au lieu de passer instantanément de 0 % à 100 %, la mise à disposition peut devenir un processus contrôlé.

Un problème ne doit pas toujours nécessiter une nouvelle version

Ce même contrôle fonctionne également dans l’autre sens.

Si un problème apparaît après l’activation, une fonctionnalité gérée à l’aide de Feature Flags peut, lorsque cela est possible, être désactivée sans attendre un nouveau cycle de release.

Le code reste en place, mais les utilisateurs ne sont plus exposés à la fonctionnalité qui pose problème.

Cela ne remplace ni les tests, ni le rollback, ni les autres pratiques visant à garantir la fiabilité du logiciel. Mais cela offre une possibilité supplémentaire de réagir rapidement et de limiter l’impact d’un problème.

De la publication des versions au contrôle des changements

Les Feature Flags ne suppriment ni les releases ni la nécessité de publier de nouvelles versions. Ils changent la manière dont une fonctionnalité passe du code à l’utilisateur.

L’équipe peut déployer le code en production, puis contrôler séparément le moment où la fonctionnalité est activée, les utilisateurs qui y ont accès et la manière dont elle est progressivement mise à disposition.

Comme l’explique Ermal Beqiri, fondateur d’ALSoft :

“Avec les Feature Flags, une fonctionnalité peut être prête et déjà intégrée au logiciel sans devoir être activée immédiatement pour tous les utilisateurs. Les équipes gardent ainsi davantage de contrôle sur la manière dont les changements sont déployés et peuvent réagir rapidement si quelque chose ne fonctionne pas comme prévu.”

Le logiciel peut ainsi évoluer progressivement, tandis que l’équipe garde le contrôle sur chaque étape du changement.