On a déjà tous passé 10 minutes à chercher dans notre historique bash LA commande SSH avec tous les bons paramètres pour nous connecter à ce foutu serveur obscur qu’on a configuré il y a 3 mois… Port custom, clé spécifique, nom d’utilisateur bizarre… Un vrai cauchemar. Et du coup, je me suis souvenu d’un outil dont on m’avait parlé y’a pas longtemps : GGH .

Écrit en Go par Binyamin Yawitz, ce petit outil CLI garde en mémoire toutes vos sessions SSH et vous permet de les retrouver instantanément. Plus besoin de fouiller dans votre historique comme un archéologue ou de maintenir un fichier notes.txt avec toutes vos connexions.

Le principe est con comme la lune… à chaque fois que vous utilisez GGH pour vous connecter, il enregistre tout (hôte, utilisateur, port, clé). Après, vous tapez juste ggh et vous avez une liste interactive de toutes vos sessions précédentes. Vous pouvez même filtrer en tapant quelques lettres, comme ggh - stage pour retrouver tous vos serveurs de staging.

Pour l’installer, c’est rapide. Sur Unix/Linux/Mac, une petite ligne de curl :

curl https://raw.githubusercontent.com/byawitz/ggh/master/install/unix.sh | sh

Sur Windows avec PowerShell :

powershell -c "irm https://raw.githubusercontent.com/byawitz/ggh/master/install/windows.ps1 | iex"

Ou si vous avez Go installé :

go install github.com/byawitz/ggh@latest

Une fois installé, utilisez-le exactement comme SSH. Par exemple :

ggh [email protected]
ggh [email protected] -p2222

La magie opère quand vous tapez simplement ggh sans paramètres. Vous obtenez une liste interactive de toutes vos connexions précédentes, triées par fréquence d’utilisation. Flèche haut/bas pour naviguer, Entrée pour se connecter. Simple et efficace.

Ce qui est malin, c’est que GGH lit aussi votre fichier ~/.ssh/config. Du coup, si vous tapez ggh -, vous avez accès à tous vos hôtes configurés. Et vous pouvez filtrer directement, genre ggh - prod pour voir uniquement vos serveurs de production.

Notez que GGH ne remplace pas SSH. C’est juste un wrapper intelligent qui facilite la vie. SSH doit encore être installé sur votre système pour que GGH fonctionne. L’outil se contente juste de mémoriser vos connexions et de relancer les bonnes commandes SSH.

Le projet est open source sous licence Apache 2.0, le code est propre, écrit à 80% en Go, et l’outil reste super léger. Pas de dépendances folles, pas de configuration complexe. Ça fait le job, point.

Quelques commandes utiles à connaître :

• ggh --config pour voir où sont stockées vos configs
• ggh --history pour accéder directement à l’historique
• ggh tout seul pour la liste interactive

Voilà, si comme moi vous en avez marre de chercher vos commandes SSH dans votre historique ou de maintenir des alias à n’en plus finir, donnez une chance à GGH , vous m’en direz des nouvelles.

Windows Terminal 1.23 est désormais disponible en téléchargement. Les nouveautés sont nombreuses. Voici les faits les plus marquants.

Cet article Windows Terminal : Microsoft introduit une nouvelle architecture et un menu repensé a été publié en premier par GinjFo.

Vous la connaissez cette fatigue de quand vous lancez votre serveur de dev et que ce satané message d’erreur EADDRINUSE vous annonce que le port 3000 est déjà utilisé ? Et bien moi oui, et visiblement je ne suis pas le seul puiqu’un développeur de talent a décidé que c’était la goutte d’eau et a créé Port Kill , une petite app macOS qui vit tranquillement dans votre barre de menu et qui surveille les ports ouverts comme le vigile de Franprix vous surveille.

Comme ça, au lieu de jouer au jeu du chat et de la souris avec lsof, netstat et kill dans votre terminal, Port Kill scanne automatiquement tous les ports entre 2000 et 6000 toutes les 5 secondes et vous dit ce qui est ouvert. Alors pourquoi cette plage ? Hé bien parce que c’est là que la plupart d’entre nous faisons tourner nos serveurs de développement. React sur 3000, Vue sur 8080, votre API custom sur 5000… Vous voyez le tableau.

