Connexion Abonnez-vous

X11, Wayland : pourquoi la transition est-elle aussi longue ?

Papi en aura fait de la résistance

X11, Wayland : pourquoi la transition est-elle aussi longue ?

Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d'y voir plus clair.

Le 12 septembre 2025 à 12h00

Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.

On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.

De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.

Qu’est-ce qu’un serveur graphique ?

Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.

Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.

Il reste 88% de l'article à découvrir.

Déjà abonné ? Se connecter

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (44)

votre avatar
Les lecteurs d’écran, à destination des personnes aveugles ou malveillantes
Joli lapsus!
votre avatar
L'ai remonté via "signaler une erreur". Plus de chance que ce soit "vu" :transpi:

Article intéressant en tout cas, merci
votre avatar
C'est en voyant le logo "W" dans l'illustration que j'ai compris pourquoi quand je lance mon app, j'ai pas la même icône ...
votre avatar
Pourquoi la transition est aussi longue ? Simplement parce que ça n'est pas prêt. Wayland n'a toujours pas toutes les features de X11.
votre avatar
Ça sera toujours plus rapide que Windows avec Win32. :troll:
votre avatar
Ça n'a jamais été le but.
votre avatar
Je n'ai pas dit que c'était le but, simplement que l'on comprend aisément que les gens ne sont pas pressés de switcher vers quelque chose qui ne propose pas certaines fonctionnalités qui sont cruciales pour eux.
Sans compter que l'écosystème s'est rétréci : autant faire un window manager pour X11 c'est simple, autant un compositeur Wayland embarque bien plus de choses et est bien plus compliqué à faire ; il y a donc moins de monde qui se lance dans les compositeurs Wayland, et donc moins de choix en compositeur Wayland qu'en window manager X11 (non, il n'y a pas que Gnome et KDE dans la vie).
votre avatar
Je suis par contre d'accord qu'il aurait fallut plus de code commun entre les compositeurs.
Il y a bien wlroots, mais pas utilisé par KDE et Gnome.
votre avatar
No shit Sherlock ? 😅 Pardon, mais oui, pourquoi faire un article explicatif de 500 mots quand on peut le résumer par ...
votre avatar
J'en ai une autre à proposer : IPv4 IPv6, pourquoi la transition est-elle si longue ?
votre avatar
On peut en faire pleins des comme ça: iptables nftables, pourquoi la transistion est aussi longue alors que l'auteur de nftable est également celui d'iptables et nous explique qu'il n'existe aucune raison valable pour ne pas switcher.

encore aujourd'hui la config par défaut de fail2ban utilise iptables :kill:
votre avatar
Raah mais tu te rends pas compte, il faut remplacer iptables par nftables dans tous mes scripts !
nous explique qu'il n'existe aucune raison valable pour ne pas switcher.
Ça dépend, si tu as envie d'avoir un pare-feu moins facile à configurer et moins performant, c'est une très bonne raison pour rester sous iptables non ?
votre avatar
Moins performant, je demande à avoir des éléments concrets pour cette affirmation.

Moins facile à configurer, je peux témoigner que c'est bien plus simple après quelques années d’expérience. En plus il y a pas mal de documentations plutôt bien faites à ce sujet:

https://wiki.nftables.org/wiki-nftables/index.php/Configuring_tables

Je pencherai donc pour la paresse intellectuelle comme raison principale et non valable. Comme pour la transition IPv4 vers IPv6 en fait.
votre avatar
je ne qualifierai pas cela de paresse intellectuelle, simplement de la résistance au changement (le truc classique quoi).

pour la grande majorité des utilisateurs, nftable n'apporte rien de plus à iptables. Donc une nouvelle syntaxe, pour venir modifier des scripts qui fonctionnent déjà très bien. Est-ce que ça vaut le coup de changer ? Non.

Faire une migration, c'est compliqué, surtout quand on gère plusieurs serveurs : tu vas avoir certains serveur qui vont utiliser nftables, d'autres iptables. 2 manières différentes pour au final faire la même chose. En tout cas temporairement le temps de tout migrer. Ben non.

Certains paquet utilisent encore iptables (par ex. fail2ban). Est-ce que j'ai envie de réécrire moi-même toutes les règles pour n'utiliser que nftable ? Ben non. Donc même avec la meilleure volonté du monde, je me retrouverai avec les deux.

Et au final, pour quel gain ? Pour la très grande majorité des utilisateurs : aucun. Si ce n'est avoir perdu du temps et pris des risques pour faire cette transition, qui, à leur yeux, est inutile.

la gestion d'un parefeu, c'est quelque chose de sensible et on ne s'amuse pas à changer des choses comme ça sur un coup de masturbation intellectuelle. En attendant, iptables fait très bien son taf : il a été modifié pour tenir compte du "nouveau backend", et c'est lui qui fait toutes les traductions nécessaires.

Les gens arrêteront d'utiliser iptables le jour où il n'y aura plus de CLI iptables fourni dans les distributions.

[edit] je rajouterai une chose : il faut aussi savoir qu'iptables est considéré comme déprécié. Ce qui est loin d'être le cas de tout le monde ;)
Ne pas confondre paresse intellectuelle et pragmatisme ;)

