Présentation de cf : la CLI agentique pour l’ensemble de l’API Cloudflare

Au cours de l’année écoulée, l’utilisation de Wrangler par les agents a explosé.

En mars 2026, les agents étaient à l’origine d’un quart de l’utilisation de Wrangler, contre des pourcentages à un chiffre l’année précédente. La semaine dernière, la part d’utilisation par les agents a atteint 48 %.

Les agents sont des utilisateurs plus prolifiques : ils utilisent presque deux fois plus de commandes distinctes par jour et sont presque quatre fois plus susceptibles d’utiliser six commandes ou plus.

Les agents adorent les interfaces de ligne de commande (CLI). Or, Wrangler ne propose des commandes que pour environ 280 opérations, là où Cloudflare en propose des milliers.

Plus tôt cette année, nous vous avons laissé entrevoir comment nous comptions résoudre ce problème, et aujourd’hui, nous donnons aux agents la capacité d’utiliser tous les produits Cloudflare en introduisant une nouvelle CLI : cf.

cf est une CLI conçue pour la nouvelle génération du développement logiciel :

• Les agents peuvent trouver la commande exacte dont ils ont besoin pour accomplir n’importe quelle tâche grâce à des fonctionnalités de recherche et de guidage sur mesure.
• Le format JSON est l’interface par défaut, formaté de manière lisible par les humains et condensé pour les agents, afin de maximiser les économies de contexte.
• cloudflare.config.ts est le nouveau format de configuration pour l’ensemble de Cloudflare, en commençant par Workers ; il apporte la sécurité et la précision de TypeScript à votre protocole de serveur de langage (Language Server Protocol LSP) et à celui de votre agent.
• Vite devient le serveur par défaut, offrant le meilleur serveur de développement local ainsi qu’une suite de plugins pour les développeurs et les créateurs de frameworks.

Installez la bêta ouverte dès aujourd’hui partout dans le monde et exécutez-la depuis n’importe où :

npm i -g cf

cf donne à votre agent accès à l’ensemble de l’API Cloudflare

Et si votre agent pouvait accomplir tout ce dont Cloudflare est capable ? C’est la question qui a éveillé notre intérêt en début d’année : si les agents devenaient toujours plus puissants, ce qu’ils pouvaient accomplir avec la CLI de Cloudflare restait limité.

Wrangler a été développé de manière artisanale, chaque équipe produit contribuant et adoptant sa propre approche de l’expérience développeur de commandes. Harmoniser les pratiques des différentes équipes s’est avéré pratiquement impossible, même sur nos quelque 280 parcours de commandes. Nous nous trouvions face à une terminologie incohérente entre d1 info, hyperdrive get et workflows describe, chaque équipe ayant développé ses propres pratiques à différents moments. Certaines équipes ont développé des expériences entièrement personnalisées, représentant des milliers de lignes de code, qui n’ont été que très rarement utilisées, tandis que d’autres ont adopté des approches différentes pour résoudre les mêmes problèmes.

Nous voulions à la fois standardiser l’existant et procéder à une expansion massive, le tout en une seule fois. Forge, le nouveau pipeline unifié de génération d’API de Cloudflare, nous a permis d’y parvenir, en s’appuyant sur le principe de générer nos commandes CLI directement à partir du schéma d’API qui alimente notre documentation d’API et notre génération de SDK. Tout ce que nous proposons dispose d’un schéma OpenAPI ; il suffit d’y ajouter quelques annotations supplémentaires pour pouvoir l’utiliser comme source pour générer une CLI avec Forge.

Cela nous permet de développer cf, en évoluant des quelque 280 fonctions accumulées par Wrangler pour englober l’intégralité de la surface de l’API Cloudflare, soit plus de 3 000 opérations.

Désormais, il suffit de fournir cf à votre agent et de lui demander de configurer une instance Workers, de la déployer, de la surveiller, de la protéger avec Cloudflare Access, d’acheter un nom de domaine, puis de le sécuriser avec le pare-feu WAF de Cloudflare – et tout cela, depuis un outil unique.

Développer une solution pour un agent qui n’a jamais utilisé cf

cf a été développé pour accompagner la trajectoire du génie logiciel, à une époque où le développement agentique transforme radicalement l’approche du développement et du déploiement d’applications. Cette année, nous avons priorisé la fourniture d’outils destinés à accompagner cette évolution, une démarche qui a abouti au lancement de cf. cf a été fondamentalement développé en tenant compte des agents, et inclut des outils novateurs conçus pour la découverte de commandes par les agents, qui deviendra, selon nous, la norme dans de nombreuses CLI dans un avenir proche.

Wrangler bénéficiait d’un avantage : des années de documentation, d’articles de blog et de guides tiers ont été assimilées pendant le processus d’entraînement des LLM. Il présentait toutefois le désavantage inverse : modifier le fonctionnement de Wrangler va désormais à l’encontre des comportements appris, et un changement considérable serait inévitable au vu de l’ampleur des améliorations que nous souhaitons apporter.