Ce qui est sympa avec Port Kill, c’est l’interface. L’icône dans la barre de menu change de couleur selon le nombre de processus détectés. Vert quand tout est clean, rouge quand vous avez entre 1 et 9 processus qui traînent, et orange quand ça part en cacahuète avec plus de 10 processus. Un clic sur l’icône et vous avez la liste complète avec la possibilité de tuer chaque processus individuellement ou de faire table rase d’un coup.

Techniquement, c’est du solide puisque c’est écrit en Rust (hé oui parce qu’en 2025, si c’est pas du Rust, c’est has-been), l’app utilise les commandes système lsof pour détecter les processus. Et la stratégie de kill de l’outil est plutôt intelligente puisqu’il fait d’abord un SIGTERM poli pour demander gentiment au processus de se barrer, et si au bout de 500ms ce dernier fait le têtu, PAF, un SIGKILL dans les dents. C’est la méthode douce-ferme, comme quand vous demandez à votre chat de descendre du clavier.

Le contexte, c’est qu’on a tous galéré avec ça. L’erreur EADDRINUSE est un classique du dev web. Vous fermez mal votre serveur avec Ctrl+C, ou pire, vous fermez juste la fenêtre du terminal, et hop, le processus continue de tourner en arrière-plan comme un zombie. Sur macOS, c’est encore plus vicieux depuis Monterey avec AirPlay qui squatte le port 5000 par défaut.

Il existe d’autres solutions, bien sûr. Par exemple, Killport est autre un outil en ligne de commande cross-platform écrit aussi en Rust qui fait un job similaire. kill-my-port est un package npm qui fait la même chose. Mais ces outils nécessitent de passer par le terminal à chaque fois. Port Kill, lui, est toujours là, discret dans votre barre de menu, prêt à dégainer.

L’installation est simple : vous clonez le repo GitHub, un petit cargo build --release si vous avez Rust installé, et vous lancez avec ./run.sh. L’app tourne en tâche de fond, consomme quasi rien en ressources, et met à jour son menu contextuel toutes les 3 secondes. Pas de fenêtre principale, pas de configuration compliquée, juste l’essentiel.

Pour les puristes du terminal, oui, vous pouvez toujours faire lsof -ti:3000 | xargs kill -9. Mais franchement, avoir une interface graphique pour ce genre de tâche répétitive, c’est pas du luxe. Surtout quand vous jonglez entre plusieurs projets et que vous ne vous rappelez plus quel port utilise quoi.

Le seul bémol, c’est que c’est limité à macOS pour l’instant donc les développeurs sur Linux et Windows devront se contenter des alternatives en CLI. Mais bon, vu que le code est open source, rien n’empêche quelqu’un de motivé de faire un portage.

Voilà, donc si comme moi vous en avez marre de cette danse répétitive pour trouver et tuer le processus qui squatte votre port, Port Kill mérite que vous y jetiez un oeil.

Si comme moi, vous jonglez avec une dizaine de serveurs SSH différents et que votre fichier ~/.ssh/config ressemble à un roman de Marcel Proust, je vous ai trouvé un petit outil bien sympa qui pourrait vous faciliter grandement la vie. Ça s’appelle SSH-List et c’est un gestionnaire de connexions SSH codé en Rust et équipé d’une jolie une interface TUI (Text User Interface) plutôt bien pensée.

Ce qui me plaît avec SSH-List, c’est sa philosophie minimaliste car contrairement à certains mastodontes comme Termius , Tabby ou SecureCRT qui essaient de tout faire, lui reste focus sur l’essentiel, à savoir gérer vos connexions SSH, point. Et pour beaucoup d’entre nous qui passons notre vie dans le terminal au détriment de notre famille, c’est exactement ce qu’il nous faut.

L’outil a été développé par Akinoiro et propose toutes les fonctionnalités de base dont vous avez besoin telles que ajouter, éditer, copier et trier vos connexions SSH. Vous pouvez même définir des options SSH personnalisées et exécuter des commandes directement sur vos hôtes distants. Et cerise sur le gâteau, il peut importer automatiquement vos hôtes existants depuis votre fichier ~/.ssh/config.

Pratique pour migrer en douceur.

Un point sécurité qui mérite d’être souligné c’est que SSH-List ne stocke aucun mot de passe. L’outil vous encourage même à utiliser des clés SSH pour l’authentification, ce qui est de toute façon la bonne pratique à adopter en 2025. Toute votre configuration est sauvegardée dans un simple fichier JSON ici ~/.ssh/ssh-list.json, donc vous gardez le contrôle total sur vos données.