Et pour la question ipv4/ipv6, si ils semblent similaires, ils ont quelque chose de radicalement différent : la "localité". J'entends par là que le choix iptables/nftable est un choix personnel qui ne va pas impacter le reste du monde.

Pour le choix ipv4/ipv6, pour avoir essayer de faire un serveur ipv6 only, ben c'est la merde, on peut dépendre de services qui ne sont disponibles qu'en ipv4 (coucou github !!!). Et donc, des trucs aussi basique que des installation/mises à jour peuvent échouer à cause de ça. Donc pour que la migration vers ipv6 se fasse effectivement, il faudrait qu'une très très grosse partie de web ait fait cela. Ce qui est loin d'être le cas (et quand on voit des acteurs comme github, qui devrait pour être sensibilisé à ce genre de choses et qui ont les moyens ne pas le faire, c'est pas demain la veille qu'on passera sur l'IPv6 :/)
votre avatar
Résistance au changement vs paresse intellectuelle ? Tu pinaille là :non:

Quand tu dis que nftable n'apporte rien, c'est faux ; Je suis prêt à entendre que les possibilités nouvelles offertes par nftable ne te servent pas mais tu ne peux pas affirmer que les deux font la même chose. Quelques exemples:

1 - Les règles communes qui s'appliquent à la fois à IPv4 et IPv6 permettent d'apporter de la cohérence entre les deux jeux de règles quand cela est nécessaire ;
2 - Modifier puis appliquer les nouvelles règles revient juste à éditer puis exécuter « /etc/nfttables.conf » , ce que je trouve très pratique ;
3 - Les set pour définir facilement une série d'adresses auxquelles ont peut en suite appliquer des règles, comme dans l'exemple suivant:

set ip4_crowlers_drop {
type ipv4_addr
flags interval
elements = {
#MICROSOFT-CORP-MSN-AS-BLOCK - Bing bot
40.76.0.0/14,
207.46.0.0/19,
#AS23724: CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation, CN - sogou web spider
106.38.224.0/19,
#AS208398: TELETECH, RS - Yandexbot
5.255.192.0/18,
95.108.128.0/17,
141.8.128.0/18,
178.154.128.0/19,
#14061: DIGITALOCEAN-ASN
128.199.128.0/18
}

Concernant fail2ban, cela ne change que deux lignes. Voici un extrait de mon script de modification:

#configure fail2ban pour utiliser nftables au lieu d'iptables
sed -i 's,banaction = iptables-multiport,banaction = nftables-multiport,' /etc/fail2ban/jail.conf
sed -i 's,banaction_allports = iptables-allports,banaction_allports = nftables-allports,' /etc/fail2ban/jail.conf

Trop complexe en effet....

Alors, oui, la gestion d'un firewall est quelque chose de sensible et justement, la syntaxe plus claire de nftables contribue fortement à éviter les bugs et à améliorer la maintenabilité des règles. On ne peut pas prétendre être pragmatique et ignorer les dangers des vieux trucs oubliés dont plus personne ne sais comment c'est fait.

Quand à la complexité supposée de la tâche, il existe des outils permettant de créer le fichier de config de nftables à partir des règles d'IPtables donc on ne repart pas d'une page blanche pour faire la migration.

Pour la migration IPv4 vers IPv6, je vais limiter ma réponse pour arrêter le hors sujet: ce sont les gens comme github qui rendent la chose complexe, pas le protocole lui-même qui rend tout plus simple. Je parle là d'expérience car j'ai justement un serveur qui fait tourner des VM IPv6 only.
votre avatar
Résistance au changement vs paresse intellectuelle ? Tu pinaille là :non:
Désolé si tu ne comprends la nuance entre les deux ;)
Quand tu dis que nftable n'apporte rien, c'est faux
Je n'ai pas dit que nftable n'apportait rien. Relis bien mon commentaire : il n'apporte rien pour la majorité des utilisateurs.
Pour la migration IPv4 vers IPv6, je vais limiter ma réponse pour arrêter le hors sujet: ce sont les gens comme github qui rendent la chose complexe, pas le protocole lui-même qui rend tout plus simple. Je parle là d'expérience car j'ai justement un serveur qui fait tourner des VM IPv6 only.
Ah mais là dessus, on est totalement d'accord. Il y a un gain à passer un l'IPv6. Ce qui est complexe, ce n'est pas l'IPv6, c'est la cohabitation IPv4/IPv6...
votre avatar
Résistance au changement vs paresse intellectuelle ? Tu pinaille là
La résistance au changement peut engendrer d'énormes efforts intellectuels pour ne pas vouloir bouger ;)
votre avatar
Je vais me faire un peu l'avocat du diable (car je suis d'accord avec toi quand même :D)
> 1 - Les règles communes qui s'appliquent à la fois à IPv4 et IPv6 permettent d'apporter de la cohérence entre les deux jeux de règles quand cela est nécessaire ;
Tu peux déjà le faire avec iptables:
gist.github.com GitHub
> 2 - Modifier puis appliquer les nouvelles règles revient juste à éditer puis exécuter « /etc/nfttables.conf » , ce que je trouve très pratique ;
Sauf si j'ai raté un truc, c'est pareil avec iptables: iptables-restore
> 3 - Les set pour définir facilement une série d'adresses auxquelles ont peut en suite appliquer des règles, comme dans l'exemple suivant:
Les ipset existe aussi pour iptables.

