---
title: "Optimisation du déploiement d’un projet Next.js avec Docker passant de 4 Go à 200 Mo"
slug: "optimisation-du-deploiement-dun-projet-next-js-avec-docker-passant-de-4-go-a-200-mo"
language: "fr"
canonical_url: "https://tekru.ca/fr/blog/optimisation-du-deploiement-dun-projet-next-js-avec-docker-passant-de-4-go-a-200-mo"
markdown_url: "https://tekru.ca/fr/blog/optimisation-du-deploiement-dun-projet-next-js-avec-docker-passant-de-4-go-a-200-mo/post.md"
published_at: "2025-03-17T03:51:14"
updated_at: "2026-10-08T12:46:20"
author: "Tekru Technologies"
tags: ["Exiry","Next.js","Node.js"]
---

# Optimisation du déploiement d’un projet Next.js avec Docker passant de 4 Go à 200 Mo

## Introduction

Dans cet article, nous partageons notre approche pour déployer un projet **Next.js** avec **Docker**, en mettant l’accent sur l’optimisation des performances, la sécurité et la gestion efficace des variables d’environnement.

Nous utilisons une architecture multi-stage pour distinguer l’image de build et l’image de production, ce qui réduit la taille de l’image finale et améliore la sécurité en évitant d’exposer des fichiers inutiles en production.

Cette approche nous a permis de gagner plusieurs gigaoctets de stockage, l’image déployée passant de 3-4 Go à moins de 200 Mo.

## Pourquoi utiliser un Dockerfile optimisé ?

- **Performance** : Une image plus légère charge plus rapidement et optimise l’exécution.
- **Sécurité** : En évitant d’inclure des dépendances inutiles en production, on réduit la surface d’attaque.
- **Gestion des variables d’environnement** : Une meilleure séparation entre les variables utilisées pour le build et celles utilisées au runtime.

## Analyse du Dockerfile

Nous allons utiliser deux étapes pour construire notre image Docker :

**Important** : Il faut configurer `next.config.mjs` en mode [standalone](https://nextjs.org/docs/pages/api-reference/config/next-config-js/output).

```javascript
module.exports = {
  output: "standalone",
};
```

### 1. Image de Build

Nous utilisons **Node.js 20** (toujours la version LTS) comme base pour le build :

```dockerfile
FROM node:20 AS build
```

Cette image comprend toutes les dépendances nécessaires pour compiler l’application.

#### Variables d’environnement en build-time

Nous définissons des variables d’environnement qui seront utilisées uniquement durant la compilation de l’application.

```dockerfile
ARG NEXT_PUBLIC_PUBLIC_URL
ARG WORDPRESS_API_URL
ARG EXIRY_GA_TRACKING_ID
```

Ces variables sont utilisées par **Next.js** pour générer le build statique et configurer certaines intégrations (CMS, analytics, etc.).

Après l’installation des dépendances et la copie du code, nous **construisons** l’application Next.js :

```dockerfile
RUN yarn build
```

### 2. Image de Production

Nous utilisons une image **allégée** de Node.js pour exécuter l’application en production :

```dockerfile
FROM node:20-alpine AS production
```

Pourquoi ?

- **Alpine** est une version minimaliste de Linux, réduisant la taille de l’image finale.
- Moins de packages = moins de vulnérabilités potentielles.

Nous copions uniquement les fichiers essentiels au fonctionnement de l’application en production :

```dockerfile
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/public ./public
COPY --from=build /app/.next/static ./.next/static
```

Pourquoi ?

- **Next.js standalone** permet d’exécuter l’application sans avoir besoin de toutes les dépendances de développement.
- **Seuls les fichiers nécessaires** sont inclus, réduisant ainsi la taille de l’image et améliorant la sécurité.

#### Variables d’environnement en runtime

```dockerfile
ENV NODE_ENV=production

ENV NEXT_PUBLIC_PUBLIC_URL=
ENV CSRF_SECRET=
ENV WP_API_TOKEN=
ENV WORDPRESS_API_URL=
ENV WEBHOOK_SECRET=
ENV EXIRY_GA_TRACKING_ID=
```

Pourquoi cette distinction ?

- Les variables d’environnement en **build-time** (stade 1) sont utilisées **pour compiler** l’application.
- Les variables d’environnement en **runtime** (stade 2) sont celles qui seront **utilisées par l’application en exécution**.
- Certaines variables, comme `NEXT_PUBLIC_PUBLIC_URL`, peuvent apparaître dans les deux images car elles sont requises à la fois pour le build et pour l’exécution.

En production, **aucune information sensible** ne doit figurer dans l’image elle-même. Les variables runtime sont injectées au moment de l’exécution via **un fichier .env ou un orchestrateur (Docker Compose, Kubernetes, etc.)**.

#### Exposition du port et lancement de l’application

```dockerfile
EXPOSE 3000
CMD ["node", "server.js"]
```

- **EXPOSE 3000** : Déclare le port sur lequel Next.js écoute. Si vous utilisez un autre port, assurez-vous de l’exposer ici.
- **CMD [« node », « server.js »]** : Démarre l’application Next.js.

## Conclusion

Ce Dockerfile optimisé pour Next.js permet :

- Une **meilleure gestion des variables d’environnement**, en évitant d’exposer des secrets dans l’image de build.
- Une **réduction de la taille de l’image** en excluant les dépendances inutiles.
- Une **meilleure sécurité** en limitant la surface d’attaque et en utilisant une image **Alpine**.

En suivant cette approche, nous assurons un déploiement **performant, sécurisé et maintenable** pour nos projets Next.js chez Tekru.

Voici une version complète du Dockerfile :

```dockerfile
# Stage 1: Build image
FROM node:20 AS build

# Set build-time environment variables
ARG NEXT_PUBLIC_PUBLIC_URL
ARG WORDPRESS_API_URL
ARG EXIRY_GA_TRACKING_ID

# Set the working directory inside the container
WORKDIR /app

# Install dependencies using Yarn (including dev dependencies)
COPY package.json yarn.lock ./
COPY next.config.ts ./
RUN yarn install --frozen-lockfile

# Copy the rest of the application code
COPY . .

# Set these arguments as environment variables
ENV NEXT_PUBLIC_PUBLIC_URL=$NEXT_PUBLIC_PUBLIC_URL
ENV WORDPRESS_API_URL=$WORDPRESS_API_URL
ENV EXIRY_GA_TRACKING_ID=$EXIRY_GA_TRACKING_ID

# Build the Next.js app
RUN yarn build

# Stage 2: Production image
FROM node:20-alpine AS production

# Set the working directory inside the container
WORKDIR /app

# Copy standalone output from builder stage
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/public ./public
COPY --from=build /app/.next/static ./.next/static

# Copy the next.config.ts
COPY next.config.ts .

ENV NODE_ENV=production

# Set environment variables for runtime
ENV NEXT_PUBLIC_PUBLIC_URL=
ENV CSRF_SECRET=
ENV WP_API_TOKEN=
ENV WORDPRESS_API_URL=
ENV WEBHOOK_SECRET=
ENV EXIRY_GA_TRACKING_ID=

# Expose the necessary port
EXPOSE 3000

# Start the Next.js app in production mode
CMD ["node", "server.js"]
```

### Besoin d’optimiser vos déploiements Next.js ?

Chez **Tekru**, nous accompagnons les entreprises dans l’optimisation de leurs infrastructures web. [Contactez-nous pour en savoir plus !](https://tekru.net/fr/contactez-un-expert/)