Cloudflare construit une CLI unifiée couvrant l’ensemble de ses produits

• Cloudflare reconstruit Wrangler nouvelle génération afin de proposer plus de 100 produits et environ 3�000 API HTTP via une CLI unifiée (cf) ; un aperçu technique est disponible dès maintenant avec npx cf
• Comme les seuls schémas OpenAPI ne permettent pas d’exprimer diverses interfaces telles que les commandes CLI, les bindings Workers ou les compétences d’agents, l’entreprise introduit un nouveau système de schémas basé sur TypeScript
• Alors que les agents utilisent de plus en plus la CLI comme principal consommateur, des règles de cohérence des commandes et des garde-fous comme get, --force et --json sont imposés au niveau du schéma
• La fonctionnalité Local Explorer est lancée en bêta ouverte pour parcourir facilement les ressources simulées en développement local, avec inspection directe des données locales de KV, R2, D1, etc.
• En fournissant de manière cohérente la même forme d’API pour l’ensemble des API Cloudflare, dans la CLI comme en local, Cloudflare vise une expérience de développement optimisée à la fois pour les agents et pour les développeurs

---

Taille des API de Cloudflare et transition centrée sur les agents

• Cloudflare dispose de plus de 100 produits et d’environ 3�000 opérations d’API HTTP
• Les agents s’imposent comme principaux consommateurs d’API, et les développeurs construisent et déploient sur Cloudflare des applications, des agents et des plateformes via des agents de codage
• Cloudflare propose déjà l’ensemble de ses API sous la forme d’un serveur MCP Code Mode unique de moins de 1�000 tokens, mais doit encore couvrir davantage d’interfaces comme les commandes CLI, les bindings Workers, les SDK, les fichiers de configuration, Terraform, la documentation développeur et les Agent Skills
• Dans l’ancienne CLI Wrangler, de nombreuses commandes pour des produits Cloudflare manquaient encore, tandis que les agents ont tendance à préférer la CLI

Reconstruction de la CLI Wrangler nouvelle génération

• La CLI Wrangler est reconstruite comme une CLI pour l’ensemble de Cloudflare, afin de fournir des commandes pour tous les produits et une configuration unifiée dans une approche infrastructure-as-code
• L’aperçu technique peut être utilisé avec npx cf ou installé via npm install -g cf
• Pour l’instant, seuls certains produits sont pris en charge, mais en interne Cloudflare teste déjà une version couvrant toute la surface d’API Cloudflare
• Les commandes propres à chaque produit sont en cours de revue et d’ajustement pour offrir une sortie ergonomique aux agents comme aux humains
• Dans les prochains mois, cette version sera combinée aux points forts de Wrangler existant

Schéma basé sur TypeScript et pipeline de génération de code

• Jusqu’ici, Cloudflare générait automatiquement à partir des schémas OpenAPI les SDK d’API, le provider Terraform et le serveur MCP Code Mode
• Les commandes CLI, les bindings Workers, la configuration wrangler.jsonc, les Agent Skills, le dashboard et les mises à jour de documentation reposaient encore sur des processus manuels, sources fréquentes d’erreurs et impossibles à faire évoluer à grande échelle
• Les schémas OpenAPI ne décrivent que les API REST et ne peuvent donc pas exprimer des commandes CLI interactives combinant développement local et requêtes API, ni des bindings Workers basés sur RPC, ni les Agent Skills ou la documentation
• En partant du constat que TypeScript sert de langage commun en interne, Cloudflare a confirmé qu’il était plus efficace d’exprimer les API en TypeScript dans Cap n' Web, Code Mode et le système RPC de la plateforme Workers
• Un nouveau schéma TypeScript est introduit afin de définir les API, les commandes CLI et leurs arguments, ainsi que tout le contexte nécessaire à la génération des interfaces
  • Il s’agit de types TypeScript auxquels s’appliquent conventions, linting et garde-fous
  • Ce format propriétaire permet de prendre en charge avec souplesse n’importe quelle interface nécessaire, tout en pouvant aussi générer des schémas OpenAPI

Cohérence entre agents et CLI, et ingénierie du contexte

