Introduction
Un feature flag est un paramètre qui active ou désactive une fonctionnalité sans modifier le code de l’application. Imaginez que vous prépariez une nouvelle bannière d’annonce : vous voulez la tester dans votre environnement d’exercice tout en la laissant désactivée dans la version publique. Workers KV stocke de petites valeurs sous des noms appelés clés. Un Worker peut lire une clé telle que banner:new lorsqu’il doit décider de la réponse à envoyer. Cette solution convient aux paramètres lus souvent et modifiés occasionnellement.
Avant de commencer ce cours, terminez le lab Connect LabEx to Your Cloudflare Account. Il explique le terminal de la VM LabEx, l’autorisation de l’appareil, la confirmation du compte et account_id. Si vous avez ouvert ce cours directement, commencez par ce lab. Vous devez également savoir écrire un petit Worker JavaScript et le déployer avec Wrangler, comme dans le cours pour débutants sur Workers. Un Worker exécute votre code de traitement des requêtes sur Cloudflare sans que vous ayez à gérer un serveur.
Ici, vous allez créer un namespace, c’est-à-dire un conteneur nommé qui sépare une collection de clés des autres. Vous le relierez à un Worker au moyen d’un binding, le nom configuré que votre code utilise pour accéder à cette ressource. Vous pratiquerez les opérations locales et cloud, publierez un endpoint de bannière en lecture seule, puis supprimerez les ressources temporaires.
Utilisez votre propre compte d’apprentissage. Cette nouvelle VM nécessite sa propre connexion avec les autorisations Workers et KV. L’exercice utilise un Worker, un namespace et quelques valeurs synthétiques dans les limites gratuites de KV ; aucun domaine acheté ni abonnement payant n’est nécessaire pour ce petit exercice. L’utilisation existante du compte continue toutefois de compter dans ses limites. L’endpoint public ne contient aucune information privée.
La configuration installe Node.js 22.22.0 ainsi que Wrangler 4.131.1, installé localement dans le projet, à l’emplacement /home/labex/project/feature-flags. Elle fixe les versions des dépendances directes et exécute npm install ; vous n’avez pas besoin de réinstaller ces outils. Gardez la VM ouverte jusqu’à la vérification de la suppression des ressources cloud et de la déconnexion.
Connecter un namespace dédié aux flags
Dans cette étape, vous allez donner à ce lab ses propres noms de ressources et connecter un namespace cloud à votre projet. Un namespace distinct empêche les clés d’exercice de se mélanger avec celles d’une application existante.
Accédez au projet préparé :
cd /home/labex/project/feature-flags
Générez une fois un nom unique. openssl rand -hex 6 affiche un suffixe aléatoire ; $(...) l’insère dans le nom. La variable du shell conserve ce nom pour les commandes suivantes exécutées dans ce terminal.
WORKER_NAME="labex-flags-$(openssl rand -hex 6)"
printf '%s\n' "$WORKER_NAME"
Autorisez cette VM. En plus de lire l’identité de votre compte, l’autorisation Workers Scripts Write permet le déploiement et la suppression, tandis que Workers KV Write permet de gérer le namespace et les clés de ce lab.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_kv:write
Ouvrez dans votre navigateur le lien d’appareil affiché, saisissez le code actuel, vérifiez les autorisations demandées et le compte d’apprentissage, puis autorisez Wrangler. Un accès en arrière-plan peut également apparaître sur la page de consentement. Revenez au terminal et attendez la fin de la connexion.
Développez Developer Platform sur la page de consentement et comparez les autorisations demandées avec cet exemple. Les deux autorisations d’écriture sont nécessaires pour ce lab ; elles couvrent la gestion des ressources, et pas seulement la lecture d’un flag.
npx wrangler whoami --json
Vérifiez que le résultat contient loggedIn: true ainsi que le name du compte d’apprentissage, même si un seul compte est répertorié. Copiez l’id de ce compte. Enregistrez-le dans la configuration ci-dessous en remplaçant YOUR_ACCOUNT_ID avant d’exécuter la commande. Le here-document de cat écrit dans un fichier tout ce qui se trouve entre les deux lignes JSON ; > remplace le fichier. Le délimiteur non entouré de guillemets permet au shell d’insérer $WORKER_NAME.
cat > wrangler.jsonc <<JSON
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true
}
JSON
Créez un namespace dans ce compte. Son titre reprend le nom unique du Worker afin que vous puissiez reconnaître les deux ressources plus tard. --update-config=false vous laisse modifier le binding vous-même au lieu de changer automatiquement le fichier.
npx wrangler kv namespace create "$WORKER_NAME-flags" --update-config=false
La sortie contient l’ID du nouveau namespace. Copiez-le, puis remplacez YOUR_ACCOUNT_ID et YOUR_NAMESPACE_ID dans cette configuration complète. Le nom du binding FLAGS est celui que votre code utilisera ; l’ID identifie la véritable ressource Cloudflare.
cat > wrangler.jsonc <<JSON
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true,
"kv_namespaces": [
{ "binding": "FLAGS", "id": "YOUR_NAMESPACE_ID" }
]
}
JSON
npx wrangler kv namespace list
Repérez le titre du namespace de ce lab et comparez son ID avec celui du fichier. D’autres namespaces peuvent être présents ; ne les modifiez pas. Cette configuration indique à quelles ressources et à quel compte les commandes suivantes doivent s’adresser. Un binding est une référence vers un namespace, et non une copie de ses données.
Séparer les flags locaux et distants
Dans cette étape, vous allez stocker des valeurs différentes sous la même clé et vérifier que les modifications locales ne touchent pas les données cloud. Local désigne le stockage situé dans cette VM LabEx. Remote désigne le namespace de votre compte Cloudflare. Wrangler utilise le binding pour identifier le stockage ; l’option explicite --local ou --remote indique où l’opération doit avoir lieu.
Commencez par laisser la fonctionnalité publique désactivée :
npx wrangler kv key put banner:new disabled --binding FLAGS --remote
Activez cette même fonctionnalité dans le stockage local de la VM :
npx wrangler kv key put banner:new enabled --binding FLAGS --local
Lisez les deux valeurs. put écrit une clé et get récupère sa valeur. Le deux-points dans banner:new est une convention de nommage qui regroupe les clés associées ; il ne crée pas de répertoire.
Utilisez --text pour décoder la valeur stockée en UTF-8 et l’afficher sur une ligne distincte.
npx wrangler kv key get banner:new --binding FLAGS --local --text
Vous devez obtenir enabled.
npx wrangler kv key get banner:new --binding FLAGS --remote --text
Vous devez obtenir disabled. Si vous avez modifié accidentellement la valeur distante, exécutez de nouveau sa commande put avec disabled, puis relisez-la. Ne déduisez pas la cible à partir du seul dossier du projet.
Entraînez-vous maintenant à supprimer un flag retiré. Ces commandes concernent uniquement le namespace distant temporaire associé à FLAGS.
npx wrangler kv key put banner:old retired --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --remote
La liste contient des noms tels que banner:new et banner:old, et non les valeurs qu’ils stockent. Utilisez get lorsque vous avez besoin d’une valeur.
npx wrangler kv key delete banner:old --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --remote
npx wrangler kv key list --binding FLAGS --local
Les deux listes doivent maintenant contenir uniquement banner:new. Relisez les deux valeurs si vous devez vérifier qu’elles sont toujours différentes. La suppression d’une clé retire une entrée ; la suppression ultérieure d’un namespace supprimera tout le conteneur.
KV est à cohérence éventuelle : une modification peut mettre du temps à devenir visible pour les lectures effectuées depuis d’autres emplacements. Un Worker peut temporairement voir une valeur précédente, y compris une clé auparavant absente. Ne réécrivez pas plusieurs fois une valeur pour la faire apparaître. Ces flags d’affichage sans conséquence tolèrent ce délai ; ils ne conviendraient pas à une décision immédiate de révocation d’accès. Vous étudierez ce comportement dans un lab ultérieur. Consultez le fonctionnement de KV pour comprendre le modèle de stockage.
Lire un flag depuis un Worker local
Dans cette étape, vous allez faire dépendre le comportement de l’application du paramètre stocké. Le Worker lit env.FLAGS, où env contient les bindings des ressources configurées. get() est asynchrone ; await attend donc sa valeur avant de décider de la réponse à renvoyer.
Écrivez le gestionnaire. Le délimiteur JS entre guillemets préserve exactement le JavaScript, sans expansion des variables du shell.
cat > src/index.js <<'JS'
export default {
async fetch(request, env) {
if (new URL(request.url).pathname !== "/banner") {
return new Response("Not found", { status: 404 });
}
const value = await env.FLAGS.get("banner:new");
return Response.json({
feature: "new-banner",
enabled: value === "enabled"
});
}
};
JS
Lorsqu’une clé est absente, elle renvoie null. La comparaison exacte avec "enabled" garantit qu’une valeur absente ou inattendue laisse cette bannière facultative désactivée. Il s’agit d’une petite valeur par défaut sûre : l’application reste utilisable lorsque le paramètre n’a pas été fourni. Cela ne masque pas les échecs de connexion, qui sont différents d’une clé absente.
Démarrez le développement local. --local exécute le Worker dans cette VM avec les bindings locaux. > local.log 2>&1 redirige la sortie et les erreurs vers le journal ; & permet au terminal d’accepter d’autres commandes. $! correspond à l’ID du processus exécuté en arrière-plan ; vous l’enregistrez ici pour pouvoir arrêter ce processus plus tard.
npx wrangler dev --local --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
DEV_PID=$!
cat local.log
Attendez le message indiquant que le service est prêt sur le port 8080. Si le démarrage est toujours en cours, relisez le journal avant de continuer.
curl -i http://127.0.0.1:8080/banner
curl -i affiche les en-têtes et le corps de la réponse. Vous devez obtenir HTTP 200, un type de contenu JSON et :
{"feature":"new-banner","enabled":true}
La valeur true provient du stockage KV local. Le lancement du serveur de développement n’a pas copié dans la VM la valeur distante disabled. Laissez le serveur en fonctionnement pour la comparaison suivante.
Déployer et comparer la réponse publique
Dans cette étape, vous allez publier le même code et vérifier qu’il lit le namespace cloud. Le déploiement envoie le Worker et sa configuration de bindings ; il n’envoie pas les entrées KV locales.
npx wrangler deploy
Lisez la sortie du déploiement. Vérifiez le nom du Worker, le binding FLAGS et l’adresse publique workers.dev. Enregistrez l’adresse réelle ci-dessous en remplaçant l’exemple avant d’exécuter la commande. Une variable du shell évite de retaper une URL longue.
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/banner"
Vous devez obtenir HTTP 200 et :
{"feature":"new-banner","enabled":false}
Le paramètre cloud vaut disabled, donc la réponse publique contient false. Si le nouveau nom d’hôte n’est pas encore accessible, attendez un court instant et réessayez. Si la réponse reflète une ancienne valeur, vérifiez une fois la clé distante et laissez à KV le temps de rendre la modification visible au lieu de la réécrire rapidement. Une erreur réseau ne constitue pas un test réussi.
curl -i http://127.0.0.1:8080/banner
La réponse locale contient toujours true. Vous disposez d’un seul gestionnaire et de deux stockages distincts : le développement local lit les données de la VM, tandis que le Worker déployé lit le namespace identifié par le binding.
Dans le tableau de bord Cloudflare, sélectionnez le même compte d’apprentissage et ouvrez Storage & databases → Workers KV. Trouvez le namespace dont le nom correspond à ce lab et examinez ses clés. Vérifiez qu’il ne reste que banner:new, avec la valeur distante disabled. Ouvrez ensuite Workers & Pages, sélectionnez le Worker de ce lab et examinez sa vue Bindings. Comparez le binding FLAGS avec le namespace que vous venez d’inspecter. Ces vérifications sont en lecture seule : le terminal reste l’endroit où vous effectuez les modifications.
Le namespace s’ouvre sur Metrics. Sélectionnez KV Pairs pour voir les entrées réelles ; les compteurs d’utilisation peuvent être mis à jour après les écritures. Si le nouveau Worker n’apparaît pas dans Workers & Pages, cliquez sur Refresh. Dans Bindings, descendez jusqu’au tableau pour comparer le nom du binding avec son namespace.
Le nom généré, l’ID du namespace et le sous-domaine public diffèrent des exemples. Voir un namespace dans le tableau de bord confirme où il se trouve ; une réponse HTTP réussie confirme que l’application peut l’utiliser.
Supprimer les ressources cloud temporaires
Dans cette étape, vous allez supprimer les deux ressources pendant que Wrangler est encore autorisé. Un namespace peut survivre à son Worker ; supprimer uniquement l’application ne nettoie donc pas ses données.
Arrêtez le processus de développement local démarré dans ce terminal :
kill "$DEV_PID"
Examinez les références de ressources enregistrées avant toute suppression :
cat wrangler.jsonc
Vérifiez le nom du Worker labex-flags-... et l’ID du namespace FLAGS. Supprimez le Worker sélectionné par cette configuration :
npx wrangler delete
Si une confirmation est demandée, vérifiez que le nom affiché correspond à ce lab, puis confirmez avec y. Supprimez ensuite uniquement le namespace référencé par FLAGS :
npx wrangler kv namespace delete --binding FLAGS
Vérifiez le namespace dans toute demande de confirmation avant d’accepter. Conservez wrangler.jsonc intact afin que la vérification indépendante puisse identifier les ressources qui doivent être absentes.
npx wrangler kv namespace list
Le namespace de ce lab doit avoir disparu ; les namespaces sans rapport doivent rester présents. Actualisez les listes du tableau de bord pour confirmer que le Worker et le namespace du lab ont disparu. Une requête échouée ou une connexion expirée ne prouve pas la suppression. Exécutez la vérification de cette étape avant de vous déconnecter afin qu’elle puisse inspecter un inventaire autorisé.
Mettre fin à l’autorisation de la VM
Dans cette étape, vous allez déconnecter Wrangler après la réussite de la vérification du nettoyage. La déconnexion met fin à l’autorisation Wrangler enregistrée dans cette VM ; elle ne supprime pas les ressources cloud et ne vous déconnecte pas de votre session habituelle dans le navigateur du tableau de bord.
npx wrangler logout
npx wrangler whoami --json
Vérifiez que le résultat structuré indique "loggedIn": false. Cette commande non authentifiée peut se terminer avec un code de sortie différent de zéro, ce qui est attendu ici. Si vous obtenez uniquement une erreur de connexion sans état d’authentification explicite, réessayez lorsque la connexion fonctionnera.
Les fichiers locaux restants et l’état KV local appartiennent à cette VM temporaire. Ils sont distincts des ressources cloud que vous avez déjà supprimées. Vous pouvez maintenant terminer le lab.
Résumé
Vous avez créé un namespace KV isolé, l’avez connecté au moyen d’un binding et utilisé des commandes locales et distantes explicites pour écrire, lire, lister et supprimer des clés. Votre Worker a lu la même clé dans deux stockages distincts : la bannière locale était activée tandis que la bannière publique restait désactivée. Vous avez également utilisé une valeur par défaut sûre pour un flag absent et compris pourquoi les mises à jour KV ne doivent pas être considérées comme un basculement global immédiat.
Enfin, vous avez vérifié la réponse publique, supprimé le Worker et le namespace pendant que vous étiez autorisé, puis vous êtes déconnecté de Wrangler. Ensuite, vous utiliserez des valeurs JSON structurées pour servir des préférences de compte non sensibles.
