Edge computing + Durable Objects : architecture edge-first

En 2025, Cloudflare exploite plus de 330 POPs dans 125 pays. AWS en compte environ 35 régions pour Lambda, Vercel s'appuie sur 18 edge regions. La conséquence mesurée depuis nos bancs d'essai VALRY LABS : un utilisateur à Paris, Berlin, Milan ou Madrid touche un POP Cloudflare en moins de 25 ms de RTT (median p50 sur cloudping et tests internes). Sur le marché européen, le seuil de 50 ms — sous lequel un utilisateur perçoit une interface comme instantanée — est atteint pour environ 95 % des internautes.

Ce que cela change concrètement : le pattern « base primaire dans une région, read replicas ailleurs » devient une opportunité coûteuse, pas un standard. Pour les charges Reads-héavy, collaboratives, ou sensibles à la latence (chat, présence, dashboards temps réel, IA légère), exécuter le code là où se trouve l'utilisateur bat désormais de 60 à 150 ms n'importe quelle architecture régionale bien réglée. C'est l'écart entre une UI perçue fluide (INP < 100 ms) et une UI ressentie comme « distante ».

Attention au piège narratif : edge ne signifie pas « sans état ». Pendant des années, l'edge était principalement stateless (CDN, rewrite, cache). Ce qui a changé en 2024-2025, c'est l'arrivée d'un primitif stateful fortement consistant — Durable Objects — et de bases serverless edge-friendly (Turso, Neon, PlanetScale). L'edge-first n'est plus un slogan, c'est une architecture traçable, facturable et tenable en production.

Workers n'utilise ni containers ni micro-VMs : chaque requête est servie par un isolate V8 (le moteur de Chrome) partagé entre milliers de locataires sur un même hôte. Le démarrage à froid moyen est de l'ordre de 5 ms (0 ms mesuré sur le p50, ~5 ms au p99 selon les benchmarks Cloudflare et confirmé par nos mesures sur un Worker « ping »). À titre comparatif, Lambda@Edge démarre entre 200 et 800 ms au p95 — un écart qui rend Workers quasi-obligatoire pour du chemin critique utilisateur.

Côté expérience développeur : un Worker est un fichier TypeScript, déployable via `wrangler deploy` en moins de 10 secondes, avec bindings typés (KV, R2, D1, Queues, Durable Objects, AI, Analytics Engine). Pas d'AMI, pas de Dockerfile, pas de blue/green à orchestrer. Pour une équipe de 5 à 15 développeurs — la cible de VALRY LABS — la friction de déploiement tombe au niveau d'un `git push`. Les revues de code se concentrent sur la logique, pas sur l'infrastructure.

Le revers : un modèle d'exécution contraint. CPU time plafonné à 30 s (payant), mémoire à 128 Mo, pas de `fs`, pas de `child_process`, pas de sockets brutes. On n'écrit pas un worker de traitement vidéo. On y écrit des orchestrations, du routing, des transformations de payloads, des validations Zod, du fan-out. Pour les charges CPU-lourdes, on délègue à un backend régional ou à Cloudflare Containers (sorti en 2025), pas à un Worker.

Durable Objects (DO) est la primitive qui transforme Workers de « fonction sans état » en « plateforme à objets distribués ». Un DO est une instance unique, globalement adressable, qui possède un état privé et un stockage transactionnel fortement consistant. Concrètement : pour un identifiant donné (par exemple `room:project-42`), il n'existe qu'une seule instance vivante à la fois dans le monde entier, et toute écriture est sérialisée par cette instance. C'est le modèle d'acteur (Erlang/Akka) mis à portée d'une équipe produit.

Le stockage intégré (`ctx.storage`) propose une API transactionnelle clé-valeur avec cohérence forte, à 10 ms de latence pour un `put`/`get`. Plus besoin d'ajouter un Redis externe ou un Postgres dédié pour orchestrer un compteur distribué, une room WebSocket, un rate limiter global. Le DO porte l'état, le code et la cohérence dans un même périmètre, et il migre automatiquement vers le POP le plus proche du dernier écrivain.

