---
title: "Réglages"
version: 1.9
locale: fr
source: https://docs.djangoproject.com/fr/1.9/ref/settings/
canonical: https://djangodocs.dev/fr/1.9/ref/settings/
---
# Réglages

- [Réglages de base](#core-settings)
- [Auth](#auth)
- [Messages](#messages)
- [Sessions](#sessions)
- [Sites](#sites)
- [Fichiers statiques](#static-files)
- [Index thématique des réglages de base](#core-settings-topical-index)

> **Warning**
>
> Soyez prudent lorsque vous surchargez les réglages, particulièrement quand la valeur par défaut est une liste ou un dictionnaire non vide, comme [`MIDDLEWARE_CLASSES`](#std-setting-MIDDLEWARE_CLASSES) et [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS). Prenez soin de conserver les composants requis par les fonctionnalités de Django que vous souhaitez utiliser.

## Réglages de base

Voici une liste des réglages disponibles au sein de Django et leurs valeurs par défaut. Les réglages fournis par les applications contrib sont énumérés ci-dessous, suivi d’un index des réglages de base par sujet. Pour du contenu d’initiation, consultez le [guide thématique des réglages](/fr/1.9/topics/settings/).

### `ABSOLUTE_URL_OVERRIDES`

Valeur par défaut : `{}` (dictionnaire vide)

Un dictionnaire faisant correspondre des chaînes du style `"étiquette_app.nom_modèle"` à des fonctions qui acceptent un objet de modèle et renvoient son URL. C’est une façon d’insérer ou de surcharger les méthodes `get_absolute_url()` en fonction de l’installation. Par exemple :

```
ABSOLUTE_URL_OVERRIDES = {
    'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
    'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}
```

Notez que le nom de modèle utilisé dans ce réglage doit être tout en minuscules, quelle que soit la casse du nom de la classe modèle réelle.

### `ADMINS`

Valeur par défaut : `[]` (liste vide)

Une liste de toutes les personnes qui reçoivent les notifications d’erreurs dans le code. Lorsque `DEBUG=False` et qu’une vue lève une exception, Django envoie un courriel à ces personnes contenant les informations complètes de l’exception. Chaque élément de la liste doit être un tuple au format « (nom complet, adresse électronique) ». Exemple :

```
[('John', 'john@example.com'), ('Mary', 'mary@example.com')]
```

Notez que Django envoie un courriel à *toutes* ces personnes lors de chaque erreur. Consultez [Signalement d’erreurs](/fr/1.9/howto/error-reporting/) pour plus d’informations.

### `ALLOWED_HOSTS`

Valeur par défaut : `[]` (liste vide)

A list of strings representing the host/domain names that this Django site can
serve. This is a security measure to prevent [HTTP Host header attacks](/fr/1.9/topics/security/#host-headers-virtual-hosting), which are possible even under many
seemingly-safe web server configurations.

Les valeurs de cette liste peuvent être des noms complètement qualifiés (par ex. `'www.example.com'`), auquel cas ils seront comparés exactement (insensible à la casse, port exclu) avec l’en-tête `Host` de la requête. Une valeur commençant par un point peut être utilisée comme métacaractère de sous-domaine : `'.example.com'` correspondra à `example.com`, `www.example.com`, et tout autre sous-domaine de `example.com`. Une valeur `'*'` correspond à tout ; dans ce cas, vous êtes responsable de fournir votre propre validation de l’en-tête `Host` (éventuellement dans un middleware ; dans ce cas, le middleware doit figurer en premier dans [`MIDDLEWARE_CLASSES`](#std-setting-MIDDLEWARE_CLASSES)).

Django permet également d’écrire un [nom de domaine pleinement qualifié (FQDN)](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) dans la liste. Certains navigateurs incluent un point terminal dans l’en-tête `Host`; Django l’enlève au moment de la validation d’hôte.

Si l’en-tête `Host` (ou `X-Forwarded-Host` quand [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) est actif) ne correspond à aucune valeur de cette liste, la méthode [`django.http.HttpRequest.get_host()`](/fr/1.9/ref/request-response/#django.http.HttpRequest.get_host) lèvera [`SuspiciousOperation`](/fr/1.9/ref/exceptions/#django.core.exceptions.SuspiciousOperation).

When [`DEBUG`](#std-setting-DEBUG) is `True` and `ALLOWED_HOSTS` is empty, the host
is validated against `['localhost', '127.0.0.1', '[::1]']`.

Cette validation ne s’applique qu’avec [`get_host()`](/fr/1.9/ref/request-response/#django.http.HttpRequest.get_host) ; si votre code accède directement à l’en-tête `Host` dans `request.META`, vous outrepassez cette protection de sécurité.

> **Changed in Django 1.9.11**
>
> In older versions, `ALLOWED_HOSTS` wasn’t checked if `DEBUG=True`.
> This was also changed in Django 1.8.16 to prevent a DNS rebinding attack.

### ALLOWED\_INCLUDE\_ROOTS

Valeur par défaut : `[]` (liste vide)

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Ce réglage ainsi que la balise de gabarit [`ssi`](/fr/1.9/ref/templates/builtins/#std-templatetag-ssi) sont obsolètes et seront supprimés dans Django 1.10.

> **Changed in Django 1.8**
>
> Alternativement, vous pouvez aussi définir l’option `'allowed_include_roots'` dans le réglage [`OPTIONS`](#std-setting-TEMPLATES-OPTIONS) du moteur de gabarit.

Une liste de chaînes représentant les préfixes autorisés pour la balise de gabarit `{% ssi %}`. C’est une mesure de sécurité pour que les auteurs de gabarits ne puissent pas accéder à des fichiers auxquels ils ne devraient pas avoir accès.

Par exemple, si [`ALLOWED_INCLUDE_ROOTS`](#std-setting-ALLOWED_INCLUDE_ROOTS) vaut `['/home/html', '/var/www']`, `{% ssi /home/html/foo.txt %}` fonctionne, mais pas `{% ssi /etc/passwd %}`.

### `APPEND_SLASH`

Valeur par défaut : `True`

Si défini à `True` et que l’URL de la requête ne correspond à aucun des motifs de l’URLconf et que l’URL ne se termine pas par une barre oblique (slash), Django effectue une redirection HTTP vers la même URL additionnée d’une barre oblique finale. Notez que la redirection peut causer la perte d’éventuelles données envoyées avec une requête POST.

Le réglage [`APPEND_SLASH`](#std-setting-APPEND_SLASH) n’est utilisé que si [`CommonMiddleware`](/fr/1.9/ref/middleware/#django.middleware.common.CommonMiddleware) est installé (voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/)). Voir aussi [`PREPEND_WWW`](#std-setting-PREPEND_WWW).

### `CACHES`

Valeur par défaut :

```
{
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    }
}
```

Un dictionnaire contenant les réglages de tous les caches à utiliser avec Django. C’est un dictionnaire imbriqué dont les contenus sont une correspondance entre les alias des caches et un dictionnaire contenant les options de chacun des caches.

Le réglage [`CACHES`](#std-setting-CACHES) doit configurer un cache `default` (par défaut) ; il est possible d’ajouter autant d’autres caches que souhaité. Si vous utilisez un moteur de cache autre que le cache de mémoire locale ou que vous deviez définir plusieurs caches, d’autres options devront être ajoutées. Les options de cache suivantes sont disponibles.

#### `BACKEND`

Valeur par défaut : `''` (Chaîne vide)

Le moteur de cache à utiliser. Les moteurs de cache intégrés à Django sont :

- `'django.core.cache.backends.db.DatabaseCache'`
- `'django.core.cache.backends.dummy.DummyCache'`
- `'django.core.cache.backends.filebased.FileBasedCache'`
- `'django.core.cache.backends.locmem.LocMemCache'`
- `'django.core.cache.backends.memcached.MemcachedCache'`
- `'django.core.cache.backends.memcached.PyLibMCCache'`

Vous pouvez utiliser un moteur de cache non livré avec Django en définissant [`BACKEND`](#std-setting-CACHES-BACKEND) à un chemin complètement qualifié d’une classe de moteur de cache (par ex. `monpaquet.moteurs.quelquechose.MonCache`).

#### `KEY_FUNCTION`

Une chaîne contenant un chemin pointé vers une fonction (ou tout autre objet exécutable) qui définit la manière de composer un préfixe, une version et une clé pour former une clé de cache finale. L’implémentation par défaut est équivalente à la fonction :

```
def make_key(key, key_prefix, version):
    return ':'.join([key_prefix, str(version), key])
```

Vous pouvez utiliser n’importe quelle fonction de clé, tant que la signature des paramètres est la même.

Consultez la [documentation du cache](/fr/1.9/topics/cache/#cache-key-transformation) pour plus d’informations.

#### `KEY_PREFIX`

Valeur par défaut : `''` (Chaîne vide)

Une chaîne qui sera automatiquement incluse (préfixée par défaut) à toutes les clés de cache utilisées par le serveur Django.

Consultez la [documentation du cache](/fr/1.9/topics/cache/#cache-key-prefixing) pour plus d’informations.

#### `LOCATION`

Valeur par défaut : `''` (Chaîne vide)

L’emplacement du cache. Cela peut être un répertoire pour un cache en système de fichiers, un hôte et un port pour le moteur `memcache`, ou simplement un identifiant pour un cache en mémoire locale, par ex. :

```
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}
```

#### `OPTIONS`

Valeur par défaut : `None`

Paramètres supplémentaires à transmettre au moteur de cache. Les paramètres disponibles varient en fonction du moteur de cache.

Certaines informations sur les paramètres disponibles peuvent être trouvées dans la documentation des [moteurs de cache](/fr/1.9/topics/cache/). Pour plus d’informations, consultez la documentation propre au module du moteur utilisé.

#### `TIMEOUT`

Valeur par défaut : `300`

Le nombre de secondes avant qu’une entrée de cache soit considérée comme obsolète. Si la valeur de ce réglage est `None`, les contenus du cache n’expirent jamais.

#### `VERSION`

Valeur par défaut : `1`

Le numéro de version par défaut des clés de cache générées par le serveur Django.

Consultez la [documentation du cache](/fr/1.9/topics/cache/#cache-versioning) pour plus d’informations.

### `CACHE_MIDDLEWARE_ALIAS`

Valeur par défaut : `default`

La connexion de cache à utiliser pour l”[intergiciel de cache](/fr/1.9/topics/cache/#the-per-site-cache).

### `CACHE_MIDDLEWARE_KEY_PREFIX`

Valeur par défaut : `''` (Chaîne vide)

Une chaîne qui servira de préfixe aux clés de cache générées par l”[intergiciel de cache](/fr/1.9/topics/cache/#the-per-site-cache). Ce préfixe est combiné avec le réglage [`KEY_PREFIX`](#std-setting-CACHES-KEY_PREFIX), il ne le remplace pas.

Voir [L’infrastructure de cache dans Django](/fr/1.9/topics/cache/).

### `CACHE_MIDDLEWARE_SECONDS`

Valeur par défaut : `600`

Le nombre de secondes correspondant à la durée par défaut de mise en cache d’une page pour l”[intergiciel de cache](/fr/1.9/topics/cache/#the-per-site-cache).

Voir [L’infrastructure de cache dans Django](/fr/1.9/topics/cache/).

### `CSRF_COOKIE_AGE`

Valeur par défaut : `31449600` (environ 1 année, en secondes)

L’âge des cookies CSRF, en secondes.

La raison de définir un temps d’expiration de longue durée est d’éviter des problèmes au cas où un utilisateur ferme son navigateur ou place une page dans ses signets, puis recharge cette page à partir du cache du navigateur. Sans cookie à durée prolongée, l’envoi du formulaire échoue dans ce scénario.

Certains navigateurs (spécifiquement Internet Explorer) peuvent prohiber l’utilisation de cookies persistants ou posséder un index de conteneur de cookies corrompu sur disque, ce qui fera échouer les contrôles de protection CSRF (et parfois de manière intermittente). Définissez ce réglage à `None` pour utiliser des cookies CSRF basés sur la session, ce qui conserve les cookies en mémoire au lieu d’utiliser un stockage persistant.

### `CSRF_COOKIE_DOMAIN`

Valeur par défaut : `None`

Le domaine à utiliser lors de la définition du cookie CSRF. Cela peut être utile pour facilement exclure des requêtes inter-domaines de la protection habituelle contre les attaques inter-sites. Il devrait être défini à une chaîne telle que `".example.com"` pour autoriser une requête POST provenant d’un formulaire d’un sous-domaine à être acceptée par une vue servie sur un autre sous-domaine.

Notez que la présence de ce réglage n’implique pas que la protection CSRF de Django soit assurée par défaut contre des attaques inter-sous-domaines ; consultez la section sur les [limites de CSRF](/fr/1.9/ref/csrf/#csrf-limitations).

### `CSRF_COOKIE_HTTPONLY`

Valeur par défaut : `False`

Indique si le drapeau `HttpOnly` doit être utilisé sur le cookie CSRF. Si ce paramètre est défini à `True`, le JavaScript côté client ne sera pas en mesure d’accéder au cookie CSRF.

Ceci peut contribuer à éviter que du code JavaScript malicieux outrepasse la protection CSRF. Si vous activez ceci et que vous avez besoin d’envoyer la valeur du jeton CSRF à partir de requêtes Ajax, votre code JavaScript devra obtenir la valeur à partir d’un composant de formulaire caché contenant le jeton CSRF dans la page au lieu de l’obtenir par le cookie.

Voir [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) pour plus de détails sur `HttpOnly`.

### `CSRF_COOKIE_NAME`

Valeur par défaut :: `'csrftoken'`

Le nom du cookie à utiliser pour le jeton d’authentification CSRF. Vous pouvez y mettre ce qui vous plaît (tant que c’est un nom de cookie différent de ceux qui existent déjà). Voir [Protection contre le « Cross site request forgery » (CSRF)](/fr/1.9/ref/csrf/).

### `CSRF_COOKIE_PATH`

Valeur par défaut : `'/'`

Le chemin défini dans le cookie CSRF. Cela devrait correspondre au chemin d’URL de votre installation Django ou être un parent de ce chemin.

C’est utile lorsque vous avez plusieurs instances Django fonctionnant sous le même nom d’hôte. Elles peuvent alors utiliser des chemins de cookie différents et chaque instance ne verra que ses propres cookies CSRF.

### `CSRF_COOKIE_SECURE`

Valeur par défaut : `False`

Indique s’il est nécessaire d’utiliser un cookie sécurisé pour le cookie CSRF. Si défini à `True`, le cookie sera marqué comme « sécurisé », ce qui signifie que les navigateurs sont chargés de vérifier que le cookie n’est envoyé que pour des connexions HTTPS.

### `CSRF_FAILURE_VIEW`

Valeur par défaut : `'django.views.csrf.csrf_failure'`

Un chemin pointé vers la fonction Vue à utiliser lorsqu’une requête entrante est rejetée par la [protection CSRF](/fr/1.9/ref/csrf/). La fonction doit avoir cette signature :

```
def csrf_failure(request, reason=""):
    ...
```

où `reason` est un bref message (à l’intention des développeurs ou de la journalisation, par pour les utilisateurs finaux) indiquant la raison du rejet de la requête. Elle devrait renvoyer une réponse [`HttpResponseForbidden`](/fr/1.9/ref/request-response/#django.http.HttpResponseForbidden).

### `CSRF_HEADER_NAME`

> **New in Django 1.9**

Valeur par défaut : `'HTTP_X_CSRFTOKEN'`

Le nom de l’en-tête de requête utilisé pour l’authentification CSRF.

Comme avec d’autres en-têtes HTTP dans `request.META`, le nom d’en-tête reçu du serveur est normalisé en convertissant tous les caractères en majuscules, remplaçant les tirets par des soulignements et en ajoutant un préfixe `HTTP_` au nom. Par exemple, si un client envoie un en-tête `'X-XSRF-TOKEN'`, le réglage devrait être `'HTTP_X_XSRF_TOKEN'`.

### `CSRF_TRUSTED_ORIGINS`

> **New in Django 1.9**

Valeur par défaut : `[]` (liste vide)

Une liste d’hôtes qui sont des origines de confiance pour les requêtes non sûres (par ex. `POST`). Pour une requête [`sécurisée`](/fr/1.9/ref/request-response/#django.http.HttpRequest.is_secure) non sûre, la protection CSRF de Django exige que la requête possède un en-tête `Referer` correspondant à l’origine présente dans l’en-tête `Host`. Cela empêche par exemple qu’une requête `POST` à partir de `sousdomaine.exemple.com` puisse aboutir sur `api.exemple.com`. En continuant sur cet exemple, si vous avez besoin de pouvoir effectuer des requêtes croisées non sûres entre domaines et par HTTPS, ajoutez `"sousdomaine.exemple.com"` à cette liste. Le réglage accepte également les sous-domaines, de sorte que par exemple, `".exemple.com"` serait aussi valable pour permettre l’accès depuis tous les sous-domaines de `exemple.com`.

### `DATABASES`

Valeur par défaut : `{}` (dictionnaire vide)

Un dictionnaire contenant les réglages de toutes les bases de données à utiliser avec Django. C’est un dictionnaire imbriqué dont les contenus font correspondre l’alias de base de données avec un dictionnaire contenant les options de chacune des bases de données.

Le réglage [`DATABASES`](#std-setting-DATABASES) doit configurer une base de données `default`; il est possible de définir autant de bases de données que nécessaire.

Le fichier de réglages le plus simple possible est destiné à une configuration à base de données unique utilisant le moteur SQLite. Cela peut être configuré de cette façon :

```
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'mydatabase',
    }
}
```

Lors de la connexion à d’autres moteurs de base de données, tels que MySQL, Oracle ou PostgreSQL, des paramètres de connexion supplémentaires sont requis. Voir le réglage [`ENGINE`](#std-setting-DATABASE-ENGINE) ci-dessous sur la façon de spécifier d’autres types de bases de données. Cet exemple vaut pour PostgreSQL :

```
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydatabase',
        'USER': 'mydatabaseuser',
        'PASSWORD': 'mypassword',
        'HOST': '127.0.0.1',
        'PORT': '5432',
    }
}
```

Les options internes suivantes, qui peuvent être nécessaires pour des configurations plus complexes, sont disponibles :

#### `ATOMIC_REQUESTS`

Valeur par défaut : `False`

Définissez ce réglage à `True` pour envelopper chaque vue dans une transaction sur cette base de données. Voir [Couplage des transactions aux requêtes HTTP](/fr/1.9/topics/db/transactions/#tying-transactions-to-http-requests).

#### `AUTOCOMMIT`

Valeur par défaut : `True`

Définissez ce réglage à `False` si vous souhaitez [désactiver la gestion des transactions de Django](/fr/1.9/topics/db/transactions/#deactivate-transaction-management) et implémenter la vôtre.

#### `ENGINE`

Valeur par défaut : `''` (Chaîne vide)

Le moteur de base de données à utiliser. Les moteurs de base de données intégrés à Django sont :

- `'django.db.backends.postgresql'`
- `'django.db.backends.mysql'`
- `'django.db.backends.sqlite3'`
- `'django.db.backends.oracle'`

Vous pouvez utiliser un moteur de base de données non livré avec Django en définissant `ENGINE` à un chemin complètement qualifié d’une classe de moteur de base de données (par ex. `monpaquet.moteurs.quelquechose`).

> **Changed in Django 1.9**
>
> Le moteur `django.db.backends.postgresql` s’appelait `django.db.backends.postgresql_psycopg2` dans les versions précédentes. Par rétro-compatibilité, l’ancien nom fonctionne encore dans les versions plus récentes.

#### `HOST`

Valeur par défaut : `''` (Chaîne vide)

L’hôte à utiliser lors de la connexion à la base de données. Une chaîne vide signifie `localhost`. Non utilisé avec SQLite.

Si cette valeur commence par une barre oblique (`'/'`)  et que vous utilisez MySQL, MySQL se connectera par un connecteur Unix au connecteur indiqué. Par exemple :

```
"HOST": '/var/run/mysql'
```

Si vous utilisez MySQL et que cette valeur ne commence *pas* par une barre oblique, Django part du principe que la valeur est un hôte.

Si vous utilisez PostgreSQL, par défaut ([`HOST`](#std-setting-HOST) vide), la connexion à la base de données se fait au travers de connecteurs Unix (lignes « local » dans `pg_hba.conf`). Si votre connecteur de domaine UNIX n’est pas à l’emplacement standard, utilisez la même valeur `unix_socket_directory` que celle de `postgresql.conf`. Si vous préférez vous connecter via des connecteurs TCP, définissez [`HOST`](#std-setting-HOST) à « localhost » ou « 127.0.0.1 » (lignes « host » dans `pg_hba.conf`). Sous Windows, vous devez toujours définir [`HOST`](#std-setting-HOST), car les connecteurs de domaine Unix ne sont pas disponibles.

#### `NAME`

Valeur par défaut : `''` (Chaîne vide)

Le nom de la base de données à utiliser. Pour SQLite, c’est le chemin complet vers le fichier de la base de données. Quand un chemin est indiqué, utilisez toujours des barres obliques vers l’avant, même sur Windows (par ex. `C:/homes/user/mysite/sqlite3.db`).

#### `CONN_MAX_AGE`

Valeur par défaut : `0`

La durée de vie d’une connexion de base de données, en secondes. Utilisez `0` pour fermer les connexions de base de données à la fin de chaque requête – comportement historique de Django – et `None` pour les connexions persistantes illimitées.

#### `OPTIONS`

Valeur par défaut : `{}` (dictionnaire vide)

Des paramètres supplémentaires à utiliser lors de la connexion à la base de données. Les paramètres disponibles varient en fonction du moteur de base de données.

Certaines informations sur les paramètres disponibles peuvent être trouvées dans la documentation des [moteurs de base de données](/fr/1.9/ref/databases/). Pour plus d’informations, consultez la documentation propre au module du moteur utilisé.

#### `PASSWORD`

Valeur par défaut : `''` (Chaîne vide)

Le mot de passe à utiliser lors de la connexion à la base de données. Non utilisé avec SQLite.

#### `PORT`

Valeur par défaut : `''` (Chaîne vide)

Le port à utiliser lors de la connexion à la base de données. Une chaîne vide signifie le port par défaut. Non utilisé avec SQLite.

#### `TIME_ZONE`

> **New in Django 1.9**

Valeur par défaut : `None`

Une chaîne représentant le fuseau horaire des dates/heures stockées dans cette base de données (en supposant qu’elle prenne en charge les fuseaux horaires) ou `None`. Les valeurs acceptées sont les mêmes que pour le réglage général [`TIME_ZONE`](#std-setting-TIME_ZONE).

Ceci permet d’interagir avec des bases de données tierces qui stockent les dates/heures en heure locale plutôt qu’en UTC. Pour éviter des problèmes autour des changements d’heure d’été/hiver, vous ne devriez pas définir cette option pour les bases de données gérées par Django.

La définition de cette option nécessite l’installation de [pytz](http://pytz.sourceforge.net/).

Lorsque [`USE_TZ`](#std-setting-USE_TZ) vaut `True` et que la base de données ne gère pas les fuseaux horaires (par ex. SQLite, MySQL, Oracle), Django lit et écrit les dates/heures en heure locale en fonction de cette option quand elle est définie et en UTC si elle ne l’est pas.

Lorsque [`USE_TZ`](#std-setting-USE_TZ) vaut `True` et que la base de données prend en charge les fuseaux horaires (par ex. PostgreSQL), la définition de cette option produit une erreur.

> **Changed in Django 1.9**
>
> Avant Django 1.9, le moteur de base de données PostgreSQL acceptait une option `TIME_ZONE` non documentée, ce qui pouvait causer des corruptions de données.

Lorsque [`USE_TZ`](#std-setting-USE_TZ) vaut `False`, la définition de cette option produit une erreur.

#### `USER`

Valeur par défaut : `''` (Chaîne vide)

Le nom d’utilisateur à utiliser lors de la connexion à la base de données. Non utilisé avec SQLite.

#### `TEST`

Valeur par défaut : `{}` (dictionnaire vide)

Un dictionnaire de réglages pour les bases de données de test ; pour plus de détails sur la création et l’utilisation de bases de données de test, voir [La base de données de test](/fr/1.9/topics/testing/overview/#the-test-database).

Voici un exemple avec une configuration de base de données de test :

```
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'mydatabaseuser',
        'NAME': 'mydatabase',
        'TEST': {
            'NAME': 'mytestdatabase',
        },
    },
}
```

Les clés suivantes sont disponibles dans le dictionnaire `TEST`:

##### `CHARSET`

Valeur par défaut : `None`

Le codage de caractères utilisé pour créer la base de données de test. La valeur de cette chaîne est passée directement à la base de données, son format est donc dépendant du moteur.

Pris en charge par les moteurs [PostgreSQL](http://www.postgresql.org/docs/current/static/multibyte.html) (`postgresql`) et [MySQL](https://dev.mysql.com/doc/refman/5.6/en/charset-database.html) (`mysql`).

##### `COLLATION`

Valeur par défaut : `None`

L’ordre de collation à utiliser lors de la création de la base de données de test. Cette value est directement transmise au moteur, son format est donc spécifique au moteur.

Pris en charge uniquement pour le moteur `mysql` (consultez le [manuel de MySQL](https://dev.mysql.com/doc/refman/5.6/en/charset-database.html) pour plus de  détails).

##### `DEPENDENCIES`

Valeur par défaut : `['default']`, pour toutes les bases de données, excepté `default` qui n’a pas de dépendances.

Les dépendances d’ordre de création de la base de données. Consultez la documentation sur le [contrôle de l’ordre de création des bases de données de test](/fr/1.9/topics/testing/advanced/#topics-testing-creation-dependencies) pour plus de détails.

##### `MIRROR`

Valeur par défaut : `None`

L’alias de la base de données que cette base de données doit refléter durant les tests.

Ce réglage existe pour permettre de tester des configurations primaire/réplique (aussi appelées maître-esclaves par certaines bases de données) de plusieurs bases de données. Consultez la documentation sur le [test de configurations primaire/réplique](/fr/1.9/topics/testing/advanced/#topics-testing-primaryreplica) pour plus de détails.

##### `NAME`

Valeur par défaut : `None`

Le nom de la base de données à utiliser lors du fonctionnement de la suite de tests.

Si la valeur par défaut (`None`) est utilisée avec le moteur de base de données SQLite, les tests utiliseront une base de données en mémoire vive. Pour tous les autres moteurs de base de données, la base de données de test sera nommée `'test_' + DATABASE_NAME`.

Voir [La base de données de test](/fr/1.9/topics/testing/overview/#the-test-database).

##### `SERIALIZE`

Valeur booléenne permettant de contrôler si le lanceur de tests par défaut sérialise la base de données en une chaîne JSON en mémoire avant de lancer les tests (utilisé pour restaurer l’état de la base de données entre les tests s’il n’y a pas de transactions). Vous pouvez le définir à `False` pour accélérer nettement le temps de création si aucune de vos classes de test ne comporte [serialized\_rollback=True](/fr/1.9/topics/testing/overview/#test-case-serialized-rollback).

##### `CREATE_DB`

Valeur par défaut : `True`

Ce paramètre est spécifique à Oracle.

S’il est défini à `False`, l’espace de tables de test ne sera pas automatiquement créé au début des tests, ni supprimé à la fin.

##### `CREATE_USER`

Valeur par défaut : `True`

Ce paramètre est spécifique à Oracle.

Si défini à `False`, l’utilisateur test ne sera pas automatiquement créé au début des tests, ni supprimé à la fin.

##### `USER`

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

Le nom d’utilisateur à utiliser lors de la connexion à la base de données Oracle durant les tests. Si non fourni, Django utilise `'test_' + USER`.

##### `PASSWORD`

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

The password to use when connecting to the Oracle database that will be used
when running tests. If not provided, Django will generate a random password.

> **Changed in Django 1.9.11**
>
> Older versions used a hardcoded default password. This was also changed
> in 1.8.16 to fix possible security implications.

##### `TBLSPACE`

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

Le nom de l’espace de tables utilisé lors des tests. Si non fourni, Django utilise `'test_' + USER`.

> **Changed in Django 1.8**
>
> Précédemment, Django utilisait `'test_' + NAME` lorsqu’il ne trouvait pas de nom.

##### `TBLSPACE_TMP`

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

Le nom de l’espace de tables temporaire utilisé lors des tests. Si non fourni, Django utilise `'test_' + USER + '_temp'`.

> **Changed in Django 1.8**
>
> Précédemment, Django utilisait `'test_' + NAME + '_temp'` lorsqu’il ne trouvait pas de nom.

##### `DATAFILE`

> **New in Django 1.8**

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

Le nom du fichier de données à utiliser pour TBLSPACE. Si non fourni, Django utilise `TBLSPACE + '.dbf'`.

##### `DATAFILE_TMP`

> **New in Django 1.8**

Valeur par défaut : `None`

Ce paramètre est spécifique à Oracle.

Le nom du fichier de données à utiliser pour TBLSPACE\_TMP. Si non fourni, Django utilise `TBLSPACE_TMP + '.dbf'`.

##### `DATAFILE_MAXSIZE`

> **New in Django 1.8**

Valeur par défaut : `'500M'`

> **Changed in Django 1.8**
>
> La valeur précédente était `200M` et n’était pas configurable par l’utilisateur.

Ce paramètre est spécifique à Oracle.

La taille maximale que DATAFILE est autorisé à atteindre.

##### `DATAFILE_TMP_MAXSIZE`

> **New in Django 1.8**

Valeur par défaut : `'500M'`

> **Changed in Django 1.8**
>
> La valeur précédente était `200M` et n’était pas configurable par l’utilisateur.

Ce paramètre est spécifique à Oracle.

La taille maximale que DATAFILE\_TMP est autorisé à atteindre.

### `DATABASE_ROUTERS`

Valeur par défaut : `[]` (liste vide)

La liste des routeurs utilisés pour déterminer à quelle base de données il faut accéder lors de l’exécution d’une requête de base de données.

Consultez la documentation sur le [routage automatique des bases de données dans des configurations à plusieurs bases](/fr/1.9/topics/db/multi-db/#topics-db-multi-db-routing).

### `DATE_FORMAT`

Valeur par défaut : `'N j, Y'` (ex . : `Feb. 4, 2003`)

Le format par défaut pour l’affichage des champs dates dans les différentes parties du système. Notez que si [`USE_L10N`](#std-setting-USE_L10N) est défini à `True`, le format piloté par la locale a une priorité plus élevée et remplacera ce format. Voir les [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date).

Voir aussi [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) et [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT).

### `DATE_INPUT_FORMATS`

Valeur par défaut :

```
[
    '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
    '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
    '%d %b %Y', '%d %b, %Y',            # '25 Oct 2006', '25 Oct, 2006'
    '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006'
    '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006'
]
```

A list of formats that will be accepted when inputting data on a date field.
Formats will be tried in order, using the first valid one. Note that these
format strings use Python’s [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date)
template filter.

Lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce format.

Voir aussi [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) et [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS).

### `DATETIME_FORMAT`

Valeur par défaut : `'N j, Y, P'` (ex. `Feb. 4, 2003, 4 p.m.`)

Le format par défaut pour l’affichage des champs dates/heures dans les différentes parties du système. Notez que si [`USE_L10N`](#std-setting-USE_L10N) est défini à `True`, le format piloté par la locale a une priorité plus élevée et remplacera ce format. Voir les [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date).

Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) et [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT).

### `DATETIME_INPUT_FORMATS`

Valeur par défaut :

```
[
    '%Y-%m-%d %H:%M:%S',     # '2006-10-25 14:30:59'
    '%Y-%m-%d %H:%M:%S.%f',  # '2006-10-25 14:30:59.000200'
    '%Y-%m-%d %H:%M',        # '2006-10-25 14:30'
    '%Y-%m-%d',              # '2006-10-25'
    '%m/%d/%Y %H:%M:%S',     # '10/25/2006 14:30:59'
    '%m/%d/%Y %H:%M:%S.%f',  # '10/25/2006 14:30:59.000200'
    '%m/%d/%Y %H:%M',        # '10/25/2006 14:30'
    '%m/%d/%Y',              # '10/25/2006'
    '%m/%d/%y %H:%M:%S',     # '10/25/06 14:30:59'
    '%m/%d/%y %H:%M:%S.%f',  # '10/25/06 14:30:59.000200'
    '%m/%d/%y %H:%M',        # '10/25/06 14:30'
    '%m/%d/%y',              # '10/25/06'
]
```

A list of formats that will be accepted when inputting data on a datetime
field. Formats will be tried in order, using the first valid one. Note that
these format strings use Python’s [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date)
template filter.

Lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce format.

Voir aussi [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) et [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS).

### `DEBUG`

Valeur par défaut : `False`

Une valeur booléenne qui active ou désactive le mode de débogage.

Ne déployez jamais de site en production avec le réglage [`DEBUG`](#std-setting-DEBUG) activé.

Avez-vous bien lu ? Ne JAMAIS déployer un site en production avec le réglage [`DEBUG`](#std-setting-DEBUG) activé.

L’une des fonctionnalités principales du mode de débogage est l’affichage de pages d’erreur détaillées. Si votre application lève une exception quand [`DEBUG`](#std-setting-DEBUG) vaut `True`, Django affiche une trace détaillée, y compris de nombreuses métadonnées au sujet de votre environnement, comme par exemple la liste complète des réglages Django en vigueur (tirés de `settings.py`).

As a security measure, Django will *not* include settings that might be
sensitive, such as [`SECRET_KEY`](#std-setting-SECRET_KEY). Specifically, it will exclude any
setting whose name includes any of the following:

- `'API'`
- `'KEY'`
- `'PASS'`
- `'SECRET'`
- `'SIGNATURE'`
- `'TOKEN'`

Notez qu’il s’agit de correspondances *partielles*. `'PASS'` va aussi intercepter PASSWORD, comme `'TOKEN'` interceptera TOKENIZED et ainsi de suite.

Toutefois, notez qu’il y aura toujours des parties de l’affichage de débogage qui contiennent des éléments inappropriés pour le tout public. Des chemins de fichiers, des options de configuration et d’autres choses semblables peuvent tous donner à des attaquants des informations supplémentaires au sujet de votre serveur.

Il est aussi important de se rappeler que lorsque un site fonctionne en mode [`DEBUG`](#std-setting-DEBUG), Django mémorise chaque requête SQL qu’il exécute. C’est utile lors de séances de débogage, mais cela va assez rapidement consommer beaucoup de mémoire sur un serveur de production.

Enfin, si [`DEBUG`](#std-setting-DEBUG) vaut `False`, vous devez également définir correctement le réglage [`ALLOWED_HOSTS`](#std-setting-ALLOWED_HOSTS). Sans cela, toutes les requêtes renverront l’erreur « Bad Request (400) ».

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) définit `DEBUG = True` par commodité.

### `DEBUG_PROPAGATE_EXCEPTIONS`

Valeur par défaut : `False`

Si défini à `True`, la gestion normale des exceptions par Django pour les fonctions de vue sera supprimée et les exceptions vont donc se propager. Cela peut être utile pour certaines configurations de test, mais ne devrait jamais être activé sur un site en production.

### `DECIMAL_SEPARATOR`

Valeur par défaut : `'.'` (point)

Séparateur décimal par défaut utilisé lors du formatage des nombres à virgule.

Notez que lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce séparateur.

Voir aussi [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) et [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `DEFAULT_CHARSET`

Valeur par défaut : `'utf-8'`

Codage de caractères par défaut utilisé pour tous les objets `HttpResponse` si un type MIME n’est pas manuellement indiqué. Utilisé conjointement avec [`DEFAULT_CONTENT_TYPE`](#std-setting-DEFAULT_CONTENT_TYPE) pour construire l’en-tête `Content-Type`.

### `DEFAULT_CONTENT_TYPE`

Valeur par défaut : `'text/html'`

Type de contenu par défaut utilisé pour tous les objets `HttpResponse` si un type MIME n’est pas manuellement indiqué. Utilisé conjointement avec [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) pour construire l’en-tête `Content-Type`.

### `DEFAULT_EXCEPTION_REPORTER_FILTER`

Valeur par défaut : `'`[`django.views.debug.SafeExceptionReporterFilter`](/fr/1.9/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter)`'`

Classe de filtre de rapports d’exception utilisée par défaut si aucune n’a été attribuée à l’instance [`HttpRequest`](/fr/1.9/ref/request-response/#django.http.HttpRequest). Voir [Filtrage des rapports d’erreur](/fr/1.9/howto/error-reporting/#filtering-error-reports).

### `DEFAULT_FILE_STORAGE`

Valeur par défaut : `'`[`django.core.files.storage.FileSystemStorage`](/fr/1.9/ref/files/storage/#django.core.files.storage.FileSystemStorage)`'`

Classe de stockage de fichiers utilisée par défaut pour toute opération liée à des fichiers quand un système de stockage n’est pas explicitement indiqué. Voir [Gestion des fichiers](/fr/1.9/topics/files/).

### `DEFAULT_FROM_EMAIL`

Valeur par défaut : `'webmaster@localhost'`

L’adresse de courriel par défaut à utiliser pour diverses correspondance automatisées de la part des gestionnaires du site. Cela n’inclut pas les messages d’erreur envoyés à [`ADMINS`](#std-setting-ADMINS) et [`MANAGERS`](#std-setting-MANAGERS); pour cela, voir [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL).

### `DEFAULT_INDEX_TABLESPACE`

Valeur par défaut : `''` (Chaîne vide)

Espace de tables utilisé par défaut pour les index sur les champs qui n’en indiquent pas, si le moteur les prend en charge (voir [Espaces de tables](/fr/1.9/topics/db/tablespaces/)).

### `DEFAULT_TABLESPACE`

Valeur par défaut : `''` (Chaîne vide)

Espace de tables utilisé par défaut pour les modèles qui n’en indiquent pas, si le moteur les prend en charge (voir [Espaces de tables](/fr/1.9/topics/db/tablespaces/)).

### `DISALLOWED_USER_AGENTS`

Valeur par défaut : `[]` (liste vide)

Liste d’objets d’expressions régulières compilées représentant des chaînes d’agent utilisateur (User-Agent) qui ne sont globalement pas autorisés à visiter le site. Utile pour les robots ou les collecteurs malveillants. Ce réglage n’est utilisé que si `CommonMiddleware` est installé (voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/)).

### `EMAIL_BACKEND`

Valeur par défaut : `'`[`django.core.mail.backends.smtp.EmailBackend`](/fr/1.9/topics/email/#django.core.mail.backends.smtp.EmailBackend)`'`

Le moteur à utiliser pour envoyer des courriels. Consultez [Envoi de messages électroniques](/fr/1.9/topics/email/) pour obtenir la liste des moteurs disponibles.

### `EMAIL_FILE_PATH`

Valeur par défaut :  non définie

Le répertoire utilisé par le moteur de messagerie `file` pour stocker les fichiers qu’il produit.

### `EMAIL_HOST`

Valeur par défaut : `'localhost'`

L’hôte à utiliser pour envoyer des courriels.

Voir aussi [`EMAIL_PORT`](#std-setting-EMAIL_PORT).

### `EMAIL_HOST_PASSWORD`

Valeur par défaut : `''` (Chaîne vide)

Mot de passe à utiliser pour le serveur SMTP défini dans [`EMAIL_HOST`](#std-setting-EMAIL_HOST). Ce réglage est utilisé conjointement avec [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) lors de l’authentification au serveur SMTP. Si l’un de ces réglages est vide, Django ne tente pas de s’authentifier.

Voir aussi [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER).

### `EMAIL_HOST_USER`

Valeur par défaut : `''` (Chaîne vide)

Nom d’utilisateur à utiliser pour le serveur SMTP défini dans [`EMAIL_HOST`](#std-setting-EMAIL_HOST). S’il est vide, Django ne tente pas de s’authentifier.

Voir aussi [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD).

### `EMAIL_PORT`

Valeur par défaut : `25`

Port à utiliser pour le serveur SMTP défini dans [`EMAIL_HOST`](#std-setting-EMAIL_HOST).

### `EMAIL_SUBJECT_PREFIX`

Valeur par défaut : `'[Django] '`

Préfixe de la ligne du sujet dans les messages électroniques envoyés avec `django.core.mail.mail_admins` ou `django.core.mail.mail_managers`. Une espace finale est probablement adéquate.

### `EMAIL_USE_TLS`

Valeur par défaut : `False`

Indique si une connexion TLS (sécurisée) doit être utilisée pour le dialogue avec le serveur SMTP. Ceci s’applique aux connexions TLS explicites, généralement sur le port 587. Si vous obtenez des connexions qui se bloquent, consultez le réglage TLS implicite [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL).

### `EMAIL_USE_SSL`

Valeur par défaut : `False`

Indique si une connexion TLS implicite (sécurisée) doit être utilisée pour le dialogue avec le serveur SMTP. Dans la plupart de documentations de messagerie électronique, ce type de connexion TLS s’appelle SSL. C’est généralement le port 465 qui est utilisé. Si vous rencontrez des problèmes, consultez le réglage TLS explicite [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS).

Notez que setting:EMAIL\_USE\_TLS/[`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) sont mutuellement exclusifs, un seul d’entre eux peut donc être défini à `True`.

### `EMAIL_SSL_CERTFILE`

> **New in Django 1.8**

Valeur par défaut : `None`

Si [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) ou [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) valent `True`, vous pouvez définir de manière facultative le chemin vers un fichier de chaîne de certificat de type PEM à utiliser pour la connexion SSL.

### `EMAIL_SSL_KEYFILE`

> **New in Django 1.8**

Valeur par défaut : `None`

Si [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) ou [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) valent `True`, vous pouvez définir de manière facultative le chemin vers un fichier de clé privée de type PEM à utiliser pour la connexion SSL.

Notez que la définition de [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) et de [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) n’amène à aucune vérification de certificat. Ces valeurs sont transmises à la connexion SSL sous-jacente. Veuillez vous référer à la documentation de la fonction `python:ssl.wrap_socket()` de Python pour des détails sur la façon dont les fichiers de chaîne de certificat et de clé privée sont traités.

### `EMAIL_TIMEOUT`

> **New in Django 1.8**

Valeur par défaut : `None`

Définit un délai d’expiration en secondes pour des opérations bloquantes telles que la tentative de connexion.

### `FILE_CHARSET`

Valeur par défaut : `'utf-8'`

Le codage de caractères utilisé pour décoder tout fichier lu à partir du disque. Cela comprend les fichiers de gabarits et les fichiers de données SQL initiales.

### `FILE_UPLOAD_HANDLERS`

Valeur par défaut :

```
[
    'django.core.files.uploadhandler.MemoryFileUploadHandler',
    'django.core.files.uploadhandler.TemporaryFileUploadHandler',
]
```

Une liste de gestionnaires à utiliser pour le téléversement de fichiers. Ce réglage permet de personnaliser complètement (même remplacer) le processus de gestion des téléversements par Django.

Voir [Gestion des fichiers](/fr/1.9/topics/files/) pour plus de détails.

### `FILE_UPLOAD_MAX_MEMORY_SIZE`

Valeur par défaut : `2621440` (c-à-d. 2.5 Mio).

La taille maximale (en octets) d’un téléversement avant qu’il ne soit déporté sur le système de fichiers. Voir [Gestion des fichiers](/fr/1.9/topics/files/) pour plus de détails.

### `FILE_UPLOAD_DIRECTORY_PERMISSIONS`

Valeur par défaut : `None`

Le mode numérique à appliquer aux répertoires créés durant le processus de téléversement de fichiers.

Ce réglage détermine également les permissions par défaut pour les répertoires de recueil des fichiers statiques lors de l’utilisation de la commande d’administration [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic). Voir [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) pour des détails sur la façon de le redéfinir.

Cette valeur reflète la fonctionnalité et les restrictions du réglage [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS).

### `FILE_UPLOAD_PERMISSIONS`

Valeur par défaut : `None`

Le mode numérique (ex : `0o644`) des permissions pour les nouveaux fichiers téléversés. Pour plus d’informations sur la signification des ces modes, consultez la documentation de [`os.chmod()`](https://docs.python.org/3/library/os.html#os.chmod).

Si ce réglage n’est pas défini ou qu’il vaut `None`, vous obtiendrez un comportement dépendant du système d’exploitation. Sur la plupart des plates-formes, les fichiers temporaires obtiennent un mode `0o600` et les fichiers enregistrés à partir de la mémoire sont enregistrés avec le masque « umask » standard du système.

Pour des raisons de sécurité, ces permissions ne sont pas appliquées aux fichiers temporaires qui sont stockés dans [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR).

Ce réglage détermine également les permissions par défaut pour les fichiers statiques recueillis par la commande d’administration [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic). Voir [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) pour des détails sur la façon de le redéfinir.

> **Warning**
>
> **Toujours précéder le mode d’un 0.**
>
> Si vous n’êtes pas à l’aise avec les modes de fichiers, sachez que le premier `0` est très important : il indique un nombre octal, ce qui est la bonne manière d’indiquer les modes. Si vous essayez d’utiliser `644`, vous obtiendrez un comportement totalement incorrect.

### `FILE_UPLOAD_TEMP_DIR`

Valeur par défaut : `None`

Le répertoire dans lequel stocker temporairement les données (typiquement pour les fichiers plus grands que [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE)) lors des téléversements de fichiers. Avec la valeur `None`, Django utilise le répertoire temporaire standard du système d’exploitation. Par exemple, il s’agit de `/tmp` sur les systèmes d’exploitation de type Unix.

Voir [Gestion des fichiers](/fr/1.9/topics/files/) pour plus de détails.

### `FIRST_DAY_OF_WEEK`

Valeur par défaut : `0` (dimanche)

Un nombre représentant le premier jour de la semaine. C’est particulièrement utile lors de l’affichage d’un calendrier. Cette valeur n’est utilisée que si les formats internationaux ne sont pas en vigueur ou si un format n’est pas trouvé pour la langue actuelle.

La valeur est un entier de 0 à 6, où 0 signifie dimanche, 1 signifie lundi, etc.

### `FIXTURE_DIRS`

Valeur par défaut : `[]` (liste vide)

Liste de répertoires dans lesquels des fichiers de fixtures sont recherchés, en plus de répertoire `fixtures` de chaque application, dans l’ordre de recherche.

Notez que ces chemins doivent utiliser les barres obliques de style Unix, même avec Windows.

Voir [Données initiales par les instantanés](/fr/1.9/howto/initial-data/#initial-data-via-fixtures) et [Chargement des instantanés](/fr/1.9/topics/testing/tools/#topics-testing-fixtures).

### `FORCE_SCRIPT_NAME`

Valeur par défaut : `None`

Si différent de `None`, ce réglage est utilisé comme valeur de la variable d’environnement `SCRIPT_NAME` dans toute requête HTTP. Il peut être utilisé pour surcharger la valeur de `SCRIPT_NAME` fournie par le serveur, qui peut être une version réécrite de la valeur préférée ou carrément absente.

### `FORMAT_MODULE_PATH`

Valeur par défaut : `None`

Un chemin Python complet vers un paquet Python contenant des définitions de formats pour les locales du projet. Si différent de `None`, Django cherche un fichier `formats.py` dans le répertoire dont le nom correspond à la locale en cours et utilise les formats définis dans ce fichier.

Par exemple, si [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH) est défini à `mysite.formats` et que la langue actuelle est `en` (anglais), Django s’attend à une arborescence de répertoires comme celle-ci :

```
mysite/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py
```

> **Changed in Django 1.8**
>
> Vous pouvez aussi définir ce réglage à une liste de chemins Python, par exemple :
>
> ```
> FORMAT_MODULE_PATH = [
>     'mysite.formats',
>     'some_app.formats',
> ]
> ```
>
> Lorsque Django recherche un certain format, il va parcourir tous les chemins Python indiqués jusqu’à ce qu’il trouve un module qui définit réellement le format recherché. Cela signifie que les formats définis dans les premiers paquets de la liste ont la priorité sur les formats des paquets suivants.

Les formats disponibles sont [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT), [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT), [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT), [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT), [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK), [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) et [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING).

### `IGNORABLE_404_URLS`

Valeur par défaut : `[]` (liste vide)

Liste d’objets expressions régulières compilées décrivant les URL qui doivent être ignorées lors du signalement des erreurs HTTP 404 par courriel (voir [Signalement d’erreurs](/fr/1.9/howto/error-reporting/)). Les expressions régulières sont comparées aux [`chemins complets des requêtes`](/fr/1.9/ref/request-response/#django.http.HttpRequest.get_full_path) (y compris la chaîne de requête, le cas échéant). Ceci est utile si votre site ne fournit pas certains fichiers fréquemment demandés comme `favicon.ico` ou `robots.txt`, ou s’il est bombardé par des scripts malveillants.

Ce n’est utilisé que si [`BrokenLinkEmailsMiddleware`](/fr/1.9/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) est activé (voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/)).

### `INSTALLED_APPS`

Valeur par défaut : `[]` (liste vide)

Une liste de chaînes désignant toutes les applications activées dans cette installation de Django. Chaque chaîne doit correspondre à un chemin pointé Python vers :

- une classe de configuration d’application (de préférence), ou
- un paquet contenant une application.

[En savoir plus sur les configurations d’applications](/fr/1.9/ref/applications/).

> **Utilisez le registre des applications pour l’introspection**
>
> Votre code ne devrait jamais accéder directement à [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS). Utilisez plutôt [`django.apps.apps`](/fr/1.9/ref/applications/#django.apps.apps).

> **Les noms et les étiquettes d’application doivent être uniques dans INSTALLED_APPS**
>
> Les [`noms`](/fr/1.9/ref/applications/#django.apps.AppConfig.name) d’applications, le chemin pointé Python vers le paquet de l’application, doivent être uniques. Il n’existe aucune manière d’inclure deux fois la même application, sauf en dupliquant son code sous un autre nom.
>
> Les [`étiquettes`](/fr/1.9/ref/applications/#django.apps.AppConfig.label) d’application, par défaut la partie finale du nom, doivent aussi être uniques. Par exemple, il n’est pas possible d’inclure à la fois `django.contrib.auth` et `monprojet.auth`. Cependant, vous pouvez renommer l’étiquette d’une application avec une configuration personnalisée définissant un attribut [`label`](/fr/1.9/ref/applications/#django.apps.AppConfig.label) différent.
>
> Ces règles s’appliquent dans tous les cas, quelle que soit la cible des références dans [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS), des classes de configuration d’application ou des paquets d’application.

Lorsque plusieurs applications fournissent différentes versions de la même ressource (gabarit, fichier statique, commande d’administration, traduction), l’application apparaissant en premier dans [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) a la priorité.

### `INTERNAL_IPS`

Valeur par défaut : `[]` (liste vide)

Une liste d’adresses IP, sous forme de chaînes, dont les requêtes :

- Permettent au processeur de contexte [`debug()`](/fr/1.9/ref/templates/api/#django.template.context_processors.debug) d’ajouter quelques variables au contexte du gabarit.
- Peuvent utiliser les [signets dynamiques de admindocs](/fr/1.9/ref/contrib/admin/admindocs/#admindocs-bookmarklets) même si l’utilisateur n’est pas connecté en tant qu’administrateur (staff).
- Sont marquées comme « internes » (et non pas « EXTERNAL ») dans les courriels envoyés par [`AdminEmailHandler`](/fr/1.9/topics/logging/#django.utils.log.AdminEmailHandler).

### `LANGUAGE_CODE`

Valeur par défaut : `'en-us'`

Une chaîne représentant le code de langue de cette installation. Elle doit respecter le [format de langue](/fr/1.9/topics/i18n/#term-language-code) standard. Par exemple, l’anglais américain est `"en-us"`. Voir aussi la [liste des identifiants de langue](http://www.i18nguy.com/unicode/language-identifiers.html) et [Internationalisation et régionalisation](/fr/1.9/topics/i18n/).

[`USE_I18N`](#std-setting-USE_I18N) doit être activé pour que ce réglage ait un effet.

Ce réglage sert à deux fins :

- Si l’intergiciel de localisation n’est pas actif, il décide quelle traduction est utilisée pour tous les utilisateurs.
- Si l’intergiciel de localisation est actif, il fournit une langue par défaut dans le cas où la langue préférée de l’utilisateur ne peut être déterminée ou n’est pas prise en charge par le site Web. Il fournit également la traduction par défaut lorsqu’une traduction d’une chaîne donnée n’existe pas dans la langue préférée de l’utilisateur.

> **Changed in Django 1.8**
>
> La traduction par défaut au niveau des chaînes a été ajoutée.

Voir [Processus de découverte de la préférence de langue par Django](/fr/1.9/topics/i18n/translation/#how-django-discovers-language-preference) pour plus de détails.

### `LANGUAGE_COOKIE_AGE`

Valeur par défaut : `None` (expiration à la fermeture du navigateur)

L’âge du cookie de langue, en secondes.

### `LANGUAGE_COOKIE_DOMAIN`

Valeur par défaut : `None`

Le domaine à utiliser pour le cookie de langue. Définissez ce réglage à une chaîne, comme `".example.com"` (relevez le point initial) pour un cookie inter-domaine, ou utilisez `None` pour un cookie de domaine standard.

Soyez prudent lors de la mise à jour de ce réglage sur un site de production. Si vous mettez à jour ce paramètre pour activer les cookies inter-domaines sur un site qui utilisait précédemment les cookies de domaine standards, les cookies existants des utilisateurs qui contiennent l’ancien domaine ne seront pas mis à jour. Il en résultera qu’ils seront incapables de changer de langue aussi longtemps que ces cookies persistent. La seule façon sûre et fiable d’effectuer ce changement est de modifier de manière permanente le cookie de langue (via le réglage [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME)) et d’ajouter un intergiciel qui copie la valeur de l’ancien cookie vers le nouveau, puis supprime l’ancien.

### `LANGUAGE_COOKIE_NAME`

Valeur par défaut : `'django_language'`

Le nom à utiliser pour le cookie de langue. Vous pouvez mettre ce que vous voulez (tant que c’est un nom de cookie différent de ceux qui existent déjà). Voir [Internationalisation et régionalisation](/fr/1.9/topics/i18n/).

### `LANGUAGE_COOKIE_PATH`

Valeur par défaut : `'/'`

Le chemin défini dans le cookie de langue. Cela devrait correspondre au chemin d’URL de votre installation Django ou être un parent de ce chemin.

C’est utile lorsque vous avez plusieurs instances Django fonctionnant sous le même nom d’hôte. Elles peuvent alors utiliser des chemins de cookie différents et chaque instance ne verra que ses propres cookies de langue.

Soyez prudent lors de la mise à jour de ce réglage sur un site de production. Si vous mettez à jour ce réglage afin d’utiliser un chemin plus profond que précédemment, les cookies existants des utilisateurs qui contiennent l’ancien chemin ne seront pas mis à jour. Il en résultera qu’ils seront incapables de changer de langue aussi longtemps que ces cookies persistent. La seule façon sûre et fiable d’effectuer ce changement est de modifier de manière permanente le cookie de langue (via le réglage [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME)) et d’ajouter un intergiciel qui copie la valeur de l’ancien cookie vers le nouveau, puis supprime l’ancien.

### `LANGUAGES`

Valeur par défaut : une liste des langues disponibles. Cette liste augmentant continuellement, nous évitons de la reproduire ici, car elle deviendrait vite obsolète. Vous pouvez consultez la liste des langues disposant d’une traduction en examinant le fichier `django/conf/global_settings.py` (ou en consultant la [source en ligne](https://github.com/django/django/blob/master/django/conf/global_settings.py)).

La liste est formée de listes binaires dans le format ([code de langue](/fr/1.9/topics/i18n/#term-language-code), `nom_de_langue`), par exemple `('ja', 'Japanese')`. Cette liste définit les langues disponibles dans la sélection de langues. Voir [Internationalisation et régionalisation](/fr/1.9/topics/i18n/).

Généralement, la valeur par défaut convient bien. Ne définissez ce réglage que si vous souhaitez restreindre la sélection de langues à un sous-ensemble des langues fournies par Django.

Si vous personnalisez le réglage [`LANGUAGES`](#std-setting-LANGUAGES), vous pouvez marquer les noms des langues en tant que chaînes à traduire en utilisant la fonction [`ugettext_lazy()`](/fr/1.9/ref/utils/#django.utils.translation.ugettext_lazy).

Voici un exemple de fichier de réglages :

```
from django.utils.translation import ugettext_lazy as _

LANGUAGES = [
    ('de', _('German')),
    ('en', _('English')),
]
```

### `LOCALE_PATHS`

Valeur par défaut : `[]` (liste vide)

Une liste de répertoires dans lesquels Django cherche les fichiers de traduction. Voir [Processus de découverte des traductions par Django](/fr/1.9/topics/i18n/translation/#how-django-discovers-translations).

Exemple :

```
LOCALE_PATHS = [
    '/home/www/project/common_files/locale',
    '/var/local/translations/locale',
]
```

Django cherche dans chacun de ces chemins des répertoires `<code_locale>/LC_MESSAGES` contenant eux-mêmes les fichiers de traduction réels.

### `LOGGING`

Valeur par défaut : un dictionnaire de configuration de la journalisation.

Une structure de données contenant les informations de configuration. Le contenu de cette structure de données est transmis comme paramètre à la méthode de configuration indiquée par [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG).

Entre autres choses, la configuration par défaut de la journalisation transmet les erreurs de serveur HTTP 500 à un gestionnaire de journal de type courriel lorsque [`DEBUG`](#std-setting-DEBUG) vaut `False`. Voir aussi [Configuration de la journalisation](/fr/1.9/topics/logging/#configuring-logging).

Vous pouvez voir la configuration par défaut de journalisation en regardant dans `django/utils/log.py` (ou en affichant le [code source en ligne](https://github.com/django/django/blob/master/django/utils/log.py)).

### `LOGGING_CONFIG`

Valeur par défaut : `'logging.config.dictConfig'`

A path to a callable that will be used to configure logging in the
Django project. Points at a instance of Python’s [dictConfig](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) configuration method by default.

Si vous définissez [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) à `None`, le processus de configuration de la journalisation sera court-circuité.

### `MANAGERS`

Valeur par défaut : `[]` (liste vide)

Une liste dans le même format que [`ADMINS`](#std-setting-ADMINS) qui détermine qui doit recevoir les notifications de liens brisés lorsque [`BrokenLinkEmailsMiddleware`](/fr/1.9/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) est activé.

### `MEDIA_ROOT`

Valeur par défaut : `''` (Chaîne vide)

Chemin absolu de système de fichiers pointant vers le répertoire qui contiendra les [fichiers téléversés par les utilisateurs](/fr/1.9/topics/files/).

Exemple : `"/var/www/example.com/media/"`

Voir aussi [`MEDIA_URL`](#std-setting-MEDIA_URL).

> **Warning**
>
> [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) et [`STATIC_ROOT`](#std-setting-STATIC_ROOT) doivent avoir des valeurs différentes. Avant que [`STATIC_ROOT`](#std-setting-STATIC_ROOT) soit introduit, il était fréquent de compter ou de se replier sur [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) pour servir également les fichiers statiques ; cependant, comme cela peut avoir des conséquences graves pour la sécurité, il y a un contrôle de validation pour l’empêcher.

### `MEDIA_URL`

Valeur par défaut : `''` (Chaîne vide)

URL qui gère les fichiers médias servis à partir de [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT), utilisée pour la [gestion des fichiers stockés](/fr/1.9/topics/files/). Elle doit se terminer par une barre oblique si elle ne contient pas de valeur vide. Il sera nécessaire de [configurer ces fichiers afin d’être servis](/fr/1.9/howto/static-files/#serving-uploaded-files-in-development) aussi bien en environnement de développement que de production.

Si vous souhaitez utiliser `{{ MEDIA_URL }}` dans vos gabarits, ajoutez `'django.template.context_processors.media'` dans l’option `'context_processors'` de [`TEMPLATES`](#std-setting-TEMPLATES).

Exemple : `"http://media.example.com/"`

> **Warning**
>
> Il existe des risques de sécurité si vous acceptez du contenu téléversé de la part d’utilisateurs non fiables. Consultez le sujet [Contenu envoyé par les utilisateurs](/fr/1.9/topics/security/#user-uploaded-content-security) du guide de sécurité pour des détails sur les mesures de réduction des risques.

> **Warning**
>
> [`MEDIA_URL`](#std-setting-MEDIA_URL) et [`STATIC_URL`](#std-setting-STATIC_URL) doivent avoir des valeurs différentes. Voir [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) pour plus de détails.

### `MIDDLEWARE_CLASSES`

Valeur par défaut :

```
[
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
]
```

Une liste de classes de middleware à utiliser. Voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/).

### `MIGRATION_MODULES`

Valeur par défaut : `{}` (dictionnaire vide)

Un dictionnaire indiquant le paquet où les modules de migration peuvent être trouvés pour chaque application. La valeur par défaut de ce réglage est un dictionnaire vide, mais le nom de paquet par défaut pour les modules de migration est `migrations`.

Exemple :

```
{'blog': 'blog.db_migrations'}
```

Dans ce cas, les migrations concernant l’application `blog` seront contenues dans le paquet `blog.db_migrations`.

Si vous fournissez le paramètre `app_label`, [`makemigrations`](/fr/1.9/ref/django-admin/#django-admin-makemigrations) crée automatiquement le paquet s’il n’existe pas déjà.

> **New in Django 1.9**

Lorsque vous fournissez `None` comme valeur pour une application, Django considère l’application comme sans migrations, sans prendre en compte un éventuel sous-module `migrations` existant. Ceci peut être utilisé, par exemple, dans un fichier de règlages de test pour sauter les migrations durant les tests (les tables seront quand même créées pour les modèles des applications). Si cela est utilisé dans les réglages généraux du projet, pensez à utiliser l’option [`migrate --run-syncdb`](/fr/1.9/ref/django-admin/#cmdoption-migrate-run-syncdb) si vous souhaitez créer les tables de l’application.

### `MONTH_DAY_FORMAT`

Valeur par défaut : `'F j'`

Le format par défaut à utiliser pour les champs date dans les listes pour modifications des pages de l’administration de Django, et potentiellement dans d’autres parties du système, dans les cas où seuls le mois et le jour sont affichés.

Par exemple, lorsqu’une page de liste pour modification de l’administration de Django est filtrée par un choix de date, l’en-tête d’un jour donné affiche le jour et le mois. Différentes locales présentent différents formats. Par exemple, l’anglais américain affichera « January 1, » alors que l’espagnol affichera « 1 Enero. ».

Notez que lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale qui correspond a une priorité plus élevée et remplace ce séparateur.

Voir [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date). Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) et [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT).

### `NUMBER_GROUPING`

Valeur par défaut : `0`

Nombre de chiffres groupés dans la partie entière d’un nombre.

L’utilisation habituelle est d’afficher un séparateur de milliers. Si ce réglage est à `0`, aucun groupement n’est effectué. S’il est plus grand que `0`, [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) est utilisé comme séparateur entre ces groupes.

Notez que lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce séparateur.

Voir aussi [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) et [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `PREPEND_WWW`

Valeur par défaut : `False`

Indique s’il faut préfixer le sous-domaine « www. » aux URL qui ne l’ont pas. Utilisé seulement si [`CommonMiddleware`](/fr/1.9/ref/middleware/#django.middleware.common.CommonMiddleware) est installé (voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/)). Voir aussi [`APPEND_SLASH`](#std-setting-APPEND_SLASH).

### `ROOT_URLCONF`

Valeur par défaut :  non définie

Une chaîne représentant le chemin d’importation Python complet vers votre URLconf racine. Par exemple : `"mesapplisdjango.urls"`. Il peut être surchargé pour chaque requête en définissant l’attribut `urlconf` de l’objet `HttpRequest` entrant. Voir [Processus de traitement des requêtes par Django](/fr/1.9/topics/http/urls/#how-django-processes-a-request) pour plus de détails.

### `SECRET_KEY`

Valeur par défaut : `''` (Chaîne vide)

La clé secrète d’une installation Django. Elle est utilisée dans le contexte de la [signature cryptographique](/fr/1.9/topics/signing/), et doit être définie à une valeur unique et non prédictible.

[`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) ajoute automatiquement une valeur `SECRET_KEY` générée aléatoirement dans chaque nouveau projet.

Django refuse de démarrer si [`SECRET_KEY`](#std-setting-SECRET_KEY) n’est pas défini.

> **Warning**
>
> **Gardez cette valeur secrète.**
>
> Le fonctionnement de Django avec une clé [`SECRET_KEY`](#std-setting-SECRET_KEY) connue réduit à néant de nombreuses protections de sécurité de Django et peut amener à une élévation de privilèges et à des vulnérabilités d’exécution de code à distance.

La clé secrète est utilisée pour :

- Toutes les [sessions](/fr/1.9/topics/http/sessions/) si vous utilisez un autre moteur de sessions que `django.contrib.sessions.backends.cache` ou que vous utilisez [`SessionAuthenticationMiddleware`](/fr/1.9/ref/middleware/#django.contrib.auth.middleware.SessionAuthenticationMiddleware) ainsi que la méthode [`get_session_auth_hash()`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) par défaut.
- Tous les [messages](/fr/1.9/ref/contrib/messages/) si vous utilisez les moteurs de stockage [`CookieStorage`](/fr/1.9/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) ou [`FallbackStorage`](/fr/1.9/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage).
- Tous les jetons de [`password_reset()`](/fr/1.9/topics/auth/default/#django.contrib.auth.views.password_reset).
- Tout emploi de la [signature cryptographique](/fr/1.9/topics/signing/), sauf si une clé différente est fournie.

Lorsque la clé secrète est modifiée, tous les éléments ci-dessus sont invalidés. Les clés secrètes ne sont pas utilisées pour les mots de passe des utilisateurs ; ceux-ci ne sont pas touchés par un changement de clé.

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) crée une clé `SECRET_KEY` unique par commodité.

### `SECURE_BROWSER_XSS_FILTER`

> **New in Django 1.8**

Valeur par défaut : `False`

Si `True`, l’intergiciel [`SecurityMiddleware`](/fr/1.9/ref/middleware/#django.middleware.security.SecurityMiddleware) définit l’en-tête [X-XSS-Protection: 1; mode=block](/fr/1.9/ref/middleware/#x-xss-protection) pour toutes les réponses qui ne l’ont pas déjà.

### `SECURE_CONTENT_TYPE_NOSNIFF`

> **New in Django 1.8**

Valeur par défaut : `False`

Si `True`, l’intergiciel [`SecurityMiddleware`](/fr/1.9/ref/middleware/#django.middleware.security.SecurityMiddleware) définit l’en-tête [X-Content-Type-Options: nosniff](/fr/1.9/ref/middleware/#x-content-type-options) pour toutes les réponses qui ne l’ont pas déjà.

### `SECURE_HSTS_INCLUDE_SUBDOMAINS`

> **New in Django 1.8**

Valeur par défaut : `False`

Si `True`, l’intergiciel [`SecurityMiddleware`](/fr/1.9/ref/middleware/#django.middleware.security.SecurityMiddleware) ajoute la balise `includeSubDomains` à l’en-tête [Sécurité de transport HTTP stricte (HSTS)](/fr/1.9/ref/middleware/#http-strict-transport-security). Il n’a pas d’effet tant que [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) ne contient pas une valeur différente de zéro.

> **Warning**
>
> Une définition incorrecte de ce paramètre peut casser votre site de manière irréversible (pour la durée de [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS)). Lisez d’abord la documentation [Sécurité de transport HTTP stricte (HSTS)](/fr/1.9/ref/middleware/#http-strict-transport-security).

### `SECURE_HSTS_SECONDS`

> **New in Django 1.8**

Valeur par défaut : `0`

Si défini à un nombre entier autre que 0, l’intergiciel [`SecurityMiddleware`](/fr/1.9/ref/middleware/#django.middleware.security.SecurityMiddleware) définit l’en-tête [Sécurité de transport HTTP stricte (HSTS)](/fr/1.9/ref/middleware/#http-strict-transport-security) pour toutes les réponses qui ne l’ont pas déjà.

> **Warning**
>
> Une définition incorrecte de ce paramètre peut casser votre site de manière irréversible (pour un certain temps). Lisez d’abord la documentation [Sécurité de transport HTTP stricte (HSTS)](/fr/1.9/ref/middleware/#http-strict-transport-security).

### `SECURE_PROXY_SSL_HEADER`

Valeur par défaut : `None`

Un tuple représentant une combinaison en-tête/valeur HTTP signifiant qu’une requête est sécurisée. Ce réglage contrôle le comportement de la méthode `is_secure()` de l’objet requête.

Cela demande quelques explications. Par défaut, `is_secure()` est capable de déterminer si une requête est sécurisée en inspectant le protocole de l’URL demandée (« <https://> »). C’est important pour la protection CSRF de Django et peut être utilisé par votre propre code ou des applications tierces.

Si votre application Django est derrière un serveur mandataire (proxy), celui-ci peut masquer le fait que la requête est en HTTPS en utilisant une connexion non HTTPS entre le serveur mandataire et Django. Dans ce cas, `is_secure()` renvoie toujours `False`, même pour les requêtes qui ont été initiées en HTTPS par l’utilisateur final.

Dans cette situation, il est alors possible de configurer le serveur mandataire pour qu’il définisse un en-tête HTTP indiquant à Django si la requête est arrivée en HTTPS ; le réglage `SECURE_PROXY_SSL_HEADER` permet de signaler à Django le nom de l’en-tête où il doit chercher cette information.

Il est nécessaire de définir un tuple contenant deux éléments : le nom de l’en-tête à examiner et la valeur requise. Par exemple :

```
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
```

Ici, nous disons à Django que nous nous fions à l’en-tête `X-Forwarded-Proto` ajouté par le serveur mandataire et indiquant par une valeur `'https'` que la requête provenait bien d’une connexion sécurisée (c’est-à-dire qu’elle est arrivée par HTTPS). Évidemment, ce réglage ne doit être défini qu’à la condition que vous soyez maître du serveur mandataire ou que vous ayez la garantie que l’en-tête soit ajouté ou enlevé de manière appropriée.

Notez que le nom de l’en-tête doit être dans le format utilisé par `request.META`, tout en majuscules et commençant probablement par `HTTP_` (souvenez-vous que Django ajoute automatiquement `'HTTP_'` au début des noms d’en-têtes X avant de les rendre accessibles dans `request.META`).

> **Warning**
>
> **Vous créerez probablement des trous de sécurité dans votre site si vous définissez ce réglage sans savoir ce que vous faites. Et si vous n’arrivez pas à le définir quand vous devriez. Sérieusement.**
>
> Assurez-vous que TOUS les points ci-après sont vrais avant de définir ce réglage (en prenant comme exemple les valeurs ci-dessus) :
>
> - Votre application Django est derrière un serveur mandataire.
> - Le serveur mandataire ôte les en-têtes `X-Forwarded-Proto` de toute requête entrante. En d’autres termes, si des utilisateurs ajoutent cet en-tête dans leurs requêtes, le serveur mandataire n’en tient aucun compte.
> - Le serveur mandataire définit l’en-tête `X-Forwarded-Proto` et le transmet à Django, mais seulement pour les requêtes arrivées par HTTPS.
>
> Si l’un de ces points n’est pas réalisé, il vaut mieux laisser ce réglage à `None` et trouver une autre façon de déterminer la provenance HTTPS, peut-être au moyen d’un middleware personnalisé.

### `SECURE_REDIRECT_EXEMPT`

> **New in Django 1.8**

Valeur par défaut : `[]` (liste vide)

Si un chemin d’URL correspond à une expression régulière de cette liste, la requête ne sera pas redirigée vers HTTPS. Si [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) vaut `False`, ce réglage n’a pas d’effet.

### `SECURE_SSL_HOST`

> **New in Django 1.8**

Valeur par défaut : `None`

Si défini à une chaîne (par ex. `secure.example.com`), toutes les redirections SSL seront redirigées vers cet hôte au lieu de l’hôte d’origine (par ex. `www.example.com`). Si [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) vaut `False`, ce réglage n’as pas d’effet.

### `SECURE_SSL_REDIRECT`

> **New in Django 1.8**

Valeur par défaut : `False`

Si `True`, [`SecurityMiddleware`](/fr/1.9/ref/middleware/#django.middleware.security.SecurityMiddleware) [redirige](/fr/1.9/ref/middleware/#ssl-redirect) toutes les requêtes non HTTPS vers HTTPS (sauf pour les URL correspondant à une expression régulière figurant dans [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT)).

> **Note**
>
> Si en définissant ce réglage à `True` vous obtenez des redirections infinies, cela signifie probablement que votre site fonctionne derrière un serveur mandataire (proxy) et ne peut pas savoir quelles requêtes sont sécurisées et celles qui ne le sont pas. Il est probable que le serveur mandataire définisse un en-tête pour indiquer les requêtes sécurisées ; vous pouvez alors corriger le problème en cherchant cet en-tête et en ajoutant son nom dans le réglage [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER).

### `SERIALIZATION_MODULES`

Valeur par défaut :  non définie

Un dictionnaire de modules contenant des définitions de sérialiseurs (sous forme de chaînes) dont les clés sont des identifiants textuels pour le type de sérialisation correspondant. Par exemple, pour définir un sérialiseur YAML :

```
SERIALIZATION_MODULES = {'yaml': 'path.to.yaml_serializer'}
```

### `SERVER_EMAIL`

Valeur par défaut : `'root@localhost'`

L’adresse électronique utilisée comme expéditeur des messages d’erreur, comme ceux envoyés aux [`ADMINS`](#std-setting-ADMINS) et aux [`MANAGERS`](#std-setting-MANAGERS).

> **Pourquoi mes courriels sont-ils envoyés à partir d’une autre adresse ?**
>
> Cette adresse est uniquement utilisée pour les messages d’erreur. Il ne s’agit *pas* de l’adresse utilisée par [`send_mail()`](/fr/1.9/topics/email/#django.core.mail.send_mail) pour l’envoi de courriers électroniques habituels ; pour cela, voir [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL).

### `SHORT_DATE_FORMAT`

Valeur par défaut : `'m/d/Y'` (ex . : `12/31/2003`)

Un format disponible pour l’affichage des champs dates dans les gabarits. Notez que si [`USE_L10N`](#std-setting-USE_L10N) est défini à `True`, le format piloté par la locale a une priorité plus élevée et remplacera ce format. Voir les [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date).

Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT) et [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT).

### `SHORT_DATETIME_FORMAT`

Valeur par défaut : `'m/d/Y P'` (ex . : `12/31/2003 4 p.m.`)

Un format disponible pour l’affichage des champs dates/heures dans les gabarits. Notez que si [`USE_L10N`](#std-setting-USE_L10N) est défini à `True`, le format piloté par la locale a une priorité plus élevée et remplacera ce format. Voir les [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date).

Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT) et [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT).

### `SIGNING_BACKEND`

Valeur par défaut : `'django.core.signing.TimestampSigner'`

Le moteur utilisé pour signer les cookies et d’autres données.

Voir aussi la documentation sur [Signatures cryptographiques](/fr/1.9/topics/signing/).

### `SILENCED_SYSTEM_CHECKS`

Valeur par défaut : `[]` (liste vide)

Une liste d’identifiants de messages générés par l’infrastructure de contrôle système (par ex: `["models.W001"]`) que vous souhaitez ignorer de manière permanente. Les contrôles ainsi masqués n’apparaissent plus dans la console.

> **Changed in Django 1.9**
>
> Dans les anciennes version, les messages masqués de niveau `ERROR` ou plus élevé étaient affichés dans la console.

Voir aussi la documentation [Infrastructure de contrôle système](/fr/1.9/ref/checks/).

### `TEMPLATES`

> **New in Django 1.8**

Valeur par défaut : `[]` (liste vide)

Une liste contenant les réglages de tous les moteurs de gabarit à utiliser avec Django. Chaque élément de la liste est un dictionnaire contenant les options de chacun des moteurs.

Voici une configuration simple qui indique au moteur de gabarit de Django de charger les gabarits à partir du sous-répertoire `templates` de chaque application installée :

```
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'APP_DIRS': True,
    },
]
```

Les options suivantes sont disponibles pour tous les moteurs.

#### `BACKEND`

Valeur par défaut :  non définie

Le moteur de gabarit à utiliser. Les moteurs de gabarit intégrés à Django sont :

- `'django.template.backends.django.DjangoTemplates'`
- `'django.template.backends.jinja2.Jinja2'`

Vous pouvez utiliser un moteur de gabarit non livré avec Django en définissant `BACKEND` à un chemin complètement qualifié (par ex. `monpaquet.moteurs.Backend`).

#### `NAME`

Valeur par défaut :: voir ci-dessous

L’alias de ce moteur de gabarit particulier. Il s’agit d’un identifiant qui permet de choisir un moteur pour le processus de rendu. Les alias doivent être uniques parmi tous les moteurs de gabarit configurés.

Sa valeur par défaut contient le nom du module définissant la classe du moteur, c’est-à-dire l’avant-dernier élément de [`BACKEND`](#std-setting-TEMPLATES-BACKEND), lorsque celui-ci est présent. Par exemple, si le moteur est `'mypackage.whatever.Backend'`, le nom par défaut vaut `'whatever'`.

#### `DIRS`

Valeur par défaut : `[]` (liste vide)

Répertoires dans lesquels le moteur recherche des fichiers sources de gabarits, dans l’ordre de leur recherche.

#### `APP_DIRS`

Valeur par défaut : `False`

Indique si le moteur recherche des fichiers sources de gabarits dans les applications installées.

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) définit `'APP_DIRS': True`.

#### `OPTIONS`

Valeur par défaut : `{}` (dictionnaire vide)

Paramètres supplémentaires à passer au moteur de gabarit. Les paramètres disponibles varient en fonction du moteur. Voir [`DjangoTemplates`](/fr/1.9/topics/templates/#django.template.backends.django.DjangoTemplates) et [`Jinja2`](/fr/1.9/topics/templates/#django.template.backends.jinja2.Jinja2) pour les options des moteurs intégrés.

### TEMPLATE\_CONTEXT\_PROCESSORS

Valeur par défaut :

```
["django.contrib.auth.context_processors.auth",
"django.template.context_processors.debug",
"django.template.context_processors.i18n",
"django.template.context_processors.media",
"django.template.context_processors.static",
"django.template.context_processors.tz",
"django.contrib.messages.context_processors.messages"]
```

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Définissez plutôt l’option `'context_processors'` dans le réglage [`OPTIONS`](#std-setting-TEMPLATES-OPTIONS) du moteur de gabarit.

Une liste d’exécutables utilisés pour remplir le contexte de `RequestContext`. Ces exécutables acceptent un objet requête comme paramètre et renvoient un dictionnaire d’éléments à fusionner dans le contexte.

> **Changed in Django 1.8**
>
> Les processeurs de contexte de gabarit intégrés ont été déplacés de `django.core.context_processors` vers `django.template.context_processors` dans Django 1.8.

### TEMPLATE\_DEBUG

Valeur par défaut : `False`

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Définissez plutôt l’option `'debug'` dans le réglage [`OPTIONS`](#std-setting-TEMPLATES-OPTIONS) du moteur de gabarit.

Une valeur booléenne qui active ou désactive le mode débogage des gabarits. Quand elle vaut `True`, une page d’erreur élaborée affiche un rapport détaillé lors de toute exception générée durant le rendu des gabarits. Ce rapport contient les extraits concernés du gabarit avec les bonnes lignes mises en évidence.

Notez que Django n’affiche ces pages d’erreur élaborées que quand [`DEBUG`](#std-setting-DEBUG) vaut également `True`, il faut donc aussi veiller à définir ce réglage pour profiter de ce mode de débogage.

Voir aussi [`DEBUG`](#std-setting-DEBUG).

### TEMPLATE\_DIRS

Valeur par défaut : `[]` (liste vide)

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Définissez plutôt l’option [`DIRS`](#std-setting-TEMPLATES-DIRS) du moteur de gabarit `DjangoTemplates`.

Liste d’emplacements dans lesquels [`django.template.loaders.filesystem.Loader`](/fr/1.9/ref/templates/api/#django.template.loaders.filesystem.Loader) recherche les fichiers sources des gabarits, dans l’ordre de recherche.

Notez que ces chemins doivent utiliser les barres obliques de style Unix, même avec Windows.

Voir [Le langage de gabarit de Django](/fr/1.9/ref/templates/language/).

### TEMPLATE\_LOADERS

Valeur par défaut :

```
['django.template.loaders.filesystem.Loader',
 'django.template.loaders.app_directories.Loader']
```

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Définissez plutôt l’option `'loaders'` dans le réglage [`OPTIONS`](#std-setting-TEMPLATES-OPTIONS) du moteur de gabarit.

Une liste de classes de chargeurs de gabarits, sous forme de chaînes. Chaque classe `Loader` sait comment importer les gabarits d’une source particulière. Il est possible d’indiquer des tuples au lieu de chaînes. Le premier élément du tuple correspond au module `Loader` alors que les éléments suivants seront transmis à la classe `Loader` en vue de son initialisation. Voir [Le langage de gabarit de Django : pour les programmeurs Python](/fr/1.9/ref/templates/api/).

### TEMPLATE\_STRING\_IF\_INVALID

Valeur par défaut : `''` (Chaîne vide)

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Définissez plutôt l’option `'string_if_invalid'` dans le réglage [`OPTIONS`](#std-setting-TEMPLATES-OPTIONS) du moteur de gabarit.

Chaîne de caractères que le système des gabarits utilise pour remplacer le contenu de variables non valides (par ex. mal orthographiées). Voir [Traitement des variables non valides](/fr/1.9/ref/templates/api/#invalid-template-variables).

### `TEST_RUNNER`

Par défaut : `django.test.runner.DiscoverRunner`

Le nom de la classe à utiliser pour lancer la suite de tests. Voir [Utilisation d’autres infrastructures de test](/fr/1.9/topics/testing/advanced/#other-testing-frameworks).

### `TEST_NON_SERIALIZED_APPS`

Valeur par défaut : `[]` (liste vide)

Afin de pouvoir restaurer l’état de la base de données entre les tests pour les classes `TransactionTestCase` et les moteurs de base de données non transactionnels, Django ref:sérialise le contenu de toutes les applications \<test-case-serialized-rollback\> lorsqu’il lance la suite de tests pour pouvoir ensuite recharger ces données copiées avant de lancer les tests qui ont en besoin.

Cela ralentit le démarrage du lanceur de tests ; si vous savez que certaines applications n’ont pas besoin de cette fonctionnalité, vous pouvez ajouter leur nom complet dans ce réglage (par ex. `'django.contrib.contenttypes'`) pour les exclure du processus de sérialisation.

### `THOUSAND_SEPARATOR`

Valeur par défaut : `','` (virgule)

Séparateur de milliers utilisé par défaut lors de la mise en forme de nombres. Ce réglage n’est utilisé que lorsque [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) vaut `True` et que [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) est plus grand que `0`.

Notez que lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce séparateur.

Voir aussi [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) et [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `TIME_FORMAT`

Valeur par défaut : ```'P'` (ex . : ``4 p.m.```)

Le format par défaut pour l’affichage des champs heures dans les différentes parties du système. Notez que si [`USE_L10N`](#std-setting-USE_L10N) est défini à `True`, le format piloté par la locale a une priorité plus élevée et remplacera ce format. Voir les [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date).

Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT) et [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT).

### `TIME_INPUT_FORMATS`

Valeur par défaut :

```
[
    '%H:%M:%S',     # '14:30:59'
    '%H:%M:%S.%f',  # '14:30:59.000200'
    '%H:%M',        # '14:30'
]
```

A list of formats that will be accepted when inputting data on a time field.
Formats will be tried in order, using the first valid one. Note that these
format strings use Python’s [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date)
template filter.

Lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale a une priorité plus élevée et remplace ce format.

Voir aussi [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) et [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS).

### `TIME_ZONE`

Valeur par défaut : `'America/Chicago'`

Une chaîne représentant le fuseau horaire pour cette installation, ou `None`. Voir la [liste des fuseaux horaires](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

> **Note**
>
> Comme Django a été initialement publié avec le réglage [`TIME_ZONE`](#std-setting-TIME_ZONE) contenant `'America/Chicago'`, le réglage global (utilisé si aucun n’est défini dans le `settings.py` du projet) reste `'America/Chicago'` pour garantir la rétrocompatibilité. Les nouveaux gabarits de projet par défaut utilisent `'UTC'`.

Notez que cela ne correspond pas forcément au fuseau horaire du serveur. Par exemple, il est imaginable qu’un site serve plusieurs instances de sites Django, chacun ayant leur propre réglage de fuseau horaire.

Lorsque [`USE_TZ`](#std-setting-USE_TZ) est défini à `False`, ce réglage définit le fuseau horaire avec lequel Django stocke tous les objets dates/heures. Lorsque [`USE_TZ`](#std-setting-USE_TZ) est défini à `True`, il s’agit alors du fuseau horaire que Django utilise par défaut pour afficher les dates/heures dans les gabarits et pour interpréter les valeurs dates/heures saisies dans les formulaires.

Django définit la variable `os.environ['TZ']` au fuseau horaire défini dans le réglage [`TIME_ZONE`](#std-setting-TIME_ZONE). Ainsi, toutes les vues et tous les modèles opèrent automatiquement dans ce fuseau horaire. Cependant, Django ne définit pas la variable d’environnement `TZ` dans les conditions suivantes :

- si vous utilisez l’option de configuration manuelle telle que décrite dans [configuration manuelle des réglages](/fr/1.9/topics/settings/#settings-without-django-settings-module), ou
- si vous indiquez `TIME_ZONE = None`. Django se synchronise alors sur le fuseau horaire du système. Toutefois, nous décourageons ce cas de figure lorsque [`USE_TZ = True`](#std-setting-USE_TZ), parce qu’il fragilise les conversions entre le temps local et le temps UTC.

Quand Django ne définit pas la variable d’environnement `TZ`, il est de votre responsabilité de contrôler que les processus fonctionnent dans un environnement correct.

> **Note**
>
> Django ne peut pas utiliser de fuseaux horaires différents du système de façon fiable dans un environnement Windows. Si vous faites fonctionner Django avec Windows, [`TIME_ZONE`](#std-setting-TIME_ZONE) doit être réglé sur le même fuseau horaire que le système.

### `USE_ETAGS`

Valeur par défaut : `False`

Une valeur booléenne indiquant si l’en-tête « Etag » doit être généré. Cela économise de la bande passante mais dégrade les performances. Utilisé par `CommonMiddleware` (voir [Intergiciels (« Middleware »)](/fr/1.9/topics/http/middleware/)) et dans le système de cache (voir [L’infrastructure de cache dans Django](/fr/1.9/topics/cache/)).

### `USE_I18N`

Valeur par défaut : `True`

Une valeur booléenne indiquant si le système de traduction de Django doit être activé. C’est un moyen rapide de le désactiver pour gagner un peu de performances. Si défini à `False`, Django optimise son fonctionnement pour ne pas charger le mécanisme de traduction.

Voir aussi [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE), [`USE_L10N`](#std-setting-USE_L10N) et [`USE_TZ`](#std-setting-USE_TZ).

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) définit `USE_I18N = True` par commodité.

### `USE_L10N`

Valeur par défaut : `False`

Une valeur booléenne indiquant si la régionalisation du format des données est activée. Si défini à `True`, Django affiche par exemple les nombres et les dates en utilisant la mise en forme correspondant à la locale active.

Voir aussi [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE), [`USE_I18N`](#std-setting-USE_I18N) et [`USE_TZ`](#std-setting-USE_TZ).

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) définit `USE_L10N = True` par commodité.

### `USE_THOUSAND_SEPARATOR`

Valeur par défaut : `False`

Une valeur booléenne indiquant si les nombres doivent être affichés avec des séparateurs de milliers. Lorsque [`USE_L10N`](#std-setting-USE_L10N) est défini à `True` et que ce réglage l’est également, Django utilise les valeurs de [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) et de [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) pour mettre en forme les nombres, sauf si la locale possède déjà une définition du séparateur de milliers. Dans ce dernier cas, ce séparateur a la priorité et sera utilisé plutôt que le réglage général.

Voir aussi [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) et [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR).

### `USE_TZ`

Valeur par défaut : `False`

Une valeur booléenne indiquant si les dates/heures sont conscientes de leur fuseau horaire. Si défini à `True`, Django utilise en interne des dates/heures conscientes de leur fuseau horaire. Sinon, Django utilise des dates/heures naïves en temps local.

Voir aussi [`TIME_ZONE`](#std-setting-TIME_ZONE), [`USE_I18N`](#std-setting-USE_I18N) et [`USE_L10N`](#std-setting-USE_L10N).

> **Note**
>
> Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) définit `USE_TZ = True` par commodité.

### `USE_X_FORWARDED_HOST`

Valeur par défaut : `False`

A boolean that specifies whether to use the `X-Forwarded-Host` header in
preference to the `Host` header. This should only be enabled if a proxy
which sets this header is in use.

This setting takes priority over [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT). Per
[**RFC 7239 Page 7**](https://datatracker.ietf.org/doc/html/rfc7239.html#page-7), the `X-Forwarded-Host` header can include the port
number, in which case you shouldn’t use [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT).

### `USE_X_FORWARDED_PORT`

> **New in Django 1.9**

Valeur par défaut : `False`

A boolean that specifies whether to use the `X-Forwarded-Port` header in
preference to the `SERVER_PORT` `META` variable. This should only be
enabled if a proxy which sets this header is in use.

[`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) takes priority over this setting.

### `WSGI_APPLICATION`

Valeur par défaut : `None`

Le chemin Python complet de l’objet application WSGI que les serveurs intégrés dans Django vont utiliser (par ex. [`runserver`](/fr/1.9/ref/django-admin/#django-admin-runserver)). La commande de gestion [`django-admin startproject`](/fr/1.9/ref/django-admin/#django-admin-startproject) crée un simple fichier `wsgi.py` contenant un exécutable `application` et fait pointer ce réglage vers cet objet `application`.

Si indéfini, c’est la valeur renvoyée par `django.core.wsgi.get_wsgi_application()` qui sera utilisée. Dans ce cas, le comportement de [`runserver`](/fr/1.9/ref/django-admin/#django-admin-runserver) sera le même que lors des versions précédentes de Django.

### `YEAR_MONTH_FORMAT`

Valeur par défaut : `'F Y'`

Le format par défaut à utiliser pour les champs date dans les listes pour modifications des pages de l’administration de Django, et potentiellement dans d’autres parties du système, dans les cas où seuls l’année et le mois sont affichés.

Par exemple, lorsqu’une page de liste pour modification de l’administration de Django est filtrée par un choix de date, l’en-tête d’un mois donné affiche le mois et l’année. Différentes locales présentent différents formats. Par exemple, l’anglais américain affichera « January 2006, » alors qu’une autre locale affichera peut-être « 2006/January. ».

Notez que lorsque [`USE_L10N`](#std-setting-USE_L10N) vaut `True`, le format piloté par la locale qui correspond a une priorité plus élevée et remplace ce séparateur.

Voir [`chaînes de format de date autorisées`](/fr/1.9/ref/templates/builtins/#std-templatefilter-date). Voir aussi [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) et [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT).

### `X_FRAME_OPTIONS`

Valeur par défaut : `'SAMEORIGIN'`

La valeur par défaut de l’en-tête X-Frame-Options utilisé par [`XFrameOptionsMiddleware`](/fr/1.9/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware). Voir la documentation sur la [protection contre le détournement de clic](/fr/1.9/ref/clickjacking/).

## Auth

Réglages pour [`django.contrib.auth`](/fr/1.9/topics/auth/#module-django.contrib.auth).

### `AUTHENTICATION_BACKENDS`

Valeur par défaut : `['django.contrib.auth.backends.ModelBackend']`

Une liste de classes de moteurs d’authentification (sous forme de chaînes) à utiliser durant la tentative d’authentification d’un utilisateur. Consultez la [documentation sur les moteurs d’authentification](/fr/1.9/topics/auth/customizing/#authentication-backends) pour plus de détails.

### `AUTH_USER_MODEL`

Valeur par défaut : `'auth.User'`

Le modèle à utiliser pour représenter un utilisateur. Voir [Substitution par un modèle User personnalisé](/fr/1.9/topics/auth/customizing/#auth-custom-user).

> **Warning**
>
> Il n’est pas possible de modifier le réglage `AUTH_USER_MODEL` au cours de la vie d’un projet (c’est-à-dire après avoir créé et migré des modèles qui en dépendent) sans effort conséquent. Il est prévu pour être défini au début d’un projet et le modèle qu’il désigne doit être disponible dans la première migration de l’application dans laquelle il se trouve. Voir [Substitution par un modèle User personnalisé](/fr/1.9/topics/auth/customizing/#auth-custom-user) pour plus de détails.

### `LOGIN_REDIRECT_URL`

Valeur par défaut : `'/accounts/profile/'`

L’URL vers laquelle seront redirigées les requêtes après un processus de connexion lorsque la vue `contrib.auth.login` ne reçoit pas de paramètre `next` .

C’est utilisé par exemple par le décorateur [`login_required()`](/fr/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required).

Ce réglage accepte aussi des [motifs d’URL nommés](/fr/1.9/topics/http/urls/#naming-url-patterns) qui peuvent être utilisés pour réduire les doublons de configuration étant donné qu’il n’est pas nécessaire de définir les URL à deux endroits (`settings` et configuration d’URL).

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Ce réglage peut aussi être un chemin Python pointé vers une fonction de vue. Mais cette possibilité sera supprimée dans Django 1.10.

### `LOGIN_URL`

Valeur par défaut : `'/accounts/login/'`

L’URL vers laquelle sont redirigées les requêtes pour un processus de connexion, plus particulièrement lors de l’utilisation du décorateur [`login_required()`](/fr/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required).

Ce réglage accepte aussi des [motifs d’URL nommés](/fr/1.9/topics/http/urls/#naming-url-patterns) qui peuvent être utilisés pour réduire les doublons de configuration étant donné qu’il n’est pas nécessaire de définir les URL à deux endroits (`settings` et configuration d’URL).

> **Deprecated since Django 1.8**
>
> Obsolète depuis la version 1.8: Ce réglage peut aussi être un chemin Python pointé vers une fonction de vue. Mais cette possibilité sera supprimée dans Django 1.10.

### `PASSWORD_RESET_TIMEOUT_DAYS`

Valeur par défaut : `3`

Le nombre de jours de validité d’un lien de réinitialisation de mot de passe. Utilisé par le mécanisme de réinitialisation de mot de passe de [`django.contrib.auth`](/fr/1.9/topics/auth/#module-django.contrib.auth).

### `PASSWORD_HASHERS`

Voir [Stockage des mots de passe par Django](/fr/1.9/topics/auth/passwords/#auth-password-storage).

Valeur par défaut :

```
[
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
    'django.contrib.auth.hashers.BCryptPasswordHasher',
    'django.contrib.auth.hashers.SHA1PasswordHasher',
    'django.contrib.auth.hashers.MD5PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
    'django.contrib.auth.hashers.CryptPasswordHasher',
]
```

### `AUTH_PASSWORD_VALIDATORS`

> **New in Django 1.9**

Valeur par défaut : `[]` (liste vide)

La liste des validateurs utilisés pour vérifier la solidité des mots de passe des utilisateurs. Voir [Validation des mots de passe](/fr/1.9/topics/auth/passwords/#password-validation) pour plus de détails. Par défaut, aucune validation n’est effectuée et tous les mots de passe sont acceptés.

## Messages

Réglages pour [`django.contrib.messages`](/fr/1.9/ref/contrib/messages/#module-django.contrib.messages).

### `MESSAGE_LEVEL`

Valeur par défaut : `messages.INFO`

Définit le niveau minimum des messages qui seront traités par le système des messages. Voir les [niveaux de message](/fr/1.9/ref/contrib/messages/#message-level) pour plus de détails.

> **Important**
>
> Si vous surchargez `MESSAGE_LEVEL` dans votre fichier de réglages et que vous comptez sur les constantes intégrées, vous devez importer directement le module des constantes pour éviter une éventuelle importation circulaire, par ex. :
>
> ```
> from django.contrib.messages import constants as message_constants
> MESSAGE_LEVEL = message_constants.DEBUG
> ```
>
> Si souhaité, vous pouvez indiquer directement les valeurs numériques des constantes en fonction des valeurs dans le [tableau des constantes](/fr/1.9/ref/contrib/messages/#message-level-constants) ci-dessus.

### `MESSAGE_STORAGE`

Valeur par défaut : `'django.contrib.messages.storage.fallback.FallbackStorage'`

Contrôle l’emplacement de stockage des données de messages. Les valeurs possibles sont :

- `'django.contrib.messages.storage.fallback.FallbackStorage'`
- `'django.contrib.messages.storage.session.SessionStorage'`
- `'django.contrib.messages.storage.cookie.CookieStorage'`

Voir les [moteurs de stockage de messages](/fr/1.9/ref/contrib/messages/#message-storage-backends) pour plus de détails.

Les moteurs qui utilisent des cookies – [`CookieStorage`](/fr/1.9/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) et [`FallbackStorage`](/fr/1.9/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage) – utilisent les valeurs de [`SESSION_COOKIE_DOMAIN`](#std-setting-SESSION_COOKIE_DOMAIN), [`SESSION_COOKIE_SECURE`](#std-setting-SESSION_COOKIE_SECURE) et [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) lors de la définition de leurs cookies.

### `MESSAGE_TAGS`

Valeur par défaut :

```
{
    messages.DEBUG: 'debug',
    messages.INFO: 'info',
    messages.SUCCESS: 'success',
    messages.WARNING: 'warning',
    messages.ERROR: 'error',
}
```

Ceci définit l’association du niveau de message à l’étiquette de message, qui est généralement rendue comme une classe CSS au format HTML. Si vous indiquez une valeur, elle étendra celle par défaut. Cela signifie que vous devez seulement définir les valeurs que vous souhaitez redéfinir. Voir [Affichage des messages](/fr/1.9/ref/contrib/messages/#message-displaying) ci-dessus pour plus de détails.

> **Important**
>
> Si vous surchargez `MESSAGE_TAGS` dans votre fichier de réglages et que vous comptez sur les constantes intégrées, vous devez importer directement le module des constantes pour éviter une éventuelle importation circulaire, par ex. :
>
> ```
> from django.contrib.messages import constants as message_constants
> MESSAGE_TAGS = {message_constants.INFO: ''}
> ```
>
> Si souhaité, vous pouvez indiquer directement les valeurs numériques des constantes en fonction des valeurs dans le [tableau des constantes](/fr/1.9/ref/contrib/messages/#message-level-constants) ci-dessus.

## Sessions

Réglages pour [`django.contrib.sessions`](/fr/1.9/topics/http/sessions/#module-django.contrib.sessions).

### `SESSION_CACHE_ALIAS`

Valeur par défaut : `'default'`

Si vous utilisez le [stockage des sessions basé en cache](/fr/1.9/topics/http/sessions/#cached-sessions-backend), ce réglage choisit le cache à utiliser.

### `SESSION_COOKIE_AGE`

Valeur par défaut : `1209600` (2 semaines, en secondes)

L’âge des cookies de sessions, en secondes.

### `SESSION_COOKIE_DOMAIN`

Valeur par défaut : `None`

Le domaine à utiliser pour les cookies de session. Pour des cookies inter-domaines, utilisez une syntaxe du genre `".example.com"` (remarquez le point initial !) et laissez la valeur `None` pour des cookies de domaine standards.

Soyez prudent lors de la mise à jour de ce réglage sur un site de production. Si vous mettez à jour ce paramètre pour activer les cookies inter-domaines sur un site qui utilisait précédemment les cookies de domaine standards, les cookies des utilisateurs existants seront définis sur l’ancien domaine. Il peut en résulter qu’ils seront incapables de s’identifier aussi longtemps que ces cookies persistent.

Ce réglage affecte aussi les cookies définis par [`django.contrib.messages`](/fr/1.9/ref/contrib/messages/#module-django.contrib.messages).

### `SESSION_COOKIE_HTTPONLY`

Valeur par défaut : `True`

Indique si le drapeau `HTTPOnly` doit être utilisé sur le cookie de session. Si ce paramètre est défini à `True`, le code JavaScript côté client ne sera pas en mesure d’accéder au cookie de session.

[HTTPOnly](https://www.owasp.org/index.php/HTTPOnly) est un drapeau inclus dans un en-tête de réponse HTTP Set-Cookie. Il ne fait pas partie du standard [**RFC 2109**](https://datatracker.ietf.org/doc/html/rfc2109.html) pour les cookies, et les navigateurs n’en tiennent pas tous compte. Cependant, quand il est pris en compte, c’est un moyen utile de réduire le risque d’un script côté client accédant les données d’un cookie protégé.

En activant ce réglage, cela complique la tâche d’un attaquant qui voudrait exploiter une vulnérabilité de script inter-site pour accéder sans limite à une session d’utilisateur. Il n’y a pas beaucoup d’excuses pour ne pas activer ce réglage : si votre code dépend de la lecture de cookies de session à partir du code JavaScript, c’est que vous faites probablement quelque chose de faux.

### `SESSION_COOKIE_NAME`

Valeur par défaut : `'sessionid'`

Le nom du cookie à utiliser pour les sessions. Vous pouvez mettre ce que vous voulez (pour autant que ce soit différent de ceux qui existent déjà dans votre application).

### `SESSION_COOKIE_PATH`

Valeur par défaut : `'/'`

Le chemin défini dans le cookie de session. Cela doit correspondre au chemin d’URL de votre installation de Django ou être un parent de ce chemin.

Utile si vous avez plusieurs instances de Django fonctionnant sous le même nom d’hôte. Ils peuvent alors utiliser des chemins de cookies différents pour que chaque instance ne voit que son propre cookie de session.

### `SESSION_COOKIE_SECURE`

Valeur par défaut : `False`

Indique s’il est nécessaire d’utiliser un cookie sécurisé pour le cookie de session. Si défini à `True`, le cookie sera marqué comme « sécurisé », ce qui signifie que les navigateurs sont chargés de vérifier que le cookie n’est envoyé que pour des connexions HTTPS.

Comme il est trivial pour un renifleur de paquets (comme par ex. [Firesheep](http://codebutler.com/firesheep)) d’intercepter une session utilisateur quand le cookie de session est envoyé en clair, il n’y a vraiment aucune excuse de désactiver ce paramètre. Il vous empêchera d’utiliser les sessions dans les requêtes non sécurisées et c’est une bonne chose.

### `SESSION_ENGINE`

Valeur par défaut : `'django.contrib.sessions.backends.db'`

Contrôle l’emplacement de stockage des données de sessions. Les moteurs inclus sont :

- `'django.contrib.sessions.backends.db'`
- `'django.contrib.sessions.backends.file'`
- `'django.contrib.sessions.backends.cache'`
- `'django.contrib.sessions.backends.cached_db'`
- `'django.contrib.sessions.backends.signed_cookies'`

Voir [Configuration du moteur de sessions](/fr/1.9/topics/http/sessions/#configuring-sessions) pour plus de détails.

### `SESSION_EXPIRE_AT_BROWSER_CLOSE`

Valeur par défaut : `False`

Indique s’il faut que la session expire lorsque l’utilisateur ferme son navigateur. Voir [Expiration ou persistance des sessions](/fr/1.9/topics/http/sessions/#browser-length-vs-persistent-sessions).

### `SESSION_FILE_PATH`

Valeur par défaut : `None`

Si vous utilisez le stockage de sessions basé sur des fichiers, cela définit le répertoire dans lequel Django stocke les données de sessions. Avec la valeur par défaut (`None`), Django utilise le répertoire temporaire standard du système.

### `SESSION_SAVE_EVERY_REQUEST`

Valeur par défaut : `False`

Indique si les données de sessions sont enregistrées lors de chaque requête. Avec la valeur `False` (par défaut), Django n’enregistre la session dans la base de données qu’au moment où la session a été modifiée, c’est-à-dire qu’au moins une des valeurs de son dictionnaire a été définie ou supprimée. Les sessions vides ne seront pas créées, même si ce réglage est activé.

### `SESSION_SERIALIZER`

Par défaut : `'django.contrib.sessions.serializers.JSONSerializer'`

Chemin d’importation complet d’une classe de sérialisation à utiliser pour la sérialisation des données de session. Les sérialiseurs inclus sont :

- `'django.contrib.sessions.serializers.PickleSerializer'`
- `'django.contrib.sessions.serializers.JSONSerializer'`

Voir [Sérialisation des sessions](/fr/1.9/topics/http/sessions/#session-serialization) pour plus de détails, y compris un avertissement concernant une éventuelle exécution de code à distance lors de l’utilisation de [`PickleSerializer`](/fr/1.9/topics/http/sessions/#django.contrib.sessions.serializers.PickleSerializer).

## Sites

Réglages pour [`django.contrib.sites`](/fr/1.9/ref/contrib/sites/#module-django.contrib.sites).

### `SITE_ID`

Valeur par défaut :  non définie

L’identifiant (nombre entier) du site actuel dans la table de base de données `django_site`. Peut être utilisé par les applications pour lier leurs données à des sites spécifiques et ainsi gérer dans une même base de données du contenu pour plusieurs sites.

## Fichiers statiques

Réglages pour [`django.contrib.staticfiles`](/fr/1.9/ref/contrib/staticfiles/#module-django.contrib.staticfiles).

### `STATIC_ROOT`

Valeur par défaut : `None`

Le chemin absolu vers le répertoire dans lequel [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) rassemble les fichiers statiques en vue du déploiement.

Exemple : `"/var/www/example.com/static/"`

Si l’application complémentaire [staticfiles](/fr/1.9/ref/contrib/staticfiles/) est activée (c’est le cas par défaut), la commande de gestion [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) rassemble les fichiers statiques dans ce répertoire. Consultez le guide pratique sur la [gestion des fichiers statiques](/fr/1.9/howto/static-files/) pour plus de détails sur son utilisation.

> **Warning**
>
> Ce réglage doit indiquer un répertoire de destination initialement vide pour la collecte des fichiers statiques depuis leur emplacement permanent vers un répertoire unique pour faciliter le déploiement ; ce n’est **pas** un endroit pour stocker des fichiers statiques de manière permanente. À cet effet, il s’agit d’utiliser les répertoires qui seront recherchés par les [`découvreurs`](#std-setting-STATICFILES_FINDERS) de [staticfiles](/fr/1.9/ref/contrib/staticfiles/), qui sont par défaut les sous-répertoires `'static/'` des applications et tout répertoire mentionné dans [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS).

### `STATIC_URL`

Valeur par défaut : `None`

URL utilisée pour se référer aux fichiers statiques se trouvant dans [`STATIC_ROOT`](#std-setting-STATIC_ROOT).

Exemple : `"/static/"` ou `"http://static.example.com/"`

Si ce réglage ne vaut pas `None`, il est utilisé comme chemin de base pour les [définitions de fichiers annexes](/fr/1.9/topics/forms/media/#form-asset-paths) (la classe `Media`) et l”[application staticfiles](/fr/1.9/ref/contrib/staticfiles/).

Cette valeur doit se terminer par une barre oblique quand elle est définie.

Vous devrez peut-être [configurer ces fichiers pour être servis en développement](/fr/1.9/howto/static-files/#serving-static-files-in-development) et aurez sans aucun doute besoin de le faire [en production](/fr/1.9/howto/static-files/deployment/).

### `STATICFILES_DIRS`

Valeur par défaut : `[]` (liste vide)

Ce réglage définit les emplacements supplémentaires que l’application `staticfiles` parcourt si la recherche par `FileSystemFinder` est activée, par exemple quand vous utilisez la commande de gestion [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) ou [`findstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-findstatic), ou quand vous utilisez la vue de service de fichiers statiques.

Il devrait contenir une liste de chaînes contenant les chemins complets vers les répertoires de fichiers supplémentaires ; par exemple :

```
STATICFILES_DIRS = [
    "/home/special.polls.com/polls/static",
    "/home/polls.com/polls/static",
    "/opt/webfiles/common",
]
```

Notez que ces chemins doivent utiliser des barres obliques de type Unix, même sur Windows (par ex. `"C:/Users/user/mon_site/contenu_statique_suppl"`).

#### Préfixes (facultatifs)

Dans le cas où vous souhaiteriez vous référer aux fichiers d’un des emplacements avec un espace de noms supplémentaire, il est **possible** d’indiquer un préfixe sous la forme de tuples `(préfixe, chemin)`, comme par exemple :

```
STATICFILES_DIRS = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]
```

Par exemple, en supposant que [`STATIC_URL`](#std-setting-STATIC_URL) soit défini à `/static/`, la commande de gestion [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic) recueillera les fichiers « stats » dans un sous-répertoire `'downloads'` de [`STATIC_ROOT`](#std-setting-STATIC_ROOT).

Cela permettrait de se référer au fichier local `'/opt/webfiles/stats/polls_20101022.tar.gz'` par `'/static/downloads/polls_20101022.tar.gz'` dans les gabarits ; par exemple :

```html+django
<a href="{% static "downloads/polls_20101022.tar.gz" %}">
```

### `STATICFILES_STORAGE`

Par défaut : `django.contrib.staticfiles.storage.StaticFilesStorage`

Le moteur de stockage de fichiers à utiliser lors de la collecte des fichiers statiques avec la commande d’administration [`collectstatic`](/fr/1.9/ref/contrib/staticfiles/#django-admin-collectstatic).

Une instance prête à l’emploi du moteur de stockage défini dans ce réglage peut être trouvée dans `django.contrib.staticfiles.storage.staticfiles_storage`.

Pour un exemple, voir [Fichiers statiques sur un service cloud ou un CDN](/fr/1.9/howto/static-files/deployment/#staticfiles-from-cdn).

### `STATICFILES_FINDERS`

Valeur par défaut :

```
[
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]
```

La liste des moteurs de découverte sachant retrouver les fichiers statiques en divers endroits.

Le comportement par défaut recherche les fichiers stockés aux emplacements du réglage [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS) (en utilisant `django.contrib.staticfiles.finders.FileSystemFinder`) et dans un sous-répertoire `static` de chaque application (en utilisant `django.contrib.staticfiles.finders.AppDirectoriesFinder`). Si plusieurs fichiers de même nom sont présents, le premier fichier trouvé est utilisé.

Un moteur de découverte est désactivé par défaut : `django.contrib.staticfiles.finders.DefaultStorageFinder`. S’il est ajouté au réglage [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS), il recherche les fichiers statiques dans l’emplacement de stockage des fichiers par défaut tel que défini par le réglage [`DEFAULT_FILE_STORAGE`](#std-setting-DEFAULT_FILE_STORAGE).

> **Note**
>
> Lorsqu’on utilise le moteur `AppDirectoriesFinder`, il faut s’assurer que les applications peuvent être trouvées par `staticfiles`. Il suffit d’ajouter l’application au réglage [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) du site.

Les moteurs de découverte de fichiers statiques sont actuellement considérés comme une interface privée, ce qui explique que cette interface n’est pas documentée.

## Index thématique des réglages de base

### Cache

- [`CACHES`](#std-setting-CACHES)
- [`CACHE_MIDDLEWARE_ALIAS`](#std-setting-CACHE_MIDDLEWARE_ALIAS)
- [`CACHE_MIDDLEWARE_KEY_PREFIX`](#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX)
- [`CACHE_MIDDLEWARE_SECONDS`](#std-setting-CACHE_MIDDLEWARE_SECONDS)

### Base de données

- [`DATABASES`](#std-setting-DATABASES)
- [`DATABASE_ROUTERS`](#std-setting-DATABASE_ROUTERS)
- [`DEFAULT_INDEX_TABLESPACE`](#std-setting-DEFAULT_INDEX_TABLESPACE)
- [`DEFAULT_TABLESPACE`](#std-setting-DEFAULT_TABLESPACE)

### Débogage

- [`DEBUG`](#std-setting-DEBUG)
- [`DEBUG_PROPAGATE_EXCEPTIONS`](#std-setting-DEBUG_PROPAGATE_EXCEPTIONS)

### Messagerie

- [`ADMINS`](#std-setting-ADMINS)
- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL)
- [`EMAIL_BACKEND`](#std-setting-EMAIL_BACKEND)
- [`EMAIL_FILE_PATH`](#std-setting-EMAIL_FILE_PATH)
- [`EMAIL_HOST`](#std-setting-EMAIL_HOST)
- [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD)
- [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER)
- [`EMAIL_PORT`](#std-setting-EMAIL_PORT)
- [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE)
- [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE)
- [`EMAIL_SUBJECT_PREFIX`](#std-setting-EMAIL_SUBJECT_PREFIX)
- [`EMAIL_TIMEOUT`](#std-setting-EMAIL_TIMEOUT)
- [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS)
- [`MANAGERS`](#std-setting-MANAGERS)
- [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL)

### Signalement d’erreurs

- [`DEFAULT_EXCEPTION_REPORTER_FILTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER)
- [`IGNORABLE_404_URLS`](#std-setting-IGNORABLE_404_URLS)
- [`MANAGERS`](#std-setting-MANAGERS)
- [`SILENCED_SYSTEM_CHECKS`](#std-setting-SILENCED_SYSTEM_CHECKS)

### Téléversement de fichiers

- [`DEFAULT_FILE_STORAGE`](#std-setting-DEFAULT_FILE_STORAGE)
- [`FILE_CHARSET`](#std-setting-FILE_CHARSET)
- [`FILE_UPLOAD_HANDLERS`](#std-setting-FILE_UPLOAD_HANDLERS)
- [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE)
- [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS)
- [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR)
- [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT)
- [`MEDIA_URL`](#std-setting-MEDIA_URL)

### Traduction et régionalisation (`i18n`/`l10n`)

- [`DATE_FORMAT`](#std-setting-DATE_FORMAT)
- [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS)
- [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT)
- [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS)
- [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR)
- [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK)
- [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH)
- [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE)
- [`LANGUAGE_COOKIE_AGE`](#std-setting-LANGUAGE_COOKIE_AGE)
- [`LANGUAGE_COOKIE_DOMAIN`](#std-setting-LANGUAGE_COOKIE_DOMAIN)
- [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME)
- [`LANGUAGE_COOKIE_PATH`](#std-setting-LANGUAGE_COOKIE_PATH)
- [`LANGUAGES`](#std-setting-LANGUAGES)
- [`LOCALE_PATHS`](#std-setting-LOCALE_PATHS)
- [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT)
- [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING)
- [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT)
- [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT)
- [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR)
- [`TIME_FORMAT`](#std-setting-TIME_FORMAT)
- [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS)
- [`TIME_ZONE`](#std-setting-TIME_ZONE)
- [`USE_I18N`](#std-setting-USE_I18N)
- [`USE_L10N`](#std-setting-USE_L10N)
- [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR)
- [`USE_TZ`](#std-setting-USE_TZ)
- [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT)

### HTTP

- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`DEFAULT_CONTENT_TYPE`](#std-setting-DEFAULT_CONTENT_TYPE)
- [`DISALLOWED_USER_AGENTS`](#std-setting-DISALLOWED_USER_AGENTS)
- [`FORCE_SCRIPT_NAME`](#std-setting-FORCE_SCRIPT_NAME)
- [`INTERNAL_IPS`](#std-setting-INTERNAL_IPS)
- [`MIDDLEWARE_CLASSES`](#std-setting-MIDDLEWARE_CLASSES)
- Sécurité

  - [`SECURE_BROWSER_XSS_FILTER`](#std-setting-SECURE_BROWSER_XSS_FILTER)
  - [`SECURE_CONTENT_TYPE_NOSNIFF`](#std-setting-SECURE_CONTENT_TYPE_NOSNIFF)
  - [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS)
  - [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS)
  - [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER)
  - [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT)
  - [`SECURE_SSL_HOST`](#std-setting-SECURE_SSL_HOST)
  - [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT)
- [`SIGNING_BACKEND`](#std-setting-SIGNING_BACKEND)
- [`USE_ETAGS`](#std-setting-USE_ETAGS)
- [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST)
- [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT)
- [`WSGI_APPLICATION`](#std-setting-WSGI_APPLICATION)

### Journalisation

- [`LOGGING`](#std-setting-LOGGING)
- [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG)

### Modèles

- [`ABSOLUTE_URL_OVERRIDES`](#std-setting-ABSOLUTE_URL_OVERRIDES)
- [`FIXTURE_DIRS`](#std-setting-FIXTURE_DIRS)
- [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS)

### Sécurité

- Protection contre le « Cross site request forgery » (CSRF)

  - [`CSRF_COOKIE_DOMAIN`](#std-setting-CSRF_COOKIE_DOMAIN)
  - [`CSRF_COOKIE_NAME`](#std-setting-CSRF_COOKIE_NAME)
  - [`CSRF_COOKIE_PATH`](#std-setting-CSRF_COOKIE_PATH)
  - [`CSRF_COOKIE_SECURE`](#std-setting-CSRF_COOKIE_SECURE)
  - [`CSRF_FAILURE_VIEW`](#std-setting-CSRF_FAILURE_VIEW)
  - [`CSRF_HEADER_NAME`](#std-setting-CSRF_HEADER_NAME)
  - [`CSRF_TRUSTED_ORIGINS`](#std-setting-CSRF_TRUSTED_ORIGINS)
- [`SECRET_KEY`](#std-setting-SECRET_KEY)
- [`X_FRAME_OPTIONS`](#std-setting-X_FRAME_OPTIONS)

### Sérialisation

- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`SERIALIZATION_MODULES`](#std-setting-SERIALIZATION_MODULES)

### Gabarits

- [`ALLOWED_INCLUDE_ROOTS`](#std-setting-ALLOWED_INCLUDE_ROOTS)
- [`TEMPLATES`](#std-setting-TEMPLATES)
- [`TEMPLATE_CONTEXT_PROCESSORS`](#std-setting-TEMPLATE_CONTEXT_PROCESSORS)
- [`TEMPLATE_DEBUG`](#std-setting-TEMPLATE_DEBUG)
- [`TEMPLATE_DIRS`](#std-setting-TEMPLATE_DIRS)
- [`TEMPLATE_LOADERS`](#std-setting-TEMPLATE_LOADERS)
- [`TEMPLATE_STRING_IF_INVALID`](#std-setting-TEMPLATE_STRING_IF_INVALID)

### Tests

- Base de données : [`TEST`](#std-setting-DATABASE-TEST)
- [`TEST_NON_SERIALIZED_APPS`](#std-setting-TEST_NON_SERIALIZED_APPS)
- [`TEST_RUNNER`](#std-setting-TEST_RUNNER)

### URL

- [`APPEND_SLASH`](#std-setting-APPEND_SLASH)
- [`PREPEND_WWW`](#std-setting-PREPEND_WWW)
- [`ROOT_URLCONF`](#std-setting-ROOT_URLCONF)