Fin de vie d'OpenJDK 11 : dates, risques et solutions (Guide 2026)

Principaux enseignements

• La distribution gratuite des correctifs de sécurité pour OpenJDK 11 a pris fin fin 2024. Si vous n'avez pas souscrit à un support étendu, toutes les vulnérabilités CVE identifiées depuis cette date restent non corrigées dans votre environnement d'exécution.
• La date effective de fin de vie dépend de la version du fournisseur que vous utilisez ; il ne s'agit pas d'une date unique applicable à l'ensemble de la communauté.
• Passer à Java 17 ou 21 est la bonne décision à long terme, mais la dépendance vis-à-vis des bibliothèques et les piles d'applications certifiées rendent la tâche plus difficile qu'il n'y paraît.
• Le support prolongé proposé par les éditeurs ou des tiers tels que TuxCare vous permet de maintenir OpenJDK 11 à jour tout en planifiant votre migration selon votre propre calendrier.

Si vous utilisez actuellement OpenJDK 11 en production, vous avez déjà franchi le point de non-retour. Les correctifs communautaires gratuits ont cessé d'être publiés fin 2024, et toutes les vulnérabilités CVE publiées depuis lors ne sont pas corrigées dans votre environnement d'exécution, à moins que quelqu'un ne paie pour cela.

La fin de vie d'OpenJDK 11 n'est plus une simple éventualité à prendre en compte dans votre planification : elle est déjà effective, et votre niveau de sécurité s'est progressivement affaibli en conséquence. Ce guide vous présente les dates exactes, les changements qui interviennent à la fin du support communautaire, ainsi que les options réalistes qui s'offrent à vous lorsque « il suffit de passer à Java 17 » n'est pas une phrase que vous pouvez réellement mener à bien ce trimestre.

Présentation du cycle de vie d'OpenJDK

OpenJDK ne dispose pas d'un cycle de vie de support unique et harmonisé – et c'est justement ce qui pose problème aux équipes.

Le projet OpenJDK en amont s'engage uniquement à fournir six mois de mises à jour par version. Tous les autres calendriers que vous avez pu voir proviennent de fournisseurs en aval : Red Hat, Oracle, Amazon, Azul, Microsoft, Eclipse Adoptium. Chacun d'entre eux propose sa propre version et fixe sa propre date de fin de vie.

Cette distinction est plus importante que la plupart des gens ne le pensent. Les termes « fin de vie » et « fin de support » sont souvent utilisés de manière interchangeable jusqu’à ce qu’une vulnérabilité CVE soit signalée – et là, soudainement, la différence prend une importance considérable. La « fin de vie » signifie généralement « plus aucune mise à jour gratuite de la part de ce fournisseur ». La « fin de support » signifie « aucune assistance disponible, qu’elle soit payante ou gratuite ». Pour OpenJDK, vous pouvez atteindre la fin de vie chez votre fournisseur actuel tout en trouvant une assistance payante ailleurs. C'est là tout l'intérêt des programmes d'assistance prolongée proposés par les fournisseurs et les tiers.

Voici un aperçu de ce que vous apporte réellement chaque phase du cycle de vie :

Bon à savoir : Le label « LTS » attribué aux versions Java 8, 11, 17, 21 et 25 est une convention des éditeurs, et non un engagement de la part d'OpenJDK en amont. Oracle en a été l'initiateur ; le reste de l'écosystème a suivi. Le projet lui-même évolue tous les six mois, quelle que soit la version installée sur votre serveur.

Types de versions d'OpenJDK

OpenJDK est publié tous les six mois, mais les éditeurs traitent ces versions de manière très différente selon qu'il s'agit ou non de versions LTS.

Communiqués de presse LTS

Les versions LTS sont celles que les éditeurs s'engagent à maintenir pendant plusieurs années. Java 8, 11, 17, 21 et 25 constituent les versions LTS actuelles. Celles-ci bénéficient de correctifs de sécurité rétroportés, de corrections de bogues et de mises à jour trimestrielles critiques (Critical Patch Updates) de la part des principaux éditeurs. Si vous exploitez une application en production, vous opterez très certainement pour une version LTS : c'est précisément pour cela qu'elles existent.

