Fin de support RHEL 8 et RHEL 9 : toutes les dates du cycle de vie Red Hat Enterprise Linux (2026)

Rédigé par Scott Bissett  ·  Publié le 7 septembre 2026  ·  Chaque date de cet article est liée à notre couche de données, relue chaque jour dans l'API product life-cycle de Red Hat et vérifiée à chaque construction du site — notre méthode de vérification (en anglais)  ·  English version  ·  日本語版

À la question « jusqu'à quand RHEL est-il supporté ? », il existe en réalité deux réponses. La première est la date de fin de la version majeure — pour RHEL 8, le 31 mai 2029 — et c'est celle qui sert à planifier une migration. La seconde est de savoir si le serveur qui tourne aujourd'hui reçoit réellement des correctifs, et cela se décide au niveau de la version mineure. Confondre les deux, c'est découvrir qu'un « serveur RHEL 8 encore supporté » n'a en fait reçu aucun correctif depuis des années. Cet article donne les deux réponses.

Le cycle de vie RHEL : trois phases

Chaque version majeure de Red Hat Enterprise Linux a un cycle de vie standard d'environ dix ans à partir de sa disponibilité générale (GA), découpé en trois phases successives.

• Support complet (Full Support, environ cinq ans) — nouvelles fonctionnalités, prise en charge de nouveau matériel, corrections de bugs et correctifs de sécurité. Les versions mineures (8.1, 8.2, …) sortent pendant cette phase, à peu près tous les six mois.
• Support de maintenance (Maintenance Support, environ cinq ans) — plus de nouvelles fonctionnalités ; l'essentiel est constitué des correctifs de sécurité de criticité élevée (RHSA) et des corrections de bugs importants. Quand on parle de « fin de support », d'« EOL » ou d'« obsolescence » de RHEL, c'est la fin de cette phase que l'on désigne.
• Extended Life Cycle Support (ELS) — option payante disponible après la fin du support de maintenance. Elle prolonge de plusieurs années la livraison des correctifs de sécurité critiques et importants. Red Hat a publié les dates suivantes : RHEL 7 jusqu'au 31 mai 2029, RHEL 8 jusqu'au 31 mai 2033, RHEL 9 jusqu'au 31 mai 2036.

Un mécanisme distinct existe en parallèle : l'Extended Update Support (EUS). Là où l'ELS prolonge la vie d'une version majeure, l'EUS est un flux payant qui maintient une version mineure précise sous correctifs pendant environ deux ans après sa sortie (versions mineures paires uniquement). Cette distinction est au cœur du « piège des versions mineures » décrit plus bas.

Dates de fin de support de toutes les versions RHEL

Pour chaque version majeure, de la disponibilité générale à la fin de l'ELS. Les dates sont au format ISO 8601 (année-mois-jour).

Chaque cellule de ce tableau est liée à notre couche de données, qui relit l'API product life-cycle de Red Hat tous les jours : si Red Hat modifie une date, le tableau est réécrit à la construction suivante du site. Cliquez sur une version pour voir son statut du jour et son score de risque.

Trois lectures à retenir. D'abord, RHEL 7 a quitté le support ordinaire : depuis le 30 juin 2024, un serveur RHEL 7 sans contrat ELS n'a reçu aucun correctif de sécurité. Ensuite, RHEL 8 est en phase de maintenance depuis le 31 mai 2024, et il reste moins de trois ans avant son EOL du 31 mai 2029. Enfin, la fin du support complet de RHEL 9, le 31 mai 2027, est plus proche qu'on ne le pense : c'est la date après laquelle RHEL 9 ne reçoit plus de nouvelles fonctionnalités ni de nouvelles versions mineures, même si les correctifs de sécurité continuent jusqu'en 2032.

Le piège des versions mineures : « RHEL 8 est supporté jusqu'en 2029 »

C'est le point le plus important de cet article. Les deux affirmations suivantes sont toutes les deux exactes.

