API Cloudflare : maîtriser le nouveau CLI cf

Le véritable gain ne tient pas à une commande plus courte, mais au travail d’intégration qu’elle évite. Un fondateur peut examiner un compte sans fouiller dans le dashboard, une équipe plateforme fournir à un agent des résultats lisibles par une machine, et une agence harmoniser ses opérations Cloudflare entre plusieurs clients sans entretenir un wrapper d’API distinct pour chaque produit.

Aucune licence cf supplémentaire n’est nécessaire. Le dépôt est open source, un petit Worker peut démarrer sur le forfait gratuit de Cloudflare, et Workers Paid impose un minimum mensuel de $5. À l’autre extrémité du budget, une plateforme généraliste de gouvernance d’infrastructure comme Spacelift affiche une offre Starter+ à $20,000. cf supprime une bonne partie de la plomberie d’API entre ces deux extrêmes. Il ne dispense ni des validations, ni des journaux d’audit, ni d’une gestion rigoureuse des autorisations.

API Cloudflare : ce que change vraiment le nouveau CLI cf

cf fournit une surface de commandes générée pour toute l’API Cloudflare, complétée par des workflows conçus à la main pour créer, compiler, migrer et déployer des Workers. On peut voir Wrangler comme un établi spécialisé, très bien équipé pour les Workers. cf, lui, ajoute l’annuaire et l’accueil de tout l’immeuble Cloudflare, tout en continuant à confier certains travaux Worker à Wrangler lorsque celui-ci reste l’outil le plus fiable.

C’est aussi ce qui distingue cette version de la preview technique publiée par Cloudflare le 13 avril. Celle d’avril ne couvrait qu’un petit nombre de produits. La bêta ouverte de septembre apporte une couverture complète de l’API, des réponses JSON par défaut, la recherche de commandes, une configuration Worker en TypeScript et Vite comme parcours Worker par défaut.

Quatre évolutions transforment concrètement le workflow :

• Toute l’API accessible : les commandes générées suivent la forme cf <product> [group…] <operation> pour plus de 3,000 opérations.
• Recherche de commandes : cf cli search reçoit une tâche formulée en langage courant et renvoie cinq correspondances classées au format JSON. Plus besoin de mémoriser toute l’arborescence.
• JSON par défaut : les résultats structurés de l’API sont envoyés sur la sortie standard sous forme de JSON mis en forme. Une personne, un script ou un agent de code peut donc filtrer la même réponse.
• Configuration Worker typée : cloudflare.config.ts apporte les retours TypeScript aux éditeurs et aux agents de code. Pour l’instant, ce mécanisme commence par les Workers. La configuration d’un compte entier — DNS, zones et politiques — reste une orientation future, pas une fonctionnalité actuelle.

Installer le CLI, s’authentifier et valider une première lecture

Commencez par une opération en lecture seule. Elle permet de valider le package, les identifiants, le choix du compte, la découverte des commandes et le parcours JSON avant d’autoriser un script à modifier quoi que ce soit.

Le package officiel exige Node.js 22 ou une version plus récente. Dans un terminal utilisé manuellement, cf auth login gère le profil OAuth par défaut. Dans la CI, définissez un CLOUDFLARE_API_TOKEN aux droits strictement limités : cf vérifie cette variable d’environnement avant tout profil OAuth enregistré. Si vous intervenez sur plusieurs comptes clients ou d’entreprise, vous pouvez créer des profils nommés et les associer à des répertoires différents.

La requête transmise à cf cli search doit rester générique. Décrivez l’action et le type de ressource, sans inclure de domaine, d’adresse e-mail, d’identifiant de compte ni de token.

node --version
npm i -g cf
cf --version

cf auth login
cf auth whoami

cf cli search "list zones in an account"
cf zones list | jq -e 'type == "array" and all(.[]; has("name") and has("status"))'

Pour cette tâche, la recherche classe actuellement cf zones list en première position. La dernière ligne sert de preuve : elle lance un appel d’API en lecture seule et ne se termine avec succès que si le résultat est un tableau JSON dont les entrées contiennent name et status. Avec plusieurs comptes, sélectionnez un profil nommé à l’aide de --profile ou filtrez la commande avec --account-id.

