Autoblog de korben.info

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 !!

Cas pratique du week-end : ma pote Alex m'a passé son PC familial tournant sous Windows 8, car son fils a changé le mot de passe du Windows et n'a pas la moindre idée de ce qu'il a tapé. Pour faire sauter ce mot de passe sans tout réinstaller, j'utilise depuis des années la bonne vieille astuce Sticky Keys, qui consiste à booter sur une clé USB Windows pour accéder au Terminal de récupération via MAJ+F10. Sauf que pour préparer cette clé, j'avais juste mon MacBook sous la main.

Et là, surprise !

Sur Windows, Rufus fait ça en deux clics depuis dix ans. Sur macOS, ça reste un sport de combat. Boot Camp Assistant est toujours dans le dossier Utilitaires mais inopérant sur les Mac Apple Silicon, le Media Creation Tool de Microsoft ne tourne pas sur Mac, et les tutos Terminal vous font formater en exFAT sans préciser que votre install.wim va dépasser les 4 Go de FAT32.

Mais heureusement, WinDiskWriter , signé TechUnRestricted, vient combler ce trou.

Vous téléchargez d'abord la build adaptée à votre Mac depuis les releases GitHub (Intel et Apple Silicon dispo) et ensuite vous glissez votre ISO Windows 10 ou 11, vous choisissez votre clé USB dans la liste, et vous cliquez Start. Voilà. Lui s'occupe du reste : partitionnement, formatage, copie des fichiers, et surtout le split automatique de l'install.wim en plusieurs install.swm dès que la taille dépasse les 4 Go.

Ce point vaut une explication, parce que c'est là où la plupart des tutos Mac plantent en silence. En fait, depuis certaines ISO de Windows 10, le fichier install.wim qui contient l'image disque compressée pèse plus de 4 Go. Or FAT32 plafonne chaque fichier à 4 Go (très précisément 4 GiB moins 1 octet), et la majorité des firmwares UEFI bootent par défaut sur du FAT32, sauf à charger un pilote tiers genre UEFI:NTFS.

Donc soit vous formatez en exFAT et vous priez pour que le PC cible accepte le boot, ce qui est loin d'être garanti sur les machines un peu anciennes comme c'est mon cas ici. Soit vous splittez le .wim en plusieurs morceaux que le bootloader Windows sait recombiner à l'install. WinDiskWriter effectue la deuxième option par défaut, comme ça vous n'avez rien à configurer.

Et côté création de clé USB pure, il propose des trucs que Boot Camp Assistant ne faisait pas. Le patch Windows 11 intégré contourne également les vérifications TPM, la RAM minimale et le Secure Boot. Bref, c'est super pratique pour réinstaller Win 11 sur un PC qui ne coche pas les cases officielles.

Le BIOS Legacy est géré pour les vieilles machines, et la liste des Windows supportés remonte jusqu'à Vista, en x64 comme en x32. À noter quand même que le projet ne fournit pas de build macOS 32-bit, donc ce sera inutilisable sur des Mac Intel pré-2010. Mais bon, ça ne concerne plus grand monde.

Notez par contre que WinDiskWriter ne bypasse PAS l'obligation de compte Microsoft online introduite avec Windows 11 22H2. Donc si vous comptez vraiment réinstaller, vous devrez toujours sortir cette bonne vieille astuce OOBEBYPASSNRO en ligne de commande pour créer un compte local.

Du coup, une fois la clé prête, j'ai pu dérouler la procédure Sticky Keys et Alex a récupéré l'accès à son PC. Et tant qu'à faire, j'en ai profité pour rafraîchir cette vieille machine. D'abord upgrade Windows 8 vers Windows 8.1 avec la mise à jour normale du Store Microsoft. Puis Windows 8.1 vers Windows 10 grâce à la clé USB préparée avec WinDiskWriter, en lançant setup.exe depuis Windows 8.1 actif pour conserver la licence. Et enfin Windows 10 vers Windows 11 avec Flyoobe , dont je vous ai parlé en détail dans un autre article.

Bref, trois upgrades en chaîne, données préservées, et le PC d'Alex qui repart sur du Windows 11 récent et à jour (même sans TPM) !

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 a conçu un accessoire LED avec boutons et a sorti un prototype fonctionnel en 2 heures de bout en bout (conception, impression, assemblage), donc c'est 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.

Depuis quelques jours, plusieurs médias français ressortent cette merveilleuse histoire de la carte bancaire à empreinte digitale comme s'il s'agissait d'une révolution imminente ! Par exemple l'Indépendant titre carrément "le code à quatre chiffres c'est bientôt fini". Toudoum !!