Le support communautaire comprend généralement des correctifs de sécurité et des corrections de bogues gratuits, mais prend fin à la date de fin de vie (EOL) annoncée pour chaque version. Passé ce délai, les mises à jour ne sont disponibles que dans le cadre de programmes de support étendu proposés par le fournisseur ou par des tiers.

Au-delà de la communauté OpenJDK, les éditeurs et les distributeurs proposent leurs propres versions et calendriers de support pour les versions d'OpenJDK. Ces calendriers varient également, et comprendre les principales différences entre OpenJDK et Oracle JDK peut vous aider à choisir la distribution la mieux adaptée à votre stratégie de support à long terme.

Versions non-LTS

Les versions non LTS (Java 9, 10, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 26) bénéficient de six mois de mises à jour avant de ne plus être prises en charge activement. Elles sont destinées aux développeurs qui souhaitent accéder en avant-première aux nouvelles fonctionnalités, et non aux environnements de production. Selon le rapport « 2024 State of the Java Ecosystem » de New Relic, moins de 2 % des applications de production fonctionnent sous une version non LTS – ce qui est logique, car cela revient en substance à s'engager à effectuer une mise à niveau obligatoire tous les six mois.

Niveaux d'assistance étendue

Au-delà du cycle de vie standard (LTS), les éditeurs proposent des phases de support étendu payantes. Oracle offre aux versions LTS cinq ans de « Premier Support », suivis de trois ans de « Extended Support », puis d’un « Sustaining Support » à durée indéterminée – qui n’inclut toutefois aucun correctif de sécurité. Red Hat propose une structure similaire, avec une phase ELS-1 distincte pour OpenJDK 11, disponible sous forme de module complémentaire payant. Des offres tierces telles que l'Endless Lifecycle Support de TuxCare pour OpenJDK vont encore plus loin, en proposant des correctifs CVE continus aussi longtemps que vous en avez besoin, quel que soit le build du fournisseur que vous avez initialement déployé.

Conseil d'initié : Votre période de support « LTS » correspond à celle indiquée par le fournisseur dont vous avez téléchargé la version, et non à celle indiquée par Oracle. Les versions Microsoft Build d'OpenJDK, Amazon Corretto, Azul Zulu et Eclipse Temurin ont toutes des dates de fin de support différentes pour la même version de Java. Vérifiez la page relative au cycle de vie publiée par votre fournisseur avant de supposer qu'il vous reste encore plusieurs années.

Fin de vie d'OpenJDK 11 : les dates qui comptent vraiment

Java 11 a été lancé en septembre 2018, constituant la deuxième version LTS après Java 8. La durée de prise en charge varie considérablement selon la version que vous utilisez – et comme le montre le tableau ci-dessous, certains éditeurs ont prolongé leurs délais bien au-delà de ce à quoi s'attendent la plupart des équipes.

La situation est plus complexe que ne le pensent la plupart des équipes. Si vous utilisez la version de Red Hat sans abonnement ELS-1, la fourniture de correctifs gratuits a pris fin le 31 octobre 2024. Pour les équipes gérant des piles logicielles plus étendues sur cette plateforme, il est tout aussi essentiel de suivre le calendrier de fin de vie de RHEL 8 pour la planification opérationnelle. Le support Premier d'Oracle a pris fin encore plus tôt, en septembre 2023. Mais si vous utilisez Corretto, Temurin ou Azul Zulu, vous bénéficiez peut-être encore de la période de support actif de votre fournisseur. Votre exposition réelle dépend de la version que vous utilisez et de l'actualité de votre niveau de correctifs, et pas seulement du numéro de version.

