Votre Terminal en 4 Améliorations Qui Changent Tout
J'ai failli supprimer en masse mes dotfiles mardi dernier.
Pas parce qu'ils étaient faux — mais parce que j'ai réalisé que j'avais passé six ans à configurer un environnement de terminal qui était toujours plus lent, plus laid et plus bête que ce que quatre outils pouvaient me donner en un après-midi. Six ans d'ajustements .bashrc, de chasse aux schémas de couleurs iTerm2 et de hacks de prompt maintenus avec du ruban adhésif et des réponses Stack Overflow. Tout cela — inutile.
Ce qui m'a fait craquer, c'est de regarder un collègue partager son écran pendant une session de pair programming. Son terminal était rapide. Visiblement rapide. Pas du genre "oh, c'est réactif" — je veux dire le genre de rapidité où vous arrêtez de prêter attention à l'outil et vous concentrez uniquement sur le travail. Le rendu de texte était net. Le prompt montrait exactement ce qui comptait. Il divisait des panneaux, se déconnectait, revenait une heure plus tard, et tout était exactement où il l'avait laissé.
"Tu utilises quoi ?" lui ai-je demandé.
Quatre outils. C'est tout. Ghostty, tmux, fish et Starship. J'ai passé cette soirée à remplacer toute ma pile de terminal, et je n'ai pas regardé en arrière depuis.
Le point que la plupart des développeurs n'admettront pas : votre terminal est l'outil que vous utilisez le plus et que vous configurez le moins intentionnellement. Vous avez hérité de ce qui venait avec votre OS, vous avez boulonné quelques personnalisations au fil des ans et vous vous êtes convaincu que c'était "assez bien." Je le sais parce que c'était moi. Ce que je vais vous présenter n'est pas juste une liste de quatre outils — c'est la pile exacte qui m'a fait arrêter de penser à mon terminal et simplement commencer à l'utiliser.
Mais d'abord, je dois expliquer pourquoi le terminal que vous utilisez en ce moment vous freine probablement de manières que vous ne remarquez même pas.
Le Problème Dont Personne Ne Parle Avec les Terminaux Par Défaut
Votre émulateur de terminal par défaut — que ce soit Terminal.app sur macOS, GNOME Terminal sur Linux, ou ce que Windows livre ces jours-ci — a été conçu par un comité pour n'offenser personne. Et les outils conçus pour n'offenser personne finissent par n'inspirer personne non plus.
J'ai utilisé iTerm2 pendant des années. C'est correct. Il a des profils, des onglets, il fait le travail. Mais "fait le travail" est un standard bas pour un outil dans lequel vous passez 4 à 8 heures chaque jour. La latence s'accumule. L'expansion de la configuration s'accumule. Les petits moments où vous pensez "j'aimerais que ça marche simplement" — ceux-là aussi s'accumulent.
Ce qui a finalement fait tilt pour moi, c'est qu'une excellente configuration de terminal ne repose pas sur un seul outil. C'est quatre couches travaillant ensemble, chacune faisant une chose exceptionnellement bien :
- L'émulateur de terminal lui-même — comment le texte arrive sur votre écran
- Le gestionnaire de sessions — comment votre travail persiste et s'organise
- Le shell — comment vous interagissez avec votre système
- Le prompt — comment votre environnement communique en retour avec vous
La plupart des développeurs optimisent une ou deux de ces couches et ignorent le reste. Je vais parcourir les quatre, dans l'ordre exact où je les ai installées, avec les configurations exactes que j'utilise en ce moment. Et je serai honnête sur la seule chose dans cette pile qui m'a pris du temps à m'habituer — car ce n'est pas que de la magie instantanée.
Ghostty : L'Émulateur de Terminal Qui M'a Fait Supprimer iTerm2
Je dois être franc sur quelque chose. Quand quelqu'un me dit qu'un outil de développement est "rapide et beau," mon premier réflexe est de lever les yeux au ciel. Chaque nouvel émulateur de terminal prétend être le plus rapide. Alacritty l'a dit. Kitty l'a dit. Warp l'a dit (tout en étant aussi un IDE, une startup et un service d'abonnement).
Ghostty est différent par qui l'a construit et ce qu'ils ont choisi de NE PAS inclure.
Mitchell Hashimoto — oui, le fondateur de HashiCorp — a construit Ghostty comme un émulateur de terminal natif. Pas Electron. Pas une vue web prétendant être native. Véritablement natif, utilisant le rendu spécifique à la plateforme sur macOS (Metal) et Linux (GTK). La différence n'est pas subtile. La première fois que j'ai ouvert Ghostty et tapé une commande, j'ai pu sentir la différence de latence d'entrée. Les caractères apparaissaient au fur et à mesure que je les tapais, pas 16 millisecondes plus tard.
Voici ce que Ghostty fait bien et que les autres ratent :
Beauté sans configuration. Dès la sortie de la boîte, le rendu des polices est net, les couleurs par défaut sont sensées et le chrome de la fenêtre est minimal. J'ai passé approximativement zéro minute à configurer l'apparence de Ghostty, comparé aux heures que j'avais investies dans les profils iTerm2.
Performance native là où ça compte. Faire défiler un fichier de log de 50 000 lignes est fluide. Pas un fluide "acceptable" — vraiment fluide. Le rendu accéléré par GPU gère les grands tampons de sortie sans le saccadement que j'avais fini par accepter dans d'autres terminaux.
La simplicité comme fonctionnalité. Ghostty n'a pas d'assistant IA intégré. Il n'a pas de marketplace de plugins. Il ne veut pas être votre IDE. Il affiche du texte dans une fenêtre, extrêmement rapidement, et se retire de votre chemin. Après des années d'émulateurs de terminal essayant d'être des plateformes, cette retenue semble presque radicale.
L'obtenir est simple — rendez-vous sur ghostty.org et téléchargez-le. Sur macOS c'est une installation standard .dmg. Sur Linux, des paquets existent pour la plupart des distributions.
# Sur macOS — télécharger depuis ghostty.org
# Sur Arch Linux
pacman -S ghostty
# Sur Ubuntu/Debian (consultez ghostty.org pour le dépôt actuel)
# Le projet avance vite — vérifiez toujours la dernière méthode d'installation
Mon fichier de configuration se trouve à ~/.config/ghostty/config et il est embarrassement court :
font-family = JetBrains Mono
font-size = 14
theme = catppuccin-mocha
window-padding-x = 8
window-padding-y = 4
C'est tout. Cinq lignes. Mon plist iTerm2 faisait des milliers de lignes de XML que j'avais peur de toucher. Cinq lignes me donnent un terminal qui est plus beau et plus rapide que tout ce que j'ai utilisé en quinze ans de développement professionnel.
Mais un terminal beau et rapide n'est que la fondation. Ce dont vous avez besoin ensuite est quelque chose qui résout un problème si fondamental qu'une fois que vous l'avez, vous vous demanderez comment vous avez pu travailler sans.
tmux : Des Sessions Qui Survivent à Tout
J'ai perdu quatre heures de contexte de débogage l'année dernière parce que mon terminal a planté.
J'avais six onglets ouverts, chacun positionné dans un répertoire spécifique avec des variables d'environnement spécifiques chargées, exécutant des commandes spécifiques. J'étais plongé dans une session de débogage — le genre où vous avez construit cette carte mentale à travers de multiples processus et fichiers de log et vous approchez enfin de la cause racine. Puis macOS a décidé que mon terminal avait besoin de redémarrer pour... des raisons. Tout disparu. Chaque onglet. Chaque répertoire. Chaque processus en cours.
C'était la dernière fois que j'ai travaillé sans tmux.
tmux est un multiplexeur de terminal, ce qui est une façon élégante de dire : il gère des sessions de terminal qui existent indépendamment de votre fenêtre de terminal. Vous pouvez diviser votre écran en panneaux. Vous pouvez créer des sessions nommées pour différents projets. Et — voici la partie qui change tout — vous pouvez vous détacher d'une session et vous y rattacher plus tard, et tout est exactement comme vous l'avez laissé.
Pas "restauré." Pas "recréé." Réellement encore en cours d'exécution, comme si vous n'étiez jamais parti.
brew install tmux
Une commande. C'est l'installation. Maintenant voici comment je l'utilise réellement au quotidien.
Démarrer une session de projet :
# Créer une session nommée pour votre projet
tmux new -s myproject
# Maintenant vous êtes dans tmux — diviser verticalement
# Ctrl-b puis %
# Diviser horizontalement
# Ctrl-b puis "
# Se déplacer entre les panneaux
# Ctrl-b puis touches fléchées
Le flux de travail détacher/rattacher qui a changé ma vie :
# Se détacher de votre session (elle continue de tourner)
# Ctrl-b puis d
# Rentrez chez vous. Dormez. Revenez demain.
# Se rattacher à votre session
tmux attach -t myproject
# Tout est exactement où vous l'avez laissé
Je maintiens trois sessions persistantes : une pour mon travail de développement principal, une pour les serveurs et les logs, et une pour les tâches diverses. Chacune a sa propre disposition de panneaux. La session de développement a un panneau éditeur à gauche, un panneau terminal à droite et un panneau étroit en bas pour exécuter les tests. La session serveur a des tails de logs pour chaque service que je surveille.
Voici mon .tmux.conf minimal qui améliore significativement l'expérience :
# Remapper le préfixe de Ctrl-b à Ctrl-a (beaucoup plus facile à atteindre)
unbind C-b
set -g prefix C-a
bind C-a send-prefix
# Diviser les panneaux avec | et - (vraiment mémorisable)
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %
# Changer de panneau avec Alt-flèche sans préfixe
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D
# Activer le support souris (oui, vraiment — on est en 2026)
set -g mouse on
# Ne pas renommer les fenêtres automatiquement
set -g allow-rename off
# Commencer la numérotation des fenêtres à 1 (0 est trop loin)
set -g base-index 1
setw -g pane-base-index 1
Conseil de pro : La ligne de support souris est controversée dans les cercles tmux. Certains puristes insistent sur la navigation clavier uniquement. J'en faisais partie. Puis j'ai réalisé que je dépensais de l'énergie cognitive sur quelque chose qu'un trackpad gère instantanément. Activez le support souris. Votre productivité vous remerciera.
Je veux être honnête sur un point : tmux a une courbe d'apprentissage. La première semaine, vous oublierez la touche de préfixe. Vous fermerez des panneaux accidentellement. Vous confondrez sessions, fenêtres et panneaux. Persévérez. À la deuxième semaine, la mémoire musculaire s'installe, et à la troisième semaine, vous tressaillirez physiquement en voyant quelqu'un travailler dans un terminal sans gestion de sessions.
Les raccourcis clavier que j'ai remappés ci-dessus aident énormément — Ctrl-a est beaucoup plus naturel que Ctrl-b, et diviser avec | et - a vraiment du sens visuellement. Mais même avec une bonne configuration, attendez-vous à trois à cinq jours où vous vous sentirez plus lent avant de vous sentir plus rapide.
Si vous êtes arrivé jusqu'ici, vous avez déjà amélioré les deux couches que la plupart des développeurs ne touchent jamais — l'émulateur et le gestionnaire de sessions. Les deux prochaines améliorations sont là où les choses deviennent vraiment amusantes, car elles changent la façon dont vous interagissez avec votre shell chaque seconde.
fish : Le Shell Qui M'a Fait Abandonner 20 Ans de Bash
J'ai une confession à faire. J'ai résisté au changement de shell pendant deux décennies.
Bash fonctionne partout. Chaque serveur, chaque conteneur, chaque pipeline CI — bash est là. Je connaissais ses bizarreries. Je savais que [[ ]] est différent de [ ]. Je connaissais la syntaxe étrange d'expansion de paramètres. J'avais mémorisé assez de one-liners sed et awk pour me sentir compétent. Changer de shell me semblait comme changer de langue parlée — techniquement possible, mais pourquoi volontairement se rendre moins fluent ?
Puis j'ai regardé quelqu'un utiliser fish pendant dix minutes, et chaque excuse que j'avais s'est évaporée.
fish — le Friendly Interactive Shell — fait trois choses que bash ne fait pas, et il les fait directement, sans aucune configuration :
Des autosuggestions qui fonctionnent vraiment. Au fur et à mesure que vous tapez, fish affiche une suggestion grise basée sur votre historique de commandes. Ce n'est pas de la tab-completion — ce sont des suggestions en ligne en temps réel qui apparaissent pendant que vous tapez. Appuyez sur la touche flèche droite pour accepter. Ça semble mineur jusqu'à ce que vous réalisiez que vous complétez 60% de vos commandes avec une seule touche. Vos commandes git les plus courantes, vos chemins de projet spécifiques, vos incantations Docker — fish les retient toutes et les propose avant que vous ayez fini de taper.
Coloration syntaxique en temps réel. Les commandes valides apparaissent dans une couleur. Les commandes invalides apparaissent en rouge. Avant que vous appuyiez sur entrée. Je ne saurais trop insister sur le temps que cela économise. Plus d'erreurs "command not found" parce que vous avez tapé dcoker au lieu de docker. Vous voyez le texte rouge, corrigez la faute de frappe et continuez — le tout avant d'exécuter quoi que ce soit.
Des valeurs par défaut de scripting sensées. Les variables fonctionnent comme vous l'attendriez. La manipulation de chaînes est lisible. La syntaxe if/else/end se lit comme de l'anglais réel au lieu du fi et esac de bash (qui, oui, sont juste "if" et "case" écrits à l'envers — et oui, ça m'agace toujours).
brew install fish
Après l'installation, vous voudrez en faire votre shell par défaut :
# Ajouter fish aux shells autorisés
echo /opt/homebrew/bin/fish | sudo tee -a /etc/shells
# Définir comme défaut
chsh -s /opt/homebrew/bin/fish
Maintenant, je dois aborder l'éléphant dans la pièce : fish n'est pas conforme à POSIX. Vos scripts bash ne fonctionneront pas dans fish. Vos variables d'environnement .bashrc ne se transféreront pas automatiquement. Ça semble rédhibitoire. Ça ne l'est pas. Voici pourquoi.
Vous n'écrivez pas de scripts en fish. Vous écrivez des scripts en bash (ou sh) — la ligne shebang (#!/bin/bash) gère ça automatiquement. Fish est votre shell interactif — l'interface où vous tapez des commandes. Les scripts d'automatisation restent en bash. Ce sont deux cas d'utilisation complètement différents, et les confondre est la raison pour laquelle la plupart des gens n'essaient jamais un meilleur shell interactif.
Pour les variables d'environnement, fish utilise une syntaxe différente :
# bash: export PATH="$HOME/.local/bin:$PATH"
# fish:
set -gx PATH $HOME/.local/bin $PATH
# Ou pour les variables persistantes (survivent aux redémarrages) :
set -Ux EDITOR nvim
Mon ~/.config/fish/config.fish est minimal parce que fish n'a presque besoin de rien :
# C'est véritablement tout — fish gère le reste
set -gx EDITOR nvim
set -gx GPG_TTY (tty)
# Alias (fish les appelle abréviations)
abbr -a g git
abbr -a gc "git commit"
abbr -a gp "git push"
abbr -a ll "ls -la"
abbr -a dc "docker compose"
Le système d'abréviations est secrètement brillant. Contrairement aux alias, les abréviations s'expansent en ligne quand vous appuyez sur espace. Quand vous tapez gc et appuyez sur espace, ça se transforme en git commit directement dans votre prompt. Cela signifie que vous voyez la commande complète avant de l'exécuter, votre historique reste lisible et vous développez une mémoire musculaire pour les abréviations sans perdre conscience de ce que vous exécutez réellement.
Il y a encore une chose à propos de fish qui m'a convaincu, et personne ne semble la mentionner : l'outil de configuration basé sur le web.
fish_config
Cela ouvre une interface dans le navigateur où vous pouvez prévisualiser et sélectionner des schémas de couleurs, configurer votre prompt, gérer les abréviations et ajuster les paramètres — le tout sans éditer de fichiers de configuration. Est-ce nécessaire ? Non. Est-ce étonnamment agréable la première fois que vous l'utilisez ? Absolument.
Je veux donner un avertissement honnête. Si vous faites du pair programming ou partagez des terminaux fréquemment, vous devrez occasionnellement taper une commande compatible bash et vous rappeler que vous êtes dans fish. L'opérateur &&, par exemple, fonctionne différemment (fish utilise and ou ;). Après environ un mois, cela devient une seconde nature — mais ce premier mois a quelques moments "ah oui, je suis dans fish."
Bien — vous avez un terminal rapide, des sessions persistantes et un shell intelligent. Il reste une pièce, et c'est celle qui lie tout visuellement.
Starship : Un Prompt Qui Vous Montre Ce Qui Compte
Avant Starship, mon prompt était un fouillis de configuration spécifique au shell qui cassait chaque fois que je changeais de machine.
J'avais un prompt bash personnalisé avec détection de branche git, affichage de virtualenv Python, indicateurs de code de sortie et contexte kubectl. C'était environ 40 lignes de script bash que j'avais accumulées au fil des ans. Ça marchait sur ma machine. Ça ne marchait pas sur la machine de mon collègue. Ça ne marchait définitivement pas dans fish (shell différent, syntaxe de prompt différente). Et c'était lent — je pouvais voir le délai entre appuyer sur entrée et l'apparition du nouveau prompt parce que toutes ces vérifications de statut s'exécutaient de manière synchrone.
Starship a résolu chacun de ces problèmes.
Starship est un prompt cross-shell écrit en Rust. Un seul fichier de configuration fonctionne avec bash, zsh, fish, PowerShell — n'importe quel shell. Il est rapide parce qu'il est compilé, et intelligent parce qu'il ne vous montre que les informations pertinentes pour votre contexte actuel.
brew install starship
Pour fish, ajoutez une ligne à votre configuration :
# Ajouter à ~/.config/fish/config.fish
starship init fish | source
Directement — sans aucune configuration — Starship vous montre :
- Votre répertoire actuel (abrégé intelligemment)
- Branche et statut Git (fichiers modifiés, compteurs ahead/behind, indicateur de stash)
- Le code de sortie de la dernière commande (uniquement en cas d'échec — pas de bruit quand tout fonctionne)
- L'environnement de programmation actif (version Node, version Python, version Rust — uniquement quand des fichiers pertinents existent dans le répertoire)
- La durée de la commande (uniquement pour les commandes qui prennent plus de 2 secondes)
Ce dernier point est la clé de la philosophie de Starship : montrer ce qui compte, cacher ce qui ne compte pas. Vous n'avez pas besoin de voir votre version de Node quand vous êtes dans un répertoire de projet Rust. Vous n'avez pas besoin de voir la durée de commande pour les commandes instantanées. Vous n'avez pas besoin d'un indicateur de succès quand le succès est la norme.
Mon ~/.config/starship.toml est court parce que les valeurs par défaut sont excellentes :
# Légèrement personnalisé — principalement des ajustements de format
[character]
success_symbol = "[➜](bold green)"
error_symbol = "[✗](bold red)"
[git_branch]
symbol = " "
[git_status]
modified = "!"
untracked = "?"
ahead = "⇡"
behind = "⇣"
[directory]
truncation_length = 3
truncation_symbol = "…/"
[cmd_duration]
min_time = 2_000
show_milliseconds = false
[nodejs]
symbol = " "
[python]
symbol = " "
[rust]
symbol = " "
Voici à quoi ressemble mon prompt en pratique :
…/ai-agents-team main !2 ?1 ➜
Cela me dit : je suis dans le répertoire ai-agents-team, sur la branche main, avec 2 fichiers modifiés et 1 fichier non suivi. Le tout sans exécuter git status. Le tout rendu en moins de 10 millisecondes.
Conseil de pro : Si vous venez de Oh My Zsh ou Powerlevel10k, Starship vous semblera familier mais plus léger. Vous perdez certains segments de prompt plus exotiques, mais vous gagnez en simplicité de configuration et en véritable compatibilité cross-shell. J'ai fait l'échange et les extras ne m'ont pas manqué une seule fois.
La différence de vitesse est mesurable. Mon ancien prompt personnalisé ajoutait 200-400ms de latence à chaque rendu de prompt. Starship rend systématiquement en moins de 50ms, même avec des vérifications de statut git sur de grands dépôts. Sur une journée avec des centaines d'exécutions de commandes, cette économie de latence est significative — pas seulement en temps brut, mais dans la sensation de réactivité qui vous maintient dans le flow.
Ce que j'apprécie particulièrement chez Starship, c'est qu'il respecte votre attention. Le prompt est un élément d'interface que vous regardez des milliers de fois par jour. La plupart des outils de prompt essaient de fourrer le maximum d'informations dans cet espace. Starship prend l'approche opposée : montrer l'information minimale utile, et la montrer vite.
Tout Assembler : L'Installation Complète
Voici toute la configuration en partant de zéro. Si vous avez un Mac neuf avec Homebrew installé, voici tout ce qu'il faut :
# Étape 1 : Installer les outils
brew install tmux fish starship
# Télécharger Ghostty depuis ghostty.org
# Étape 2 : Définir fish comme shell par défaut
echo /opt/homebrew/bin/fish | sudo tee -a /etc/shells
chsh -s /opt/homebrew/bin/fish
# Étape 3 : Ajouter starship à fish
echo 'starship init fish | source' >> ~/.config/fish/config.fish
# Étape 4 : Créer la configuration tmux (optionnel mais recommandé)
# Copier le .tmux.conf de la section tmux ci-dessus
# Étape 5 : Ouvrir Ghostty et commencer à travailler
Cinq commandes (plus un téléchargement). C'est la distance entre le terminal que vous avez maintenant et le terminal que vous voulez vraiment.
L'ordre compte, d'ailleurs. Installez Ghostty d'abord parce que vous voulez tout expérimenter dedans. Puis tmux, parce que la persistance de session doit tourner dès le premier jour. Puis fish, parce qu'il transforme votre expérience interactive. Puis Starship, parce qu'il ne compte qu'une fois votre shell configuré.
À quoi s'attendre le premier jour : Tout semble légèrement peu familier. Votre mémoire musculaire va se battre contre vous sur les raccourcis tmux. Les différences de syntaxe de fish vous surprendront une ou deux fois. C'est normal.
À quoi s'attendre le septième jour : La touche de préfixe tmux est automatique. Les autosuggestions de fish complètent la moitié de vos commandes. Vous avez arrêté de penser à votre prompt parce que Starship vous montre simplement ce dont vous avez besoin.
À quoi s'attendre le trentième jour : Vous vous asseyez devant la machine de quelqu'un d'autre et ressentez immédiatement la friction de son terminal par défaut. Vous remarquez physiquement la latence d'entrée. Les autosuggestions vous manquent. Vous réalisez — viscéralement — à quel point votre configuration est meilleure.
Les Compromis Honnêtes Que Personne Ne Mentionne
Je vous rendrais un mauvais service si je présentais cela comme que du positif. Chaque outil a ses compromis, et je préfère que vous y alliez les yeux ouverts.
Ghostty est jeune. Il est disponible publiquement depuis fin 2024 et bien qu'il soit remarquablement stable pour son âge, vous tomberez occasionnellement sur des cas limites. J'ai rencontré exactement deux glitchs de rendu en trois mois d'utilisation quotidienne — tous deux corrigés en une semaine par la communauté active de contributeurs. Si vous avez besoin d'une stabilité absolument à toute épreuve et que le rendu plus lent ne vous dérange pas, iTerm2 ou Kitty restent d'excellents choix.
tmux ajoute une surcharge cognitive. Il y a une raison pour laquelle la plupart des développeurs n'utilisent pas de multiplexeur de terminal — c'est une couche d'abstraction supplémentaire à gérer. Le système de touche de préfixe semble maladroit au début. Le comportement du copier-coller change (vous devrez maintenir Option/Alt pour utiliser le presse-papiers système dans tmux, ou configurer l'intégration du presse-papiers). Certaines applications en terminal ne fonctionnent pas bien avec l'émulation de terminal de tmux. Ce sont de vrais points de friction qui prennent deux à trois semaines pour se lisser complètement.
fish casse vos dotfiles. Si vous avez un .bashrc ou .zshrc soigneusement élaboré, rien ne se transfère directement. Les variables d'environnement nécessitent une migration manuelle. Les fonctions personnalisées doivent être réécrites. Cela m'a pris environ 45 minutes pour ma configuration — votre kilométrage variera selon la complexité.
Starship ne peut pas tout faire comme Powerlevel10k. Si vous utilisez une configuration P10K avancée avec des prompts transitoires, un prompt instantané et des segments personnalisés — Starship est un pas en arrière en termes de personnalisation pure. Ce que vous gagnez, c'est la simplicité et la compatibilité cross-shell. Pour 90% des développeurs, c'est le bon compromis.
J'ai appris quelque chose en construisant cette pile qui s'applique au-delà des outils de terminal : la meilleure expérience développeur ne vient pas d'un outil incroyable. Elle vient de quatre bons outils qui font chacun une chose bien et restent hors du chemin les uns des autres. Ghostty affiche du texte. tmux gère les sessions. fish s'occupe de l'interaction. Starship montre le statut. Pas de chevauchement. Pas de conflits. Pas de fichiers de configuration de 600 lignes.
Ce Qui a Réellement Changé Après 30 Jours
J'ai suivi mon utilisation du terminal pendant un mois après avoir fait le changement, parce que je suis le genre de personne qui mesure les choses avant de les déclarer bonnes. Voici ce que les chiffres ont montré.
La vitesse d'exécution des commandes n'a pas changé. Les outils en eux-mêmes ne font pas compiler votre code plus vite ou tourner vos tests plus rapidement. Quiconque vous dit qu'un shell différent rend vos programmes plus rapides essaie de vous vendre quelque chose.
La vitesse de saisie des commandes s'est améliorée d'environ 30%. Les autosuggestions et abréviations de fish signifient moins de frappes pour les opérations courantes. J'ai mesuré cela informellement en chronométrant mon flux de travail git typique — stage, commit, push — avant et après. C'est passé d'environ 8 secondes de frappe à environ 5.
Le changement de contexte a chuté de façon spectaculaire. Avant tmux, passer d'un projet à l'autre signifiait fermer des onglets, naviguer vers des répertoires et reconstruire mon modèle mental de l'emplacement de chaque chose. Maintenant je tape tmux attach -t projectname et je suis exactement où j'en étais. Mes logs continuent de défiler. Mon lanceur de tests continue d'afficher les résultats. Le coût cognitif du changement est passé de "j'ai besoin d'une minute pour m'installer" à "j'y suis déjà."
La latence du prompt est passée de notable à invisible. Celle-ci m'a le plus surpris. Je ne réalisais pas à quel point le délai de 300ms de mon ancien prompt cassait mon flow jusqu'à ce qu'il disparaisse. Le rendu quasi-instantané de Starship crée un sentiment subtil mais réel de réactivité qui vous maintient engagé dans votre travail.
La victoire inattendue : les sessions SSH. Parce que tmux tourne côté serveur, mes sessions distantes survivent aux coupures réseau. Je fais un SSH vers un serveur, je m'attache à une session tmux, et si mon WiFi a un hoquet — je me reconnecte et me rattache. Pas de travail perdu. Pas de moments "qu'est-ce que je faisais ?" Pour quiconque travaille régulièrement avec des serveurs distants, cela seul justifie toute la configuration.
Probablement la métrique la plus révélatrice : j'ai arrêté de configurer mon terminal. Avant cette pile, j'ajustais quelque chose chaque semaine — une couleur ici, un raccourci là, une mise à jour de plugin qui cassait autre chose. Le mois dernier, j'ai changé exactement un paramètre (augmenté la taille de ma police de 13 à 14 parce que j'ai eu de nouvelles lunettes). La configuration fonctionne, et j'ai redirigé cette énergie de configuration vers le vrai travail d'ingénierie.
Votre Futur Vous Vous Remerciera
Vingt minutes. C'est à peu près le temps que prend l'installation complète, du brew install à la configuration fonctionnelle. Vingt minutes pour remplacer une pile de terminal que vous tolérez depuis des années par une qui respecte réellement votre temps et votre attention.
Je pense à ce collègue dont le partage d'écran a tout déclenché. Il ne m'a pas montré une démo tape-à-l'œil ni guidé à travers un argumentaire de vente. Il a simplement travaillé — et ses outils étaient si fluides que l'absence de friction était en elle-même remarquable. C'est ce que font les bons outils. Ils disparaissent. Ils vous laissent vous concentrer sur ce pour quoi vous vous êtes réellement assis.
Alors voici votre mission : bloquez 20 minutes cette semaine. Installez les quatre outils. Donnez-vous une semaine pour vous adapter. Et le huitième jour, essayez de revenir à votre ancienne configuration.
Vous n'y arriverez pas.
brew install tmux fish starship
# + ghostty.org pour le terminal lui-même
Quatre outils. Un après-midi. Un terminal que votre futur vous vous remerciera sincèrement d'avoir construit.
🤝 Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.
- 🔗 Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
- 🌐 Portfolio : mejba.me
- 🏢 Ramlit Limited (solutions entreprise) : ramlit.com
- 🎨 ColorPark (design et branding) : colorpark.io
- 🛡 xCyberSecurity (services de sécurité) : xcybersecurity.io
