Guide sur la fin de vie de Django : dates, risques et solutions en 2026

Principaux enseignements

• Les versions 3.2, 4.0, 4.1, 5.0 et 5.1 de Django ont toutes déjà atteint leur fin de vie – Django 4.2 est la dernière à avoir atteint ce statut.
• L'utilisation d'une version de Django en fin de vie ne provoque pas de problèmes immédiats, mais les vulnérabilités non corrigées et les non-conformités s'accumulent rapidement.
• Les entreprises n'ont pas à choisir entre une migration précipitée et une faille de sécurité ; TuxCare assure la correction continue des vulnérabilités pour ces versions de Django en fin de vie, aussi longtemps que le nécessite votre calendrier de migration.

Lorsque Django 4.2 a atteint sa fin de vie le 7 avril 2026, de nombreuses applications en production ont continué de fonctionner sans le moindre accroc – et c'est précisément là que réside le problème. La fin de vie (EOL), ou fin du support, n'entraîne pas de dysfonctionnement, mais signifie que le projet Django a officiellement cessé de publier des correctifs de sécurité. La version 4.2 se retrouve ainsi dans la même catégorie de vulnérabilité que les versions 3.2 (fin de vie en avril 2024), 4.0 (fin de vie en avril 2023), 4.1 (fin de vie en décembre 2023), 5.0 (fin de vie en avril 2025) et 5.1 (fin de vie en décembre 2025). Toute vulnérabilité découverte dans ces versions à partir de maintenant restera sans correctif – à moins que vous ne preniez vous-même des mesures pour y remédier.

Ce guide couvre tout ce que vous devez savoir sur la fin de vie (EOL) de Django, ce que cela implique concrètement en matière de sécurité et de conformité, ainsi que les pistes réalistes qui s'offrent aux équipes qui ne peuvent pas tout laisser tomber pour procéder à une mise à niveau majeure.

Qu'est-ce que la fin de vie (EOL) de Django ?

Chaque version de Django a une date d'expiration, après laquelle l'équipe chargée de la maintenance de Django cesse de s'en occuper : plus de mises à jour de sécurité, plus de corrections de bogues, plus rien. C'est ce qu'on appelle la fin de vie.

Votre application ne plantera pas soudainement lorsqu'une version atteindra sa fin de vie (EOL), mais en l'absence de correctifs du fournisseur, les risques de sécurité deviennent importants et s'accumulent au fil du temps. Par exemple, si un chercheur en sécurité découvre demain une vulnérabilité de type injection SQL dans Django 4.2, aucun correctif ne sera publié. La vulnérabilité sera documentée, un identifiant CVE lui sera attribué, et votre version restera exposée. Pour les organisations soumises à des obligations de conformité, cela entraîne automatiquement une non-conformité lors d'un audit, car votre environnement utilise un logiciel comportant des vulnérabilités CVE connues et non corrigées.

Cycle de publication de Django et calendrier de fin de vie

Django suit un calendrier de publication régulier : une nouvelle version est publiée tous les huit mois environ. Chaque version passe par deux phases de support de sécurité avant d'être retirée à la fin de son cycle de vie.

Versions standard (non LTS) bénéficient de huit mois de support actif, suivis de huit mois supplémentaires de support limité à la sécurité. Seize mois au total. Passé ce délai, elles atteignent leur fin de vie (EOL).

Versions LTS (support à long terme) fonctionnent différemment : elles bénéficient des mêmes huit mois de support actif, mais la phase dédiée uniquement à la sécurité s'étend sur vingt-huit mois, ce qui porte la durée totale du support à environ trois ans.

Si vous utilisez une version non LTS, votre délai est plus court que pour les versions LTS. Django 5.1, par exemple, a été publié en août 2024 et a atteint sa fin de vie (EOL) dès décembre 2025, soit environ seize mois plus tard. Les équipes qui n’ont pas effectué la mise à niveau pendant cette période utilisent désormais un logiciel qui n’est plus pris en charge.