Les cas d'usage où DO brille : éditeurs collaboratifs temps réel (CRDT ou OT centralisé), rate limiters globaux (Cloudflare lui-même utilise DO pour son produit Rate Limiting natif), présence et indicateurs en ligne, matchmaking de jeux multijoueur, files de priorité par utilisateur, registres de sessions. Sur ces charges, l'alternative « Postgres + websocket gateway + Redis pub/sub » représente typiquement 4 services à opérer. Un DO les remplace par une classe TypeScript de 150 lignes.

Trois patterns couvrent 90 % des charges que nous voyons en B2B premium. Pattern 1 — edge-first avec base régionale en fallback : Worker en façade pour auth, routing, transformation, cache KV, et lecture/écriture sur une base serverless edge-friendly (Turso pour SQLite distribué, Neon pour Postgres répliqué multi-région, PlanetScale pour MySQL). Latence p50 de 30 à 70 ms pour 95 % des utilisateurs, complexité d'ops contenue.

Pattern 2 — edge + Durable Object pour charges stateful : chaque session/room/document est adossée à un DO. Le Worker route vers le DO via `env.MY_DO.idFromName(roomId)`. Le DO porte l'état chaud (cursor positions, presence, locks) et persiste périodiquement vers la base régionale (snapshot, audit, archive). C'est ce que Figma implémente avec une architecture similaire (objects centralisés par document, edge pour le rendu) et ce que Discord utilise pour la présence via Cloudflare.

Pattern 3 — edge + Queues pour async : un Worker reçoit la requête, écrit un message dans Cloudflare Queues, retourne immédiatement 202 Accepted. Un consumer Worker traite en arrière-plan (génération de PDF, appels API tiers, webhooks sortants, embeddings IA). Latence perçue < 50 ms, débit absorbé sans backpressure sur l'edge. À combiner avec Cloudflare Workflows (sorti 2025) pour les pipelines multi-étapes avec retries et durées longues.

La question de la base se pose tôt. Règle pratique : si la donnée est mostly-read avec invalidation lente → KV (cache edge). Si elle est relationnelle et requiere SQL → Turso (edge SQLite), Neon (edge Postgres), ou PlanetScale (edge MySQL). Si elle est fortement stateful et collaborative → Durable Objects + snapshot périodique vers Neon/PlanetScale. Et si vous êtes en charges analytiques lourdes, restez en région : BigQuery, ClickHouse, Snowflake ne vivent pas à l'edge.

Figma (publiquement documenté dans leurs talks engineering) utilise un pattern d'objets centralisés par document qui préfigure Durable Objects : une instance unique par fichier multiplayer, migrations automatiques vers le datacenter le plus proche de l'activité, synchronisation par diff CRDT. La leçon : un éditeur collaboratif fluide à l'échelle mondiale ne s'obtient pas avec un Postgres central et des websockets — il faut un acteur étatique par document, exactement le modèle DO.

Discord utilise Cloudflare pour servir sa couche présence à plusieurs centaines de millions d'utilisateurs simultanés. Le défi : savoir qui est en ligne, dans quel serveur, sur quel canal, sans inonder les bases. La couche edge absorbe le bruit des heartbeats et agrège l'état avant de pousser vers le backend. C'est un exemple typique de la division du travail edge/région : l'edge gère le volume et la fraîcheur, la région gère la persistance durable.

Cloudflare lui-même s'appuie sur Durable Objects pour son produit Rate Limiting géré (announced et documenté en 2023-2024). Chaque bucket de rate limit est un DO adressé par `bucket:user-or-ip`, avec un compteur transactionnel. Cela permet à Cloudflare d'appliquer des limites globales cohérentes sans dépendre d'un Redis central, et de scaler à plusieurs millions de buckets sans opérations manuelles. Un cas d'école de la primitive DO.

Pour nos clients VALRY LABS, le cas d'usage le plus immédiat est le dashboard temps réel : un DO par tableau de bord agrège les webhooks entrants (Stripe, Linear, Vercel, Sentry), calcule les agrégats, et pousse les deltas via WebSocket/SSE aux viewers connectés. Latence évènement-à-écran typique : 80 à 150 ms monde entier, contre 400 à 900 ms avec une gateway régionale. Pour des KPIs de production ou de revenue ops, l'écart est perceptible et commercial.