Maintenant, pour l’installation, vous avez l’embarras du choix. Si vous êtes sur Arch Linux, un petit paru -S ssh-list via l’AUR et c’est réglé. Sur Ubuntu ou Linux Mint, il y a un PPA dédié :

sudo add-apt-repository ppa:akinoiro/ssh-list
sudo apt update
sudo apt install ssh-list

Pour les puristes ou ceux sur d’autres distributions, vous pouvez l’installer via Cargo (le gestionnaire de paquets Rust) avec un simple cargo install ssh-list, ou compiler directement depuis les sources si vous êtes du genre à aimer avoir la main sur tout.

L’interface TUI est vraiment intuitive. Vous naviguez dans votre liste de connexions avec les flèches, vous appuyez sur Entrée pour vous connecter, et vous avez des raccourcis clavier pour toutes les actions courantes. C’est simple, efficace, et ça reste dans l’esprit terminal qu’on aime tant.

Ce qui différencie SSH-List des autres gestionnaires de connexions SSH disponibles, c’est justement cette approche sans chichi. Pas de fonctionnalités inutiles, pas d’interface graphique lourde, juste ce qu’il faut pour bosser efficacement. C’est un peu l’antithèse de solutions comme MobaXterm ou mRemoteNG qui essaient de gérer tous les protocoles possibles et imaginables.

Si vous cherchez une alternative légère à des outils comme sshs ou sgh (qui font à peu près la même chose mais avec des approches différentes), SSH-List mérite également le détour et le fait qu’il soit écrit en Rust garantit des performances au top et une utilisation mémoire minimale. Deux points non négligeables quand on passe sa journée avec 50 onglets de terminal ouverts.

Alors non, SSH-List ne va pas changer drastiquement votre façon de travailler, mais il va clairement la simplifier.

C’est par ici que ça se passe .

Vous recevez un fichier Word et votre premier réflexe, en bon libriste, c’est de lancer LibreOffice qui met 30 minutes à démarrer, juste pour lire trois paragraphes. Ou pire, vous êtes en SSH sur un serveur et là, c’est le drame total, impossible de lire un doc Word là bas. Hé bien ce bon Ben Greenwell en a eu marre de cette galère et a créé doxx , un outil écrit en Rust qui affiche vos .docx directement dans le terminal.

Ce concept m’a rappelé Glow , vous savez, ce magnifique renderer Markdown pour terminal créé par l’équipe de Charm, sauf qu’ici, on s’attaque à un format bien plus casse-pieds : les fichiers Word.

Doxx gère donc non seulement le texte formaté, mais aussi les tableaux avec de jolies bordures Unicode, les listes, et même les images si votre terminal le supporte (Kitty, iTerm2, WezTerm). Et comme c’est écrit en Rust, il parse le XML des fichiers .docx en un clin d’œil.

Pour utiliser l’outil, rien de plus simple :

doxx rapport.docx

Et boom, votre document s’affiche. Vous cherchez quelque chose ?

doxx contrat.docx --search "paiement"

Et il vous surligne toutes les occurrences. Il peut aussi exporter vers d’autres formats comme le Markdown, le CSV pour les tableaux, le JSON pour les devs, ou du plain text pour les puristes.

Pour l’installer, si vous êtes sur macOS avec Homebrew, c’est

brew install doxx

Et pour les rustacés :

cargo install doxx

Les utilisateurs d’Arch ont leur paquet AUR, et il y a même une option Nix et Conda. Bref, peu importe votre setup, vous devriez pouvoir l’installer.

Alors comment ce truc fonctionne pour afficher le format de Microsoft dans le terminal. Et bien c’est simple vous allez voir. En fait, les fichiers .docx sont des archives ZIP contenant du XML. Donc techniquement, vous pourriez les dézipper et parser le XML vous-même avec sed ou awk. Mais qui a envie de faire ça ?

C’est pourquoi doxx utilise la bibliothèque docx-rs pour le parsing, ratatui pour l’interface terminal interactive, et viuer pour l’affichage des images. Bref, c’est solide. Il y a même déjà un port en Go créé par keskinonur qui maintient la parité des fonctionnalités.

Alors oui, Doxx ce n’est pas un éditeur mais juste un viewer mais je trouve quand même que c’est bien pratique ! Donc si vous en avez marre de lancer des applications lourdes juste pour consulter un fichier Word, cet outil mérite clairement le détour.

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?

