Cloudflare Workers
Serverless
Edge Computing
JavaScript
Rust
KV Store
Durable Objects
API Gateway
Security
Performance
Deployment

Cloudflare Workers : Guide pratique de l'informatique de périphérie sans serveur

Cloudflare Workers : Guide pratique de l'informatique de périphérie sans serveur

Cloudflare Workers vous permet d'exécuter du code JavaScript (ou Rust/Wasm) à la périphérie du réseau, à proximité de l'utilisateur final. Cela réduit la latence, améliore les performances et simplifie l'architecture en éliminant les serveurs traditionnels. En 2025, la plateforme propose des fonctionnalités avancées telles que KV Store, Durable Objects, Workers Sites et une intégration native avec Cloudflare Pages.

Pourquoi utiliser les Workers ?

  • Latence minimale, le code s'exécute dans les centres de données mondiaux, généralement <10 ms.
  • Mise à l'échelle automatique, pas besoin de provisionner les instances.
  • Modèle de paiement à l'utilisation, facturation basée sur les demandes et le temps CPU.
  • Intégration avec les services Cloudflare, pare-feu, CDN, Argo, Images, etc.
  • Prise en charge de plusieurs langages, JavaScript, TypeScript, Rust, C, Go via WebAssembly.

Architecture de base d'un Worker

  1. Script, fonction fetch qui reçoit Request et renvoie Response.
  2. Routage, défini en wrangler.toml ou via Workers Routes.
  3. Stockage facultatif, KV ou objets durables pour un état persistant.
  4. Déploiement, wrangler publish ou intégration CI/CD.

Flux de requête

Le chemin d'une requête est direct : l'utilisateur accède à Cloudflare Edge via HTTPS, qui exécute le Worker Script dans le centre de données le plus proche. Le Worker lit et écrit dans le magasin KV, communique avec les objets durables lorsqu'il a besoin d'un état cohérent et renvoie la réponse à l'utilisateur. En parallèle, Edge diffuse autant que possible le contenu déjà mis en cache par le CDN, évitant ainsi une réexécution inutile.

Configurer le projet avec Wrangler

## Instalar Wrangler (CLI oficial)
npm i -g @cloudflare/wrangler
## Inicializar projeto
wrangler init my-worker --type=javascript
## Editar wrangler.toml (exemplo)

Exemple minimum de wrangler.toml :

name = "my-worker"
type = "javascript"
account_id = "YOUR_ACCOUNT_ID"
workers_dev = true
compatibility_date = "2025-01-01"

[vars]
  API_KEY = "${API_KEY}"

[[kv_namespaces]]
  binding = "MY_KV"
  id = "YOUR_KV_ID"

Script de base (3 lignes)

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
});
async function handleRequest(request) {
  return new Response('Olá do Cloudflare Workers!', {status: 200});
}

Ce code répond « Bonjour de la part des travailleurs de Cloudflare ! » à toute demande.

Routage du chemin

Dans wrangler.toml, ajoutez des routes pour des domaines spécifiques :

routes = ["example.com/api/*", "api.example.com/*"]

Désormais, le Worker ne se déclenchera que pour les URL correspondant au modèle.

Utilisation de KV Store (exemple sur 2 lignes)

await MY_KV.put('visitas', '1');
let count = await MY_KV.get('visitas');

KV offre une latence d'une milliseconde et une haute disponibilité mondiale.

Objets durables, état cohérent par clé (exemple 3 lignes)

class Counter {
  constructor(state) { this.state = state; }
  async fetch(request) { let value = await this.state.storage.get('count') || 0; await this.state.storage.put('count', ++value); return new Response(String(value)); }
}
addEventListener('fetch', event => event.respondWith(handleRequest(event.request)));

Les objets durables maintiennent un état synchrone entre les instances, idéal pour les compteurs, les salons de discussion, etc.

Sécurité et bonnes pratiques

  • Validation d'entrée, ne faites jamais confiance aux paramètres d'URL ; utilisez URLSearchParams et désinfectez.
  • Limite CPU, les Workers ont une limite de 50 ms par requête ; évitez les longues boucles.
  • Utilisation de variables d'environnement, stockez les secrets dans wrangler secret put au lieu de coder en dur.
  • CORS, configurez les en-têtes appropriés pour les API publiques.
  • Limitation de débit, à combiner avec les règles de pare-feu Cloudflare pour vous protéger contre les abus.

Tests localement

wrangler dev

La commande démarre un serveur local qui simule l'environnement Edge.

Déployer via CI/CD (exemple GitHub Actions), 5 lignes

name: Deploy Workers
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm i -g @cloudflare/wrangler
      - run: wrangler publish
        env:
          CF_API_TOKEN: $

Observabilité

  • Logs, wrangler tail affiche les logs en temps réel.
  • Metrics, Cloudflare Analytics affiche la latence, les erreurs et le trafic.
  • Suivi des erreurs, utilisez try/catch et envoyez les détails à Sentry ou Workers KV.

Liste de contrôle rapide

  • Installez Wrangler CLI.
  • Configurez wrangler.toml avec account_id et KV/DO.
  • Écrire le script fetch gestionnaire.
  • Définissez des itinéraires ou utilisez workers_dev.
  • Testez localement avec wrangler dev.
  • Configurez les secrets via wrangler secret.
  • Déployer avec wrangler publish ou CI.
  • Surveiller les journaux (wrangler tail).
  • Appliquer les règles de pare-feu pour la sécurité.

Conclusion

Cloudflare Workers offre un calcul ultra-rapide à la périphérie, vous permettant de créer des API sans serveur, des sites Web statiques, des transformations d'images et une logique métier. En suivant les meilleures pratiques de sécurité, en utilisant KV ou Durable Objects pour l'état et en intégrant des pipelines CI/CD, vous pouvez faire évoluer les applications à l'échelle mondiale avec des coûts prévisibles et des performances élevées.

Avez-vous déjà développé un Worker ? Partagez vos astuces et défis dans les commentaires !

A lire aussi

-[WebAssembly at the edge : Pourquoi démarrer rapidement et isolément est important27 -Cloudflare Workers en production : ce qui change après hello world -Développement d'applications sans serveur avec AWS Lambda et Cloudflare Workers en 2025

GitHub
LinkedIn
X
youtube