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.

Flash à sa grande époque c'était quand même tout un truc, mais est-ce que vous vous souvenez de Shockwave ? Le grand frère de Flash (techniquement c'était une autre techno bâtie sur Director mais bref...), qui était capable de faire tourner des trucs bien plus complexes que les vieux .swf ?

Et ben l'équipe derrière DirPlayer s'est tapé tout le reverse-engineering du moteur Director from scratch pour le ressusciter grâce à Rust et le rendre à nouveau fonctionnel dans nos navigateurs modernes !

Faut savoir qu'Adobe a débranché Shockwave Player en avril 2019 et Flash un peu plus tard, et avec eux c'est un pan entier du web rétro qui s'est retrouvé inaccessible du jour au lendemain. Du genre tous ces jeux qui tournaient sur Shockwave.com ou les vieux portails de mini-jeux des années 2000, paf, d'un coup plus moyen d'y rejouer.

Alors heureusement, pour Flash, y'a déjà Ruffle qui fait tourner les bons vieux .swf. Hé bien ici c'est le même principe avec DirPlayer pour les .dcr Shockwave.

L'outil se décline sous 3 formes. D'abord une extension Chrome qui détecte automatiquement les balises Shockwave qui traînent encore sur les vieux sites web, ce qui peut être sympa pour redécouvrir des sites des années 2000.

Y'a aussi une version standalone construite avec Electron qui embarque carrément un debugger Lingo (le langage de scripting de Director, super pratique si vous voulez bidouiller du contenu existant). Et enfin un polyfill JS auto-contenu qui réécrit les et directement sur votre site web.

Perso, pour vous faire une idée, je vous invite surtout à jeter un oeil à la démo web pour tester rapidement parce qu'il n'y a rien à installer. Mais dès que vous voudrez analyser ou debugger un vieux jeu en profondeur, faudra plutôt opter pour la version standalone.

Notez que DirPlayer utilise Ruffle en submodule Git donc les 2 projets sont liés et bonus côté sécurité, le tout tourne en WebAssembly avec le sandboxing du navigateur, donc y'aura plus toutes ces failles qu'on pouvait retrouver à l'époque sur l'ancien plugin Shockwave Player.

Pour les sites qui hébergent encore des applis ou des jeux Shockwave (genre archive.org, avec des musées interactifs ou des jeux des années 2000), c'est une nouvelle corde à leur arc. Et si vous avez de vieux .dcr planqués sur un disque dur, la démo web devrait pouvoir les avaler aussi (faudra tester quoi...).

Bref, grâce à Ruffle pour Flash et DirPlayer pour Shockwave, le web des années 90-2000 n'est pas encore tout à fait mort ! Un peu comme moi finalement ^^

Vincent en avait parlé il y a peu : Firefox 149 embarque maintenant discrètement adblock-rust , le moteur Adblock de Brave, désactivé par défaut et contrôlé uniquement par deux prefs dans about:config.

A l'origine, je vous avais parlé d'une extension mais après analyse plus approfondie, celle-ci n'est pas vraiment nécessaire. Y'a juste deux valeurs à coller dans about:config et le moteur tourne. Merci donc à François qui m'a indiqué cette méthode directe.

Étape 1 : Activer le moteur

Dans la barre d'adresse, tapez about:config et acceptez l'avertissement. Cherchez la préférence suivante :

privacy.trackingprotection.content.protection.enabled

Passez-la à true. Si elle n'existe pas encore dans votre profil, créez-la : clic droit quelque part dans la liste → Nouveau → Booléen.

Étape 2 : Charger vos listes de filtres

Cherchez ensuite cette seconde préférence :

privacy.trackingprotection.content.protection.test_list_urls

Collez-y la valeur suivante, toutes les URLs séparées par des pipes :

https://easylist.to/easylist/easylist.txt|https://easylist.to/easylist/easyprivacy.txt|https://secure.fanboy.co.nz/fanboy-cookiemonster.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/annoyances-others.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_2_Base/filter.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/filters.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_3_Spyware/filter.txt|https://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblockplus&showintro=1&mimetype=plaintext

Ça couvre 8 listes : EasyList, EasyPrivacy, Fanboy Cookie Monster, uBO Annoyances (les 4 de base), plus uBO Filters, AdGuard Base, AdGuard Tracking et Peter Lowe. Si vous voulez un profil plus léger, vous pouvez supprimer des URLs avant de coller.

Petite note : le préfixe test_ dans le nom de cette pref indique que la feature est encore expérimentale dans Firefox 149. Les noms peuvent donc changer dans une version future.

Désactiver ETP (optionnel mais recommandé)