Attention : « Nous utilisons une version prise en charge » signifie souvent « nous avons téléchargé la dernière version il y a six mois et ne l'avons jamais mise à jour depuis ». Les fournisseurs OpenJDK publient chaque trimestre des mises à jour de correctifs critiques. Si le niveau de correctif de votre version date de plus de 90 jours, vous avez des vulnérabilités CVE non corrigées, même si votre version est techniquement toujours prise en charge.

Qu'en est-il d'OpenJDK 8 ?

Le cas de Java 8 est similaire, même si le processus a pris plus de temps que prévu. Les mises à jour publiques gratuites d'Oracle pour Java 8 ont pris fin en janvier 2019 pour les utilisateurs commerciaux. Cependant, les éditeurs ont continué à proposer leurs propres versions bien au-delà de cette date.

Le support d'OpenJDK 8 par Red Hat est prolongé au moins jusqu'en 2026 pour les abonnés RHEL, tandis qu'Azul, Amazon Corretto et Eclipse Temurin continuent de proposer des versions bénéficiant de différents niveaux de maintenance active. Début 2026, Java 8 représentait encore une part importante des charges de travail en production – selon certaines enquêtes, à peu près équivalente à celle de Java 11.

La différence entre Java 8 et Java 11 réside dans le fait que Java 8 est en phase de « prolongation » depuis plus longtemps ; par conséquent, les entreprises qui l'utilisent encore ont généralement mûrement réfléchi à ce choix. Les équipes travaillant avec Java 11 en sont souvent encore au tout début de cette réflexion, souvent parce que la date de fin de vie les a prises au dépourvu.

Si vous gérez à la fois des charges de travail Java 8 et Java 11, les considérations sont similaires. Le nombre de CVE qui s'accumulent au cours du cycle de vie prolongé d'une version LTS donne à réfléchir : l'historique des CVE de Java 8 constitue un point de référence utile pour comprendre ce qui attend désormais Java 11 en l'absence de correctifs.

Java 11 et 8 sont encore partout

Selon les données de New Relic – issues de centaines de milliers d'applications en production –, Java 11 et Java 8 représentent ensemble environ 62 % des charges de travail en production, Java 11 totalisant 33 % et Java 8, 28,8 %.

Il y a de réelles raisons à cela, et pas seulement une question d'inertie organisationnelle. Java 11 et 8 sont des versions stables et bien maîtrisées qui sous-tendent des applications web, des services backend, des plateformes middleware et des outils internes dans presque tous les secteurs d'activité. Bon nombre d'entre eux reposent sur des frameworks soumis à leurs propres contraintes de cycle de vie : si une plateforme middleware n'est certifiée que pour Java 11, la mise à niveau du runtime n'est pas une décision que l'équipe d'exploitation peut prendre de son propre chef.

Il n'est pas toujours possible de réécrire ou de mettre à niveau une application lorsqu'elle est essentielle à l'activité, mal documentée ou gérée par une équipe dont les effectifs ont diminué de moitié depuis sa création. Ce n'est pas un échec, c'est la réalité du fonctionnement des logiciels d'entreprise.

Que se passe-t-il une fois que le soutien de la communauté prend fin ?

Le lendemain de la fin de vie, rien de dramatique ne se produit. Vos JVM continuent de fonctionner. Vos applications continuent de répondre. C'est justement là le problème : la défaillance est silencieuse et se manifeste plus tard sous la forme d'une vulnérabilité CVE pour laquelle il n'existe aucun correctif.

Voici ce qui change concrètement :