• Les agents attendent de la cohérence dans la CLI : si une commande utilise info et une autre get, l’agent peut tenter d’appeler une commande inexistante
• Dans une grande organisation comptant des centaines voire des milliers d’ingénieurs, maintenir cette cohérence par la seule revue est inévitablement faillible, selon un modèle de fromage suisse
• Si la cohérence n’est imposée qu’au niveau de la couche CLI, le problème des écarts de nommage entre CLI, API REST et SDK peut au contraire empirer
• Cloudflare applique donc des règles et des garde-fous au niveau du schéma : toujours get (jamais info), toujours --force (jamais --skip-confirmations), toujours --json (jamais --format) de manière uniforme dans toutes les commandes
• La CLI Wrangler a une structure particulière, car elle fonctionne à la fois avec des ressources locales simulées et des ressources distantes
  • Les bases de données D1, les buckets de stockage R2 et les namespaces KV sont disponibles en local comme à distance
  • Un agent peut croire modifier une base distante alors qu’il ajoute en réalité un enregistrement dans la base locale, d’où un risque de confusion
  • Des valeurs par défaut cohérentes et des sorties indiquant clairement s’il s’agit du local ou du distant fournissent un guidage explicite aux agents

Local Explorer — explorer en local les mêmes ressources qu’à distance

• Local Explorer est lancé en bêta ouverte et peut être utilisé aussi bien avec la CLI Wrangler qu’avec le plugin Cloudflare Vite
• En développement local, il permet d’explorer directement les ressources simulées utilisées par un Worker : KV, R2, D1, Durable Objects, Workflows
• Les mêmes opérations possibles via l’API Cloudflare et le dashboard peuvent être réalisées entièrement en local, avec la même structure d’API
• Cloudflare investit depuis des années dans le développement entièrement local, et même une base de données serverless hébergée comme D1 peut fonctionner totalement en local via des bindings, sans configuration ni outil supplémentaire
  • Miniflare (émulateur de plateforme de développement local) fournit les mêmes API que la production et utilise une base de données SQLite locale
  • Cela permet d’écrire et d’exécuter rapidement des tests sans accès réseau, y compris hors ligne
• Jusqu’ici, pour voir quelles données étaient stockées en local, il fallait faire de la rétro-ingénierie du répertoire .wrangler/state ou installer des outils tiers
• Lorsqu’une application est lancée avec la CLI Wrangler ou le plugin Cloudflare Vite, une invite propose d’ouvrir Local Explorer, accessible avec le raccourci clavier e
  • Une interface locale permet alors de voir les bindings connectés au Worker courant ainsi que leurs données
• Lors des builds assistés par des agents, cet outil aide à comprendre comment l’agent manipule les données ; il permet aussi la validation de schémas, l’initialisation d’enregistrements de test et les remises à zéro via DROP TABLE
• Il fournit un miroir de l’API Cloudflare qui ne modifie que les données locales, permettant d’accéder aux ressources locales avec la même API que pour le distant
  • Comme la forme de l’API est identique en local et à distance, passer le flag --local dans la CLI bascule simplement les requêtes vers l’API miroir locale
• L’API locale est accessible à l’adresse /cdn-cgi/explorer/api, où les agents peuvent découvrir la spécification OpenAPI et gérer les ressources locales

Demande de retours et feuille de route

• L’aperçu technique de la CLI nouvelle génération est disponible via npx cf ou npm install -g cf
• Cloudflare demande des retours, non seulement sur les fonctions déjà présentes dans cet aperçu, mais aussi sur ce que les utilisateurs attendent d’une CLI pour l’ensemble de la plateforme Cloudflare
  • Les opérations qui demandent aujourd’hui plusieurs clics dans le dashboard mais qu’un utilisateur voudrait exécuter via une simple commande CLI sur une ligne
  • Les éléments que l’on aimerait configurer dans wrangler.jsonc (par exemple des enregistrements DNS ou des règles de cache)
  • Les points où les agents se retrouvent bloqués et les commandes qu’on souhaiterait voir proposées dans la CLI
• Les retours sont recueillis sur le Discord Cloudflare Developers