Déployer React en 2026 : compilations immuables, Traefik et mises en production sans interruption

Un article de suivi actuel et orienté production, qui traduit la documentation des éditeurs en contrôles opérationnels, décisions de migration et critères de mise en service vérifiables.

Ce qui a changé en 2026

Nous revenons sur ce sujet parce que les limites opérationnelles ont évolué. Les principes durables restent pertinents, mais les versions actuelles rendent certains anciens raccourcis incomplets ou risqués. Ce suivi part de la documentation des éditeurs disponible au 14 juillet 2026, distingue les faits des choix locaux et traite chaque modification de configuration comme une intervention contrôlée en production.

Sources primaires actuelles

Comment exploiter cette mise à jour

Lisez d’abord les sources, consignez les versions réellement déployées et définissez le résultat observable avant de modifier un paramètre. Testez la plus petite intervention réversible dans un environnement représentatif. Une commande réussie ne constitue pas un critère de validation : l’état du service, l’intégrité des données, la latence, les limites de sécurité et le délai de retour à la version précédente le sont. Lorsque l’ancien guide propose une séquence de diagnostic utile, nous la conservons ci-dessous comme socle opérationnel ; les exemples propres à une version doivent toujours être vérifiés dans la documentation actuelle. Les fichiers de configuration et les commandes mentionnés ci-dessous se trouvent dans le guide d’origine.

Socle opérationnel

Compiler une application React en local est simple. La déployer correctement sur des serveurs de production ? C’est là que la plupart des développeurs se heurtent à des obstacles inattendus. Ce guide documente une véritable session de débogage de déploiement où tout semblait correctement configuré — conteneur en fonctionnement, labels Traefik définis, DNS résolu — et pourtant l’application renvoyait des erreurs 404 persistantes.

Aujourd’hui, nous allons parcourir le processus complet de compilation d’applications React en local et de leur déploiement sur des serveurs Docker de production avec une configuration appropriée du proxy inverse, une gestion automatique de SSL et un routage des domaines adapté à un usage professionnel. Cette approche s’appuie sur notre philosophie de solutions auto-hébergées — comme nous l’avons montré pour l’auto-hébergement de n8n pour l’automatisation des flux de travail et la création de piles de développement multi-locataires pour un contrôle opérationnel complet.

Le problème des déploiements React traditionnels

La plupart des tutoriels de déploiement React passent sous silence les détails critiques de production. Vous trouverez des guides montrant npm run build et la copie des fichiers vers nginx, mais ils couvrent rarement :

Conflits de configuration :

Des routeurs HTTP personnalisés qui remplacent les redirections globales

Des erreurs de syntaxe dans les labels Traefik qui causent des échecs silencieux

Des problèmes de liaison IPv6 et IPv4 dans les contrôles de disponibilité

Des mappages de ports de service manquants qui produisent des erreurs 404

Gestion des ressources :

Des erreurs de disque plein empêchant l’enregistrement des conteneurs

Le gonflement des images Docker à cause d’artefacts de compilation inutiles

Des stratégies de mise en cache inefficaces qui ralentissent les déploiements

Des contraintes de mémoire affectant les performances de compilation

Préparation à la production :

Automatisation correcte des certificats SSL

Stratégies de déploiement sans interruption

Configurations des contrôles de disponibilité

Intégration de la journalisation et de la surveillance

Le résultat ? Des heures perdues à déboguer pourquoi une application fonctionnant parfaitement en local renvoie de mystérieuses erreurs 404 en production, alors que « tout semble correct ».

Les outils que nous utilisons

Comprenons le rôle de chaque composant dans notre architecture de déploiement React rationalisée :

Vite : outil de compilation moderne

Vite offre un développement ultra-rapide et des compilations de production optimisées. Contrairement à Create React App, Vite exploite les modules ES natifs pendant le développement et produit des bundles hautement optimisés pour la production. Votre application React se compile en quelques secondes au lieu de minutes.

L’avantage principal ? Vite gère automatiquement le découpage du code, le tree shaking et l’optimisation des ressources. Vous obtenez des compilations prêtes pour la production sans configurations webpack complexes.