Conseil de pro : La dernière version fonctionnelle d'une version majeure sera une version LTS. Basez toujours votre choix de version de Django sur une version LTS. La période de trois ans vous offre une marge de manœuvre réelle pour les mises à niveau prévues.

Voici l'état actuel des dernières versions du projet Django :

Les risques liés à la fin de vie de Django pour votre organisation

Utiliser une version de Django en fin de vie (EOL) ne constitue pas une urgence immédiate, contrairement à une faille de sécurité sur un site en ligne. Cependant, le profil de risque change radicalement dès que le support en amont prend fin – et il ne cesse de s'aggraver à mesure que vous restez sur une version obsolète.

Vulnérabilités de sécurité non corrigées

C'est une évidence, mais il vaut la peine de préciser à quoi cela ressemble concrètement.
Django a un historique CVE bien établi. Injection SQL via les méthodes QuerySet, déni de service par le biais d'entrées XML malveillantes, traversée de répertoires dans les commandes de modèles, injection dans les journaux via des chemins de requête non validés : il ne s'agit pas là de types d'attaques théoriques. Ce sont des schémas de vulnérabilité qui ont été mentionnés dans les avis de sécurité de Django lui-même, certains datant d’aussi récemment que 2025. Par exemple, CVE-2025-57833, CVE-2025-64460, CVE-2025-59682 et CVE-2025-48432.

Lorsque votre version atteint la fin de son cycle de vie (EOL), ces avis de sécurité continuent d'être publiés. Un identifiant CVE est toujours attribué, mais les correctifs ne sont fournis que pour les versions prises en charge. Votre version n'en bénéficie tout simplement pas.

Rien qu'en 2024 et 2025, plusieurs failles de sécurité très graves ont été corrigées dans les versions prises en charge, tandis que des branches en fin de vie telles que les versions 3.2.x et 5.0.x ont été explicitement signalées comme étant concernées, mais n'ont pas fait l'objet d'une évaluation dans plusieurs avis de sécurité récents.

Défauts de conformité et d'audit

Les logiciels en fin de vie posent un problème particulier en matière de conformité : il est difficile de prétendre que vos mesures de sécurité sont suffisantes lorsque le cadre sur lequel repose votre application ne bénéficie plus de mises à jour de sécurité.

La norme PCI DSS 6.3.3 exige que tous les composants du système soient protégés contre les vulnérabilités connues par l'installation des correctifs de sécurité appropriés. Les auditeurs SOC 2 considèrent de plus en plus les dépendances en fin de vie (EOL) comme une lacune dans les contrôles. La norme ISO 27001 impose aux organisations de gérer les vulnérabilités techniques ; l'utilisation de logiciels dont le support a pris fin constitue un manquement évident à cette exigence.

Évolution des écosystèmes et lacunes en matière de compatibilité

Les versions de Django en fin de vie n’existent pas en vase clos : elles s’inscrivent dans une pile technologique. Et cette pile évolue constamment. Python lui-même suit un cycle de publication. Python 3.8 et 3.9, sur lesquels reposaient Django 3.2 et 4.0, ne sont déjà plus pris en charge. La prise en charge de Python 3.10 prendra fin en octobre 2026. Les pilotes de bases de données, les bibliothèques d'authentification, les SDK cloud : tous finissent par cesser de prendre en charge les anciennes versions de Python et de Django. Il en résulte une pile qui devient de plus en plus difficile à maintenir, non pas parce que tout cesse de fonctionner d'un seul coup, mais parce que l'écart entre votre situation actuelle et l'évolution de l'écosystème ne cesse de se creuser.

Les conflits de dépendances qui semblent mineurs aujourd’hui ont tendance à s’accumuler jusqu’à ce que le système devienne un véritable cauchemar à maintenir. Une bibliothèque cesse de prendre en charge Django 4.2 dans sa prochaine version majeure. Un correctif de sécurité nécessite une version de Python que votre version de Django en fin de vie ne prend pas en charge. Il ne s’agit pas là de cas exceptionnels, mais bien de l’évolution normale de toute application qui ne suit pas le rythme de ses dépendances.

Alourdissement des charges d'entretien