Si vous êtes du genre à passer votre vie en SSH sur des serveurs distants comme moi, alors voici un petit outil bien sympa qui va peut-être changer votre façon de bosser. Cela s’appelle sshrc et au début, j’ai cru à une énième tentative de réinventer la roue, mais en fait non. Ce truc est vraiment cool car quand vous vous connectez en SSH, il copie automatiquement votre configuration locale dans un dossier temporaire sur le serveur distant. Comme ça, vous retrouvez instantanément vos alias bash, vos raccourcis vim, votre prompt avec ses jolies couleurs…etc. Tout ce qui fait que vous vous sentez chez vous… mais sur votre serveur.

Le truc vraiment cool, c’est que ça ne pollue pas le serveur car tout est stocké dans /tmp dans un dossier propre à votre session. Si d’autres utilisateurs se connectent (même avec sshrc), ils auront leurs propres configs et pas les vôtres.

Pour l’installer, rien de plus simple. Sous macOS avec Homebrew :

brew install sshrc

Sous Ubuntu, il y a un PPA dédié :

sudo add-apt-repository ppa:russell-s-stewart/ppa
sudo apt-get update
sudo apt-get install sshrc

Pour les autres systèmes, vous pouvez récupérer le script directement depuis le repo GitHub.

Une fois installé, créez un fichier ~/.sshrc avec vos configs préférées. Par exemple, vous pouvez mettre vos alias les plus utiles, quelques fonctions bash, et même des variables d’environnement spécifiques.

Ensuite, au lieu de taper ssh user@server, vous faites sshrc user@server et c’est tout. Derrière, l’outil fait sa magie noire en compressant vos configurations, en les envoyant sur le serveur, puis en les décompressant dans /tmp, et en sourçant le tout automatiquement. Vous pouvez même avoir des configurations différentes selon les serveurs en créant des fichiers comme ~/.sshrc.d/servername.

Pour les fans de vim, il y a une astuce sympa. Ajoutez cette ligne dans votre ~/.sshrc :

export VIMINIT="let \$MYVIMRC='$SSHHOME/.sshrc.d/.vimrc' | source \$MYVIMRC"

Et placez votre .vimrc dans ~/.sshrc.d/. Comme ça, vim utilisera votre config perso même sur le serveur distant.

Attention quand même, il y a une limite. Si votre dossier ~/.sshrc.d fait plus de 64KB, certains serveurs peuvent bloquer la connexion. C’est pour ça qu’une alternative existe : SSHdot. Cette variante n’a pas de limite de taille et fonctionne exactement pareil. C’est pratique si vous avez une config vim bien chargée avec plein de plugins.

D’ailleurs, pour ceux qui préfèrent une approche différente, il y a aussi la méthode git. Vous mettez tous vos dotfiles dans un repo, et vous configurez vos serveurs pour pull automatiquement à la connexion. C’est plus lourd à mettre en place mais ça scale mieux si vous gérez beaucoup de machines.

Un dernier truc sympa, sshrc fonctionne aussi avec tmux. Vous pouvez donc configurer tmux pour qu’il utilise vos raccourcis habituels même sur le serveur distant. Il suffit d’ajouter votre .tmux.conf dans ~/.sshrc.d et de définir un alias dans ~/.sshrc qui pointe vers cette config.

Au final, sshrc vous n’en aviez pas besoin, mais maintenant que vous savez qu’il existe, c’est un incontournable ! Bref, si vous en avez marre de retrouver un environnement spartiate à chaque connexion SSH, essayez-le, ça prend 2 minutes à installer et ça change vraiment la donne niveau confort de travail.

Il y a des moments où on tombe sur une approche si simple et efficace qu’on se demande pourquoi on n’y avait pas pensé avant. C’est exactement ce que j’ai ressenti en découvrant la technique d’Armin Ronacher pour donner à Claude Code le contrôle total d’une session de debugging.

Le principe c’est de combiner GNU Screen, ce vieux multiplexeur de terminal que certains considèrent comme dépassé, avec LLDB, le debugger de LLVM, pour créer un environnement où Claude peut littéralement piloter votre terminal comme s’il était assis devant votre clavier.

