Edge functions : le futur du backend en 2026

Une fonction edge déployée sur 300 datacenters Cloudflare répond en 12ms à un user à Tokyo et 8ms à un user à Paris. Sans serveur à gérer. Sans scale à planifier. En 2026 c'est devenu standard, mais ce n'est pas une silver bullet. Voici le guide réaliste.

C'est quoi exactement une edge function

Une fonction edge, c'est du code JS/TS qui tourne sur un réseau de POPs (points of presence) répartis géographiquement. Quand un user fait une requête, le code s'exécute dans le POP le plus proche, pas dans un datacenter central.

Les principaux acteurs en 2026 :

• Cloudflare Workers : 300+ POPs, V8 isolates, gratuit jusqu'à 100K req/jour
• Vercel Edge Functions : basé sur Cloudflare, intégré Next.js
• Deno Deploy : edge Deno, compatible npm
• Netlify Edge Functions : basé sur Deno Deploy
• AWS Lambda@Edge : limité, pas vraiment compétitif

Les characteristics communes :

• Cold start quasi nul (50ms vs 1s+ pour Lambda)
• Latence réseau divisée par 5-10x
• Pas d'access au filesystem ou aux Node API natives
• Limites strictes (CPU time, memory, response size)

Hello world Cloudflare Workers

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    return new Response(`Hello from ${url.hostname}`);
  },
};

Deploy :

npx wrangler deploy

5 secondes plus tard, votre code tourne sur 300 POPs. C'est presque magique.

Hello world Vercel Edge Functions

Dans une route Next.js 16 :

// app/api/hello/route.ts
export const runtime = 'edge';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const name = searchParams.get('name') ?? 'World';
  return Response.json({ message: `Hello ${name}` });
}

Déployé automatiquement sur l'edge avec vercel deploy.

Le cas d'usage parfait : middleware d'auth

C'est LE killer use case. Avant :

• User à Tokyo fait une requête
• Round-trip Tokyo vers Paris (votre serveur) : 250ms
• Vérif JWT, redirect si pas auth : 5ms
• Réponse : 250ms supplémentaires
• Total : 505ms juste pour un check d'auth

Avec edge :

• User à Tokyo fait une requête
• Edge à Tokyo vérifie le JWT : 8ms
• Si auth OK, proxie vers le backend
• Total : 8ms pour le check

Exemple Next.js middleware (toujours edge par défaut) :

// middleware.ts
import { NextResponse } from 'next/server';
import { jwtVerify } from 'jose';

export async function middleware(request: Request) {
  const token = request.cookies?.get('token')?.value;
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  try {
    await jwtVerify(token, new TextEncoder().encode(process.env.JWT_SECRET));
    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL('/login', request.url));
  }
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
};

Un user au Japon est protégé en 8ms au lieu de 500ms. La différence est massive sur l'UX.

Cas d'usage 2 : géolocalisation et personnalisation

L'edge sait d'où vient l'user (header cf-ipcountry chez Cloudflare). Vous pouvez personnaliser sans round-trip :

// Cloudflare Worker
export default {
  async fetch(request: Request): Promise<Response> {
    const country = request.headers.get('cf-ipcountry') ?? 'FR';

    const config = {
      FR: { currency: 'EUR', lang: 'fr', vat: 20 },
      US: { currency: 'USD', lang: 'en', vat: 0 },
      DE: { currency: 'EUR', lang: 'de', vat: 19 },
    };

    return Response.json(config[country] ?? config.FR);
  },
};

Cas d'usage 3 : A/B testing sans flicker

export async function middleware(request: Request) {
  const url = new URL(request.url);
  if (url.pathname !== '/') return NextResponse.next();

  let variant = request.cookies.get('variant')?.value;
  if (!variant) {
    variant = Math.random() > 0.5 ? 'A' : 'B';
  }

  url.pathname = `/variants/${variant}`;
  const response = NextResponse.rewrite(url);
  response.cookies.set('variant', variant, { maxAge: 30 * 24 * 60 * 60 });
  return response;
}

Le user reçoit directement la bonne variante, sans flash, sans JS client.

Cas d'usage 4 : streaming AI responses

export const runtime = 'edge';