Ces deux faits, en apparence contradictoires, sont la source de l'erreur la plus fréquente sur le cycle de vie RHEL. Le mécanisme est le suivant : dans une souscription standard, Red Hat ne fournit les correctifs (errata) que pour la version mineure la plus récente de chaque version majeure. Aujourd'hui, la dernière version mineure de RHEL 8 est la 8.10 et la version mineure actuelle de RHEL 9 est la 9.8. Un serveur qui exécute simplement dnf update suit automatiquement la dernière version mineure et ne court aucun risque. Mais un serveur verrouillé sur une version mineure précise — pour une certification éditeur, une règle de gestion des changements, une image de référence figée ou simplement subscription-manager release --set oublié par un prédécesseur — cesse de recevoir des correctifs le jour où la version mineure suivante sort, alors que la version majeure reste officiellement « supportée » pendant des années.

La soupape prévue par Red Hat est l'EUS : les versions mineures paires (9.4, 9.6, …) peuvent rester sous correctifs pendant environ deux ans après leur sortie, moyennant un contrat payant. Les versions mineures impaires (9.3, 9.7, …) n'ont pas d'EUS : leurs correctifs s'arrêtent net à la sortie de la version suivante. Le détail version par version, avec pour chaque mineure la date de fin du flux standard, de l'EUS et de l'E4S (variante SAP), est tenu à jour dans l'article détaillé en anglais → Is RHEL 8.10 / 9.4 / 9.6 / 9.7 Still Supported?

Si l'inventaire fait apparaître un serveur figé sur une ancienne version mineure, trois réponses sont possibles.

1. Lever le verrou et rejoindre la version mineure courante. subscription-manager release --unset puis dnf update ramène la machine sur 8.10 ou 9.8 et rétablit les correctifs du flux standard, sans coût supplémentaire. Si plus personne ne sait pourquoi la version était figée, c'est la bonne réponse.
2. Si le verrou est réellement nécessaire, souscrire le flux payant correspondant. Certification ISV, environnement SAP sous gestion des changements : dans ces cas, l'EUS d'une version mineure paire encore vivante, ou l'E4S / Enhanced EUS côté SAP, est la seule façon de rester corrigé. Le danger est de n'avoir souscrit aucun flux tout en se rassurant avec la date de fin de la version majeure.
3. Traiter le cas comme un signal de migration. Un serveur encore figé sur 8.6 en 2026 n'est pas un problème de gestion des correctifs mais de cycle de vie : il appartient au plan de migration RHEL 8, dont l'échéance est le 31 mai 2029.

Planifier la migration : deux cibles depuis RHEL 8

Pour un parc RHEL 8, le 31 mai 2029 paraît lointain ; une fois comptés la qualification des applications, les fenêtres de changement et le déploiement, la marge est en réalité mince. Les deux cibles sont RHEL 9, supporté jusqu'au 31 mai 2032, et RHEL 10, sorti le 20 mai 2025 et supporté jusqu'au 31 mai 2035. Pour un système que l'on compte garder longtemps, viser directement RHEL 10 a du sens, puisque sa durée de support restante est la plus longue ; selon l'état de compatibilité des middlewares et des produits tiers, RHEL 9 reste souvent la cible réaliste. Dans les deux cas, la mise à niveau en place avec l'outil leapp (8 vers 9, puis 9 vers 10) évite une réinstallation, à condition de la valider sur une copie avant de toucher à la production. Et pour les serveurs qui ne peuvent pas migrer à temps, l'ELS est prévu pour cela : il achète du temps, pas une exemption.

Questions fréquentes

Pages liées

• Statut et score de risque de toutes les versions RHEL (mis à jour chaque jour) · RHEL 8 · RHEL 9 · RHEL 10
• Le piège des versions mineures RHEL, version par version (en anglais)
• RHEL End of Life & Support Options : le guide détaillé des versions majeures (en anglais)
• RHEL 10 End of Life : toutes les phases (en anglais)
• Guide de décision RHEL : mise à niveau, ELS ou support tiers (en anglais)