La protection contre le pistage intégrée de Firefox (ETP) et adblock-rust filtrent chacun de leur côté. C'est redondant. Pour désactiver ETP, allez dans about:preferences → Confidentialité et sécurité → Protection renforcée contre le pistage → cochez "Personnalisée", puis décochez tout ce que vous voulez confier à adblock-rust.

Limitation actuelle : adblock-rust ne gère pas encore les sélecteurs CSS de masquage d'éléments, les règles ## du style uBlock Origin. Brave les supporte déjà, Firefox devrait suivre. En attendant, quelques pubs que uBO cachait via CSS resteront visibles.

Pour le contexte technique complet sur l'intégration de ce moteur, allez lire l'article de Vincent sur l'arrivée discrète d'adblock-rust dans Firefox 149 . Et si vous voulez un guide général pour bloquer les pubs et trackers sur le web , c'est par là.

Merci à François pour la méthode et la liste de filtres !

Datadog Labs vient de sortir pup , un outil CLI codé en Rust qui donne à vos agents IA un accès complet à leur plateforme. L'idée c'est que pendant que Vercel et AWS galèrent de ouf à rendre leurs trucs « agent-friendly », Datadog, lui, dégaine un outil dédié qui expose +200 commandes sur plus de 33 de leurs produits, du monitoring aux SLOs en passant par la sécurité et les incidents.

Côté install c'est du classique, brew tap datadog-labs/pack && brew install pup, puis pup auth login pour le flow OAuth2 avec PKCE.

Plus besoin comme ça de balader vos clés API à vie dans des variables d'env, même si le fallback DD_API_KEY reste là quand même pour d'éventuels cas "headless". Une fois loggué, vous tapez alors par exemple :

pup monitors list

pup metrics query --query="avg:system.cpu.user{*}" --from="1h"

Vous avez déjà voulu créer une appli desktop qui tourne sur Linux, Mac et Windows en même temps ? En Rust, c'était un peu compliqué jusqu'ici. Heureusement, Slint , créé par la société allemande SixtyFPS GmbH, propose une solution sympa !

L'idée, c'est de décrire votre interface dans des petits fichiers .slint (un genre de mini HTML/CSS pour appli native), et de brancher ça à du Rust, du C++, du JavaScript ou du Python. Comme ça, vous codez le visuel d'un côté, la logique de l'autre.

Et ce qui est encore plus cool c'est que leur runtime tient dans 300 KiB de RAM. A titre de comparaison, une appli Electron type Discord en bouffe plusieurs centaines de mégaoctets. Slint tourne donc aussi bien sur un Raspberry Pi, un microcontrôleur STM32, ou directement dans un navigateur via WebAssembly.

Par exemple, SK Signet, un fabricant sud-coréen leader sur le marché américain des bornes de recharge électrique, anime ses écrans tactiles 15 à 32 pouces avec. OTIV fait tourner ses trains autonomes dessus. WesAudio l'utilise également pour son plugin audio pro.

Donc c'est du sérieux et si vous voulez tester sans rien installer, direction SlintPad . Vous tapez du code, et le rendu apparaît dans le navigateur. Ensuite pour débuter un projet Slint en local, faudra faire un cargo install slint-lsp puis utiliser le template slint-rust-template dispo sur GitHub. 2 minutes de compilation plus tard et hop, vous avez votre première fenêtre.

Côté tarif, Slint est gratuit pour les projets open source et gratuit aussi pour les applis desktop, mobile ou web même propriétaires. Seul l'embarqué propriétaire est payant. Donc pour la majorité des gens, c'est gratos.

Le revers de la médaille c'est qu'il faudra apprendre un nouveau langage de description, et la bibliothèque de boutons et menus prêts à l'emploi est moins fournie qu'un Qt qui a 30 ans d'avance derrière lui. Mais ça vaut le coup d'essayer puis vu que tout le monde vibe code de toute façon, ça ne devrait pas vous poser trop de soucis.

Voilà, si vous bricolez vos propres outils sur Raspberry Pi ou que vous voulez juste une appli desktop ultra-légère sans embarquer un navigateur entier avec, c'est à regarder.

Merci Chrltc pour le lien !

Source : github.com/slint-ui/slint

Docker Desktop bouffe la RAM comme vous le saucisson à l'apéro. Et même quand vous n'utilisez pas cette RAM, d'autres outils comme Lima ou Colima prennent aussi de la RAM.

Mais c'était sans compter sur smolvm , le projet de BinSquare et de l'équipe smol-machines, qui s'attaque au problème par un autre angle, à savoir utiliser des microVMs hardware-isolées qui bootent en moins de 200 millisecondes, qu'on configure en TOML, et qu'on peut packer dans un seul binaire .smolmachine qui tournera sur n'importe quel Mac ou Linux compatible.