export async function POST(request: Request) {
  const { prompt } = await request.json();

  const stream = new ReadableStream({
    async start(controller) {
      const response = await fetch('https://api.anthropic.com/v1/messages', {
        method: 'POST',
        headers: {
          'x-api-key': process.env.ANTHROPIC_API_KEY!,
          'content-type': 'application/json',
          'anthropic-version': '2023-06-01',
        },
        body: JSON.stringify({
          model: 'claude-opus-4-7',
          max_tokens: 1024,
          stream: true,
          messages: [{ role: 'user', content: prompt }],
        }),
      });

      const reader = response.body!.getReader();
      while (true) {
        const { done, value } = await reader.read();
        if (done) break;
        controller.enqueue(value);
      }
      controller.close();
    },
  });

  return new Response(stream, {
    headers: { 'content-type': 'text/event-stream' },
  });
}

L'edge proxie l'API Anthropic. La réponse streame mot par mot vers l'user, sans buffering.

Les vraies limitations

Limite 1 : pas de Node API natives

// MAUVAIS : ne marche pas en edge
import fs from 'fs';
const data = fs.readFileSync('./data.json');

Vous avez Web Crypto, fetch, URL, Headers, etc. Mais pas fs, pas de spawn de processus, pas de drivers DB natifs.

Limite 2 : CPU time strict

• Cloudflare Workers : 50ms CPU par requête (plan paid : jusqu'à 30s)
• Vercel Edge : 25s wall time
• Lambda@Edge : 5s

Un calcul lourd (image processing, ML inference) ? Pas pour l'edge.

Limite 3 : taille du bundle

• Cloudflare Workers : 10 MB max (compressed 3 MB free tier)
• Vercel Edge : 4 MB initial bundle

Finies les libs lourdes (puppeteer, sharp, etc.). Préférez des HTTP APIs externes.

Limite 4 : DB connections

Les edge functions sont serverless distribuées. Une connexion Postgres standard ne marche pas (pool exhausté en 5 minutes).

Solutions :

• Drivers HTTP : Neon HTTP, Supabase REST, Turso
• Connection pooler : pgBouncer, Supabase pooler, Hyperdrive
• Caching agressif : KV, Cache API

// Drizzle + Neon HTTP, marche en edge
import { neon } from '@neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-http';
import { users } from './schema';

export const runtime = 'edge';

export async function GET() {
  const sql = neon(process.env.DATABASE_URL!);
  const db = drizzle(sql);
  const result = await db.select().from(users).limit(10);
  return Response.json(result);
}

💡 Vous voulez qu'on déploie votre backend sur l'edge pour vous ? On en discute 15 minutes : rdv.lenobot.com.

Combien ça coûte vraiment ?

App client (1M requêtes/mois, calculs simples).

| Plateforme | Coût mensuel | |------------|--------------| | Cloudflare Workers (Paid) | 5$ flat | | Vercel Edge Functions | 20$ (Hobby Pro) | | AWS Lambda@Edge | ~12$ | | Deno Deploy | gratuit (1M req/mois) | | Netlify Edge | 0$ (Free tier) |

À 100M requêtes/mois ça change :

| Plateforme | Coût mensuel | |------------|--------------| | Cloudflare Workers | 35$ | | Vercel Edge | 240$ | | AWS Lambda@Edge | 240$ |

Cloudflare casse le marché en pricing edge. C'est notre default depuis 2024.

Quand NE PAS utiliser l'edge

• Background jobs longs : utilisez des queues (SQS, BullMQ)
• CPU intensif : préférez Lambda classique ou container
• Filesystem nécessaire : container ou VPS
• DB writes en cascade complexe : restez en backend traditionnel
• Code legacy avec deps Node natives : pas d'edge

L'architecture hybride 2026

La stack qu'on déploie le plus chez Lenobot :

User request
  vers
Cloudflare Worker (edge)
  vers (auth, géoloc, A/B test, cache check)
  - Hit cache : réponse directe
  - Miss : backend Express sur VPS Hetzner
      vers
      Postgres self-hosted

Le meilleur des deux mondes : latence edge pour 80% des requêtes, backend stable pour la logique complexe.

Verdict 2026

L'edge n'est plus une mode, c'est un outil mature. Mais ce n'est pas un remplacement universel du backend traditionnel. C'est une couche additionnelle qui résout des problèmes spécifiques : latence globale, cold start, scale élastique pour de la logique légère.

Dans une stack Next.js moderne, le middleware edge est non-négociable. Pour le reste, mesurez avant de migrer.

Prêt à déployer une couche edge pour accélérer votre backend en 2026 ? Notre équipe de devs seniors vous accompagne. Réservez votre appel découverte gratuit sur rdv.lenobot.com, 15 minutes pour évaluer votre projet, devis ferme sous 48h, sans engagement.

Article rédigé par L'équipe Lenobot.