ADR: Choix technologique pour la Couche 03 (Backend) via FaaS et Edge Computing

• Statut : Accepté
• Date : 2026-09-01
• Auteur : Équipe Architecture IT

---

1. Contexte et Problématique

Les Couches 01 (Contenu via Sanity/Starlight) et 02 (Présentation via Astro en mode Hybride) étant définies, nous devons structurer la Couche 03 : Backend (Logique métier et services tiers).

Cette couche doit répondre à plusieurs impératifs :

• Performance globale : Minimiser la latence mondiale pour les utilisateurs, quel que soit leur emplacement géographique.
• Flexibilité d’exécution : Être capable de traiter aussi bien des opérations légères et immédiates (personnalisation à la volée) que des tâches métier plus lourdes (webhooks, traitement de formulaires, intégration d’API tierces, sauvegardes).
• Réutilisabilité cross-projets : La logique d’authentification, de routage bas niveau ou de sécurité (middleware) ne doit pas être prisonnière du framework de présentation Astro, car l’entreprise prévoit une stratégie multi-sites.
• Sécurité & Résilience Serverless : Éliminer les vulnérabilités réseau (Open Redirects, spams de formulaires), éviter la saturation des pipelines de déploiement (debouncing des webhooks), et respecter strictly les limites de ressources Serverless (RAM/CPU) lors de l’upload et des sauvegardes.

---

2. Décision Architecturale

Nous décidons d’adopter une architecture FaaS (Function-as-a-Service) couplée à l’Edge Computing, entièrement basée sur l’écosystème Cloudflare.

La couche backend est découpée selon quatre niveaux de traitement :

1. Edge Caching Strict : Les pages statiques (articles, landing pages, doc) sont servies instantanément depuis le Edge cache de Cloudflare.
2. Cloudflare Pages Functions : Utilisé pour le rendu SSR à la volée des pages Astro nécessitant une personnalisation légère.
3. Cloudflare Workers Dédiés (Microservices) : Microservices indépendants exposés sous forme d’API pour la logique métier lourde (form-handler, cms-webhook-receiver, media-upload, media-cleanup, sanity-backup).
4. Middleware Cloudflare Workers Indépendant : Isolation de la logique de contrôle réseau (CORS, CSP, détection de bots, validation sécurisée de la preview Sanity) au niveau de Cloudflare, en dehors d’Astro.

---

3. Justification du choix

3.1. Edge Caching (Pages Statiques)

La Vitrine, le Blog, le Portfolio et la Documentation sont générés au build. En les servant directement depuis le réseau Edge mondial de Cloudflare, le serveur d’origine n’est jamais sollicité par les utilisateurs finaux. Les temps de réponse se mesurent en millisecondes et le coût d’infrastructure est quasi nul.

3.2. Cloudflare Pages Functions (Personnalisation Légère)

Pour les routes Astro configurées en mode SSR (prerender = false), Astro utilise l’adaptateur @astrojs/cloudflare pour compiler ces routes en Pages Functions. S’exécutant sur l’infrastructure globale de Cloudflare (V8 isolates), elles permettent de personnaliser l’affichage ou d’injecter des données contextuelles sans subir les temps de démarrage à froid (cold starts).

3.3. Cloudflare Workers Dédiés (Microservices & Scalabilité)

Toute la logique découplée de l’interface est encapsulée dans des Cloudflare Workers autonomes :

• Gestion des formulaires (form-handler) : Validation Zod, vérification serveur Turnstile anti-spam, et résilience d’envoi.
• Récepteur de Webhooks Sanity (cms-webhook-receiver) : Validation cryptographique HMAC-SHA256 de la signature et mécanisme de debouncing (tampon KV de 2 min) pour empêcher la surchauffe du pipeline CI/CD lors d’éditions multiples.
• Gestion des médias (media-upload) : Utilisation d’URLs présignées R2 et de Cloudflare Stream Direct Upload pour permettre l’envoi direct depuis le client sans surcharger la mémoire des Workers.
• Maintenance & Sauvegardes (media-cleanup & sanity-backup) : Intégration de Safety Locks (interdiction de purge si l’API source flanche) et de Streaming HTTP (TransformStream) vers R2 pour garantir une empreinte mémoire constante (< 10 MB).

3.4. Middleware Externe (Découplage Multi-site & Sécurité)

En plaçant un Middleware directement sous forme de Cloudflare Worker en amont de la couche de présentation, nous interceptons les requêtes HTTP au niveau du réseau. Cette approche permet :

• De réutiliser le même middleware (sécurité, CSP, réécriture d’URLs, détection de bots) pour d’autres sites de l’entreprise.
• De sécuriser l’activation du mode Preview (validation HMAC, cookie httpOnly/Secure, protection anti-Open-Redirect) et de forcer le bypass du cache Edge (cf.cacheEverything = false).

---

4. Conséquences de la décision

Effets Positifs (Avantages)

• Performances extrêmes & Latence minimale : Exécution au plus proche de l’utilisateur sur le réseau Edge Cloudflare.
• Scalabilité infinie et coûts maîtrisés : Le modèle serverless absorbe les pics de trafic sans administration de serveur.
• Protection & Résilience applicative : Protection renforcée (Turnstile, CSP strict, HMAC) et préservation de la mémoire des Workers grâce au streaming et aux URLs présignées.
• Architecture multi-tenant / multi-site : Le middleware et les Workers de logique métier sont agnostiques et réutilisables.

Effets Négatifs (Inconvénients & Risques)

• Contraintes V8 Isolates : Obligation d’utiliser des APIs Web Standard (Fetch, Streams, Crypto) compatibles Cloudflare Workers.
• Complexité d’orchestration locale : Nécessite l’utilisation de Wrangler Monorepo pour exécuter simultanément les simulacres de Workers, du Middleware et du serveur de dev Astro.

---

5. Alternatives Exclues

• Middleware intégré à Astro : Exclu car il aurait lié la logique réseau à l’application Astro, empêchant sa réutilisation multi-site.
• Upload de médias traversant le Worker : Exclu en raison des limites de payload et de RAM des Workers. Les URLs présignées R2/Stream ont été retenues.
• Serveur monolithique traditionnel (ex: Express/Node.js sur un VPS) : Exclu en raison des coûts de maintenance, des risques de goulots d’étranglement, et d’une latence supérieure par rapport au Edge.