Fedora 42 enterre X11 et accélère DNF5 — voici ce que RHEL 10 vous réserve

Fedora 42, sorti le 14 avril 2026, marque une rupture nette avec deux décennies d’héritage Linux. X11 disparaît de l’installation par défaut de l’édition Workstation, et DNF5 devient le seul gestionnaire de paquets livré. Le noyau passe en 6.15, GNOME 48 soigne l’expérience de bureau, et systemd 257 poursuit la consolidation du système d’init. Ces choix ne sont pas anecdotiques : ils annoncent ce que Red Hat Enterprise Linux 10 imposera aux parcs d’entreprise dans dix-huit à vingt-quatre mois. Voici la feuille de route.

DNF5 — plus qu’un dépoussiérage

C’est le changement le plus visible pour quiconque tape dnf install plusieurs fois par jour. DNF5 remplace l’ancien DNF (lui-même successeur de Yum) avec une base de code unifiée en C++, une résolution des dépendances nettement accélérée et une empreinte mémoire réduite d’environ 40 % par rapport à DNF4.

Trois améliorations concrètes changent le quotidien d’un admin. D’abord, la gestion automatique des clés PGP expirées : DNF5 détecte et supprime les clés de dépôt obsolètes sans intervention manuelle, un irritant récurrent sur les systèmes qui ne sont pas mis à jour toutes les semaines. Ensuite, le support du Copy-on-Write en option permet des installations plus rapides en évitant les copies inutiles pendant les transactions RPM. Enfin, le paquet git est désormais scindé en git-core pour les systèmes qui n’ont besoin que du binaire de base sans l’intégralité de la suite — une réduction de dépendances bienvenue sur les images conteneur et les serveurs minimalistes.

Pour les équipes qui automatisent leurs déploiements, la syntaxe reste compatible avec dnf classique. Les scripts Ansible et les pipelines CI/CD qui appellent dnf install continuent de fonctionner sans modification. En coulisses, en revanche, le gain de vitesse est réel : sur un dnf update avec 2 000 paquets à synchroniser, DNF5 termine en moyenne 35 % plus vite que DNF4, d’après les benchmarks publiés par l’équipe Fedora.

X11 retiré — Wayland devient la norme unique

C’est le titre qui fera le plus de bruit dans les DSI. Fedora 42 retire les paquets X11 de GNOME de l’image d’installation par défaut. La session « GNOME on Xorg » n’existe plus. Les utilisateurs qui mettent à niveau depuis Fedora 41 sont automatiquement basculés vers la session Wayland.

Le travail de fond a commencé il y a plusieurs années. Fedora 36 avait fait de Wayland le choix par défaut, y compris pour les cartes NVIDIA. Fedora 41 avait retiré la session X11 du média d’installation. Fedora 42 franchit le pas définitif en supprimant les paquets eux-mêmes.

Les applications X11 historiques ne sont pas abandonnées pour autant : XWayland continue de les prendre en charge de manière transparente. Les logiciels packagés en Flatpak, les terminaux, les IDE et les navigateurs modernes fonctionnent nativement sous Wayland depuis plusieurs versions. Le point de friction résiduel concerne les outils de capture d’écran et de partage d’écran qui s’appuyaient directement sur l’API X11 : OBS Studio, les clients RDP et certains logiciels de télémédecine devront migrer vers PipeWire et le protocole xdg-desktop-portal, ce qui est déjà fait pour la quasi-totalité d’entre eux en 2026.

Pour les administrateurs de parc, le message est clair : si vos postes de travail tournent encore sous X11 par nécessité (logiciel métier non porté, carte graphique exotique), restez sur RHEL 9 jusqu’à la fin de son cycle de maintenance en 2032. Mais ne comptez pas sur RHEL 10 pour prolonger X11 au-delà.

GNOME 48 — triple buffering et bien-être numérique

L’environnement de bureau GNOME 48 apporte trois améliorations qui comptent, au-delà de l’effet de nouveauté cosmétique.

Le triple buffering dynamique est le changement le plus impactant au quotidien. Après plus de cinq ans de développement et de tests, cette fonction réduit les images sautées et lisse les animations, en particulier sur les machines à GPU intégré ou les configurations multi-écrans. Concrètement, le bureau ne « bégaye » plus quand on redimensionne une fenêtre ou qu’on fait défiler une page lourde.

La fonction bien-être numérique introduit un suivi du temps d’écran, des rappels de pause et la possibilité de programmer des créneaux de coupure. C’est un emprunt direct aux interfaces mobiles, et un signal que GNOME se pense désormais comme un OS complet plutôt qu’un simple gestionnaire de fenêtres.

Enfin, le stacking des notifications regroupe les messages par application. Finis les panneaux de notification qui débordent après une heure de build CI : les alertes de Slack, les notifications Git et les popups système sont désormais empilés et lisibles.

Sous le capot — noyau 6.15, GCC 15 et conteneurs

La colonne vertébrale de Fedora 42 repose sur le noyau Linux 6.15, qui active par défaut le support des machines virtuelles confidentielles AMD SEV-SNP et introduit la pile Intel SGX pour les environnements d’exécution de confiance. Ces deux fonctionnalités intéressent directement les équipes qui déploient des charges sensibles dans le cloud ou sur des infrastructures mutualisées.

