Cloudflare Workers : déployer une fonction à l'edge

Cloudflare Workers permet d’exécuter du code JavaScript (ou WebAssembly) directement sur le réseau mondial de Cloudflare, au plus près de l’utilisateur. Pas de serveur à provisionner, pas de région à choisir : votre fonction tourne à l’edge, dans le datacenter le plus proche de chaque visiteur. Ce tutoriel vous guide de l’installation de wrangler jusqu’à un premier Worker en production, avec routes et stockage KV.

Transparence : cette page peut contenir des liens affiliés une fois les programmes validés. Cela n’influence pas le contenu du tutoriel et n’entraîne aucun surcoût pour vous.

Pourquoi l’edge computing ?

Sur une architecture serveur classique, une requête part du navigateur, traverse le réseau jusqu’à votre datacenter (souvent lointain), attend le traitement, puis revient. À l’edge, le code s’exécute dans le point de présence le plus proche, ce qui réduit drastiquement la latence.

Le modèle Workers repose sur les isolates V8 plutôt que sur des conteneurs : le démarrage est quasi instantané, sans cold start perceptible, et la facturation se fait à la requête. En contrepartie, l’environnement est contraint — pas d’accès complet à Node.js, des limites de temps CPU par requête — ce qui oriente vers des traitements courts et découpés.

Prérequis

Node.js installé (version LTS récente).
Un compte Cloudflare (l’offre gratuite suffit largement pour démarrer).

Étape 1 : installer et configurer wrangler

wrangler est l’outil en ligne de commande officiel pour développer et déployer des Workers.

npm install -g wrangler
wrangler --version
wrangler login

La commande login ouvre votre navigateur pour autoriser la CLI à accéder à votre compte.

Étape 2 : créer votre premier Worker

Générez un projet à partir d’un modèle :

npm create cloudflare@latest mon-worker
cd mon-worker

L’assistant vous propose plusieurs templates ; choisissez « Hello World » pour commencer. Vous obtenez un fichier d’entrée minimal :

export default {
  async fetch(request, env, ctx) {
    return new Response("Bonjour depuis l'edge !", {
      headers: { "content-type": "text/plain; charset=utf-8" },
    });
  },
};

Le cœur d’un Worker est la fonction fetch : elle reçoit la requête entrante et renvoie une Response. Vous disposez des API web standard (Request, Response, fetch, URL, crypto), pas de l’API Node complète.

Étape 3 : développer en local puis déployer

Lancez un serveur de développement local :

wrangler dev

Votre Worker tourne sur http://localhost:8787. Modifiez le code, rechargez : le rechargement est immédiat. Quand vous êtes prêt :

wrangler deploy

En quelques secondes, votre fonction est distribuée sur l’ensemble du réseau mondial, accessible via une URL en *.workers.dev.

Étape 4 : lire la requête et router

Un Worker devient utile dès qu’il réagit au contenu de la requête. Voici un petit routeur basé sur le chemin :

export default {
  async fetch(request) {
    const url = new URL(request.url);

    switch (url.pathname) {
      case "/":
        return new Response("Accueil");
      case "/api/heure":
        return Response.json({ now: new Date().toISOString() });
      default:
        return new Response("Introuvable", { status: 404 });
    }
  },
};

Response.json() sérialise automatiquement l’objet et positionne le bon en-tête content-type.

Étape 5 : associer le Worker à votre domaine

Le sous-domaine workers.dev convient pour tester, mais en production vous voudrez votre propre domaine. Deux approches :

Les Routes : dans le tableau de bord Cloudflare, associez un motif d’URL (ex. exemple.com/api/*) à votre Worker. Le domaine doit être géré par Cloudflare.
Custom Domains : rattachez directement un domaine ou sous-domaine au Worker, sans passer par un enregistrement DNS manuel.

Vous pouvez aussi déclarer une route dans le fichier wrangler.toml :

name = "mon-worker"
main = "src/index.js"
compatibility_date = "2026-01-01"

routes = [
  { pattern = "exemple.com/api/*", zone_name = "exemple.com" }
]

Étape 6 : stocker des données avec KV

Workers KV est un magasin clé-valeur distribué à l’échelle mondiale, optimisé pour des lectures très fréquentes et des écritures moins nombreuses (cohérence à terme). Créez un namespace :

wrangler kv namespace create MON_STOCK

La commande renvoie un identifiant à reporter dans wrangler.toml :

[[kv_namespaces]]
binding = "MON_STOCK"
id = "votre-id-de-namespace"

Le binding MON_STOCK devient accessible via env dans le Worker :

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const cle = url.searchParams.get("cle");

    if (request.method === "PUT") {
      const valeur = await request.text();
      await env.MON_STOCK.put(cle, valeur);
      return new Response("Enregistré");
    }

    const valeur = await env.MON_STOCK.get(cle);
    return valeur
      ? new Response(valeur)
      : new Response("Absent", { status: 404 });
  },
};

KV est idéal pour de la configuration, des feature flags ou un cache. Pour des données fortement relationnelles ou transactionnelles, l’écosystème Cloudflare propose d’autres briques (bases SQL à l’edge, objets à état, stockage objet), à explorer une fois les bases acquises.

Cas d’usage typiques à l’edge

A/B testing et personnalisation : réécrire ou aiguiller la réponse selon la géolocalisation ou un cookie, sans latence serveur.
Authentification et middleware : vérifier un jeton, ajouter des en-têtes de sécurité, gérer des redirections avant que la requête n’atteigne l’origine.
API légères : exposer un endpoint JSON adossé à KV, sans back-end à maintenir.
Reverse proxy et transformation : agréger plusieurs sources, réécrire du HTML, servir des images optimisées.
Webhooks : recevoir et traiter des événements avec un démarrage instantané.

Les limites à garder en tête

L’environnement edge impose ses règles : temps CPU limité par requête, pas de système de fichiers persistant, API Node partielle. Ce n’est pas une faiblesse mais une orientation : Workers vise des traitements courts et distribués, pas des jobs longs ou gourmands. Pour ces derniers, un VPS ou un serveur applicatif classique reste plus adapté.

Conclusion

En quelques commandes, vous avez déployé une fonction exécutée dans des dizaines de villes à la fois, sans gérer un seul serveur. C’est toute la promesse de l’edge : de la logique au plus près de l’utilisateur, avec une mise à l’échelle transparente. À partir de ce socle — fetch, routes, KV — vous pouvez construire des middlewares, des API et des optimisations qui étaient hier réservés à des infrastructures lourdes.