Personnellement, je trouve iptables plus simple (sûrement à cause de l'habitude) pour des besoins basiques. Même si on peut créer des chains, le fait qu'iptables arrive avec des chains prédéfinies n'incite pas à aller plus loin. On peut s'en sortir sans problème sans même savoir comment ca fonctionne. Là où avec nftables, on rentre forcement dans le sujet.
votre avatar
Alors, je disais ça d'iptables (si tu veux moins performant et plus complexe à configurer : tu choisis iptables).
votre avatar
Raah mais tu te rends pas compte, il faut remplacer iptables par nftables dans tous mes scripts !
alias iptables='nftables'

EZ

:langue:
votre avatar
A ma connaissance, iptables et nftables sont tous les deux des "frontend" permettant de configurer le sous-système netfilter. Donc en terme de performance, je pense que c'est strictement identique.

Moins pratique, plus pratique, ... c'est pas le problème à mon avis. Ce qui est chiant, c'est la période transitoire où t'as des systèmes encore en iptables et d'autre en nftables. Quand tu cherches à automatiser pour gérer des centaines de machines, bah tu t'alignes sur le plus petit dénominateur commun, iptables. Quand il n'y aura plus que des distrib avec nftables à gérer, alors ce sera le grand switch pour tout le monde en même temps.

Et pendant ce temps là, firewalld guette.
votre avatar
I stand corrected (j'étais resté dans la vieille opposition conceptuelle entre ipchains et iptables).
votre avatar
Ce serait une bêtise de faire mourir ipv4 par sa facilité de lecture sur les réseaux privés. Je ne vois pas la corrélation avec X11 et Wayland.
L'idée de faire disparaitre le protocole NAT me dépasse un peu...
votre avatar
Ce serait une bêtise de faire mourir ipv4 par sa facilité de lecture sur les réseaux privés.
Je pense que c'est un des pires arguments en faveur d'IPv4 que j'aie pu voir.
L'idée de faire disparaitre le protocole NAT me dépasse un peu...
Faire disparaître un protocole merdique fait pour rattraper les limites d'un protocole dépassé, tout en cassant la connectivité de bout en bout, mais quel pourrait être l'intérêt ?
votre avatar
Du calme rufus, le débat par le dialogue pas les aboiements.
Ton commentaire ne me sert à rien, car il ne m'apprend rien.
votre avatar
C'est toi qui entames la discussion par "ce serait une bêtise", alors qu'IPv6 est conçu pour fournir les fonctionnalités d'IPv4 (adressage global, routage, mobilité), sans en avoir les limitations.

La NAT n'apporte rien par rapport à IPv6 (permet juste de ne pas tomber en rade d'adresses), pas plus que la soi disant facilité de lecture des IPv4 (sorti des adresses RFC1918, c'est pas tellement plus lisible; et en adressage local, IPv6 peut être assez simple aussi).

La corrélation avec X11 et Wayland, c'est qu'à voir IPv4/IPv6, on peu imaginer avoir encore X11 et Wayland dans les distribs en 2040.
votre avatar
Il y a un moment, quand je commençais sur Linux, je pouvais démarrer l'ordi en mode console et faire un "startx" pour avoir une interface graphique avec fenêtres.
D'après ce que je comprends de l'article, en fait, je ne démarrais pas vraiment X11, qui se chargeait déjà de l'affichage de la console, ou il y a un raccourci dans l'article ?
votre avatar
Tu démarrais le client, le serveur était déjà en attente.
votre avatar
Non c’est bien le serveur d’affichage qui est lancé. L’introduction de l’article est d’ailleurs très trompeuse, en ce sens qu’elle suggère que le serveur serait sur le serveur. Dans une architecture de types « clients légers » / « terminaux X », c’est bien le client léger qui fait tourner le serveur d’affichage, tandis que le serveur fait tourner les applications, qui sont les clients du serveur d’affichage (c’est bon, vous avez des nœuds au cerveau ?) :D . Wikipedia détaille ça de manière plus claire : fr.wikipedia.org Wikipedia .
votre avatar
Non, les consoles textes sont gérées directement par le noyau, aucun rapport avec X11 (à part que X11 et la console teste utilisent tous les deux KMS pour gérer les modes graphiques).
Quand tu lances startx, ça lance en réalité xinit, qui lance toute une session X11 : à la fois le serveur et les clients de départ (la xsession).
votre avatar
Je pense qu'il faut aussi mentionner Wayback qui devrait permettre de faire tourner un environnement de bureau X11, directement sur wayland (à la difference de XWayland qui permet "juste" de faire tourner une application X11, pas un DE complet)
votre avatar
C'est assez le bazar quand on creuse. Par exemple, sur debian, FreeCad ne foncitonne pas sur Wayland, que sur X11. Au contraire, j'ai d'autres applis qui ne fonctionnent que sur Wayland (XWayland non compatible).
Le rendu Wayland de certaines applis non Qt sur Qt peut être très différent du rendu non Wayland (Cura3D par exemple est inutilisable sous Wayland/K - mais fonctionne sur Wayland/Gnome)
Certains jeux pâtissent au niveau perfs d'être lancés depuis Wayland (lié à OpenGL je pense, comme Freecad), d'autres c'est depuis X11 qu'ils ont des problèmes.
Même libreoffice a eu (je n'ai pas retesté) de gros écarts graphiques sur les présentations entre Wayland et X11.

En fait il y a une myriade de bugs disséminés sur toutes les applis qui font que en desktop c'est la foire si on est utilisateur un peu avancé (gaming, bureautique avancée, modélisation 3D et impression 3D pour ce que j'ai vu).
votre avatar
Super article, merci !
votre avatar
+1
votre avatar
d'un point de vue technique, il est aussi intéressant de noter l'approche radicalement différente entre X11 et Wayland :
- X11 fourni des primitives permettant de dessiner texte, lignes, etc.
- Wayland fourni uniquement des buffers

Autrement dit : une application minimaliste pouvait attaquer directement X11 pour afficher sa GUI. Avec Wayland, il faut soi-même définir des primitives de dessin (ou utiliser quelque chose de déjà existant).

En pratique, je doute qu'il y ait beaucoup d'applications "récentes" qui attaquent directement X11, mais passent plutôt par des toolkits graphiques comme Qt, Gtk, Wt, etc.
votre avatar
xeyes :)
votre avatar
X11 est aussi très pratique pour lancer en ssh à partir d'un poste sous X11, une fenêtre graphique qui exécute un programme sur un serveur en mode ligne de commande. Wayland ne sait pas le faire.
votre avatar
Waypipe ne permet de faire celà ?
votre avatar
Et même sans ssh, il m'arrive encore de faire un export DISPLAY=:0.0 , à l'ancienne , pour lancer un programme sur un autre écran... :-)
votre avatar
 La plupart des gros problèmes liés à Wayland sont aujourd’hui réglés
