Le bidouilleurs et leur capacité à détourner littéralement n’importe quoi pour y faire tourner DOOM, perso j’adore ! Et là, Aaron Christophel vient de franchir un nouveau cap en transformant une station de charge Anker Prime (lien affilié) en console de jeu. Oui, vous allez pouvoir joueur sur votre chargeur entre deux sessions de recharge.

L’histoire commence par une découverte intéressante… En bon hacker, Christophel analyse la station Anker Prime qu’il vient d’acheter et réalise que le hardware embarqué est bien plus costaud que prévu. Sous le capot, on trouve un ESP32-C3 pour le Bluetooth, mais surtout un microcontrôleur ARM Synwit SWM341RET7 cadencé à 150 MHz, accompagné de 16 Mo de flash et 8 Mo de RAM. Pour un simple chargeur, c’est du luxe !

Et puis il y a l’écran ! Et quel écran puisqu’il fait 200×480 pixels. C’est pas énorme, c’est vrai mais LARGEMENT suffisant pour afficher les couloirs de la base Martienne et les affreux démons pixelisés. Et le meilleur dans tout ça c’est qu’A’aucune modification hardware n’est nécessaire. Christophel a simplement chargé son code et hop, DOOM tourne.

Mais comment on joue sur un chargeur, me direz-vous ? Eh bien, c’est tout l’art de cette prouesse. Pour cela, le développeur utilise la molette rotative de la station comme contrôleur principal. On pousse pour avancer, on tourne pour se diriger, et on appuie pour tirer. C’est pas le summum de l’ergonomie, mais ça fonctionne ! Les contrôles sont surprenamment jouables, même si naviguer dans les niveaux demande un certain temps d’adaptation.

Techniquement, le jeu tourne de manière fluide, mais Christophel a dû faire quelques compromis. Le mode plein écran s’avère trop gourmand pour le processeur, et globalement l’expérience reste “un peu bancale” selon ses propres mots. Mais franchement, quand on voit DOOM tourner sur une station de charge, on va pas chipoter sur la fluidité.

Bref, un appareil de plus dans la longue liste des portages de DOOM sur des bidoules improbables. Christophel n’en est d’ailleurs pas à son coup d’essai puisqu’il avait déjà fait tourner le jeu sur une brosse à dents électrique. Entre les calculatrices, les réfrigérateurs connectés, les PDF et maintenant les chargeurs, on se demande s’il existe encore un appareil électronique incapable de faire tourner ce chef-d’œuvre de 1993.

Et ce qu’on découvre aussi c’est que cette station Anker n’est pas qu’un bête chargeur… c’est un petit ordinateur déguisé, avec suffisamment de ressources pour faire tourner des applications complexes. Christophel l’explique d’ailleurs très bien sur Mastodon : “Le MCU interne SWM34S est juste excellent ! 8 Mo de RAM + 16 Mo de flash directement mappés en mémoire, ça déchire.”

Alors si un simple chargeur peut faire tourner DOOM, qu’est-ce qui nous empêche d’imaginer des fonctionnalités plus poussées ? Par exemple, un chargeur qui affiche vos mails, votre météo, qui sert de hub domotique ? Ou qui se fait infecter par un virus dont l’objectif est de le faire exploser ?

Une fois encore, la seule limite des hackers c’est l’imagination. Et visiblement, Aaron Christophel n’en manque pas. Maintenant, reste à savoir quel sera le prochain appareil à rejoindre la grande famille des supports DOOM ???

Source

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 ?

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…

Pendant que vous lisez cet article, Jules pourrait être en train de corriger les bugs présent dans votre code. Non, c’est pas une blague, c’est le nouveau délire de Google qui vient de sortir de beta. Jules, c’est un agent IA qui code vraiment tout seul, et franchement, après l’avoir testé, je commence à me demander si le métier de dev a encore un avenir.

Vous créez une issue GitHub avec le label “jules”, vous partez boire un café (ou vous taper une petite sieste), et quand vous revenez, hop, une pull request toute propre vous attend. Tests écrits, dépendances mises à jour, et bugs corrigés. Jules a tout fait pendant que vous vous tourniez les pouces.

Ce qui rend Jules différent de Copilot et consorts c’est qu’il ne se contente pas de compléter votre code ou de suggérer des snippets. Non, non. C’est un véritable agent autonome qui clone votre repo dans une VM Google Cloud sécurisée et se met au boulot tout seul. Sous le capot c’est Gemini 2.5 Pro, donc il comprend le contexte global de votre projet et peut enchaîner plusieurs tâches complexes.

L’intégration GitHub est particulièrement soignée. Jules peut créer ses propres branches, ouvrir des pull requests avec des commits propres et même générer des changelogs audio. C’est fou ça, des changelogs audio. Faut croire que lire en 2025 c’est has been…

Pour l’utiliser, c’est simple comme bonjour. Vous vous connectez sur jules.google.com (avec votre compte Google, évidemment), vous liez votre GitHub, et c’est parti. Le bouton “Give a plan” lance le processus de réflexion de Jules qui vous soumettra alors son grand projet pour vous. Et si ça vous convient, vous validez et il se met au travail.

Comme Jules fonctionne de manière totalement asynchrone, vous pourriez être en train de jouer à Baldur’s Gate 3 qu’il continuerait tranquillement de refactoriser votre code tout pourri.

Les fonctionnalités qui tuent c’est d’abord, les mises à niveau de version. Terminées les heures passées à vérifier la compatibilité et à ajuster le code pour la dernière version d’une lib. Jules s’en charge. L’écriture de tests, cette tâche aussi cruciale que chiante, Jules la fait. Et en plus, il le fait bien, le bougre.

Niveau langages supportés, c’est du lourd : Node.js, Python, Go, Java et Rust. Par contre, pas de PHP pour l’instant. Désolé les warriors du web de 2005. Google promet d’autres langages bientôt, mais on connaît leurs promesses…

Bon, parlons fric maintenant. Google a sorti trois forfaits. Y’a le plan gratuit qui vous donne 15 tâches par jour et 3 simultanées. C’est déjà pas mal pour tester. Le Pro multiplie les limites par 5, et l’Ultra par 20 pour les gros projets avec du multi-agent.

Un truc important sur la privacy, c’est que si votre repo est public, Google peut utiliser vos données pour entraîner l’IA. Et si c’est privé, rien n’est envoyé. En tout cas, c’est ce qu’ils disent.

Google est tellement confiant qu’ils vont l’utiliser sur leurs propres projets.

Alors est-ce que Jules va remplacer les développeurs ? Non, je crois pas, mais il va clairement changer notre façon de travailler car au lieu de passer des heures sur des tâches répétitives, on pourra se concentrer sur l’architecture, la créativité, les vrais problèmes complexes. Et lui s’occupera du sale boulot.

Par contre, si vous êtes le genre de dev qui se contente de copier-coller du Stack Overflow, là oui, commencez à chercher une reconversion. Car Jules fait ça mieux, plus vite, et il ne se plaint jamais du montant de ses tickets resto.

Merci à Lorenper pour la découverte !