Comment gérez-vous les paramètres de configuration entre les environnements ?

Question

IT Interview Practice · Accepted Answer

La configuration Django réside dans `settings.py`, mais les applications réelles nécessitent **des paramètres différents par environnement** (développement, staging, production) et doivent garder **les secrets hors du code**. Gérer cela correctement est à la fois une nécessité opérationnelle et une exigence de sécurité.

## Le problème avec un seul settings.py

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

Coder en dur les valeurs mélange les environnements et — de façon critique — valide les secrets (SECRET_KEY, mots de passe de base de données, clés API) dans le contrôle de version, une faille de sécurité grave.

## Solution 1 : lire la configuration à partir de variables d'environnement

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

Lire la configuration (en particulier les secrets) à partir de **variables d'environnement** la garde hors du code — le même codebase s'exécute dans n'importe quel environnement avec des valeurs injectées différentes (l'approche twelve-factor).

## Solution 2 : diviser les fichiers de paramètres par environnement

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

Diviser les paramètres en un `base.py` partagé plus des fichiers par environnement (sélectionnés via `DJANGO_SETTINGS_MODULE`) sépare proprement la configuration spécifique à l'environnement tout en partageant les paramètres communs.

## Paramètres critiques de production

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

## Pourquoi c'est important

Gérer les paramètres entre environnements est à la fois une **nécessité opérationnelle** et une **pratique de sécurité critique** pour toute application Django réelle.

Les applications doivent se comporter différemment selon les environnements — le développement a besoin de `DEBUG=True` et de paramètres locaux pratiques, tandis que la production exige `DEBUG=False`, le durcissement de la sécurité, de véritables bases de données et des hosts appropriés — et un seul `settings.py` codé en dur ne peut pas servir tous ces cas.

Plis important encore, c'est une **préoccupation majeure de sécurité** : coder en dur les secrets (la SECRET_KEY, les mots de passe de base de données, les clés API) les valide dans le contrôle de version, l'une des failles de sécurité les plus courantes et les plus graves (quiconque ayant accès au repo, ou dans un repo public, obtient les clés de votre application et de vos données).

Comprendre les solutions — lire la configuration et les secrets à partir de **variables d'environnement** (les garder hors du code, l'approche twelve-factor, souvent avec des outils comme django-environ et des fichiers `.env` ignorés par git) et **diviser les paramètres** en un base partagé plus des fichiers par environnement — est essentiel pour déployer Django en toute sécurité et correctement.

Connaître les **paramètres critiques de production** (notamment que `DEBUG` doit être `False` en production, puisque `DEBUG=True` fuite les tracebacks, les chemins source et les paramètres aux attaquants, plus `ALLOWED_HOSTS` et le durcissement de la sécurité) est une connaissance de production non négociable.

Bien gérer les paramètres — les secrets dans l'environnement, la configuration appropriée à l'environnement, les défauts de sécurité de production — est fondamental pour exécuter les applications Django de manière professionnelle et pour éviter les vulnérabilités graves qui résultent des secrets divulgués ou des environnements de production mal configurés, ce qui en fait une connaissance importante et pratiquement critique pour tout déploiement réel.

Le problème avec un seul settings.py

Solution 1 : lire la configuration à partir de variables d'environnement

Solution 2 : diviser les fichiers de paramètres par environnement

Paramètres critiques de production

Pourquoi c'est important

Questions connexes