Comme ça, au lieu d’implémenter des serveurs MCP complexes ou des intégrations cheloues, Ronacher s’appuie sur des outils qui existent depuis des décennies. GNU Screen permet de multiplexer un terminal physique entre plusieurs processus, créant des sessions persistantes qui survivent aux déconnexions SSH. C’est cette persistance qui devient la clé de voûte du système.

Dans sa démonstration vidéo, Ronacher montre donc comment il configure Claude Code pour automatiser complètement une session de debugging. Le secret tient dans quelques lignes ajoutées au fichier CLAUDE.md : “définir un nom de session Screen spécifique pour le debugging, utiliser la syntaxe “dollar string” pour envoyer des commandes, et fermer proprement la session une fois terminé”.

Claude peut alors créer la session, lancer LLDB, identifier un bug de type segfault, le corriger, recompiler le code et vérifier que tout fonctionne. Le tout sans intervention humaine.

Comme le souligne Ronacher dans ses recommandations, Claude Code excelle quand on lui donne accès à des outils bien documentés qu’il connaît déjà. Screen et LLDB font partie de ces outils sur lesquels il existe une montagne de documentation et d’exemples donc Claude peut les manipuler avec aisance. En tout cas, beaucoup plus que moi, c’est certain !

Mais au-delà du debugging, cette technique ouvre des perspectives fascinantes pour l’automatisation. On pourrait imaginer un Claude gérant vos sessions tmux pour orchestrer des déploiements multi-serveurs, surveillant des logs en temps réel via Screen pour détecter des anomalies, ou même maintenant des connexions SSH persistantes vers des serveurs pour des interventions d’urgence. J’avoue c’est toujours prendre un risque donc à éviter sur de la prod, mais c’est très cool quand même.

Surtout que les sessions Screen continuent de fonctionner même quand la fenêtre n’est pas visible. C’est ça qui permet à Claude de maintenir des processus longs sans monopoliser votre terminal.

Si vous faites du DevOps, vous pourriez configurer Claude pour qu’il lance automatiquement des sessions Screen lors de debugging de containers Docker, maintienne des tunnels SSH persistants pour du debugging à distance de Kubernetes, ou même gère des sessions de monitoring avec des dashboards textuels comme htop ou glances. La combinaison de la persistance de Screen et de l’intelligence de Claude crée un assistant capable de gérer des workflows complexes de manière autonome.

C’est vrai que Screen est souvent considéré comme obsolète face à tmux, mais dans ce cas précis, sa simplicité devient un avantage car Claude a probablement plus de données d’entraînement sur Screen, qui existe depuis 1987, que sur des alternatives plus modernes. Donc c’est smooooth pour lui…

Un autre cas d’usage intéressant serait la gestion de sessions de développement complexes durant lesquelles Claude pourrait maintenir plusieurs fenêtres Screen avec différents environnements : une pour les tests, une pour le serveur de développement, une pour les logs, et naviguer entre elles selon les besoins. Vous pourriez ainsi demander à Claude de lancer les tests et de vous montrer les logs en cas d’échec, et il orchestrerait tout via Screen.

Pour les équipes, cette technique pourrait vraiment renforcer le pair programming à distance…. Vous partagez une session Screen avec Claude et un collègue simultanément et Claude pourrait vous assister en temps réel, suggérer des corrections, exécuter des commandes de diagnostic, pendant que vous discutez de l’architecture avec votre collègue avec un petit kawa. C’est comme avoir un 3e collègue expert toujours dispo.

Pas besoin d’API, de webhooks, ou de services cloud… Juste des outils Unix standard que tout développeur a déjà sur sa machine et un bon prompt et hop ça fait des chocapics (ou plus de bugs…^^) !

Bref, parfois les solutions les plus belles sont aussi les plus simples. Pas besoin de réinventer la roue…

Ça vous dirait de pouvoir taper cursor-agent "trouve et corrige tous les bugs" dans votre terminal et voir GPT-5 analyser l’ensemble de votre code, proposer des corrections, et même les appliquer après votre validation ?

Plus besoin de copier-coller entre ChatGPT et votre éditeur, plus besoin de jongler entre interfaces. Et bien c’est exactement ce que Cursor CLI propose.

Avec la sortie de GPT-5 et l’explosion des assistants de code IA, Cursor frappe fort en proposant une alternative terminal-first qui s’intègre partout : JetBrains, Android Studio, Xcode, ou même directement dans votre shell préféré. Et ce qui est cool c’est qu’on peut utiliser GPT-5 gratuitement pendant la beta.

