En bref

Les Edge Functions conviennent à la personnalisation légère, au routage et à la détection géographique ; le runtime Node reste nécessaire pour la logique lourde, les requêtes en base et les appels IA longs. Elles n'ont pas accès aux API Node, ce qui exclut certains SDK comme Prisma classique ou node-postgres en direct.

Les Edge Functions Vercel ont beaucoup progressé en 2024 : latence < 100 ms à peu près partout, cold start < 50 ms. Mais elles ne remplacent pas tout — leurs limites sont réelles.

Règle rapide : Edge pour de la personnalisation légère, du routing, du geo-detection. Node Runtime pour de la logique lourde, DB queries, appels IA long.

Où l'Edge brille

  • Middleware d'auth (JWT verify)
  • A/B testing dynamique
  • Redirections localisées
  • Personnalisation légère basée sur cookies

Où l'Edge trahit

  • Pas d'accès Node APIs (fs, child_process, certains npm packages)
  • Timeout serré (25 s Vercel Pro)
  • Bundle limité à 4 Mo
  • Certains SDK Node (Prisma classique, node-postgres direct) ne marchent pas

Alternatives

  • Cloudflare Workers pour du full edge
  • Node Runtime Vercel pour la logique riche
  • Fluid Compute (Vercel 2024) — hybride, souvent le meilleur choix
Une Edge Function bien placée fait gagner 200 ms perçus par utilisateur. Mal placée, elle vous force à réécrire.

On regarde votre archi ?

En 30 minutes on peut identifier ce qui gagne à passer en Edge. Réservez un appel. À lire : Serverless vs container.

Un projet à lancer ou à sauver ?

30 min d'appel gratuit. On regarde ensemble ce qui bloque et par où commencer.

Réserver un appel découverte