Docker : la conteneurisation pour la cohérence

Docker garantit que votre application React fonctionne de manière identique en développement et en production. Le même conteneur nginx servant votre application localement se comportera exactement de la même façon sur votre serveur de production — éliminant le classique problème « ça marche sur ma machine ».

Docker regroupe l’ensemble de votre environnement applicatif (fichiers issus de la compilation React, configuration nginx et environnement d’exécution) dans un conteneur portable qui fonctionne partout.

Traefik : proxy inverse intelligent

Traefik agit comme un aiguilleur de trafic intelligent, routant automatiquement les requêtes vers les applications conteneurisées appropriées en fonction des noms de domaine. Au lieu de configurer manuellement des règles nginx ou Apache complexes pour chaque nouvelle application, Traefik lit les labels de vos conteneurs Docker et configure le routage automatiquement.

Dans notre configuration Docker multi-locataire, nous avons démontré la puissance de Traefik pour gérer plusieurs environnements clients. Les mêmes principes s’appliquent ici pour gérer plusieurs applications React sur un seul serveur.

L’avantage est que Traefik gère la terminaison SSL via Let's Encrypt automatiquement, offre la découverte automatique des services et propose une supervision détaillée — le tout avec une configuration minimale.

nginx : serveur web de production

nginx sert vos fichiers statiques React avec des performances exceptionnelles. C’est le standard de facto pour servir du contenu statique en production, gérant des milliers de connexions simultanées efficacement tout en utilisant des ressources minimales.

Comprendre le flux de déploiement

Voici le parcours complet du développement local à la production :

Développement local : construisez et testez votre application React avec npm run dev

Compilation de production : créez les fichiers statiques optimisés avec npm run build

Conteneurisation : empaquetez les fichiers compilés dans un conteneur Docker nginx

Déploiement serveur : transférez et démarrez le conteneur sur le serveur de production

Enregistrement Traefik : routage automatique et provisionnement du certificat SSL

Supervision de la disponibilité : des vérifications continues garantissent la disponibilité

Ce qui rend cette approche puissante, c’est l’automatisation. Une fois la configuration correcte, vous pouvez déployer des mises à jour en moins de 60 secondes avec une seule commande.

Configurer votre application React

Structure du projet pour la production

Organisez votre projet React en pensant au déploiement :

my-react-app/
├── src/                    # React source code
├── public/                 # Static assets
├── dist/                   # Build output (auto-generated)
├── package.json            # Dependencies
├── package-lock.json       # Locked dependency versions (npm ci)
├── vite.config.ts          # Vite configuration
├── Dockerfile              # Container definition
├── nginx.conf              # nginx configuration
└── docker-compose.yml      # Deployment definition

Optimiser votre configuration Vite

Créez vite.config.ts avec des paramètres optimisés pour la production :

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: 'dist',
    sourcemap: false, // Do not publish source maps in production
    // Minification is on by default (Oxc minifier in Vite 8)
    rolldownOptions: {
      output: {
        // Vite 8 (Rolldown): codeSplitting replaces the manualChunks object form
        codeSplitting: {
          groups: [
            { test: /node_modules[\\/](react|react-dom|scheduler)[\\/]/, name: 'vendor' },
          ],
        },
      },
    },
  },
  server: {
    port: 3000,
    host: true, // Enable network access
  },
})

Cette configuration :

Sépare les bibliothèques tierces pour une meilleure mise en cache

Minifie le code pour des fichiers plus petits

Désactive les cartes de correspondance du code source en production (empêche l’exposition du code)

Optimise le découpage des fragments de code pour des temps de chargement plus rapides

Compiler pour la production

Compilez votre bundle de production optimisé :

# Install the exact dependency versions from package-lock.json
npm ci
# Create production build
npm run build
# Verify build output
ls -lh dist/

Votre dossier dist/ devrait contenir :

index.html — Point d’entrée

assets/ — JS, CSS et images minifiés

Fichiers statiques depuis public/

Créer le conteneur de production

