Qu'est-ce qu'un Feature Flag ? Expliqué simplement
Résumé
Un feature flag est un commutateur conditionnel qui active ou désactive une fonctionnalité logicielle à l'exécution, sans changer ni redéployer le code. Les équipes ops et product managers les rencontrent dans chaque sprint review et post-mortem. Cet article explique ce qu'ils sont, les quatre types principaux, pourquoi ils importent au-delà de l'engineering, et comment construire un simple suivi de feature flags dans Excel ou Google Sheets avec des formules IF.
Qu'est-ce qu'un feature flag ? C'est un commutateur conditionnel dans le logiciel qui active ou désactive une fonctionnalité à l'exécution, sans changer le code sous-jacent ni pousser un nouveau déploiement. Votre équipe engineering livre le code, et le flag décide si les utilisateurs le voient. Si vous avez entendu en sprint review la phrase « on lance ça derrière un flag », maintenant vous savez exactement ce que ça veut dire.
Ce concept revient constamment dans le travail cross-fonctionnel : les lancements produit, les rapports d'incident, les résultats de tests A/B, et les notes de release font tous référence aux flags. Plus vite vous parlez le langage des flags et de leur état, plus vous êtes utile dans ces conversations.
Un feature flag, c'est une formule IF que votre équipe engineering utilise à grande échelle
Au cœur du concept, un feature flag est une instruction IF. Dans Excel, vous écrivez =IF(A2="ON","Afficher","Masquer"). Dans du code application, un flag fait la même chose : si le flag est vrai, exécutez ce chemin de code ; sinon, sautez-le et exécutez le plan B.
La différence, c'est l'échelle et le contexte. Un flag dans une application de production s'évalue des millions de fois par seconde, à travers chaque session utilisateur actif, avec de la logique qui peut cibler des utilisateurs spécifiques, des géographies, des types d'appareils, ou des cohortes en pourcentage. Le concept sous-jacent est identique à ce que vous utilisez déjà dans un tableur.
Ce n'est pas un hasard. Les feature flags ont été formalisés précisément parce que les développeurs écrivaient la même logique de bascule encore et encore, dans chaque codebase. Le pattern a été extrait dans des bibliothèques et des plateformes dédiées. L'instruction IF a grandi.
Les quatre types de feature flags que vous allez rencontrer au travail
Les feature flags se divisent en quatre catégories. Savoir quel type quelqu'un mentionne change complètement la conversation.
Les release flags contrôlent si une nouvelle fonctionnalité est visible aux utilisateurs. Ils sont temporaires par conception : une fois que la fonctionnalité est stable et complètement déployée, le flag est supprimé. « Le nouveau flux de paiement est derrière un flag » signifie qu'il est construit et testé mais pas encore public. L'équipe contrôle le moment du lancement indépendamment du moment du déploiement.
Les experiment flags alimentent les tests A/B. Un pourcentage d'utilisateurs voient la version A, les autres voient la version B, et les outils analytics mesurent la différence comportementale. Ces flags génèrent des données avant qu'une décision produit ne soit finalisée et évitent les suppositions du type « quelle version est meilleure ».
Les ops flags sont des boutons d'arrêt d'urgence. Ils sont activés par défaut, et si quelque chose casse en production, un engineer bascule le flag à OFF pour désactiver la fonctionnalité instantanément, sans attendre qu'un nouveau déploiement soit livré. Le temps de réponse aux incidents baisse de 45 minutes à moins de 2 minutes. Chaque système de production sérieux en a au moins quelques-uns.
Les permission flags verrouillent les fonctionnalités par tier utilisateur, type de compte, région, ou n'importe quel autre attribut. Les utilisateurs premium voient le tableau de bord reporting avancé ; les utilisateurs gratuits non. Un client améliore son plan, et le flag s'évalue différemment la prochaine fois qu'il se connecte. Zéro changement de code requis.
Pourquoi les équipes ops, analytics, et product se soucient des feature flags
Les feature flags ne sont pas seulement une préoccupation des développeurs. Ils façonnent directement les données avec lesquelles travaillent chaque jour vos équipes ops et analytics.
La gestion des releases devient plus complexe quand l'engineering pousse du code continuellement. Une seule application de production peut avoir 30 à 60 flags actifs à la fois. Si votre équipe ops ne sait pas quelles fonctionnalités sont en direct, lesquelles sont en déploiement partiel, et lesquelles ont été désactivées, vous manquez du contexte pour chaque métrique que vous suivez.
Le taux de conversion baisse un mardi matin ? La première question devrait être : un flag a-t-il changé dans les dernières 24 heures ? Une nouvelle cohorte se comporte différemment que la baseline ? Vérifiez si elle est dans un groupe expérimental. L'attribution semble bizarre ? Un flag a peut-être silencieusement changé le flux utilisateur sur lequel repose votre tracking.
Les gens qui attrapent ces anomalies en premier ne sont souvent pas en engineering, mais en analytics. Lire un changelog de flag est une compétence de base pour quiconque travaille avec des données produit.
Comment l'état des feature flags s'affiche dans vos rapports
Quand un flag change d'état, ça crée une discontinuité dans vos données. Ce n'est pas un bug ; c'est attendu. Mais si vous ne le suivez pas, vous allez passer des heures à déboguer quelque chose qui n'est pas un bug du tout.
La façon la plus propre de gérer cela : tenez un journal d'événements flag à côté de vos données analytics. Chaque fois qu'un flag bascule, enregistrez l'horodatage, le nom du flag, l'état précédent, le nouvel état, et qui a fait le changement. Quand vous tirez un rapport de série temporelle et voyez un changement de palier dans une métrique, vous pouvez superposer le journal des flags pour voir si une bascule corrèle avec le point d'inflexion.
Dans Google Sheets, un simple VLOOKUP contre les horodatages du journal des flags vous donne cette vue en environ 10 minutes. La formule : =VLOOKUP(DATE_SPIKE,flag_log!A:E,3,TRUE) retourne le changement de flag le plus proche avant ou à cette date. Pas précis, mais assez rapide pour confirmer ou exclure une hypothèse avant d'escalader.
Comment construire un suivi de feature flags dans Excel ou Google Sheets
Vous n'avez pas besoin d'une plateforme dédiée pour suivre l'état des flags pour une petite équipe. Un tableur fonctionne bien pour la visibilité, la coordination, et l'audit léger.
Créez une feuille appelée « flags ». Ajoutez ces colonnes : Nom du Flag | Statut | Type | Propriétaire | Dernière modification | Notes.
Pour le Statut, utilisez un vrai Booléen. Dans Google Sheets : Format > Case à cocher crée une cellule VRAI/FAUX. Dans Excel : utilisez Validation des données pour autoriser VRAI/FAUX, ou une liste déroulante qui mappe à ces valeurs. N'utilisez pas les chaînes texte « VRAI » et « FAUX » comme du texte brut ; les comparaisons IF cassent.
Dans votre feuille de reporting, référencez la table des flags avec XLOOKUP (Excel 365 et Google Sheets) :
Ou avec VLOOKUP pour les anciennes versions d'Excel :
Ça permet à votre feuille de reporting de réagir automatiquement quand quelqu'un met à jour la colonne Statut dans la feuille flags. Basculez une case, et chaque formule dépendante se met à jour.
Le pattern de formule IF au cœur de la logique des flags
La formule de base est courte :
Où B2 contient le statut Booléen du flag.
Pour une version plus pratique qui se cascadise à travers une ligne de reporting, en utilisant XLOOKUP pour aller chercher le statut par nom de flag :
Décomposition des arguments :
Un point de précision : si vous êtes sur une version d'Excel antérieure à 2019, XLOOKUP n'existe pas. Utilisez la version VLOOKUP ou mettez à jour vers 365. Google Sheets supporte XLOOKUP sur toutes les versions depuis 2024.
Un autre point de précision : XLOOKUP avec une colonne Statut Booléenne retourne directement VRAI ou FAUX. La vérification IF IF(résultat) fonctionne sans =VRAI parce que IF traite VRAI comme truthy. Mais ajouter =VRAI explicitement, comme dans IF(XLOOKUP(...)=VRAI, ...), rend l'intention plus claire pour quiconque lit la formule plus tard. Les deux fonctionnent.
Quand le tableur suffît, et quand il ne suffît plus
Un tableur de suivi des flags fonctionne quand l'équipe est petite, le nombre de flags actifs est moins de 20, et le besoin est visibilité et coordination, pas l'évaluation à l'exécution.
Ça s'écroule dans trois scénarios. D'abord, quand les flags doivent s'évaluer pour de vrais utilisateurs dans une application en direct : ça requiert du code lisant un magasin de flags au moment de la requête, ce qu'un tableur ne peut pas faire. Deuxièmement, quand vous avez besoin de déploiements en pourcentage, par exemple servir la nouvelle fonctionnalité à 10 % des utilisateurs : cette logique vit dans la couche application. Troisièmement, quand l'audit et la conformité requièrent des journaux à l'épreuve des modifications : un Google Sheet partagé n'a pas de piste d'audit au niveau de l'écriture.
Pour les équipes qui dépassent le tableur, le chemin typique est : commencez par une plateforme open-source comme Unleash ou Flagsmith (auto-hébergée, tier gratuit disponible), puis passez à un outil commercial comme LaunchDarkly ou Statsig quand l'échelle et les intégrations justifient le coût.
Trois outils qu'ops et analytics utilisent aux côtés des feature flags
Que vous construisiez le suivi des flags ou que vous lisiez simplement le résultat, ces outils reviennent régulièrement dans le même workflow.
Les erreurs courantes des feature flags qui créent des maux de tête reporting
Les flags obsolètes sont le problème le plus fréquent. Un flag créé pour un test temporaire traîne dans la codebase pendant un an. Sa colonne Statut dit toujours Actif, mais personne n'est sûr de ce qu'il contrôle exactement, et personne ne veut le supprimer au cas où quelque chose se casse.
La solution est un audit trimestriel des flags : passez en revue chaque flag qui a été dans un état stable pendant plus de 60 jours. Les flags qui sont complètement déployés à 100 % des utilisateurs sans plans de revenir en arrière devraient être supprimés du codebase. C'est une tâche de coordination de 30 minutes, pas un projet engineering. Votre tableur de suivi est l'endroit approprié pour l'exécuter.
La deuxième erreur est de basculer un flag sans enregistrer le changement. Quand une métrique change jeudi après-midi, la question immédiate est qu'est-ce qui a changé aujourd'hui. Si les changements de flag ne sont pas horodatés et attribués dans votre tableur, l'analyse de cause racine prend des heures au lieu de minutes.
La solution est simple : ajoutez un onglet Journal des changements. Quand quelqu'un met à jour la colonne Statut, ils ajoutent une ligne avec la date, le nom du flag, l'ancien statut, le nouveau statut, leur nom, et la raison. Deux minutes de discipline par changement économisent deux heures de débogage par incident. La formule pour rendre ça facile : utilisez Google Sheets avec des plages protégées et une ligne liée à un formulaire pour le journal, donc le processus est difficile à sauter.
La troisième erreur est de donner aux flags des noms qui n'expliquent pas ce qu'ils font. Un flag nommé flag_4712 ou test_checkout_v2 ne vous dit rien en isolement. Les noms de flag devraient être descriptifs : checkout_new_address_form, homepage_personalization_experiment, reporting_v3_early_access. Votre moi futur relisant le tableur six mois à partir de maintenant vous remerciera.