Test de Django : en vaut-il encore la peine ?

Django a livré deux versions majeures et réécrit tout son rythme de publication en huit mois, entre décembre 2025 et août 2026.

Tout cela est arrivé à un framework dont la réputation n'a guère bougé depuis 2023 : le framework Python tout équipé, productif, directif, uniquement synchrone, et qui perd du terrain face à FastAPI. L'étiquette « synchrone » est périmée, et l'histoire de sa popularité est plus compliquée que ne le laissent croire les chiffres en gros titres.

Voici donc ma position sur la question de savoir si Django en vaut encore la peine en 6.1 : un verdict avec une note, les types de projets auxquels il convient, et ceux pour lesquels FastAPI est désormais le meilleur choix.

La version courte

Oui, sous conditions. Django 6.1 reste le meilleur choix par défaut quand l'admin, l'authentification, les formulaires et l'ORM constituent l'essentiel du travail, et l'écart sur l'asynchrone s'est assez réduit pour que « uniquement synchrone » ne soit plus une raison de l'écarter. Il est inadapté à une seule API à forte concurrence sans interface d'administration. 4 sur 5.

• C'est l'ensemble que vous achetez. L'ORM, les migrations, l'authentification par session avec permissions, une couche formulaires et une admin générée arrivent ensemble et déjà intégrés, pas sous forme de cinq bibliothèques plus les jointures entre elles.
• Les tâches de fond sont le point faible. Le framework Tasks de Django 6.0 vous donne un décorateur et un appel de mise en file, mais pas de worker : Celery ou un équivalent reste donc une décision qui vous revient.
• L'asynchrone est bien meilleur et manifestement inachevé. Django prend en charge les vues asynchrones et les appels ORM asynchrones, mais les transactions ne fonctionnent pas en mode asynchrone. Sous WSGI, les vues asynchrones peuvent encore effectuer des E/S asynchrones concurrentes au sein d'une requête, mais vous ne bénéficiez pas d'une pile de requêtes entièrement asynchrone : les requêtes de longue durée et une forte concurrence de connexions exigent ASGI.
• Planifier au-delà de 2027 est devenu plus simple. À partir de janvier 2028, Django publie une version majeure par an, chacune avec trois ans de support, et l'étiquette « LTS » disparaît puisque chaque version bénéficie désormais de cet engagement.
• Adapté aux produits riches en administration et en CRUD, et aux petites équipes. Inadapté à une seule API à haut débit ou en streaming, sans admin ni formulaires, où FastAPI est le choix le plus naturel.

Comment j'ai construit ce test : Il s'agit d'une évaluation de Django 6.1 fondée sur les notes de version et la documentation du projet lui-même, l'annonce de gouvernance de la Django Software Foundation d'août 2026, les enquêtes développeurs JetBrains/PSF 2024 et Django 2025, ainsi que des praticiens nommément cités qui écrivent publiquement sur leur propre expérience en production. Je n'ai pas mené d'essai en production sur plusieurs semaines pour cet article, et il n'y a aucun benchmark ici : rien n'a été testé en charge. Django est gratuit et sous licence BSD, et je n'ai aucun lien avec le projet.

Qu'est-ce qui a réellement changé dans Django depuis 2025 ?

Django 6.0 est sorti le 3 décembre 2025 avec un framework Tasks intégré et d'autres ajouts au cœur du framework. L'interface ORM asynchrone est plus ancienne : Django 4.1 a introduit les opérations QuerySet asynchrones en 2022. Django 6.1 est devenu la version stable actuelle le 5 août 2026. Puis, le 10 août 2026, le projet a annoncé une version majeure par an à partir de janvier 2028, trois ans de support pour chaque version, et la fin de l'étiquette LTS.

Les notes de version de la 6.1 confirment que la 6.1 prend en charge Python 3.12, 3.13 et 3.14, avec un support principal qui s'arrête en avril 2027 et un support étendu en décembre 2027.

Les numéros de version changent avec le reste. Ils portent l'année : Django 2028, puis Django 2029 (au moins, « vous êtes sur quelle version ? » devient plus facile à répondre). Les trois ans se décomposent en un an de corrections de bugs classiques puis deux ans de correctifs de sécurité et de perte de données, ce qui correspond à l'ancien sens de LTS, d'où la disparition de l'étiquette.

