Architecture edge : quand ça vaut le coup et quand ça ne vaut pas

Tous les six mois, un nouveau framework « edge-first » sort et le débat repart de zéro. La réponse honnête : les runtimes edge sont un choix fantastique pour environ 20 % des workloads, et une contrainte supplémentaire pour les 80 % restants.

Voici comment je décide.

Les 20 % où l’edge gagne clairement

Trois patterns où le calcul est sans appel :

1. Les APIs requête/réponse sans état qui doivent être rapides partout dans le monde. Vérifications d’auth, feature flags, routage géographique, transformations d’images. Le cold start est votre ennemi — et l’edge n’en a pas.
2. L’ingestion de webhooks qui fan out. Recevoir, vérifier la signature, enqueue. L’unité de travail entière prend moins de 50 ms. Payer pour un serveur permanent n’a aucun sens.
3. Projets perso et side projects où le coût d’ops compte plus que la performance maximale. Zéro serveur, zéro patch, zéro alertes.

Les 80 % où l’edge est le mauvais outil

Les cas d’échec sont prévisibles :

1. Calcul longue durée. Les workers edge ont des limites de temps CPU. Générer un rapport, rendre un PDF, transformer un batch — ces tâches ont leur place sur un serveur classique.
2. Dépendances natives lourdes. Node crypto, sharp, tout ce qui a un binding natif. Le sous-ensemble V8 est bien réel, même avec les flags de compatibilité Node.
3. Connexions persistantes. WebSockets à scale, connection pooling de base de données, sessions avec état. L’edge n’a pas de mémoire entre les requêtes et ne peut pas garder une connexion ouverte.

Oui, des contournements existent pour tout ça. Ce sont des contournements.

Le signal le plus fiable : si votre handler dépasse 500 ms de temps CPU, vous combattez le runtime au lieu de l’utiliser.

Ce que « edge » change vraiment dans votre code

On parle de l’edge comme d’un choix de déploiement. C’est en réalité un choix de modèle de programmation :

• Pas de filesystem en écriture → tout l’état est externalisé.
• Streaming en premier → vos handlers retournent des objets Response, pas des blobs JSON.
• APIs Node limitées → le sous-ensemble V8 est réel, même avec les flags de compatibilité.
• Limites sur les sous-requêtes → vous ne pouvez pas fan out 200 appels parallèles dans un seul handler.

Si ces contraintes vous semblent libératrices, l’edge vous rendra plus rapide. Si elles vous semblent étouffantes, restez sur un runtime Node classique. Il n’y a pas de honte.

Le pattern hybride que je livre vraiment

Pour la plupart des produits, je fais tourner une fine couche proxy edge devant un backend Node classique :

• L’edge gère : auth, géo, cache, rate limiting, lectures légères.
• Node gère : transactions en base, jobs en arrière-plan, tout ce qui est stateful.

Vous obtenez un TTFB rapide sur les 80 % de requêtes ordinaires sans réécrire les parties de votre app qui n’ont rien à faire sur l’edge.

C’est la réponse ennuyeuse. C’est aussi celle qui fonctionne.