Durable Objects a un modèle de prix à connaître. À fin 2025 : 12,50 $ par million de requêtes vers des DO, 12,50 $ par million de `alarm()` (scheduler intégré), et surtout 12,50 $ par million de « duration-seconds » (temps facturé à la seconde, plafonné par DO). Le stockage est facturé 0,75 $/Go/mois, et chaque opération de storage (get/put/list/transaction) coûte environ 1 $ par million. Sur une charge type chat collaboratif (100 salles actives, 50 msgs/s chacune), on tourne autour de 80 à 150 $/mois — raisonnable. Sur une charge type polling-agressif (1 requête/seconde par utilisateur connecté), la facture grimpe vite.

Les limites techniques méritent d'être tracées : 1 Mo maximum par clé de storage (au-delà, fragmenter ou utiliser R2), 1000 Durable Objects par Worker (limite « soft », levable sur demande), 128 Mo de mémoire par DO, 30 s de CPU par requête, pas de `setTimeout` au-delà de la durée de vie de la requête (utiliser les `alarm()` pour le scheduling durable). Ces plafonds ne sont pas rédhibitoires, mais ils imposent une discipline de design : petits objets, état chaud en mémoire, persistance par batch, alarmes pour le TTL.

La règle de décision coût : l'edge gagne quand la latence utilisateur est critique et la charge par session est modérée (chat, presence, dashboards, IA courte). La région gagne quand la charge par session est lourde (ETL, ML training, reporting analytique, batch) ou quand vous avez déjà un investissement Postgres/BigWare profond. Sur un volume de 10 req/s soutenus, l'edge coûte 5 à 15 $/mois. Sur un million de requêtes par minute, l'edge peut coûter 3 à 10 fois plus cher qu'une VM régionale autoscalée — à méditer avant de tout pousser en Workers.

Notre décisionnaire opérationnel : (1) Read-heavy, mondial, données < 1 Mo → KV + Worker. (2) Stateful collaboratif temps réel, état chaud < 128 Mo → Durable Object + snapshot. (3) Charges CPU ou DB relationnelles lourdes → région (Neon/PlanetScale + compute régional). (4) Charges async → Queues + Workers consumer. (5) Si doute sur le volume → démarrer en région, migrer l'edge sur le seul chemin qui pousse en latence. C'est ce cheminement qui nous a fait économiser un refactoring complet sur deux clients en 2025.

Pour 2026, nous anticipons trois bascules concrètes chez nos clients B2B premium. D'abord, l'edge-first deviendra le défaut pour toutes les charges Reads-héavy, collaboratives, et IA légère (classification, embeddings courts, routing). Le coût marginal de l'edge a baissé suffisamment pour que l'arbitrage se joue sur la latence, pas sur le budget. Ensuite, les bases serverless edge (Turso, Neon, PlanetScale) atteindront la maturité pour servir de socle transactionnel primaire sur 70 % des projets — pas seulement de cache.

Ensuite, Durable Objects va se banaliser comme primitif de référence pour les workloads stateful. Avec l'arrivée de SQLite dans DO (annoncé en 2024, généralisation 2025), un DO devient une mini-base SQL locale au POP, fortement consistante, qui se réplique vers la région en arrière-plan. C'est une primitive qui n'existait pas il y a 18 mois et qui change l'équation pour les éditeurs collaboratifs, les file-processing par utilisateur, et tout état chaud ayant une structure relationnelle.

Enfin, la séparation edge/région va se clarifier : edge pour le chemin critique utilisateur (latence, état chaud, présence, routing), région pour les charges lourdes (analytique, ETL, ML, persistance longue, conformité RGPD sur données sensibles). Pour les architectes, le travail de 2026 n'est pas de choisir edge OU région, mais de dessiner la frontière nette entre les deux — et de savoir justifier chaque placement de charge par un chiffre de latence, de coût, et de risque.