Gestionnaires de fenêtres tiling : l'alternative que presque personne n'envisage

Les fenêtres n’étaient pas censées se chevaucher. Du moins, c’était l’idée originelle.

Quand, dans les années septante, on réfléchit à la façon dont un écran pourrait donner de la place à plusieurs choses à la fois, personne n’imaginait un chaos de rectangles superposés. On pensait partitions. Des surfaces qui se divisent dès qu’un nouvel élément survient — comme des tables sur lesquelles on pose des livres côte à côte, sans les empiler. Les premiers systèmes à fenêtres sur les Lisp Machines de Symbolics, dans le projet Andrew de l’Université Carnegie Mellon, voire Microsoft Windows 1.0 en 1985 : tous fondés sur le tuilage. Le chevauchement comptait comme une option, non comme la norme.

Puis le chevauchement l’emporta. Apple le popularisa avec le Macintosh, Microsoft emboîta le pas, X11 sous Unix suivit. La raison n’était pas que le chevauchement fonctionnait mieux — il paraissait seulement plus intuitif. On pouvait traiter les fenêtres comme des feuilles sur un bureau, ramener celle du dessus, masquer les autres. La métaphore était saisissable. L’efficacité, elle, ne l’était pas. Qui voulait voir quelque chose de masqué devait d’abord le ramener au premier plan. Qui voulait embrasser plusieurs choses à la fois devait les disposer à la main. Le prix de la métaphore était un labeur manuel constant — un prix que plus personne ne remettait en question, car il ne semblait pas y avoir d’alternative.

Aujourd’hui, quiconque fait tourner un bureau Linux choisit généralement entre deux grands environnements : GNOME et KDE Plasma. Tous deux sont excellents. Tous deux sont flottants. Tous deux organisent les fenêtres selon le paradigme popularisé en 1984. Et presque personne ne demande si ce paradigme tient.

Ce que le tiling est véritablement

Les gestionnaires de fenêtres tiling disposent les fenêtres non pas en chevauchement mais en tuiles. Chaque nouvelle fenêtre reçoit une zone rectangulaire de l’écran ; les fenêtres existantes rétrécissent pour faire de la place. Rien n’est masqué. Chaque pixel travaille.

Deux sous-catégories existent. Le tuilage manuel — comme dans i3 — exige que vous scindiez activement les fenêtres en conteneurs ; le gestionnaire distribue l’espace en conséquence. Le tuilage dynamique — comme dans dwm, AwesomeWM ou xmonad — calcule la disposition automatiquement selon un algorithme : maître-pile, spirale, grille, peu importe. Vous ouvrez une fenêtre, le gestionnaire trie. Vous en fermez une, les autres remplissent le vide.

Le résultat ne ressemble pas à un bureau. Il ressemble à un tableau de bord. Et il modifie votre rapport à la machine.

La domination du flottant

Parlons du présent. GNOME et KDE Plasma règnent sur le bureau Linux. Tous deux livrent des environnements complets : panneau, menu d’applications, notifications, gestionnaire de fichiers, paramètres, thèmes, gestion d’affichage, gestion de session. Ils sont entièrement pris en charge. Qui les installe dispose d’un bureau fonctionnel — non d’une brique à assembler soi-même.

Ce n’est pas un défaut. C’est la raison pour laquelle la plupart restent. Un environnement de bureau est une infrastructure. Elle doit fonctionner, pas être explorée. La plupart des utilisateurs — mêmes ceux qui ont choisi Linux par conviction — n’ont guère d’appétit pour transformer un gestionnaire de fenêtres en chantier permanent.

Les distributions font leur part. Fedora, Ubuntu, openSUSE, Arch — toutes livrent un environnement flottant par défaut. Les gestionnaires tiling existent dans les dépôts, mais derrière une décision consciente : il faut aller les chercher, les installer, les configurer. Personne ne tombe sur i3 par hasard. Qui les découvre a soit cherché — soit rencontré quelqu’un qui les utilise.

Et là commence le paradoxe. La même communauté qui compare les distributions, débat des systèmes d’initialisation, s’affronte sur les formats de paquets et mène des guerres saintes d’éditeur — la communauté qui érige le choix en valeur — traite le choix du paradigme de fenêtrage comme s’il n’en existait qu’un seul. Pourtant, une alternative existe, au moins aussi rigoureuse que tout ce qui distingue Linux par ailleurs. Elle s’appelle le tiling. Et elle mène une existence dans l’ombre.

Ce qu’offrent les gestionnaires tiling

Les avantages ne sont pas romantiques. Ils sont mécaniques.