Cela laisse une fenêtre inconfortable pour un projet qui démarre aujourd'hui. Django 5.2 est l'actuelle LTS, prise en charge jusqu'en avril 2028. Django 6.1 est la version stable actuelle, mais son support étendu s'arrête en décembre 2027, soit environ quatre mois avant la fin de la fenêtre de support de Django 5.2 en avril 2028.

Donc : viser la fenêtre de support la plus longue revient à démarrer sur la 5.2. Vouloir le framework Tasks et les dernières fonctionnalités 6.x revient à démarrer sur la 6.1 et à accepter une mise à niveau plus tôt. Aucune des deux options n'est mauvaise, et ce choix inconfortable disparaît quand Django 6.2 LTS arrive en avril 2027.

Je vois ce changement de rythme comme un bon signe. Les projets en déclin étirent discrètement leurs promesses de support ; ils ne les restructurent pas en public avec un calendrier daté. Celui-ci a simplifié un engagement qu'il tenait déjà.

Ce que Django fait encore mieux que tout le reste

Démarrez un projet Django 6.1 et vous disposez d'une authentification par session fonctionnelle avec système de permissions, d'une couche formulaires qui valide et affiche, d'un système de migrations lié à vos modèles, de l'ORM et d'une admin générée, avant même d'écrire la moindre fonctionnalité. C'est tout l'argument, et c'est la partie de Django qui n'a pas eu besoin de changer.

La valeur ne tient pas à l'existence de ces briques. Elle tient au fait qu'elles ont été conçues les unes par rapport aux autres. Les mêmes permissions de modèle alimentent l'admin, et une modification de modèle génère la migration et met à jour le formulaire d'admin d'un même geste.

Assembler une couverture équivalente à partir de bibliothèques indépendantes finit par y arriver. Cela vous donne aussi une surface de maintenance permanente à chaque jointure, et c'est dans les jointures que vivent les bugs.

L'admin est un outil pour le personnel interne. La documentation de référence de l'admin indique que son usage recommandé se limite à un outil de gestion interne d'une organisation et qu'elle n'est pas destinée à servir de base à tout votre front-end. Les permissions de modèle déterminent ce que les utilisateurs internes peuvent faire une fois à l'intérieur, et entrer tout court exige is_staff. Prenez cela comme une contrainte, et c'en est une bonne : vous obtenez gratuitement un back-office interne compétent, et vous n'obtenez pas d'interface destinée aux clients, donc personne n'est tenté d'en livrer une.

Les réglages de sécurité par défaut sont l'autre moitié du même argument. La protection CSRF, le paramétrage des requêtes SQL via l'ORM, l'échappement XSS dans les templates et la protection contre le clickjacking sont actifs par défaut, plutôt que d'être des points qu'un développeur expérimenté doit penser à réclamer en revue. Une petite équipe hérite de choix faits par des gens qui ont lu dix ans de rapports de sécurité.

Reste l'âge. On le lit comme un handicap ; moi, j'y vois l'argument de l'écosystème. Django REST Framework existe et il est ennuyeux de la manière dont on veut qu'une infrastructure soit ennuyeuse.

Il en va de même pour les paquets matures qui répondent aux problèmes rencontrés au quatrième mois : filtrage, limitation de débit, backends de stockage, schémas multi-locataires, journaux d'audit. Et quand un problème est assez inhabituel pour qu'aucun paquet ne le couvre, il existe en général un fil de liste de diffusion vieux de quinze ans sur le sujet. Sur l'étendue, je ne crois pas que quoi que ce soit d'autre en Python s'en approche, et c'est cet axe qui fait qu'on choisit Django au départ.

Là où Django pèche

Django manque toujours d'un typage natif complet sur l'ensemble du framework, son rythme prudent laisse des trous dont l'expression « tout inclus » ne vous prévient pas, et le framework Tasks de la 6.0 n'a pas de worker. Voilà les trois manques en 6.1. Le trou du typage est celui qui vous agace au quotidien ; Tasks est celui qui change votre schéma d'architecture.

