8 meilleures pratiques pour l’utilisation des drapeaux de fonctionnalités à connaître
Les feature flags sont une révolution pour les chefs de produit. Ils vous permettent de lancer de nouvelles fonctionnalités sans galères : pas de modifications de code, pas de déploiement complet et zéro risque.
Pensez-y comme un interrupteur que vous pouvez actionner pour personnaliser votre produit ou réaliser des expérimentations à la volée. Que vous accélériez vos cycles de publication ou testiez de nouvelles idées, les feature flags vous donnent le contrôle total.
Dans cet article, je partage les meilleures pratiques de gestion des feature flags et montre comment j'ai utilisé ces techniques sur Guardian Soulmates, la plateforme de rencontres du Guardian, pour simplifier une refonte majeure.
Vous voulez plus de The CPO Club ?
Inscrivez-vous gratuitement pour terminer la lecture de cet article :
Have an account? Log In
Définition: Les drapeaux de fonctionnalités améliorent les cycles de déploiement en permettant des mises en production sûres et flexibles sans modification du code.
Pourquoi ils sont utiles: Des conventions de nommage claires pour les drapeaux de fonctionnalités aident les équipes à comprendre facilement leur utilité et à éviter toute confusion.
Bien les utiliser: Gérez efficacement vos drapeaux en supprimant ceux devenus obsolètes et en veillant à ce qu’ils soient faciles à activer ou désactiver.
Commencer petit: Utilisez les drapeaux de fonctionnalités pour tester sur de petits groupes d’utilisateurs, puis élargissez progressivement selon les retours pour minimiser les risques.
Meilleures pratiques pour la gestion des feature flags
Pour gérer efficacement les feature flags et garantir des publications produits sans accroc, il est essentiel de suivre des bonnes pratiques qui favorisent la clarté et l’efficacité. Voici quelques points clés à garder en tête :
- Utilisez un système cohérent : que ce soit via un outil de gestion ou un fichier de configuration, assurez-vous que le système est facile à comprendre et accessible à tous les membres de l’équipe.
- Définissez des conventions de nommage claires : chaque type de flag (par exemple, publication, permission, arrêt d’urgence) doit avoir des noms uniques et explicites, afin de rester compréhensible même plusieurs années plus tard.
- Facilitez l’activation/désactivation des flags : les flags doivent être simples à activer ou désactiver sans nécessiter de modification de code ou d'intervention d’un développeur.
- Supprimez les flags obsolètes : retirez les flags qui ne sont plus nécessaires afin d’éviter l’encombrement et de réduire la dette technique dans votre système.
1. Utilisez un système cohérent pour la gestion des feature flags
Peu importe que vous utilisiez un outil de gestion de feature flag (comme par exemple LaunchDarkly), un fichier de configuration ou une table de base de données. Quel que soit votre choix, le système doit être facile à comprendre, avec des conventions de nommage adaptées, pour qu’un ingénieur logiciel puisse comprendre en un coup d’œil le rôle de chaque flag.
Prenez un peu de temps lors de l’introduction des feature flags pour discuter de la meilleure solution pour votre équipe, car vous vous engagerez avec ce système sur le long terme.
2. Définissez des conventions de nommage selon les types de feature flags
Vous pouvez implémenter des feature flags pour atteindre de nombreux objectifs différents :
- Flags de publication : facilitent le déploiement de code en production avant que la fonctionnalité ne soit prête à être dévoilée au public.
- Flags d’expérimentation : pour créer un test A/B, ce flag contrôle quel groupe d’utilisateurs reçoit quelle expérience.
- Flags de permission : vous permettent de gérer l’accès à certaines fonctionnalités pour différents clients
- Flags d’arrêt d’urgence : vous permettent de dégrader votre produit de façon maîtrisée en cas de problème de performance ou de surcharge.
Des conventions de nommage claires pour chaque type de flag permettent à chacun de savoir ce que fait chaque flag, même des années plus tard.
3. Simplifiez l’activation/désactivation d’un flag
L’avantage des feature flags c’est qu’ils peuvent être activés et désactivés facilement. Idéalement, vous devriez pouvoir modifier un flag sans changer une ligne de code ni faire intervenir un développeur. Comme leur usage est très large, plusieurs équipes pourraient vouloir les manipuler, par exemple :
- La QA pour diagnostiquer ou reproduire une situation rencontrée par un client.
- Le service client pour activer ou désactiver une fonctionnalité pour un client donné.
- L’équipe DevOps pour mettre à l’arrêt (tout ou partie) de votre produit en cas de surcharge ou d’autre problème.
Si vous disposez d’une interface en ligne pour gérer les flags, toutes ces opérations peuvent être faites sans solliciter votre équipe technique.
4. Rendez visibles les paramètres des feature flags
Il doit être facile de voir quels paramètres de feature flags sont activés pour un utilisateur donné. Cette information devrait être enregistrée avec le profil de l’utilisateur, à la fois dans votre base de données utilisateurs et dans votre système analytique.
Ceci s’avère très utile pour le service client qui doit gérer des incidents signalés. Cela peut également permettre d’analyser différents comportements d’utilisateurs en fonction des paramètres activés. C’est aussi essentiel pour tirer des conclusions fiables à l’issue d’un test A/B.
5. Supprimez les flags obsolètes
Les flags de publication et d’expérimentation sont par définition seulement temporaires. Après le lancement complet d’une nouvelle fonctionnalité contrôlée par un flag ou à la fin d’une expérimentation, prévoyez systématiquement du temps pour retirer le flag comme dernière étape. Ainsi, vous évitez l’accumulation de dette technique dans le code et votre gestion des feature flags reste simple et facile à maintenir.
6. Évitez les dépendances entre les indicateurs
Chaque indicateur doit avoir un objectif spécifique indépendant des autres. Pour les indicateurs de permission, cela signifie que le code doit être suffisamment modulaire pour que les différentes fonctionnalités puissent être activées dans n'importe quelle combinaison.
Si plusieurs indicateurs sont nécessaires pour activer un cas d'utilisation particulier, ou potentiellement entrent en conflit avec d'autres indicateurs, la gestion des réglages peut devenir confuse et, tôt ou tard, des problèmes surviendront dans l’expérience des utilisateurs.
7. Utilisez un commutateur de fonctionnalités pour éviter les branches de code
Lorsqu'on discute de la mise en œuvre d'une nouvelle grande fonctionnalité au sein de l'équipe produit, il est question de découper le développement logiciel en parties plus petites. À ce moment-là, il faut également discuter de l'utilisation d'un indicateur de fonctionnalité.
Quand vous implémentez un indicateur et que vous le laissez désactivé, vous évitez ainsi la création de branches fonctionnelles durables. Au lieu de cela, le code de la nouvelle fonctionnalité peut être fusionné et déployé en continu sans être exposé aux utilisateurs dans un processus CI/CD (intégration continue / livraison continue) ou dans un sprint Agile. Cela améliore l’intégrité de votre base de code, car il n’y a pas de grands processus de fusion complexes et les conflits sont identifiés rapidement.
Cela permet également de dissocier la mise en production du code de la présentation des changements aux utilisateurs finaux, comme expliqué au point 8.
8. Utilisez des indicateurs de fonctionnalité pour des déploiements tests à petite échelle
La mise en service de grandes nouvelles fonctionnalités peut être stressante et risquée, mais vous pouvez y répondre en exposant la fonctionnalité à un petit groupe d’utilisateurs au départ, en surveillant les effets, puis en annulant si nécessaire.
Si vous avez utilisé un indicateur de fonctionnalité pour fusionner et déployer constamment votre code avant de le rendre accessible au public, comme recommandé au point 7, vous disposez déjà de l'outil adapté pour cela.
Lorsque votre nouvelle fonctionnalité est prête, activez-la dans l’environnement de production pour la montrer d’abord à des testeurs internes, puis à un petit pourcentage de clients (ce qu'on appelle un lancement progressif ou canary release), puis à l'ensemble des utilisateurs.
À chaque étape, vous surveillez vos indicateurs clés. Si quelque chose ne va pas à un moment donné, il suffit de désactiver l’indicateur et d'enquêter, sans subir le stress d'un retour en arrière complexe.
L’étude de cas suivante illustre comment atténuer les risques lors d'une refonte majeure d'un produit.
Étude de cas - Les indicateurs de fonctionnalité dans la refonte de Guardian Soulmates
Lorsque j'étais chef de produit pour Guardian Soulmates (la plateforme de rencontres par abonnement du Guardian à l'époque), nous étions confrontés à deux défis : un site mobile de qualité inférieure et une image de marque fatiguée. Nous avons décidé de mener la transition vers un site réactif et rebrandé en deux étapes.
Il faut l’admettre : les clients détestent généralement le changement, surtout quand ils sont payants. Une refonte de la marque est une entreprise majeure qui peut perturber fortement les utilisateurs.
Nous nous sommes interrogés sur la meilleure façon d’atteindre nos objectifs, à savoir remplacer le site mobile et mettre en place une nouvelle image de marque sans trop de perturbation pour nos abonnés. La solution retenue a été un processus en deux étapes impliquant deux indicateurs de fonctionnalité :
- Indicateur pour le format réactif : cet indicateur nous a permis d’afficher chaque page individuellement soit dans la nouvelle mise en page réactive, soit dans la version bureau existante (le site mobile séparé n’a pas été modifié tant que nous n’étions pas prêts à lancer la nouvelle version mobile en totalité).
- Indicateur pour la nouvelle image de marque : cet indicateur permettait d'afficher l'ensemble du site avec l'ancienne ou la nouvelle charte graphique.
Indicateur pour le site réactif
Après avoir créé un framework réactif, nous avons migré les pages une à une vers la nouvelle version réactive. Si vous travaillez sur une démarche similaire, ces outils de prototypage de design réactif peuvent vous aider à tester et à améliorer les mises en page avant la mise en ligne.
Pour chaque page migrée, l’indicateur de fonctionnalité réactive a été activé d’abord pour un petit groupe d’utilisateurs qui avaient la possibilité de faire des retours.
Après quelques jours, la page réactive était ensuite rendue accessible à tous les utilisateurs. Ce processus a été répété jusqu’à ce que l’ensemble du site soit réactif.
Puis le site mobile a été remplacé par le nouveau site réactif. Les perturbations pour les utilisateurs sur ordinateur ont été minimes grâce à la transition progressive page par page.
L’impact sur les utilisateurs mobiles a été faible car il n’y en avait que peu à l’époque (l’ancien site mobile n’étant pas très performant !).
Indicateur pour rebrander le site réactif
Après le déploiement du site réactif, l’indicateur de fonctionnalité pour la nouvelle image de marque nous a permis d’alterner l’affichage du site entre l’ancienne et la nouvelle identité visuelle.
Les développeurs ont mis en place un bouton sur le site pour changer la charte graphique utilisateur par utilisateur, ce qui a permis aux designers, à l’assurance qualité (QA) et à moi-même, en tant que chef de produit, d’en suivre l’évolution.
Les pages repensées ont été déployées en continu, mais dans l’environnement de production l'indicateur restait désactivé afin qu’aucun utilisateur n’ait accès aux pages avec la nouvelle charte graphique.
Lorsque toutes les pages ont été prêtes, nous avons ajouté un bouton sur le site pour permettre aux utilisateurs de participer à un aperçu public du nouveau branding. Ce bouton activait le nouveau branding pour l'utilisateur. Les utilisateurs pouvaient nous faire part de leurs retours et, après une semaine, nous avons activé le branding pour tout le monde.
Tout le processus s'est déroulé sans le moindre souci, aussi bien pour l'équipe de développement que pour nos clients. Ce fut un excellent exemple de l'utilisation de "feature flags" afin de réduire les risques liés à une refonte majeure du site.
Si vous souhaitez mieux comprendre en détail ce que nous avons fait, vous pouvez trouver un article sur le projet de refonte Soulmates sur le blog d'ingénierie du Guardian.
Réflexions finales
Si vous posez de bonnes bases dès le départ, vous constaterez que l'utilisation des feature flags peut considérablement augmenter la flexibilité et l'efficacité de votre produit.
Vous devriez également envisager d'utiliser les feature flags pour des initiatives importantes afin de minimiser les risques ainsi qu'un plan de gestion des versions pour garantir un déploiement sans accroc. Vous pouvez aussi utiliser l'IA dans la gestion des versions pour élaborer ce plan. La seule limite à l'utilisation des feature flags, c'est votre imagination !
Partagez dans les commentaires vos idées ou astuces pour l'utilisation des feature flags dans vos produits.
Si vous souhaitez recevoir plus d'astuces et de conseils pour améliorer vos compétences en gestion de produit, abonnez-vous à notre newsletter.
Bénéficiez de l'aide d'un autre Product Manager dans votre équipe grâce à ce guide pratique : Comment rédiger une fiche de poste efficace d'Agile Product Manager (+Exemple)
À voir également :
- Tarification produit : stratégie basée sur la valeur, offres logicielles, et plus encore
- Cycle de vie de la publication logicielle (SRLC) : comprenez les 6 étapes principales
- Comment rédiger des notes de publication logicielles efficaces qui raviront les utilisateurs
- Outils de gestion des versions logicielles
