Sur The Register, un témoignage improbable d'un lecteur qui raconte la fois où il a effacé toutes les données et tout le code de son entreprise. Voilà qui date pas mal, puisque c,'était en 1981, il avait 21 ans, et il développait tout seul un script de nettoyage pour un mainframe IBM. Le genre de mission qu'on ne devrait pas trop confier à un dev junior sans relecture. C'est précisément ce qui a été fait, et la suite est exactement ce que vous pouvez imaginer.

Le système gérait des machines virtuelles pour les utilisateurs, chacune avec son disque attaché et une lettre attribuée de A à Z. À la fin de la journée, le script de Miller, notre héros, faisait trois choses simples : il rattachait tous les disques, les sauvegardait sur un disque temporaire, puis effaçait les originaux. Le problème, c'est que le disque temporaire recevait une lettre dynamique, pas prédictible à l'avance. Donc Miller avait écrit du code pour récupérer cette lettre au moment où elle était attribuée.

Sauf que voilà. Un jour, l'entreprise ajoute un nouveau compte utilisateur. Et là, les 26 lettres de l'alphabet sont toutes occupées. Le système ne peut plus attribuer de lettre au disque temporaire. 

La fonction censée renvoyer la lettre ne renvoie pas une erreur, mais une astérisque. Sauf que dans la plupart des langages de scripting shell, l'astérisque est un caractère joker qui veut dire "tout ce que tu trouves". Quand la commande de suppression s'exécute avec un astérisque à la place d'une lettre précise, elle ne supprime pas un disque. Elle supprime tout. Chaque fichier, toutes les données, tout le code de l'entreprise.

Une journée complète a été nécessaire pour restaurer ce qui pouvait l'être. Une vingtaine de collègues sont restés à se tourner les pouces pendant la restauration. Miller, lui, a appris ce jour-là pourquoi le contrôle de code par un pair existe. Plus de quarante ans plus tard, il dit que la leçon ne l'a jamais quitté.

L'histoire date de 1981, mais elle reste actuelle à un détail près. Aujourd'hui, on a les revues de code, les sauvegardes incrémentales, les snapshots, les outils de récupération, et on confie quand même des scripts shell critiques à des assistants IA qui n'ont pas toujours conscience de ces pièges . L'astérisque parasite n'a pas disparu, elle a juste changé de support. Méfiance donc !

Source : The Register

Vous avez déjà essayé de dessiner une TUI (Interface utilisateur pour le Terminal) à la main dans votre IDE ?

Genre, calculer les paddings d'une Box ANSI à la mano et compter les caractères Unicode pour aligner trois colonnes ? Pffff quelle galère !! Hé bien cette mauvaise expérience, Javier Alonso Gómez, Staff Design Technologist chez Docker, vient de la transformer en simple drag-and-drop avec son outil TUIStudio .

En gros, c'est comme Figma mais pour vos applis terminal.

Vous lancez l'éditeur, vous balancez des composants sur un canvas, et un aperçu ANSI temps réel vous montre ce que ça donnera dans un vrai terminal. Il y a 21 composants prêts à l'emploi (Box, Button, TextInput, Table, Tree, Modal, Tabs, Spinner...), avec un moteur de layout qui supporte Absolute, Flexbox et Grid.

C'est du CSS pour le terminal si vous préférez et le truc cool, c'est que ça reste fidèle au rendu final, donc fini les tableaux qui débordent sans raison !

J'suis pas encore super doué !

Côté thèmes, vous avez également le droit à 8 palettes intégrées (Dracula, Nord, Solarized, Monokai, Gruvbox, Tokyo Night, Nightfox et Sonokai), et le canvas se met à jour live quand vous changez. Sympa, hein !

Niveau export, TUIStudio cible les frameworks Ink (TypeScript), BubbleTea (Go), Blessed (JavaScript), Textual (Python), OpenTUI (TypeScript) et Tview (Go) mais d'après ce que j'ai lu sur le site officiel, la fonction d'export vers tout ça n'est pas encore opérationnelle. Mais ça m'étonne car lors de mes tests, j'ai quand même pu voir que ça fonctionnait... Donc j'sais pas, peut-être que le site web n'a pas été mis à jour et que l'export est bien opérationnel ?

L'export

Ça tourne sur macOS Apple Silicon, Windows et Linux (.deb) et le code est sous licence MIT sur le repo GitHub .

Amusez-vous bien !

Orhun Parmaksız, l'un des principaux mainteneurs de Ratatui (une bibliothèque Rust très utilisée pour créer des interfaces texte dans le terminal), vient de sortir un projet qui sort vraiment des clous.

Ça s'appelle Ratty, c'est donc un émulateur de terminal capable d'afficher des objets 3D, des sprites animés et des modèles complets en plein milieu de votre ligne de commande.

Entre le 6 et le 7 mai 2026, le site officiel jdownloader.org a été compromis et a servi pendant un peu plus d'une journée des installeurs piégés à la place des versions légitimes du célèbre gestionnaire de téléchargements.

Concrètement, les liens alternatifs pour Windows et l'installateur shell pour Linux ont été remplacés par un loader qui déploie un RAT (Remote Access Trojan) écrit en Python sur la machine de la victime. Pour ceux qui ne connaissent pas, un RAT donne à l'attaquant un contrôle total à distance de votre PC : exécution de commandes, vol de données, installation d'autres malwares, et tout ce qui peut se faire avec un compte utilisateur compromis.

