---
title: "Signaux"
version: 5.0
locale: fr
source: https://docs.djangoproject.com/fr/5.0/ref/signals/
canonical: https://djangodocs.dev/fr/5.0/ref/signals/
---
# Signaux

Une liste de tous les signaux envoyés par Django. Tous les signaux intégrés sont envoyés par la méthode [`send()`](/fr/5.0/topics/signals/#django.dispatch.Signal.send).

> **See also**
>
> Consultez la documentation sur la [distribution de signaux](/fr/5.0/topics/signals/) pour plus d’informations sur la façon d’inscrire et de recevoir des signaux.
>
> Le [système d’authentification](/fr/5.0/topics/auth/) envoie des [signaux lorsqu’un utilisateur se connecte ou se déconnecte](/fr/5.0/ref/contrib/auth/#topics-auth-signals).

## Signaux de modèle

Le module [`django.db.models.signals`](#module-django.db.models.signals) définit un ensemble de signaux envoyés par le système des modèles.

> **Warning**
>
> Les signaux peuvent rendre votre code plus difficile à maintenir. Avant de recourir aux signaux de modèles, considérez l’implémentation d’une méthode utilitaire d’un [gestionnaire personnalisé](/fr/5.0/topics/db/managers/#custom-managers), afin de mettre à jour vos modèles et d’appliquer toute logique supplémentaire, ou alors de [surcharger les méthodes de modèles](/fr/5.0/topics/db/models/#overriding-model-methods).

> **Warning**
>
> Beaucoup de ces signaux sont envoyés par différentes méthodes de modèle comme `__init__()` ou [`save()`](/fr/5.0/ref/models/instances/#django.db.models.Model.save). Ces méthodes peuvent être surchargées dans votre propre code.
>
> Si vous surchargez ces méthodes dans un de vos modèles, vous devez appeler la méthode de la classe parente si vous voulez que les signaux soient envoyés.
>
> Notez également que Django stocke les gestionnaires de signaux comme référence faible par défaut. Cela signifie que si le récepteur est une fonction locale, il peut être purgé de la mémoire. Pour empêcher cela, indiquez `weak=False` lors de l’appel à la méthode [`connect()`](/fr/5.0/topics/signals/#django.dispatch.Signal.connect) du signal.

> **Note**
>
> Le modèle `sender` des signaux de modèles peut être référencé de manière différée lors de la connexion à un récepteur en indiquant son étiquette d’application complète. Par exemple, un modèle `Question` défini dans l’application `polls` peut être référencé en tant que `'polls.Question'`. Ce type de référence peut être bien pratique lorsqu’on est confronté à des dépendances d’importation circulaire ou à des modèles interchangeables.

### `pre_init`

#### `django.db.models.signals.pre_init`

Lors de chaque instanciation d’un modèle Django, ce signal est envoyé au début de la méthode `__init__()` du modèle.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle dont une instance vient d’être créée.

**`args`**

  Une liste de paramètres positionnels transmis à `__init__()`.

**`kwargs`**

  Un dictionnaire de paramètres nommés transmis à `__init__()`.

Par exemple, le [tutoriel](/fr/5.0/intro/tutorial02/) contient cette ligne :

```
q = Question(question_text="What's new?", pub_date=timezone.now())
```

Les paramètres envoyés au gestionnaire [`pre_init`](#django.db.models.signals.pre_init) sont :

| Paramètre | Valeur |
| --- | --- |
| `sender` | `Question` (la classe elle-même) |
| `args` | `[]` (une liste vide, car aucun paramètre positionnel n’a été transmis à `__init__()`) |
| `kwargs` | `{'question_text': "What's new?",`<br>`'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.timezone.utc)}` |

### `post_init`

#### `django.db.models.signals.post_init`

Comme `pre_init`, mais celui-ci est envoyé lorsque la méthode `__init__()` se termine.

Paramètres envoyés avec ce signal :

**`sender`**

  Comme ci-dessus : la classe de modèle dont une instance vient d’être créée.

**`instance`**

  L’instance de modèle réelle qui vient d’être créée.

  > **Note**
  >
  > [`instance._state`](/fr/5.0/ref/models/instances/#django.db.models.Model._state) n’est pas défini avant l’envoi du signal `post_init`, ce qui fait que les attributs `_state` ont toujours leurs valeurs par défaut. Par exemple, `_state.db` vaut `None`.

> **Warning**
>
> Pour des raisons de performance, vous ne devriez pas exécuter de requête dans les récepteurs des signaux `pre_init` ou `post_init` parce qu’elles seraient exécutées pour chaque instance renvoyée durant une itération d’un jeu de requête.

### `pre_save`

#### `django.db.models.signals.pre_save`

Envoyé au début de la méthode [`save()`](/fr/5.0/ref/models/instances/#django.db.models.Model.save) d’un modèle.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle.

**`instance`**

  L’instance réelle en cours d’enregistrement.

**`raw`**

  Valeur booléenne ; `True` si le modèle est enregistré exactement comme présenté (par ex. lors du chargement d’un [instantané](/fr/5.0/topics/db/fixtures/#fixtures-explanation)). Il ne faut pas interroger ou modifier d’autres enregistrements de la base de données, car celle-ci pourrait se trouver provisoirement dans un état non cohérent.

**`using`**

  L’alias de base de données utilisé.

**`update_fields`**

  Le groupe de champs à mettre à jour tel que transmis à la méthode [`Model.save()`](/fr/5.0/ref/models/instances/#django.db.models.Model.save), ou `None` si `update_fields` n’a pas été transmis à `save()`.

### `post_save`

#### `django.db.models.signals.post_save`

Comme [`pre_save`](#django.db.models.signals.pre_save), mais envoyé à la fin de la méthode [`save()`](/fr/5.0/ref/models/instances/#django.db.models.Model.save).

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle.

**`instance`**

  L’instance réelle en cours d’enregistrement.

**`created`**

  Valeur booléenne ; `True` si un nouvel enregistrement a été créé.

**`raw`**

  Valeur booléenne ; `True` si le modèle est enregistré exactement comme présenté (par ex. lors du chargement d’un [instantané](/fr/5.0/topics/db/fixtures/#fixtures-explanation)). Il ne faut pas interroger ou modifier d’autres enregistrements de la base de données, car celle-ci pourrait se trouver provisoirement dans un état non cohérent.

**`using`**

  L’alias de base de données utilisé.

**`update_fields`**

  Le groupe de champs à mettre à jour tel que transmis à la méthode [`Model.save()`](/fr/5.0/ref/models/instances/#django.db.models.Model.save), ou `None` si `update_fields` n’a pas été transmis à `save()`.

### `pre_delete`

#### `django.db.models.signals.pre_delete`

Envoyé au début de la méthode  [`delete()`](/fr/5.0/ref/models/instances/#django.db.models.Model.delete) d’un modèle ou de la méthode [`delete()`](/fr/5.0/ref/models/querysets/#django.db.models.query.QuerySet.delete) d’un `QuerySet`.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle.

**`instance`**

  L’instance réelle en cours de suppression.

**`using`**

  L’alias de base de données utilisé.

`origin`

> L’origine de la suppression étant l’instance d’un `Model` ou d’une classe `QuerySet`.

### `post_delete`

#### `django.db.models.signals.post_delete`

Comme [`pre_delete`](#django.db.models.signals.pre_delete), mais envoyé à la fin de la méthode [`delete()`](/fr/5.0/ref/models/instances/#django.db.models.Model.delete) d’un modèle ou de la méthode [`delete()`](/fr/5.0/ref/models/querysets/#django.db.models.query.QuerySet.delete) d’un `QuerySet`.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle.

**`instance`**

  L’instance réelle en cours de suppression.

  Notez que l’objet ne se trouve plus dans la base de données, soyez donc très prudent avec ce que vous faites de cette instance.

**`using`**

  L’alias de base de données utilisé.

`origin`

> L’origine de la suppression étant l’instance d’un `Model` ou d’une classe `QuerySet`.

### `m2m_changed`

#### `django.db.models.signals.m2m_changed`

Envoyé lorsqu’un champ [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField) est modifié dans une instance de modèle. Strictement parlant, il ne s’agit pas d’un signal de modèle car il est envoyé par [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField), mais comme il complète les signaux [`pre_save`](#django.db.models.signals.pre_save)/[`post_save`](#django.db.models.signals.post_save) et [`pre_delete`](#django.db.models.signals.pre_delete)/[`post_delete`](#django.db.models.signals.post_delete) en ce qui concerne le suivi des modifications des modèles, nous l’avons inclus sous cette rubrique.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèles intermédiaire déterminant le champ [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField). Cette classe est automatiquement créée lors de la définition d’un champ plusieurs-à-plusieurs ; vous pouvez y accéder par l’attribut `through` du champ plusieurs-à-plusieurs.

**`instance`**

  L’instance dont la relation plusieurs-à-plusieurs est mise à jour. Cela peut être une instance de `sender` ou de la classe à laquelle est liée le champ [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField).

**`action`**

  Une chaîne indiquant le type de mise à jour effectuée sur la relation. Voici les valeurs possibles :

  **`"pre_add"`**

    Envoyé *avant* qu’un ou plusieurs objets soient ajoutés à la relation.

  **`"post_add"`**

    Envoyé *après* qu’un ou plusieurs objets ont été ajoutés à la relation.

  **`"pre_remove"`**

    Envoyé *avant* qu’un ou plusieurs objets soient supprimés de la relation.

  **`"post_remove"`**

    Envoyé *après* qu’un ou plusieurs objets ont été supprimés de la relation.

  **`"pre_clear"`**

    Envoyé *avant* que la relation soit effacée.

  **`"post_clear"`**

    Envoyé *après* que la relation a été effacée.

**`reverse`**

  Indique quel côté de la relation est mis à jour (c’est-à-dire si c’est la relation directe ou inverse qui est en cours de modification).

**`model`**

  La classe des objets qui sont ajoutés, supprimés ou retirés de la relation.

**`pk_set`**

  Pour les actions  `pre_add` et `post_add`, il s’agit d’un ensemble de clés primaires qui seront ou ont été ajoutées à la relation. Il peut s’agir d’un sous-ensemble des valeurs soumises pour l’ajout, car les insertions doivent filtrer les valeurs existantes afin d’éviter les erreurs de base de données `IntegrityError`.

  Pour les actions `pre_remove` et `post_remove`, il s’agit d’un ensemble de clés primaires qui ont été soumises pour la suppression de la relation. Ces valeurs ne dépendent pas du succès ou non de leur réelle suppression. En particulier, des valeurs inexistantes peuvent être soumises et apparaître donc dans `pk_set`, même si elles n’auront aucun effet sur la base de données.

  Pour les signaux `pre_clear` et `post_clear` actions, cette valeur vaut `None`.

**`using`**

  L’alias de base de données utilisé.

Par exemple, si une `Pizza` peut comporter plusieurs objets `Topping`, selon ce modèle :

```
class Topping(models.Model):
    # ...
    pass

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)
```

Si nous connectons un gestionnaire comme ceci :

```
from django.db.models.signals import m2m_changed

def toppings_changed(sender, **kwargs):
    # Do something
    pass

m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)
```

puis que nous faisons quelque chose comme ça :

```pycon
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
```

les paramètres envoyés à un gestionnaire [`m2m_changed`](#django.db.models.signals.m2m_changed) (`toppings_changed` dans l’exemple ci-dessus) seraient :

| Paramètre | Valeur |
| --- | --- |
| `sender` | `Pizza.toppings.through` (la classe plusieurs-à-plusieurs intermédiaire) |
| `instance` | `p` (l’instance `Pizza` en cours de modification) |
| `action` | `"pre_add"` (suivi d’un autre signal avec `"post_add"`) |
| `reverse` | `False` (`Pizza` contient le champ [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField), ce qui fait que cette fonction modifie la relation directe) |
| `model` | `Topping` (la classe des objets ajoutés à `Pizza`) |
| `pk_set` | `{t.id}` (car seul `Topping t` a été ajouté à la relation) |
| `using` | `"default"` (parce que le routeur par défaut dirige les écritures à cette destination) |

Et si nous faisions ensuite quelque chose comme ceci :

```pycon
>>> t.pizza_set.remove(p)
```

les paramètres envoyés à un gestionnaire [`m2m_changed`](#django.db.models.signals.m2m_changed) seraient :

| Paramètre | Valeur |
| --- | --- |
| `sender` | `Pizza.toppings.through` (la classe plusieurs-à-plusieurs intermédiaire) |
| `instance` | `t` (l’instance `Topping` en cours de modification) |
| `action` | `"pre_remove"` (suivi d’un autre signal avec `"post_remove"`) |
| `reverse` | `True` (c’est `Pizza` qui contient le champ [`ManyToManyField`](/fr/5.0/ref/models/fields/#django.db.models.ManyToManyField), ce qui fait que cette fonction modifie la relation inverse) |
| `model` | `Pizza` (la classe des objets retirés de `Topping`) |
| `pk_set` | `{p.id}` (car seul `Pizza p` a été enlevé de la relation) |
| `using` | `"default"` (parce que le routeur par défaut dirige les écritures à cette destination) |

### `class_prepared`

#### `django.db.models.signals.class_prepared`

Envoyé chaque fois qu’une classe de modèle a été « préparée », c’est-à-dire après que le modèle a été défini et inscrit dans le système des modèles de Django. Django utilise ce signal en interne ; il n’est généralement pas utilisé dans des applications tierces.

Comme ce signal est envoyé durant le processus de remplissage du registre des applications et que [`AppConfig.ready()`](/fr/5.0/ref/applications/#django.apps.AppConfig.ready) s’exécute après la fin de ce remplissage, les récepteurs ne peuvent pas être connectés dans cette méthode. Une possibilité est de les connecter dans `AppConfig.__init__()` en prenant soi de ne pas importer de modèles ni de déclencher des appels au registre des applications.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de modèle qui vient d’être préparée.

## Signaux de gestion

Signaux envoyés par [django-admin](/fr/5.0/ref/django-admin/).

### `pre_migrate`

#### `django.db.models.signals.pre_migrate`

Envoyé par la commande [`migrate`](/fr/5.0/ref/django-admin/#django-admin-migrate) afin le début de l’installation d’une application. Il n’est pas émis pour les applications qui n’ont pas de module `models`.

Paramètres envoyés avec ce signal :

**`sender`**

  Une instance [`AppConfig`](/fr/5.0/ref/applications/#django.apps.AppConfig) de l’application sur le point d’être migrée/synchronisée.

**`app_config`**

  Identique à `sender`.

**`verbosity`**

  Indique la quantité d’informations que `manage.py` affiche à l’écran. Voir l’option [`--verbosity`](/fr/5.0/ref/django-admin/#cmdoption-verbosity) pour plus de détails.

  Les fonctions à l’écoute de [`pre_migrate`](#django.db.models.signals.pre_migrate) devraient ajuster ce qu’elles affichent en fonction de la valeur de ce paramètre.

**`interactive`**

  Si `interactive` vaut `True`, il est tout à fait possible de demander à l’utilisateur de saisir des informations sur la ligne de commande. Si `interactive` vaut `False`, les fonctions à l’écoute de ce signal ne doivent pas du tout interroger l’utilisateur.

  Par exemple, l’application [`django.contrib.auth`](/fr/5.0/topics/auth/#module-django.contrib.auth) ne demande les informations de création du super-utilisateur que lorsqu”`interactive` vaut `True`.

**`stdout`**

  Un objet de type flux vers lequel sera redirigée la sortie verbeuse.

**`using`**

  L’alias de base de données sur laquelle une commande va agir.

**`plan`**

  Le plan de migration qui sera utilisé pour l’exécution des migrations. Même si le plan ne fait pas partie de l’API publique, sa présence sert aux rares cas où il est nécessaire de connaître le plan. Un plan est une liste de tuples binaires avec le premier élément comme instance d’une classe de migration et le second élément indiquant si la migration a été défaite (`True`) ou appliquée (`False`).

**`apps`**

  Une instance de [`Apps`](/fr/5.0/ref/applications/#module-django.apps) contenant l’état du projet avant l’exécution des migrations. Elle devrait être utilisée en lieu et place du registre global [`apps`](/fr/5.0/ref/applications/#django.apps.apps) pour récupérer les modèles sur lesquels portent les opérations.

### `post_migrate`

#### `django.db.models.signals.post_migrate`

Envoyé à la fin des commandes [`migrate`](/fr/5.0/ref/django-admin/#django-admin-migrate) (même si aucune migration n’est effectuée) et [`flush`](/fr/5.0/ref/django-admin/#django-admin-flush). Il n’est pas émis pour les applications qui ne possèdent pas de module `models`.

Les gestionnaires de ce signal ne doivent pas effectuer de modification de base de données car cela pourrait provoquer l’échec de la commande d’administration [`flush`](/fr/5.0/ref/django-admin/#django-admin-flush) si elle s’exécute pendant la commande [`migrate`](/fr/5.0/ref/django-admin/#django-admin-migrate).

Paramètres envoyés avec ce signal :

**`sender`**

  Une instance [`AppConfig`](/fr/5.0/ref/applications/#django.apps.AppConfig) de l’application qui vient d’être installée.

**`app_config`**

  Identique à `sender`.

**`verbosity`**

  Indique la quantité d’informations que `manage.py` affiche à l’écran. Voir l’option [`--verbosity`](/fr/5.0/ref/django-admin/#cmdoption-verbosity) pour plus de détails.

  Les fonctions à l’écoute de [`post_migrate`](#django.db.models.signals.post_migrate) devraient ajuster ce qu’elles affichent en fonction de la valeur de ce paramètre.

**`interactive`**

  Si `interactive` vaut `True`, il est tout à fait possible de demander à l’utilisateur de saisir des informations sur la ligne de commande. Si `interactive` vaut `False`, les fonctions à l’écoute de ce signal ne doivent pas du tout interroger l’utilisateur.

  Par exemple, l’application [`django.contrib.auth`](/fr/5.0/topics/auth/#module-django.contrib.auth) ne demande les informations de création du super-utilisateur que lorsqu”`interactive` vaut `True`.

**`stdout`**

  Un objet de type flux vers lequel sera redirigée la sortie verbeuse.

**`using`**

  L’alias de base de données utilisé pour la synchronisation. La valeur par défaut correspond à la base de données `default`.

**`plan`**

  Le plan de migration utilisé pour l’exécution des migrations. Même si le plan ne fait pas partie de l’API publique, sa présence sert aux rares cas où il est nécessaire de connaître le plan. Un plan est une liste de tuples binaires avec le premier élément comme instance d’une classe de migration et le second élément indiquant si la migration a été défaite (`True`) ou appliquée (`False`).

**`apps`**

  Une instance de [`Apps`](/fr/5.0/ref/applications/#django.apps.apps) contenant l’état du projet après l’exécution des migrations. Elle devrait être utilisée en lieu et place du registre global [`apps`](/fr/5.0/ref/applications/#django.apps.apps) pour récupérer les modèles sur lesquels portent les opérations.

Par exemple, il est possible d’inscrire une fonction de rappel dans une classe [`AppConfig`](/fr/5.0/ref/applications/#django.apps.AppConfig) comme ceci :

```
from django.apps import AppConfig
from django.db.models.signals import post_migrate

def my_callback(sender, **kwargs):
    # Your specific logic here
    pass

class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)
```

> **Note**
>
> Si vous fournissez une instance [`AppConfig`](/fr/5.0/ref/applications/#django.apps.AppConfig) comme paramètre `sender`, contrôlez bien que le signal est inscrit dans la méthode [`ready()`](/fr/5.0/ref/applications/#django.apps.AppConfig.ready). Des instances `AppConfig` sont recréées pour les tests qui fonctionnent avec un réglage [`INSTALLED_APPS`](/fr/5.0/ref/settings/#std-setting-INSTALLED_APPS) modifié (comme quand les réglages sont temporairement surchargés) et de tels signaux doivent alors être connectés pour chaque nouvelle instance de `AppConfig`.

## Signaux de requête et de réponse

Signaux envoyés par le système de base lors du traitement d’une requête.

> **Warning**
>
> Les signaux peuvent rendre le code plus difficile à maintenir. Considérez l’utilisation d’un [intergiciel](/fr/5.0/topics/http/middleware/) avant d’utiliser des signaux de requête/réponse.

### `request_started`

#### `django.core.signals.request_started`

Envoyé lorsque Django commence à traiter une requête HTTP.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de gestion – par ex. `django.core.handlers.wsgi.WsgiHandler` – qui est chargée de la requête.

**`environ`**

  Le dictionnaire `environ` fourni à la requête.

### `request_finished`

#### `django.core.signals.request_finished`

Envoyé lorsque Django a terminé l’envoi d’une réponse HTTP à un client.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe de gestion, comme ci-dessus.

### `got_request_exception`

#### `django.core.signals.got_request_exception`

Ce signal est envoyé chaque fois que Django rencontre une exception lors du traitement d’une requête HTTP entrante.

Paramètres envoyés avec ce signal :

**`sender`**

  Inutilisé (toujours `None`).

**`request`**

  L’objet [`HttpRequest`](/fr/5.0/ref/request-response/#django.http.HttpRequest).

## Signaux de test

Ces signaux ne sont envoyés que lors du [fonctionnement des tests](/fr/5.0/topics/testing/overview/#running-tests).

### `setting_changed`

#### `django.test.signals.setting_changed`

Ce signal est envoyé lorsque la valeur d’un réglage a été modifiée par le gestionnaire de contexte `django.test.TestCase.settings()` ou le décorateur/gestionnaire de contexte [`django.test.override_settings()`](/fr/5.0/topics/testing/tools/#django.test.override_settings).

En fait, il est envoyé deux fois : lorsque la nouvelle valeur est appliquée (« setup ») et lorsque la valeur originale est restaurée (« teardown »). Utilisez le paramètre `enter` pour distinguer entre les deux cas.

Vous pouvez aussi importer ce signal à partir de `django.core.signals` pour éviter de l’importer à partir de `django.test` dans un contexte ne concernant pas les tests.

Paramètres envoyés avec ce signal :

**`sender`**

  Le gestionnaire des réglages.

**`setting`**

  Le nom du réglage.

**`valeur`**

  La valeur du réglage après la modification. Pour les réglages qui n’existent initialement pas, durant la phase de « teardown », `value` vaut `None`.

**`enter`**

  Une valeur booléenne ; `True` si le réglage doit être appliqué, `False` s’il doit être restauré.

### `template_rendered`

#### `django.test.signals.template_rendered`

Envoyé lorsque le système de test produit un gabarit. Ce signal n’est pas émis pendant les opérations normales d’un serveur Django, il n’est disponible que durant les tests.

Paramètres envoyés avec ce signal :

**`sender`**

  L’objet [`Template`](/fr/5.0/ref/templates/api/#django.template.Template) qui a été produit.

**`template`**

  Identique à `sender`

**`context`**

  L’objet [`Context`](/fr/5.0/ref/templates/api/#django.template.Context) avec lequel le gabarit a été produit.

## Adaptateurs de base de données

Signaux envoyés par l’adaptateur de base de données lorsqu’une connexion à la base de données est initiée.

### `connection_created`

#### `django.db.backends.signals.connection_created`

Envoyé lorsque l’adaptateur de base de données crée la connexion initiale à la base de données. C’est particulièrement utile si vous avez besoin d’envoyer des commandes post connexion au moteur SQL.

Paramètres envoyés avec ce signal :

**`sender`**

  La classe d’adaptation de la base de données – c’est-à-dire `django.db.backends.postgresql.DatabaseWrapper` ou `django.db.backends.mysql.DatabaseWrapper`, etc.

**`connection`**

  La connexion de base de données qui a été ouverte. Cela peut être utilisé dans une configuration à plusieurs bases de données pour différencier les signaux de connexion de différentes bases de données.