Sauf que la techno, conçue par Thales et IDEMIA , est commercialisée en Europe depuis 2021 quand même. Et plus drôle encore, c'est que BNP Paribas a fermé la commercialisation de sa première version le 8 décembre 2025, soit bien avant que la presse en fasse un sujet d'actualité "frais".

La carte F.CODE d'IDEMIA, l'un des deux principaux fabricants de cartes biométriques en Europe avec Thales (crédit : IDEMIA).

Donc bon, on va remettre les pendules à l'heure ensemble, parce que le sujet mérite mieux qu'un communiqué de presse recopié à la chaîne par dix rédactions. Je vous propose donc de remettre un peu tout ça à plat parce que je lis quand même pas mal de conneries.

Tout d'abord, il faut savoir que le principe technique derrière ces CB est solide, faut le reconnaître. Vous posez le pouce sur un petit capteur de quelques millimètres intégré à la carte, le module Secure Element (l'équivalent du coffre-fort embarqué) compare l'empreinte au gabarit stocké dans la puce, et si ça matche, le paiement passe en moins d'une seconde !

Le mot-clé c'est d'ailleurs "match-on-card". Cela veut dire que la comparaison se fait localement, et donc que l'empreinte ne sort jamais de la carte, ni vers le commerçant, ni vers la banque, ni vers un serveur quelque part. C'est donc exactement le même délire que Touch ID ou Face ID chez Apple, et c'est ce qui distingue ce système d'une base biométrique centralisée façon ANT, dont on a vu cette année à quel point ça pouvait mal finir (looool).

Côté sécurité, y'a beaucoup de vrais points positifs. Le code PIN à quatre chiffres, c'est dix mille combinaisons. Avec un peu de skimming sur un terminal compromis et une caméra cachée au-dessus du clavier, vous pouvez tout récupérer encore plus facilement. Sans parler des PIN type 1234, 0000 ou date de naissance qui représentent une part énorme des codes en circulation selon les analyses de DataGenetics (1234 représente à lui seul environ 10,7% des PIN observés sur 3,4 millions de codes analysés).

La biométrie vient donc tuer ce vecteur d'attaque d'un coup. Ainsi, si quelqu'un vole votre carte, il ne peut rien en faire, en théorie, sans votre doigt. Faudra avoir un bon sécateur ^^. Et niveau conformité, ça rentre pile-poil dans le cadre PSD2 et l'authentification forte du client puisque la biométrie remplace le facteur "savoir" (le PIN) par un facteur "inhérence" (votre corps), ce qui valide les deux facteurs requis avec la possession de la carte. Une fois encore c'est comme avec l'iPhone et FaceID / TouchID quand on se connecte quelque part.

Sauf que voilà, c'est là que les médias arrêtent de creuser. Et y'a beaucoup de choses à creuser, croyez-moi ! Perso je trouve ça assez "gênant" (comme disent les zados... "Annnnh la génance !!") qu'on nous présente un sujet sécurité aussi important comme si on nous vendait des yaourts.

Parce que d'abord, le code PIN ne disparaît pas, sauf si vous avez la chance d'avoir une banque qui vous laisse le désactiver explicitement (et bonne chance pour trouver l'option dans les CGV). Hé oui, quasi toutes les implémentations que j'ai pu voir passer, gardent un bon gros fallback PIN pour les cas où le capteur foire (doigt mouillé, sale (sacré lulu), blessure, capteur défaillant) ou pour les retraits au DAB.

Or, vous le savez parce que vous avez Bac+18 en bon sens, la sécurité globale d'un système est celle de son maillon le plus faible. Donc si le code PIN reste en backup, vous n'avez pas supprimé le maillon faible mais vous l'avez juste rendu optionnel. Et donc un voleur qui sait ça, sera capable de forcer le fallback en simulant un échec biométrique et utiliser le code PIN pour peu qu'il le connaisse. Comme avant quoi...

Donc cette promesse "fin du code à 4 chiffres" est donc un bon gros raccourci marketing, et pas du tout une réalité technique.

Ensuite, autre souci, c'est que la biométrie n'est pas révocable. Donc si demain un labo ou un expert sécu arrive à extraire un gabarit d'empreinte d'un Secure Element compromis (ça s'est déjà vu sur des puces certifiées EAL5+ par attaques side-channel), vous ne pourrez pas changer votre doigt parce que j'sais pas si vous avez remarqué mais il est bien solidement attaché au sac de viande que vous appelez "Mon summer body" ^^.

Le risque est heureusement limité dans ce cas-ci parce que le gabarit reste sur la carte, mais structurellement, la donnée biométrique EST un mot de passe que vous ne pouvez jamais changer. C'est une contrepartie importante que personne ne mentionne dans les articles grand public.

Sur les attaques physiques par exemple, le Chaos Computer Club qu'on connaît tous, a démontré dès 2013 le bypass de Touch ID avec un moulage en latex fabriqué à partir d'une empreinte laissée sur un verre. Les capteurs intégrés dans une carte bancaire sont plus petits, moins denses en pixels, et n'ont pas la même puissance de calcul pour faire tourner des modèles anti-spoof avancés que ce qui est embarqué dans un iPhone.

Ils sont donc plausiblement PLUS contournables, donc j'imagine qu'un moulage en silicone ou en résine pourra facilement en venir à bout. À ma connaissance, y'a aucun chiffre public sérieux qui n'a été publié par les fabricants sur le taux de succès de ces attaques sur leurs cartes. Comme c'est pratique ;)

Le sujet de la mise sous pression par des affreux bandits, mérite aussi une mention. Parce qu'avec un code PIN, si on vous menace devant un DAB, vous pouvez théoriquement saisir un faux code (certaines cartes ont même une notion de " code sous contrainte " qui bloque la carte directement). Alors qu'avec un doigt, on vous chope la main et force et voilà...

La jurisprudence américaine est d'ailleurs intéressante là-dessus puisqu'un juge peut vous obliger à poser le doigt sur un TouchID, mais pas à donner votre code PIN par respect du 5e amendement. En France le débat est un peu différent mais analogue. C'est un petit détail légal mais personne ne l'aborde non plus pour tout ce qui est sécurité biométrique en général.

L'enrôlement à domicile via smartphone, vendu comme "sécurisé" mais dont le protocole détaillé reste opaque (crédit : IDEMIA).

Autre angle mort, l'enrôlement. En effet, aucun des articles que j'ai lus ne décrit exactement comment l'empreinte arrive dans la puce la première fois. Est-ce que ça se fait en agence, avec un lecteur dédié ? Via une app smartphone qui pousse le gabarit par NFC ?

On en sait rien, mais si c'est la seconde option, le pipeline app + carte est une surface d'attaque qui mérite un audit indépendant, et la promesse de "l'empreinte ne quitte jamais la carte" devient à géométrie variable. Côté Thales et IDEMIA, le marketing parle d'enrôlement à domicile sécurisé, mais les détails du protocole sont peu documentés, tout du moins ce que j'ai pu trouver en libre accès.

Et pour finir sur le côté pratique, la biométrie est une option payante. Bah ouais, 24 balles par an chez BNP et Crédit Agricole, sur des cartes Visa Premier ou Mastercard Gold qui coûtent déjà entre 130 et 180€ annuels, pourquoi se faire chier ? Société Générale a annoncé vouloir descendre en gamme là-dessus, mais pour l'instant, la sécurité forte est réservée à ceux qui peuvent payer. Sécurité à deux vitesses, donc, comme d'hab et moi je trouve que c'est un peu paradoxal pour un truc présenté comme la nouvelle norme.

Bref, mon verdict sur tout ça c'est que le design technique est bon, le match-on-card protège VRAIMENT des fuites massives, et ça c'est un excellent progrès face au PIN à 4 chiffres pour tout ce qui est usage courant. Mais le narratif "fin du code secret" reste faux puisque le PIN perdure en fallback, et surtout, la biométrie pose des problèmes structurels bien connus (non-révocable, vulnérable aux moulages, coercition, enrôlement opaque).

Donc voilà, si demain votre banque vous propose le passage au biométrique, demandez-lui comment se passe l'enrôlement, si le fallback PIN est désactivable, et combien ça coûte. Et peut-être que là, ça pourra être intéressant.

Voici l'histoire de Neukgu, un loup coréen de deux ans qui s'est fait la malle d'un zoo de Daejeon le 8 avril dernier, et qui a tenu en haleine toute la Corée du Sud pendant neuf jours.

Sauf que dans la foulée de l'évasion, un homme de 40 ans génère une fausse photo IA du loup en train de traverser un carrefour, la diffuse en ligne, et l'image finit par remonter jusqu'aux autorités qui n'y voient que du feu.

La séquence qui suit est assez improbable. La municipalité de Daejeon envoie une alerte d'urgence par SMS à la population, signalant un loup au niveau du carrefour en question. Les autorités présentent même l'image en conférence de presse officielle sur l'évasion.

Toute l'opération de recherche se déplace vers cette zone, alors que le vrai loup est très probablement ailleurs. Bref, des centaines d'agents lancés sur une fausse trace générée pour rigoler.

Pendant ce temps, Neukgu continue sa balade. Il sera finalement attrapé près d'une voie rapide neuf jours après l'évasion, sain et sauf.

La police, elle, remonte jusqu'au générateur d'images en croisant la vidéosurveillance et les logs d'utilisation des plateformes IA. Le suspect, 40 ans, raconte avoir fait ça "pour s'amuser".

Moyen rigolo du coup. Il est désormais poursuivi pour entrave au travail des autorités par tromperie, un délit qui peut coûter jusqu'à 5 ans de prison ou environ 7000 euros d'amende.

Côté postérité, Neukgu est devenu une star locale. Issu d'un programme de réintroduction du loup coréen (officiellement éteint à l'état sauvage), il a eu droit à des viennoiseries à son effigie dans une boulangerie du coin, plus d'un million de vues sur la vidéo de son retour, et la ville réfléchit même à le nommer mascotte officielle. Le président Lee Jae Myung avait publiquement prié pour son retour. Sympathique épilogue.

L'affaire pose quand même une vraie question sur l'authentification des images dans des contextes où elles deviennent opérationnelles. Quand une image IA arrive jusqu'à un SMS d'alerte gouvernemental, le filtre humain a clairement raté un étage, même si ça va devenir de plus en plus compliqué avec le temps.

Bref, premier cas vraiment grand public où une fausse photo IA détourne une opération policière, avec poursuites à la clé. Et ça ne sera pas le dernier.

Source : BBC

Anthropic a partagé hier les résultats de Project Deal, une expérience interne menée en décembre 2025 où des agents Claude ont négocié, acheté et revendu des objets personnels pour le compte de 69 salariés volontaires de leur bureau de San Francisco. Le but : voir ce que ça donne quand des gens laissent leur IA faire les courses entre elles.

Pendant deux jours, chacun des 69 participants a confié un agent Claude à son téléphone, avec 100 dollars de budget virtuel et une liste d'objets à vendre ou à acheter. Les agents ont publié les annonces, échangé des messages, négocié les prix et conclu des accords.

186 transactions ont été closes sur plus de 500 objets listés, pour un volume total d'environ 4 000 dollars. Le prix médian d'un objet était de 12 dollars, le prix moyen autour de 20.

L'expérience était en fait un protocole de recherche déguisé. Anthropic a fait tourner quatre marchés en parallèle : un seul a donné lieu à de vrais échanges physiques, les trois autres servaient à l'analyse statistique.

Dans deux d'entre eux, tous les agents tournaient sur Claude Opus 4.5. Dans les deux autres, les utilisateurs avaient une chance sur deux de se retrouver avec un Claude Haiku 4.5, beaucoup moins capable, à leur insu.

Le résultat est assez clair. Les agents Opus ont vendu en moyenne 3,64 dollars de plus par objet que les agents Haiku, et concluaient deux deals supplémentaires sur la durée. Sur un même vélo cassé, Opus l'a revendu à 65 dollars, Haiku à 38 sur un profil acheteur équivalent. Mais la perception des participants ne reflétait pas ces écarts : sur l'équité ressentie, les utilisateurs des deux modèles ont noté l'expérience à 4,05 et 4,06 sur 7. Personne ne s'est senti lésé.

Quelques moments rigolos ressortent du rapport. Un participant a récupéré un snowboard que son propre agent lui avait déjà acheté plus tôt dans l'expérience, sans s'en rendre compte. Un autre s'est vu offrir par son agent ce que celui-ci a appelé "19 sphères parfaites de possibilité", soit en pratique un sachet de balles de ping-pong. Un troisième s'est retrouvé organisateur d'une vraie balade de chiens entre deux participants, négociée et programmée par leurs agents respectifs.

La conclusion d'Anthropic est plus politique que technique. Si demain tout le monde envoie son agent négocier à sa place, l'inégalité d'accès à un bon modèle se traduit directement par des écarts financiers, et personne ne s'en rend compte sur le moment.

46% des testeurs ont déclaré qu'ils paieraient pour ce genre de service. Du coup, mieux vaut commencer à regarder ça de près avant que ça déboule pour de bon partout dans notre quotidien.

Source : Anthropic ,

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

John Decebal vient de sortir le RSVP Nano , une mini-liseuse open-source qui tient sur un ESP32-S3 et qui affiche votre bibliothèque... un mot à la fois. 92 mm sur 34, et sous licence MIT, je me suis dis que j'allais y jeter un oeil.

En fait, le concept tient en 4 mots : Rapid Serial Visual Presentation. Au lieu d'afficher une page entière, l'appareil fait défiler les mots un par un, à la cadence que vous voulez. Imaginez un téléprompteur de poche, sauf que c'est vous qui gérez le défilement. J'en parlais déjà avec Uniread en 2018 , sauf que là, la chose est matérialisée dans un boîtier qui tient dans la paume de la main, au lieu de tourner en CLI dans un terminal.

Côté hardware, c'est une carte Waveshare ESP32-S3-Touch-LCD-3.49 avec 16 Mo de flash incluant l'OPI PSRAM, plus un panel AXS15231B de 640 x 172 pixels en mode paysage. Par contre, comme c'est pas un écran e-ink, mais un LCD IPS classique tactile capacitif, exit l'autonomie d'une Kindle. On tape plutôt dans le rythme d'un téléphone.

Le firmware embarqué convertit alors les EPUB en format .rsvp directement sur la carte SD à la première ouverture, puis met le résultat en cache. Pour les autres formats type .txt ou .md ou .html, il existe un convertisseur desktop séparé à lancer sur PC avant copie. Voilà, c'est moins fluide mais ça reste carrément faisable.

Quelques bémols quand même. La lecture mot par mot, ça demande un peu d'entraînement (les premières minutes, le cerveau panique un peu !!), et si vous voulez relire un passage précédent, faudra piloter manuellement l'engin via avec l'écran tactile.

Le concept même de RSVP, ça reste quand même une affaire de goût personnel. Certains tiennent un roman entier comme ça, d'autres décrochent au bout de 30 minutes parce que le cerveau zappe la pause naturelle qu'on prend en bout de ligne. Après ça peut convenir aux lecteurs de métro qui dévorent par micro-sessions (entre 2 arrêts quoi...). Dans ce cas le format colle carrément à votre rythme.

Pour la petite histoire, j'avais déjà parlé en 2020 d'un cousin plus sérieux, The Open Book Feather , dans un genre plus orthodoxe avec un véritable écran e-ink complet et un microcontrôleur Adafruit Feather sous Linux embarqué.

Mais si ça vous chauffe, sachez que le hardware coûte une trentaine de dollars, le firmware est libre, et la communauté commence déjà à demander l'intégration Calibre.

Source : Hackster.io

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');

Pack2theRoot - 12 ans d'accès root offert dans PackageKit

Sat, 25 Apr 2026 07:11:32 +0200 - (source)

Si vous tournez sur Ubuntu, Debian, Fedora ou RockyLinux, sachez que votre démon PackageKit a passé presque 12 ans à laisser une porte ouverte vers votre compte root. La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.

Pour corriger le soucis, mettez à jour vers PackageKit 1.3.5 ou le backport de votre distro. Pour vérifier votre version, c'est dpkg -l | grep -i packagekit sous Debian/Ubuntu, ou rpm -qa | grep -i packagekit côté Fedora et Rocky. Si vous êtes en 1.3.4 ou en dessous, considérez la machine comme exploitable.

Le bug est une race condition classique. En fait PackageKit vérifie vos droits, valide la transaction, mais utilise des données qui ont eu le temps de changer entre les deux. Un appel pkcon install bien chronométré et n'importe quel paquet s'installe en root, sans prompt Polkit . La liste des distros confirmées vulnérables couvre Ubuntu 18.04 à 26.04, Debian Trixie, RockyLinux 10.1, Fedora 43 et tout RHEL avec Cockpit.

Le détail marrant encore une fois c'est la méthode de découverte. La Telekom Red Team a tout simplement dirigé Claude Opus d' Anthropic vers la base de code de PackageKit, et c'est cette session d'audit assistée par IA qui a sorti la vuln. Les LLM commencent donc à trouver des bugs subtils que les audits humains ont laissé passer pendant plus d'une décennie. Tant mieux, ça va faire grimper le niveau de sécurité de nombreux projets !

Cette faille ancienne me rappelle BitPixie et son contournement de BitLocker resté en sommeil durant 20 ans. Le pattern est toujours le même, à savoir un composant système installé partout, qui cache un bug tout bête depuis siiii longtemps que plus personne ne l'audite avec un œil neuf.

Bref, merci Claude ^^

Source