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

[eoeoe]

J’aimerais bien qu’ils corrigent aussi l’erreur qui survient quand on essaie d’exporter une base de données D1 avec une table FTS configurée.
C’est ce qui est le plus pénible quand on utilise wrangler.

[GN⁺]

Avis Hacker News

• Ce serait bien que le CLI Wrangler affiche à l’avance les autorisations du jeton API nécessaires pendant le développement local
  On verrait clairement quelles autorisations sont requises avant le déploiement, et l’idéal serait de pouvoir vérifier les autorisations manquantes ou inutiles avec une commande comme cf permissions check

  • Tout à fait d’accord. Si ChatGPT configure mal les autorisations au départ, on finit par passer des heures à fouiller la documentation ou à essayer des combinaisons de jetons
  • Une commande doctor qui fait ça serait vraiment pratique. J’aimerais que davantage de services proposent ce genre de chose
  • Il m’est déjà arrivé de mal configurer un jeton à cause d’une faute de frappe, et une telle fonctionnalité m’aurait beaucoup aidé
  • En allant plus loin, ce serait bien aussi que le CLI puisse générer automatiquement les clés
  • Au fond, l’essentiel est d’améliorer la découvrabilité (discoverability) de l’API
    GraphQL suit bien les principes HATEOAS, ce qui aide les LLM à explorer une API
    C’est bien mieux qu’une documentation dont la version ne correspond pas, si l’API elle-même expose sa structure et ses capacités

• J’aimerais qu’ils ajoutent d’abord le contrôle des autorisations au niveau des groupes de ressources
  Aujourd’hui, il n’y a que des autorisations basées sur les zones (domaines), donc pour des ressources comme les workers qui n’appartiennent pas à une zone, le code peut être remplacé ou supprimé même avec des privilèges limités
  Ce serait encore mieux avec une structure super compte + sous-compte comme dans GitHub Enterprise. Exemple : ACME Corp / ACME Corp (Prod)

  • Je me demande si cela correspond au concept de Cloudflare Organization
  • Même sans partage de domaine, une structure super compte + sous-compte serait vraiment utile
  • Je suis d’accord sur le fait que les workers étant hors du modèle basé sur les zones, l’utilité est réduite

• Excellent article, très inspirant. En revanche, je suis surpris que TypeSpec ne soit pas mentionné
  C’est un langage de schéma au style TypeScript, que je décris souvent comme « à quoi OpenAPI ressemblerait s’il avait été vraiment bien conçu »
  Ils ont sans doute jugé qu’une implémentation maison serait plus simple et plus flexible. Ces jours-ci, le coût du BYO grâce aux agents a aussi beaucoup baissé

  • J’aime beaucoup TypeSpec. Écrire de l’OpenAPI devient bien plus facile
    Mais ces temps-ci, je préfère les API dans le style aep.dev. Grâce à leurs patterns cohérents, il est facile d’utiliser directement aepcli ou d’en créer un soi-même
    Terraform fonctionne aussi immédiatement, sans provider séparé
  • Je serais curieux de savoir quels aspects d’OpenAPI cela améliore

• En ce moment, la conception CLI-first centrée sur les agents IA est intéressante
  De notre côté aussi, quand on construit des outils pour développeurs, on commence par le CLI et l’API, puis on ajoute le dashboard ensuite
  L’idée de cf permissions check mentionnée plus haut est particulièrement bonne
  Les agents savent bien utiliser un CLI, mais ils sont mauvais pour diagnostiquer la cause des erreurs.
  Des messages d’erreur explicites du type « portée X manquante, exécutez cf token add --scope X » sont bien plus importants

• On peut apparemment essayer la preview technique directement avec npx cf, mais j’ai quelques questions
  Est-ce open source, et est-il prévu de le proposer sous forme de binaire unique sans Node.js ?
  Peut-être pourraient-ils utiliser quelque chose comme Bun, qu’ils ont récemment acquis ?

  • Je n’ai pas trouvé le dépôt non plus, mais le package npm est sous licence MIT et inclut des source maps, donc cela semble devoir être publié bientôt

• J’aimerais qu’on évite les jetons de longue durée.
  À la place, ce serait bien si le CLI permettait de créer facilement des jetons à durée de vie courte et à portée limitée, de les gérer dans des fichiers ou de les renouveler automatiquement
  Une autre possibilité serait un mode proxy, qui déléguerait l’accès uniquement à un domaine ou à un bucket précis

  • J’aime bien l’approche de GitLab, qui permet de générer d’un coup des PAT à courte durée de vie via un serveur SSH

• Ironiquement, avec l’arrivée de l’ère des agents IA, on revient à un développement centré sur le CLI
  Chaque fois que je veux purger le cache Cloudflare, je dois cliquer à travers plusieurs étapes dans l’interface web, alors que j’aimerais simplement donner l’instruction à un agent OpenClaw

  • Pas besoin d’utiliser OpenClaw pour ça. Il suffit d’appeler directement la commande CLI. C’est tout l’intérêt d’un CLI

• Le mode d’authentification de Wrangler se limite à deux options : OAuth (toutes les autorisations) et des jetons statiques créés manuellement depuis le dashboard
  Mais cela ne convient pas si l’on veut des frontières d’autorisations différentes entre les humains et les agents IA
  Ce serait bien de pouvoir créer directement depuis le CLI des jetons à portée limitée et à courte durée de vie
  Le sujet est aussi discuté dans la GitHub issue #13042.
  Les jetons devraient être affinés non seulement par type de ressource, mais aussi par ID de ressource et par action

• Le 1er avril, Cloudflare a lancé EmDash avec la prise en charge de x402, et maintenant ils semblent se concentrer sur le CLI
  On dirait que Cloudflare est en train de reconstruire discrètement un écosystème développeur où les agents, et non les humains, sont les principaux utilisateurs

• Ils disent avoir défini l’API, les commandes CLI, les arguments et le contexte avec un schéma TypeScript,
  mais je me demande pourquoi cet outil ou framework n’est pas présenté ici
  J’aimerais savoir si cela ressemble à la structure similaire à TypeSpec mentionnée plus haut