Pilotage centré clavier. Dans un gestionnaire tiling, vous naviguez principalement au clavier. Modes, bascules de focalisation, création de divisions, sauts d’espace de travail — tout est séquences de touches, aucun déplacement de souris. Celui qui passe huit heures par jour devant la machine et en passe deux à glisser des fenêtres perd du temps. Ça semble marginal. Ça s’additionne.

Exploitation pleine de la surface. Les dispositions flottantes se chevauchent. Le chevauchement signifie qu’une partie du contenu est masquée — et qu’il faut fouiller activement pour la révéler. Le tiling montre tout ce qui est ouvert, simultanément. Sur un écran ultra-large, six terminaux, un navigateur et une discussion tiennent visibles côte à côte — sans olympiade Alt-Tab.

Configuration scriptable. i3, sway, Hyprland, AwesomeWM : toutes les configurations sont des fichiers texte. AwesomeWM va plus loin — sa configuration est du code Lua. Qui veut peut générer des espaces de travail dynamiquement, router les fenêtres vers certaines surfaces selon leur titre, changer de disposition par programme. Les dotfiles deviennent reproductibles. Une configuration peut être commitée, versionnée, clonée sur une seconde machine. C’est la pensée ops appliquée au bureau.

Empreinte minimale. dwm occupe moins de deux mégaoctets résidents. sway, Hyprland, i3 — tous nettement plus légers qu’un environnement complet. Sur du matériel vieillissant, sur des clients légers, sur des machines faisant surtout du travail terminal, ce n’est pas un luxe — c’est une marge pertinente.

Flux plutôt que fragmentation. Celui qui travaille simultanément dans des terminaux, des éditeurs, des navigateurs et de la documentation jongle d’ordinaire avec ses fenêtres. Le tiling fait du jonglage l’état stable : tout visible, accessible, découvert. La gymnastique mentale de changement de contexte baisse.

Un matin comparé

Considérons un matin typique. Un administrateur entre au bureau, café à la main, et la machine attend.

Dans le monde flottant : on ouvre le lanceur, on clique sur le terminal — il apparaît au centre, masquant tout. On tire un coin, on le pousse. On ouvre un navigateur, on le coince à côté, il chevauche le terminal. On lance le lecteur de journaux, encore une fenêtre qui ne sait où aller. Au bout de dix minutes de chasse au Alt-Tab, on a six fenêtres, trois à demi couvertes, et l’on a davantage déplacé la souris que tapé au clavier.

Dans le monde tiling : Mod+Entrée ouvre un terminal — moitié gauche, automatique. Mod+Entrée encore — moitié droite, partagée. Navigateur sur l’espace 2, Mod+2, le voilà, plein cadre. Journaux sur l’espace 3, supervision sur 4, wiki sur 5. Six espaces de travail, chacun clairement assigné, atteints par les touches numériques. Les mains ne quittent pas la rangée de repos. Au bout de dix minutes, on tient la même vue d’ensemble — sans avoir déplacé une seule fenêtre.

La différence semble faible prise isolément. Elle se cumule sur huit heures, cinq jours par semaine, année après année. Qui a travaillé dans ce rythme considère l’atteinte de la souris comme une interruption — non comme un outil.

Le paysage

Le paysage des gestionnaires tiling n’est pas homogène. Un aperçu des pertinents :

i3. Le classique. Depuis 2009, maintenu par Michael Stapelberg et la communauté. Tuilage manuel, excellement documenté, prévisible. Qui apprend i3 le garde souvent. L’étalon-or pour les débutants.

sway. i3 pour Wayland. Compatible en configuration, remplaçant direct. Qui veut migrer d’i3 vers Wayland trouve ici le chemin direct.

Hyprland. Le nouveau. Natif Wayland, accéléré GPU, animé, poli. Itération rapide, parfois des ruptures entre versions. Qui privilégie la modernité à la stabilité est à bonne adresse. La communauté est grande, l’énergie haute, les angles encore rugueux.

AwesomeWM. Tuilage dynamique, scriptable en Lua, extrêmement flexible. Qui préfère programmer plutôt que configurer trouve son terrain de jeu ici. La courbe d’apprentissage est plus raide, les possibilités illimitées.

dwm. Du projet suckless. Minimaliste, code source en C comme configuration, tuilage dynamique. Qui chérit la pureté philosophique — ici. Pas de fichier de config ; on patche le source.

bspwm. Partitionnement binaire de l’espace. Les fenêtres se divisent récursivement en moitiés. Concept élégant, exécution conséquente.

xmonad. Configuré en Haskell. Pour celles et ceux qui veulent porter la pureté fonctionnelle jusque dans le gestionnaire de fenêtres.

Restent dignes de mention : herbstluftwm — tuilage manuel, configurable via un outil en ligne de commande à l’exécution — et river, un projet Wayland en ascension avec disposition dynamique.

