Le CLI de Cloudflare est désormais utilisé à 48 % par des agents, alors l'entreprise l'a repensé pour eux

Cloudflare affirme que, la semaine dernière, 48 % de l'ensemble de l'usage de Wrangler provenait d'agents plutôt que d'humains. En mars 2026, ce chiffre était d'un quart. L'année précédente, il se limitait à un seul chiffre. L'entreprise indique également que les agents exécutent presque deux fois plus de commandes distinctes par jour que les humains, et qu'ils sont environ quatre fois plus susceptibles d'enchaîner six commandes ou plus au cours d'une session.

Dans la foulée, Cloudflare a lancé cf, un nouvel outil en ligne de commande en bêta ouverte, installable avec npm i -g cf. Wrangler n'est pas mort : Cloudflare recommande de continuer à l'utiliser dans les projets qui contiennent déjà un fichier wrangler.jsonc, wrangler.json ou wrangler.toml, et de ne migrer avec cf migrate que sur demande. Mais la direction prise est sans équivoque.

Comment passer de 280 à 3 000 commandes sans les écrire

Le problème évoqué est celui de la couverture. Wrangler expose environ 280 opérations, alors que l'API de Cloudflare en compte plus de 3 000. Wrangler a été construit à la main, chaque équipe produit y apportant ses propres commandes et ses propres conventions, d'où le fait que d1 info, hyperdrive get et workflows describe signifient à peu près la même chose. Cloudflare admet que certaines équipes ont écrit des milliers de lignes de code de commande sur mesure pour des fonctionnalités à peine utilisées par la suite.

cf est généré, et non écrit. Cloudflare a construit un pipeline baptisé Forge, qui prend les schémas OpenAPI alimentant déjà sa documentation d'API et ses SDK, y ajoute une couche d'annotations, puis en tire des commandes CLI. OpenAPI est simplement une description lisible par machine de chaque endpoint, de ses paramètres et de ses réponses, le même fichier qui permet de générer automatiquement des bibliothèques clientes. En le branchant sur un générateur de commandes, toute la surface de l'API devient un CLI aux noms cohérents, pour un coût à peu près équivalent à celui de la maintenance du schéma que vous maintenez déjà.

C'est là le véritable élément nouveau. Le reste du lancement découle de choix de conception qui en sont la conséquence.

JSON d'abord, et un index de recherche pour la machine

Wrangler renvoyait par défaut des tableaux lisibles par un humain, avec l'option --json disponible sur certaines commandes seulement. Cloudflare constate que les agents ajoutent --json à tout, puis font passer le résultat dans jq pour en extraire des champs. cf inverse donc le comportement par défaut : toujours du JSON, condensé pour les agents afin d'économiser du contexte, indenté pour les humains. Lorsqu'une tâche nécessite réellement une personne, par exemple l'achat d'un domaine, cf transforme les exigences de l'API en un formulaire validé plutôt qu'en une chaîne d'options nommées.

La découverte des commandes est le problème le plus ardu. Aucun agent ne peut garder 3 000 chemins de commande dans son contexte. La réponse de Cloudflare est cf cli search, un index de recherche local portant sur les descriptions et les paramètres des commandes, qui accepte une requête en langage naturel et renvoie des commandes candidates. Lancer --help pour la première fois signale à l'agent l'existence de cette fonction. L'argument de Cloudflare pour lancer un CLI qu'aucun modèle n'a jamais vu est contre-intuitif mais cohérent : un tout nouvel outil doté d'un guidage explicite est plus facile à apprendre pour un agent qu'un outil familier dont le comportement a discrètement changé.

Le fichier de configuration devient un programme TypeScript

La configuration passe dans cloudflare.config.ts, avec des fonctions utilitaires (defineConfig, bindings, triggers) et un argument mode issu de Vite pour basculer d'un environnement à l'autre. L'enjeu n'est pas l'élégance : TypeScript porte un schéma que le serveur de langage de l'éditeur peut lire, de sorte que vous comme votre agent bénéficiez de l'autocomplétion et d'erreurs de typage au lieu de deviner. Cloudflare établit le contraste avec TOML, qui n'avait aucun schéma accessible, et avec JSONC, dont le schéma lié était rarement utilisé par les agents. En interne, l'entreprise indique que certaines configurations Wrangler de plus de 5 000 lignes ont rétréci de 40 % en générant des environnements par développeur à partir d'une base partagée, plutôt qu'en copiant-collant des blocs env.

Vite devient également le builder et le serveur de développement par défaut, en remplacement de la pile esbuild et Miniflare sur laquelle Wrangler s'était construit, Rolldown assurant le tree-shaking et le rechargement à chaud des modules dès l'installation.

Les questions que vous devriez vous poser

• Comment Cloudflare classe-t-il concrètement une requête comme provenant d'un agent plutôt que d'un humain, et quelle part des 48 % correspond à un script en CI qui n'a jamais croisé de modèle ?
• Si les commandes sont générées à partir de schémas OpenAPI, que devient votre automatisation lorsqu'un schéma change en amont : une commande peut-elle être renommée ou supprimée en silence ?
• Qui passe en revue les 2 700 opérations qu'aucun humain n'a jamais exercées via un CLI ? Une couverture générée n'est pas une couverture testée.
• Quels sont les contrôles du rayon d'impact lorsqu'un agent disposant d'identifiants cf peut acheter des domaines, modifier des règles WAF et changer le DNS depuis le même outil ?
• Pendant combien de temps Wrangler sera-t-il pris en charge, et que signifie « continuer à l'utiliser sauf demande de migration » dans deux ans ?

Ce qu'il faut surveiller ensuite

Surveillez si cloudflare.config.ts s'étend réellement au-delà de Workers. Cloudflare indique que les zones, le DNS et les politiques arriveront dans le même fichier : c'est cette promesse qui ferait de cf non plus un meilleur Wrangler, mais un plan de contrôle pour l'ensemble du compte. Si cette surface se limite encore à Workers à la fin de la bêta, l'ambition n'aura été qu'une diapositive de feuille de route. Si elle voit le jour, la question intéressante ne sera plus de savoir quel CLI vous utilisez, mais quelle part de votre infrastructure un seul jeton d'agent peut atteindre.