Votre facture Vercel arrive à 847 $ pour mars — votre site marketing Next.js, 40 000 visites, trois fonctions serverless. Vous ouvrez le détail de la facture et regardez les lignes s'accumuler : dépassements de bande passante, invocations de fonction, optimisation d'image. Le même site sur AWS avec OpenNext coûte 23 $/mois. J'ai migré trois applications de production au cours de l'année écoulée — une vitrine e-commerce générant 2 M $ annuels, un tableau de bord SaaS avec 8 000 utilisateurs actifs, un portfolio d'agence. Chaque migration a pris moins de quatre heures. Chaque a réduit les coûts d'hébergement de 91–97 %. Les métriques de performance sont restées stables ou se sont améliorées. Mais voici ce que la documentation OpenNext ne vous dira pas : le premier déploiement échouera, votre middleware cassera de manière subtile, et vous passerez un après-midi à déboguer les en-têtes de cache. C'est le guide de migration que j'aurais aimé avoir en janvier 2025 quand notre première facture a dépassé quatre chiffres.

Ce n'est pas un article « Vercel c'est mal ». Vercel est véritablement excellent. Mais ce n'est plus la seule option, et pour de nombreuses équipes, ce n'est pas la bonne. Laissez-moi vous faire découvrir tout ce que j'ai appris sur l'auto-hébergement de Next.js avec OpenNext — le bon, le mauvais, et le remarquablement abordable.

Table des matières

OpenNext: Self-Host Next.js on AWS, Cloudflare, or VPS Without Vercel

Qu'est-ce qu'OpenNext et pourquoi existe-t-il

Next.js a été conçu pour s'exécuter sur Vercel. Ce n'est pas une conspiration — c'est de l'architecture. Des fonctionnalités comme ISR (Incremental Static Regeneration), les middlewares, l'optimisation d'image et les actions serveur ont tous des implémentations spécifiques à Vercel intégrées. Quand vous essayez de next start sur un serveur aléatoire, vous ne récupérez qu'un sous-ensemble de ce que Next.js peut faire.

OpenNext est un adaptateur open source qui prend votre sortie de build Next.js et la transforme en packages de déploiement qui fonctionnent sur d'autres plateformes. Il a commencé comme un projet communautaire SST axé sur AWS Lambda, mais à partir de la v3 (la version majeure actuelle en 2026), il supporte plusieurs cibles de déploiement, notamment Cloudflare Workers, les serveurs Node.js traditionnels, et plus.

Voici ce qu'OpenNext gère réellement :

  • ISR et revalidation — Le système de revalidation basé sur les tags que Vercel implémente avec son infrastructure interne ? OpenNext le récréé en utilisant DynamoDB + SQS sur AWS, ou les magasins KV sur Cloudflare.
  • Optimisation d'image — Le composant <Image> de Next.js repose sur une API d'optimisation. OpenNext empaquète un optimiseur basé sur Sharp ou routage vers des solutions spécifiques à la plateforme.
  • Middleware — S'exécute à la périphérie sur Vercel. OpenNext le mappe aux fonctions CloudFront, à Cloudflare Workers, ou l'exécute in-process sur VPS.
  • Actions serveur — Support complet, routé via la fonction serveur appropriée.
  • Streaming et prerendering partiel — Le support a considérablement mûri dans OpenNext v3.x.

Ce qu'OpenNext n'est pas

Ce n'est pas une plateforme d'hébergement. Ce n'est pas un CDN. C'est un adaptateur de build — une couche de traduction entre la sortie de Next.js et votre infrastructure. Vous devez toujours faire fonctionner le code quelque part.

Le paysage de l'auto-hébergement en 2026

L'écosystème a explosé depuis que j'ai commencé à regarder cela. Voici où les choses en sont :