KiCad ne semble pas de cet avis en tout cas
We try to be pragmatic. We support what works, we document what doesn’t, and we focus our development efforts where they’ll have most benefit for our users. We will adjust our position as Wayland improves, but we won’t compromise the reliability and functionality of KiCad. For now, if you need to use KiCad on Linux, use X11.
votre avatar
Pour entrer un peu plus dans le détail, KiCad fait partie de ce genre d'applications très spécifique, notamment multifenêtrées, où des choses possibles sous X11 (sauvegarder le positionnement des fenêtres ou encore le drag&drop entre fenêtres) sont tout simplement impossible sous Wayland (et ne le seront a priori jamais).
votre avatar
Oui, c'est presque spécifique quoique pas mal de gens font de l'impression 3D et de la conception légère.
Mais X11/Wayland n'ont pas non plus le même rendu sur des applis comme libreoffice...
votre avatar
La solution et j'ai vu ça chez Windows pour certains logiciels pro de radio une fenêtre plein écran ou multi écran et à l'intérieur des pseudo fenêtre géré par le logiciel.
votre avatar
Merci pour cet article
Je n'avais qu'une connaissance très fragmentée du sujet, grâce à cet article, je comprends beaucoup mieux les dépendances et leurs impacts techniques

X11, Wayland : pourquoi la transition est-elle aussi longue ?

  • Qu’est-ce qu’un serveur graphique ?

  • Quelque part dans le noyau

  • Pourquoi un successeur à X11 ?

  • Que propose Wayland ?

  • Wayland est un protocole, pas un logiciel

  • Un nombre incalculable de problèmes

  • NVIDIA, l’élément (très) perturbateur

  • XWayland, le pont entre les deux mondes

  • Et aujourd’hui alors ?

Fermer