python manage.py runserver 0.0.0.0:8000 exposé sur Internet avec DEBUG=True. La base SQLite en production. Les uploads dans le dépôt. Trois erreurs qui transforment un projet Django prometteur en fuite de données en attente. Le parcours minimal vers un déploiement propre est connu — il suffit de ne pas le raccourcir par fatigue.
Django en production n'est pas plus complexe qu'un autre framework web. C'est surtout une question de discipline : séparer les environnements, externaliser les fichiers, et ne jamais confondre ce qui marchait en local avec ce qui est acceptable face au public.
Parcours minimal en sept étapes
| Étape | Commande / action | Oubli fréquent |
|---|---|---|
| Settings prod | Module settings/production.py, DEBUG=False | Clé secrète commitée |
| Base | PostgreSQL ou MySQL | SQLite en prod |
| Static | collectstatic → nginx/CDN | Static servis par Django |
| Media | Stockage objet ou volume dédié | Media dans git |
| WSGI | Gunicorn + socket ou port | runserver |
| Proxy | nginx TLS + en-têtes | Pas de redirection HTTPS |
| Migrations | migrate avec backup | migrate sans test rollback |
Django en production, c'est surtout ne plus faire ce qui était pratique en local.
Stack type
Internet → nginx (TLS, static) → Gunicorn (workers) → Django
↓
PostgreSQL
↓
Redis (cache/Celery optionnel)
Les workers Gunicorn : règle (2 × CPU) + 1 comme point de départ — ajustez selon mémoire et requêtes lourdes.
Variables et secrets
Définissez DJANGO_SETTINGS_MODULE vers la configuration de production. Utilisez une SECRET_KEY unique par environnement. Listez explicitement ALLOWED_HOSTS — pas de joker *. Configurez le backend email (SMTP ou API transactionnelle). Ajoutez CSRF_TRUSTED_ORIGINS si vous servez plusieurs domaines. Injectez les variables via l'hébergeur ou un fichier hors dépôt.
Celery et tâches asynchrones
Si vous envoyez des emails, lancez des exports ou traitez des webhooks lourds, prévoyez un broker Redis ou RabbitMQ, un worker supervisé, un monitoring des tâches échouées, et séparez worker web et worker batch si la charge le justifie.
Sans Celery, un export CSV de dix mille lignes bloquera un worker Gunicorn pendant toute la durée du traitement — les autres visiteurs attendent. Avec Celery, la requête HTTP renvoie immédiatement un identifiant de tâche ; le worker batch traite en arrière-plan. Ce n'est pas obligatoire au jour un, mais prévoir Redis dès le départ coûte moins cher que refactoriser sous charge.
Hébergement : critères pour Django
Un hébergeur Django crédible permet au minimum : Python 3.x avec virtualenv ou conteneur, PostgreSQL accessible (idéalement managé), SSH ou déploiement Git, et assez de RAM pour Gunicorn plus workers Celery si besoin. Évitez le mutualisé sans accès WSGI — vous ne contrôlerez ni Gunicorn ni les variables d'environnement.
Les PaaS Python (alwaysdata, Clever Cloud, Platform.sh) simplifient le premier déploiement en encapsulant Gunicorn, TLS et parfois PostgreSQL managé. Un VPS exige plus de configuration initiale mais offre plus de contrôle — choix d'architecture, pas de qualité intrinsèque.
Checklist post-déploiement
Après mise en production, vérifiez : redirection HTTPS forcée, en-têtes sécurité (HSTS, X-Content-Type-Options), SECRET_KEY et mots de passe DB hors dépôt, sauvegardes PostgreSQL testées en restauration, monitoring 5xx et espace disque media, et absence de DEBUG=True dans les settings actifs. Cette checklist tient en trente minutes — elle évite des incidents qui durent des week-ends.
Le sommet : Django prod est boring by design
Consultez Héberger Node.js pour la culture processus long — les principes proxy plus workers sont similaires.
Décider et avancer sans angle mort
Créez un module settings prod séparé et interdisez DEBUG=True en production. Passez à PostgreSQL avec des sauvegardes testées régulièrement. Configurez nginx plus Gunicorn sous systemd ou équivalent. Intégrez collectstatic dans le pipeline de déploiement. Surveillez les erreurs 5xx et l'espace disque media. Parcourez les hébergeurs Python dans l'annuaire.
Questions fréquentes
Django peut-il tourner sans Gunicorn ?
Non en production — Gunicorn, uWSGI ou ASGI derrière un reverse proxy. Le serveur de développement intégré n'est pas conçu pour le trafic public.
Où servir static et media ?
Static via nginx ou CDN après collectstatic ; media via stockage objet ou volume dédié sauvegardé.
Faut-il Celery dès le départ ?
Dès tâches asynchrones — sinon reportez avec Redis prévu si vous savez que ça arrive.
Quel hébergeur pour une première app Django ?
PaaS Python ou VPS avec PostgreSQL managé. Évitez le mutualisé sans contrôle WSGI.
Un Django en production ne se reconnaît pas à son URL — il se reconnaît à l'absence de runserver dans ps aux.