Pas de daemon ni de service à lancer en background, non, c'est juste un bon vieil outil CLI codé en Rust qui boote une VM par workload et s'éteint quand c'est fini !

Ainsi, quand vous tapez :

smolvm machine run --image alpine -- sh -c "ma commande"

ça vous sort un noyau Linux complet avec son propre kernel, isolé via Hypervisor.framework sur Mac ou KVM sur Linux et tout ça en moins de temps qu'il n'en faut à Docker Desktop pour afficher sa fenêtre de démarrage. LOL

Le réseau est désactivé par défaut, mais si vous voulez l'activer, vous pouvez whitelister uniquement les domaines autorisés. Cette approche "deny by default" est rare dans l'écosystème conteneur, où en général on ouvre le réseau d'abord et on filtre après.

La fonctionnalité qui sort vraiment du lot, c'est surtout le packing en format .smolmachine. Concrètement, vous prenez votre image Docker (Python 3.12, Postgres, ce que vous voulez...), vous lancez :

smolvm pack create --image python:3.12-alpine -o ./python312

Et hop, magie magie, vous avez un exécutable totalement autonome avec tout ce qu'il faut dedans : kernel, rootfs, dépendances et tutti quanti comme disent les Allemands !

Plus besoin comme ça, d'installer quoi que ce soit du côté du destinataire de votre app. Vous balancez simplement votre binaire à un collègue, il le lance, et ça marche. Il est content, vous aussi, c'est trop bien, y'a plus qu'à aller boire ce truc dégeu qu'on appelle dans le sud, "un petit jaune" pour célébrer ça !!

Sous le capot, le moteur de virtualisation s'appuie sur libkrun , une bibliothèque VMM développée par Red Hat dans le cadre de l'initiative rust-vmm. Pour les noobzzzz, rust-vmm est un effort communautaire qui partage des composants Rust de virtualisation entre plusieurs projets : Firecracker (AWS), Cloud Hypervisor (Intel), crosvm (Google), libkrun (Red Hat) et donc smolvm.

Du coup les améliorations sur la mémoire ou la sécurité bénéficient à tous en parallèle. Côté kernel, smolvm embarque libkrunfw, un noyau custom optimisé pour démarrer hyper vite. J'ai testé, ça tient sa promesse < 200 ms !

La mémoire est élastique via virtio balloon ce qui fait que le host n'engage que ce que le guest utilise vraiment et récupère le reste automatiquement. Et les vCPUs dorment dans l'hyperviseur quand ils sont idle (en attente), ce qui permet d'over-provisionner sans payer le prix.

Côté sécu, y'a des détails qui sont cools aussi comme le SSH agent forwarding du host qui est exposé au guest sans jamais que les clés privées n'entrent dans la VM. En effet, c'est l'hyperviseur qui fait barrière donc vous pouvez cloner un repo privé depuis une VM jetable, comme un cochon, sans risquer d'exfiltrer vos identifiants si le code que vous lancez est foireux.

Et chaque workload a son propre kernel, donc une faille dans le kernel guest reste cantonnée à cette VM. Top hein ? Comparé à un conteneur Docker classique où une CVE kernel touche tout le host, c'est un autre niveau d'isolation.

Au niveau des concurrents, Firecracker (AWS) tourne uniquement sous Linux et vise les workloads serverless du cloud, mais pas le poste dev. Kata Containers de son côté fait du microVM mais boot en environ 500ms et nécessite une stack containerd lourde.

QEMU est puissant c'est sûr, mais boot en 15 à 30 secondes selon la config, donc oubliez, la vie est trop courte ! Quant à OrbStack dont je vous parle tout le temps puisque c'est l'alternative à Docker Desktop sur Mac qui est la plus aboutie aujourd'hui, ça reste quand même un outil proprio qui se repose sur Docker.

smolvm lui, boxe dans une autre catégorie puisque c'est une lib SDK embarquable, et pas juste un CLI, et son format .smolmachine n'a pas d'équivalent direct. C'est donc plus proche de l'esprit de Nix ou des binaires statiques Go, mais avec une isolation hardware réelle.

Sachez-le, en 2026, environ 42% des commits GitHub viennent de code généré ou assisté par IA. Je sais, ça en défrise pas mal mais c'est la nouvelle réalité.

Sauf qu'à chaque fois que vous lancez un script Python ou un paquet npm non relu, codé par une IA, vous prenez potentiellement un risque. En effet, à chaque fois, que vous donnez à du code potentiellement malveillant un accès direct à vos credentials, votre système de fichier ou encore votre réseau, vous vous exposez.