Plateforme Support OpenNext Maturité Idéal pour
AWS (via SST) Première classe Prêt pour la production Équipes déjà sur AWS
Cloudflare Workers Adaptateur officiel Stable (quelques cas limites) Applications edge-first, optimisation des coûts
Docker/VPS Communauté + officiel Stable Déploiements simples, infrastructure existante
Kubernetes Graphiques Helm communautaires En maturation Entreprise, clusters K8s existants
Netlify Intégré (adaptateur propre) Prêt pour la production Équipes engagées envers Netlify
Google Cloud Run Communauté Expérimental Boutiques GCP

Les deux chemins que j'ai personnellement testés en bataille et pour lesquels je peux vous garantir sont AWS via SST et Docker sur VPS. Cloudflare est le nouveau venu excitant qui s'améliore mensuellement.

Cible de déploiement : AWS avec SST

C'est le chemin idéal. SST (Serverless Stack) dispose du support intégré de Next.js alimenté par OpenNext, et c'est là que la majorité des efforts d'ingénierie ont été concentrés.

Aperçu de l'architecture

Quand vous déployez Next.js via SST sur AWS, voici ce qui est créé :

  • Distribution CloudFront — Votre CDN, gère les ressources statiques et le routage
  • Fonction(s) Lambda — Rendu côté serveur, routes API, actions serveur
  • Compartiment S3 — Ressources statiques, pages pré-rendues, cache ISR
  • Table DynamoDB — Mappage de tags ISR pour revalidation
  • File d'attente SQS — Traitement asynchrone de revalidation
  • Fonction CloudFront ou Lambda@Edge — Exécution du middleware

Cela semble beaucoup. C'est le cas. Mais SST l'abstrait en environ 20 lignes de configuration.

Configuration SST

Voici un vrai sst.config.ts d'un de mes projets de production :

/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-nextjs-app",
      removal: input.stage === "production" ? "retain" : "remove",
      home: "aws",
      providers: {
        aws: {
          region: "us-east-1",
        },
      },
    };
  },
  async run() {
    const site = new sst.aws.Nextjs("Site", {
      domain: {
        name: "myapp.com",
        dns: sst.aws.dns(),
      },
      warm: 5, // keep 5 Lambda instances warm
      memory: "1024 MB",
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
        NEXT_PUBLIC_API_URL: "https://api.myapp.com",
      },
    });

    return {
      url: site.url,
    };
  },
});

Puis déployez :

npx sst deploy --stage production

Le premier déploiement prend 8-12 minutes (propagation de la distribution CloudFront). Les déploiements ultérieurs prennent 2-4 minutes.

Considérations Lambda

Le plus gros inconvénient de l'hébergement basé sur Lambda est les démarrages à froid. Les fonctions serveur Next.js ne sont pas petites — vous regardez des bundles de 20-80MB selon vos dépendances. Les démarrages à froid vont de 800ms à 3 secondes.

Les atténuations que j'ai utilisées :

  1. Concurrence provisionée — Le paramètre warm de SST garde les instances actives. À $0,0000041667 par Go-seconde, garder 5 instances d'une fonction de 1 Go au chaud coûte environ 15 $/mois.
  2. Bundles plus petits — Auditez vos dépendances côté serveur. J'ai trouvé un projet important lodash côté serveur alors que nous n'avions besoin que de lodash/get. Le bundle est passé de 68 Mo à 31 Mo.
  3. Déploiement régional — N'utilisez pas Lambda@Edge pour SSR à moins que vous en ayez absolument besoin. Lambda à région unique avec cache CloudFront est parfait pour 95 % des applications.

OpenNext: Self-Host Next.js on AWS, Cloudflare, or VPS Without Vercel - architecture

Cible de déploiement : Cloudflare Workers

Cloudflare fait des progrès sérieux. Leur runtime Workers supporte maintenant suffisamment d'APIs Node.js pour que Next.js puisse réellement s'y exécuter, et l'adaptateur OpenNext Cloudflare est devenu remarquablement stable.

Configuration avec OpenNext Cloudflare

npm install @opennext/cloudflare

Ajoutez à votre wrangler.toml :

name = "my-nextjs-app"
main = ".open-next/worker.js"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat_v2"]

