Cloudflare lance cf : toute son API en ligne de commande, pensée pour les agents

Dans la semaine qui a précédé le 28 septembre 2026, 48 % de l'usage de Wrangler, l'outil en ligne de commande historique de Cloudflare (fournisseur américain de réseau, de sécurité et de cloud), venait d'agents de code, pas d'humains. En mars, la part des agents tournait autour d'un quart ; un an plus tôt, elle restait sous les 10 %. Ces chiffres, publiés par Cloudflare dans son billet de lancement, éclairent l'annonce du 28 septembre : une nouvelle CLI (interface en ligne de commande), cf, conçue d'abord pour ces agents.

Pour une équipe qui confie déjà une partie de son travail à des agents IA, la nouvelle compte double. cf ouvre à un agent, selon Cloudflare, l'ensemble de son API, bien au-delà du déploiement de code : DNS, sécurité, noms de domaine. Voici ce qui sort, ce qui change pour les projets existants, et les réglages à poser avant de laisser un agent s'en servir.

Ce que Cloudflare a lancé le 28 septembre

D'après le changelog officiel de Cloudflare, cf est une interface unique pour l'API publique de Cloudflare et pour les projets Workers, les fonctions serverless exécutées sur son réseau. Elle sert à gérer les zones (les domaines rattachés au compte), le DNS, le stockage et les réglages de sécurité, mais aussi à créer, développer et déployer des Workers, sans changer d'outil. Elle compte plus de 2 900 commandes, dont la plupart renvoient leur résultat en JSON.

L'outil est en bêta ouverte : Cloudflare prévient que les commandes, la configuration et le format de build peuvent encore changer avant la version stable. Il s'installe via npm et se connecte au compte par une autorisation dans le navigateur. Son code est open source. Le même jour, Cloudflare a présenté Forge, le pipeline de génération open source qui produit ces commandes à partir des schémas de son API, et qui doit aussi alimenter, dans les prochains mois, sa documentation d'API et ses SDK.

Pourquoi un nouvel outil plutôt qu'un Wrangler enrichi

Wrangler ne couvre qu'environ 280 opérations, quand l'API Cloudflare en compte plus de 3 000. Chaque équipe produit y a ajouté ses commandes à sa manière, avec un vocabulaire qui varie d'un service à l'autre : d1 info, hyperdrive get ou workflows describe pour une même intention, afficher une ressource. En générant les commandes directement depuis les schémas OpenAPI qui décrivent déjà l'API, Cloudflare obtient d'un coup une couverture quasi complète et une syntaxe homogène.

Le second argument est plus inattendu. Les modèles de langage ont appris Wrangler à travers des années de documentation, de billets et de tutoriels. Changer profondément son fonctionnement irait contre ce que les agents « savent » déjà. Selon le billet de lancement, un outil neuf, accompagné d'instructions ajoutées au contexte de l'agent, prête moins à confusion que deux versions très différentes d'un outil familier.

Une CLI pensée pour un agent qui ne l'a jamais vue

Cloudflare observe que les agents sont des utilisateurs plus intensifs que les humains : ils emploient presque deux fois plus de commandes distinctes par jour et sont presque quatre fois plus susceptibles d'utiliser six commandes ou plus. cf est construit autour de ce constat.

La fonction la plus visible est cf cli search. L'agent décrit sa tâche en langage courant (« créer une base D1 », D1 étant la base de données SQL managée de Cloudflare) et reçoit jusqu'à cinq commandes candidates, en JSON. La recherche tourne en local, sans identifiants. cf schema détaille ensuite la requête d'API que la commande enverra. Selon la documentation dédiée aux agents de code, un agent peut ainsi trouver et lancer la bonne commande sans connaissance préalable de cf. C'est tout l'intérêt de l'outil, et c'est aussi ce qui lui permet d'atteindre, dans la limite des droits de ses identifiants, l'ensemble du compte.

Autre choix assumé : le JSON par défaut. Avec Wrangler, les agents ajoutaient --json à chaque commande puis filtraient le résultat, mais seules certaines commandes le prenaient en charge ; beaucoup renvoyaient des tableaux conçus pour un œil humain. cf renverse la logique pour que l'agent extraie ce dont il a besoin sans déchiffrer de mise en page, et consomme moins de contexte. Pour les opérations qui demandent une vraie saisie personnelle, comme l'achat d'un nom de domaine, cf propose aussi un formulaire : il découpe les exigences de l'API en une série de saisies guidées et validées, que l'on remplit soi-même ou que l'on confie à l'agent.

Côté projet, la configuration des Workers passe à un fichier typé, cloudflare.config.ts. Éditeurs et agents peuvent y autocompléter les liaisons (bases de données, files de messages, stockage) et les déclencheurs, et le typage signale une partie des erreurs de configuration avant le déploiement. Cloudflare indique avoir réduit de 40 % certains de ses propres fichiers de configuration, qui dépassaient 5 000 lignes, grâce à ce format programmable. Pour les nouveaux projets créés avec cf init, le développement local et le build reposent désormais par défaut sur Vite, l'outil de build web ; un projet migré depuis Wrangler continue de construire avec Wrangler tant qu'il ne déclare pas le plugin Vite de Cloudflare.

Ce que ça change pour vos projets existants

Rien d'immédiat, et c'est une bonne nouvelle. Selon le changelog, les commandes de gestion des ressources de cf s'utilisent dans un projet Wrangler existant, sans migration préalable. Pour aller plus loin, cf migrate convertit la configuration Wrangler en cloudflare.config.ts. La documentation de migration recommande de lancer d'abord cf migrate --dry-run, qui liste les fichiers touchés et les points à reprendre à la main (par exemple la déclaration des Durable Objects, les objets à état persistant de Workers). La migration refuse de s'exécuter tant que le dépôt contient des changements non commités, sauf à la forcer avec --force.

