Déployer un SaaS Next.js 14 sur Vercel : le guide pas à pas
Passer d'un projet Next.js local à un SaaS réellement en production demande plus qu'un next build. Il faut une structure App Router propre, des variables d'environnement correctement séparées, une base de données accessible depuis le build, une facturation branchée et une surveillance minimale. Voici la marche à suivre, telle qu'elle est appliquée sur les templates NeuraAPI.
L'essentiel
- App Router + composants serveur par défaut, client uniquement quand nécessaire.
- Le build Vercel doit pouvoir joindre la base : Prisma generate puis db push.
- Aucun secret dans le code : tout passe par les variables d'environnement Vercel.
- Webhooks Stripe idempotents, sinon les doublons vous coûteront cher.
1. Structurer le projet App Router
Sous src/app/, chaque dossier est une route. Gardez les pages marketing en rendu statique (export const dynamic = 'force-static') : elles sont vos pages d'entrée SEO et doivent se charger instantanément. Réservez le rendu dynamique aux tableaux de bord authentifiés.
Les routes d'API vivent sous src/app/api/ et tournent sur Node.js : vous y avez accès à Prisma, au crypto Node et aux SDK complets. Le middleware, lui, tourne sur l'Edge : pas de Prisma, pas de Buffer, uniquement la Web Crypto API.
2. Variables d'environnement
Déclarez-les dans le dashboard Vercel, jamais dans le dépôt. Seules celles préfixées par NEXT_PUBLIC_ sont exposées au navigateur — tout le reste (clés Stripe, clés providers IA, secret de session, URL Postgres) doit rester côté serveur.
# Public (navigateur) NEXT_PUBLIC_APP_URL=https://votre-domaine.vercel.app # Serveur uniquement DATABASE_URL=postgres://...?connection_limit=5 STRIPE_SECRET_KEY=... STRIPE_WEBHOOK_SECRET=... SESSION_SECRET=...
3. Base de données et build
Un piège classique : la commande de build enchaîne prisma generate, prisma db push puis next build. Si la base n'est pas joignable au moment du build, tout échoue. Sur Vercel la base de production est disponible, donc cela fonctionne ; en local il faut un Postgres actif ou un DATABASE_URL distant.
Ajoutez connection_limit=5 à votre URL Postgres : les fonctions serverless multiplient les connexions et un pool trop large épuise la base.
4. Paiements Stripe sans doublons
Le webhook Stripe peut être rejoué. Stockez chaque event.id reçu dans une table dédiée avec un upsert : si l'identifiant existe déjà, on ignore l'événement. C'est la seule façon fiable d'éviter de livrer deux fois une commande ou de créditer deux fois un compte.
5. Checklist avant mise en ligne
SEO technique
sitemap.ts et robots.ts présents, metadataBase défini dans le layout racine, canonical sur chaque page.
Sécurité
Rate limiting sur les routes publiques, validation Origin/Referer sur les requêtes mutantes, sessions signées HMAC.
Résilience
Toutes les requêtes base passent par un wrapper qui renvoie une valeur de repli au lieu de faire tomber la page.
Observabilité
Une route /api/health et une page de statut publique pour détecter les incidents avant vos clients.
Gagner les trois premières semaines
Tout ce qui précède est déjà câblé dans les templates NeuraAPI : App Router Next.js 14, Prisma, Stripe, authentification, APIs IA multi-providers, dix langues et déploiement Vercel en une commande. Vous partez d'une base testée en production plutôt que d'un dossier vide.
Lancez votre SaaS sans repartir de zéro
Templates Next.js 14 prêts pour la production, APIs IA incluses, déploiement Vercel immédiat.