Configuration nginx pour React

Les applications React utilisent le routage côté client, nécessitant une configuration nginx spéciale. Créez nginx.conf :

server {
    listen 80;
    server_name _;

    root /usr/share/nginx/html;
    index index.html;
    # Gzip compression for better performance
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css text/xml text/javascript
               application/x-javascript application/xml+rss
               application/javascript application/json;
    # Security headers (a location with its own add_header drops these)
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    # SPA: Route all paths to index.html for client-side routing
    location / {
        try_files $uri $uri/ /index.html;
    }
    # Cache static assets aggressively
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    # Revalidate HTML on every request so new releases show up immediately
    location ~* \.html$ {
        expires -1;
    }
    # Health check endpoint for monitoring
    location /health {
        access_log off;
        default_type text/plain;
        return 200 "healthy\n";
    }
}

L’élément critique est try_files $uri $uri/ /index.html qui garantit le bon fonctionnement de React Router en production — toutes les routes sont servies par le fichier principal index.html.

Dockerfile pour la production

Créez un Dockerfile optimisé :

FROM nginx:alpine
# Copy custom nginx configuration
COPY nginx.conf /etc/nginx/conf.d/default.conf
# Copy production build files
COPY dist/ /usr/share/nginx/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Cela utilise nginx:alpine pour une image de production minimale (moins de 30 Mo après compression, en octobre 2026) qui contient tout le nécessaire pour servir votre application React.

Configuration Docker Compose

Créez docker-compose.yml pour un déploiement facile :

services:
  my-react-app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: my-react-app
    restart: unless-stopped
    networks:
      - proxy
    labels:
      # Enable Traefik
      - "traefik.enable=true"

      # Define routing rule
      - "traefik.http.routers.myapp.rule=Host(`app.yourdomain.com`)"
      - "traefik.http.routers.myapp.entrypoints=https"
      - "traefik.http.routers.myapp.tls=true"
      - "traefik.http.routers.myapp.tls.certresolver=letsencrypt"

      # Define service port
      - "traefik.http.services.myapp.loadbalancer.server.port=80"

    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://127.0.0.1:80/health"]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 5s
networks:
  proxy:
    external: true

Notes de configuration critiques :

La section labels est l’endroit où de nombreux déploiements échouent. Notez ce que nous n’incluons PAS :

Pas de définition séparée de routeur HTTP

Pas de middleware de redirection personnalisé

Pas de configuration de point d’entrée HTTP

Pourquoi ? Parce que la configuration globale de Traefik gère déjà les redirections HTTP vers HTTPS. Dans notre configuration, l’ajout de routeurs HTTP personnalisés a perturbé ce comportement et provoqué des erreurs 404 — exactement le problème que nous avons résolu lors de notre session de débogage.

Déployer sur votre serveur de production

Prérequis sur votre serveur

Votre serveur de production a besoin de :

Environnement Docker :

# Verify Docker is installed
docker --version
docker compose version
# Verify Traefik is running
docker ps | grep traefik
# Verify proxy network exists
docker network ls | grep proxy

Si Traefik n’est pas configuré, consultez notre guide Docker multi-locataire qui couvre la configuration complète de Traefik.

Espace disque suffisant :

# Check available space
df -h /
# You need at least 2-5GB free for Docker operations

Configuration DNS :

Pointez app.yourdomain.com vers l’adresse IP de votre serveur

Attendez la propagation DNS (généralement 5 à 60 minutes)

Transférer votre application

Transférez votre application vers le serveur :

# From your local machine
scp -r my-react-app/ user@your-server:/opt/
# Or use rsync for efficient updates
rsync -avz --exclude 'node_modules' \
  my-react-app/ user@your-server:/opt/my-react-app/

Construire et démarrer le conteneur

Connectez-vous en SSH à votre serveur et déployez :

# Navigate to application directory
cd /opt/my-react-app
# Build the Docker image
docker compose build
# Start the container
docker compose up -d
# Verify it's running
docker compose ps

Vérifier le déploiement

Vérifiez que tout fonctionne :

