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 !