Le terminal a discrètement changé de rôle ces deux dernières années, et la plupart des guides d'amélioration ne l'ont pas remarqué. C'était autrefois une surface de saisie : vous lanciez des commandes, lisiez des sorties courtes, passiez à autre chose. Aujourd'hui — si Claude Code y tourne la majeure partie de la journée de travail — c'est un espace de travail pour agents : de longs flux de sortie à parcourir, plusieurs sessions en parallèle, un état qu'il faut pouvoir lire d'un coup d'œil. Ce changement de rôle est mon filtre pour cette liste. Voici les quatre améliorations qui comptent pour la façon dont le terminal est réellement utilisé en 2026 — plus un point où le conseil habituel mérite une réserve.
Amélioration 1 : l'émulateur — Ghostty
L'émulateur de terminal est la couche que l'on améliore en dernier, parce que celui intégré fonctionne techniquement. C'est aussi la couche que vous ressentez à chaque interaction, ce qui, à l'ère des agents, veut dire en permanence.
Ghostty est mon choix final. C'est le projet de Mitchell Hashimoto après HashiCorp — environ deux années de travail à plein temps avant la version 1.0 en décembre 2024 —, écrit en Zig, accéléré par GPU et véritablement natif sur chaque plateforme : Cocoa sur macOS, GTK4 sur Linux, pas d'Electron nulle part. L'argument qui m'a convaincu n'était pas une liste de fonctionnalités ; c'était que Ghostty refuse le compromis habituel entre rapide, correct et natif, en faisant tout simplement le travail nécessaire pour obtenir les trois.
Pourquoi c'est encore plus important avec les agents : une session d'agent produit des ordres de grandeur de sortie de plus que n'en ont jamais produit les commandes tapées à la main — logs de build, diffs, exécutions de tests, raisonnement en streaming. La vitesse de rendu et le comportement du scrollback cessent d'être des benchmarks et deviennent une ergonomie que vous ressentez dans la nuque et dans les yeux. Un rendu fluide et rapide de sorties énormes, c'est la différence entre parcourir confortablement le travail d'un agent et plisser les yeux devant un mur saccadé. La configuration est un simple fichier texte, ce qui signifie aussi qu'elle est versionnable et — comme il se doit — qu'un agent peut la modifier pour vous.
Si vous ne retenez qu'une amélioration de cet article, retenez celle-ci. Elle améliore chaque heure, quoi que vous fassiez tourner d'autre.
Amélioration 2 : le multiplexeur — tmux
tmux existe depuis toujours, et je ne prétendrai pas le contraire. Ce qui a changé, c'est la raison de l'apprendre. L'argument classique était la persistance : les sessions survivent aux déconnexions SSH. C'est toujours vrai et toujours précieux. L'argument de 2026 est différent : tmux est la façon de faire tourner plusieurs agents en même temps sans perdre le fil.
Une disposition qui fonctionne : une fenêtre par sujet, avec des panneaux à l'intérieur — une session d'agent, un panneau pour le serveur de dev et les logs, un panneau pour vos propres commandes. Le travail d'agents en parallèle multiplie cela : des agents distincts dans des panneaux distincts, chacun visible, chacun avec son propre scrollback. Quand je fais tourner plusieurs sessions Claude Code sur une même base de code — la configuration que j'ai détaillée dans git worktrees pour des agents en parallèle —, tmux est le cockpit qui rend cela gérable plutôt que chaotique. Détachez-vous, et les agents continuent de travailler ; rattachez-vous depuis n'importe où et tout l'espace de travail est exactement là où vous l'avez laissé. Cette persistance me protégeait autrefois d'un SSH instable. Aujourd'hui, elle protège les tâches d'agents de longue durée de l'écran de mon portable qu'on rabat.
Apprenez dix raccourcis — diviser, naviguer, zoomer, détacher, rattacher — et ignorez le reste jusqu'à ce que vous en ayez besoin. Les histoires d'horreur sur la courbe d'apprentissage viennent de gens qui ont commencé avec la config de 400 lignes de quelqu'un d'autre au lieu de dix raccourcis.
Amélioration 3 : le prompt — Starship
Améliorer son prompt, cela semble cosmétique. Ça ne l'est pas ; c'est de l'instrumentation. Starship — un prompt rapide et multi-shell écrit en Rust, configuré dans un seul fichier TOML — place dans chaque ligne de prompt l'état que je devrais sinon interroger : branche et statut git, versions des runtimes de langage, code de sortie de la dernière commande, contexte du répertoire.
Encore l'angle de l'ère des agents : quand vous supervisez des agents au lieu de taper chaque commande vous-même, votre travail consiste à lire l'état rapidement. Sur quelle branche est ce panneau ? Cette dernière commande a-t-elle échoué ? Est-ce le worktree avec l'expérience ou le stable ? Un coup d'œil au prompt répond à ces questions sans lancer git status, et sur des sessions parallèles, ces coups d'œil s'additionnent en une vraie économie d'attention.
Le côté multi-shell est le gain discret : Starship me suit d'un shell et d'une machine à l'autre avec un seul fichier de configuration, si bien que l'instrumentation est identique partout. Dix minutes de configuration, un bénéfice permanent — le meilleur rapport effort/valeur de cette liste.
Amélioration 4 : le shell — avec une réserve honnête
Le conseil habituel ici, c'est fish : autosuggestions, coloration syntaxique et complétions sensées sans aucune configuration, et depuis la version 4.0 — la grande réécriture en Rust —, il est plus rapide et plus robuste que jamais. Si vous partez de zéro ou si votre configuration actuelle est un tas de fragments de bashrc copiés-collés auxquels vous avez peur de toucher, suivez le conseil habituel. Les réglages par défaut de fish sont meilleurs que le zsh ajusté à la main de la plupart des gens, et « mieux sans configuration » est tout l'objet de cet article.
Voici la réserve : rester sur zsh est un choix légitime. Pas parce que fish est moins bon — mais parce qu'un environnement zsh accumulé fonctionne, que macOS livre zsh comme shell par défaut, et que chaque outil, script et one-liner que vous croisez suppose un shell de type POSIX. Un zsh modernisé (autosuggestions et coloration via des plugins, qui vous donnent l'essentiel de l'expérience quotidienne de fish) peut être le gagnant honnête du rapport coût/bénéfice face à la migration d'années de mémoire musculaire et de scripts utilitaires. Les guides d'amélioration qui font comme si changer de shell était gratuit vous mentent sur le coût de la migration. Le bon choix dépend de la quantité d'historique de travail que vous abandonneriez — nouveau départ, choisissez fish ; long historique zsh, modernisez sur place.
Une raison de plus, propre à l'ère des agents, pour laquelle la couche shell compte dans tous les cas : un shell prévisible et bien complété n'est plus seulement votre interface — c'est l'environnement dans lequel vos agents s'exécutent. Démarrage du shell propre, PATH sensé, pas d'alias surprises : une hygiène ennuyeuse qui rapporte doublement quand c'est quelque chose d'autre que vous qui exécute les commandes.
Ce que j'ai délibérément laissé de côté
- Les terriers de lapin des thèmes et des polices. Choisissez une police lisible avec ligatures et un thème, puis arrêtez-vous. Cette couche s'étend pour occuper tout le temps que vous lui donnez et ne rapporte plus rien après la première heure.
- Le multiplexeur du mois. Un flot continu de nouveaux gestionnaires de sessions et de multiplexeurs orientés agents ne cesse d'apparaître. Certains sont vraiment intéressants ; aucun n'a supplanté la combinaison d'ubiquité, de stabilité et de documentation de tmux. Adoptez une infrastructure ennuyeuse pour la couche dont dépendent vos agents.
- Le maximalisme des alias. Deux cents alias forment une langue privée que vous oublierez et que vos agents ne parlent pas. Les outils CLI qui améliorent réellement un workflow d'agents sont un autre sujet — j'ai présenté mes choix dans les outils CLI qui boostent Claude Code et l'ensemble plus large dans ma sélection d'outils CLI pour Claude Code.
Dans quel ordre procéder
L'émulateur d'abord (une soirée, bénéfice pour tout le reste), le prompt ensuite (dix minutes), le multiplexeur en troisième (un week-end de mémoire musculaire), le shell en dernier (une vraie décision, selon la réserve ci-dessus). Chaque amélioration se suffit à elle-même ; ensemble, elles font passer le terminal de l'outil que vous tolérez à la pièce la mieux conçue de votre maison — ce qu'il devrait être, vu la part du développement moderne qui se passe désormais à l'intérieur.
Le terminal n'est que la moitié de l'histoire ; ce qui tourne dedans en est l'autre moitié. Mes cours à l'AI School reprennent exactement à ce point — construire les workflows d'agents que cet espace de travail est fait pour accueillir.