Alors perso, moi je suis un fervent utilisateur de Claude Code qui fonctionne excellement bien, à tel point que je trouve les IDE Cursor et Windsurf un peu nul maintenant. Donc voir Cursor sortir son clone de Claude Code, branché sur GPT-5, évidemment, ça m’intéresse.

L’installation se fait avec cette ligne magique :

curl https://cursor.com/install -fsS | bash

Une fois installé, vous suivez les instructions pour exporter cursor-agent dans votre environnement shell et ensuite vous lancez cursor-agent, et vous voilà avec un agent IA surpuissant directement dans votre terminal. Selon la documentation officielle, le CLI réutilise toute votre configuration Cursor existante : vos règles personnalisées, votre fichier AGENTS.md, et même vos intégrations MCP.

Ce qui distingue Cursor CLI des alternatives comme Claude Code ou Gemini CLI, c’est son système d’approbation granulaire. Par exemple, si vous demandez à l’agent de créer une API Express avec des tests Jest, il vous montrera d’abord les modifications proposées. Vous pouvez ensuite accepter, refuser, ou modifier chaque changement avant qu’il ne touche vos fichiers. Cette approche réduit considérablement les erreurs par rapport aux solutions qui appliquent tout automatiquement.

La vraie puissance du truc se révèle surtout dans l’automatisation, car vous pouvez créer des scripts qui utilisent Cursor CLI pour :

• Générer automatiquement de la documentation à partir de votre code
• Lancer des revues de sécurité sur chaque commit
• Créer des agents personnalisés pour vos workflows spécifiques
• Scaffolder des projets entiers avec une seule commande

Le support des modèles est lui aussi impressionnant. A part GPT-5, vous avez accès à Claude 4 Sonnet, Opus (et aussi Gemini, Grok, o3…etc mais j’ai pas vu ça dans ma beta). Un simple /model ls liste tous les modèles disponibles, et /model gpt-5 vous permet de basculer dessus instantanément. Cette flexibilité permet d’utiliser le modèle le plus adapté à chaque tâche.

Perso, j’ai beaucoup testé GPT-5 hier via Windsurf pour voir ce qu’il avait dans le ventre (sur du code uniquement) et hormis le fait que c’était lent de fou, ça ne m’a pas non plus très impressionné. J’avais un bug à régler et le truc a tourné toute la matinée pour au final me faire un gros caca. Et j’ai fini par résoudre le bug en fin de journée, cette fois avec Claude Code et en quelques dizaines de minutes. Donc j’avoue que pour le moment, je suis hyper déçu de GPT-5 mais bon, je lui redonnerai sa chance plus tard.

Pour les équipes, Cursor CLI c’est top pour votre CI/CD. Vous pourriez par exemple concevoir des pipelines qui utilisent GPT-5 pour :

• Générer automatiquement des tests pour le code non couvert
• Optimiser les performances avant chaque déploiement
• Créer des changelogs détaillés basés sur les commits
• Adapter automatiquement le code aux breaking changes des dépendances

Le système de règles personnalisées change aussi la donne. Vous pouvez définir des contraintes spécifiques dans votre fichier AGENTS.md (TypeScript strict, tests obligatoires, commentaires en français, etc.) et Cursor CLI respectera ces règles dans toutes ses générations.

L’aspect privacy est également bien pensé aussi car contrairement à des outils comme Copilot qui envoie votre contexte en permanence, Cursor CLI ne transmet que ce que vous lui demandez explicitement. Vos secrets restent locaux et votre code propriétaire reste protégé.

Par contre, c’est encore en beta donc il reste des bugs notamment sous Windows (WSL), et certains utilisateurs ont indiqué avoir des timeouts sur les gros projets. Mais bon, ça comme avec Claude Code, l’équipe met à jour quasiment non stop.

Pour tester rapidement, lancez simplement cursor-agent pour un chat interactif, ou utilisez les flags -m pour choisir le modèle et --no-interactive pour l’automation complète sans confirmation manuelle.

Et prochainement, il devrait y avoir du contexte persistant entre sessions, de la collaboration multi-agents, et même une intégration native avec les éditeurs via LSP.

Voilà, donc si vous cherchez une alternative à Claude Code ou GitHub Copilot qui respecte votre workflow dans le terminal, Cursor CLI mérite le détour. C’est gratuit pendant la beta et ça devrait bien vous aider !