Alacritty, Kitty et WezTerm rendent 60 fps avec 2 ms de latence — le choix se joue sur les détails
Les trois terminaux GPU dominants en 2026 offrent tous une expérience fluide et instantanée. La vraie différence n’est plus la vitesse brute, mais la philosophie : minimalisme assumé, tout-en-un intégré ou terminal programmable.
Avril 2026. Alacritty 0.17.0 sort avec le support TOML 1.1 et les redimensionnements incrémentaux sous Wayland. Juillet 2026. Kitty 0.48.1 corrige les derniers bugs de la 0.48.0, qui avait apporté le rendu fractionné des fenêtres en arrière-plan. Février 2024. WezTerm publie son dernier tag stable — et depuis, le projet avance en nightlies continues via GitHub Actions, sans jamais casser la compatibilité.
Trois terminaux, trois philosophies, une même promesse tenue : 60 images par seconde et une latence clavier-écran inférieure à 2 millisecondes. En 2026, la guerre du GPU rendering est terminée — tout le monde a gagné. Ce qui reste, c’est la question de l’architecture.
Pourquoi votre terminal utilise votre carte graphique
Un terminal classique — GNOME Terminal, Konsole, xterm — dessine chaque caractère sur le CPU, ligne par ligne, et envoie le résultat sous forme de bitmap au serveur X ou au compositeur Wayland. Quand vous faites défiler un fichier de 10 000 lignes dans less, le CPU recalcule et redessine l’intégralité de la grille de caractères à chaque rafraîchissement.
Un terminal GPU inverse la logique : chaque glyphe est mis en cache dans la mémoire vidéo (VRAM), et le rendu est délégué au GPU via OpenGL. Au lieu de redessiner 80×40 cellules à chaque frame, le terminal n’envoie que les quelques cellules qui ont changé. Résultat : un cat /dev/urandom qui faisait monter un cœur CPU à 100 % sur xterm consomme moins de 5 % sur un terminal GPU.
Les trois terminaux de cet article utilisent cette architecture. Mais ils ne la traitent pas de la même façon.
Alacritty — le minimaliste qui assume
Alacritty est écrit en Rust, maintenu par Christian Duerr et la communauté, avec 2 489 commits et 65 100 étoiles GitHub à son actif. Sa philosophie tient en une phrase du README : « Alacritty doesn’t implement tabs or splits — those are best left to a window manager or terminal multiplexer. »
Ce n’est pas un manque, c’est un choix architectural. Alacritty est un terminal, point. Pas un multiplexeur. Pas un gestionnaire de sessions. Juste une surface de rendu OpenGL pour votre shell.
Ce minimalisme a deux conséquences pratiques.
D’abord, la configuration est triviale. Un fichier TOML unique (alacritty.toml) contrôle les couleurs, les polices, les raccourcis et le comportement des fenêtres. Pas de langage de script, pas de hooks, pas de plugins. Vous voulez une fonte JetBrains Mono avec ligatures activées ? Vous installez la fonte dans votre OS et vous la référencez dans la config — Alacritty n’a pas son propre moteur de rendu de polices, il utilise FreeType comme tout le monde. C’est plus lent que le moteur maison de Kitty pour les ligatures complexes, mais ça évite les surprises de rendu.
Ensuite, vous avez besoin de tmux. Sans splits natifs, vous gérez vos volets via tmux ou votre gestionnaire de fenêtres (i3, Sway, Hyprland). Cela semble être un inconvénient jusqu’à ce que vous réalisiez que tmux apporte la persistance de session — vous fermez Alacritty, vous le rouvrez, tmux attach restaure tout. Avec Kitty ou WezTerm, la persistance dépend du daemon intégré, qui peut planter ou perdre l’état.
Alacritty est le choix de ceux qui veulent un seul outil par fonction et qui sont déjà à l’aise avec tmux. C’est aussi le plus léger des trois en empreinte mémoire : environ 40 Mo en utilisation normale, contre 80-120 Mo pour Kitty et WezTerm.
Kitty — le couteau suisse du terminal
Kitty est le projet personnel de Kovid Goyal (créateur de calibre), écrit en C et Python, avec 18 593 commits et 34 100 étoiles. Si Alacritty est un terminal, Kitty est une plateforme : rendu GPU, splits natifs, onglets, gestion des polices avec ligatures, protocole graphique pour afficher des images et des animations, extensions Python appelées kittens, shell integration, sessions nommées, et un protocole de contrôle distant.
Le chiffre qui tue : 134,55 Mo/s de débit moyen au benchmark interne (kitten __benchmark__), soit plus de deux fois le score du deuxième (GNOME Terminal à 61,83 Mo/s). Alacritty est à 54,05 Mo/s, WezTerm à 48,5 Mo/s. Kitty utilise des instructions SIMD pour parser le flux de bytes entrant — un détail d’implémentation qui se traduit par une différence mesurable quand vous cat un dump SQL de 2 Go.
La latence clavier-écran est également la meilleure de sa catégorie. Avec input_delay 0 et sync_to_monitor no, Kitty descend sous 1 ms sur du matériel récent — mesuré à la fois par Typometer sous Linux et par des tests hardware dédiés sous macOS. C’est le terminal le plus réactif que vous pouvez installer en 2026.
Les kittens sont le vrai différenciateur. Un kitten est un script Python qui interagit avec Kitty via son API interne. kitten ssh remplace le client SSH classique par un tunnel qui préserve les fonctionnalités graphiques de Kitty sur la machine distante. kitten themes vous laisse choisir un thème interactivement. kitten diff affiche un diff coloré. kitten icat affiche une image directement dans le terminal — sans ouvrir de visionneuse externe. Ces outils sont livrés avec Kitty, pas besoin de les installer séparément.
Le piège : Kitty est un écosystème vertical. Les kittens sont écrits pour Kitty et ne fonctionnent qu’avec Kitty. Le protocole graphique est une extension propriétaire — aucun autre terminal ne l’implémente. Si vous construisez votre workflow autour des fonctionnalités exclusives de Kitty, vous êtes verrouillé.
WezTerm — le terminal programmable
WezTerm est écrit en Rust par Wez Furlong (ex-Facebook/Meta), avec 8 630 commits et 28 000 étoiles. Son dernier tag stable date de février 2024, mais le projet publie des nightlies quotidiennes via GitHub Actions — et la communauté les utilise en production sans problème.
La proposition de WezTerm est unique : c’est un terminal + un multiplexeur + un runtime Lua, le tout dans un seul binaire.
Le multiplexeur intégré (wezterm-mux-server) est la killer feature. Il fait exactement ce que fait tmux, mais sans tmux. Vous lancez wezterm sur votre desktop, vous vous connectez en SSH à un serveur, vous ouvrez des volets et des onglets — et si votre connexion SSH tombe, les sessions survivent côté serveur. Reconnectez-vous, et tout est là. C’est le seul des trois qui gère ce scénario nativement, sans configuration supplémentaire.
La configuration en Lua est l’autre pilier. Votre fichier wezterm.lua est un vrai programme, pas un fichier INI amélioré. Vous pouvez :
-- Changer la couleur de fond dynamiquement selon l'heure
local wezterm = require 'wezterm'
local config = {}
config.color_scheme = wezterm.time.now():hour() > 18 and 'Tokyo Night' or 'Solarized Light'
return configCette programmabilité attire les utilisateurs qui veulent un terminal qui s’adapte à leur contexte sans externaliser la logique dans des scripts shell. Vous voulez lancer une commande spécifique quand vous ouvrez un nouvel onglet dans un dossier Git ? Une fonction Lua dans wezterm.lua. Vous voulez un affichage de la branche Git courante dans la barre de statut ? Lua. Vous voulez changer la police quand vous branchez un écran externe ? Lua.
Le prix de cette flexibilité : la documentation. WezTerm a une documentation de référence exhaustive, mais elle suppose que vous savez déjà quel composant chercher. La courbe d’apprentissage est réelle — prévoyez une soirée pour configurer votre premier environnement productif.
La force multiplateforme est un autre avantage décisif. WezTerm tourne sur Linux, macOS, Windows et FreeBSD avec exactement la même config Lua. Si vous travaillez sur un desktop Linux au bureau et un laptop Windows en déplacement, vous copiez votre wezterm.lua et tout fonctionne — polices, couleurs, raccourcis, multiplexeur. Ni Alacritty ni Kitty n’offrent cette portabilité sans ajustements manuels.
Le tableau comparatif
Le verdict
Le GPU rendering a nivelé le terrain de la performance brute. Les trois terminaux sont fluides, réactifs et agréables à utiliser. Ce qui les distingue, c’est la réponse à une question simple : comment voulez-vous gérer la complexité ?
Prenez Alacritty si vous avez déjà un workflow tmux qui fonctionne et que vous ne voulez pas qu’un terminal réinvente ce que votre multiplexeur fait très bien. C’est le plus léger, le plus simple à configurer, et le moins risqué — il ne casse rien parce qu’il ne fait presque rien en dehors du rendu.
Prenez Kitty si vous passez votre vie dans le terminal et que vous voulez le maximum de fonctionnalités sans dépendance externe. Les kittens, les performances brutes et le protocole graphique en font une plateforme que vous n’abandonnerez pas une fois que vous l’aurez adoptée. Le verrouillage est réel, mais le gain de productivité le justifie.
Prenez WezTerm si vous travaillez sur plusieurs OS, si la programmabilité de votre terminal est importante pour vous, ou si vous voulez un multiplexeur intégré qui survit aux déconnexions SSH sans configuration supplémentaire. C’est le plus lourd en ressources, mais c’est aussi le seul qui remplace à la fois votre terminal, votre multiplexeur et vos scripts shell de configuration.
En 2026, il n’y a plus de mauvais terminal GPU. Il n’y a que des choix d’architecture. Le vôtre dépend de ce que vous êtes prêt à déléguer à votre terminal — et de ce que vous préférez garder sous votre contrôle.
Références
- Alacritty v0.17.0 release notes — 6 avril 2026
- Kitty performance benchmarks — consulté le 1ᵉʳ juillet 2026
- Kitty v0.48.1 release — 24 juillet 2026
- WezTerm documentation — consulté le 1ᵉʳ juillet 2026
- WezTerm GitHub — 28 000 étoiles, consulté le 1ᵉʳ juillet 2026
- Alacritty features documentation — consulté le 1ᵉʳ juillet 2026
- Kitty keyboard protocol — consulté le 1ᵉʳ juillet 2026