[assets]
directory = ".open-next/assets"
binding = "ASSETS"

[[kv_namespaces]]
binding = "NEXT_CACHE_KV"
id = "your-kv-namespace-id"

Buildez et déployez :

npx @opennext/cloudflare build
npx wrangler deploy

Les compromis de Cloudflare

Avantages :

  • Pas de démarrages à froid — Les Workers se lancent en moins de 5ms mondialement
  • Edge global par défaut — Votre SSR s'exécute en 300+ emplacements
  • Tarification absurde — 5 $/mois pour 10 millions de requêtes sur le plan payant

Inconvénients :

  • Limites de mémoire — 128 Mo gratuit, 256 Mo payant. Les grandes applications Next.js peuvent atteindre cette limite.
  • Limites de temps CPU — 30 secondes sur le plan payant. Les pages SSR lourdes peuvent être un problème.
  • Lacunes de compatibilité Node.js — La plupart des choses fonctionnent, mais si vous utilisez des modules Node natifs comme sharp directement, vous aurez besoin de contournements. Cloudflare Images peut gérer l'optimisation à la place.
  • Certaines fonctionnalités Next.js ne sont pas supportées — Dès le début 2026, le support du prerendering partiel est toujours expérimental sur Cloudflare.

Pour les sites riches en contenu et les pages marketing, Cloudflare Workers est incroyablement convaincant. Pour les applications web complexes avec logique côté serveur lourde, je pencherais toujours vers AWS ou Docker.

Cible de déploiement : VPS avec Docker

Parfois, vous voulez simplement un serveur. Pas de fonctions Lambda, pas de runtime edge, pas de diagramme d'architecture de 47 services. Une boîte qui exécute votre code. Je respecte cela.

Le Dockerfile

Voici le Dockerfile de production que j'utilise. Il est multi-stage, optimisé, et fonctionne réellement :

# Stage 1: Dependencies
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable pnpm && pnpm install --frozen-lockfile

# Stage 2: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production

RUN corepack enable pnpm && pnpm build

# Stage 3: Production
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

CMD ["node", "server.js"]

Critique : vous avez besoin de output: 'standalone' dans votre next.config.js :

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

Recommandations VPS

J'ai exécuté cette configuration sur plusieurs fournisseurs :

Fournisseur Spécification Coût mensuel Notes
Hetzner CAX21 4 vCPU ARM, 8 Go de RAM €7,49 (~$8) Meilleur rapport qualité-prix, datacenters UE
DigitalOcean Droplet 2 vCPU, 4 Go de RAM $24 Bonne couverture US
Fly.io (machine) 2 vCPU, 4 Go de RAM ~$30 Auto-scaling, régions globales
Railway Usage-based $5-50 Configuration la plus facile, DX style Vercel
AWS EC2 t4g.medium 2 vCPU, 4 Go de RAM ~$25 Déjà sur AWS

Pour un déploiement Docker direct, Hetzner offre un rapport qualité-prix absurdement bon. J'exécute une application Next.js servant 2M+ pages vues/mois sur une instance Hetzner ARM à €7,49 derrière le niveau CDN gratuit de Cloudflare. Le serveur peut à peine transpirer.

Ce que vous perdez avec Docker/VPS

Soyons honnêtes sur ce que next start sur un VPS ne vous donne pas comparé à Vercel ou à la configuration SST :

  • La revalidation ISR est basique — Cache du système de fichiers uniquement. Pas de cache distribué sur plusieurs instances. Si vous exécutez un seul serveur, c'est bien. Plusieurs serveurs ? Vous avez besoin de Redis ou d'une couche de cache partagée.
  • Pas de middleware edge — Le middleware s'exécute in-process, ce qui est tout à fait acceptable pour la plupart des cas d'usage.
  • Optimisation d'image — Fonctionne via Sharp, mais vous servez des images optimisées de votre seule origine. Mettez Cloudflare ou un CDN devant.
  • Pas de déploiements atomiques — Vous devez gérer vous-même les déploiements sans temps d'arrêt (Docker Compose avec contrôles de santé, ou un proxy inverse comme Caddy/Traefik).