# Test container health internally
docker compose exec my-react-app wget -q -O- http://127.0.0.1/health
# Check Traefik routing (wait 30 seconds for SSL)
curl -I https://app.yourdomain.com
# View container logs
docker compose logs -f

Vous devriez voir HTTP/2 200 à la commande curl, indiquant le succès.

Échecs de déploiement courants et solutions

Erreur 404 malgré une configuration correcte

Symptôme : Traefik renvoie HTTP/2 404 alors que le conteneur fonctionne en interne.

Cause profonde : Plusieurs définitions de routeurs pour le même service sans mappage correct du port de service, ou des routeurs HTTP personnalisés remplaçant les redirections globales de Traefik.

Solution :

# Remove these labels if present:
# - "traefik.http.middlewares.myapp-redirect.redirectscheme.scheme=https"
# - "traefik.http.routers.myapp-http.rule=Host(`app.yourdomain.com`)"
# - "traefik.http.routers.myapp-http.entrypoints=http"
# - "traefik.http.routers.myapp-http.middlewares=myapp-redirect"
# Keep only HTTPS router:
labels:
  - "traefik.enable=true"
  - "traefik.http.routers.myapp.rule=Host(`app.yourdomain.com`)"
  - "traefik.http.routers.myapp.entrypoints=https"
  - "traefik.http.routers.myapp.tls.certresolver=letsencrypt"
  - "traefik.http.services.myapp.loadbalancer.server.port=80"

La redirection globale HTTP vers HTTPS de Traefik (configurée dans traefik.yml) gère automatiquement le trafic HTTP. Les routeurs HTTP personnalisés par service peuvent entrer en conflit avec cette redirection.

Conteneur en statut « unhealthy »

Symptôme : docker compose ps affiche le conteneur comme « unhealthy »

Cause profonde : le contrôle de disponibilité utilise localhost qui résout vers IPv6 [::1], mais nginx n’écoute que sur IPv4.

Solution :

healthcheck:
  # Use explicit IPv4 address instead of localhost
  test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://127.0.0.1:80/health"]

La compilation Docker échoue avec « No Space Left »

Symptôme : la compilation échoue avec des erreurs d’espace disque

Solution :

# Check disk usage
df -h /
# Clean Docker system
docker system prune -a -f
# Remove unused images
docker image prune -a -f
# Remove unused volumes
docker volume prune -f

Si le disque est vraiment plein (> 95 %), vous devez libérer de l’espace ou étendre votre stockage. Les opérations Docker nécessitent un espace temporaire pour la mise en cache des couches et la compilation.

Le certificat SSL ne se génère pas

Symptôme : curl affiche un certificat auto-signé après plus de 10 minutes

Causes courantes :

DNS ne pointe pas correctement vers le serveur

Ports 80/443 non accessibles depuis Internet

Limites de débit Let's Encrypt atteintes (par exemple, 5 certificats par ensemble exact de noms d’hôte ou 50 par domaine enregistré tous les 7 jours)

Solution :

# Verify DNS resolution
dig app.yourdomain.com
# Test port accessibility
curl -I http://app.yourdomain.com
# Check Traefik logs for ACME errors
docker logs traefik 2>&1 | grep -i acme
# Restart Traefik if needed
docker restart traefik

Erreurs 404 React Router lors du rafraîchissement

Symptôme : l’application fonctionne au chargement initial mais affiche une 404 lors du rafraîchissement sur des routes comme /about

Cause profonde : directive try_files manquante dans la configuration nginx

Solution : assurez-vous que votre nginx.conf inclut :

location / {
    try_files $uri $uri/ /index.html;
}

Cela indique à nginx de servir index.html pour toutes les routes, laissant React Router gérer le routage côté client.

Le conteneur démarre mais Traefik ne peut pas l’atteindre

Symptôme : le conteneur fonctionne mais Traefik renvoie « Service Unavailable »

Solution :

# Verify container is on correct network
docker network inspect proxy
# Check if container is listed
docker inspect my-react-app | grep -A 20 Networks
# Ensure proxy network exists
docker network create proxy