Voici un élément qui n'apparaît pas dans les modèles de menaces, mais qui se reflète très clairement dans les heures d'ingénierie : plus on reste longtemps sur une version en fin de vie, plus cela coûte cher.

Sans correctifs en amont, votre équipe doit soit accepter cette vulnérabilité, soit se charger elle-même de l'application des correctifs : surveiller les flux CVE, évaluer si chaque vulnérabilité affecte votre configuration spécifique, rétroporter les correctifs depuis les branches prises en charge, tester et déployer. Cela représente une charge de travail considérable, qui ne cesse de croître au fil du temps à mesure que l'écart entre votre version et la version actuelle se creuse. Les modifications incompatibles s'accumulent d'une version à l'autre. Ce qui aurait pu être une migration gérable se transforme alors en un projet d'envergure comportant des risques réels.

Que faire si votre version de Django arrive en fin de vie ?

Le fait d'utiliser une version de Django en fin de vie ne signifie pas que vous n'avez plus d'options. Cela signifie simplement que vous devez faire un choix mûrement réfléchi – car ne rien faire est aussi un choix, et c'est celui qui présente le profil de risque le plus élevé.

Il existe trois voies réalistes. Le choix de la plus appropriée dépend de votre base de code, des capacités de votre équipe et du temps dont vous disposez avant que les contraintes de conformité ou de sécurité ne vous obligent à agir.

Mise à jour vers une version prise en charge

La solution la plus sûre, et la meilleure option à long terme pour la plupart des équipes, consiste à passer à une version de Django bénéficiant d'un support technique. À l'heure actuelle, cela signifie soit Django 5.2 LTS – pris en charge jusqu'en avril 2028 – soit la dernière version, Django 6.0, dont le support s'étend jusqu'en avril 2027.

C'est facile à dire. Le plus difficile, c'est que pour de nombreuses applications de production, en particulier celles qui tournent sous la version 3.2 ou 4.2 depuis des années, une mise à niveau ne se fait pas en un week-end.

Les API obsolètes sont supprimées entre les versions majeures. Il se peut que les bibliothèques tierces n’aient pas assuré la compatibilité. Une couverture de test qui semblait suffisante sur l’ancienne version révèle parfois des lacunes lorsque l’on commence la migration. Et si vous passez plusieurs versions d’un coup – par exemple, de la version 3.2 directement à la version 5.2 –, vous traversez plusieurs cycles d’obsolescence à la fois.

Utiliser le support de sécurité étendu

Pour les équipes qui ne peuvent pas effectuer de mise à niveau dans l'immédiat – et les raisons valables ne manquent pas –, le service « Endless Lifecycle Support » (ELS) de TuxCare pour Django offre une solution de sécurité indispensable.

L'équipe TuxCare recense les vulnérabilités CVE affectant les versions de Django en fin de vie, transpose les correctifs provenant de l'amont, teste et vérifie les correctifs, puis les met à disposition via les dépôts TuxCare. Aucune modification du code, aucune migration, aucun tri manuel des vulnérabilités CVE de votre côté.

TuxCare prend actuellement en charge une longue liste de versions de Django en fin de vie (notamment les versions 3.2.25, 4.0, 4.2.22, 5.0, 5.0.1, 5.0.2, 5.1, 5.1.4, 5.1.9 et 5.1.10) – et l'assistance se poursuit aussi longtemps que vous en avez besoin après la date officielle de fin de vie. ELS offre un moyen pratique de rester à jour et conforme tout en effectuant la mise à niveau correctement, selon un calendrier adapté à votre équipe plutôt que celui imposé par une période de support arrivant à expiration.

Vous pouvez consulter le CVE Tracker pour découvrir quelles vulnérabilités ont été identifiées dans toutes les versions en fin de vie prises en charge, et vérifier que les correctifs ELS de TuxCare sont disponibles et prêts à être déployés.

Mettre en place des mesures temporaires d'atténuation des risques

Certaines équipes, généralement soumises à des contraintes de délai très court, tentent de gérer l'exposition aux produits en fin de vie (EOL) par le biais de contrôles compensatoires plutôt que par l'application de correctifs de vulnérabilité. Par exemple :