• Les correctifs CVE ne sont plus disponibles pour votre version de Java : Toute vulnérabilité découverte après la fin de vie (EOL) ne sera jamais corrigée dans votre environnement d'exécution via les canaux gratuits – elle s'accumule, et votre exposition augmente à chaque nouvelle divulgation.
• Les cadres de conformité commencent à créer des frictions :SOC 2, PCI DSS, HIPAA et FedRAMP exigent tous une gestion documentée des correctifs pour les vulnérabilités connues. L'utilisation d'un environnement d'exécution en fin de vie (EOL) n'entraîne pas automatiquement un échec à l'audit, mais il devient de plus en plus difficile d'en assurer la sécurité.
• La dérive des dépendances s'accélère : les bibliothèques et les frameworks cessent de prendre en charge les anciennes versions de Java à mesure que leurs propres écosystèmes évoluent, ce qui entraîne une dégradation progressive de la compatibilité des logiciels associés à votre environnement d'exécution figé.
• Les images de base des conteneurs ne sont plus mises à jour : Les images openjdk:11 sur Docker Hub ont été dépréciées bien avant la fin de vie (EOL) de la communauté. Si vous continuez à les récupérer, vous récupérez un instantané statique contenant des vulnérabilités connues.
• La responsabilité du fournisseur vous incombe désormais : La plupart des contrats de logiciels d'entreprise comportent des clauses relatives à l'exécution des logiciels pris en charge. Une fois que vous utilisez un environnement d'exécution en fin de vie (EOL), vous en assumez personnellement le risque.

Pourquoi « il suffit de mettre à jour » est plus difficile qu'il n'y paraît

Le conseil habituel – « passez à Java 17 ou 21 » – est la bonne réponse sur le papier, mais la mauvaise dans la réalité pour de nombreux projets. Voici pourquoi les équipes restent sur OpenJDK 11 même lorsqu’elles savent qu’elles ne devraient probablement pas.

Dépendance vis-à-vis des bibliothèques et des frameworks

Un nombre surprenant d'applications Java en production dépendent de bibliothèques qui n'ont pas été recompilées ni testées avec les versions récentes du JDK depuis des années. Dès que vous passez de Java 11 à Java 17, vous commencez à rencontrer des problèmes avec :

• Suppression des API sur lesquelles certaines bibliothèques plus anciennes s'appuyaient sans le signaler
• Un encapsulage renforcé (introduit dans Java 9, puis renforcé depuis) rend obsolètes les anciennes bibliothèques de manipulation de bytecode
• Incompatibilités avec certains outils tels que les anciennes versions de Lombok, Mockito ou Byte Buddy
• JAXB, JAX-WS et d'autres API Java EE qui ont été entièrement supprimées du JDK

Imaginez une équipe d'ingénieurs de 20 personnes en pleine migration : ils ont mis à jour le code de l'application, les outils de compilation et le pipeline d'intégration continue. C'est alors que leur bibliothèque SSO interne – dont la dernière mise à jour remonte à un ingénieur parti il y a trois ans – plante IllegalAccessError lors du premier test d'intégration. Cela représente une semaine de débogage avant qu'ils ne décident de créer une branche de la bibliothèque, et ce n'est qu'une seule dépendance.

Piles d'applications certifiées

Les éditeurs de logiciels d'entreprise certifient leurs produits pour des versions spécifiques de Java. Les systèmes ERP, les plateformes bancaires, les outils de souscription d'assurance et les logiciels de santé disposent souvent d'une matrice de compatibilité indiquant « Java 8 et 11 » – et rien d'autre. La mise à niveau du JDK sous-jacent entraîne l'annulation de votre contrat de support. Dans ce cas de figure, la mise à niveau de l'environnement d'exécution n'est pas entravée par la complexité du code, mais par une clause contractuelle.

Coût de la migration et tolérance au risque

Les migrations entraînent des dysfonctionnements : c’est ce que les équipes ont appris à chaque passage à une nouvelle version LTS. Une migration réaliste de Java 11 vers Java 17 pour une base de code complexe implique de vérifier toutes les dépendances directes et transitives (souvent plus de 200 bibliothèques), de mettre à jour les outils de compilation et les pipelines d’intégration continue, de réexécuter l’ensemble des suites de tests de régression et des tests de charge, d’assurer la coordination entre les services et de refactoriser le code pour tenir compte des API supprimées. Pour une équipe gérant 10 services, cela représente un quart du temps d'ingénierie. Pour une équipe gérant 200 services, c'est un programme d'une année.