Aucune de ces solutions n’est mauvaise. Elles diffèrent par philosophie, méthode de configuration et maturité. Mais elles partagent un trait : elles présupposent qu’on s’yengage.

Les obstacles honnêtes

Les gestionnaires tiling ne conviennent pas à tout le monde. Le dissimuler relève de l’évangélisme, non du conseil.

Courbe d’apprentissage. Les premiers jours sont inconfortables. Il faut apprendre les raccourcis, construire un modèle mental de la hiérarchie des conteneurs, restructurer les flux. Après des décennies en flottant, on attrape réflexivement la souris — et dans un setup tiling elle est souvent inutile ou contre-productive. Ça passe, mais pas instantanément.

Intégration. Un environnement de bureau fournit polkit, notifications, zone système, écran de verrouillage, gestion d’affichage, accessibilité, méthodes de saisie, cohérence de thème. Un gestionnaire tiling nu fournit : la gestion des fenêtres. Tout le reste, on l’assemble soi-même. Wayland a beaucoup amélioré les choses, mais l’effort demeure réel. Qui veut une expérience clé en main ne l’obtient pas telle quelle.

Maintenance. Les dotfiles exigent de l’entretien. Les mises à niveau peuvent casser des configurations — particulièrement avec des projets à itération rapide comme Hyprland. Qui bâtit un setup puis n’y touche plus pendant des années risque de geler. Qui suit l’amont investit périodiquement.

Défauts sobres. Les gestionnaires tiling livrent des préréglages austères. Bien quand on pense minimalisme. Moins bien quand on attend une expérience finie. La beauté émerge de la configuration — et la configuration est du travail.

Fractures de l’écosystème. Wayland a fissuré l’univers X11. Certains gestionnaires tiling sont natifs Wayland (sway, Hyprland, river), d’autres restent X11 uniquement (i3, awesome, bspwm, xmonad, dwm). Qui exploite un flux mixte doit vérifier la compatibilité. XWayland aide mais n’est pas infaillible.

Dotfiles : du désavantage à l’avantage

L’entretien des dotfiles a été nommé plus haut comme barrière — et il l’est, tant qu’on le mène seul. Un utilisateur isolé qui soigne sa propre configuration n’a personne à qui répondre hormis lui-même. Mais dès que plus d’une machine entre en jeu, la faiblesse presumée devient l’avantage décisif.

Ansible — ou des outils de templating comparables — peut tenir les dotfiles comme modèles Jinja2. Une configuration i3, un config sway, une barre polybar, un rc shell : autant de modèles avec des variables. Nom d’hôte, nom d’utilisateur, identifiants d’écran, disposition clavier, palette de couleurs — injectés par machine, variés par équipe. Un playbook, un dépôt, un appel — et tout le bureau est configuré. Pas sur une machine. Sur cent.

Idempotent. Répétable. Versionné. Le même playbook tourne sur le laptop du développeur, le serveur en rack, le client léger de la salle de conférence — et produit à chaque fois la bonne configuration depuis le même modèle. Le bureau devient infrastructure as code. Non comme un mot-clé à la mode, mais comme pratique.

Essayez la même chose avec GNOME. GNOME stocke ses paramètres dans dconf — une base de données binaire servant de backend à GSettings. L’interface est gsettings ou dconf en ligne de commande, mais ce qui se cache derrière n’est pas du texte. On ne peut ni le lire, ni le différencier, ni le tenir comme modèle. Qui veut automatiser les paramètres GNOME doit les exporter, les envelopper dans des scripts, les réimporter via dconf load — un détour par des données binaires qui résiste à toute logique de templating. Cela fonctionne, mais cela demeure un corps étranger dans le flux infrastructure-as-code.

KDE est quelque peu plus abordable à cet égard — de nombreux paramètres vivent dans des fichiers texte façon INI —, mais la cohérence est lacunaire. Certaines valeurs migrent dans des bases plasmarc, d’autres dans des fichiers rc, et la structure change entre versions majeures. Qui tente de templater un setup KDE avec Ansible lutte contre un modèle de configuration hétérogène jamais conçu pour l’automatisation.

Les gestionnaires tiling, à l’inverse, ont été bâtis pour cela. Leur configuration est du texte dès l’origine, un fichier dès l’origine, déterministe dès l’origine. Pas de base de données, pas de format binaire, pas d’état caché. Un modèle générant un config i3 est aussi naturel qu’un modèle générant un nginx.conf. Les outils cadrent parce que le matériau cadre.

