Nouvelles fonctionnalités de Django 6.0

• La version Django 6.0, qui fête son 20e anniversaire, est une sortie majeure qui améliore massivement des domaines clés comme les templates, les tâches en arrière-plan, la sécurité et les emails.
• La fonction Template partials facilite la réutilisation du code au sein des templates, et l'intégration avec des outils comme htmx a été renforcée.
• Le framework Tasks a été ajouté pour exécuter des travaux en arrière-plan en dehors du cycle de requête-réponse HTTP.
• La Content Security Policy (CSP) est intégrée par défaut, ce qui simplifie la protection contre les attaques par injection de contenu comme le XSS.
• La modernisation de l'API email, les améliorations de l'ORM et l'extension des clés primaires améliorent grandement l'expérience développeur et la scalabilité.

---

Vue d'ensemble de Django 6.0

• Django 6.0 est la nouvelle version du framework web Python, qui poursuit 20 ans d'évolution.
• Les changements principaux sont centrés sur quatre blocs clés : templates, tâches en arrière-plan, sécurité et traitement des emails.
• Plusieurs contributeurs de la communauté ont participé, et les améliorations majeures sont récapitulées d'après les notes de release officielles.

Outil django-upgrade

• Lors d'une montée de version d'un projet existant de Django 5.2 ou inférieur, l'outil django-upgrade permet une conversion automatique du code.
• Il inclut 5 fixers automatiques liés à Django 6.0 et résout automatiquement certains avertissements.

Template partials

• La fonctionnalité définition de partie de template ({% partialdef %}) a été ajoutée pour réduire la duplication de code dans les templates et permettre la réutilisation.
  • Un partial défini dans le même template peut être appelé plusieurs fois.
  • L'option inline permet de le rendre en même temps qu'au moment de sa définition.
• La fonction de rendu partiel permet de rendre indépendamment un seul partial.
  • Dans l'exemple, htmx est utilisé pour actualiser périodiquement la partie view_count.
  • En ajoutant #partial_name à l'URL, seul un fragment précis peut être rendu.
• Cette fonctionnalité a été intégrée à Django via un projet Google Summer of Code et provient du package existant django-template-partials.

Framework Tasks

• Django a ajouté un framework Tasks pour l'exécution de tâches en arrière-plan.
  • Possibilité d'exécuter du code en dehors du cycle de requête-réponse HTTP.
  • Utilisable pour des tâches asynchrones comme l'envoi d'emails, le traitement de données ou la génération de rapports.
• Définir une tâche avec le décoreur @task, l'enregistrer dans une file avec Task.enqueue().
• Les backends fournis par défaut sont ImmediateBackend et DummyBackend à destination du développement, et l'utilisation de DatabaseBackend du package django-tasks permet une exécution basée sur une base SQL.
• Exécuter un worker avec la commande db_worker, et vérifier l'état via les logs.
• Cette fonctionnalité provient d'une idée lancée dans Wagtail et a été intégrée à Django après la proposition DEP 0014.

Support de Content Security Policy (CSP)

• Django 6.0 prend en charge nativement la norme CSP pour renforcer la défense contre des attaques d'injection de contenu comme le XSS.
  • Ajouter ContentSecurityPolicyMiddleware à MIDDLEWARE pour l'activer.
  • Les paramètres SECURE_CSP et SECURE_CSP_REPORT_ONLY permettent de configurer la politique.
• Une sécurité basée sur le nonce est intégrée, ce qui permet d'ajouter l'attribut nonce="{{ csp_nonce }}" aux balises <script> et <style>.
  • Un nonce aléatoire est généré à chaque requête et seules les ressources de confiance sont exécutées.
• Le CSP, proposé en 2004, était implémenté via le package django-csp et devient officiellement intégré dans cette version.

Mise à jour de l'API email

• La logique d'email de Django est passée à l'API email moderne de Python 3.6.
  • Elle utilise en interne la classe email.message.EmailMessage.
  • Les interfaces existantes send_mail() et EmailMessage restent inchangées.
• La nouvelle API offre notamment une réduction des bugs, une meilleure sécurité et une amélioration du traitement des pièces jointes inline.
• Avec l'objet MIMEPart, il est simple d'ajouter des pièces jointes inline comme des images dans le corps HTML.
• Cette modification a été proposée en 2024 et fusionnée après 8 mois de développement.

Restriction des arguments positionnels de l'API email