Retour à la réalité : Les fournisseurs adorent publier des guides de « migration facile » présentant une mise à niveau de Java 8 vers 17 dans une vidéo de 30 minutes. Ces démos utilisent des applications Spring Boot « propres » avec cinq dépendances. Votre base de code de production a accumulé des années de complexité, plusieurs branches de bibliothèques internes abandonnées et probablement au moins un fichier JAR dont personne ne connaît l’origine. Préparez-vous à cela, pas à la démo.

Que faire après la fin de vie d'OpenJDK 11 ?

Il existe trois voies réalistes pour aller de l'avant, et le choix de la bonne dépend de la marge de manœuvre dont vous disposez réellement en matière de migration.

Support de cycle de vie étendu

Si vous ne pouvez pas migrer dans l'immédiat mais ne pouvez pas vous permettre de laisser des vulnérabilités (CVE) non corrigées, le support étendu est la solution la plus appropriée. Les grands fournisseurs comme Oracle et Red Hat proposent des phases de support étendu payantes avec des conditions bien définies, tandis que des prestataires indépendants comblent ce vide pour les entreprises qui ont besoin d'une solution plus flexible.

Le service « Endless Lifecycle Support » (ELS) de TuxCare pour OpenJDK couvre les versions 6, 7, 8, 11 et 17, y compris celles dont la fin de vie (EOL) a déjà été dépassée par la communauté. Il est spécialement conçu pour les équipes qui ont besoin de correctifs de sécurité continus sans être contraintes de respecter un calendrier de mise à niveau qu’elles ne peuvent pas raisonnablement respecter :

• Correctifs CVE rétroportés pour les versions d'OpenJDK dont la fin de vie (EOL) a été dépassée par la communauté
• Indépendant du fournisseur : fonctionne que vous ayez initialement déployé la version Red Hat d'OpenJDK, Adoptium, Corretto ou une installation personnalisée
• Aucune modification du code de l'application n'est nécessaire
• La couverture reste en vigueur aussi longtemps que vous en avez besoin, et non pas pendant une période fixe de deux ou trois ans
• Couvre les variantes d'Enterprise Linux et les distributions basées sur Debian, notamment RHEL, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, Debian et Ubuntu.

L'ELS de TuxCare pour OpenJDK est une solution au niveau du runtime : elle applique des correctifs spécifiquement au runtime Java. Si vous utilisez également une distribution Linux en fin de vie (par exemple, CentOS 7), TuxCare propose un ELS distinct pour les systèmes d'exploitation qui couvre l'ensemble des paquets du système d'exploitation, y compris OpenJDK lorsqu'il fait partie de cet ensemble. Il s'agit de produits distincts. ELS pour OpenJDK vous offre une couverture au niveau de l'environnement d'exécution quel que soit votre système d'exploitation ; ELS pour le système d'exploitation couvre l'ensemble de la distribution. En fonction de votre situation, vous pourriez avoir besoin de l'un, de l'autre, ou des deux.

Si votre préoccupation concerne uniquement le runtime Java – même si vous l'utilisez sur un système d'exploitation récent et pris en charge –, TuxCare ELS pour OpenJDK s'en charge sans nécessiter d'abonnement au niveau du système d'exploitation.

Passer à Java 17 ou Java 21

Si vous disposez des ressources techniques nécessaires et que votre infrastructure le permet, la migration vers une version LTS actuelle constitue la meilleure solution à long terme. Selon New Relic, l'adoption de Java 17 a atteint 35 % des applications en production en 2024, et le taux d'adoption de Java 21 au cours de ses six premiers mois a été près de trois fois supérieur à celui de Java 17.

Java 17 constitue une avancée significative, même s'il convient de tenir compte de son calendrier de prise en charge pour planifier vos projets. Renseignez-vous sur la fin de vie (EOL) d'OpenJDK 17 avant de l'adopter comme objectif à long terme.