Ce bon vieux chmod +x && ./run.sh servi avec du café et beaucoup d'espoir, c'est terminé ! smolvm vous propose de basculer vers un modèle où l'isolation est l'état par défaut, et où ouvrir le réseau ou votre système de fichiers est une décision vraiment explicite. Donc parfait pour laisser des agents IA faire leur vie sur vos projets sans prendre de risques.

Notez que le support GPU est dans une branche séparée, et pas encore mergé. Et le projet est principalement piloté par BinSquare avec un Discord modeste derrière, et pas une fondation booster aux milliards d'Amazon ou de Google. Du coup ne déployez pas ça en prod sans backup... Mais pour du dev, de la sandbox d'agents IA, ou tout simplement pour distribuer votre binaire, c'est déjà très solide.

Et comme ça bouffe moins de RAM que Docker Desktop, sur un MacBook avec 16 Go, la différence se sent immédiatement.

Pour l'installer, ça passe par curl :

curl -sSL https://smolmachines.com/install.sh | bash

ou un download manuel depuis les releases GitHub.

Lancez ensuite

smolvm --help

ou ce hello world :

smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"

Et à vous de jouer !

Le paysage médiatique mondial est sur le point de basculer. Ce vendredi 24 avril 2026, lors d'une assemblée générale extraordinaire, les actionnaires de Warner Bros. Discovery (WBD) ont massivement voté en faveur du rachat par Paramount Skydance. Si cette étape marque une victoire cruciale pour David Ellison, le futur patron de l'entité fusionnée, le chemin vers la finalisation reste parsemé d'obstacles réglementaires et politiques.

Redox OS vient de publier son dernier rapport d'avancement et il y a du nouveau. En plus des progrès sur les pilotes graphiques et le bureau COSMIC, le projet open source a adopté une politique stricte : toute contribution générée par une intelligence artificielle sera refusée et son auteur banni. Carrément.

Du code IA ? Dehors.

Redox OS ne veut pas de code écrit par ChatGPT, Copilot ou tout autre modèle de langage. La règle est inscrite dans les directives de contribution du projet : toute soumission identifiée comme générée par un LLM (issues, merge requests, descriptions) sera immédiatement fermée. Et quiconque tente de contourner la règle se fait bannir du projet. Le tout est présenté comme non négociable.

Redox OS rejoint d'autres projets open source qui ont pris la même direction ces derniers mois, comme Fedora, Gentoo, le projet Rust lui-même ou LLVM, qui ont tous eu à gérer des vagues de contributions de mauvaise qualité générées par IA.

COSMIC, GPU et nouveau scheduler

En parallèle, le mois de mars a été productif côté technique. La démo libcosmic tourne désormais dans le compositeur COSMIC sur Redox, ce qui veut dire qu'on se rapproche d'un vrai bureau utilisable. Les pilotes graphiques ont aussi avancé : support du mapping mémoire GPU sur le pilote Intel, mise en place de shadow buffers pour améliorer les performances, et du travail sur l'API DRM.

Le noyau a aussi reçu un nouveau planificateur de tâches (Deficit Weighted Round Robin) et une meilleure détection des deadlocks. Côté paquets, CPython, PHP, Nano et Vim ont été mis à jour avec le support Unicode via ncursesw.

Un OS ecrit en Rust, pour quoi faire ?

Pour ceux qui ne connaissent pas, Redox OS est un système d'exploitation open source entièrement écrit en Rust, avec une architecture microkernel. Le projet existe depuis 2015 et cherche à proposer une alternative à Linux et BSD, avec la sécurité mémoire de Rust comme argument principal.

Il est porté par Jeremy Soller, qui travaille aussi chez System76 sur Pop!_OS. Redox n'est pas encore prêt pour un usage quotidien, mais chaque mois le rapproche un peu plus d'un système fonctionnel, et l'arrivée du bureau COSMIC est un gros morceau.

Interdire le code IA dans un projet open source en 2026, c'est quand même une prise de position forte. On peut comprendre la démarche : quand on construit un noyau de système d'exploitation, la qualité du code compte, et les contributions générées par IA ont tendance à créer plus de travail qu'elles n'en économisent pour les mainteneurs.

Mais bon, la politique reconnaît elle-même qu'il est impossible de détecter du code IA non étiqueté, ce qui pose la question de l'efficacité réelle de la mesure. Côté technique, voir COSMIC tourner sur Redox est une bonne nouvelle pour tous ceux qui suivent le projet de près. Après dix ans de développement, l'OS en Rust commence à ressembler à quelque chose.

Source : Phoronix