Le 16 juillet 2026, Cloudflare a livre une suite de commandes wrangler flagship qui permet de gerer son service de feature flags Flagship entierement depuis le terminal. Jusqu'ici, Flagship, le service de flags edge natif de Cloudflare bati sur le standard ouvert OpenFeature, se pilotait surtout par un tableau de bord et une API. Les nouvelles commandes comblent l'ecart qui compte pour les equipes qui automatisent tout : vous pouvez creer une app, la brancher dans votre config Wrangler comme un binding, creer des flags, changer la valeur par defaut d'un flag, et desactiver un flag comme coupe circuit, sans quitter votre shell. Comme ce n'est que le CLI, les memes commandes tournent dans les pipelines CI/CD, les scripts de deploiement et meme des agents IA. Pour quiconque traite la configuration comme du code, sortir les flags d'une console web pour les mettre dans des commandes versionnees, c'est la partie utile de cette sortie.
The short answer
Le 16 juillet 2026, Cloudflare a livre une suite de commandes wrangler flagship qui gere son service de feature flags Flagship depuis le terminal. Vous pouvez creer une app, l'ajouter a votre config Wrangler comme binding, creer des flags, changer la valeur par defaut d'un flag, et desactiver un flag comme coupe circuit, le tout depuis le shell. Comme ce n'est que le CLI, les memes commandes tournent dans les pipelines CI/CD, les scripts de deploiement et les agents IA. Flagship est bati sur le standard ouvert OpenFeature, votre code lit donc les flags par une interface neutre. Au lancement, l'acces est reserve par compte.
Les feature flags ont un defaut de conception familier. Le flag qui decide si une fonctionnalite risquee est active vit dans un tableau de bord web, gere au clic, alors que tout le reste de votre deploiement vit dans le controle de version et passe par un pipeline revu. Cette separation ne pose pas de probleme jusqu'a un incident, ou le seul levier que vous avez le plus besoin de tirer se trouve dans un autre systeme avec un autre chemin d'acces. La sortie du 16 juillet de Cloudflare vise exactement cet ecart en amenant Flagship dans Wrangler, le meme CLI que les equipes utilisent deja pour deployer des Workers.
Ce qui a ete livre
L'ajout, c'est une suite de commandes wrangler flagship. Flagship est le service de feature flags edge natif de Cloudflare, bati sur OpenFeature, un standard ouvert de feature flagging, et jusqu'ici il se pilotait surtout par le tableau de bord et une API. Le CLI amene le cycle de vie principal dans le terminal.
Vous pouvez creer une app Flagship et faire ajouter par Wrangler cette app a votre fichier wrangler.json ou wrangler.jsonc comme binding, de sorte que votre Worker lise les flags par le meme mecanisme de configuration qu'il utilise pour toute autre ressource. A partir de la, vous creez des flags, definissez leurs valeurs et changez leur comportement. Les flags peuvent contenir des valeurs booleennes, des chaines, des nombres ou du JSON, un flag n'est donc pas limite a un simple interrupteur marche ou arret. Il peut porter une configuration structuree que votre code lit a l'execution.
Des flags comme commandes, pas comme clics
Les commandes correspondent proprement au cycle de vie quotidien d'un flag. Vous creez une app et la branchez, creez un flag, changez sa variation par defaut, et l'activez ou le desactivez. Les commandes d'activation et de desactivation sont les coupe circuits : une commande eteint une fonctionnalite partout ou le flag est lu, sans deploiement. Cloudflare expose aussi des sous commandes rollout, split et rules pour les sorties progressives et le ciblage, vous pouvez donc elargir l'exposition ou viser un flag sur une partie du trafic sans livrer de nouveau code.
Aucune de ces capacites n'est nouvelle pour le feature flagging en tant que concept. Ce qui change, c'est ou elles vivent. Une action de tableau de bord est une etape manuelle qui ne laisse ni diff ni trace de revue. Une commande, c'est du texte. Elle peut se placer dans un script, passer par la revue de code, etre journalisee et rejouee. C'est tout l'argument de la configuration comme code, applique a la seule partie d'un deploiement qui etait obstinement restee dans une console.
Ou cela s'insere : CI/CD, scripts et agents
Comme ce sont des commandes Wrangler ordinaires, elles tournent partout ou Wrangler tourne. C'est le vrai deverrouillage pratique. Un pipeline de sortie peut creer un flag desactive par defaut, deployer le code derriere lui, et n'activer le flag qu'une fois les tests de fumee passes. Un job de retour arriere peut eteindre le meme flag des qu'une alerte se declenche, sans attendre un nouveau deploiement. Et comme les commandes sont du texte, un agent automatise peut inspecter l'etat de Flagship, changer un flag ou revenir en arriere dans le cadre d'un flux plus large.
Ce dernier point est la ou Cloudflare vise Flagship depuis le debut, en le presentant comme du feature flagging pour l'ere de l'IA. Le raisonnement est direct : si le logiciel est de plus en plus modifie par des systemes automatises, les controles qui encadrent ces changements doivent eux aussi etre automatisables. Un coupe circuit n'est utile que si la chose la plus susceptible de devoir etre arretee peut aussi l'atteindre. Batir sur OpenFeature garde honnete le cote lecture, puisque votre code parle a une interface neutre plutot qu'a un SDK proprietaire, ce qui compte si vous voulez un jour changer de fournisseur de flags sans reecrire la façon dont votre application verifie les flags.
Les compromis a peser
C'est une sortie vraiment utile, mais il y a quelques points a garder en tete avant de vous appuyer dessus.
- L'acces est reserve au lancement. La fonctionnalite est actuellement derriere un flag par compte, il faudra donc peut etre contacter votre equipe de compte Cloudflare pour l'activer. Ne supposez pas qu'elle est active sur votre compte par defaut.
- La puissance du CLI coupe des deux cotes. La meme scriptabilite qui permet a un pipeline d'actionner un coupe circuit permet a un mauvais script ou a une commande negligente d'actionner le mauvais. Traitez les identifiants et l'automatisation qui changent les flags avec le meme soin que les identifiants de deploiement, et gardez une trace d'audit de qui ou de quoi a change un flag.
- Un flag reste un engagement. Mettre les flags dans le code les rend plus faciles a creer, ce qui rend plus facile l'accumulation de flags obsoletes que personne ne retire. La vieille discipline s'applique toujours : un flag est un echafaudage temporaire, et le nettoyage fait partie du travail, pas d'une reflexion apres coup.
Le titre, pris seul, est modeste. Un fournisseur cloud a ajoute des commandes CLI a un service qui existait deja. Mais la direction est celle qui continue de payer : prendre un controle operationnel qui exigeait un humain dans une console web, et en faire une commande que l'automatisation, la revue et le controle de version peuvent tous atteindre. Pour les equipes qui pilotent deja leur infrastructure depuis Wrangler, c'est un levier de moins coince en dehors du pipeline.
Sources et pour aller plus loin
- Journal des changements Cloudflare : gerer Flagship en ligne de commande avec Wrangler
- Blog Cloudflare : presentation de Flagship, des feature flags batis pour l'ere de l'IA
- Journal des changements Cloudflare : provisionnement automatique des bindings Flagship
- InfoQ : Cloudflare presente Flagship, un service de feature flags edge natif bati sur OpenFeature
Questions fréquentes
Qu'a reellement livre Cloudflare ?
Le 16 juillet 2026, Cloudflare a ajoute une suite de commandes wrangler flagship a son CLI Wrangler. Elle permet de gerer Flagship, le service de feature flags de Cloudflare, depuis le terminal. Vous pouvez creer une app Flagship et l'ajouter a votre wrangler.json ou wrangler.jsonc comme binding, creer des flags, changer la variation par defaut d'un flag, et activer ou desactiver des flags directement, sans passer par le tableau de bord.
Qu'est ce que Flagship et qu'est ce qu'OpenFeature ?
Flagship est le service de feature flags edge natif de Cloudflare. Les feature flags permettent d'activer ou de desactiver une fonctionnalite, ou d'en faire varier le comportement, sans deployer de nouveau code. Flagship est bati sur OpenFeature, un standard ouvert de feature flagging, ce qui signifie que la façon dont votre code lit les flags n'est pas verrouillee sur le SDK proprietaire d'un seul fournisseur. Un flag peut contenir une valeur booleenne, une chaine, un nombre ou du JSON.
Pourquoi gerer les flags depuis le CLI change t il quelque chose ?
Un CLI est scriptable la ou un tableau de bord ne l'est pas. Comme ce sont des commandes Wrangler ordinaires, elles tournent dans les pipelines CI/CD, les scripts de deploiement et les agents automatises. Les changements de flag peuvent donc vivre dans le controle de version, suivre le meme chemin de revue et de retour arriere que votre code, et etre pilotes par l'automatisation. Les commandes d'activation et de desactivation servent de coupe circuits que vous pouvez actionner depuis un pipeline des qu'un probleme survient.
Est ce disponible pour tout le monde des maintenant ?
Pas encore par defaut. Au lancement, la fonctionnalite est reservee derriere un flag par compte, il faudra donc peut etre contacter votre equipe de compte Cloudflare pour l'activer. Les commandes s'appuient aussi sur un travail plus tot en juillet qui a ajoute le provisionnement automatique des bindings Flagship, permettant a Wrangler de connecter ou de creer une app Flagship pendant le deploiement.