Bonne nouvelle dans le malheur. Tous les canaux de distribution n'ont pas été touchés. La version macOS est passée à travers, pareil pour les installations via Flatpak, Winget et Snap, ainsi que pour le package JAR principal de JDownloader. Seuls les liens "alternative download" Windows et le script shell Linux du site officiel sont contaminés. Si vous utilisez ces canaux pour vous mettre à jour, c'est sur eux qu'il faut vérifier.

Le problème a d'abord été relevé par un utilisateur Reddit, "PrinceOfNightSky", qui a constaté que les exécutables téléchargés étaient signalés par Microsoft Defender et signés par des éditeurs douteux (Zipline LLC, The Water Team) au lieu de la signature légitime AppWork GmbH.

Une fois alerté, le développeur de JDownloader a confirmé la fuite, mis le site hors ligne, et publié un rapport d'incident détaillé pour permettre l'analyse externe. La porte d'entrée des attaquants ? Une vulnérabilité du CMS du site qui permettait de modifier les listes de contrôle d'accès et le contenu sans authentification. Pas génial.

Le malware Windows fonctionne en deux étages. Un petit programme téléchargé sert de loader, qui récupère et exécute ensuite le vrai payload en se connectant à deux serveurs de commande nommés parkspringshotel[.]com et auraguest[.]lk. Architecture modulaire, ce qui veut dire que l'attaquant peut envoyer le code Python qu'il veut depuis ses serveurs et adapter sa charge en temps réel. Vol de mots de passe, persistance, mouvement latéral sur le réseau local, tout y est possible.

Si vous avez téléchargé JDownloader depuis le site officiel entre le 6 et le 7 mai, faites donc très attention. Réinstallez complètement l'OS et changez tous vos mots de passe. Un RAT donne suffisamment d'accès pour qu'un nettoyage par antivirus seul ne soit pas une garantie suffisante. Pénible mais c'est le seul moyen propre.

Source : Bleeping Computer

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

Si vous utilisez Claude Code au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque, sans prévenir, cette putain de limite de quota imposée par Anthropic vous explose à la gueule ! Et le pire c'est que vous n'avez pas l'impression d'avoir fait grand chose.

En réalité, la vraie raison c'est surtout le "bruit" de toutes vos sorties shell. Un git log, un cargo test, un npm build... votre agent IA ingère tout ça comme du petit lait alors qu'il n'a besoin que d'une fraction pour comprendre ce qui se passe.

Breeef, c'est pas ouf quoi.

Heureusement pour vous RTK (Rust Token Killer) vient régler en partie ce problème. RTK c'est développé par un Français et c'est un proxy CLI en Rust qui s'intercale entre votre shell et votre agent IA, intercepte les commandes courantes et compresse leur sortie avant qu'elle n'atterrisse dans le contexte de votre agent.

Comme ça plutôt que de massacrer vos prompts ou de changer vos habitudes (et dieu sait que vous avez horreur de changer d'habitudes..lol), il attaque le bruit à la source grâce à 4 stratégies de compression : un filtrage du boilerplate, un regroupement des lignes similaires, une troncature intelligente et de la déduplication des répétitions.

Et tout ça s'intègre merveilleusement bien via un hook pour Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf, Cline, Codex... soit une bonne dizaine d'outils supportés !

Ainsi, votre git status devient rtk git status sans changer quoi que ce soit à vos habitudes... RTK fait tout le filtrage dans votre dos, ce qui est parfait ! C'est un outil qu'on installe et qu'on oublie.

Par exemple un git diff passe de 12 000 tokens à 960, soit 92% d'économie, un npm test tombe de 6 000 à 600 tokens et une session de refactoring sur 12 fichiers passe de 74 700 à 6 960 tokens d'après les benchmarks. En pratique, les utilisateurs constatent des économies autour de 70% sur l'ensemble d'une journée de boulot, ce qui représente plusieurs millions de tokens par semaine pour ceux qui bossent avec des agents IA à plein régime.

Moi ça fait plusieurs mois que je le teste et voici mes stats. Ça donne quand même 81,5 % d'économie de tokens !!

L'installation se fait en une commande : brew install rtk sur macOS, ou un script curl pour les autres plateformes, ou cargo install --git https://github.com/rtk-ai/rtk si vous préférez compiler ça vous-même.

Avec la commande rtk gain vous verrez un tableau comme ci-dessus avec les statistiques par commande, et rtk gain --history donnera l'historique détaillé. Y'a plus de 100 commandes couvertes, de git aux runners de tests en passant par AWS CLI, kubectl et docker. Par contre, ça marche pas super bien si vos sorties de commandes sont déjà très courtes. Ça ne fera pas de miracle mais pour des diffs volumineux ou de suites de tests qui crachent 3 000 lignes à chaque fois, c'est tip top !

Si vous utilisez des agents en mode autonome où une boucle tourne sans intervention, c'est même encore plus pertinent car chaque itération accumule du bruit de façon cumulative, et du coup le contexte se remplit de trucs inutiles à vitesse grand V. Moins de bruit grâce à RTK, c'est donc une économie de tokens mais c'est également un meilleur signal pour votre agent.

RTK est dispo en open source sur GitHub sous licence Apache 2.0.