Un développeur fait l'autopsie de Wayland et sa position suscite la polémique
Un développeur fait l'autopsie de Wayland : comment un projet né pour simplifier X11 aurait fini par fragmenter tout ce qu'il voulait unifier,
sa position suscite la polémique
Dix-huit ans après ses débuts, Wayland polarise toujours autant les développeurs et utilisateurs Linux. Un billet publié sur le blog d'Omar Roth a relancé une dispute vieille comme le protocole lui-même : ce successeur d'X11 a-t-il tenu ses promesses, ou a-t-il mobilisé une décennie de ressources pour un résultat décevant ? La discussion qui s'en est suivie révèle une communauté profondément fracturée, entre pragmatiques satisfaits et utilisateurs avancés qui n'en finissent pas de payer la facture de cette transition.
Le constat de départ est arithmétique : en 2026, Wayland a atteint une part d'utilisation estimée entre 40 et 50 %, voire 50 à 60 % selon les sources. Pour un projet lancé en 2008, c'est une adoption que l'auteur du billet juge singulièrement lente. Le parallèle qu'il dresse avec PipeWire est cruel : ce remplaçant de PulseAudio a mis environ huit ans à s'imposer comme standard par défaut dans Ubuntu, quatre ans seulement après son lancement.
Le reproche central ne porte pas sur la qualité technique de Wayland en tant que telle, mais sur la dissonance entre les promesses initiales et la réalité vécue. L'implémentation de référence originale faisait un peu plus de 3 000 lignes de code, une ambition de simplicité assumée. Dix-huit ans plus tard, les migrations sont encore incomplètes et les cas limites, nombreux.
Sur le plan de la sécurité, argument historiquement central dans la communication pro-Wayland, l'auteur exprime une perplexité légitime : le modèle de menace présenté est difficile à cerner. Les applications ne peuvent plus voir les fenêtres des autres, mais elles restent libres d'interagir d'autres façons potentiellement problématiques. Pendant ce temps, des cas concrets posent problème : OBS ne peut pas enregistrer l'écran, le copier-coller ne fonctionne pas de façon fiable, et les aperçus de fenêtres sont absents sans implémentation d'une extension spécifique au protocole de base.
Côté performance, le bilan est tout aussi mitigé. Les gains architecturaux (réduction du nombre de copies, élimination des allers-retours X11) ne se sont pas concrètement matérialisés, ou sont si situationnels qu'il est difficile de revendiquer une victoire nette. Certains benchmarks montrent même une régression de l'ordre de 40 % sous Wayland par rapport à X11.
La réponse de la communauté : entre défense raisonnée et lassitude
La publication a immédiatement déclenché une discussion dense, révélatrice des positions irréconciliables qui traversent la communauté Linux depuis des années.
D'un côté, les partisans d'une lecture structurelle : plusieurs développeurs rappellent que Wayland a provoqué des améliorations massives dans l'ensemble de la pile graphique Linux. Avant lui, il était impossible d'utiliser un GPU sans qu'une session X soit active, et les pilotes graphiques étaient entièrement embarqués dans Xorg, le serveur d'affichage de l'époque. L'insistance de Wayland à refuser de fonctionner sur des plates-formes n'ayant pas assez assaini leurs pilotes aurait été le seul levier capable de pousser les constructeurs à remettre à plat leurs implémentations.
Un argument souvent avancé est celui du scaling fractionné par écran, resté longtemps impossible sous X11. De nombreux utilisateurs témoignent que la gestion de plusieurs moniteurs à résolutions ou densités différentes est précisément ce qui les a définitivement fait basculer sous Wayland, en particulier sur Fedora.
De l'autre côté, les critiques les plus sévères ne ciblent pas la qualité technique de Wayland mais sa philosophie de déploiement. Un intervenant résume ce que ressentent beaucoup d'utilisateurs avancés : le vrai problème n'est pas Wayland en soi, mais le fait que quinze ans ont été nécessaires pour atteindre une parité fonctionnelle approximative avec X11, pendant lesquels le développement d'X11 a été délibérément ralenti. Ce délai aurait pu être mis à profit pour améliorer X11, et la parité n'est toujours pas complète.
La question du choix contraint revient comme un fil rouge. GNOME a déjà désactivé la session X11 par défaut dans GNOME 49, inclus dans Fedora 43 et Ubuntu 25.10, et la suppression complète du code X11 est en cours. KDE Plasma a de son côté annoncé l'abandon total du support X11 dans la version 6.8, attendue début 2027. L'environnement Budgie a également basculé en Wayland exclusif avec sa version 10.10, posant les bases de Budgie 11. Autrement dit, « restez sur X11 si vous n'êtes pas satisfaits » est une réponse qui a une date d'expiration de plus en plus proche.
La fracture GPU : NVIDIA et le cas particulier des outils professionnels
L'expérience utilisateur sous Wayland reste profondément hétérogène selon le matériel. Les utilisateurs de cartes NVIDIA sont historiquement les plus exposés aux problèmes, liés aux choix d'implémentation du constructeur. La situation s'est significativement améliorée dans les pilotes récents, mais elle demeure l'exception la plus notable.
La configuration multi-GPU, les bureaux avec des écrans à fréquences de rafraîchissement différentes et certains usages créatifs continuent de poser des difficultés spécifiques. Des logiciels comme Bitwig, les synthétiseurs virtuels VST ou des outils d'animation 3D tels que Houdini et Maya, qui fonctionnaient bien sous Linux/X11, se comportent de façon dégradée sous Wayland, certains développeurs n'ayant pas les ressources nécessaires pour porter leurs logiciels.
Sur le plan des utilitaires du quotidien, le répertoire des outils cassés ou partiellement fonctionnels reste long : xdotool, xkill, des gestionnaires de presse-papiers comme xclip, des outils de monitoring comme WorkRave ou ActivityWatch, des barres système comme Polybar. Il n'existe pas d'API standard permettant d'obtenir la fenêtre actuellement active sous Wayland, une fonctionnalité triviale sous X11 et même sous Windows.
Le paradoxe architectural : la fragmentation comme réponse à la centralisation
Une des critiques les plus fondamentales adressées à Wayland par la communauté touche à sa philosophie de conception. En déléguant la majorité des responsabilités aux compositeurs (les gestionnaires de fenêtres qui implémentent le protocole), Wayland a transformé chaque gestionnaire de fenêtres en un mini-environnement de bureau partiel. Résultat : les développeurs d'applications ne peuvent pas s'appuyer sur des extensions de protocole représentant des comportements desktop nécessaires, car leur disponibilité et leur implémentation varient d'un compositeur à l'autre. Ce qui était un point de défaillance central unique est devenu des centaines de composants légèrement défaillants dispersés dans l'écosystème.
Cette fragmentation a une conséquence pratique directe : l'expérience utilisateur sous Sway, Hyprland, GNOME ou KDE Plasma peut varier considérablement pour un même cas d'usage : capture d'écran, partage de fenêtre, copier-coller entre applications. L'argument « ce n'est pas Wayland qui est cassé, c'est ton compositeur » est devenu une réponse type que beaucoup d'utilisateurs trouvent aussi frustrante que le problème lui-même.
Steam Deck, Wine 9 et les signaux positifs
Le tableau ne serait pas complet sans mentionner les avancées réelles. Le Steam Deck embarque Gamescope, un compositeur Wayland, pour son mode de jeu principal. La prochaine version de SteamOS devrait activer Wayland par défaut pour le mode bureau également. Wine 9.22 a introduit un moteur Wayland natif activé par défaut, réduisant considérablement la dépendance à XWayland pour les applications Windows.
La liste de suivi des problèmes connus de KDE Plasma sous Wayland (captures d'écran, partage de bureau, VNC, restauration des dispositions de fenêtres, accessibilité) reflète également l'ampleur du travail restant, mais aussi une rigueur de documentation que l'ancienne époque X11 n'imposait pas.
La comparaison avec la transition Python 2 vers Python 3, qui a elle aussi duré une décennie et provoqué des frictions durables dans l'écosystème, revient régulièrement dans les discussions. Elle suggère que la lenteur de Wayland n'est peut-être pas une anomalie mais un trait structurel des grandes migrations dans les logiciels libres où personne ne peut « décréter » une coupure.
Sources : Omar, XDA
Et vous ?
Quelle lecture faites-vous de son analyse ? La trouvez-vous pertinente ou non ? Dans quelle mesure ?
Voir aussi :
Répondre avec citation
Envoyé par OrthodoxWindows
Partager