Ne collez jamais un token dans l’historique du shell. Placez un token à portée limitée dans l’environnement du processus utilisé par la CI et ne lui accordez que les droits de lecture ou d’écriture indispensables à la tâche. Pour une session individuelle au terminal, OAuth est généralement plus confortable, car cf peut actualiser le profil sélectionné.

Ce que le test en environnement jetable a confirmé

Une installation neuve et isolée a renvoyé cf v1.0.0-beta.5 le 29 septembre. La recherche de commandes a produit un tableau JSON valide de cinq éléments, cf init a créé un projet Worker typé, et aussi bien le nouveau projet que le projet de test Vite migré ont été compilés localement. Aucun identifiant de compte Cloudflare de test n’était disponible dans l’environnement : la lecture authentifiée des zones et le déploiement ne figurent donc pas parmi les tests menés à terme.

Cette limite est importante. Une compilation locale réussie valide le parcours du projet. Elle ne prouve ni que le token dispose des bonnes autorisations en production, ni que le déploiement a atteint Cloudflare.

Créer un petit Worker, puis examiner le résultat

cf init est le moyen le plus rapide de tester proprement le nouveau workflow de projet. Dans un répertoire vide, la commande crée le code source TypeScript, cloudflare.config.ts, vite.config.ts, les scripts du package et les types Worker générés. cf build délègue ensuite la compilation au Cloudflare Vite Plugin et produit un Build Output standardisé.

cf init hello-cf --package-manager npm
cd hello-cf
npm run build

# In a copied existing Vite Worker:
cf migrate --dry-run
cf migrate
npm run build

Après l’un ou l’autre parcours, ouvrez cloudflare.config.ts. Pour un Worker simple, vous devriez y trouver un bloc worker avec son nom, sa date de compatibilité, son point d’entrée et ses bindings typés. Un binding texte se déclare dans l’API de configuration au lieu d’être recopié dans plusieurs blocs d’environnement. C’est là que TypeScript prend tout son sens : une faute dans un nom de champ peut être signalée par l’éditeur avant de provoquer l’échec d’un déploiement.

La configuration Vite générée n’est pas décorative. Vite est désormais le parcours par défaut de cf pour le développement local et la compilation, et Cloudflare recommande son plugin Vite aussi bien pour les frontends que pour les API backend. Dans le projet jetable, npm run build a bien délégué la compilation à Vite et s’est achevé avec succès. Le déploiement a volontairement été exclu. Une fois la revue et le test du compte terminés, la commande documentée cf deploy compile et envoie le projet par défaut.

Les cas où Wrangler reste indispensable

Ne désinstallez pas Wrangler simplement parce que cf fonctionne. La bonne stratégie de migration dépend du parcours de compilation du projet.

Pour un Worker Vite existant, cf migrate peut convertir une configuration Wrangler au format JSON, JSONC ou TOML en cloudflare.config.ts. La commande repère le plugin Cloudflare Vite à côté de la configuration Wrangler et choisit alors le parcours Vite. Si le plugin n’est pas déclaré, les versions bêta actuelles retiennent plutôt le bundler Wrangler. Lancez la prévisualisation à blanc, examinez chaque action complémentaire, puis migrez une copie ou une branche propre avant de toucher au projet de travail.

Pour les Workers JavaScript qui dépendent encore du comportement esbuild de Wrangler, cf délègue le développement et le déploiement à Wrangler. Il procède de la même manière pour les Workers Rust et Python. Ce choix garantit la compatibilité ; il ne signale pas l’échec de la migration. L’équipe utilise cf comme porte d’entrée, tandis que le builder éprouvé reste dans la chaîne.

Le calendrier de support de Cloudflare prête aussi à confusion. La maintenance de Wrangler est prévue pendant 18 mois après la fin de la bêta ouverte, et non pendant 18 mois à compter du lancement du 28 septembre. Rien ne justifie de forcer dès cette semaine un projet Rust, Python ou esbuild à passer sur Vite.