Pour la plupart des applications chez Social Animal, en particulier les builds de CMS headless que nous réalisons dans le cadre de notre travail de développement CMS headless, un seul VPS avec un CDN devant est parfaitement adéquat.

Comparaison des coûts : Vercel vs Auto-hébergé

Parlez-moi d'argent. Ceci est basé sur des données de facturation réelles d'une application Next.js effectuant ~5M requêtes/mois avec ISR, optimisation d'image et rendu côté serveur modéré.

Facteur de coût Vercel Pro Vercel Enterprise AWS/SST Cloudflare Hetzner VPS
Plateforme de base $20/utilisateur/mois Personnalisé (~$3k+/mois) $0 $5/mois €7,49/mois
Calcul/requêtes $150-400/mois Inclus $40-80/mois $0-15/mois Inclus
Bande passante (100 Go) Inclus Inclus $8,50 (CloudFront) Inclus Inclus
Optimisation d'image $50-200/mois Inclus $5-15/mois (Lambda) $5/mois (CF Images) Inclus (Sharp)
ISR/Cache Inclus Inclus $2-5/mois (DynamoDB) $0-5/mois (KV) $0
Total estimé $300-700/mois $3 000+/mois $55-110/mois $10-25/mois $8-15/mois

Ces chiffres Vercel ne sont pas hypothétiques. J'ai vu les factures. La tarification par siège, les surcharges d'exécution de fonction et les frais de bande passante sur le niveau Pro s'ajoutent rapidement pour les équipes de 5+.

Les chiffres AWS/SST supposent un trafic modéré avec concurrence provisionée. La tarification de Cloudflare est véritablement sauvage — il est difficile de dépenser de l'argent réel là-bas à moins que vous fassiez quelque chose d'exotique.

Quand quitter Vercel

Ne partez pas juste parce que vous le pouvez. Partez parce que vous devriez. Voici mon cadre :

Restez sur Vercel si :

  • Votre équipe est petite (1-3 devs) et le temps des développeurs est votre ressource la plus chère
  • Vous dépensez moins de 100 $/mois sur Vercel
  • Vous n'avez personne qui aime le travail d'infrastructure
  • Vous itérez rapidement et avez besoin d'aperçus instantanés pour chaque PR
  • Vous utilisez des fonctionnalités spécifiques à Vercel comme Analytics, Speed Insights ou les intégrations Vercel AI SDK

Quittez Vercel si :

  • La facture mensuelle dépasse 500 $ et augmente
  • Vous avez besoin d'infrastructure dans des régions spécifiques pour la conformité (RGPD, résidence des données)
  • Vous exécutez déjà une infrastructure AWS/GCP/Cloudflare importante
  • Les démarrages à froid sur serverless sont inacceptables pour votre cas d'usage
  • Vous avez besoin de stratégies de cache personnalisées qui ne correspondent pas au modèle de Vercel
  • Vous avez atteint les limites de taille de fonction ou de temps d'exécution de Vercel

Envisagez sérieusement de partir si :

  • Vous êtes sur la tarification Vercel Enterprise et le renouvellement du contrat vient d'arriver
  • Votre application est principalement statique/ISR et vous payez les prix SSR dynamiques
  • Vous voulez exécuter votre frontend aux côtés de votre backend dans la même infrastructure

Le guide de migration

J'ai fait cela trois fois maintenant. Voici le processus que je suis, affiné par une expérience douloureuse.

Étape 1 : Auditez vos fonctionnalités Next.js

Avant de toucher à quoi que ce soit, cataloguez quelles fonctionnalités Next.js vous utilisez réellement :

# Find middleware
find . -name "middleware.ts" -o -name "middleware.js"

# Find API routes
find ./app -name "route.ts" -o -name "route.js" | head -20

# Check for ISR
grep -r "revalidate" ./app --include="*.ts" --include="*.tsx" | head -20

