Apprenez à concevoir et construire une application web pour créer des feature flags, cibler des utilisateurs, effectuer des rollouts progressifs, ajouter un kill switch et suivre les changements en toute sécurité.
Un feature flag (aussi appelé « feature toggle ») est un simple contrôle qui vous permet d'activer ou de désactiver une fonctionnalité sans déployer de nouveau code. Plutôt que de lier une release au déploiement, vous séparez « le code est déployé » de « le code est actif ». Ce petit changement modifie la manière dont vous pouvez livrer, en termes de sécurité et de rapidité.
Les équipes utilisent des feature flags parce qu'ils réduisent le risque et augmentent la flexibilité :
La valeur opérationnelle est simple : les feature flags offrent un moyen rapide et contrôlé de réagir au comportement réel — erreurs, régressions de performance ou retours utilisateurs négatifs — sans attendre un cycle complet de redeploy.
Ce guide vous accompagne pour construire une application web pratique de gestion des feature flags et des rollouts avec trois parties centrales :
L'objectif n'est pas une plateforme d'entreprise massive ; c'est un système clair et maintenable que vous pouvez mettre entre les mains d'une équipe produit et faire confiance en production.
Si vous souhaitez prototyper rapidement cet outil interne, un workflow de prototypage peut aider. Par exemple, des équipes utilisent souvent Koder.ai pour générer une première version fonctionnelle du tableau de bord React et d'une API Go/PostgreSQL à partir d'un cahier des charges structuré, puis itèrent sur le moteur de règles, le RBAC et les exigences d'audit en mode planning avant d'exporter le code source.
Avant de concevoir des écrans ou d'écrire du code, clarifiez pour qui le système est conçu et ce que signifie « succès ». Les outils de feature flag échouent souvent non pas parce que le moteur de règles est mauvais, mais parce que le workflow ne correspond pas à la manière dont les équipes livrent et supportent le logiciel.
Les ingénieurs veulent des contrôles rapides et prévisibles : créer un flag, ajouter des règles de ciblage et livrer sans redeployer. Les chefs produit veulent la confiance que les releases peuvent être graduelles et planifiées, avec une visibilité claire sur qui est affecté. Le support et les opérations ont besoin d'un moyen sûr de répondre aux incidents — idéalement sans déranger l'équipe d'ingénierie — en désactivant rapidement une fonctionnalité risquée.
Un bon document d'exigences nomme ces personas et les actions qu'ils doivent pouvoir faire (et ne pas pouvoir faire).
Concentrez-vous sur un noyau serré qui permet le déploiement progressif et le rollback :
Ce ne sont pas des « extras agréables » — ce sont ce qui rend un outil de rollout adoptable.
Capturez-les maintenant, mais ne les construisez pas en priorité :
Rédigez les exigences de sécurité comme des règles explicites. Exemples courants : approbations pour les changements en production, audit complet (qui a changé quoi, quand et pourquoi), et un chemin de rollback rapide disponible même pendant un incident. Cette « définition du sûr » guidera les décisions ultérieures sur les permissions, la friction UI et l'historique des changements.
Un système de feature flags est plus facile à comprendre si vous séparez la gestion des flags de l'évaluation. Ainsi, l'expérience d'administration peut être sûre et agréable, tandis que vos applications obtiennent des réponses rapides et fiables.
À un niveau élevé, vous aurez quatre blocs :
Un modèle mental simple : le dashboard met à jour les définitions ; les applications consomment un snapshot compilé de ces définitions pour une évaluation rapide.
Généralement, deux patterns :
Évaluation côté serveur (recommandée pour la plupart des flags). Votre backend interroge la couche d'évaluation/SDK avec un objet user/context, puis décide de l'action. Cela garde les règles et attributs sensibles hors du client et facilite un comportement cohérent.
Évaluation côté client (à utiliser sélectivement). Un client web/mobile récupère une configuration signée et pré-filtrée (seulement ce que le client est autorisé à connaître) et évalue localement. Cela peut réduire la charge backend et améliorer la réactivité UI, mais nécessite une hygiène stricte des données.
Pour démarrer, un monolithe modulaire est généralement le plus pratique :
À mesure que l'usage grandit, la première séparation est souvent le chemin d'évaluation (lecture intensive) du chemin d'administration (écriture intensive). Vous pouvez conserver le même modèle de données tout en introduisant un service d'évaluation dédié plus tard.
Les vérifications de flags sont sur des chemins chauds, optimisez les lectures :
L'objectif est un comportement cohérent même lors d'incidents partiels : si le dashboard est down, les applications doivent quand même évaluer avec la dernière configuration valide connue.
Un système de feature flags réussit ou échoue selon son modèle de données. S'il est trop lâche, vous ne pouvez pas auditer ou rollbacker en toute sécurité. S'il est trop rigide, les équipes l'éviteront. Visez une structure qui supporte des valeurs par défaut claires, un ciblage prévisible et un historique fiable.
Flag est l'interrupteur au niveau produit. Gardez-le stable dans le temps en lui donnant :
key (unique, utilisé par les SDKs, ex. new_checkout)name et description (pour les humains)type (boolean, string, number, JSON)archived_at (suppression douce)Variant représente la valeur que peut renvoyer un flag. Même les flags booléens gagnent à avoir des variantes explicites (on/off) car cela standardise le reporting et les rollouts.
Environment sépare le comportement par contexte : dev, staging, prod. Modélisez-le explicitement pour qu'un flag puisse avoir des règles et des valeurs par défaut différentes selon l'environnement.
Segment est une définition de groupe sauvegardée (ex. « Beta testers », « Utilisateurs internes », « Grands payeurs »). Les segments doivent être réutilisables sur plusieurs flags.
Les règles concentrent la complexité, faites-en des enregistrements de première classe.
Approche pratique :
FlagConfig (par flag + environnement) stocke default_variant_id, état enabled, et un pointeur vers la révision published actuelle.Rule appartient à une révision et inclut :
priority (le plus petit nombre gagne)conditions (tableau JSON d'expressions sur attributs)serve (variante fixe, ou rollout en pourcentage entre variantes)fallback est toujours le default_variant_id dans FlagConfig quand aucune règle ne matche.Cela simplifie l'évaluation : chargez la révision publiée, triez les règles par priorité, matchez la première, sinon valeur par défaut.
Traitez chaque changement comme une nouvelle FlagRevision :
status : draft ou publishedcreated_by, created_at, commentaire optionnelLa publication est une action atomique : définir FlagConfig.published_revision_id à la révision choisie (par environnement). Les drafts permettent de préparer des changements sans impacter les utilisateurs.
Pour l'audit et les rollback, stockez un journal append-only :
AuditEvent : qui a changé quoi, quand, dans quel environnementbefore/after (ou un JSON patch) référencant les IDs de révisionLe rollback devient « re-publier une révision antérieure » plutôt que de tenter de reconstruire manuellement des réglages. C'est plus rapide, plus sûr et facile à expliquer aux parties prenantes non techniques via la vue historique du dashboard.
Le ciblage est la partie « qui reçoit quoi » des feature flags. Bien fait, il permet des déploiements sûrs : exposer une modification d'abord aux utilisateurs internes, puis à un niveau de client, puis à une région — sans redeployer.
Commencez avec un petit ensemble d'attributs cohérents que vos apps peuvent envoyer à chaque évaluation :
Gardez les attributs simples et prévisibles. Si une app envoie plan=Pro et une autre plan=pro, vos règles se comporteront de façon inattendue.
Les segments sont des groupes réutilisables comme « Beta testers », « Clients EU » ou « Tous les admins enterprise ». Implémentez-les comme des définitions calculées (pas des listes statiques), pour que l'appartenance puisse être évaluée à la demande :
Pour garder l'évaluation rapide, cachez l'appartenance aux segments pendant un court laps de temps (secondes/minutes), indexée par environnement et utilisateur.
Définissez un ordre d'évaluation clair pour que les résultats soient explicables dans le dashboard :
Supportez des groupes AND/OR et les opérateurs courants : equals, not equals, contains, in list, greater/less than (pour versions ou attributs numériques).
Minimisez les données personnelles. Préférez des identifiants stables et non-PII (ex. un ID interne utilisateur). Quand vous devez stocker des identifiants pour des listes allow/deny, stockez des IDs hachés si possible, et évitez de copier emails, noms ou adresses IP brutes dans le système de flags.
Les rollouts sont l'endroit où un système de feature flags apporte une réelle valeur : vous pouvez exposer des changements progressivement, comparer des options et arrêter des problèmes rapidement — sans redeployer.
Un rollout en pourcentage signifie "activer pour 5% des utilisateurs", puis augmenter au fur et à mesure que la confiance monte. Le détail clé est le bucketing déterministe : un même utilisateur doit rester de façon fiable dans (ou en dehors) du rollout entre les sessions.
Utilisez un hash déterministe d'un identifiant stable (par exemple user_id ou account_id) pour assigner un bucket entre 0–99. Si vous choisissez des utilisateurs aléatoirement à chaque requête, les personnes "flip" entre expériences, les métriques deviennent bruyantes et le support ne peut pas reproduire les incidents.
Décidez aussi de l'unité de bucketing :
Commencez par des flags booléens (on/off), mais prévoyez des variantes multivariées (ex. control, new-checkout-a, new-checkout-b). Le multivarié est essentiel pour les A/B tests, les tests de copy et les modifications UX progressives.
Vos règles doivent toujours renvoyer une seule valeur résolue par évaluation, avec un ordre de priorité clair (ex. overrides explicites > règles de segment > rollout en pourcentage > défaut).
Le scheduling permet aux équipes de coordonner les releases sans que quelqu'un reste éveillé pour basculer un interrupteur. Supportez :
Considérez les schedules comme partie intégrante de la config du flag, pour que les changements soient audités et prévisualisables avant publication.
Un kill switch est un "off" d'urgence qui outrepasse tout le reste. Faites-en un contrôle de première classe avec le chemin le plus rapide dans l'UI et l'API.
Décidez de ce qui se passe lors d'une panne :
Documentez cela clairement pour que les équipes sachent ce que le client fera en cas de dégradation du système de flags. Pour plus d'informations opérationnelles, voir /blog/testing-deployment-and-governance.
Votre application web n'est que la moitié du système. L'autre moitié est la façon dont votre code produit lit les flags de façon sûre et rapide. Une API claire plus un petit SDK par plateforme (Node, Python, mobile, etc.) maintiennent l'intégration cohérente et empêchent chaque équipe d'inventer sa propre méthode.
Vos applications appelleront des endpoints en lecture bien plus souvent qu'en écriture, optimisez-les en premier.
Patterns courants :
GET /api/v1/environments/{env}/flags — lister tous les flags d'un environnement (souvent filtré sur "enabled" seulement)GET /api/v1/environments/{env}/flags/{key} — récupérer un flag par cléGET /api/v1/environments/{env}/bootstrap — récupérer flags + segments nécessaires pour l'évaluation localeRendez les réponses adaptées au cache (ETag ou updated_at), et gardez les payloads petits. Beaucoup d'équipes supportent aussi ?keys=a,b,c pour des fetchs groupés.
Les endpoints d'écriture doivent être stricts et prédictibles :
POST /api/v1/flags — créer (valider unicité de la clé, règles de nommage)PUT /api/v1/flags/{id} — mettre à jour une config draft (validation du schéma)POST /api/v1/flags/{id}/publish — promouvoir une draft vers un environnementPOST /api/v1/flags/{id}/rollback — revenir à la dernière version saineRetournez des erreurs de validation claires pour que le dashboard puisse expliquer ce qu'il faut corriger.
Le SDK doit gérer le cache avec TTL, les retries/backoff, les timeouts et un fallback offline (servir les dernières valeurs en cache). Il doit aussi exposer un appel unique « evaluate » pour que les équipes n'aient pas à comprendre votre modèle de données.
Si les flags affectent la tarification, les droits ou des comportements sensibles, évitez de faire confiance au client navigateur/mobile. Préférez l'évaluation côté serveur, ou utilisez des tokens signés (le serveur émet un "snapshot" signé des flags que le client peut lire mais pas falsifier).
Un système de feature flags ne fonctionne que si les gens lui font confiance en production. Le dashboard construit cette confiance : labels clairs, valeurs par défaut sûres et changements faciles à réviser.
Commencez par une vue simple de la liste de flags qui supporte :
Affichez l'état courant de façon lisible. Par exemple, montrer On pour 10%, Ciblage : segment Beta, ou Off (kill switch actif) plutôt qu'un simple point vert.
L'éditeur doit ressembler à un formulaire guidé, pas à une configuration technique.
Incluez :
Si vous supportez des variantes, affichez-les comme des options lisibles (« Nouveau checkout », « Ancien checkout ») et validez que le trafic total est cohérent.
Les équipes auront besoin d'activer/désactiver en masse et de « copier les règles vers un autre environnement ». Ajoutez des garde-fous :
Utilisez des avertissements et des notes obligatoires pour les actions risquées (modifs en Production, sauts de pourcentage importants, toggles du kill switch). Affichez un résumé des changements avant enregistrement — ce qui a changé, où et qui sera affecté — pour que les relecteurs non techniques approuvent en toute confiance.
La sécurité est l'endroit où les outils de feature flags gagnent rapidement la confiance — ou se font bloquer par votre équipe sécurité. Parce que les flags peuvent changer des expériences utilisateurs instantanément (et parfois casser la production), traitez le contrôle d'accès comme une partie intégrante du produit.
Commencez par email + mot de passe pour la simplicité, mais prévoyez les attentes enterprise.
Un modèle propre est RBAC plus permissions par environnement.
Puis scindez ce rôle par environnement (Dev/Staging/Prod). Par ex. quelqu'un peut être Editor en Staging mais seulement Viewer en Prod. Cela évite des basculements accidentels en production tout en gardant les équipes rapides ailleurs.
Ajoutez un workflow d'approbation optionnel pour les modifications Prod :
Vos SDKs auront besoin de clés pour récupérer les valeurs de flags. Traitez-les comme des API keys :
Pour la traçabilité, reliez cette section à votre conception du journal d'audit dans /blog/auditing-monitoring-alerts.
Quand les feature flags contrôlent de vraies expériences utilisateurs, "qui a changé quoi ?" devient une question de production, pas de bureaucratie. L'audit et le monitoring transforment votre outil de rollout en un système opérationnel digne de confiance.
Chaque action d'écriture dans l'app admin doit émettre un événement d'audit. Traitez-le en append-only : ne modifiez jamais l'historique — ajoutez un nouvel événement.
Capturez l'essentiel :
Rendez ce journal facile à parcourir : filtres par flag, environnement, acteur et plage temporelle. Un lien profond "copier le lien vers ce changement" est inestimable pour les threads d'incident.
Ajoutez une télémétrie légère autour des évaluations de flags (lectures SDK) et des résultats de décision (quelle variante a été servie). Au minimum, suivez :
Cela aide pour le debug ("les utilisateurs reçoivent-ils bien la variante B ?") et la gouvernance ("quels flags sont morts et peuvent être supprimés ?").
Les alertes doivent relier un événement de changement à un signal d'impact. Règle pratique : si un flag est activé (ou monté en charge) et que les erreurs augmentent peu après, alertez quelqu'un.
Exemples de conditions :
Créez une zone “Ops” simple dans votre dashboard :
Ces vues réduisent l'incertitude pendant les incidents et rendent les rollouts plus contrôlés que risqués.
Les feature flags sont sur le chemin critique de chaque requête, donc la fiabilité est une caractéristique produit, pas un détail infra. L'objectif : l'évaluation des flags doit être rapide, prévisible et sûre même quand des parties du système sont dégradées.
Commencez par un cache en mémoire dans votre SDK ou service edge pour que la plupart des évaluations n'atteignent jamais le réseau. Gardez le cache petit et indexé par environnement + version du set de flags.
Ajoutez Redis quand vous avez besoin de lectures partagées et basses latences entre de nombreuses instances d'app (et pour diminuer la charge sur la base principale). Redis est aussi utile pour stocker un « snapshot courant de flags » par environnement.
Un CDN n'aide que si vous exposez un endpoint de flags en lecture seule qui est sûr à mettre en cache publiquement ou par-tenant (souvent ce n'est pas le cas). Si vous utilisez un CDN, préférez des réponses signées et de courte durée et évitez de cacher des données user-spécifiques.
Le polling est plus simple : les SDKs récupèrent le dernier snapshot toutes les N secondes avec des checks ETag/version pour éviter de retélécharger des données inchangées.
Le streaming (SSE/WebSockets) offre une propagation plus rapide pour les rollouts et kill switches. C'est excellent pour de grandes équipes, mais demande plus de soin opérationnel (limites de connexions, logique de reconnexion, fanout régional). Un compromis pratique : polling par défaut avec streaming optionnel pour les environnements « instantanés ».
Protégerez vos APIs contre des mauvais paramétrages SDK (ex. polling toutes les 100ms). Appliquez côté serveur des intervalles minimaux par clé SDK et renvoyez des erreurs explicites.
Protégez aussi votre base de données : assurez-vous que le chemin de lecture est basé sur un snapshot, pas sur "évaluer les règles en joignant les tables utilisateurs". L'évaluation de flags ne doit jamais déclencher des joins coûteux.
Sauvegardez votre datastore principal et faites des drills de restauration régulièrement (pas seulement des backups). Conservez un historique immuable des snapshots de flags pour un rollback rapide.
Définissez des valeurs par défaut sûres pour les pannes : si le service de flags est injoignable, les SDKs doivent retomber sur le dernier snapshot connu ; s'il n'en existe pas, par défaut mettre la fonctionnalité à "off" pour les features risquées et documenter les exceptions (ex. flags critiques pour la facturation).
Déployer un système de feature flags n'est pas "déployer et oublier". Parce qu'il contrôle le comportement en production, vous voulez une forte confiance dans l'évaluation des règles, les workflows de changement et les chemins de rollback — et un processus de gouvernance léger pour que l'outil reste sûr au fur et à mesure de l'adoption.
Commencez par des tests qui protègent les promesses centrales :
Astuce pratique : ajoutez des cas tests "golden" pour les règles délicates (plusieurs segments, fallbacks, conditions conflictuelles) pour que les régressions soient évidentes.
Faites du staging un environnement de répétition :
Avant les releases en production, utilisez une checklist courte :
Pour la gouvernance, restez simple : définissez qui peut publier en production, exigez une approbation pour les flags à fort impact, révisez les flags obsolètes chaque mois et ajoutez un champ « date d'expiration » pour éviter que des rollouts temporaires vivent indéfiniment.
Si vous construisez cela comme une plateforme interne, il peut être utile de standardiser la façon dont les équipes demandent des changements. Certaines organisations utilisent Koder.ai pour générer un dashboard initial et itérer sur les workflows (approbations, résumés d'audit, UX de rollback) avec les parties prenantes en conversation, puis exporter la base de code pour une revue de sécurité et une appropriation à long terme.
Un feature flag (ou « feature toggle ») est un contrôle à l'exécution qui active ou désactive une fonctionnalité sans déployer de nouveau code. Il sépare le fait de publier du code et d'activer un comportement, ce qui permet des déploiements progressifs plus sûrs, des retours arrière rapides et des expériences contrôlées pour les tests.
Une configuration pratique sépare :
Cette séparation maintient le workflow de changement sûr et traçable tout en garantissant des évaluations à faible latence.
Utilisez un bucketing cohérent : calculez un hash déterministe à partir d'un identifiant stable (par exemple user_id ou account_id), mappez-le sur 0–99, puis incluez/excluez selon le pourcentage de déploiement.
Évitez l'aléa à chaque requête ; sinon les utilisateurs "flip" entre expériences, les métriques sont bruitées et le support ne peut pas reproduire les problèmes.
Commencez avec :
Une ordre de priorité clair rend le comportement explicable :
Gardez l'ensemble d'attributs petit et cohérent (ex. rôle, plan, région, version de l'app) pour éviter des dérives de règles entre services.
Stockez les schedules dans la config spécifique à l'environnement :
Rendez ces changements planifiés audités et prévisualisables pour que les équipes puissent confirmer ce qui va se passer avant la mise en production.
Optimisez pour la lecture :
Ainsi, la base de données n'est pas interrogée à chaque vérification de flag.
Préférez l'évaluation côté serveur pour les flags qui touchent au prix, aux droits ou à la sécurité, afin d'éviter que le client ne manipule les règles ou attributs.
Si l'évaluation doit se faire côté client :
Utilisez RBAC avec portée par environnement :
Pour la production, ajoutez des workflows d'approbation optionnels pour les changements affectant le ciblage, les pourcentages ou le kill switch. Enregistrez toujours demandeur, approbateur et le changement exact.
Au minimum, capturez :
Pour les pannes : les SDK doivent retomber sur le dernier snapshot valide, puis sur un défaut sûr (souvent « off » pour les fonctionnalités risquées). Voir aussi /blog/auditing-monitoring-alerts et /blog/testing-deployment-and-governance.
key stable, type, nom/description, suppression douce (archivé).dev/staging/prod avec configs séparées.Ajoutez des révisions (draft vs published) pour que la publication soit un changement atomique par pointeur et que le rollback soit "re-publier une ancienne révision".