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…

Pourquoi prendre des vacances d’été et glander sur une plage, alors qu’on pourrait pondre projet open source qui résout un vrai problème ?

Adrien Revel a fait exactement ça avec Microfolio, et le plus rigolo c’est qu’il s’est fait assister par Claude Code pour développer son bébé. Une fois installé, vous lui balancez vos fichiers dans des dossiers, vous ajoutez du Markdown pour les descriptions, et paf, vous avez un portfolio statique qui a la classe.

Pas de base de données qui rame, pas de CMS à maintenir, pas de plugins WordPress qui vous lâchent au pire moment. Juste des fichiers, du contenu, et un site qui booste.

Microfolio tourne sur SvelteKit 2, l’un des générateurs de sites statiques les plus utilisés, couplé à Tailwind CSS 4. Pour ceux qui ne suivent pas l’actu dev, SvelteKit est un framework qui compile votre code en vanilla JavaScript ultra-optimisé. Du coup, les sites chargent à la vitesse de l’éclair même sur une connexion 3G pourrie.

Maintenant, l’installation, c’est du velours. Par exemple, sous macOS, une ligne de Homebrew et c’est parti :

brew install aker-dev/tap/microfolio
microfolio new mon-portfolio
cd mon-portfolio
microfolio dev

Pour les autres OS, un bon vieux clone Git et pnpm font l’affaire. Le projet est pensé pour les designers, architectes, photographes, bref tous les créatifs qui veulent montrer leur travail sans se prendre la tête avec du code.

Ce qui est intéressant dans l’histoire, c’est qu’Adrien a développé Microfolio avec Claude Code, ce nouvel assistant IA d’Anthropic qui cartonne chez les développeurs. Claude Code est d’ailleurs particulièrement doué pour bosser avec Svelte 5 et sa nouvelle syntaxe de runes. L’IA l’a visiblement bien aidé sur la doc et le code, ce qui montre qu’on peut faire de l’open source de qualité en duo avec une IA.

La démo en ligne montre déjà ce que ça donne à savoir une interface épurée, une navigation fluide entre les projets, une vue carte pour les projets géolocalisés (pratique pour les architectes), et un système de tags pour filtrer le contenu. Le tout responsive évidemment, c’est la base aujourd’hui.

Moi j’en ai fait un site de chat pour rigoler…

Pour le déploiement, GitHub Pages est supporté d’office avec possibilité de mettre un domaine custom. Adrien cherche également des beta-testeurs pour peaufiner le projet avant de sortir la v1.0 à la rentrée. Donc si vous avez un portfolio à refaire ou si vous voulez juste tester un outil moderne, c’est le moment.

Bref, du bon “file-based CMS” comme on les aime. Comme ça, au lieu de stocker vos contenus dans une base de données qui peut foirer, tout est dans des fichiers que vous pouvez versionner avec Git. Vous gardez le contrôle total sur vos données, vous pouvez tout éditer offline, et surtout vous n’êtes pas prisonnier d’un système.

Puis ce combo SvelteKit + Tailwind CSS est vraiment pertinent, je trouve. SvelteKit permet de générer des sites statiques en automatique, ce qui veut dire que votre site est servi en HTML statique pour le SEO, puis devient interactif côté client. C’est le meilleur des deux mondes.

Pour les devs qui veulent contribuer, le code est sur GitHub sous licence MIT. Le projet utilise les dernières versions de tout (SvelteKit 2, Tailwind CSS 4, Node.js 20+), donc c’est aussi l’occasion de jouer avec les dernières technos du moment.

A découvrir ici !

Merci à Adrien Revel pour avoir partagé son projet !