# Check for server actions
grep -r "use server" ./app --include="*.ts" --include="*.tsx" | head -20

# Check next.config for special features
cat next.config.js

Étape 2 : Choisissez votre cible

En fonction de l'audit :

  • ISR lourd + middleware + optimisation d'image → AWS/SST
  • SSR simple + site de contenu → Cloudflare ou VPS
  • Infrastructure Docker/K8s existante → VPS/Docker
  • Besoin d'être fait vendredi → Docker sur Railway ou Fly.io

Si vous construisez avec Next.js ou Astro, le choix de la plateforme cible affecte considérablement vos décisions architecturales.

Étape 3 : Configurer CI/CD

Le CI/CD de Vercel est véritablement excellent. Vous en aurez besoin. Répliquez-le avec GitHub Actions :

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm test

      # For SST:
      - run: npx sst deploy --stage production
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      # For Docker/VPS (alternative):
      # - run: docker build -t myapp .
      # - run: docker push registry.example.com/myapp:latest
      # - run: ssh deploy@server 'cd /app && docker compose pull && docker compose up -d'

Étape 4 : Déploiements d'aperçu

C'est la chose que les gens manquent le plus de Vercel. Pour SST, utilisez les stages :

# In your PR CI workflow
npx sst deploy --stage pr-${{ github.event.pull_request.number }}

Pour Docker, des outils comme Coolify (auto-hébergé) ou Railway gèrent bien les déploiements d'aperçu.

Étape 5 : Basculement DNS

Le moment actuel de la migration. Je recommande toujours :

  1. Déployez sur une nouvelle infrastructure aux côtés de Vercel
  2. Testez complètement avec un domaine de staging
  3. Baissez le TTL DNS à 60 secondes une jour avant
  4. Coupez DNS pendant les heures de faible trafic
  5. Gardez le déploiement Vercel en cours d'exécution pendant 48 heures comme fallback
  6. Surveillez attentivement les taux d'erreur, TTFB et Core Web Vitals

Étape 6 : Démontez Vercel

Une fois que vous êtes confiant (donnez-le au moins une semaine), annulez l'abonnement Vercel et supprimez le projet. Ne laissez pas de projets zombies facturer des frais.

Pièges courants et comment les éviter

Les variables d'environnement disparaissent. Next.js a des variables avec préfixe NEXT_PUBLIC_ (regroupées au moment de la build) et des variables serveur uniquement (disponibles au runtime). Sur Vercel, cette distinction est quelque peu floue. En auto-hébergement, c'est strict. Assurez-vous que toutes les variables NEXT_PUBLIC_ sont disponibles au moment de la build dans votre CI.

Le cache ISR ne persiste pas. Sur Docker, le répertoire .next/cache doit être sur un volume persistant. Sinon, chaque redémarrage de conteneur perd vos pages en cache :

# docker-compose.yml
services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - next-cache:/app/.next/cache

volumes:
  next-cache:

Échecs d'installation de Sharp. La bibliothèque d'optimisation d'image sharp a besoin de binaires spécifiques à la plateforme. Dans Docker, assurez-vous d'installer les dépendances dans la même architecture que votre runtime. Le Dockerfile ci-dessus gère cela en utilisant des builds multi-stage avec la même image de base.

Différences de comportement du middleware. Vercel exécute le middleware sur son réseau edge. Sur AWS/SST, il s'exécute en tant que CloudFront Function (limité à 10ms d'exécution, taille de 2 Mo). Le middleware complexe pourrait avoir besoin d'être déplacé vers la fonction serveur. J'ai dû refactoriser le middleware d'authentification à cause de ces limites.

En-têtes et rewrites manquants. Si vous comptiez sur vercel.json pour les en-têtes, les redirections ou les rewrites, vous devez les déplacer vers la configuration next.config.js ou votre CDN/proxy inverse.

