Connexion
J'sais pas si vous avez suivi, mais dès janvier 2027 , ce gros nul de Gmail ne saura plus aller chercher le courrier de vos autres boîtes via POP3, et encore moins vous laisser envoyer des mails depuis leurs adresses. De mon point de vue, c'est une sacrée régression...
Alors j'ai cherché une solution pour amortir le choc et je suis tombé sur plMail , un client mail que vous hébergez vous-même sur votre propre serveur / NAS qui n'est pas un serveur de messagerie (puisqu'il ne reçoit rien et n'héberge pas votre domaine) mais un formidable outil qui se connecte à vos boîtes existantes (IMAP, Gmail, Outlook), les synchronise dans une base PostgreSQL chez vous et vous affiche vos emails dans une seule et même boîte de réception, avec une recherche unifiée et la possibilité de mettre des tags...etc.
C'est vachement plus sympa que de se config je ne sais combien de boîtes dans Apple Mail ou Thunderbird et le moteur de recherche est assez puissant avec également la possibilité de faire des filtres, des alias ainsi qu'un agenda synchronisé avec Google, Microsoft et CalDAV.
Il y a aussi un modèle de langage (inactif de base) permettant de résumer un fil ou de chercher un truc en fonction de son sens.
Ce modèle, c'est à vous de le fournir, en indiquant à plMail l'adresse d'un Ollama qui tourne sur votre réseau ou de n'importe quel service compatible OpenAI. Et en plus du résumé et de la recherche par le sens, il sait rédiger des brouillons de réponse et trier votre courrier dans des onglets, chacune de ces quatre fonctions s'activant séparément.
Côté pièces jointes, plMail sait aussi aller chercher un fichier ou en ranger un dans Nextcloud, Immich, Paperless-ngx, Google Drive, Google Photos, OneDrive ou Dropbox. Et pour sécuriser l'accès, vous avez la double authentification, et la connexion via Authentik, Keycloak ou n'importe quel fournisseur OpenID Connect. Et l'interface est traduite en français.
Maintenant, pour brancher Gmail, il faut d'abord enregistrer une application OAuth dans la console Google Cloud, ce qui n'est pas forcément super simple pour tout le monde (tout est cependant très bien expliqué dans le doc). Par contre, un compte IMAP classique, lui, s'ajoute très rapidement dans le menu Settings > Mail accounts.
Après niveau mobile, c'est pas encore ça puisque même s'il y a bien une appli iPhone / Android, faudra compiler celle pour iPhone vous-même ( l'APK Android , lui, est fourni). De plus, côté serveur, marquer un message lu dans plMail le marque lu sur le serveur sans que l'inverse ne soit possible. Donc vaut mieux ne lire vos boîtes QUE dans plMail. Hé oui c'est un projet encore un peu jeune, c'est vrai.
En attendant mieux, sachez que plMail parle JMAP, donc un client mail compatible peut s'y brancher avec un mot de passe d'application généré dans Settings > App passwords. Et c'est aussi une PWA, ce qui permet à votre navigateur de l'installer comme une appli et de vous notifier des nouveaux mails même quand l'onglet est fermé, à condition d'avoir généré les clés VAPID du serveur (la doc explique comment).
Pour l'installer, il vous faut Docker :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) git clone https://github.com/karatektus/pl_mail.git
cd pl_mail
docker compose up -d
Vous ouvrez ensuite le localhost ou votre NAS en https, vous créez votre compte et vous acceptez une fois pour toutes l'avertissement du certificat auto-signé. Sur TrueNAS, sachez que l'appli est dans leur catalogue.
Après pour sauvegarder les datas de PlMail, conservez bien ces 2 choses séparément : D'un côté la base PostgreSQL et de l'autre, le fichier var/secrets/generated.env, qui contient la clé des mots de passe de vos boîtes.
Source : Noted
Je ne sais pas si vous connaissez curl.md, mais c'est un service qui prend l'adresse d'une page web et vous l'affiche en Markdown. Y'a pas de menus, pas de bandeaux de cookies, et ce genre de conneries... C'est juste le texte de votre article, les titres, les liens et les tableaux.
Et le plus sympa, c'est que vous n'avez rien à installer pour l'essayer. Vous collez curl.md/ devant l'adresse qui vous intéresse, dans la barre de votre navigateur, et vous obtenez la page en texte markdonw. Avec curl dans un terminal, c'est pareil, la réponse arrivera en text/markdown, et si vous préférez du JSON, vous envoyez l'en-tête Accept: application/json.
Un article de korben.info passé par curl.md : le texte, les liens, et un en-tête de métadonnées en haut
Et vous pouvez aller plus loin
en ajoutant un objectif
avec le paramètre --objective. Par exemple, vous décrivez ce que vous cherchez dans la page, et le service ne vous renvoie que le passage qui correspond. Il y a aussi des mots-clés, qui font un pré-filtrage avant l'extraction, et un mode smart ou rush selon que vous voulez une passe plus poussée ou plus rapide. Tout ça passe en paramètres d'URL, donc sans ligne de commande.
Pour ceux qui y reviennent souvent, il existe également un client à installer avec npm, avec bun ou avec un script, et qui s'invoque ensuite par curl.md ou par son alias court md :
# Sans rien installer
curl curl.md/example.com
# Ou avec le client
npm i -g curl.md
md zod.dev/error-formatting --objective "tree error formatting"
Côté agents de code, il y a des intégrations natives pour Amp, Claude, OpenCode et Pi. Si votre outil n'est pas dans la liste, le client sait aussi tourner en serveur MCP avec curl.md --mcp, et il existe un SDK TypeScript. Dans tous les cas, c'est l'agent qui va chercher les pages tout seul, vous n'avez plus rien à lui coller.
Du coup, ça sert à quoi ?
Bah dans le cadre de votre boulot, c'est surtout pour arrêter de coller des pages entières dans vos prompt. Vous donnez à votre agent la doc d'une bibliothèque avec un objectif précis, et il reçoit trois paragraphes au lieu de quarante pages HTML.
Ça marche aussi pour un script de veille qui suit les notes de version d'un projet, ou pour aspirer une doc dans un fichier texte que vous garderez dans le dépôt (bien plus lisible qu'un PDF dans un coin...).
Et en usage perso, ça vous permet de récupérer par exemple un article pour le relire au calme dans Obsidian, d'archiver une recette ou un mode d'emploi avant qu'il disparaisse, ou de vous envoyer une page à ChatGPT sans lui faire avaler la moitié du site autour. Notez que si c'est la consommation de vos agents qui vous embête, j'avais parlé de RTK, un proxy qui économise des tokens sur le même principe.
Par contre, il y a un plafond. En mode anonyme sur la version hébergée, vous avez droit à 100 requêtes par heure, et 1 000 une fois connecté. Et pour les requêtes avec un objectif, celles qui font justement l'intérêt du truc, c'est 3 par heure en anonyme et 10 en étant connecté. Bref, de quoi essayer, mais pas vraiment de quoi travailler... Au-delà, faudra passer par des crédits prépayés, à recharger par tranches de 5, 10, 20 ou 50 dollars.
Et si vous ne voulez pas dépenser d'argent, le code source est public sur GitHub sous licence MIT pour l'auto-héberger chez vous.
C'est à tester sur curl.md , et merci à Camille Roux pour le lien !
Pour fabriquer une application Windows native, le passage par Visual Studio était jusqu'ici la voie normale. Mais c'était sans compter sur Microsoft qui a publié winapp , un outil en ligne de commande qui permet de faire tout pareil directement depuis un terminal : il crée le projet, le construit, le lance avec son identité de paquet et sort le résultat sous la forme d'un fichier d'installation MSIX.
C'est encore estampillé en version "expérimentale" par ses auteurs, mais ça fonctionne déjà très bien pour des trucs basiques. C'est pour ça qu'aujourd'hui, je vous propose un petit tuto pour afficher un Hello World dans une vraie fenêtre Windows. Vous allez voir, c'est fastoche !
Il vous faut donc Windows 10 version 1809 au minimum, le mode développeur activé dans Paramètres, Système, Options avancées, et le SDK .NET 10 ou plus récent. Visual Studio, non par contre, y'en a pas besoin. Les deux installations se font via winget, dans un terminal normal :
winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget
Faites ensuite un winapp --version et vous saurez si le CLI répond.
La commande new fabrique l'application à partir des modèles WinUI 3 officiels, qu'elle télécharge toute seule dès qu'on la lance. Sans option elle vous pose des questions, mais avec celles que je vous mets ci-dessous, elle ne demandera rien et prendra le modèle le plus dépouillé du lot :
winapp new --template winui --name HelloKorben --use-defaults
cd HelloKorben
Vous récupérez alors un projet C# complet, avec son manifeste de paquet et ses icônes. Et surtout, le modèle winui vous donne une fenêtre vide, ce qui tombe bien puisqu'on va écrire dedans. Notez que le pack de modèles est encore publié en 0.0.6-alpha, donc si un nom de fichier a bougé depuis, winapp new --list vous sortira la liste de ce que le vôtre propose.
Attention, là y'a un petit piège ! Le fichier qui décrit la fenêtre s'appelle MainWindow.xaml, sauf que ce n'est pas celui-là qu'il faut toucher. Ouvrez plutôt MainPage.xaml, qui est à la racine du projet, et remplacez son <Grid /> vide par ces quelques lignes :
<Grid>
<TextBlock Text="Hello World !"
HorizontalAlignment="Center"
VerticalAlignment="Center"
FontSize="48" />
</Grid>
Ensuite, un petit winapp run construira le projet, l'enregistrera auprès de Windows avec une identité de paquet qui pointe droit sur votre dossier de build, et le lancera. Votre fenêtre s'ouvre alors avec le Hello World au milieu :
winapp run
La fenêtre HelloKorben ouverte par winapp run, et derrière, le terminal qui vient de la construire en 12 secondes
Bon, là, on a fait un Hello World, mais bien sûr, si vous faites chauffer une IA là-dessus, vous pouvez faire des trucs un peu plus complexes sans forcément savoir coder, et tout ça, une fois encore, sans Visual Studio.
Maintenant, à quoi bon empaqueter ?
Cette identité de paquet, ce n'est pas de la paperasse. En fait c'est elle qui ouvre à votre application les notifications natives, les associations de fichiers, les protocoles maison et les API d'IA locale de Windows. Donc si vous voulez du sérieux, il faut publier l'application compilée dans un dossier, et ça, c'est possible comme ceci directement dans votre terminal :
dotnet publish -o ./publish
L'empaquetage fabrique au passage un certificat de développement et l'installe dans le magasin Personnes de confiance de la machine mais faut que je vous prévienne, la commande qui suit réclame un terminal ouvert en admin dans lequel il faudra refaire le cd vers votre dossier de projet pour qu'il s'y retrouve.
winapp pack ./publish --generate-cert --install-cert
Le MSIX signé sort dans le dossier du projet, nommé d'après le GUID du paquet
Vous obtenez alors un .msix signé, nommé d'après l'identité du paquet, sa version et son architecture, qui s'installe chez vous d'un double clic. Et cette identité, le modèle la génère sous forme de GUID : ne cherchez pas le nom de votre application dans le nom du fichier. Par contre, ne l'envoyez pas tel quel à un collègue, parce que le paquet réclamera le runtime Windows App SDK. Ajoutez --self-contained à la commande pack et le runtime partira dans le paquet. Le certificat, lui, reste un certificat de développement local : sur le PC d'en face, Windows refusera le paquet tant que ce certificat n'y sera pas installé aussi.
Maintenant, si vous vous demandez à quoi sert vraiment ce CLI, c'est surtout l'étape MSIX qui sera moins douloureuse car vous n'aurez pas besoin de lancer Visual Studio.
Source : Neowin
Vous avez déjà pesté contre votre télé qui refuse de lire une vidéo pourtant toute bête trouvée sur le web ? Hé bien Kilian Houpeurt aussi et c'est pourquoi il a décidé, plutôt que de râler dans le vide comme un mec lambda sur Twitter, qu'il allait prendre le taureau par les cornes et coder sa propre solution.
Ça s'appelle Castor et évidemment ça envoie du bois, lol. En fait c'est un outil en ligne de commande écrit en Go qui est open source et qui permet d'envoyer le vrai flux vidéo d'une page Web directement sur votre télévision en qualité max sans avoir besoin de Chromecast, ni d'AirPlay.
L'astuce, c'est qu'il ne recopie pas votre écran comme le ferait un mirroring (qui rame et qui compresse tout, on est d'accord...). Vous lui donnez simplement l'adresse d'une page Web et lui va la charger dans un Chrome Headless, c'est-à-dire sans interface et capter le trafic réseau grâce au Chrome Devtools Protocol. C'est le flux vidéo ensuite qui transite qui est repéré et qu'il prend à la source.
Derrière, vous vous en doutez,
ffmpeg
transcode à la volée pour votre télé pendant que ffprobe détecte le format qui arrive. Pour alimenter Castor, vous avez alors trois possibilités, soit vous lui fournissez une page Web avec la commande castor cast player, soit vous lui passez un flux brut en .m3u8 avec la commande castor cast url, ou alors simplement un identifiant IMDB/TMDB que Castor résoudra via les sources que vous avez configurées de votre côté.
Et si vous renseignez une clé TMDB, castor cast tout court vous sortira alors un navigateur interactif en plein terminal Et c'est là-dedans que vous pourrez filtrer par genre (ou peu importe la métadonnée que vous voulez) ou parcourir les films comme vous le feriez sur Netflix, ou encore aller explorer les épisodes d'une série. Qui vous fait envie. Tout ça sans jamais quitter votre terminal. Ça a quand même un peu de gueule !
Le navigateur TMDB de Castor, directement dans le terminal.
Castor sait les générer lui-même les sous-titres avec whisper.cpp avant de les incruster dans la vidéo, Mais attention quand même, le modèle par défaut ne comprend que l'anglais, si vous voulez du français, faudra faire pointer Castor vers un modèle whisper multilingue.
Enfin, côté réception, Castor sait causer DLNA / UPnP, un protocole que Samsung, LG, Sony Bravia, Panasonic, Philips, Hisense ou encore TCL savent gérer depuis des années. Un petit castor scan et il vous liste tous les récepteurs qui traînent sur votre réseau et vous verrez que Kodi, VLC et Plex répondront aussi présents. Pour ce qui est du support du Chromecast, c'est encore un peu expérimental, donc ne comptez pas trop dessus pour le moment.
L'installation sur Mac se fait via brew install --cask stupside/tap/castor. Prévoyez juste Chrome ou Chromium sur la machine + ffmpeg et ffprobe accessibles dans le PATH. Une image Docker existe avec tout dedans, mais méfiance sur Docker Desktop macOS ou Windows puisque la découverte réseau ne passe pas le bridge, donc le conteneur ne verra jamais votre télé.
Maintenant, ce n'est pas un outil de piratage, puisque Castor n'héberge rien du tout. C'est un outil générique qui pousse un flux vers une TV, et c'est à vous de respecter la loi ainsi que les conditions d'usage des sites. Bref, ne castez que ce que vous avez le droit de regarder. Pour envoyer un flux
IPTV
ou un bête .m3u8 sur l'écran du salon, c'est en tout cas, super pratique.
Si vous bidouillez un serveur média maison, allez donc jeter un œil à Castor , le dépôt vaut le détour !
"Climatiser son appartement, c'est réchauffer celui du voisin." Vous l'avez forcément déjà entendue, cette bonne blague là... C'est comme ça que commence la dernière vidéo de Numerama, où durant 23 minutes, Julien Cadot démonte une par une les idées reçues sur la climatisation.
Et j'ai trouvé ça passionnant et d'utilité publique, donc je vous la partage. Le point de départ, c'est que la clim et la pompe à chaleur qu'on vous subventionne à coups de milliers d'euros, c'est rigoureusement le même objet. Même compresseur, même fluide, même physique. En France, on a quand même réussi le tour de force d'avoir une technologie qu'on subventionne l'hiver et qu'on diabolise l'été, comme il le dit dans la vidéo.
Je ne vais pas vous refaire la vidéo, elle se suffit largement à elle-même. L'îlot de chaleur urbain ? Les clims de TOUT Paris pèsent à peu près autant sur la température des rues que le trafic automobile dont personne ne parle jamais. Les fluides "1000 fois pires que le CO2" ? Un combat gagné il y a 30 ans, votre clim récente tourne au R32 voire au propane. On nous vend la peur d'un combat que la science a réglé depuis longtemps et je me demande bien pourquoi...
Et avec le kWh français ultra décarboné, si un pays sur Terre peut être climatisé proprement, c'est bien la France. Alors pourquoi s'en priver ??? La canicule de 2003 a tué 15 000 personnes. Celle de juin dernier compte déjà un bon millier de morts, à 85 % des plus de 65 ans, souvent chez eux dans des chambres à 35°C. Alors Julien pose la vraie question : faut-il continuer à sacrifier l'endroit où les gens vivent pour garder le trottoir un demi-degré plus frais ? Surtout que vu le climat qui attend nos villes dans 20 ans , les nuits fraîches ne reviendront pas.
Et moi, ce qui me sidère, c'est la réticence des gens. Je parle pas de ceux qui n'ont pas d'argent pour en faire poser une. Je parle de ceux qui ont la thune mais que ça embête de faire installer une clim, parce que "l'écologie" ou je ne sais quoi d'autre. Même des vieux qui souffrent dans leur maison, il faut vraiment insister pour les convaincre... Dur dur. Les anti-clim, pour moi, c'est comme les antivax. Ce sont des gens qui se reposent sur des trucs entendus il y a des années, qui se sont arrêtés là et qui se refilent des infos périmées entre eux. C'est dommage quand même de littéralement mourir de chaud juste par connerie.
Et l'administration n'aide pas, avec des PLU meurtriers qui nous interdisent les unités extérieures en façade. C'est dire le niveau de connerie institutionnelle dans ce pays.
Perso je déménage bientôt en location, et là il n'y a pas la clim, et en plus il y a une véranda... je pense que je vais devoir prendre une clim portable, alors que c'est le pire des 2 mondes, bruyant et énergivore, mais bon, c'est pas chez moi. J'essaierai quand même de convaincre la propriétaire d'en faire installer une vraie, quitte à en payer une petite partie. Je lui ferai regarder la vidéo, tiens.
Et si vous sautez le pas : comptez quelques milliers d'euros pour une clim fixe posée par un pro, prenez des modèles silencieux pour les chambres, et anticipez dès cet hiver parce que les installateurs sont débordés chaque été. L'article de Numerama détaille tout ça par écrit si vous voulez aller plus loin.
Voilà, vive la clim ! Et si un anti-clim vous ressort le coup des fluides qui trouent la couche d'ozone, offrez-lui un calendrier, parce que visiblement sa capacité à comprendre le monde s'est arrêtée en 1995.
Vous vous souvenez de Windows Movie Maker ? Mais siiii, ce petit logiciel de montage livré avec les Windows depuis l'époque de Windows ME ? C'est celui sur lequel vous avez bricolé vos premiers diaporamas de vacances avec des transitions en forme d'étoile. Aaah, ça vous parle maintenant, hein ?
Eh bien, ces gros méchants de Microsoft l'ont laissé mourir en janvier 2017. Mais heureusement, SkylerDaGirl vient de le remettre au goût du jour et vous pouvez maintenant télécharger un installer fonctionnel sur Internet Archive qui va vous permettre d'installer la V6.0.
Le site Windows Latest l'a testé et apparemment c'est incroyable parce que Movie Maker s'est contenté d'une vingtaine de Mo de RAM alors que son remplaçant officiel, Clipchamp, lui, en réclamait près de 800 Mo pour faire globalement la même chose. D'après les captures d'écran du testeur, ça fait à peu près 97% de mémoire en moins pour l'ancêtre. Une fois encore, ça prouve que les logiciels modernes sont comme nous, ils grossissent au fil des années...
Maintenant, si vous cherchez plutôt du léger côté navigateur, il y a d'ailleurs des alternatives modernes comme Cutia ou Pikimov qui tournent sans installer une usine à gaz.
Après, je ne vous conseille pas non plus de passer sur Windows Movie Maker, parce que déjà, ce n'est pas un logiciel supporté officiellement par Microsoft. Ces derniers n'ont absolument rien ressuscité. Et puis ces fameux 97%, c'est une mesure qui a été réalisée par un seul testeur et pas vraiment un benchmark qu'on peut reproduire. Donc bon, vous pouvez essayer, mais il n'y a aucune promesse.
Et surtout, gros panneau ACHTUNG ACHTUNG côté sécurité puisque ce build n'est plus supporté par Microsoft depuis neuf ans, donc zéro correctif, zéro garantie sur ce que contient réellement l'installeur.
M'enfin, ceux qui aiment gratter la nostalgie apprécieront ce portage et également l'effet VHS de ntsc-rs pour donner à vos exports ce grain d'époque qui va bien avec l'esthétique Movie Maker ^^.
Peter Steinberger, le papa de PSPDFKit , s'est mis en tête de faire sortir WhatsApp de sa prison dorée. Et pour cela, il a mis au point wacli, un client WhatsApp qui tourne exclusivement dans votre terminal. Ça se compose donc de commandes que vous pouvez scripter dans la joie et la bonne humeur pour enchaîner et automatiser toutes vos idées folles sur Whatsapp comme avec n'importe quel outil Unix.
Wacli se connecte à votre compte comme un appareil lié, exactement comme WhatsApp Web, vous scannez un QR code depuis votre téléphone et hop, l'outil rapatrie vos conversations dans une base SQLite locale, sur votre machine. À partir de là, la recherche se fait hors ligne.
Un wacli messages search "réunion" et vous ressortez un vieux message noyé dans la masse, sans même être connecté. Pour envoyer un message, un wacli send file --to maman --file ./photo.jpg et c'est parti. Et les groupes et les contacts se pilotent de la même façon, réactions comprises, au clavier.
Côté technique, c'est du Go bâti sur
whatsmeow
, la bibliothèque de référence qui parle le protocole WhatsApp Web multi-device. Comme ça vos messages restent chiffrés de bout en bout. Et de son côté, la base locale offre une recherche plein texte instantanée (FTS5), et à peu près tout ressort en JSON avec le flag --json, ce qui veut dire que vous pouvez brancher wacli sur vos propres scripts, un cron, un pipeline de sauvegarde, ou tout ce que vous voulez.
Les données atterrissent ensuite dans ~/.wacli sur votre Mac, et vous en faites ce que bon vous semble. Un brew install openclaw/tap/wacli et c'est installé (Oui, le projet est passé sous l'organisation openclaw).
Et comme le tout est sous licence MIT, vous pouvez bidouiller ça comme bon vous semble.
Maintenant, la partie où je dois être franc avec vous c'est que wacli n'est pas un outil officiel. Il passe par le protocole WhatsApp Web récupéré par rétro-ingénierie via whatsmeow, et Meta n'aime pas trop ça.
Le README le dit noir sur blanc, c'est un outil tiers non affilié à WhatsApp. En clair, vous jouez avec les conditions d'utilisation, et un compte repéré sur ce genre de manip peut se faire suspendre. À réserver donc à un usage perso et raisonnable, et pas pour faire du spam de masse.
Reste que pour qui veut reprendre la main sur ses données, c'est pile le genre d'outil que j'aime. Dans le même esprit que msgvault qui libère vos emails de la prison Gmail , mais pour la messagerie de Meta.
Merci Camille Roux pour le lien !
Source : https://github.com/openclaw/wacli
Les devs de chez Google viennent de sortir un outil conçu pour les agents IA qui codent afin qu'ils deviennent des experts en développement d'agents IA sur Google Cloud. J'sais pas si je suis très clair, alors je vais essayer de vous expliquer tout ça.
Que vous soyez sur Claude Code, Codex d'OpenAI ou Gemini CLI (ça s'appelle agy cli maintenant d'ailleurs pour Antigravity CLI...), écrire un agent qui tient la route et le faire tourner dans le cloud de Mountain View, ça exige déjà de connaître par cœur l'ADK (Agent Development Kit) maison de Google, de savoir évaluer et coder le projet et surtout de tout déployer sans tout péter.
Ce sont clairement plusieurs métiers différents, et ça demande pas mal de connaissances, alors plutôt que de vous faire lire une doc bien chiante, les dev de Google ont eu l'idée de packager toute cette expertise dans des skills que votre agent de coding va lire à votre place.
Après, vous votre rôle, c'est de décrire tout ce que vous voulez en anglais ou en français et de siroter votre mojito. Et une fois que vous aurez fini, votre super agent générera le squelette du projet, le testera en local et poussera tout ça dans un runtime sur Google Cloud.
Pour l'installer, suffit de faire un petit :
uvx google-agents-cli setup
ou si vous voulez juste injecter les skills dans votre agent sans la CLI complète :
npx skills add google/agents-cli
Une fois la machinerie en place, vous aurez à votre service 7 modules de skills et 25 commandes qui couvrent tout le cycle de vie des agents Google Cloud, du scaffolding (croyez le ou non, en français, ça se dit échafaudage ...lol) à la publication sur Gemini Enterprise (ex-Vertex AI). Et puis Agents-CLI sait surtout générer tout ce qui est jeux de tests, noter les réponses avec un LLM qui fait office de juge, comparer 2 versions d'un même agent ou encore optimiser les prompts à partir des résultats collectés.
C'est du taf pénible qui rebute tout le monde, alors qu'un agent IA se le tape, je pense que ça ne manquera à personne. On est dans la même veine que les outils qui font collaborer plusieurs IA sur votre code, sauf qu'ici l'objectif final c'est de déployer des agents dans le cloud en prod.
Le code et les instructions sont sur le GitHub de Google .
Quand vous demandez à un assistant IA de corriger une faille dans une de vos dépendances, il vous propose presque toujours la même chose : ajouter ce qu'on appelle un "override", une ligne de configuration qui force votre projet à utiliser une version saine d'une brique logicielle.
Le conseil semble bon sur le moment. Mais voilà, personne ne vous dit jamais de revenir vérifier, six mois plus tard, que cette ligne sert encore à quelque chose.
C'est précisément le trou que vient boucher CVE Lite CLI , un scanner gratuit et open source développé par Sonu Kapoor et adoubé par l'OWASP, la fondation qui fait référence en sécurité des applications. Cet outil a l'avantage de tourner en local, sans compte ni cloud, et sans qu'une seule ligne de votre code ne quitte votre machine.
Le problème qu'il cible est très simple. Une dépendance dite transitive, c'est une brique dont dépend une autre brique que vous, vous avez installée : vous ne l'avez jamais choisie vous-même, mais elle se retrouve quand même embarquée dans votre projet. Pour neutraliser une faille planquée là-dedans, on force une version corrigée via un override. Le souci, c'est que cette rustine vieillit toute seule, dans votre dos.
Kapoor a du coup ajouté une fonction qui audite ces configurations et débusque trois cas de figure : l'override pointe vers un paquet qui n'existe tout simplement plus, il s'applique au mauvais gestionnaire de paquets, ou il utilise un motif de caractères (une sorte de joker censé attraper plusieurs chemins d'un coup) qui en réalité ne correspond à rien. Dans tous ces cas vous vous croyez protégé alors que la protection est tombée depuis un moment.
Pour le prouver, il a passé quatre projets JavaScript très utilisés au crible, et les résultats sont parlants. Cal.com en alignait 90, dont 11 complètement inopérants ; Jest traînait une configuration qui pointait dans le vide ; NoCoDB empilait des jokers inefficaces ; seul Next.js s'en sortait sans le moindre défaut.
Entre l'affaire node-ipc de 2022, où un développeur avait lui-même saboté son propre paquet par militantisme, et la vague d'attaques Shai-Hulud de ces derniers mois, un ver qui se réplique tout seul en volant les jetons d'accès des développeurs sur npm pour contaminer au passage tous leurs autres paquets, l'écosystème JavaScript prend cher. Et un override mort, c'est une porte qu'on croyait verrouillée.
Ce qui est amusant, c'est que l'outil censé rattraper les approximations des IA est, lui, volontairement dépourvu de toute IA. Il interroge sagement une base de vulnérabilités connues et vous recrache des commandes prêtes à copier-coller, sans deviner quoi que ce soit.
Quoi qu'il en soit, on a là un petit outil tout bête qui repasse derrière l'IA, et franchement, ça rassure.
Source : The Register
Si vous passez votre vie dans un terminal et que vous avez réussi un jour à quitter tout seul Vi / Vim, voici une application qui va vous intéresser. Il s'agit de Tanko , signé Alexandro Mendez, un outil en ligne de commande qui permet de lire et télécharger vos mangas préférés directement depuis un terminal. C'est, en gros, le même concept que youtube-dl mais pour les scans japonais.
Pour installer Tanko, ouvrez un terminal et entrez la commande suivante : pnpm install -g tanko (npm marche aussi). Une fois que c'est fait, y a plus qu'à lancer tanko. Plus besoin d'aller sur les sites en question, vous entrez vos critères de recherche et hop, vous lisez votre chapitre directement. Les chapitres que vous téléchargez en PDF atterrissent dans $HOME/tanko/downloads/.
Après, Tanko affiche les vraies pages en image, à condition d'utiliser un terminal moderne comme Kitty, Ghostty ou WezTerm qui gèrent les protocoles graphiques (Kitty graphics, Sixel). Mais surtout dans un terminal basique, genre le terminal intégré de VS Code ou le bon vieux CMD de Windows, Tanko basculera en mode ASCII Art.
J'suis sûr que vous voyez où je veux en venir... Votre boss passe derrière vous, voit des caractères bizarres défiler dans VS Code, et repart convaincu que vous compilez un truc alors que pendant ce temps-là vous suivez peinard le dernier chapitre de One Piece... niark niark niark.
Côté fonctions, vous avez l'historique de lecture, un menu de config, les notifications et le support de plusieurs sources de scans. Attention quand même, certaines sources scrappent les sites via un navigateur, donc il faudra installer Firefox avec npx playwright install firefox. Après c'est pas non plus obligatoire et vous pouvez vous contenter des sources qui n'en ont pas besoin.
L'outil est cool mais après en ce qui me concerne, lire un manga en ASCII Art c'est marrant 30 secondes, mais pour de la vraie lecture je vous conseille vraiment d'opter pour l'un des terminaux avec support des images que je vous ai cités plus haut.
Et si votre but c'est juste d'aspirer des tonnes de scans, le vieux mangal est plus complet, même s'il est archivé depuis avril 2025 et que plus personne ne le maintient... sniiif. Dans le même style, ça me rappelle aussi Lue qui vous lit vos ebooks en audio dans le terminal et si vous préférez un truc avec une vraie bibliothèque, jetez plutôt un œil à Kavita .
Et enfin, roulements de tambours, pour savoir où trouver vos scans sans finir en correctionnelle, j'avais fait un guide sur le manga et le scantrad .
Bref, c'est gratuit, mais à consommer avec modération pendant les heures de boulot, bande d'ennemis du capitalisme ^^ !!
Grasp , c'est une alternative décentralisée à GitHub, signée DanConwayDev, le dev derrière ngit. Ça carbure à Nostr , le protocole décentralisé de fiatjaf, et l'idée avec ce truc, c'est que votre identité de dev, ce n'est plus un compte avec un email et un mot de passe, mais juste une paire de clés cryptographiques qui ne dépend de personne. Vous publiez votre code depuis le terminal, sans avoir à vous inscrire nulle part et pi c'est tout !
Vous me connaissez, j'adore fureter à la recherche de petits outils cools à partager avec vous, et niveau décentralisation, celui-là vaut le détour. Pour tester, ça se passe avec l'outil nak . Vous créez votre dépôt, vous le synchronisez, vous poussez comme ceci :
nak git init --owner <votre-clé-npub> --identifier mon-projet --name "Mon Super Projet" --description "Mon premier repo Grasp"
nak git sync
nak git push
Pour cloner le dépôt de quelqu'un d'autre, c'est nak git clone <npub-du-maintainer>/mon-projet, et pour lui envoyer un patch, nak git patch send HEAD^. Pas de fork ni de pull request à remplir dans une interface pour contribuer au code des autres... C'est beau non ?
Derrière, tout repose sur Nostr et sa spec NIP-34 qui transforme un dépôt, une issue ou un patch en messages signés que n'importe quel serveur peut relayer. Du coup chaque état de votre code est signé par votre clé, et comme ça, vos dépôts migrent d'un serveur à l'autre sans rien perdre. Impecc si vous ne faites pas confiance aux hébergeurs.
La vraie différence avec un Forgejo ou un Gitea que vous auto-hébergez, c'est donc que vous ne créez pas un compte sur chaque instance. Votre identité Nostr vous suit partout, une seule clé pour tous les serveurs ! À ne pas confondre par contre avec Radicle , qui fait du P2P local-first avec son propre protocole gossip et Git en natif (et pas sur IPFS, contrairement à ce qu'on lit souvent, le vrai GitHub-sur-IPFS ce serait plutôt GitLike ).
Grasp, lui, parie sur l'interopérabilité : plusieurs clients, plusieurs serveurs, un seul standard, et tout communique.
Et l'écosystème est déjà bien debout avec ngit-grasp comme serveur de référence, pyramid pour gérer une communauté, viewsource.win pour visualiser le code dans le navigateur, et gitworkshop.dev pour une interface complète façon GitHub.
Maintenant ce n'est pas non plus la solution miracle, car c'est encore un peu trop jeune à mon goût... Mais c'est à tester car le jour où l'un de ces frontends web deviendra vraiment carré et grand public, il pourrait bien venir taquiner GitHub, et ça, c'est plutôt une bonne nouvelle...
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 !
Si vous cherchez une alternative à Termius qui ne vous coûte pas une petite couille, je crois que j'ai trouvé ce qu'il vous faut !
C'est vrai qu'il y a quelque chose de carrément agréable à pouvoir ouvrir un navigateur depuis n'importe quelle machine et retrouver tous ses serveurs, fichiers et tunnels au même endroit... Et Termius fait ça très bien, sauf que la fonctionnalité la plus utile, à savoir la synchro entre appareils, c'est payant !
Et c'est ça la raison d'être de Termix qui propose exactement ça mais en open source, en gratos et à héberger vous-même !
Termix, c'est donc une plateforme de gestion de serveurs accessible depuis le navigateur. On y retrouve un terminal SSH complet, de la gestion de fichiers distants, des tunnels SSH inversés, et depuis la v2.0 sortie en mars dernier, le support RDP, VNC et Telnet.
En clair, ça couvre à peu près tout ce dont on a besoin pour piloter une infra depuis un seul endroit. Petit détail à noter quand même, le RDP/VNC/Telnet n'est pas inclus par défaut, donc il faut ajouter un second conteneur guacd au compose. Rien de compliqué, mais à savoir avant de se lancer.
Le terminal SSH supporte jusqu'à 4 panels simultanés comme ça plutôt que de multiplier les sessions, vous regroupez au même endroit. Le gestionnaire de fichier est aussi très sympa avec du drag & drop dans les deux sens, la modification de fichiers distants directement dans le navigateur... Et y'a aussi une gestion des conteneurs Docker intégrée, un Network Graph pour visualiser les connexions entre hôtes, et un système de snippets de commandes pour éviter de retaper les mêmes commandes à longueur de journée.
Ce qui change par rapport aux autres alternatives web, c'est surtout sa dispo sur toutes les plateformes. L'accès web est évidemment central, mais il existe aussi des apps natives pour Windows, Linux, macOS (App Store, DMG ou Homebrew selon vos préférences), iOS/iPadOS et Android.
Tout se synchronise ensuite via le conteneur self-hosted comme ce que permet Termius, à la différence près que vous hébergez vous-même le système.
Côté sécurité et gestion d'équipe, Termix intègre du RBAC, de l'OIDC, du 2FA, et stocke les données dans une SQLite chiffrée.
Pour tester en local, le docker-compose de base ressemble à ça :
services:
termix:
image: ghcr.io/lukegus/termix:latest
ports:
- "8080:8080"
volumes:
- termix-data:/app/data
volumes:
termix-data:
Attention à la config réseau avant tout puisque le port 8080 par défaut est souvent filtré ou déjà occupé donc changez ça dans le compose si besoin. Ajoutez ensuite le conteneur guacd si vous voulez le RDP/VNC/Telnet (je vous laisse aller lire la doc).
Après l'interface est fonctionnelle mais pas aussi léchée que Termius. Y'a pas de passkeys, et pas de support ed25519-sk pour les clés de sécurité hardware.
Pour une utilisation personnelle ou une petite équipe qui gère de l'infra linux, c'est largement suffisant, cela dit. Bref, si Termius c'est pas fait pour vous parce que c'est encore des sousous à sortir, sachez que Termix est là pour vous.
Merci Letsar pour le lien !
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...
Monter un serveur HTTPS local pour bosser sur du Next.js ou du Vite, ça reste étrangement chiant. Faut mkcert pour générer les certifs, faut éditer le /etc/hosts à la mimine, installer caddy ou nginx en reverse proxy par-dessus... bref, vous voyez le diiiiliiiire ! Heureusement, Kamran Ahmed , le mec derrière roadmap.sh, vient de balancer Slim , un binaire Go standalone qui fait tout ça d'un coup.
Et tant qu'à faire, il rajoute aussi des tunnels publics à la ngrok au cas où vous voudriez présenter votre travail de dev payé au lance pierre, à un client pressé.
L'idée c'est donc de taper : slim start myapp --port 3000 et hop, votre app tourne OKLM en local sur le port 3000 et devient accessible via https://myapp.test avec un certif totalement valide reconnu à 100% par votre navigateur.
Ça permet d'esquiver tout config manuelle, puisque le binaire crée une autorité de certification locale (CA) dès le premier lancement, signe ensuite les certifs par domaine, et met à jour /etc/hosts tout seul, sans oublier de rediriger les ports 80/443 sur 10080/10443 sans même avoir besoin de root.
Et cette CA est ajoutée au trousseau du système, donc votre Chrome, Safari ou Firefox (ze best !!) la considèrent immédiatement comme légitime, sans alerte de sécurité. Du tout-en-un comme je l'aime quoi !
L'install se fait en une ligne (pensez à regarder comme d'hab le contenu du fichier .sh avant de le lancer, je ne le répéterais jamais assez) :
curl -sL https://slim.sh/install.sh | sh
Ensuite, pour les domaines, vous avez le choix entre .test (par défaut), .loc ou .dev. Notez que Kamran a explicitement banni le .local parce que ce TLD est réservé à mDNS et que ça fout en l'air toute la résolution DNS sur macOS et Linux. Ouf !
Le routing par chemin est aussi de la partie. Si vous bossez sur une app Next.js qui tourne sur le port 3000 et une API séparée sur le 8080, vous pouvez tout router en 1 seule commande :
slim start myapp --port 3000 --route /api=8080 --route /ws=9000
Tout tape alors sur https://myapp.test, et c'est slim qui fait le découpage. Et si vous avez plusieurs services à orchestrer, un fichier .slim.yaml à la racine du projet permet de tout déclarer d'un coup et de lancer le bouzin avec slim up.
WebSocket et HMR sont également gérés nativement, donc ça marche direct avec Vite et Next.
Maintenant, l'autre moitié de l'outil c'est slim share --port 3000 --subdomain demo qui vous délivre une URL publique sur slim.show pour exposer votre localhost sur le net. Vous pouvez ainsi ajouter un mot de passe, un TTL d'expiration, voir les logs en direct... bref, c'est du ngrok-like classique mais déjà inclus dans le même binaire ce qui évite d'aller vous créer un compte séparé. Suffit de lancer un slim login pour activer le partage public.
Alors Slim c'est cool mais y'a pas de support Windows officiel pour l'instant... ce sera donc macOS ou Linux uniquement.
Et si vous êtes sur des stacks où vous avez déjà investi dans Tunnelto pour son dashboard d'introspection HTTP ou dans Tunnl.gg pour son approche zéro-client, slim n'apportera pas forcément de quoi migrer. Mais si vous galérez à empiler mkcert + caddy + ngrok à chaque nouveau projet, c'est pil poil ce qu'il vous faut.
Le code est sur GitHub et un grand merci à Philobois pour le partage !
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
ou
pup metrics query --query="avg:system.cpu.user{*}" --from="1h"
et l'agent récupère du JSON 100% clean, prêt à être bouffé et digéré par Claude Code, Cursor ou peu importe ce que vous utilisez.
Pour détecter le mode agent, Pup regarde les variables d'environnement type CLAUDE_CODE ou CURSOR_AGENT, et bascule tout seul en sortie machine, avec tout ce qui va bien, genre les metadonnées, les hints et autres auto-approbation des prompts destructifs (oui, c'est à utiliser avec prudence, mais je vous fais confiance, vous êtes des pro).
Les commandes sont aussi auto-découvrables via pup --help ou pup agent schema, donc l'agent peut introspecter ce qu'il a à disposition sans que vous lui mâchiez le travail.
Y'a même un moteur de runbooks en YAML pour chaîner des étapes (commandes pup, shell, HTTP, workflows Datadog) avec interpolation de variables, conditions et polling. Pratique donc pour scripter un triage d'incident ou un déploiement, sans sortir un Argo ou un Temporal pour ça. Et pour les setups un peu plus velus, pup se compile aussi en WASM, donc vous pouvez le faire tourner dans Wasmtime ou un Cloudflare Worker.
À noter, le projet est encore en Preview, et que certaines API ne sont pas implémentées (Session Replay, Powerpacks, IP Allowlist).
Vous synchronisez 4 ou 5 dossiers vers plusieurs serveurs avec rsync ? Alors vous connaissez ce sketch quand un job mouline pendant que les autres font la queue, parce que rsync de base c'est mono-thread et ça avance en file indienne.
Hé bien y'a un petit utilitaire Python qui dégoupille tout ça, pondu par overflowy. Ça s'appelle parallel-rsync et le nom annonce la couleur !
L'idée c'est de pouvoir empiler plusieurs jobs rsync en parallèle, avec une config YAML pour piloter le tout. Vous décrivez vos sources et destinations dans sync.yml, vous lancez parallel-rsync -c sync.yml --workers 4 --max-per-host 2, et hop, ça parallélise.
Le bougre tourne sur un ThreadPoolExecutor Python 3 qui spawn N processus rsync système avec un cap global et un cap par hôte. Et pendant ce temps, des barres de progression vous affichent l'avancement de chaque transfert sans que la console parte en sucette.
La dernière fois, je vous parlais de rsyncy qui collait juste une barre de progression à un rsync solo mais là, on monte clairement d'un cran avec une orchestration multi-cibles.
--workers cap c'est donc le nombre total de processus rsync simultanés (4 par défaut). --max-per-host limite la concurrence par destination (2 par défaut, histoire de ne pas saturer un seul serveur, parce que oui, balancer 8 rsync sur la même machine c'est juste se tirer une balle dans le pied côté I/O).
--timeout met une laisse à chaque rsync, --dry-run ajoute le flag à toutes les commandes pour tester avant de tirer, et --no-progress débraye les barres si vous voulez juste les logs. Côté logging, --log-file et --log-level font également le job.
Par contre y'a pas de retry automatique donc si une session SSH coupe en plein transfert, faudra relancer à la main. C'est logique mais un peu dommage.
Sur un homelab, ce genre de config YAML permet de résoudre le problème des synchros récurrentes avec un seul fichier centralisé au lieu de 8 scripts shell.
Notez aussi que le repo build un binaire universel via cosmofy , qui empaquette le tout en un exécutable cross-platform Windows, macOS et Linux d'un coup. Du coup, pas besoin d'installer Python sur la machine cible. Carrément pratique pour distribuer sur des serveurs où vous n'avez pas envie de gérer un environnement Python complet avec pip et un venv.
Petit point d'attention quand même : rsync lui-même doit être installé sur la machine qui lance le binaire, ce qui est natif sous macOS et Linux mais nécessite WSL ou Cygwin sous Windows.
Y'avait déjà
msrsync
qui découpe les transferts en buckets,
parsyncfp
qui s'appuie sur fpart pour grouper par taille, et la classique combine find . -type f | parallel -j10 rsync que tout sysadmin a bricolée un jour pour gratter de la bande passante. De son côté, overflowy se place plutôt sur le créneau "config déclarative" pour orchestrer plusieurs rsync entre sources et cibles.
Le code est sous licence MIT et tout se passe sur le repo GitHub . À tester si vous orchestrez régulièrement plusieurs rsync à la main.
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 !
Si vous bossez sur Mac et que Docker Desktop commence à vous prendre la tête, les amis, y'a une alternative super cool qui vient de débarquer. Ça s'appelle
Mocker
, c'est écrit en Swift, c'est sous licence AGPL-3.0, et le principe c'est de remplacer la CLI de Docker à l'identique : mêmes flags, mêmes formats de sortie, même syntaxe pour Compose. mocker run, mocker ps, mocker compose up (...bref, le README annonce 111 commandes et sous-commandes couvertes avec les flags qui matchent).
Pour l'installer, un brew tap us/tap && brew install mocker et c'est plié !
La plupart des images Docker Hub standards (format OCI) se pullent pareil, et votre fichier docker-compose.yml tourne le plus souvent sans rien retoucher. Attention quand même, si vous avez encore Docker Desktop qui tourne en parallèle, coupez-le avant de jouer avec mocker sinon vos ports vont faire la bagarre !
De plus, certaines features Docker très spécifiques (options de runtime exotiques, images qui tapent dans des sockets Linux particuliers) peuvent planter ou produire un avertissement côté Apple Containerization. Mais sur du stack web classique (nginx, postgres, redis, node), par contre, ça passe crème.
Mais alors, pourquoi ça fonctionne aussi bien ?
Hé bien parce que Mocker ne réinvente pas la roue, il l'enrobe. Rien de plus, rien de moins. En fait, sous le capot, c'est le framework Apple Container qui fait tout le boulot.
Pour rappel, c'est ce truc qu'Apple a sorti à la WWDC 2025 et qui permet ainsi de lancer une petite VM Linux dédiée par conteneur (au lieu de la grosse VM partagée à la Docker Desktop). Mocker délègue alors tout au binaire container d'Apple pour run, stop, exec et logs, tape directement dans le Containerization.ImageStore pour les pulls et les tags, et gère les ports via un petit proxy TCP userspace.
L'état des conteneurs, images, réseaux et volumes est alors stocké en JSON dans le dossier ~/.mocker/ sur votre Mac. Comme y'a rien de magique, vous pouvez tout inspecter à la main, ce qui est plutôt chouette !
Côté perfs, il y a quand même un coût. Selon les benchmarks publiés par le dev sur sa machine Apple Silicon, au démarrage d'un container Docker Desktop tourne à 320 ms, le CLI container d'Apple à 1030 ms, et Mocker à 1153 ms (3,6× plus lent que Docker, ~120 ms d'overhead sur Apple).
Dans la vraie vie, 800 ms de plus au boot c'est transparent si vous relancez 5 containers par jour en dev, mais ça devient clairement pénible si vous faites du CI local intensif avec 50 runs à la chaîne. Sur ces mêmes benchmarks, une fois que le container est up, CPU et mémoire s'en sortent ensuite pareil. Autrement dit, la VM par conteneur coûte au boot, mais pas au runtime. En tout cas, sur cette config de test pour les benchmarks.
Si vous voulez une alternative plus mature et commerciale, OrbStack reste encore une fois la référence sur Mac, mais c'est du freemium. Mocker, lui, est gratuit et open source du début à la fin.
Voilà les amis, si vous êtes sur Mac Apple Silicon et que Docker Desktop vous saoule, ça vaut grave le coup de tester !! Au pire vous revenez à Docker, au mieux vous gardez Mocker et vous arrêtez de payer la licence Business...
Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.
GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.
L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.
Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.
Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.
Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.
Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.
En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.
Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.
Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.
Source : The Register
Les beaux jours reviennent, et avec eux l'envie d'un soda bien frais ! Sauf qu'au lieu d'alimenter un énième groupe industriel (coucou Coca Cola), vous pouvez maintenant fabriquer le vôtre à la maison. Et blinry , un développeur allemand, l'a bien compris puisqu'il vient de publier sur GitHub ses 6 années de recherches sur le sujet... en CC0, donc dans le domaine public ! A vous votre copie cheap du Bougnat / Breizh Cola ^^
L'histoire commence en 2020. Le mec a deux problèmes simples à résoudre : la caféine lui file des migraines, et il veut éviter le sucre. Du coup il décide de se faire son propre cola, sans caféine, sans sucre, et surtout sans dépendre d'une marque qui garde sa formule secrète depuis plus d'un siècle.
Six ans plus tard, il a finalement trois recettes bien abouties : cola, orange, et amande (!). Toutes sont dispos sur son dépôt GitHub en markdown, dans le même esprit que Cooklang dont je parlais récemment . Et comme c'est du domaine public pur et dur, vous pouvez tout copier, modifier, revendre, tout ce que vous voulez.
Car concrètement, un cola c'est quoi ? Hé bien selon la recette de blinry, c'est un mélange de 7 huiles essentielles (orange, citron vert, citron, noix de muscade, casse, coriandre, lavande), un peu de gomme arabique pour l'émulsion, de l'acide citrique, du colorant caramel, et un édulcorant genre sucralose.
Ensuite, vous prenez une seringue d'un millilitre pour doser les huiles au centième de millilitre près, vous pesez le reste sur une balance de précision, et hop, vous avez un sirop concentré qu'il n'y a plus qu'à diluer avec de l'eau gazeuse !
Niveau matos, c'est assez basique... Balance, seringue, mixeur à main, un petit récipient en plastique, et voilà. D'abord vous mélangez les huiles avec la gomme arabique pour faire l'émulsion, ensuite vous ajoutez l'eau et le reste, puis vous filtrez. Par contre, attention, les huiles essentielles concentrées sont corrosives, donc c'est gants en latex obligatoires si vous ne voulez pas finir avec les doigts brûlés.
Et le verdict ? Hé bien le gars dit qu'il préfère son cola au vrai Coca, carrément ! D'ailleurs quand il a testé un Coca récemment pour comparer, il l'a trouvé, je cite "fade, genre glace au cola fondue". Moi j'suis plus Cherry Coke mais c'est compliqué d'en trouver du light, donc si je me lance là dedans, j'essayerai de bien doser en huile essentielle de cerise ^^.
Notez que Blinry n'est pas seul dans cette quête. Avant lui, il y a eu Cube Cola , OpenCola avant encore, et plus récemment un certain LabCoatz a utilisé carrément un spectromètre de masse pour décoder le profil de saveur. Bref, y'a tout un écosystème de gens qui essaient de percer le "secret" Coca-Cola depuis des décennies mais visiblement sans succès puisque tout ce que j'ai pu goûter en cola alternatif était vraiment pas ouf... Ça sent trop le médicament aux plantes en général.
Et comme Coca n'a jamais breveté sa formule parce qu'un brevet aurait tout révélé, le vrai produit qu'ils vendent, c'est surtout le mystère autour de la formule. Donc il suffit qu'un de ces bidouilleurs de soda perce le mystère et demain on aura du coca 100% similaire à l'original niveau goût, 100% sous licence libre ! Ce serait fou !
Bref, servez-vous, modifiez, et surtout partagez vos améliorations sur son Git. Et si vous trouvez la recette ultime, faites signe !
MZLA, la filiale de la Mozilla Foundation qui gère Thunderbird, sort un client IA open source auto-hébergeable baptisé Thunderbolt. Multi-plateforme, compatible MCP et Agent Client Protocol, avec intégration du framework Haystack de deepset pour le RAG et les agents. Le tout doit pouvoir tourner sur votre infra, pas chez OpenAI.
Le positionnement est clair. Ryan Sipes, le patron de MZLA, résume : "Est-ce que vous voulez vraiment construire vos workflows IA sur un service propriétaire d'OpenAI ou d'Anthropic, avec toutes les données internes de votre boîte qui transitent par leurs serveurs ?"
La question est vite répondue pour pas mal de DSI en ce moment, surtout en Europe où la souveraineté des données est devenue un sujet bouillant.
Thunderbolt utilise des modèles au choix de l'utilisateur et peut tourner sur une seule machine, sans cluster à gérer. Côté protocoles, la compatibilité MCP (Model Context Protocol) et ACP (Agent Client Protocol) ouvre l'interopérabilité avec les serveurs et agents du marché.
L'intégration de Haystack, le framework d'orchestration IA de deepset (boîte allemande), gère le RAG, les applications multimodales et les agents. Du coup, Thunderbolt ne fait pas que du chat, il peut chercher dans vos documents, croiser des sources, et exécuter des tâches.
La cible, c'est les entreprises qui veulent un Copilot ou un ChatGPT Enterprise sans donner leurs fichiers à Microsoft ou OpenAI. Le code est sur GitHub, et MZLA travaille aussi sur une version hébergée pour les petites équipes qui n'ont pas d'infra à déployer.
Côté crédibilité, MZLA a l'avantage du track record Thunderbird, un projet open source géré proprement depuis des années, avec une communauté active et un financement stable via la Mozilla Foundation. Ce n'est pas un énième side project IA lancé par une startup de quatre personnes. La base de contributeurs existe déjà.
Bref, si vous cherchez un client IA d'entreprise qui ne finit pas chez OpenAI, Thunderbolt est une piste sérieuse.
Source : The Register
Figurez-vous que les agents IA sont désormais les premiers consommateurs des APIs Cloudflare, bien devant les développeurs humains. C'est en tous cas ce que l'éditeur déclare publiquement pour justifier une refonte importante de son outil en ligne de commande, Wrangler, et la sortie d'un nouveau CLI unifié baptisé sobrement "cf".
Le raisonnement est froid mais a du sens. Si les agents IA pilotent la plateforme, autant qu'ils aient un CLI qui ne les plante pas.
Concrètement, Cloudflare a refait toute sa pipeline de génération de code autour d'un schéma TypeScript unique. Ce schéma décrit le périmètre complet des APIs, des commandes CLI, des arguments et du contexte nécessaire pour générer n'importe quelle interface.
Quand un nouveau produit Cloudflare arrive, il tombe automatiquement dans le CLI. Avec près de 3 000 opérations d'API au catalogue, c'était effectivement le bon moment pour industrialiser la chose.
Le point qui dit beaucoup sur l'état de l'industrie, c'est celui-ci. Cloudflare force désormais des commandes CLI par défaut au niveau du schéma, pour éviter que les agents se plantent sur des variantes moins standards qu'ils ne connaissent pas.
En clair, le design du CLI est partiellement contraint par ce que les LLM savent deviner. C'est nouveau, et pas anodin.
À côté du nouveau CLI cf, Cloudflare lance Local Explorer en bêta ouverte, intégré à Wrangler et au plugin Cloudflare pour Vite. L'outil permet d'inspecter les Workers en local, de voir quels bindings leur sont attachés et quelles données y sont stockées.
Pratique pour déboguer sans passer par le dashboard web, surtout quand on jongle entre plusieurs environnements.
Pour les développeurs humains, la promesse est double. D'abord, un CLI plus cohérent, moins de surprises d'un produit à l'autre. Ensuite, un outil de debug local qui évite l'allée-retour constant avec l'interface web Cloudflare. Pour les agents IA, la promesse est plus prosaïque, appeler Cloudflare sans générer d'erreurs de syntaxe toutes les trois commandes.
C'est en fait assez symptomatique d'une tendance qu'on voit chez plusieurs plateformes cloud en ce moment, où l'ergonomie CLI est pensée pour les LLM autant que pour les humains. Pas sûr que tous les acteurs l'assument aussi frontalement, mais Cloudflare, fidèle à son style, le dit.
Bref vous l'avez compris, cf et Local Explorer valent le détour. Et si vous laissez un agent piloter l'infra, au moins il aura des rails pour que ça ne parte pas dans tous les sens.
Source : The Register
Plus de 230 millions de dollars. C'est ce qui a été misé sur le climat et la météo via Kalshi depuis juillet 2021, dont plus de la moitié rien que sur les neuf premiers mois de 2025.
La plateforme américaine de marchés de prédiction laisse ses utilisateurs acheter des contrats "oui" ou "non" sur la température de demain à Chicago, le passage d'un ouragan sur la Floride, ou encore la probabilité que la planète franchisse les 2°C avant 2050.
Le fonctionnement est simple. Vous pariez 15 cents sur "il fera 78°F à Los Angeles demain", s'il fait bien 78°F vous récupérez un dollar. Profit : 85 cents. C'est rapide. Derrière, Kalshi s'appuie sur les données officielles du NOAA et du National Weather Service, les mêmes qui alimentent depuis toujours les bulletins télé.
Sauf que cette fois, ces données publiques financées par les impôts américains servent à enrichir des traders privés. Du coup, pas mal de scientifiques trouvent ça un peu gênant.
Les défenseurs du système poussent une idée séduisante : agréger les paris de milliers de gens pourrait produire des prévisions météo plus précises que les modèles classiques. En théorie, c'est la "sagesse des foules" appliquée aux nuages.
En pratique, personne n'a vraiment prouvé que les marchés battent les modèles numériques du NOAA sur les températures à 7 jours. Les parieurs les plus sérieux lisent justement... les modèles du NOAA.
Côté éthique, ça coince. Kalshi refuse explicitement les paris sur les incendies de forêt, parce que l'entreprise elle-même reconnaît que ça créerait une incitation financière à mettre le feu. Logique. Mais rien n'empêche de parier sur le trajet d'un ouragan ou sur le niveau de pluie pendant une inondation, au moment même où des gens perdent leur maison.
Une étude parue dans Nature Climate Change en 2023 montre que parier sur le climat augmente un peu la prise de conscience chez les joueurs, mais l'effet reste modeste, entre quelques pourcents. Pas exactement de quoi compenser l'inconfort moral.
Le modèle avance quand même à toute vitesse. Kalshi pèse désormais près de 90% du marché américain de la prédiction et a dépassé les 12 milliards de dollars de volume mensuel en mars 2026.
En face, les régulateurs commencent à serrer : l'Arizona a déposé des poursuites pénales contre la plateforme en mars 2026 pour exploitation d'un jeu d'argent non licencié et paris électoraux. Plusieurs États pourraient suivre. Mais bon, tant que les investisseurs continuent d'affluer, l'entreprise n'a aucune raison de lever le pied.
Bref, transformer une tempête en ticket de loto sur fond de données publiques, ça pose quand même quelques questions.
Source : Bloomberg
