Django 6.1 est sorti

Django 6.1 est sorti le 5 août 2026. Cette version prend en charge Python 3.12, 3.13 et 3.14, et prend en charge 3.15 depuis la 6.1.3, sortie le 3 novembre 2026. Elle apporte un contrôle fin du chargement des champs, des suppressions déléguées à la base et une nouvelle configuration des e-mails.

Les nouveautés principales

Modes de récupération des champs

La récupération à la demande d’un champ non chargé devient configurable. Trois modes existent :

FETCH_ONE (par défaut) : ne charge le champ que pour l’instance courante, comme avant.
FETCH_PEERS : charge le champ pour toutes les instances issues du même QuerySet, à la manière d’un prefetch_related() à la demande.
FETCH_RAISE : lève FieldFetchBlocked, pratique pour traquer les requêtes involontaires.

from django.db import models

books = Book.objects.fetch_mode(models.FETCH_PEERS)
for book in books:
    print(book.author.name)

Avec FETCH_PEERS, cette boucle n’exécute que deux requêtes : une pour les livres, une pour les auteurs.

Suppression gérée par la base

ForeignKey.on_delete accepte trois nouvelles options qui s’appuient sur la clause SQL ON DELETE : DB_CASCADE, DB_SET_NULL et DB_SET_DEFAULT. Django ne charge plus les objets avant de les supprimer, ce qui est plus efficace. En contrepartie, DB_CASCADE ne déclenche ni pre_delete ni post_delete.

Le réglage `MAILERS`

Le nouveau réglage MAILERS configure plusieurs backends d’e-mail avec leurs propres options.

MAILERS = {
    "default": {
        "BACKEND": "django.core.mail.backends.smtp.EmailBackend",
        "OPTIONS": {"host": "smtp.example.com", "use_tls": True},
    },
    "marketing": {
        "BACKEND": "example.third.party.EmailBackend",
        "OPTIONS": {"region": "africa-1"},
    },
}

On choisit un mailer avec le nouvel argument using des fonctions d’envoi, ou avec mail.mailers[alias]. MAILERS n’est pas activé par défaut. Il remplacera EMAIL_BACKEND et les réglages EMAIL_* dans Django 2028, qui sont dès maintenant dépréciés, tout comme mail.get_connection().

Autres nouveautés

Admin : la vue de connexion redirige vers next pour un utilisateur déjà authentifié, action() gagne les arguments location et description_plural, et delete_confirmation_max_display tronque les longues listes d’objets.
Authentification : les itérations PBKDF2 par défaut passent de 1 200 000 à 1 500 000.
CSP : nouvelle balise de gabarit csp_nonce_attr et nouvelle vérification security.W027.
Modèles : expression JSONNull, fonctions UUID4 et UUID7, QuerySet.totally_ordered, et agrégats BitAnd, BitOr et BitXor désormais disponibles hors PostgreSQL.
Tâches : task() accepte des **kwargs transmis à la task_class du backend, et Task comme TaskResult sont sérialisables avec pickle.

Changements incompatibles

Les notes listent de nombreux changements incompatibles. Les plus susceptibles de toucher un projet :

Support abandonné pour PostgreSQL 14 (PostgreSQL 15 minimum), MySQL antérieur à 8.4, MariaDB antérieur à 10.11 et SQLite antérieur à 3.37.0.
Les alias SELECT, de tables et de JOIN sont désormais toujours cités. Comme les alias cités respectent la casse, le SQL brut (RawSQL) qui référence des alias à casse mixte peut demander un ajustement.
union(), difference() et intersection() lèvent DatabaseError quand un champ de Options.ordering n’est pas sélectionné par values() ou values_list(). Appelez order_by() sans argument après la combinaison.
first() et last() ne trient plus par clé primaire quand l’ordre du QuerySet a été effacé par order_by() sans argument.
Envoi d’e-mails : fournir fail_silently=True, auth_user ou auth_password avec un connection lève TypeError, et EmailMessage.message() lève ValueError si Bcc figure dans les en-têtes (utiliser l’argument bcc).
Sous ASGI, RemoteUserMiddleware ne préfixe plus HTTP_ pour chercher des valeurs personnalisées dans request.META.
Les versions jusqu’ici prévues comme Django 7.0 et 7.1 deviennent Django 2028 et 2029 (versionnage calendaire). Les classes d’avertissement de dépréciation suivent : RemovedInDjango70Warning devient RemovedInDjango2028Warning, ce qui compte si vos filtres d’avertissements les nomment.
La valeur par défaut de SIGNED_COOKIE_LEGACY_SALT_FALLBACK passe à False : les cookies signés avec l’ancienne dérivation du sel sont refusés. Remettez-la à True pour continuer à les accepter.
Les clés de cache qui varient selon des arguments (cache_page(), balise cache) changent : la première requête après la mise à jour est un défaut de cache.
Une base64 invalide lève une erreur dans MultiPartParser et dans DatabaseCache, au lieu d’être ignorée silencieusement.
Fonctionnalités retirées : paramètre all de staticfiles.finders.find() (remplacé par find_all), paramètre ordering des agrégats PostgreSQL ArrayAgg, JSONBAgg et StringAgg (remplacé par order_by), replis sur request.user dans login() et alogin().

Dépréciations à connaître

select_related() sans argument : préciser les champs ou utiliser FETCH_PEERS.
values_list(flat=True) sans nom de champ : passer un champ explicite, par exemple values_list("pk", flat=True).
None pour désigner un null JSON de premier niveau dans les requêtes JSONField : utiliser JSONNull.
transaction.savepoint() : utiliser savepoint_create().
Les doubles points dans les variables de gabarit ({{ book..title }}).

À retenir

Django 6.1 rend le chargement des champs et la suppression plus maîtrisables, et prépare la sortie de EMAIL_BACKEND avec MAILERS. Avant de migrer, relisez les changements incompatibles, en particulier la citation des alias SQL, les bases de données minimales et les dépréciations qui disparaîtront avec Django 2028.