Vous assemblez encore l'essentiel du typage à partir d'outils tiers. django-stubs fournit des stubs de types ainsi qu'un plugin mypy dédié au comportement dynamique de Django. Sa documentation actuelle annonce une prise en charge complète de mypy et une prise en charge basique de pyright, pyrefly et ty. La situation est meilleure qu'avant, mais il s'agit toujours d'une couche de compatibilité séparée plutôt que d'un typage natif complet dans Django lui-même.

En venant d'un framework bâti autour des annotations de types, c'est une régression mesurable de l'expérience quotidienne dans l'éditeur.

Le rythme prudent est un coût autant qu'une vertu. Django ajoute les choses avec soin et tardivement, et c'est pour cela que le framework appris en 2019 est celui que vous savez lire aujourd'hui. C'est aussi pour cela que les piles s'arrêtent là où elles s'arrêtent : pas de couche WebSocket dans le cœur, pas d'ordonnanceur, aucun avis sur l'orchestration des tâches asynchrones. Franchissez l'une de ces lignes et vous rassemblez de nouveau les pièces vous-même.

Django 6 a-t-il encore besoin de Celery ?

Pas Celery en particulier. Le framework Tasks de Django 6.0 normalise la façon dont une tâche est définie et mise en file, mais il n'exécute pas lui-même le travail en attente. En production, il vous faut toujours un backend ou un processus worker qui exécute les tâches ; Celery est une option, pas une exigence du framework. Les notes de version de Django 6.0 sont franches sur la limite : Django gère la création et la mise en file des tâches mais ne fournit pas de mécanisme de worker, et l'exécution doit être prise en charge par une infrastructure externe, par exemple un processus ou un service distinct.

Ce que vous obtenez, c'est l'interface :

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) envoie la tâche vers un backend configuré. Les deux backends livrés avec la 6.0 sont destinés au développement et aux tests (donc pas celui que vous espériez). La planification, la récurrence, les tentatives et la durabilité sont toutes hors périmètre.

Kevin Renskers, développeur Django en activité, l'a formulé le plus nettement dans son test de Tasks:

Au lieu de cela, nous avons eu une abstraction sans implémentation.

Il a raison sur la forme. Je formulerais l'intention autrement. Dans le vote du Steering Council sur DEP 14, la proposition d'amélioration de Django à l'origine de la fonctionnalité, Simon Charette a soutenu que « cela devrait être quelque chose auquel des frameworks comme Celery et RQ viennent se brancher », et l'auteur de la proposition l'a décrite comme une interface pour workers d'arrière-plan plutôt que comme un moteur d'exécution. La critique juste n'est donc pas que Tasks est cassé. C'est qu'il est bien plus étroit que ce que « tout inclus » laissait espérer, et que le trou qu'il comble est le trou ennuyeux : le code de votre application peut mettre du travail en file sans importer une bibliothèque de file d'attente précise.

Prévoyez donc une file de tâches dans tout projet Django 6.1 qui a besoin de tentatives, de travaux planifiés ou de visibilité sur les échecs. C'est la même ligne budgétaire qu'avant la 6.0, et si vous espériez que cette version l'efface de votre schéma d'architecture, ce n'est pas le cas.

Si vous avez déjà décidé que Django convient et que vous préférez ne pas assembler la couche serveur depuis zéro, le VPS Django de Cloudzy vous donne un point de départ autogéré avec Django, Gunicorn, Nginx et PostgreSQL, plus un accès root quand vous avez besoin de Redis ou de Celery. Le serveur reste le vôtre à exploiter : vous sautez l'étape de la machine vide, pas la responsabilité opérationnelle.

LIRE

Comment installer Python sur un serveur VPS ? | un guide étape par étape

La prise en charge de l'asynchrone dans Django est-elle enfin suffisante ?

Assez bonne pour que « c'est uniquement synchrone » ne vous arrête plus, et pas assez bonne pour bâtir dessus une couche de données entièrement asynchrone. Les deux moitiés sont vraies en 6.1. Laquelle s'applique à vous dépend de ce que vous construisez et du fait que vous le serviez sous ASGI ou WSGI, car ce choix détermine si vous obtenez une pile de requêtes entièrement asynchrone et une gestion efficace des connexions de longue durée.

