Cloudflare Workers vous permet d’exécuter du code backend à l’edge, au plus près de vos utilisateurs, sans gérer de serveurs. Pour les API, cette combinaison de démarrages à froid quasi nuls, de distribution mondiale et de stockage étroitement intégré fait de Workers une plateforme convaincante en 2026. Ce guide explique comment une API Cloudflare Workers est structurée et ce qui la distingue d’un backend traditionnel.

En bref

  • Cloudflare Workers exécute votre code sur le réseau mondial de Cloudflare à l’edge, de sorte que les requêtes sont servies au plus près des utilisateurs avec des démarrages à froid quasi nuls
  • Un Worker traite les requêtes entrantes via un handler fetch ; vous routez selon la méthode et le chemin et renvoyez des objets Response standard
  • Les Workers se lient directement au stockage : D1 (SQLite), KV (clé-valeur), R2 (stockage d’objets), Queues et Durable Objects
  • Les Workers conviennent aux API à faible latence et distribuées mondialement ; ils utilisent un runtime léger plutôt qu’un environnement serveur complet, ce qui façonne la manière de construire

Ce qui rend Workers différent

Une API traditionnelle s’exécute sur un serveur (ou un conteneur) dans une seule région. Cloudflare Workers s’exécute au contraire sur le réseau mondial de Cloudflare en utilisant de légers V8 isolates plutôt que des conteneurs ou des machines virtuelles. Les conséquences concrètes :

  • Démarrages à froid quasi nuls. Les isolates démarrent presque instantanément, évitant les délais de démarrage à froid courants sur certaines plateformes serverless.
  • Mondial par défaut. Votre code s’exécute au plus près de chaque utilisateur sur le réseau de Cloudflare, réduisant la latence sans que vous ayez à déployer dans plusieurs régions.
  • Aucun serveur à gérer. Pas de provisioning, de patching ni de mise à l’échelle ; la plateforme s’en charge.
  • Un runtime ciblé. Les Workers fournissent des API web-standard (Fetch, Request/Response, Web Crypto, streams) plutôt qu’un système d’exploitation serveur complet, avec une couche de compatibilité Node.js pour de nombreuses API Node. Vous concevez autour des standards du web.

La forme d’une API Cloudflare Workers

À la base, un Worker exporte un handler qui reçoit chaque requête :

1export default {
2  async fetch(request, env, ctx) {
3    const url = new URL(request.url);
4    if (request.method === "GET" && url.pathname === "/api/health") {
5      return Response.json({ status: "ok" });
6    }
7    return new Response("Not found", { status: 404 });
8  }
9};

À partir de là, vous construisez :

  • Le routage selon la méthode HTTP et le chemin (à la main pour de petites API, ou avec un routeur léger pour de plus grandes).
  • L’analyse des requêtes à l’aide des méthodes Request standard pour le JSON, les données de formulaire et les paramètres de requête.
  • Les réponses sous forme d’objets Response standard, y compris Response.json().
  • Les bindings disponibles sur l’argument env pour atteindre le stockage et d’autres ressources.

Connecter le stockage avec les bindings

La véritable force d’une API Workers réside dans la manière dont elle se lie directement aux données :

  • D1 pour une base de données SQLite serverless, idéale pour les données relationnelles. Voir Cloudflare D1 .
  • KV pour des données clé-valeur rapides et distribuées mondialement, comme la configuration ou le cache.
  • R2 pour le stockage d’objets (fichiers, images) sans frais de sortie.
  • Queues pour le traitement asynchrone en arrière-plan.
  • Durable Objects pour la coordination avec état et la cohérence là où vous en avez besoin.

Les bindings sont déclarés dans votre configuration et apparaissent sur env, de sorte que votre code les appelle directement sans gérer de chaînes de connexion ni d’identifiants de la manière habituelle.

Développement et déploiement

  • Wrangler, la CLI de Cloudflare, gère le développement local, la configuration, les secrets et le déploiement.
  • Vous développez face à un runtime local qui reflète la production, puis vous déployez mondialement d’une seule commande.
  • Les secrets sont gérés via Wrangler plutôt que d’être commités dans le code.

Quand Workers est le bon choix

Les Workers sont un excellent choix pour les API à faible latence et distribuées mondialement, les webhooks, les middlewares d’edge et les services qui gagnent à s’exécuter au plus près des utilisateurs. Ils conviennent moins aux charges nécessitant des processus longue durée, un calcul intensif en CPU au-delà du modèle de requête, ou un runtime de langage spécifique que la plateforme ne cible pas. Pour une comparaison plus large des options de compute, voir Cloudflare Workers vs AWS Lambda .

Un exemple concret : l’API AI Code Review est construite sur Cloudflare Workers, s’exécutant à l’edge dans le monde entier sans démarrage à froid pour renvoyer des résultats rapides et structurés, exactement le type d’API à faible latence où Workers excelle.

À retenir

  • Une API Cloudflare Workers s’exécute à l’edge avec des démarrages à froid quasi nuls et une distribution mondiale, sans serveur à gérer.
  • Un Worker traite les requêtes via un handler fetch ; vous routez selon la méthode et le chemin et renvoyez des objets Response standard.
  • Les bindings connectent votre API directement à D1, KV, R2, Queues et Durable Objects.
  • Les Workers conviennent aux API à faible latence et distribuées mondialement ; leur runtime web-standard ciblé façonne la manière de construire.

Construisez votre API edge avec des experts

Concevoir une API serverless qui exploite bien l’edge (routage, bindings de stockage et runtime web-standard) profite de l’expérience de la plateforme. Explorez les produits et outils de Mecanik pour des exemples construits sur Cloudflare, et voyez comment la comparaison Cloudflare Pages vs Workers vous aide à choisir le bon service Cloudflare pour votre projet.

Foire aux questions (FAQ)

Qu’est-ce qu’une API Cloudflare Workers ? C’est une API backend qui s’exécute sous forme de code sur le réseau edge mondial de Cloudflare plutôt que sur un serveur traditionnel. Un Worker traite les requêtes HTTP via un handler fetch et peut se connecter directement au stockage comme D1, KV et R2, servant les requêtes au plus près des utilisateurs avec des démarrages à froid quasi nuls.

Les Cloudflare Workers ont-ils des démarrages à froid ? Ils ont des démarrages à froid quasi nuls car ils s’exécutent sur de légers V8 isolates qui démarrent presque instantanément, plutôt que de lancer des conteneurs ou des machines virtuelles. C’est l’un des principaux avantages de Workers pour les API sensibles à la latence.

Puis-je utiliser une base de données avec Cloudflare Workers ? Oui. Les Workers se lient directement à D1 (SQLite serverless) pour les données relationnelles, KV pour les données clé-valeur, R2 pour le stockage d’objets, plus Queues et Durable Objects. Les bindings apparaissent sur l’argument env afin que votre code y accède directement.

Quel langage les Cloudflare Workers utilisent-ils ? Principalement JavaScript et TypeScript, et WebAssembly pour les autres langages. Les Workers fournissent des API web-standard (Fetch, Request/Response, Web Crypto) avec une couche de compatibilité Node.js pour de nombreuses API Node, de sorte que vous construisez autour des standards du web plutôt que d’un runtime serveur complet.

Quand devrais-je utiliser Cloudflare Workers pour une API ? Utilisez Workers pour les API à faible latence et distribuées mondialement, les webhooks et les middlewares d’edge qui gagnent à s’exécuter au plus près des utilisateurs avec une mise à l’échelle instantanée. Ils conviennent moins aux processus longue durée ou au travail intensif en CPU en dehors du modèle de requête.