---
title: "Comment déployer avec ASGI"
version: 5.1
locale: fr
source: https://docs.djangoproject.com/fr/5.1/howto/deployment/asgi/
canonical: https://djangodocs.dev/fr/5.1/howto/deployment/asgi/
---
# Comment déployer avec ASGI

En plus de WSGI, Django peut aussi être déployé avec [ASGI](https://asgi.readthedocs.io/en/latest/), le standard Python émergent pour les serveurs et applications asynchrones.

La commande d’administration [`startproject`](/fr/5.1/ref/django-admin/#django-admin-startproject) de Django définit par défaut une configuration ASGI pour vous, que vous pouvez ensuite adapter aux besoins de votre projet ; cette configuration est alors utilisable par tout serveur d’applications se conformant au standard ASGI.

Django contient de la documentation sommaire pour les serveurs ASGI suivants :

- [Comment utiliser Django avec Daphne](/fr/5.1/howto/deployment/asgi/daphne/)
- [Comment utiliser Django avec Hypercorn](/fr/5.1/howto/deployment/asgi/hypercorn/)
- [Comment utiliser Django avec Uvicorn](/fr/5.1/howto/deployment/asgi/uvicorn/)

## L’objet `application`

Comme WSGI, ASGI met à disposition un objet exécutable `application` que le serveur d’applications utilise pour communiquer avec votre code. Ceci est généralement fourni par un objet nommé `application` dans un module Python accessible par le serveur.

La commande [`startproject`](/fr/5.1/ref/django-admin/#django-admin-startproject) crée un fichier `<nom_de_projet>/asgi.py` qui contient l’objet exécutable `application`.

Il n’est pas utilisé par le serveur de développement (`runserver`), mais peut être utilisé par tout serveur ASGI, que ce soit en développement ou en production.

Les serveurs ASGI acceptent généralement le chemin vers l’objet application sous forme de chaîne ; pour la plupart des projets Django, cela ressemble à `monprojet.asgi:application`.

> **Warning**
>
> Bien que le gestionnaire ASGI par défaut de Django exécute tout le code dans un fil d’exécution synchrone, si vous choisissez d’exécuter votre propre gestionnaire asynchrone, vous devez être conscient des mesures de sûreté asynchrones.
>
> N’appelez pas de fonctions ou bibliothèques bloquantes à partir de code asynchrone. Django vous empêche de faire cela dans les parties de Django qui ne gèrent pas l’asynchronisme, mais ce n’est pas forcément le cas pour du code tiers ou de bibliothèques Python.

## Configuration du module de réglages (settings)

Lorsque le serveur ASGI charge une application, Django doit importer le module `settings`, c’est là où se trouve toute la configuration de votre application.

Django utilise la variable d’environnement [`DJANGO_SETTINGS_MODULE`](/fr/5.1/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) pour trouver le module `settings` approprié. Il doit contenir le chemin vers le module `settings` avec la syntaxe pointée. Il est possible d’utiliser une valeur différente entre le développement et la production ; tout dépend de la façon d’organiser les réglages.

Si cette variable n’est pas définie, le fichier `asgi.py` par défaut la définit à `monsite.settings`, où `monsite` est le nom de votre projet.

## Application des intergiciels ASGI

Pour appliquer un , ou pour envelopper Django dans une autre application ASGI, vous pouvez encapsuler l’objet `application` de Django dans le fichier `asgi.py`. Par exemple

```
from some_asgi_library import AmazingMiddleware

application = AmazingMiddleware(application)
```