Le volet des capacités ne fait pas débat. Chaque méthode de QuerySet qui déclenche du SQL possède une variante asynchrone préfixée par a. La boucle async for fonctionne sur les QuerySets, et les API de base de données asynchrones incluent des méthodes de modèle comme asave() et des méthodes de QuerySet comme acreate(). Vous pouvez écrire une vue asynchrone qui attend des requêtes et des appels HTTP sortants concurrents sans passer par un wrapper de threadpool. Comparé au Django au sujet duquel la critique « uniquement synchrone » a été écrite, c'est un autre framework.

Ce qui décide du comportement, c'est le protocole de déploiement, pas la version du framework, et c'est justement le point que le forum de Django doit réexpliquer sans cesse. Le guide thématique sur l'asynchrone précise que, sous un serveur WSGI, les vues asynchrones s'exécutent dans leur propre boucle d'événements ponctuelle : vous pouvez donc utiliser les fonctionnalités asynchrones mais « vous n'obtiendrez pas les avantages d'une pile asynchrone ».

Servir des centaines de connexions sans threads Python, le streaming lent, le long-polling : tout cela exige ASGI. Même code, comportement de concurrence différent, et rien dans le framework ne vous dit lequel vous obtenez.

Cette confusion a la vie dure. Un utilisateur signant tomcypress a ouvert un fil sur le forum de Django demandant pourquoi des requêtes consécutives vers une vue asynchrone n'exécutaient pas toutes leur travail de fond, et l'habitué du forum KenWhitesell l'a orienté vers la boucle d'événements WSGI. Cet échange date de 2021 et rien n'y a changé en 6.1.

Et cette confusion est renforcée de l'extérieur. La page « avantages et inconvénients » de Django chez TechVidvan explique aux lecteurs que Django « n'est pas capable de gérer plusieurs requêtes en même temps », ce qui est faux pour Django 6.1 et représente le genre d'affirmation qui met fin à une évaluation avant qu'elle commence. La concurrence n'est pas quelque chose qui manque au framework : c'est quelque chose que le déploiement décide.

Le vrai point d'arrêt, ce sont les transactions, et la propre documentation asynchrone de Django le dit sans détour :

Les transactions ne fonctionnent pas encore en mode asynchrone. Si vous avez un morceau de code qui a besoin du comportement transactionnel, nous vous recommandons d'écrire ce morceau sous forme d'une seule fonction synchrone et de l'appeler avec sync_to_async().

La même page classe certaines parties clés du framework comme « non sûres en asynchrone » et les empêche de s'exécuter dans un contexte asynchrone, en levant SynchronousOnlyOperation si vous essayez. La forme d'une application Django 6.1 asynchrone est donc : vues asynchrones et lectures asynchrones, avec des îlots synchrones partout où les écritures ont besoin d'atomicité. Praticable, et ce n'est pas la même chose qu'un framework nativement asynchrone. Mon verdict sur cet axe : nettement meilleur, pas terminé, et un feu vert clair pour tout ce qui ne place pas la concurrence en premier.

FastAPI a-t-il fait de Django le mauvais choix par défaut ?

Pour une catégorie précise de projets, en croissance, oui. L'enquête 2024 auprès des développeurs Python de JetBrains et de la Python Software Foundation, recueillie en octobre et novembre 2024 auprès de plus de 30 000 participants, place FastAPI à 38 %, Django à 35 % et Flask à 34 % sur l'ensemble des répondants. Parmi ceux qui ont indiqué le développement web comme usage principal de Python, Django atteint 61 %, FastAPI 56 % et Flask 39 %.

Regardez bien cette question avant de l'emporter en réunion de planification, car elle est à choix multiples. On a demandé aux répondants quels frameworks ils utilisent, pas lequel ils ont choisi, et un développeur qui maintient un monolithe Django tout en écrivant des services FastAPI compte dans les deux. Ce ne sont pas des parts de marché exclusives, et personne ne détient ici 38 % d'un marché. Ce qu'elles montrent, c'est un signal partagé : FastAPI devançait Django sur l'ensemble des répondants, tandis que Django devançait encore FastAPI chez les répondants qui utilisent Python surtout pour le développement web.

