Django email backends :
quel mode d'envoi pour quel usage
Django fournit plusieurs email backends prêts à l'emploi — SMTP, console, fichier, mémoire et dummy — chacun adapté à un usage précis, de la production aux tests automatisés.
Django ne se contente pas d’un unique mode d’envoi d’e-mails : il propose plusieurs email backends prêts à l’emploi, chacun taillé pour un contexte précis. Le mode retenu se choisit d’un seul réglage, EMAIL_BACKEND, dans les settings du projet.
Un même code d’envoi, cinq comportements possibles : toute la différence tient au backend que vous activez dans les settings.
Django livre cinq backends sous django.core.mail.backends. En production, le backend SMTP achemine réellement les messages via un serveur d’envoi — c’est l’unique choix viable. Pour le développement, console affiche les e-mails dans le terminal, fichier les enregistre sur disque. Pour les tests, la mémoire stocke les messages dans django.core.mail.outbox, et dummy neutralise les envois sans rien faire.
Pour le fonctionnement interne, consultez la page dédiée au email backend. Ce système rappelle le paramètre AUTHENTICATION_BACKENDS, autre couche configurable de Django.
Un projet Django à cadrer ? Contactez Scornidigital, studio web à Gembloux : devis création site web ou 0476 07 23 28.
Notions liées.
Le réseau de notions autour de cette fiche — chaque entrée renvoie vers sa propre définition.
Le concept d'email backend
Comment Django expédie un e-mail, en principe.
Django comme back-end
Le rôle serveur global du framework.
Le réglage AUTHENTICATION_BACKENDS
Un autre paramètre à backends multiples.
Développement back-end en Python
Le contexte serveur plus large.
Le back-end, côté serveur
Les fondamentaux du développement serveur.
Ce qu'on nous demande souvent.
Une question qui n'est pas ici ? Écrivez-nous : on répond en clair, sans jargon, sous 24 h.
Poser votre questionQuels email backends Django propose-t-il ?
Django fournit plusieurs modes prêts à l'emploi : le backend SMTP pour l'envoi réel via un serveur d'e-mails, le backend console qui affiche les messages dans le terminal, le backend fichier qui les écrit sur disque, le backend en mémoire qui les conserve le temps de l'exécution, et le backend dummy qui n'envoie rien du tout.
Chacun répond à un besoin d'environnement différent.
Lequel utiliser en production ?
Le backend SMTP, sans hésiter. C'est le seul qui achemine réellement les e-mails vers les boîtes de vos utilisateurs, en se connectant à un serveur d'envoi.
Les autres modes sont conçus pour le développement ou les tests et n'expédient rien vers l'extérieur.
À quoi servent les backends console et fichier ?
Ils facilitent le développement. Le backend console affiche chaque e-mail dans le terminal, pour vérifier son contenu sans rien envoyer.
Le backend fichier fait la même chose mais enregistre les messages dans des fichiers, ce qui permet de les relire tranquillement plus tard. Aucun des deux ne contacte de vraie boîte de réception.
Quand utiliser le backend en mémoire ?
Principalement pour les tests automatisés.
Ce mode garde les messages envoyés dans une liste accessible pendant l'exécution, ce qui permet de vérifier, dans un test, qu'un e-mail a bien été déclenché et qu'il contient les bonnes informations, sans jamais rien expédier réellement.
Et le backend dummy, à quoi bon ?
Le backend dummy ignore purement et simplement les envois : il accepte les appels sans rien faire. C'est utile quand on veut désactiver totalement l'e-mail dans un environnement donné, tout en laissant le code d'envoi en place.
Il évite de conditionner chaque appel par un test, en neutralisant la couche d'envoi d'un seul réglage.