Optimiser pour la production

Mettre en œuvre des déploiements sans interruption

Mettez à jour votre application avec une interruption minimale. La recréation d’un conteneur unique avec docker compose up interrompt toujours brièvement le trafic ; pour éviter toute interruption, une seconde instance en bon état de fonctionnement doit être disponible derrière Traefik avant l’arrêt de l’ancienne :

#!/bin/bash
# deploy-update.sh - rebuild and replace the container
# Recreating a single container briefly interrupts traffic (see above)
set -euo pipefail
cd /opt/my-react-app
# Pull latest code (from git or updated files)
git pull origin main
# Build new production assets from the lockfile
npm ci
npm run build
# Build the new image while the old container keeps serving
docker compose build my-react-app
# Replace the container: Compose stops the old one, then starts the new one,
# and --wait returns once the new container reports healthy
docker compose up -d --no-deps --wait my-react-app

Contrôles de disponibilité avancés

Mettez en place une supervision complète de la disponibilité :

healthcheck:
  test: |
    wget --no-verbose --tries=1 --spider http://127.0.0.1:80/health &&
    wget --no-verbose --tries=1 --spider http://127.0.0.1:80/
  interval: 30s
  timeout: 5s
  retries: 3
  start_period: 10s

Cela vérifie à la fois le point de terminaison de contrôle de disponibilité ET la route principale de l’application, garantissant que l’ensemble de l’application répond correctement.

Optimisation des performances

Ajustez la configuration de nginx pour de meilleures performances :

