Un visiteur à Sydney charge votre site hébergé en France. Le CDN met déjà les images à Sydney. Mais chaque requête HTML repart en Europe pour vérifier un cookie de session — quatre cents millisecondes de plus. L'équipe parle d'« edge computing » sans savoir si elle doit y mettre le panier, le blog statique ou la recherche full-text Postgres.
L'edge computing, c'est exécuter un peu de logique au plus près du visiteur — pas déplacer toute votre stack. La question utile : quelles millisecondes coûtent cher en aller-retour origine, et lesquelles n'ont pas besoin de la base ?
Trois couches — ne pas confondre
| Couche | Rôle | Exemple |
|---|---|---|
| CDN cache | Servir octets déjà calculés | CSS, images, JS |
| Edge compute | Calcul léger par requête | Auth, geo redirect, A/B |
| Origine | Vérité métier + DB | Checkout, compte client |
Accélérez au edge ce qui est idempotent, cacheable ou sans état durable. Gardez en origine ce qui écrit en base ou exige des transactions.
Mettre Postgres « au edge » est un anti-pattern. Mettre une décision de routage au edge en est un bon.
Cas d'usage concrets
Routage géographique — /fr/ versus /de/ selon Accept-Language ou pays, sans aller-retour application.
Authentification edge — validation JWT ou cookie signé au POP ; l'origine reçoit une identité déjà vérifiée.
Personnalisation légère — bannière promo, feature flag, page de maintenance.
Agrégation lecture seule — fusionner deux ou trois APIs publiques en une réponse cacheable soixante secondes.
Protection — limitation de débit, score bot avant origine — voir WAF et DDoS petit site.
Complétez avec CDN premier usage si vous débutez au cache statique.
Limites techniques
Temps processeur limité — millisecondes à secondes, pas jobs longs. Pas de disque local durable — KV edge ou cache TTL uniquement. Cohérence complexe — invalidation de cache difficile, contenu périmé possible. Débogage pénible — reproduire un bug « seulement au POP Brésil » exige des journaux edge. Verrouillage fournisseur — Workers, Lambda@Edge, Fastly Compute@Edge : APIs différentes.
RGPD et souveraineté
L'edge implique un traitement — parfois de données personnelles — sur l'infrastructure du fournisseur, parfois hors UE. Posez ces questions : quels POP pour visiteurs UE ? Les cookies de session passent-ils par un POP américain ? Les journaux edge contiennent-ils IP et user-agent stockés où ?
Pour données sensibles, limitez l'edge au statique ou choisissez des acteurs documentant des POP UE. Voir RGPD hébergeur et Cloud Act.
Quand ne pas utiliser l'edge
Ne déplacez pas au edge : requêtes d'écriture en base, sessions stockées en origine sans cache, personnalisation basée sur historique client complet, ou logique métier qui exige transactions ACID. Ne déplacez pas non plus des jobs longs (génération PDF lourde, transcodage vidéo) — les limites CPU des Workers ou Lambda@Edge couperont l'exécution.
L'edge brille sur le chemin lecture chaud : assets, décisions de routage, validation token, agrégation cacheable. Tout le reste reste en origine ou dans une région centrale — et c'est normal. Avant tout projet edge, profilez une page réelle avec WebPageTest : vous saurez en dix minutes si le gain potentiel vaut la complexité opérationnelle.
Le sommet : accélérer le mauvais composant n'accélère pas le site
Décider et avancer sans angle mort
Analysez la cascade réseau via WebPageTest depuis deux ou trois régions. Identifiez les allers-retours origine évitables. Prototypez un Worker ou une route edge sur un chemin lecture. Mesurez le percentile 95 avant et après plus la charge origine. Documentez le périmètre RGPD de l'edge — cookies, journaux, POP utilisés. Comparez CDN et edge intégrés dans l'annuaire et le comparateur avant de lier votre architecture à un seul fournisseur.
Questions fréquentes
Edge remplace l'origine ?
Non pour le cœur avec état. Edge cache, filtre, décide ; la base reste en origine.
CDN vs edge compute ?
CDN sert fichiers ; edge exécute code au POP.
Edge US et RGPD ?
Cartographiez les données personnelles ; POP UE ou origine seule pour le sensible.
Cloudflare Workers suffisants ?
Souvent oui pour réécriture/auth/cache sélectif. Testez limites processeur et charge.
Edge computing : accélérer ce qui n'a pas besoin de votre base — pas déplacer votre base sous prétexte de proximité.