Pour les équipes, cela signifie : un administrateur définit un setup tiling — espaces de travail, raccourcis clavier, couleurs, démarrage automatique — et le déploie via Ansible sur chaque machine. Les nouveaux collègues obtiennent le même bureau dès le premier jour. Les machines défectueuses sont reconstruites et convergent vers l’état cible. Un audit demande : comment le bureau est-il configuré ? La réponse se trouve dans le dépôt Git. Pas dans une base de données binaire qu’il faut d’abord extraire.

Ce n’est pas un argument cosmétique. C’est la différence entre un bureau que l’on administre et un bureau qui se laisse administrer.

À qui cela profite

Les gestionnaires tiling parlent à un type d’utilisateur spécifique.

Des développeurs travaillant simultanément dans éditeurs, terminaux, navigateurs et documentation. Des administrateurs systèmes voulant garder six sessions SSH, des journaux, du suivi et un wiki ouverts. Des data scientists ayant besoin de notebooks, REPL et fenêtres de tracé juxtaposés. Des utilisateurs avancés qui voient leur bureau comme un atelier, non comme une surface de consommation.

Mais aussi : des gens qui apprécient la reproductibilité. Qui committe ses dotfiles possède un bureau qu’on peut détruire et restaurer — en quelques secondes, sur n’importe quelle machine. Ce n’est pas un jouet. C’est une stratégie de sauvegarde pour le poste de travail.

Et des gens qui insufflent de la vie à du vieux matériel. Un gestionnaire tiling sur un ThinkPad de 2015 tourne fluidement là où un environnement complet peine. C’est pertinent économiquement et écologiquement — les appareils vivent plus longtemps quand le logiciel ne grossit pas avec eux.

Inversement : celui qui travaille avant tout dans des logiciels graphiques à palettes — retouche d’image, illustration vectorielle, montage vidéo, CAO — trouve souvent dans le tiling la mauvaise réponse. Ces outils vivent du libre agencement de grandes toiles, de palettes flottantes, de montages superposés. Les plaquer dans une grille rigide ne crée aucun avantage, seulement des frottements. Le tiling n’est pas un dogme. C’est un outil pour un certain mode de travail — et qui en a un autre ferait mieux de s’en passer.

Une question d’attitude

Les gestionnaires tiling incarnent des valeurs au cœur du mouvement open source : transparence, configurabilité, bidouillabilité, reproductibilité. La configuration est lisible. Le comportement est traçable. Les dépendances sont minimes. Personne ne décide de mon bureau à ma place.

C’est la même impulsion qui pousse vers Linux, l’auto-hébergement, les standards ouverts. Simplement au bureau — l’endroit qu’on fixe huit heures par jour et qu’on questionne pourtant le moins.

S’ajoute une culture que partagent les utilisateurs de gestionnaires tiling : la communauté des dotfiles. Les configurations sont publiées, commitées, débattues — sur des plateformes qui valent des forums à elles seules. Un setup n’est pas une propriété privée mais un brouillon que d’autres étudient, adaptent, améliorent. C’est la pensée open source à la plus petite échelle : la transparence non comme devoir mais comme allant de soi. Qui exploite ainsi un bureau ne le fait pas en consommateur mais en co-auteur.

Qui choisit KDE ou GNOME ne se trompe pas. Les deux sont des logiciels remarquables. Mais qui les choisit sans jamais avoir pesé l’alternative ne fait pas de choix. Il adopte un produit standard. Et cela, pour une communauté qui débat de chaque autre facette de son infrastructure, est remarquable.

Ce que cela signifie pour libcom.de

Depuis vingt-cinq ans je travaille avec des bureaux Linux — en mono-poste, en équipe et en entreprise. Je connais les deux côtés : la complétude arrondie d’un environnement et la rigueur puristique d’un setup tiling. Tous deux ont leur justification. La question n’est pas lequel est meilleur. La question est lequel est meilleur pour qui.

Qui vient à moi n’obtient pas de recommandation standard. Obtient une analyse : Comment travaillez-vous ? Quelles applications, quels affichages, quels flux ? Où sont les dépendances imposant un setup particulier ? Ensuite nous planifions — par étapes, documenté, réversible. Qui veut essayer le tiling n’a pas besoin de sauter à pieds joints dans l’eau froide. On peut tester, piloter, évaluer. Et si ça ne colle pas, on revient — sans perte.

Si vous vous demandez si un gestionnaire de fenêtres tiling vous convient, à vous ou votre équipe, ou si vous voulez simplement une estimation honnête de votre configuration actuelle : écrivez à contact@libcom.de. Nous faisons un inventaire honnête. Sans pression commerciale. Avec le regard sur ce qui dure à long terme.

Les fenêtres n’étaient pas faites pour se chevaucher. C’était l’idée originelle. Peut-être est-il temps de la repeser.