• Règles WAF visant à bloquer les vecteurs d'attaque connus
• Segmentation du réseau pour limiter l'exposition
• Renforcement de la surveillance et de la détection des anomalies
• Une validation plus stricte des données d'entrée au niveau de la couche applicative

Ces mesures permettent de réduire la surface d'attaque. Elles ne la suppriment pas pour autant et ne suffisent pas à elles seules à satisfaire la plupart des exigences de conformité. Une règle WAF conçue pour bloquer un modèle d'exploitation CVE spécifique ne fonctionne que si l'attaque suit ce modèle – et les pirates ne jouent pas toujours le jeu.

Conseil de pro : Considérez cette option comme une solution temporaire, à l'échelle de quelques semaines, et non de plusieurs mois. Si vous utilisez ces mesures d'atténuation pour gagner du temps en vue d'une mise à niveau adéquate ou de la mise en œuvre d'ELS, il s'agit d'une stratégie raisonnable à court terme. Si vous les utilisez pour éviter complètement le débat, le risque ne fait que s'accumuler.

Que se passera-t-il si vous ne faites rien après la fin de vie de Django ?

Ce n'est pas vraiment une option, mais c'est ce qui se passe par défaut lorsque les équipes ne prennent pas de décision délibérée.

L'application continue de fonctionner. Personne ne planifie la mise à jour. Les vulnérabilités CVE s'accumulent en silence. Et comme rien ne semble dysfonctionner, l'urgence ne se fait jamais vraiment sentir jusqu'à ce qu'un événement la rende inévitable : un audit échoué, un incident de sécurité ou une exigence de conformité qui prend soudainement tout son sens.

Le risque ici est que cette exposition s'aggrave insidieusement. Chaque mois passé sur une version en fin de vie non mise à jour représente un mois supplémentaire d'exposition aux vulnérabilités CVE, un cycle d'audit supplémentaire où votre inventaire logiciel constitue un risque, et un mois supplémentaire de modifications incompatibles qui s'accumulent entre votre version actuelle et celle vers laquelle vous devrez finalement migrer. En substance, vous ne faites pas que retarder une mise à niveau ; vous augmentez, sans le savoir, la difficulté et le coût de la migration inévitable à laquelle vous serez tôt ou tard contraint.

Assurez votre sécurité et votre conformité après la fin de vie de Django grâce à TuxCare

La mise à niveau d'une application Django en production prend du temps, parfois beaucoup de temps. Pendant ce temps, les failles de sécurité n'attendent pas que votre cycle de développement rattrape son retard.

Le support à vie proposé par TuxCare pour Django répond à un besoin concret : celui des organisations qui utilisent des versions de Django arrivées en fin de vie et qui doivent continuer à bénéficier des correctifs et rester conformes pendant qu'elles mettent en œuvre leur plan de migration, non pas parce que le calendrier l'impose, mais parce que leur base de code l'exige réellement.

Les versions de Django actuellement prises en charge dans le cadre du service ELS de TuxCare sont les suivantes : 3.2.25, 4.0, 4.2.22, 5.0, 5.0.1, 5.0.2, 5.1, 5.1.4, 5.1.9 et 5.1.10.

De plus, Django est rarement le seul composant en fin de vie d'une pile. Il est courant qu'une application Django en fin de vie repose sur un environnement d'exécution Python en fin de vie ou soit hébergée sur une distribution Linux en fin de vie. TuxCare prend également en charge les environnements d'exécution Python, les bibliothèques open source et les distributions Linux en fin de vie grâce à son offre « Endless Lifecycle Support ».

Foire aux questions sur la fin de vie de Django

Résumé

Nom de l'article

Guide sur la fin de vie de Django : dates, risques et solutions en 2026

Description

Découvrez les dates de fin de vie (EOL) de Django, les versions prises en charge, la politique de cycle de vie, les risques de sécurité et comment effectuer une mise à niveau en toute sécurité avant que votre version n'atteigne sa fin de vie.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur