Déployer une application Next.js en Suisse

D’abord, choisir lequel des deux Next.js vous avez

Next.js fait deux choses très différentes sous le même nom, et l’essentiel des difficultés de déploiement vient de ne pas avoir tranché.

La règle est simple : si votre site n’a pas besoin d’un serveur, ne lui en donnez pas. Un site statique n’a rien à redémarrer, rien à superviser, rien à mettre à jour en urgence, et il se met en cache. Le site que vous lisez est compilé de cette façon.

Le mode statique

Une ligne dans la configuration, et la compilation écrit un dossier out/ au lieu de préparer un serveur.

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  images: {
    // Sans serveur, pas d'optimiseur d'images : préparez vos
    // fichiers en WebP en amont.
    unoptimized: true,
  },
};

export default nextConfig;

Le mode serveur, déployé et chronométré

Pour une application qui a besoin de rendre des pages à la demande, le mode standalone demande à Next de produire un serveur autonome : il n’embarque que les dépendances réellement utilisées, ce qui donne une image bien plus légère qu’un node_modules complet.

// next.config.mjs
const nextConfig = { output: "standalone" };
export default nextConfig;

// package.json
{
  "engines": { "node": "22" },
  "scripts": {
    "build": "next build",
    "start": "node .next/standalone/server.js"
  }
}

La déclaration engines n’est pas facultative : sans elle, les constructeurs choisissent une version de Node par défaut, et elle est souvent trop ancienne. C’est la première cause d’échec que nous voyons.

Nous avons déployé exactement ce projet sur notre production, avec une page volontairement dynamique pour vérifier qu’un serveur tourne réellement derrière.

║ setup      │ nodejs_22, npm-9_x ║
║ install    │ npm i              ║
║ build      │ npm run build      ║
║ start      │ npm run start      ║

   Creating an optimized production build ...

Route (app)                                 Size  First Load JS
┌ ƒ /                                      124 B         102 kB
└ ○ /_not-found                            994 B         103 kB
+ First Load JS shared by all             102 kB

ƒ  (Dynamic)  server-rendered on demand
○  (Static)   prerendered as static content

✓ build en 107.4s
✓ en ligne : https://demo-next-suisse.swigs.cloud

Cent treize secondes entre l’envoi et la mise en ligne, dont cent sept de compilation. Le ƒ devant la route racine confirme qu’elle est rendue à la demande — c’est bien un serveur, pas un fichier.

La preuve que c’est du serveur

Une affirmation vérifiable vaut mieux qu’un symbole dans un tableau. La page affiche l’heure à laquelle elle a été rendue ; deux requêtes successives donnent deux heures différentes.

2026-09-02T10:28:07.391Z
2026-09-02T10:28:07.475Z

Quatre-vingt-quatre millisecondes d’écart entre deux rendus : la page est fabriquée à chaque requête. Un fichier statique aurait renvoyé deux fois la même heure.

Les variables d’environnement, là où ça se casse

C’est le piège le plus fréquent, et il est propre à Next.js. Deux catégories de variables coexistent, et elles n’ont pas le même cycle de vie.

• NEXT_PUBLIC_* est compilée dans le code du navigateur. Sa valeur est figée au moment du build, et elle est publique. La changer après coup n’a aucun effet : il faut recompiler.
• Toute autre variable est lue à l’exécution, côté serveur, et reste privée. C’est là que vont les clés d’API.

La conséquence pratique : une clé secrète nommée par erreur NEXT_PUBLIC_API_KEY se retrouve en clair dans un fichier JavaScript servi à tout le monde. Ce n’est pas une fuite subtile, c’est une clé publiée.

grep -rn "NEXT_PUBLIC_.*\(KEY\|SECRET\|TOKEN\|PASSWORD\)" .

Ce qu’il faut retenir

Tranchez d’abord entre statique et serveur — c’est la seule décision structurante. Déclarez votre version de Node, sans quoi le constructeur en choisira une trop ancienne. Vérifiez vos variables NEXT_PUBLIC_ avant de compiler. Le reste tient en une ligne de configuration et deux minutes d’attente.