Comment déployer une application Django en production ?

Question

Accepted Answer

Déployer Django en production implique de l'exécuter derrière un serveur **WSGI/ASGI** approprié et un **serveur web**, de servir les fichiers statiques correctement, de sécuriser les paramètres et de gérer la base de données — très différent du serveur de développement intégré (qui n'est **pas** pour la production).

## La pile de production

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

Le serveur de développement est inadapté à la production. La pile standard : un **serveur d'application** (Gunicorn/uWSGI pour WSGI, Uvicorn pour ASGI/async) exécute Django avec plusieurs workers, derrière un **serveur web** (nginx) qui gère les connexions entrantes, TLS et les fichiers statiques.

## Paramètres de production (critique pour la sécurité)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Fichiers statiques

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Base de données et migrations

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Une liste de contrôle de déploiement typique

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Approches de déploiement modernes

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Pourquoi c'est important

Déployer Django en production correctement est une connaissance essentielle pour faire passer les applications du développement à l'utilisation réelle, et cela implique des considérations importantes qui diffèrent fondamentalement du développement local — faire erreur entraîne des vulnérabilités de sécurité, de mauvaises performances ou des applications cassées.

Comprendre la **pile de production** est fondamental : le serveur de développement intégré (`runserver`) n'est explicitement pas destiné à la production (il est monothread, non sécurisé et ne peut pas gérer la charge), vous devez donc exécuter Django derrière un **serveur d'application** approprié (Gunicorn/uWSGI pour WSGI ou Uvicorn pour ASGI/async) avec plusieurs workers, fronté par un **serveur web** (nginx) gérant les connexions, TLS et la distribution des fichiers statiques.

Plusieurs aspects sont critiques pour la sécurité et la correction : les **paramètres de production** (en particulier `DEBUG=False`, qui est obligatoire car `DEBUG=True` divulgue les tracebacks sensibles et la configuration aux attaquants, plus `ALLOWED_HOSTS`, une `SECRET_KEY` secrète provenant de l'environnement et l'application de HTTPS), la **gestion des fichiers statiques** (exécuter `collectstatic` et servir les fichiers via nginx/CDN/WhiteNoise, car Django ne les sert pas lui-même en production — un échec de déploiement courant) et la **gestion de la base de données** (une vraie base de données comme PostgreSQL, appliquer les migrations, sauvegardes).

Connaître la liste de contrôle de déploiement, les approches modernes (Docker/conteneurs, plates-formes gérées, stockage cloud pour les médias, workers Celery comme services séparés, mise à l'échelle horizontale avec une application sans état) et les préoccupations opérationnelles (journalisation, surveillance avec Sentry, vérifications de santé, gestion des processus) est ce qui distingue un déploiement en production fonctionnel d'un déploiement fragile ou non sécurisé.

Parce que chaque application Django réelle doit finalement être déployée, et parce que les erreurs de déploiement (laisser `DEBUG=True`, mal gérer les fichiers statiques, exposer des secrets, utiliser le serveur de développement) causent de vrais problèmes de sécurité et de fiabilité, comprendre comment déployer Django correctement — la pile, les paramètres critiques pour la sécurité, la gestion des fichiers statiques/média et les pratiques de déploiement modernes — est une connaissance importante et à fort enjeu qui reflète la capacité à livrer des applications prêtes pour la production, un sujet fréquemment pertinent et professionnellement essentiel pour tout développeur Django responsable de systèmes en direct.