Introduire une nouvelle CLI que les agents n’ont jamais vu semble être une rupture majeure, mais c’est en réalité la démarche la plus saine que nous puissions adopter. Grâce aux décisions architecturales que nous avons prises, aux injections de contexte que nous pouvons effectuer et aux fichiers AGENTS.md que nous pouvons ajouter, opérer un tel changement est en réalité moins déroutant pour un agent que de lui demander de contextualiser les différences majeures entre deux versions d’un outil qu’il connaît déjà. Nous lançons cette version en y intégrant quelques-unes de ces fonctionnalités pensées pour les agents, et d’autres suivront prochainement.

Les agents doivent filtrer du JSON, pas analyser des tableaux

Lorsque les agents utilisent Wrangler, ils ajoutent --json à chaque commande qu’ils exécutent, puis filtrent généralement le résultat avec jq afin d’en extraire un sous-ensemble de champs. Or, seules certaines commandes de Wrangler prenaient en charge l’indicateur --json ; beaucoup renvoyaient des tableaux en caractères Unicode, conçus pour des utilisateurs humains consultant l’affichage dans leur terminal. Les agents peuvent les interpréter, mais cela leur demande plus de temps et plus de tokens qu’un filtre jq.

Dans cf, nous adoptons la démarche inverse : les agents ont uniquement besoin de JSON, et si les agents sont appelés à devenir les utilisateurs principaux de cet outil, JSON doit logiquement devenir le choix par défaut. Pour la grande majorité des commandes, qui ne seront que rarement utilisées par des opérateurs humains, c’est de toute évidence la bonne décision.

En tant qu’utilisateur humain de cette CLI, vous êtes, en réalité, un intermédiaire en retrait d’un niveau de son utilisation directe. Il est préférable que les agents puissent facilement filtrer leurs résultats, puis vous présenter cette liste filtrée dans le format de votre choix que de vous fournir des tableaux que vous ne lirez probablement jamais directement.

Mais qu’en est-il si vous cherchez à accomplir une action qui nécessite une réelle saisie personnelle, par exemple, rechercher un nom de domaine à acheter ?

Pour les commandes auxquelles votre agent peut accéder en enchaînant des paramètres nommés dans une longue et fastidieuse séquence, vous pouvez simplement remplir un formulaire. cf décompose les exigences de l’API en une série de saisies validées, transformant l’achat d’un nom de domaine (même avec des exigences complexes) en une démarche simple à réaliser.

Ou, si vous y tenez vraiment, demandez simplement à votre agent de s’en occuper.

Votre agent peut trouver la bonne commande par lui-même

Avec 3 000 itinéraires possibles dans une CLI, comment votre agent peut-il identifier rapidement l’opération dont il a besoin sans saturer vos informations de contexte ? C’est la raison pour laquelle nous avons également ajouté cf cli search.

Cette commande permet à votre agent de formuler en langage naturel la tâche qu’il souhaite accomplir, et un index de recherche léger lui renvoie une liste de commandes appropriées, établie en fonction de leur description d’API et de leurs paramètres. Nous informons automatiquement votre agent de l’existence de cette commande lorsqu’il exécute --help pour la première fois.

Une configuration avec vérification de type pour votre agent

Notre nouveau format de configuration repose sur TypeScript ; facile à analyser pour les humains et les agents, il vous permet d’écrire votre configuration de façon programmatique.

Une configuration typée s’avère extrêmement utile pour les agents. Nous avons constaté que, même sans connaissance préalable du format de configuration programmatique, les agents parviennent facilement à identifier et modifier la configuration à la demande, même pour des éléments comme env, dont le fonctionnement a considérablement changé par rapport à la fonctionnalité du même nom dans Wrangler. Tous les agents utilisant des plugins LSP, comme Claude Code et Codex, tirent parti d’une meilleure capacité d’interprétation contextuelle du fichier de configuration, qui leur permet de formuler des suggestions beaucoup plus précises.

Comparez cela au format TOML, qui ne proposait pas de schéma accessible, ou à JSONC, dont le schéma associé était rarement utilisé par les agents.

Certains fichiers de configuration Wrangler internes à Cloudflare ont été condensés de 40 %, passant de plus de 5 000 lignes avec de nombreux environnements personnalisés par développeur à des fichiers « d’usine » qui génèrent plus efficacement la configuration de chaque développeur.

Ce résultat est obtenu en définissant programmatiquement chaque environnement à partir d’une même base universelle, au lieu de dupliquer des blocs env comme c’était l’usage dans Wrangler. Une instance Workers simple comportant plusieurs environnements bascule désormais simplement vers l’argument mode natif de Vite pour passer d’un ensemble de configuration à un autre.