• Dans l'API django.core.mail, certains paramètres sont désormais acceptés uniquement en arguments nommés.
  • Si des paramètres optionnels comme fail_silently sont passés positionnellement, un avertissement est affiché.
  • C'est une mesure destinée à améliorer la lisibilité et la maintenabilité.
• Correction automatique possible via le fixer mail_api_kwargs de django-upgrade.

Extension de l'import automatique dans le shell

• La fonctionnalité d'import automatique des modèles de Django 5.2 est étendue, avec import automatique de settings, connection, models, functions, timezone.
• La liste des imports automatiques est visible avec ./manage.py shell -v 2.
• Cela améliore la commodité de développement et réduit le code répétitif.

Amélioration de l'ORM : mise à jour dynamique des champs lors de save()

• Les champs GeneratedField ou basés sur des expressions sont mis à jour automatiquement après save().
  • Sur les DB supportant la clause RETURNING (SQLite, PostgreSQL, Oracle), la mise à jour est immédiate.
  • Sur MySQL et MariaDB, elle est effectuée en chargement différé.
• Il est possible d'utiliser immédiatement la valeur la plus récente sans requête supplémentaire, ce qui améliore l'efficacité.

Fonction d'agrégation StringAgg universelle

• La fonction d'agrégation StringAgg est disponible sur tous les backends de bases de données.
  • Elle renvoie une chaîne obtenue en concaténant les valeurs avec un séparateur (delimiter).
  • Fonctionalité qui était auparavant spécifique à PostgreSQL, elle est désormais accessible directement depuis django.db.models.
• Le séparateur peut être spécifié via l'expression Value().

BigAutoField par défaut

• La valeur par défaut de DEFAULT_AUTO_FIELD a été changée en BigAutoField.
  • Utilisation d'une clé primaire d'entiers 64 bits pour prévenir la exhaustion des clés primaires.
  • Sur les nouveaux projets, l'application est automatique sans configuration supplémentaire.
• La configuration introduite par Django 3.2 est simplifiée, ce qui réduit la surcharge de configuration.

Améliorations du template

• La variable forloop.length a été ajoutée pour accéder à la longueur totale d'une boucle.
  • Utilisation sous la forme {{ forloop.counter }}/{{ forloop.length }}.
• Le tag template querystring est amélioré.
  • Ajout automatique de ? quand le mapping est vide, pour garantir une cohérence de comportement des liens.
  • Support de la fusion de plusieurs arguments de mapping pour faciliter la combinaison des paramètres de requête.

Conclusion

• Django 6.0 a rassemblé 174 contributeurs, avec de nombreuses optimisations et corrections de bugs incluses.
• La montée de version améliore globalement la sécurité, la maintenabilité et l'expérience développeur (DX).
• Consultez les notes de release officielles pour les changements supplémentaires.

[GN⁺]

Commentaires sur Hacker News

• Cela fait quelques années que j’utilise Django de façon intermittente au travail. Globalement, j’aime bien, mais l’ORM reste difficile à appréhender
  J’ai fini par comprendre que Django est un framework très prescriptif et qu’il faut suivre la « manière Django ».
  Le problème, c’est que je dois gérer plusieurs bases de données pour différentes unités métier, et je galère à chaque fois à m’adapter à leurs particularités.
  Au final, je désactive managed, j’importe le schéma avec inspectdb, puis je supprime manuellement les tables que je ne veux pas exposer sur le web.
  Pour une nouvelle web app, Django reste malgré tout le meilleur choix

  • D’accord. Mais le workflow de migration de base de données laisse encore à désirer
    Django ne stocke pas l’état du schéma avec le code, donc il doit déduire l’état actuel à chaque exécution d’une commande DB.
    Définir l’état de la base via le code des modèles a des limites intrinsèques.
    Je préfère de loin l’approche de Rails, avec des migrations construites à partir de commandes DB explicites, puis les modèles par-dessus
  • Je me demande si tu utilises la prise en charge multi-base de données de Django
  • J’ai essayé Aldjemy sur un petit projet, et ça gérait plutôt bien les combinaisons de requêtes complexes qui sont difficiles avec l’ORM de Django
  • J’utilise Django depuis plus de 10 ans, et l’ORM est « correct » sans plus. Il y a eu un temps où certains voulaient passer à SQLAlchemy, mais ça n’en valait pas la peine.
    L’interface des managers est déroutante au début, mais les outils de migration sont vraiment excellents
  • Configurer des views ou des materialized views via l’ORM peut énormément aider les performances.
    On profite à la fois de la souplesse du tuning SQL et de la praticité de Django.
    Il ne faut simplement pas oublier de les créer dans les scripts de migration

