--- title: "Liste de contrôle de déploiement" version: 2.2 locale: fr source: https://docs.djangoproject.com/fr/2.2/howto/deployment/checklist/ canonical: https://djangodocs.dev/fr/2.2/howto/deployment/checklist/ --- # Liste de contrôle de déploiement Internet est un environnement hostile. Avant de déployer votre projet Django, il est recommandé de passer du temps à vérifier les réglages en ayant à l’esprit la sécurité, la performance et les opérations. Django contient beaucoup de [fonctionnalités liées à la sécurité](/fr/2.2/topics/security/). Certaines sont intégrées et toujours actives. D’autres sont facultatives car elles ne sont pas toujours adéquates ou parce qu’elles ne conviennent pas durant le développement. Par exemple, l’utilisation exclusive de HTTPS ne convient pas à tous les sites Web et ce n’est pas réaliste lors du développement local. Les optimisations de performance sont une autre catégorie de compromis entre efficacité et commodité. Par exemple, l’utilisation de cache est utile en production, beaucoup moins lors du développement local. Les besoins en terme de signalement d’erreurs sont aussi très différents. La liste de contrôle suivante contient des réglages qui : - doivent être configurés correctement pour que Django puisse garantir le niveau de sécurité attendu ; - sont généralement différents en fonction de chaque environnement ; - activent des fonctionnalités de sécurité facultatives ; - activent des optimisations de performance ; - s’occupent du signalement des erreurs. Beaucoup de ces réglages sont sensibles et doivent être traités de manière confidentielle. Si vous publiez le code source de votre projet, une pratique courante est de publier des réglages convenant au développement, mais d’utiliser un module de réglages privés à destination de la production. ## Lancez `manage.py check --deploy` Certains des contrôles présentés ci-dessous peuvent être automatisés en utilisant l’option `--deploy`. Prenez garde de la lancer en activant le fichier de réglages de production comme décrit dans la documentation de l’option. ## Réglages critiques ### [`SECRET_KEY`](/fr/2.2/ref/settings/#std-setting-SECRET_KEY) **La clé secrète doit être une longue valeur aléatoire et doit rester confidentielle.** Assurez-vous que la clé utilisée en production n’est employée nulle part ailleurs et ne l’ajoutez pas dans le système de gestion de versions. Cela réduit le nombre de vecteurs par lesquels un attaquant pourrait trouver la clé. Au lieu d’inscrire statiquement la clé secrète dans votre module de réglages, envisagez de la charger à partir d’une variable d’environnement : ``` import os SECRET_KEY = os.environ['SECRET_KEY'] ``` ou à partir d’un fichier : ``` with open('/etc/secret_key.txt') as f: SECRET_KEY = f.read().strip() ``` ### [`DEBUG`](/fr/2.2/ref/settings/#std-setting-DEBUG) **Vous ne devez jamais activer \`\`DEBUG\`\` en production.** Vous développez certainement votre projet avec [`DEBUG = True`](/fr/2.2/ref/settings/#std-setting-DEBUG), car cela offre des possibilités bien pratiques comme les traces d’appel détaillées dans votre navigateur. Dans un environnement de production, cependant, c’est une très mauvaise idée, parce que cela révèle de nombreuses informations sur votre projet : extraits de code source, variables locales, réglages, bibliothèques utilisées, etc. ## Réglages spécifiques à l’environnement ### [`ALLOWED_HOSTS`](/fr/2.2/ref/settings/#std-setting-ALLOWED_HOSTS) Lorsque [`DEBUG = False`](/fr/2.2/ref/settings/#std-setting-DEBUG), Django ne fonctionne pas du tout sans une valeur correcte de [`ALLOWED_HOSTS`](/fr/2.2/ref/settings/#std-setting-ALLOWED_HOSTS). Ce réglage est obligatoire pour protéger votre site contre certaines attaques CSRF. Si vous indiquez un caractère générique, vous devez effectuer vous-même la validation de l’en-tête HTTP `Host`, ou sinon vous assurer que vous n’êtes pas vulnérable à cette catégorie d’attaques. Il s’agit également de configurer le serveur Web placé devant Django pour valider l’hôte. En cas de requêtes avec des noms d’hôte incorrects, le serveur Web devrait répondre avec une page d’erreur statique ou ignorer ces requêtes au lieu de les transférer vers Django. De cette façon, cela évitera de polluer les journaux de Django avec des erreurs (ou des courriels si vous avez configuré le signalement d’erreur par ce biais). Par exemple avec nginx, il est possible de configurer le serveur afin qu’il renvoie par défaut des erreurs « 444 No Response » s’il détecte un hôte inconnu : ```nginx server { listen 80 default_server; return 444; } ``` ### [`CACHES`](/fr/2.2/ref/settings/#std-setting-CACHES) Si vous utilisez du cache, les paramètres de connexion peuvent être différents entre le développement et la production. Par défaut, Django utilise le [cache en mémoire locale](/fr/2.2/topics/cache/#local-memory-caching), ce qui n’est pas toujours le plus approprié. Les serveurs de cache ont souvent une faible authentification. Assurez-vous qu’ils n’acceptent de connexions que de vos serveurs d’applications. Si vous utilisez Memcached, envisagez l’utilisation de [sessions en cache](/fr/2.2/topics/http/sessions/#cached-sessions-backend) pour améliorer les performances. ### [`DATABASES`](/fr/2.2/ref/settings/#std-setting-DATABASES) Les paramètres de connexion à la base de données sont probablement différents entre le développement et la production. Les mots de passe de base de données sont très sensibles. Vous devez les protéger aussi bien que [`SECRET_KEY`](/fr/2.2/ref/settings/#std-setting-SECRET_KEY). Pour une sécurité maximale, assurez-vous que les serveurs de bases de données n’acceptent des connexions que de vos serveurs d’applications. Si vous n’avez pas configuré de sauvegardes pour votre base de données, faites-le maintenant ! ### [`EMAIL_BACKEND`](/fr/2.2/ref/settings/#std-setting-EMAIL_BACKEND) et réglages liés Si votre site envoie des courriels, ces valeurs doivent être définies correctement. Par défaut, Django envoie ses messages avec les adresses d’origine [webmaster@localhost](mailto:webmaster@localhost) et [root@localhost](mailto:root@localhost). Toutefois, certains fournisseurs de messagerie rejettent les messages provenant de ces adresses. Pour utiliser des adresses d’expéditeur différentes, modifiez les réglages [`DEFAULT_FROM_EMAIL`](/fr/2.2/ref/settings/#std-setting-DEFAULT_FROM_EMAIL) et [`SERVER_EMAIL`](/fr/2.2/ref/settings/#std-setting-SERVER_EMAIL). ### [`STATIC_ROOT`](/fr/2.2/ref/settings/#std-setting-STATIC_ROOT) et [`STATIC_URL`](/fr/2.2/ref/settings/#std-setting-STATIC_URL) Les fichiers statiques sont servis automatiquement par le serveur de développement. En production, vous devez définir un répertoire [`STATIC_ROOT`](/fr/2.2/ref/settings/#std-setting-STATIC_ROOT) dans lequel [`collectstatic`](/fr/2.2/ref/contrib/staticfiles/#django-admin-collectstatic) va copier les fichiers. Voir [Gestion des fichiers statiques (par ex. images, JavaScript, CSS)](/fr/2.2/howto/static-files/) pour plus d’informations. ### [`MEDIA_ROOT`](/fr/2.2/ref/settings/#std-setting-MEDIA_ROOT) et [`MEDIA_URL`](/fr/2.2/ref/settings/#std-setting-MEDIA_URL) Les fichiers « média » sont téléversés par vos utilisateurs. Vous ne devez pas leur faire confiance ! Vérifiez que votre serveur Web n’essaie jamais de les interpréter. Par exemple, si un utilisateur téléverse un fichier `.php`, le serveur Web ne doit jamais l’exécuter. C’est maintenant le moment favorable de vérifier votre stratégie de sauvegarde pour ces fichiers. ### [`FILE_UPLOAD_PERMISSIONS`](/fr/2.2/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) Avec les réglages de téléversement de fichier par défaut, les fichiers plus petits que [`FILE_UPLOAD_MAX_MEMORY_SIZE`](/fr/2.2/ref/settings/#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) peuvent être stockés avec des permissions différentes que les grands fichiers, comme décrit dans [`FILE_UPLOAD_PERMISSIONS`](/fr/2.2/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS). Le réglage de [`FILE_UPLOAD_PERMISSIONS`](/fr/2.2/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) garantit que les fichiers téléversés ont tous les mêmes permissions. ## HTTPS Tout site Web autorisant des utilisateurs à se connecter devrait imposer l’accès HTTPS généralisé pour éviter de transmettre des jetons d’accès en clair. Dans Django, les jetons d’accès contiennent l’identifiant et le mot de passe, le cookie de session et les jetons de réinitialisation de mot de passe (vous ne pouvez guère mieux protéger les jetons de réinitialisation de mot de passe si vous les envoyer par courriel). La protection de zones sensibles comme les comptes des utilisateurs ou l’interface d’administration n’est pas suffisant, car le même cookie de session est utilisé à la fois pour HTTP et HTTPS. Votre serveur Web doit rediriger tout le trafic HTTP vers HTTPS et ne transmettre que les requêtes HTTPS à Django. Après avoir configuré HTTPS, activez les réglages suivants. ### [`CSRF_COOKIE_SECURE`](/fr/2.2/ref/settings/#std-setting-CSRF_COOKIE_SECURE) Définissez-le à `True` pour éviter de transmettre le cookie CSRF accidentellement par HTTP. ### [`SESSION_COOKIE_SECURE`](/fr/2.2/ref/settings/#std-setting-SESSION_COOKIE_SECURE) Définissez-le à `True` pour éviter de transmettre le cookie de session accidentellement par HTTP. ## Optimisations de performance La configuration de [`DEBUG = False`](/fr/2.2/ref/settings/#std-setting-DEBUG) désactive plusieurs fonctionnalités qui ne sont utiles qu’en cours de développement. De plus, vous pouvez affiner les réglages suivants. ### [`CONN_MAX_AGE`](/fr/2.2/ref/settings/#std-setting-CONN_MAX_AGE) L’activation des [connexions persistantes à la base de données](/fr/2.2/ref/databases/#persistent-database-connections) peut significativement améliorer les performances quand la connexion à la base de données constitue une part importante du temps de traitement des requêtes. C’est un plus important sur des hôtes virtualisés dont la performance réseau est limitée. ### [`TEMPLATES`](/fr/2.2/ref/settings/#std-setting-TEMPLATES) L’activation du cache des chargeurs de gabarits améliore souvent les performances de manière très importante, car cela évite de devoir recompiler les gabarits lors de chacun de leurs rendus. Consultez la [documentation sur les chargeurs de gabarits](/fr/2.2/ref/templates/api/#template-loaders) pour plus d’informations. ## Signalement d’erreurs Au moment de passer votre code en production, il est censé être robuste, mais on ne peut jamais exclure des erreurs inattendues. Heureusement, Django peut capturer les erreurs et vous en avertir. ### [`LOGGING`](/fr/2.2/ref/settings/#std-setting-LOGGING) Analysez votre configuration de la journalisation avant de mettre votre site Web en production et contrôlez qu’elle fonctionne comme prévu dès que l’application commence à recevoir du trafic. Consultez [Journalisation](/fr/2.2/topics/logging/) pour plus de détails sur la journalisation. ### [`ADMINS`](/fr/2.2/ref/settings/#std-setting-ADMINS) et [`MANAGERS`](/fr/2.2/ref/settings/#std-setting-MANAGERS) Les [`ADMINS`](/fr/2.2/ref/settings/#std-setting-ADMINS) sont avertis par courriel des erreurs de type 500. Les [`MANAGERS`](/fr/2.2/ref/settings/#std-setting-MANAGERS) sont avertis des erreurs 404. [`IGNORABLE_404_URLS`](/fr/2.2/ref/settings/#std-setting-IGNORABLE_404_URLS) peut aider à filtrer les signalements inopportuns. Consultez [Signalement d’erreurs](/fr/2.2/howto/error-reporting/) pour plus de détails sur le signalement d’erreurs par courriel. > **Le signalement d’erreurs par courriel n’est pas adapté au fort trafic** > > Considérez l’emploi d’un système de surveillance d’erreurs tel que [Sentry](https://docs.sentry.io/) avant de voir votre boîte de réception inondée de messages. Sentry peut aussi collecter la journalisation. ### Personnalisation des vues d’erreurs par défaut Django inclut des vues et des gabarits par défaut pour plusieurs codes d’erreurs HTTP. Il peut être souhaitable de remplacer les gabarits par défaut en créant les gabarits suivants dans votre répertoire de gabarits racine : `404.html`, `500.html`, `403.html` et `400.html`. Les [vues d’erreur par défaut](/fr/2.2/ref/views/#error-views) qui utilisent ces gabarits devraient convenir à 99 % des applications Web, mais vous pouvez très bien les [adapter](/fr/2.2/topics/http/views/#customizing-error-views) aussi.