OUJOOD.COM
Passer d'un projet qui tourne sur votre ordinateur à un site accessible par tout le monde est une étape stressante. On ne compte plus les sites piratés ou plantés parce qu'une option de test est restée activée par erreur. Je vous ai préparé une liste des points non négociables pour que votre mise en ligne ne tourne pas au cauchemar.
Le réglage fatal : DEBUG = False
C'est la règle numéro un. En développement, DEBUG = True est génial car il affiche vos erreurs en détail. En production, c'est une faille de sécurité béante : n'importe qui pourrait voir la structure de votre code et vos variables secrètes en provoquant une erreur. Passez-le immédiatement à False.
Définir les hôtes autorisés
Une fois le mode debug désactivé, Django refuse de répondre si vous ne lui dites pas quel nom de domaine il doit écouter. C'est le rôle de ALLOWED_HOSTS. Vous devez y inscrire votre domaine et éventuellement l'adresse IP de votre serveur.
DEBUG = False ALLOWED_HOSTS = ['www.votre-site.com', '123.45.67.89']
Rassembler les fichiers statiques
En local, Django s'occupe de servir vos fichiers CSS et vos images. En production, il délègue ce travail à un serveur plus rapide (comme Nginx). Pour cela, vous devez exécuter une commande qui va "aspirer" tous les fichiers statiques de vos applications pour les mettre dans un dossier unique nommé STATIC_ROOT.
python manage.py collectstatic
Sécuriser les secrets
Je ne le répéterai jamais assez : votre SECRET_KEY et vos accès à la base de données ne doivent pas être visibles. Si vous avez bien suivi la leçon sur les variables d'environnement Django, vous êtes déjà protégé. Sinon, c'est le moment ou jamais de corriger le tir.
Une fois ces réglages validés, votre projet est prêt techniquement. Il lui faut maintenant un moteur pour tourner sur le serveur. C'est ce que nous allons voir avec la mise en place de Gunicorn et Nginx.
Par carabde | Mis à jour le 09/05/2026