Sept workflows à adopter en priorité

Les meilleurs premiers usages ont un point commun : ils éliminent des recherches et des tâches de formatage répétitives sans accorder d’emblée de larges droits d’écriture.

1. Une agence standardise le contrôle des comptes

Une agence peut associer un profil OAuth nommé à chaque répertoire client, rechercher la commande de lecture appropriée et envoyer une structure JSON uniforme vers un script de vérification. Elle réduit ainsi les écarts entre un ingénieur qui navigue dans les dashboards et un autre qui maintient une commande curl personnalisée. Le bénéfice est surtout la répétabilité entre les comptes clients, notamment pour les DNS, les zones, les réglages de compte et les revues de sécurité.

2. Une équipe plateforme fournit une interface Cloudflare sûre aux agents de code

Un responsable plateforme peut définir dans AGENTS.md une règle encadrant cf cli search, autoriser les commandes de lecture par défaut et exiger une validation humaine pour toute mutation. La recherche évite à l’agent d’inventer une ancienne syntaxe Wrangler, tandis que JSON garde la sortie compacte et filtrable. Cette approche est particulièrement utile si l’équipe demande déjà aux agents d’examiner l’état des builds, les logs, les files d’attente ou les ressources du compte et souhaite une interface prévisible.

3. Un ingénieur d’astreinte rassemble le contexte d’un incident

Pendant un incident, l’opérateur peut rechercher la bonne commande pour lire les logs, les zones, les rulesets ou les données d’analytics au lieu de parcourir les interfaces de plusieurs produits. La commande exacte reste importante et les autorisations continuent de s’appliquer, mais la découverte se fait désormais en local et la réponse est prête pour jq. Pour les équipes qui exécutent des tâches comme Cloudflare Browser Run, le chemin entre un job en échec et le contexte du compte devient plus direct.

4. Un fondateur lance un Worker sans concevoir toute une toolchain

Pour créer un webhook, un service de redirection ou une petite API interne, un fondateur peut lancer cf init, examiner le Worker et le binding générés, puis compiler avec Vite sans choisir séparément chaque package. Le projet peut démarrer sur Workers Free. S’il lui faut l’offre payante, le minimum actuel est de $5 par compte et par mois. Le bénéfice est un chemin court vers un artefact local facile à relire, pas la promesse d’opérations de production gratuites.

5. Une équipe Vite convertit sa configuration sans réécrire l’application

Une équipe qui exploite un Worker basé sur Vite peut lancer cf migrate --dry-run sur une copie, examiner le TypeScript généré, puis compiler avant de modifier son déploiement. Ce parcours est particulièrement utile lorsque les blocs d’environnement sont devenus répétitifs. Le nouveau format permet de calculer la configuration à partir d’une base partagée, mais l’équipe doit migrer le comportement, pas seulement la syntaxe du fichier.

6. Une équipe data ou d’exploitation injecte les lectures Cloudflare dans ses rapports

Les résultats structurés étant fournis en JSON par défaut, un opérateur peut envoyer une lecture vers jq, un chargeur de data warehouse ou un rapport planifié sans avoir à extraire les données d’un tableau Unicode. Le bénéfice métier est volontairement banal : moins d’adaptateurs de sortie et moins de règles de parsing fragiles. Utilisez un token de lecture à portée limitée et ne laissez pas la sortie de la commande apparaître dans les logs publics de la CI.

7. Une équipe Worker vérifie les ressources locales avant de toucher à la production

Les commandes compatibles acceptent --local et communiquent avec une instance Miniflare éphémère adossée à un état local. Cela comprend les opérations définies pour KV, D1 et R2. Lorsqu’aucun équivalent local n’existe, cf renvoie une erreur au lieu de basculer silencieusement vers la production. Une équipe qui construit un Cloudflare AI Search Worker peut ainsi tester les données locales nécessaires sans transformer une commande de développement en écriture distante.

Deux produits à construire autour de cf

Le CLI n’est pas en lui-même l’opportunité produit. Celle-ci se trouve dans la couche de contrôle dont les équipes ont encore besoin autour d’une surface d’API aussi vaste.