# Add to nginx.conf
server {
    # ... existing config ...

    # Increase buffer sizes for large headers
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    # Enable keep-alive connections
    keepalive_timeout 65;

    # Optimize file serving
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

Limites de ressources

Prévenez l’épuisement des ressources avec des limites de conteneur :

services:
  my-react-app:
    # ... existing config ...
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

nginx servant des fichiers React statiques nécessite des ressources minimales — 512 Mo de mémoire et un demi-cœur CPU constituent une limite initiale raisonnable ; effectuez des tests de charge pour confirmer le nombre de connexions simultanées nécessaire à votre trafic.

Pourquoi les déploiements Docker auto-hébergés comptent

L’auto-hébergement de vos applications React sur une infrastructure Docker vous donne un contrôle total sur votre pipeline de déploiement sans dépendance à un fournisseur. Vous pouvez déployer un nombre illimité d’applications sur votre propre infrastructure, personnaliser chaque aspect du processus de déploiement et intégrer facilement le déploiement à vos services auto-hébergés existants.

Cette approche fonctionne particulièrement bien combinée à notre architecture Docker multi-locataire, où vous pouvez héberger plusieurs applications clients sur la même infrastructure avec des conteneurs et des réseaux distincts pour chaque client.

Automatisation et intégration CI/CD

Déploiement avec GitHub Actions

Automatisez les déploiements à chaque push :

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Setup Node.js
        uses: actions/setup-node@v7
        with:
          node-version: '24'
          cache: 'npm'

      - name: Build React app
        run: |
          npm ci
          npm run build

      - name: Deploy to server
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: "dist/,Dockerfile,nginx.conf,docker-compose.yml"
          target: "/opt/my-react-app"

      - name: Restart container
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /opt/my-react-app
            docker compose up -d --build --wait

Pipeline CI/CD GitLab

Pour les utilisateurs de GitLab :

# .gitlab-ci.yml
stages:
  - build
  - deploy
build:
  stage: build
  image: node:24
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour
deploy:
  stage: deploy
  image: alpine:3.23
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    # Trust the server's host key (store `ssh-keyscan your-server` output in SSH_KNOWN_HOSTS)
    - mkdir -p ~/.ssh && echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
  script:
    - scp -r dist/ Dockerfile nginx.conf docker-compose.yml $SERVER_USER@$SERVER_HOST:/opt/my-react-app/
    - ssh $SERVER_USER@$SERVER_HOST "cd /opt/my-react-app && docker compose up -d --build --wait"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Surveiller votre déploiement en production

Stratégie de journalisation

Mettez en place une journalisation complète :

# Add to docker-compose.yml
services:
  my-react-app:
    # ... existing config ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Consultez les journaux efficacement :

# Real-time logs
docker compose logs -f my-react-app
# Last 100 lines
docker compose logs --tail=100 my-react-app
# Logs from specific time
docker compose logs --since=2h my-react-app
# Filter for errors only
docker compose logs my-react-app | grep -i error

Métriques et alertes

Surveillez la disponibilité des conteneurs :

#!/bin/bash
# health-check.sh - Regular health monitoring
CONTAINER="my-react-app"
WEBHOOK_URL="your-notification-webhook"
STATUS=$(docker inspect --format='{{.State.Health.Status}}' $CONTAINER)
if [ "$STATUS" != "healthy" ]; then
    curl -X POST $WEBHOOK_URL \
      -H 'Content-Type: application/json' \
      -d "{\"text\":\"⚠️ Container $CONTAINER is $STATUS\"}"
fi

Exécutez ce script via cron toutes les 5 minutes pour une surveillance de base.

Connecter React à l’infrastructure backend

Votre application React a probablement besoin de communiquer avec des services backend. Cela s’intègre naturellement à l’infrastructure auto-hébergée. Si vous exécutez n8n pour l’automatisation des flux de travail ou Windmill pour les flux de travail backend, configurez correctement le CORS et le routage API dans votre configuration nginx :

# Add to nginx.conf, above the server block: set Connection only for WebSocket upgrades
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# Inside the server block. Same-origin proxying: the browser makes no
# cross-origin request, so these API calls need no CORS headers
location /api {
    proxy_pass http://your-backend-service:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Cela fonctionne parfaitement lorsque tous les services font partie du même réseau Docker, comme démontré dans notre guide d’architecture multi-locataire.

Compilations propres à chaque environnement

Différents environnements nécessitent souvent des configurations différentes :

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig(({ mode }) => ({
  plugins: [react()],
  define: {
    'import.meta.env.VITE_API_URL': JSON.stringify(
      mode === 'production'
        ? 'https://api.yourdomain.com'
        : 'http://localhost:3000'
    ),
  },
  build: {
    outDir: 'dist',
    sourcemap: mode !== 'production',
  },
}))

Compilez pour différents environnements :

# Development build
npm run build -- --mode development
# Staging build
npm run build -- --mode staging
# Production build
npm run build -- --mode production

L’intérêt de comprendre cette configuration

Cette approche de déploiement est pertinente si vous :

Gérez plusieurs applications :

Déployez des applications React aux côtés de services backend sur la même infrastructure

Utilisez des processus de déploiement cohérents pour tous les projets

Intégrez vos applications à des outils auto-hébergés comme n8n et Windmill

Développez pour des clients :

Domaines personnalisés professionnels sécurisés par SSL

Contrôle total sur l’infrastructure et les déploiements

Aucune limitation de plateforme ni dépendance à un fournisseur

Apprenez à gérer l’infrastructure :

Comprenez les fondamentaux de la conteneurisation Docker

Maîtrisez la configuration du proxy inverse Traefik

Déboguez les problèmes de déploiement en production de manière systématique

La configuration documentée ici est basée sur une véritable session de débogage — les problèmes décrits se sont réellement produits et les solutions ont réellement fonctionné. Cela la rend plus précieuse que des tutoriels théoriques car vous voyez les vrais pièges et comment les éviter.

Combinée à notre architecture Docker multi-locataire, cette approche forme les bases d’un déploiement d’applications auto-hébergé, capable de monter en charge et entièrement sous votre contrôle.

Ressources associées

Pour plus de guides d’infrastructure auto-hébergée, consultez ces ressources :

Auto-héberger n8n pour l’automatisation des flux de travail — Automatisez les déploiements et les tâches d’infrastructure

Auto-héberger Windmill avec Docker — Plateforme alternative d’automatisation des flux de travail

Construire des piles Docker multi-locataires — Configuration complète de Traefik pour plusieurs applications

tva Duplicate Pro — Outils d’automatisation WordPress pour les flux de travail de contenu

Ces guides illustrent différents aspects de la construction d’une infrastructure auto-hébergée qui vous donne un contrôle total tout en maintenant des standards professionnels.

Obtenez un accompagnement professionnel

La mise en place de déploiements React de niveau production implique de nombreuses considérations d’infrastructure. Bien que nous ayons fourni une documentation complète, chaque projet a des exigences uniques, des contraintes d’infrastructure existantes et des besoins de performance spécifiques.

Si vous mettez en place une infrastructure de déploiement React pour un usage en production ou si vous avez besoin de personnalisation pour vos besoins spécifiques de livraison client, nous pouvons vous aider avec :

Des pipelines de déploiement personnalisés adaptés à votre flux de travail

L’intégration avec des systèmes CI/CD existants

L’optimisation des performances pour les applications à fort trafic

Des stratégies de déploiement multi-régions

La formation des équipes aux bonnes pratiques Docker et Traefik

La gestion et la surveillance continues de l’infrastructure

Contactez-nous via tva.sg/contact pour discuter de vos besoins de déploiement React et obtenir des conseils professionnels sur la mise en œuvre.

De la configuration à la décision opérationnelle

La question pratique n’est pas de savoir si une plateforme peut être configurée. Il s’agit de savoir si l’équipe peut expliquer qui en est responsable, détecter les dérives, rétablir le service sans improviser et démontrer que le changement a amélioré le résultat attendu. Nous associons donc chaque configuration à un responsable, une référence initiale, une procédure de retour à la version précédente et une période de vérification après intervention. Une correction ponctuelle devient ainsi une capacité opérationnelle durable. Le dossier de production doit préciser le motif du changement, les éléments examinés, le périmètre exact et la personne autorisée à l’arrêter ou à l’annuler. Après la mise en production, comparez les indicateurs convenus à la référence initiale et conservez le résultat dans le dossier du changement. Si l’amélioration attendue n’est pas constatée, le retour à la version précédente est une issue valable, plutôt qu’un échec. Cette discipline compte davantage que n’importe quelle valeur de configuration. Le même dossier donne au prochain responsable un point de départ fiable et fait de l’optimisation ultérieure une décision mesurée plutôt qu’une nouvelle série de suppositions.

Ce qui a changé en 2026

Sources primaires actuelles

Comment exploiter cette mise à jour

Socle opérationnel

Le problème des déploiements React traditionnels

Les outils que nous utilisons

Vite : outil de compilation moderne

Docker : la conteneurisation pour la cohérence

Traefik : proxy inverse intelligent

nginx : serveur web de production

Comprendre le flux de déploiement

Configurer votre application React

Structure du projet pour la production

Optimiser votre configuration Vite

Compiler pour la production

Créer le conteneur de production

Configuration nginx pour React

Dockerfile pour la production

Configuration Docker Compose

Déployer sur votre serveur de production

Prérequis sur votre serveur

Transférer votre application

Construire et démarrer le conteneur

Vérifier le déploiement

Échecs de déploiement courants et solutions

Erreur 404 malgré une configuration correcte

Conteneur en statut « unhealthy »

La compilation Docker échoue avec « No Space Left »

Le certificat SSL ne se génère pas

Erreurs 404 React Router lors du rafraîchissement

Le conteneur démarre mais Traefik ne peut pas l’atteindre

Optimiser pour la production

Mettre en œuvre des déploiements sans interruption

Contrôles de disponibilité avancés

Optimisation des performances

Limites de ressources

Pourquoi les déploiements Docker auto-hébergés comptent

Automatisation et intégration CI/CD

Déploiement avec GitHub Actions

Pipeline CI/CD GitLab

Surveiller votre déploiement en production

Stratégie de journalisation

Métriques et alertes

Connecter React à l’infrastructure backend

Compilations propres à chaque environnement

L’intérêt de comprendre cette configuration

Ressources associées

Obtenez un accompagnement professionnel

De la configuration à la décision opérationnelle

Analyses connexes

Pour aller plus loin