• J’aime beaucoup le fait que Django s’améliore régulièrement à chaque release, petit à petit.
  La version 6.0 en particulier est intéressante, avec beaucoup de fonctionnalités utiles.
  Dire qu’une technologie fiable est ennuyeuse, c’est faux. C’est exactement comme ça qu’elle devrait évoluer

  • Moi aussi, je l’utilise depuis l’époque pré-1.0 et je l’aime toujours autant.
    J’habite maintenant près de l’endroit où Django est né.
    Au passage, je cherche un emploi depuis hier, donc si vous cherchez un développeur Django expérimenté, contactez-moi ([e-mail])

• Le code et les articles de blog écrits par Adam valent toujours la peine d’être lus.
  J’ai hâte de voir comment le framework de tasks va évoluer.
  Cela dit, je trouve un peu dommage que l’excellent Django-Q2 ait été mentionné à côté de Celery

  • Auteur ici. Merci pour le compliment, et Celery n’a été mentionné que parce qu’il est populaire ;)
  • Celery n’est pas parfait, mais c’est la meilleure option.
    Il a beaucoup de bugs, mais sa base d’utilisateurs est si large qu’il est rare d’être le premier à rencontrer un problème.
    J’ai traité de manière fiable des dizaines de millions de messages par jour avec le duo Celery + RabbitMQ.
    Ça reste une solution à envisager en premier
  • J’utilise Celery depuis des années, donc je suis curieux : qu’est-ce qui posait problème, et en quoi Django Q2 améliore les choses ?
    Sur d’autres stacks, on utilise aussi Kafka, mais c’est un cas d’usage d’un tout autre niveau
  • Je me demande pourquoi certains disent que Celery est « horrible »

• J’utilise Django depuis 5 ou 6 ans ; son côté « batteries included » est indéniable, mais dans l’ensemble il me paraît lourd

• La fonctionnalité de template partials a l’air intéressante.
  L’une des raisons du succès de React, c’est la réutilisabilité du code, et Django semble aller dans cette direction

  • Le cœur de la réutilisabilité et de la composabilité de React, ce ne sont pas les templates, c’est le fait que tout est une fonction
  • Cette fonctionnalité est particulièrement précieuse avec HTMX. HTMX a besoin de beaucoup de templates partiels
  • React n’apporte pas de simples templates, mais des composants qui encapsulent l’état
  • J’ai moi aussi testé Django 6 en utilisant des partials sur mon blog
    Un exemple est visible dans ce code
  • Je suis surpris que Django n’ait ajouté une telle fonctionnalité qu’en 2025

• J’utilise surtout Odoo, mais j’ai aussi un peu touché à Django et Celery.
  En tant que gros utilisateur du module OCA queue d’Odoo,
  je me suis toujours demandé pourquoi Django n’exploitait pas la fonctionnalité LISTEN/NOTIFY de Postgres.
  C’est peut-être simplement parce que je connais mal l’écosystème Django

• Template Partials et HTMX donnent l’impression d’être la version Django de Rails View Components + Stimulus.
  Je suis aussi ravi de voir que la fonctionnalité Tasks bénéficie d’un support officiel

  • Le rendu des partials dans Rails peut se voir dans le guide officiel
  • Je me demande s’il faut aussi utiliser django-tasks pour faire tourner Tasks en production

• J’utilise Django depuis l’époque 1.x, avant l’ORM.
  Je trouve vraiment étonnant que l’exécution de tasks ne soit ajoutée que maintenant.
  Ce n’est pas une critique, juste une évolution intéressante

  • Au contraire, je trouve ça rafraîchissant. Django n’ajoute pas les fonctionnalités dans la précipitation, il les implémente correctement.
    Chaque fonctionnalité n’est intégrée qu’après avoir été suffisamment éprouvée, avec un fort accent sur les LTS et la stabilité de l’API.
    Grâce à ça, quand une nouvelle version sort, on n’a presque jamais à réécrire toute l’application
  • En réalité, Django incluait déjà un ORM à partir de la version 0.95.
    C’était simple à l’époque, mais on pouvait déjà se passer de SQL brut pendant assez longtemps

• La discussion continue aussi dans ce fil

• En utilisant Django avec HTMX, j’ai trouvé les templates orientés composants tellement peu pratiques
  que j’ai créé moi-même une bibliothèque de composants en Python, Compone.
  Elle fonctionne non seulement avec Django, mais avec tous les frameworks web Python, et offre une expérience de développement bien plus agréable