Meilleure opportunité : contrôler les changements Cloudflare pour les agences

Construisez une couche ciblée de validation et de preuve pour les agences ou les petites équipes plateforme qui administrent plusieurs comptes Cloudflare. L’utilisateur propose une modification DNS, de zone, de WAF ou de Worker ; le produit s’appuie sur cf pour récupérer l’état JSON actuel, affiche un diff lisible, demande une validation, exécute l’opération avec un profil aux droits limités et conserve le résultat.

Le signal de demande est modeste, mais commercial : cloudflare dns management génère environ 170 recherches mensuelles aux États-Unis, avec un CPC de $6 et des enchères en haut de page allant de $3.85 à $36.64. La gouvernance généraliste d’infrastructure bénéficie elle aussi de budgets réels. Spacelift affiche Starter+ à $20,000. Un produit centré sur Cloudflare peut être moins cher et plus simple à adopter, car il n’a pas à gouverner tous les clouds.

La plus petite version commercialisable serait une application GitHub ou une file de validation hébergée pour les changements DNS et Worker, avec isolation des profils, liste de commandes autorisées, JSON avant/après et rollback en un clic lorsque l’API sous-jacente le permet. La difficulté consiste à créer un avantage défendable : cf fournit déjà la couverture des commandes. La valeur différenciante réside donc dans les politiques, les preuves, les autorisations et le workflow d’agence. Une simple interface graphique sera vite copiée.

Fonctionnalité utile : évaluer la préparation à la migration Worker

Construisez un scanner qui classe un dépôt comme Vite natif, esbuild adossé à Wrangler, Python ou Rust, puis exécute la prévisualisation sûre de la migration et transforme les actions complémentaires en checklist de pull request. Les acheteurs sont les équipes qui gèrent un portefeuille de Workers, pas les développeurs indépendants qui migrent un seul petit projet.

La demande est trop faible pour en faire une entreprise à part entière. cloudflare worker deployment ne génère qu’environ 10 recherches mensuelles aux États-Unis, même si la requête révèle une intention transactionnelle. Le MVP raisonnable est une fonctionnalité payante au sein d’un produit d’opérations Cloudflare ou d’un service de migration : analyse du dépôt, cf migrate --dry-run, vérification du build et rapport clair sur le repli vers Wrangler. La difficulté vient du rythme des versions pendant la bêta. Le scanner doit suivre de près les versions de cf et du Cloudflare Vite Plugin, sous peine de voir ses recommandations vieillir plus vite que les projets analysés.

Limites et décision sans détour

Utilisez cf dès maintenant pour découvrir les commandes, lire les comptes avec des réponses JSON, créer de nouveaux Workers Vite et tester prudemment les migrations. Gardez Wrangler installé partout où cf lui délègue une tâche et protégez les écritures en production par des scopes explicites et une revue.

La bêta ouverte ne fait pas encore de cloudflare.config.ts une source de vérité pour tout le compte. Elle commence par les Workers. Elle ne transforme pas non plus chaque opération de l’API Cloudflare en workflow métier sûr. La couverture complète de l’API élargit ce qu’un token peut atteindre : le principe du moindre privilège et la revue des commandes deviennent donc plus importants, pas moins.

Le mode local est volontairement limité. Les opérations compatibles avec KV, D1, R2, Durable Object et Workflow peuvent exploiter un état local, mais une opération sans équivalent dans l’explorateur local renvoie une erreur. C’est une garantie de sécurité utile, mais --local n’est donc pas un miroir hors ligne universel de Cloudflare.

Enfin, les versions bêta évoluent rapidement. Épinglez cf dans les dépendances du projet pour le travail en équipe, relisez la configuration générée et demandez à la CI d’utiliser la version locale au projet. Une installation globale est pratique pour découvrir les commandes ; une version épinglée garantit le même comportement à tous les collaborateurs.

Pour définir et construire un parcours d’automatisation Cloudflare sûr pour votre équipe, découvrez nos systèmes d’IA en production.