> Tutoriel Cloudflare Workers : installer wrangler, déployer votre premier Worker, gérer les routes et KV, et découvrir les cas d'usage à l'edge.

*Source : https://coder-studio.com/hebergement/cloudflare-workers-edge/*

---

[// Hébergement & Cloud](https://coder-studio.com/hebergement/)

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

Par **Kévin Papot** · publié le 18 avril 2026

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.

* * *

## À lire ensuite

-   [Meilleur hébergeur web pour développeurs](https://coder-studio.com/hebergement/meilleur-hebergeur-web-developpeur/)
-   [VPS pas cher : comment bien choisir](https://coder-studio.com/hebergement/vps-pas-cher-comparatif/)
-   [Cloud souverain français : les alternatives crédibles](https://coder-studio.com/hebergement/cloud-souverain-francais/)