Un piège est signalé noir sur blanc : dans un projet Wrangler non migré, cf dev, cf build ou cf deploy peuvent écrire leur propre configuration, ou échouer. Un agent lâché sur un dépôt existant doit donc recevoir une consigne claire. Cloudflare en fournit une, à placer dans les fichiers d'instructions de l'agent (AGENTS.md, CLAUDE.md) : utiliser cf, sauf si le projet contient une configuration Wrangler.

Côté calendrier, Wrangler ne disparaît pas. À la fin de la bêta, une dernière version majeure redirigera utilisateurs et agents vers cf, puis Wrangler restera maintenu 18 mois. cf continue par ailleurs de déléguer à Wrangler le développement et le déploiement des Workers JavaScript qui doivent rester sur esbuild, le bundler utilisé par Wrangler, ainsi que des Workers écrits en Rust ou en Python. Les équipes ont donc le temps de planifier la bascule, projet par projet.

Le vrai sujet : ce que votre agent a le droit de faire

La présentation officielle de cf le résume en une phrase : les agents de code lancent les mêmes commandes que vous. La documentation ne décrit pas de mode « agent » aux droits réduits : l'agent agit avec les accès de la session ou du jeton qu'il utilise. Le scénario mis en avant par Cloudflare montre l'étendue du périmètre. Depuis un seul outil, un agent peut créer un Worker, le déployer, le surveiller, le protéger avec Cloudflare Access (le contrôle d'accès de Cloudflare), acheter un domaine et le placer derrière le WAF, le pare-feu applicatif. Du code à la facturation, en passant par la sécurité.

Les leviers pour encadrer tout cela existent et sont documentés. Encore faut-il les activer :

• Un jeton limité à la tâche. Sans humain présent, en CI notamment, cf s'authentifie avec un jeton d'API (CLOUDFLARE_API_TOKEN), prioritaire sur toute connexion enregistrée. La documentation répète la consigne : ne lui accorder que les permissions dont le travail a besoin.
• Un profil par projet. Les profils nommés gardent des identifiants séparés, par exemple pour un compte professionnel et un compte personnel. cf auth activate lie un profil à un répertoire : dans ce projet, les commandes utilisent ces identifiants-là par défaut. Ce n'est pas une barrière : une variable CLOUDFLARE_API_TOKEN présente dans l'environnement, ou l'option --profile, passe avant le profil lié.
• Un aperçu avant d'agir. Sur les commandes d'API, l'option --dry-run affiche la requête en JSON sans l'envoyer, et ne demande aucun identifiant. Sur cf deploy, elle construit et valide le Worker sans l'envoyer ; mais dans un projet sans cloudflare.config.ts, elle lance d'abord la configuration automatique, qui peut installer des paquets et modifier des fichiers.
• Des suppressions verrouillées. Hors terminal interactif, une commande destructive lancée sans --force s'interrompt sans rien modifier.

Ce dernier point cache un piège. La commande interrompue affiche « Aborted. » sur la sortie d'erreur, mais se termine avec le code de sortie 0, celui d'un succès. Un script ou un agent qui ne lit que le code de retour croira la ressource supprimée. Et --force n'est pas qu'une confirmation : sur certaines commandes, c'est aussi un paramètre d'API. cf workers delete --force supprime ainsi un Worker même si d'autres Workers y font encore référence. Autoriser --force à un agent est une décision à prendre en connaissance de cause.

Reste ce que la documentation consultée ne décrit pas : ni circuit de validation humaine avant une action sensible, ni journal propre à cf des commandes exécutées par l'agent. Ces garde-fous se construisent côté équipe, avec la gestion des accès du compte Cloudflare et dans le pipeline. Le compte Cloudflare dispose toutefois de journaux d'audit, conservés 18 mois, qui indiquent quand une action a été authentifiée par un jeton d'API et lequel : un jeton dédié à chaque agent rend ses actions identifiables. L'exemple de CI publié par Cloudflare donne le ton : les étapes de pull request tournent en dry run, sans secrets, et seule l'étape finale de déploiement, sur la branche principale, reçoit le jeton. C'est typiquement le chantier d'une équipe cloud et DevOps : découper les jetons par environnement, isoler la production et tracer qui, humain ou agent, a lancé quoi.

Faut-il s'y mettre maintenant ?

Pour un nouveau projet Workers ou des tâches d'administration ponctuelles (DNS, inventaire des zones, stockage), cf peut s'essayer dès aujourd'hui, à condition d'accepter qu'une commande change de nom d'ici la version stable. Pour un projet en production sous Wrangler, rien ne presse : un cf migrate --dry-run donne une première mesure de l'effort, et la bascule peut attendre la fin de la bêta. Dans les deux cas, l'ordre des étapes compte : définir d'abord les jetons et les profils, ensuite seulement confier l'outil à l'agent.

Avec cf, Cloudflare ouvre toute son API à des agents, dans un outil généré et auto-descriptif. La surface à gouverner s'élargit d'autant : ce qu'un agent peut faire dépend avant tout de ce que les jetons, les rôles et les environnements autorisent. Régler ces accès en amont permet de profiter de la vitesse des agents en limitant le risque d'incident.

Pour aller plus loin

• Vercel Ship 2026 : la plateforme bascule vers les agents
• Model Context Protocol (MCP) : le standard IA expliqué
• Shadow AI en entreprise : risques et solutions