Quelques pistes pratiques pour commencer :

• Exécuter jdeps --jdk-internals en comparant vos fichiers JAR d'application afin de détecter rapidement l'utilisation d'API internes supprimées
• Vérifiez que chaque dépendance Maven/Gradle utilise bien la dernière version compatible avec la version Java ciblée
• Organisez la migration en passant par les phases de développement, de test et de déploiement canary avant le déploiement à l'échelle de l'ensemble du parc
• Prévoyez explicitement du temps pour les surprises du type « on a trouvé une autre bibliothèque » : ce n’est pas une hypothèse

Java 21 est la meilleure option si vous pouvez y accéder. Il bénéficie de l'une des plus longues périodes de support encore en vigueur parmi les différents fournisseurs et inclut des threads virtuels, ce qui peut réduire considérablement la charge liée au pool de threads pour les charges de travail à forte concurrence.

Continuer à utiliser un produit en fin de vie et accepter le risque

C'est ce que font discrètement de nombreuses équipes. Si vous choisissez cette voie, faites-le en toute conscience :

• Consignez officiellement cette décision et faites-la approuver par les responsables de la sécurité et de la conformité
• Mettre en place des mesures de contrôle compensatoires (pare-feu d'application Web, autoprotection des applications en exécution, politiques réseau plus strictes)
• Surveillez chaque semaine les flux CVE concernant Java 11 et Java 8 et évaluez chaque vulnérabilité par rapport à votre exposition réelle
• Fixez une date butoir stricte pour la migration ou l'adoption du support étendu – si vous vous dites « on s'en occupera un jour », vous risquez de vous retrouver encore sous Java 11 en 2028

C'est la voie la plus risquée et elle n'est pas viable à long terme. Mais si l'alternative réaliste consiste à déployer une migration à moitié testée en deux semaines, une phase d'attente documentée et maîtrisée est parfois le choix le plus justifiable. La différence essentielle réside dans l'intentionnalité.

En première ligne : Les équipes qui gèrent le mieux les transitions de fin de vie (EOL) sont celles qui ont commencé à planifier 12 mois avant la date prévue. Si vous lisez ceci en 2026 et que vous utilisez toujours OpenJDK 11 sans plan de transition, vous n'avez plus de marge de manœuvre. Choisissez l'une de ces trois voies dès ce trimestre.

Que faire après la fin de vie d'OpenJDK 11 ?

Le soutien de la communauté en amont d'OpenJDK 11 a pris fin fin 2024, et les délais de prise en charge proposés par plusieurs éditeurs arriveront à échéance au cours des prochaines années. Vos machines virtuelles Java (JVM) ne se soucient guère de ces dates, mais vos auditeurs, votre responsable de la sécurité des systèmes d'information (RSSI) et votre équipe d'intervention en cas d'incident y prêteront de plus en plus attention.

Si vous avez la possibilité de migrer, privilégiez Java 21 plutôt que Java 17 : son cycle de support est plus long, et les threads virtuels constituent une amélioration notable pour les charges de travail à forte concurrence. Si une migration n'est pas envisageable pour le moment mais que vous avez besoin de correctifs de sécurité réguliers, TuxCare ELS pour OpenJDK prend en charge Java 8, 11 et d'autres versions dont la fin de vie est dépassée, sur divers environnements Linux d'entreprise et basés sur Debian. Cela vaut la peine d'être examiné avant votre prochain audit de conformité.

Quelle que soit la voie que vous choisissiez, faites-le en toute conscience. Le pire scénario, c'est celui qui se produit par défaut : rester sur Java 11 en fin de vie parce que personne n'a pris la décision délibérée d'agir autrement.

Résumé

Nom de l'article

Fin de vie d'OpenJDK 11 : dates, risques et solutions (Guide 2026)

Description

Tout ce qu'il faut savoir sur la fin de vie d'OpenJDK 11 : dates clés, risques de sécurité et options de mise à niveau ou de prolongation du support en 2026.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur