Deux fois plus rapide que LZ4 en décompression ?? Ah bon c'est possible ? Évidemment, quand Bertrand Lebonnois a publié zxc sur GitHub , et m'a envoyé un email pour me prévenir, j'ai été jeter un œil, surtout aux benchmarks.

Eh bien après analyse, c'est bien réel !

La philosophie de zxc est assez tranchée vous allez voir. Il s'agit d'une lib WORM (Write-Once, Read-Many) qui permet de compresser une fois lentement, à la compilation ou en CI, et ensuite de décompresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs à la vitesse de l'éclair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la décompression soit méga rapide et simple pour le processeur. C'est aussi simple que ça.

Le revers de la médaille, c'est que si vous voulez de la compression à la volée ou du streaming temps réel, ce n'est clairement pas adapté. Par contre, si vous produisez des assets une fois et qu'ensuite, vous les servez des milliers de fois, alors vous êtes exactement dans la cible.

En pratique, sur macOS M2 avec un corpus de test standard, zxc dépasse les ~12 000 Mo/s en décompression, contre ~5 600 Mo/s pour LZ4 --fast dans le même test. L'écart reste également hyper solide ailleurs : 1,8× sur ARM serveur (Google Axion) et 2× sur x86_64 (AMD).

Et l'API proposée par zxc ne s'arrête pas à un compresseur basique. En effet, un mode "seekable" permet d'accéder à n'importe quelle position d'une archive sans scanner le fichier depuis le début. Par exemple, vous packagez vos assets de jeux vidéo dans une seule archive zxc, et quand le joueur charge une texture précise, vous lisez directement le bon bloc, et pas tout le fichier.

Côté installation, c'est simple : brew install zxc sur macOS, apt install zxc sous Debian ou Ubuntu, pip install zxc-compress, npm install zxc, cargo add zxc-compress ou vcpkg install zxc sous Windows.

Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communauté a aussi ajouté Nim et Free Pascal de son côté. Et comme c'est codé en C, y'a aucune dépendance lourde.

Sache que pour assoir la crédibilité du projet, zxc a été intégré dans lzbench et TurboBench, les deux outils de référence permettant de comparer les algos de compression. Et le paquet est déjà dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont validé le truc !

Bref, si vous gérez de la compression d'assets ou de firmwares dans votre pipeline, ça vaut le coup d'y jeter un oeil.

Merci à Bertrand pour l'info et chapeau pour le boulot !

Si vous utilisez Claude Code au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque sans prévenir quand 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 ^^

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

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

slim start myapp --port 3000 --route /api=8080 --route /ws=9000

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

Pour la première fois, l'équipe du Parc archéologique de Pompéi a utilisé une chaîne d'intelligence artificielle pour reconstruire numériquement le visage d'une victime de l'éruption du Vésuve en 79 après Jésus-Christ.

Le portrait, présenté hier, montre un homme âgé qui tentait de fuir la ville vers la côte au moment où la pluie de pierres ponces s'est abattue sur lui. La méthode pourrait être étendue à des centaines d'autres victimes du site dans les prochains mois.

Screenshot

La victime a été retrouvée près de la nécropole de la Porta Stabia, juste à l'extérieur des murs de la ville antique. Son squelette gardait dans ses mains un mortier en terre cuite, que les chercheurs interprètent comme une tentative improvisée de se protéger la tête des projectiles volcaniques. Un détail qui parle de la panique du moment, quand les habitants saisissaient ce qu'ils trouvaient pour se couvrir.

La reconstruction a été menée en collaboration avec l'Université de Padoue. Les chercheurs ont combiné des relevés ostéologiques classiques (forme du crâne, points d'attache des muscles, état de la dentition) avec des outils d'IA spécialisés dans l'estimation de tissus mous à partir de squelettes.

Le résultat est un visage qui ressemble plus à un portrait probabiliste qu'à une photo. Les paramètres comme la couleur des yeux ou la coiffure restent des hypothèses éducatives, basées sur des moyennes de la population romaine de l'époque.

L'apport de l'IA n'est pas dans le portrait final, qui aurait pu être réalisé à la main par un médecin légiste expérimenté. Il est dans l'industrialisation de la méthode. Le pipeline développé peut être appliqué à d'autres squelettes du site, et il y en a beaucoup.

Pompéi a livré plus d'un millier de victimes identifiées, dont une grande partie n'avait jamais été visualisée. Le portrait n'est pas une photo, ce n'est pas non plus la vérité historique de cet homme : c'est une représentation cohérente avec ses os et avec le contexte démographique connu.

Les chercheurs insistent sur ce point pour éviter que le portrait soit pris au pied de la lettre. À noter aussi qu'aucune analyse ADN n'a encore été réalisée pour affiner l'origine ethnique précise de la victime.

Dans cette histoire, l'IA donne aux archéologues un nouveau pinceau pour redonner un visage aux morts de Pompéi.

Source : AP

La conférence des développeurs d'Apple se tiendra début juin. En marge de l'événement, plusieurs rencontres sont prévues dans la région de Cupertino, accessibles sans invitation.

L’article WWDC 2026 : les événements gratuits auxquels vous pouvez assister sans billet est apparu en premier sur Tom’s Hardware.

Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'éteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.

La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.

Concrètement ça donne ça :

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé

Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !

La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...

Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.

Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !

Sur le terrain anti-bot, ça se compare bien à Botasaurus dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.

Détail sympa pour les bidouilleurs : y'a également un serveur MCP intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.

Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.

Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.

Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .

Et merci à Letsar pour le lien !

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.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/parallel-rsync/parallel-rsync-1.mp4">lien vers la vidéo</a>.

Quarkdown vient de passer en v2.0.0, et c'est une mise à jour qui en jette ! Pour ceux qui auraient raté le projet de Giorgio Garofalo, c'est ce compilateur Markdown capable de cracher livres, slides, PDF académiques et wikis à partir du même projet.

J'en avais parlé il y a presque un an dans cet article , et le truc a bien grossi depuis.