Le compilateur passe en GCC 15 avec un support amélioré de C23, et LLVM/Clang 20 l’accompagne. Côté langages, Go 1.24, Ruby 3.4 et PHP 8.4 sont livrés en version à jour. Python 3.8 est définitivement retiré des dépôts — les applications doivent viser Python 3.9 minimum, et idéalement 3.12 ou 3.13 pour bénéficier des gains de performance de l’interpréteur.

Du côté des conteneurs, Fedora CoreOS bascule sa livraison des mises à jour d’OSTree vers des registres OCI standards, alignant l’OS immutable sur les workflows Kubernetes et Podman. Les Atomic Desktops (Silverblue, Kinoite) activent ComposeFS par défaut pour la composition du système de fichiers, ce qui améliore la vérification d’intégrité et la déduplication. Enfin, Fedora produit désormais des images officielles pour WSL, ce qui facilite l’adoption de l’écosystème Fedora/RHEL sur les postes Windows en entreprise.

Ce que RHEL 10 va retenir — et ce qu’il va écarter

La règle est connue : chaque version de RHEL est une photographie stabilisée d’une version de Fedora, figée pour dix ans de maintenance. RHEL 9 (2022) était basé sur Fedora 34. RHEL 10, attendu pour fin 2027 ou début 2028, sera très probablement construit sur les fondations posées par Fedora 42 et 43.

Voici ce qui passera presque certainement dans RHEL 10 :

• DNF5 comme gestionnaire de paquets unique. La transition sera transparente pour les scripts, mais les administrateurs devront mettre à jour leurs procédures de troubleshooting — les logs et les options de debug changent.
• Wayland par défaut, X11 absent. Les paquets Xorg ne seront pas livrés. XWayland restera disponible pour les applications clientes X11. Les logiciels qui dépendent encore d’un serveur X complet devront migrer avant la bascule.
• Noyau 6.x LTS stabilisé, avec SEV-SNP et SGX pour les workloads confidentiels. RHEL 10 sera la première version Enterprise Linux à offrir ces fonctions en support complet.
• ComposeFS et OCI pour les déploiements Atomiques et CoreOS, alignant RHEL sur les standards de l’écosystème conteneur.
• GCC 15, Python 3.12+, Go 1.24 dans les canaux Application Stream, avec une fenêtre de support classique de deux à cinq ans selon les composants.

Ce que RHEL 10 n’intégrera probablement pas, en revanche :

• KDE Plasma Edition promu dans Fedora 42 au rang d’édition officielle : RHEL reste un produit GNOME/Workstation, KDE est une offre communautaire.
• COSMIC Desktop (le spin Rust de System76) : trop jeune, pas de support entreprise annoncé.
• Anaconda Web UI : l’installateur web est encore en rodage. RHEL conservera probablement l’interface texte classique d’Anaconda pour les déploiements Kickstart, avec le Web UI en option.

Le verdict — ce que les admins RHEL doivent faire maintenant

Si vous gérez un parc RHEL 9 aujourd’hui, vous avez deux ans pour préparer la bascule vers RHEL 10 sans précipitation. Voici la liste des actions par priorité :

• Auditez vos dépendances X11. Identifiez les applications métier qui utilisent encore un serveur X complet et planifiez leur migration vers Wayland ou leur remplacement. Le délai est confortable, mais ces migrations prennent souvent plus de temps que prévu — commencez maintenant.
• Testez DNF5 sur une Fedora 42. Les scripts Ansible et les pipelines de build ne casseront pas, mais les hooks de plugin et les formats de sortie changent. Vérifiez que vos outils de supervision qui parsent la sortie de dnf ne produisent pas de faux négatifs.
• Montez vos conteneurs sur des bases Fedora. Les images fedora:42 donnent un aperçu exact de ce que seront les conteneurs RHEL 10. Testez vos Dockerfiles et vos charts Helm contre cette base dès maintenant.
• Migrez vos applications Python vers 3.12. Python 3.8 et 3.9 disparaîtront des dépôts RHEL 10. La cible raisonnable en 2026 est Python 3.12, supporté jusqu’en 2028 par la communauté CPython.

Fedora 42 n’est pas une version de plus dans le cycle semestriel du projet : c’est le moment où l’écosystème Red Hat acte la fin de X11 et la maturité de DNF5. RHEL 10 n’aura pas d’autre choix que d’embarquer ces décisions. La meilleure chose à faire, c’est de les anticiper.

Références

• Announcing Fedora 42, Red Hat Blog, 14 avril 2026.
• What’s New in Fedora Workstation 42, Fedora Magazine, 15 avril 2026.
• Fedora 42 Change Set, Fedora Project Wiki.
• Changes/WaylandOnlyGNOME, Fedora Project Wiki.
• RHEL 10 plans for Wayland and Xorg server, Red Hat Blog.
• RHEL 10 — What’s New for Sysadmins, mylinux.work.
• Fedora Linux 42 Release Notes, Fedora Docs.
• GNOME 48 Release Notes, GNOME Project.