Comment déployer une application Next.js en production en 5 étapes

Étape 1 : Configurer le build pour la production

La première chose à faire est de séparer proprement vos variables d'environnement. Créez un fichier .env.production distinct de votre .env.local. Les variables préfixées par NEXT_PUBLIC_ sont exposées côté client : ne mettez jamais de clé API secrète dedans. Les variables serveur (base de données, tokens API) doivent rester uniquement dans l'environnement du serveur.

Dans votre next.config.ts, activez le mode output: 'standalone'. Ce mode produit un dossier autonome qui contient tout le nécessaire pour démarrer le serveur sans node_modules, ce qui réduit l'image Docker de 1,2 Go à environ 100 Mo. C'est un gain considérable en temps de déploiement et en espace disque.

Vérifiez que votre build passe sans warning critique :npm run buildCorrigez les erreurs de type, les imports inutilisés et les pages qui génèrent des hydration mismatches. Un développeur à Bordeaux nous a raconté avoir perdu 3 jours en production à cause d'un useEffect qui ne se déclenchait pas côté serveur. Testez avec next build && next start en local avant de déployer.

Étape 2 : Choisir et configurer votre hébergement

Vercel est le chemin de moindre résistance : push sur GitHub, déploiement automatique, preview pour chaque PR, CDN mondial. Pour un projet perso ou une startup, c'est imbattable. Mais pour les projets qui nécessitent un contrôle total, des données en Europe ou un budget maîtrisé, d'autres options s'imposent.

La solution Docker sur VPS est la plus flexible. Utilisez le Dockerfile officiel Next.js avec un build multi-stage. Un VPS chez Hetzner à 5 euros par mois supporte aisément un site Next.js avec 50 000 visites mensuelles. À Paris, une agence digitale héberge 12 sites Next.js sur un seul serveur Hetzner à 20 euros par mois avec Docker Compose et Traefik en reverse proxy. L'astuce : Traefik gère automatiquement les certificats SSL via Let's Encrypt.

Pour les projets à fort trafic, AWS avec ECS/Fargate ou Google Cloud Run offrent du scaling automatique. Cloud Run est particulièrement adapté à Next.js car il scale à zéro (pas de coût quand il n'y a pas de trafic) et démarre en moins de 2 secondes grâce au cold start optimisé. Consultez la documentation officielle Next.js sur le déploiement pour les configurations spécifiques à chaque plateforme.

Étape 3 : Mettre en place le CI/CD

Un pipeline CI/CD automatisé élimine les erreurs humaines et accélère les déploiements. GitHub Actions est le choix le plus courant pour les projets Next.js. Créez un fichier.github/workflows/deploy.ymlqui se déclenche sur chaque push vers la branche main.

Votre pipeline devrait inclure au minimum : lint (ESLint), tests (Jest ou Vitest), build, et déploiement. Ajoutez un job de preview pour les pull requests : chaque PR génère une URL de prévisualisation que vos collègues ou clients peuvent tester avant le merge. À Nantes, une équipe de développeurs a réduit son temps de déploiement de 45 minutes (processus manuel) à 3 minutes (pipeline automatisé) en configurant GitHub Actions avec un workflow de build et push Docker vers leur registry.

Pour les déploiements Docker, utilisez GitHub Container Registry (ghcr.io) ou Docker Hub. Le workflow build l'image, la pousse vers le registry, puis déclenche un redéploiement sur le serveur via SSH ou un webhook Watchtower. N'oubliez pas les rollbacks : gardez les 3 dernières images Docker tagées pour pouvoir revenir en arrière en moins de 30 secondes si un déploiement pose problème. Consultez notre guide du cahier des charges pour structurer vos projets en amont.

Étape 4 : Configurer le monitoring et les alertes

Un site en production sans monitoring, c'est comme conduire de nuit sans phares. Vous avez besoin de trois niveaux de surveillance : la disponibilité (le site est-il accessible ?), les performances (les pages se chargent-elles en moins de 2 secondes ?) et les erreurs (des crashs côté serveur ou client ?).

Pour la disponibilité, un service comme UptimeRobot (gratuit jusqu'à 50 monitors) ou Better Uptime envoie un ping toutes les 5 minutes et vous alerte par e-mail, SMS ou Slack en cas de panne. Pour les erreurs, Sentry est le standard : son SDK Next.js s'intègre en 5 minutes et capture les exceptions côté serveur et client avec le contexte complet (stack trace, requête, utilisateur). À Toulouse, un SaaS B2B a détecté un memory leak en production grâce à Sentry qui remontait des crashs toutes les 6 heures.

Pour les performances, Next.js intègre un reporting Web Vitals. Envoyez ces métriques vers Vercel Analytics (si vous êtes chez Vercel) ou vers un dashboard custom avec Grafana + Prometheus. Surveillez en particulier le LCP (Largest Contentful Paint), le FID (First Input Delay) et le CLS (Cumulative Layout Shift). Google utilise ces métriques pour le classement SEO. Un LCP supérieur à 2,5 secondes sur mobile est un signal d'alerte qui nécessite une optimisation immédiate. Voir notre article sur les techniques SEO pour approfondir.

Étape 5 : Optimiser les performances pour la production

La compression est votre premier levier. Activez Brotli (ou gzip en fallback) au niveau de votre reverse proxy ou CDN. Brotli réduit la taille des assets JavaScript et CSS de 15 à 25% par rapport à gzip. Si vous utilisez Traefik ou Nginx (en tant que proxy, pas serveur web), la configuration tient en 3 lignes.

Utilisez systématiquement le composant Image de Next.js au lieu de balises img classiques. Il gère automatiquement le lazy loading, le responsive sizing et la conversion en WebP/AVIF. Pour les pages à contenu semi-statique, configurez l'ISR (Incremental Static Regeneration) avec un revalidate de 60 à 3600 secondes selon la fraîcheur requise. Un site e-commerce marseillais a réduit son TTFB de 800ms à 50ms en passant ses pages catégorie en ISR avec un revalidate de 300 secondes.

Enfin, placez un CDN devant votre application. Cloudflare (gratuit) ou AWS CloudFront cachent vos assets statiques au plus près des utilisateurs. Configurez les headersCache-Control de façon granulaire : max-age=31536000 pour les assets hashés (ils changent de nom à chaque build),s-maxage=60, stale-while-revalidate=600 pour les pages HTML. Ces headers font la différence entre un site qui rame et un site qui vole.

Questions fréquentes