Du Kotlin sous le capot, et surtout une v2 qui ajoute le truc qu'on attendait pas : un vrai système de permissions ! En gros, vous pouvez maintenant brider ce qu'un document Quarkdown a le droit de faire pendant la compilation. Ça se contrôle avec des flags comme --deny network (pour bloquer l'accès réseau) ou --deny global-read (pour empêcher la lecture de fichiers en dehors du projet) à la compilation. C'est pratique quand vous compilez un document que quelqu'un vous a envoyé sans trop savoir ce qu'il y a dedans.

L'autre nouveauté qui change la vie, c'est l'output HTML qui peut maintenant tourner sans réseau. Plus besoin de pinger un CDN au moment du rendu puisque toutes les polices et les thèmes sont copiés dans le dossier de sortie. Par contre, maintenant les fichiers pèsent plus lourd mais c'est un bon compromis quand même puisque vous pouvez balancer le HTML sur une clé USB et ça tourne en quasi-autonomie (sauf si vous chargez des Google Fonts custom ou des polices cheloues, qui restent distantes).

Côté SEO, la fonction .htmloptions peut générer un sitemap.xml et des canonical links si vous lui passez un baseurl, ce qui le rend utilisable pour publier de vrais sites statiques.

Pour le reste, y'a plein de petits trucs sympas : les cross-références (figures, tables, équations) sont enfin cliquables, la fonction .keybinding affiche les raccourcis clavier avec ⌘ sur Mac et Ctrl ailleurs, et le rendu se parallélise sur les éléments frères. Ah, et un détail qui va surprendre ceux qui mettent à jour : le dossier de sortie passe de ./output à ./quarkdown-output, donc faudra adapter vos scripts CI !

Côté installation, ils ont aussi simplifié tout ça : Homebrew sur Mac (brew install quarkdown-labs/quarkdown/quarkdown), Scoop sur Windows, ou les habituels scripts shell. Attention quand même, faut se taper la syntaxe Quarkdown plutôt que du Markdown pur, ce qui est un nouveau dialecte à apprendre, mais c'est pas non plus la mer à boire, donc pas de stress.

Bref, si vous cherchez une alternative à LaTeX ou un complément à Pandoc pour votre workflow doc, c'est peut-être le bon moment de tester !

Source

Vous savez cette télécommande Apple TV de première génération qui traîne dans un tiroir et dont vous ne faites rien ?

Bah y'a enfin un truc à faire avec ! Jinsoo An, alias machinarii sur GitHub, vient de sortir Hypervibe , un outil macOS qui transforme la télécommande de l'Apple TV en walkie-talkie comme disent les québecois, pour Claude Code.

Push-to-talk, swipes pour les commandes slash, boutons remappables, le tout pour coder à une seule main pendant que vous mangez vos chips au vinaigre de hipsters de l'autre.

Le principe est simple : vous tenez la télécommande comme un talkie, vous appuyez sur le bouton Siri pour parler à Claude Code (dictation Claude doit être activée préalablement), puis Play/Pause envoie le prompt, Menu fait Échap, et TV envoie un Ctrl+C pour annuler.

Et les swipes du touchpad sont mappés sur les commandes slash de Claude : swipe up pour /usage, swipe down pour /compact, swipe left pour /model, swipe right pour basculer en mode plan/auto-accept. Et comme vous pouvez vous en douter, ous les mappings sont modifiables à la volée via la barre de menu, et sauvegardés dans UserDefaults.

Hypervibe est en V0.1 expérimental, et y'a pas de binaire pré-compilé, donc vous devrez le compiler depuis les sources.

Notez quand même (parce qu'il faut rendre à César ce qui appartient à César) que Hypervibe est un fork de Remotastic de Lauschue, qui a posé les fondations du HID Siri Remote et du menu bar. Hypervibe ajoute en plus le push-to-talk, les swipes mappables sur les commandes Claude Code, et pas mal de petites subtilités pour que ça fonctionne au poil !. Côté licence c'est MIT, donc vous pouvez forker à votre tour si vous voulez ajouter votre propre layout.

Et voilà comme une télécommande à 3 balles en vente sur LeBonCoin devient un périphérique d'entrée pour Claude Code avec voix et gestures intégrés, pendant que des startups de dropshipping nous vendent des claviers "AI-native" à 300 €.

La bidouille plus fort que la douille !!

Ce matin, j'ai demandé à une IA de me concevoir un baladeur qui lit du FLAC. L'outil m'a alors posé quelques questions puis il m'a sorti le design électronique complet en quelques secondes. Blueprint.am , c'est le service de 3E8 Robotics qui transforme une simple phrase en bidule hardware DIY : schéma de cablage, liste de pièces avec liens Amazon, vues 3D, instructions de montage étape par étape...etc.

Vous tapez votre idée bien délirante dans un champ texte, l'outil balance un plan pour décrire l'archi générale ainsi qu'un "wiring diagram" (je pense qu'on peut traduire ça par plan de câblage) avec les connexions GPIO/SPI/I2S qui vont bien + la liste des pièces / composants et une suite d'instructions de fabrication regroupées par étapes.

Pour mon baladeur FLAC, ça m'a sorti un ESP32-WROOM-32E couplé à un DAC PCM5102A, un ampli casque TPA6120A2, un écran 2.4 pouces SPI TFT, une batterie Li-Po 1000mAh avec chargeur TP4056 et boost converter XL6009. 30 pièces au total soit 13 composants électroniques et 17 pièces à imprimer en 3D pour le boîtier pour un coup total d'environ 282 $.

Le truc qui me plait bien, c'est pas que ça génère de la conception hardware (Ce bon vieux Claude Code fait déjà ça depuis un moment), mais c'est surtout la cohérence des choix. L'outil semble avoir piqué les bonnes pratiques de la communauté maker et me sort pas juste des composants au pif.

Avant ce genre d'outil, fallait sortir KiCad pour le schéma, Octopart pour vérifier les composants disponibles, Fusion 360 ou OnShape pour modéliser le boîtier, et un gros tableur des familles pour calculer le coût total de votre délire.

Là c'est un seul prompt et 30 secondes à patienter. La liste des composants a même des liens Amazon donc vous cliquez et vous commandez.

Comme vous pouvez le voir sur mes captures, la 3D générée, c'est un wireframe d'enclosure et pas un design final, donc faudra repasser dans un soft de modélisation pour arrondir les angles et caler les vis. Y'a pas non plus de firmware auto-généré, donc une fois le hardware monté, faudra flasher l'ESP32 vous-même via Arduino IDE ou PlatformIO avec votre propre code. Et faudra savoir souder, disposer d'une imprimante 3D, d'un multimètre...etc. Bref, l'outil réfléchit, mais c'est quand même encore à vous de bosser.

Si ça vous branche, vous avez un quota gratuit pour tester sans compte mais après faudra vous en créer un pour débloquer plus de générations et éventuellement acheter des crédits. L'outil a aussi un onglet documentation auto-générée, donc même si vous foirez le montage, vous pouvez relire la procédure pas-à-pas pour comprendre où ça n'a pas fonctionné.

Dans son test, le reviewer FabScene (alias Ryuta Kobayashi, qui bosse sur des robots dans l'automobile japonaise, donc pas vraiment un newbie) a conçu un accessoire LED avec boutons et a sorti un prototype fonctionnel en 2 heures de bout en bout (conception, impression, assemblage). Comptez un peu plus si vous débutez à la soudure, mais ça reste utilisable pour de vrai.

Ça remplacera pas un ingénieur senior, mais pour du proto de week-end, franchement, c'est une vraie bouffée d'air pour les makers.

Si vous avez un site, vous savez déjà qu'il faut l'optimiser et le rendre lisible pour Google. Mais en ce moment, Cloudflare pousse vraiment une toute autre couche par-dessus : le rendre lisible pour les agents IA. Et pour vérifier si vous êtes dans les clous, l'équipe a sorti isitagentready.com , un scanner gratuit qui vérifie ça en quelques secondes.

Vous tapez tout simplement votre URL, et le scanner check une dizaine de standards émergents, puis pour chaque truc qui manque, il vous crache carrément un prompt prêt à coller dans Claude Code, Cursor ou Windsurf pour qu'il vous aide à l'implémenter. Vous pouvez aussi customiser le scan en cochant uniquement ce qui vous intéresse, selon que votre site est plutôt un blog de contenu ou une API.

L'interface annoncée par Cloudflare pour son nouveau scanner agent-ready

Les checks sont organisés en 5 catégories : la découvrabilité (robots.txt, sitemap, Link headers HTTP), l'accessibilité du contenu (markdown negotiation, llms.txt), le contrôle et la signalisation des bots (Content Signals, Web Bot Auth, règles IA dans robots.txt), la découverte de protocoles (MCP Server Card, Agent Skills, API Catalog, OAuth) et le commerce agentique (x402, MPP, UCP, ACP). Chaque catégorie pèse alors dans le score final, sauf le commerce qui est juste checké mais pas scoré.

J'ai testé sur korben.info et le résultat est franchement mitigé. Côté positif : robots.txt présent avec Content Signals (search=yes, ai-train=no, donc je dis oui à l'indexation et non à l'entraînement IA), llms.txt opérationnel avec 111 lignes en français, markdown negotiation qui répond bien sur Accept: text/markdown, sitemap.xml en place, et GPTBot, Google-Extended et Meta bloqués explicitement.

Côté manquant : pas de MCP Server Card, pas d'Agent Skills, pas d'API Catalog, pas de Link headers.

Score estimé : très moyen, et c'est plutôt cohérent avec un site qui n'a pas besoin d'OAuth ni de serveur MCP.

Cloudflare balance surtout des chiffres bien concrets dans son article de lancement . Sur les 200 000 domaines les plus visités du web, 78% ont un robots.txt, 4% déclarent leurs préférences via Content Signals, 3.9% font de la markdown negotiation, et moins de 15 (oui, quinze) ont un MCP Server Card ou un API Catalog combinés. Autant dire qu'on est très tôt dans la partie. Côté boite à outils, dans le panel d'agents testé par Cloudflare, seuls Claude Code, OpenCode et Cursor envoient un Accept: text/markdown par défaut quand ils browsent le web. Les autres récupèrent du HTML par défaut, comme un navigateur classique.

Cloudflare a aussi mesuré l'impact sur sa propre doc en activant tous ces standards : 31% de tokens en moins consommés et 66% de réponses plus rapides. Du coup c'est pas négligeable, surtout quand vous payez les agents au token. Et bonus, isitagentready.com lui-même est agent-ready (forcément), avec son propre serveur MCP exposé à /.well-known/mcp.json et un outil scan_site disponible pour les agents qui veulent l'appeler en autonomie.

Mais attention au piège ! Si on traite tout pour viser le "tout vert" comme objectif, beaucoup de sites finiront par prétendre être des fournisseurs OAuth ou des serveurs MCP juste pour cocher la case. Donc mieux vaut dire honnêtement "non, ça je ne fais pas" que de faire semblant. Pour un blog perso, vous n'avez probablement pas besoin de l'API Catalog ni du serveur MCP. Pour un site e-commerce par contre, x402 et l'Agentic Commerce Protocol vont commencer à compter le jour où les agents paieront vraiment pour leurs utilisateurs.

Petit détail historique amusant, le robots.txt date de 1994 (j'avais 12 ans, j'étais à fond sur le PC mais pas encore sur le net) et le code HTTP 402 Payment Required existe depuis 1997 mais n'a jamais été massivement utilisé. Jusqu'au jour où Cloudflare et Coinbase se sont associés pour le ressusciter avec x402, en l'imaginant comme la couche de paiement entre humains, agents et services. On verra bien si leur mayonnaise va prendre...

Aujourd'hui l'adoption de tout cela est embryonnaire, mais rappelez-vous qu'en 2004 peu de monde aurait parié sur l'industrie SEO qu'on connaît aujourd'hui. Donc ça vaut le coup d'y jeter un œil maintenant.

Merci à Camille Roux pour le lien !

Source

Distribuer des paquets binaires en WebAssembly, c'est galère. Vous téléchargez le .tar.gz, vous le gunzippez, vous l'extrayez en mémoire... et ça rame sévèrement !! Mais youpi, Jeroen Ooms (qui contribue à webR et bosse chez ROpenSci) vient de publier tar-vfs-index , un petit npm package qui casse cette malédiction des enfers en sautant carrément l'étape extraction.

L'astuce est toute bête ! Au lieu d'extraire l'archive, on génère un fichier d'index qui liste la taille et l'offset de chaque fichier dans le tar. Du coup le navigateur n'a plus qu'à monter le blob du tar comme un système de fichiers virtuel, et chaque lecture devient alors un simple slice du blob à la bonne position. Pas d'extraction donc, mais juste du slicing à la demande !

Sous le capot, ça repose sur 3 propriétés alignées. 1/ le format tar est un layout plat : une suite de headers de 512 octets suivis des données du fichier, le tout contigu et adressable à l'octet près. 2/ Emscripten propose un backend filesystem appelé WORKERFS, prévu pour servir les lectures d'un Blob sans le copier dans le heap WASM. Et 3/ les navigateurs ont une API native, DecompressionStream , qui gunzippe efficacement pendant le téléchargement.

Concrètement, vous installez le truc avec npm install tar-vfs-index (y'a aucune dépendance externe) puis vous lancez npx tar-vfs-index archive.tar.gz. Et hop, le package vous sort un JSON dans ce genre :

{
 "files": [
 { "filename": "mypackage/DESCRIPTION", "start": 512, "end": 548 },
 { "filename": "mypackage/R/code.R", "start": 1536, "end": 1563 }
 ],
 "remote_package_size": 3072
}

const [metaRes, dataRes] = await Promise.all([
 fetch('archive.tar.gz.json'),
 fetch('archive.tar.gz'),
]);
const metadata = await metaRes.json();
const blob = await new Response(
 dataRes.body.pipeThrough(new DecompressionStream('gzip'))
).blob();
FS.mkdir('/pkg');
FS.mount(WORKERFS, { packages: [{ metadata, blob }] }, '/pkg');

Vous bossez sur un Dockerfile et vous avez besoin de la dernière version de nginx. Vous ouvrez GitHub, vous cliquez sur Releases, vous copiez-collez. Et 3 minutes plus tard, rebelote pour curl. Puis pour PHP. Sans parler du fait que dans votre script d'auto-update, vous avez hardcodé une "v3.2.1" qui dort là depuis 2023 parce que personne n'a pris le temps de mettre à jour le fichier.

Lastversion , c'est le petit CLI Python signé Danila Vershinin qui remplace cette corvée par une seule ligne. Vous tapez lastversion apache/incubator-pagespeed-ngx et vous récupérez le numéro de la dernière version.

Le truc marche sur GitHub, GitLab, BitBucket, PyPI, Wikipédia, les flux RSS, les plugins WordPress, Helm charts, Gitea, SourceForge... et même sur des sites qui publient leurs versions comme ils veulent, genre nginx.org.

La beauté du bazar, c'est qu'il comprend les humains, parce que, c'est vrai, les mainteneurs font un peu n'importe quoi avec leurs tags. Ils étiquettent release-1.2.3 au lieu de 1.2.3, ils marquent des release candidates en stable sans le faire exprès, ils changent de format entre v20150121 et v2.0.1 sans prévenir. lastversion détecte toutes ces incohérences et vous renvoie la véritable dernière stable, celle que vous vouliez dès le départ. C'est pénible à gérer à la main quand vous avez vingt dépendances à suivre. Maintenant c'est réglé tout seul avec ce petit bidule.

Et les sources exotiques, c'est tout un délire. lastversion windows vous crache le build Windows en cours, lastversion ios pour iOS, lastversion rocky vous renverra 8.4 et lastversion https://en.wikipedia.org/wiki/Rocky_Linux aussi, parce que le bidule va carrément parser la page Wikipédia pour vous.

Alors certains d'entre vous me diront que ce n'est pas utile au quotidien. Peut-être jusqu'au jour où vous devez scripter une vérif de version d'OS sans dépendre d'un outil système. Par contre, si vous enchaînez cinquante requêtes par heure sur un token GitHub anonyme, faudra pas s'étonner de manger un rate limit dans la tronche.

Côté one-liners qui tuent, y'a déjà de quoi faire.

wget $(lastversion --assets mautic/mautic) télécharge direct la dernière archive.

lastversion --pre Aircoookie/WLED --format assets --filter ESP32.bin -d ESP32.bin récupère le dernier firmware ESP32 WLED.

Pour Nginx, lastversion https://nginx.org --major stable renvoie 1.16.1 pendant que --major mainline renvoie 1.17.9.

Vous voyez l'idée, c'est du pipe-friendly pur jus.

Et le mode install, c'est un autre délire. Vous tapez lastversion install mailspring et hop, il récupère l'AppImage ou le RPM du dépôt, il l'installe, et c'est fini. Attention quand même, sur les dépôts un peu bordéliques il va parfois se vautrer sur le packaging et juste vous balancer le tarball brut. Bon, c'est pas la mort, vous dézippez à la main et vous passez à la suite...

Combiné avec cron, @daily /usr/bin/lastversion install mailspring -y et votre bureau sera toujours à jour sans passer par un store. Pour tous les outils qui ne sont ni dans apt, ni dans un snap, ni dans un flatpak, c'est l'alternative la plus propre à avoir sous la main.

L'install se fait via pip install lastversion sur à peu près tout, ou yum install lastversion après avoir ajouté le repo GetPageSpeed si vous êtes sur CentOS, RHEL, Rocky, Alma, Fedora ou Amazon Linux.

Le projet est publié sous licence BSD-2, codé en Python, et il y a aussi une API utilisable directement (from lastversion import latest) si vous préférez appeler ça dans vos scripts plutôt que de piper dans un subprocess.

Bref, un chouette outil à ranger entre vos redirections bash et votre gestionnaire SSH , catégorie petits trucs qui font gagner 10 minutes par semaine.

Un Linux qui tourne dans un Windows 95, vous ne rêvez pas puisqu'un développeur solo du nom de Hailey Somerville, a sorti WSL9x, un "Windows 9x Subsystem for Linux" qui pousse encore plus loin la logique de Microsoft avec WSL.

Le truc marche avec une simple commande wsl tapée dans le terminal MS-DOS, ce qui ouvre un pseudo-terminal Linux au beau milieu de votre Windows 9x. Pour les couleurs ANSI, il faudra charger un driver comme nnansi.com (c'est pas un nom de domain hein...) avant mais une fois en place, vous avez un shell Linux qui tourne en coopératif à côté du système Microsoft. Pas besoin de redémarrer ni de vous lancer dans la mise en place d'un dual boot.

Sous le capot, c'est une bidouille assez rigolote. En fait, Hailey a patché le noyau Linux 6.19 dans sa variante user-mode, cross-compilé en i386 avec musl, puis intégré via Open Watcom v2 pour la partie Windows. Le code se compose à 63% de C et à 35% d'assembleur, ce qui donne une idée du niveau de bas-niveau qu'il faut pour faire tourner un kernel Linux en parallèle d'un Windows 95 ou 98.

Ensuite, tout ce qui est pagination, protection mémoire et ordonnancement préemptif tirent parti des capacités des deux OS en même temps. Linux gère ses processus invités, Windows arbitre en bas niveau, et les deux cohabitent sans se marcher sur les pieds. Ça permet comme ça de lancer vos outils Linux préférés sans jamais quitter votre session OuinOuin.

Pour reproduire ça chez vous, il vous faudra un cross-compilateur i386-linux-musl (musl-cross-make fait très bien le job), Open Watcom v2, et une image disque Windows 9x pré-installée. Vous configurez les variables WATCOM et LINUX via .envrc.example, puis vous buildez le kernel avec make defconfig ARCH=um SUBARCH=i386 KBUILD_DEFCONFIG=win9x suivi d'un make vmlinux.

Un dernier petit make à la racine du projet pour génèrer le hdd.img final, et en suite c'est tout prêt à booter dans un 86Box , PCem ou carrément une vraie bécane sous Windows 95.

Maintenant, ce projet est qualifié de "very messy" par son auteur car c'est encore un travail en cours, et pas du tout un WSL officiel prêt pour un usage stable. Le dépôt est sous GPL-3 donc forkable, mais la doc se résume au README, donc c'est encore un peu léger.

Par contre, si vous aimez les hacks rétro de l'extrême, WSL9x mérite un petit coup d'œil. Ça me rappelle ce sous-système Linux pour MS-DOS qu'un autre dev avait sorti il y a quelques années, qui était le même délire mais pour DOS pur. À côté, le WSL2 officiel de Microsoft fait hyper sérieux.

Donc si vous avez un vieux Pentium qui traîne dans un placard, c'est l'occasion parfaite de le dépoussiérer pour faire la chose la plus absurde du mois.

Ah, le presse-papiers et Claude Code... Quelle misère !!! Si vous utilisez l'assistant d'Anthropic dans le terminal, vous connaissez la douleur. Vous copiez 3 lignes pour les coller ailleurs et vous vous retrouvez avec des │ partout, des marges de deux espaces, et des sauts de ligne au milieu des phrases. Un vrai bordel !

Un développeur norvégien, Anders Myrmel, en avait déjà ras-le-bol lui aussi. Du coup il a pondu claude-copy , un script Hammerspoon qui intercepte votre Cmd+C quand vous êtes dans un terminal, laisse la copie native s'exécuter, puis nettoie le presse-papiers après coup.

Côté prérequis, il vous faut donc macOS avec Homebrew installé. L'installation ensuite c'est 3 commandes :

git clone https://github.com/andersmyrmel/claude-copy
cd claude-copy
./install.sh

Le script installe alors Hammerspoon via Homebrew si vous ne l'avez pas déjà et ajoute une ligne dans ~/.hammerspoon/init.lua. Au premier lancement, macOS demande ensuite l'accès Accessibility à Hammerspoon, donc donnez-le puis rechargez la config. C'est testé sur Ghostty, mais ça devrait également fonctionner avec iTerm2, Alacritty, kitty, WezTerm, Warp et une poignée d'autres terminaux.

Le truc cool, c'est comment ça décide quoi nettoyer. Le code Lua classe chaque copie en 3 niveaux de confiance :

• Haute confiance, avec une couverture de marge à 2 espaces qui dépasse 0,65 ou des │ partout ? Hop, strip des marges, box-drawing virées, lignes molles rejointes en paragraphes !
• Confiance moyenne, on nettoie sans rejoindre.
• Basse, on touche à rien. Les blocs de code indentés (+4 espaces) et les listes markdown sont préservés.

Alors pourquoi Anthropic a livré un TUI qui pourrit votre clipboard à la moindre copie structurée ? Hé bien on n'en sait rien mais c'est un vrai souci. Y'a d'ailleurs plusieurs issues ouvertes sur le sujets qui se référencent les unes les autres comme doublons (genre la #4686 et la #5097 ) donc qui s'annulent... Tu parles d'un bordel...

Après claude-copy n'est pas tout seul dans son coin. Y'a aussi Clean-Clode (dont claude-copy s'inspire d'ailleurs) qui fait pareil en version web, et un autre claude-copy signé clementrog pour Kitty et iTerm2.

C'est évidemment macOS only, parce que Hammerspoon est macOS only. Si vous êtes sous Linux ou Windows, ou que vous préférez éviter d'installer Hammerspoon, Clean-Clode fait le même boulot dans votre navigateur et rien ne quitte votre bécane.

Bref, si vous passez vos journées à copier-coller du Claude Code, ça vaut peut-être le coup. Donc en attendant qu'Anthropic se sorte les doigts et décide de nettoyer leur sortie à la source, je trouve ce genre de petit hack bien pratique !