Une configuration simple permettant d’appliquer cette approche se présente désormais comme ceci :

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker", 
      entrypoint,
      compatibilityDate: "2026-09-27",
      env: {
        Environment: bindings.text(`This is ${mode} environment`),
      },
    },
}));

Vous pouvez migrer votre instance Cloudflare Workers vers ce nouveau format via la commande cf migrate.

Nous vous proposons également plusieurs fonctions d’assistance, grâce auxquelles le développement de votre instance Workers devient un jeu d’enfant.

bindings offre à votre agent un espace centralisé depuis lequel découvrir tout ce que propose la plateforme pour développeurs. Toutes les ressources, des variables d’environnement au stockage, aux bases de données et aux files d’attente, peuvent être automatiquement suggérées et expliquées par votre éditeur.

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    env: {
      API_URL: bindings.text(
        mode === "production"
          ? "https://example.com"
          : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      CACHE: bindings.kv({
        id: mode === "production"
          ? "production-namespace-id"
          : "staging-namespace-id",
      }),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

De la même manière, nous avons intégré une fonction d’aide pour les déclencheurs (triggers), qui constituent la nouvelle façon de définir les routes, les files d’attente, les plannings et les déclencheurs d’e-mails pour votre instance Workers. Plutôt que de travailler avec des déclencheurs disséminés dans votre fichier de configuration, vous pouvez désormais retrouver facilement, dans un seul bloc, les actions susceptibles de déclencher l’exécution de votre instance Workers.

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker n’est que le point de départ. Notre objectif, avec cloudflare.config.ts, est de proposer un outil central de gestion pour l’ensemble de l’écosystème Cloudflare. Chaque produit dont vous avez besoin (ainsi que son API, qui sera accessible à votre agent via cf) pourra être exprimé à travers une configuration fortement typée. Bientôt, vous pourrez configurer des politiques complètes, paramétrer des zones, gérer le DNS et bien davantage via ce fichier de configuration.

Une expérience de développement inégalée

Quand Wrangler a commencé à développer des instances Workers JavaScript, Vite n’existait pas encore. À la place, nous utilisions esbuild dans Wrangler pour bundler vos instances Workers. Le serveur de développement que proposait Wrangler sur le port : 8787 était un outil créé par notre équipe spécialiste de Wrangler, et la moindre modification impliquait de s’immerger longuement dans les arcanes d’outils locaux spécifiques à Cloudflare, comme Miniflare.

Vite offre une amélioration considérable à cet égard : il propose un vaste écosystème de plugins, l’un des meilleurs serveurs de développement du marché avec remplacement des modules à chaud (Hot Module Replacement, HMR) et des builds qui utilisent Rolldown, une bibliothèque écrite en langage Rust, pour l’élimination du code mort (ou « tree-shaking »). Tout ce que vous pouvez accomplir avec Vite est réalisable avec le plugin Vite pour Cloudflare.

Le plugin Vite pour Cloudflare constitue la méthode recommandée pour développer des instances Workers, quelle que soit la nature de votre projet : qu’il s’agisse d’un projet orienté frontend ou d’une API backend. Associé à notre plugin Vitest, il offre un environnement de développement et de test cohérent, qui correspond au runtime Workers et vous donne un accès direct aux bindings et aux API de la plateforme.

cf est développé dans Vite, par défaut. La plupart de vos instances Workers pourront être migrées avec facilité, grâce aux agents. Pour d’autres, la migration pourra demander plus de temps ; c’est pourquoi cf continuera de déléguer à Wrangler la gestion du développement et du déploiement des instances Workers JavaScript qui doivent continuer à utiliser esbuild, ainsi que des instances Workers Rust et Python.

Migration depuis Wrangler

Migrer une instance Workers depuis Wrangler est aussi simple qu’exécuter la commande cf migrate

cf migrate

Les instances Workers qui développent déjà des applications avec Vite seront automatiquement converties vers cloudflare.config.ts. Si votre instance Workers s’appuie sur Wrangler pour esbuild, cf continuera de déléguer les builds à Wrangler.

À la fin de la bêta ouverte, nous publierons une dernière version majeure de Wrangler qui vous guidera, vous et votre agent, vers l’utilisation de cf. Nous maintiendrons le support de Wrangler pendant 18 mois après la fin de la bêta, afin de vous laisser le temps d’effectuer la migration.

Vous pouvez également configurer automatiquement de nouveaux projets pour Cloudflare en exécutant cf init/deploy, qui installera le plugin Vite pour Cloudflare et créera votre fichier de configuration

Les sites statiques ne nécessitent toujours aucun fichier de configuration pour démarrer, et leur déploiement est aussi simple que le fait d’exécuter cf deploy dans votre projet.

Pour démarrer un nouveau projet « Hello World » avec cf, utilisez la commande cf init.

cf est un projet open source et les problèmes peuvent être signalés sur notre dépôt GitHub.