L'enquête propre à Django ajoute un autre signal, venu de ceux qui utilisent déjà le framework. L'enquête 2025 auprès des développeurs Django, menée par la Django Software Foundation avec JetBrains sur 4 655 réponses filtrées recueillies entre novembre 2024 et janvier 2025, relève 82 % de personnes écrivant du Django à titre professionnel, 77 % le désignant comme leur framework le plus utilisé, et 48 % passant à chaque version stable, contre 40 % un an plus tôt. Des répondants auto-sélectionnés : cela décrit donc la base d'utilisateurs actuelle plutôt que le marché. L'ampleur de l'usage et la profondeur de l'engagement sont deux signaux distincts, et le second chiffre de Django est plus sain que le premier.

Les endroits où FastAPI gagne sont plus étroits et plus nets que ne le suggère l'écart de l'enquête. Une surface d'API pilotée par les types, où vos modèles Pydantic sont la couche de validation et où le schéma OpenAPI généré est le contrat, bat Django plus une couche de sérialiseurs. FastAPI est nativement asynchrone au niveau de la requête, mais sa propre documentation est explicite : les opérations de chemin peuvent s'écrire des deux façons, et un gestionnaire ou une dépendance déclarés avec un simple def s'exécutent dans un pool de threads externe.

Et un service sans admin, sans formulaires et sans templates transporte les piles de Django comme du poids mort : vous payez pour les partis pris du framework et vous en utilisez un quart. Si c'est ce que vous construisez, l'engouement n'est pas du battage et vous devriez le suivre.

Qui devrait choisir Django ?

Optez pour Django en 6.1 quand l'admin, l'authentification, les formulaires et l'ORM représentent l'essentiel du travail à venir : outils internes, places de marché, SaaS de back-office. C'est aussi le bon choix pour une petite équipe qui a besoin que tout cela fonctionne dès le premier jour, et pour une équipe qui doit savoir dès maintenant à quoi ressemblera sa fenêtre de support en 2029.

Les produits pour lesquels les partis pris du framework couvrent l'essentiel du travail réel. Tout ce qui comporte une matrice de permissions et beaucoup de CRUD derrière une connexion. Ici, le fait que le framework fasse les choix structurels est l'intérêt et non un coût, parce que ces choix représentent l'essentiel de ce que vous auriez construit de toute façon.

Les petites équipes qui doivent être productives dès le premier jour. Avec trois développeurs et aucun ingénieur plateforme, une équipe se met à écrire des fonctionnalités pendant que l'autre se met à évaluer des bibliothèques d'authentification. À partir de là, l'écart se creuse.

Les équipes déjà sur Django qui planifient les trois prochaines années. Django 5.2 vous donne un socle pris en charge jusqu'en avril 2028, et le rythme annuel vous en donne un prévisible ensuite. Un horizon de support lisible vaut de l'argent au moment de planifier, et il est rare qu'on vous en tende un aussi clair.

Qui ne devrait pas choisir Django ?

Ne choisissez pas Django pour une API à haut débit ou en streaming sans admin derrière : FastAPI est le choix par défaut le plus net pour ce type de projet. Ne le choisissez pas s'il vous faut cette année un accès asynchrone aux données, transactions comprises, parce que la 6.1 ne l'a pas. Et ne le choisissez pas en comptant sur les piles pour exécuter vos tâches de fond.

Une seule API à haut débit ou en streaming, sans admin ni surface de formulaires. Presque rien de ce que Django fait bien n'est porteur pour ce type de projet : vous entretiendriez la structure d'un framework entier pour un service qui avait besoin d'un routeur et d'un validateur.

Les équipes qui ont besoin dès aujourd'hui d'un accès aux données entièrement asynchrone, transactions comprises. Django 6.1 ne prend pas en charge les transactions en mode asynchrone. Envelopper vos écritures dans sync_to_async() est un motif légitime, pas un contournement dont vous vous débarrasserez cette année, et là où c'est inacceptable, c'est un point bloquant et non une écorchure.

Les équipes qui lisent « tout inclus » comme couvrant l'exécution des tâches de fond. Tasks ne livre pas de worker. Si votre plan supposait que la 6.0 avait retiré la file d'attente de votre pile, il faut y remettre une file avant de vous engager sur le framework.

Choisir quel framework web apprendre en premier est une autre question, avec une autre réponse ; la FAQ ci-dessous en donne la version courte.

Savoir où Django s'arrête est ce qui rend son adoption sûre : les sorties ci-dessus sont visibles avant l'engagement plutôt que découvertes après.

Foire aux questions