Si tout cela semble accablant, c'est exactement le type de travail d'infrastructure que nous gérons chez Social Animal. Consultez notre tarification ou contactez-nous — nous avons fait suffisamment de migrations pour avoir un processus affiné.

FAQ

OpenNext est-il prêt pour la production en 2026 ?

Oui. OpenNext v3.x s'exécute sur des charges de travail de production pour des milliers d'entreprises. Le chemin SST/AWS est le plus testé en bataille, avec le support Cloudflare de près derrière. Je ne qualifierais pas le support Google Cloud ou Kubernetes nu de mature à ce stade, mais AWS et Cloudflare sont solides.

OpenNext supporte-t-il Next.js App Router et Server Components ?

Support complet. App Router, Server Components, Server Actions, streaming et Suspense fonctionnent tous. L'équipe OpenNext suit étroitement les versions de Next.js, bien qu'il y ait généralement un décalage de 1-3 semaines après les versions majeures de Next.js avant qu'OpenNext ne suive.

Combien puis-je réellement économiser en quittant Vercel ?

Cela dépend beaucoup de vos modèles d'utilisation. Pour une équipe de 5 développeurs exécutant une application à trafic modéré, j'ai vu des équipes passer de 600-800 $/mois sur Vercel Pro à 30-80 $/mois sur AWS/SST ou moins de 20 $/mois sur un VPS. Les économies sont réelles mais aussi la charge de maintenance supplémentaire.

Puis-je utiliser ISR (Incremental Static Regeneration) sans Vercel ?

Absolument. Sur AWS/SST, ISR utilise DynamoDB pour le cache de tags et SQS pour revalidation asynchrone — c'est complètement fonctionnel, y compris la revalidation à la demande via revalidateTag() et revalidatePath(). Sur un VPS, ISR fonctionne avec le cache du système de fichiers, ce qui est bien pour les déploiements à serveur unique.

Qu'en est-il des déploiements d'aperçu de Vercel ? Puis-je répliquer ceux-ci ?

Vous pouvez obtenir 80 % de l'expérience. SST supporte les déploiements basés sur stages, donc chaque PR peut obtenir sa propre pile. Coolify et des outils similaires offrent des déploiements d'aperçu pour les configurations basées sur Docker. Ce que vous ne pourrez pas facilement répliquer, c'est le système de commentaires visuels de Vercel et l'intégration GitHub serrée pour l'état du déploiement. La plupart des équipes trouvent le compromis acceptable.

Dois-je utiliser OpenNext avec Cloudflare ou AWS pour un site CMS headless ?

Pour les sites CMS headless riches en contenu (Sanity, Contentful, Storyblok), Cloudflare Workers est un excellent choix. Ces sites ont tendance à être lourds en ISR avec une logique côté serveur relativement légère — parfait pour le modèle de tarification de Cloudflare. Je n'irais à AWS que si vous avez besoin de fonctionnalités que Cloudflare ne supporte pas encore ou si vous êtes déjà profondément dans l'écosystème AWS.

L'auto-hébergement de Next.js est-il plus difficile que l'auto-hébergement d'Astro ou Remix ?

Honnêtement ? Oui. Next.js a la sortie de build la plus complexe de tous les frameworks en raison de fonctionnalités comme ISR, middleware, optimisation d'image et prerendering partiel. Astro et Remix ont des histoires de déploiement beaucoup plus simples. Si vous commencez un nouveau projet et que l'auto-hébergement est une priorité, envisagez Astro — c'est dramatiquement plus simple à héberger. Mais si vous êtes déjà sur Next.js, OpenNext rend la migration pratique.

Que se passe-t-il si OpenNext cesse d'être maintenu ?

OpenNext est soutenu par SST et dispose d'une communauté active avec des sponsors majeurs. Cela dit, c'est une préoccupation légitime pour toute dépendance open source. La mitigation est que l'approche Docker/standalone (next start) fonctionne sans OpenNext — vous perdez simplement certaines des fonctionnalités les plus avancées comme la revalidation de tags ISR et le middleware edge. C'est une dégradation élégante, pas une falaise.