Je déménage bientôt, et comme je quitte ma jolie campagne pour aller dans un endroit plus petit et sans nature (ouin), je dois me débarrasser de pas mal de matériel... Ponceuse, débroussailleuse, taille-haie, tronçonneuse, canapé, tracteur tondeuse.... la totale quoi. Et Le Bon Coin, même si à un moment, je vais devoir y passer, ça me stresse. Je me suis déjà fait menacer par un connard, quand je vendais ma Clio y'a longtemps et entre les acheteurs fantômes et les négociateurs relous, je trouve que les gens s'y comportent comme des bêtes. Du coup, pour commencer en douceur, j'ai choisi la méthode old school à savoir faire un petit catalogue recto verso glissé dans les boîtes aux lettres des voisins.

Sauf qu'aligner des colonnes sur un logiciel de mise en page un soir de semaine, ça heurte très violemment ce que je peux encaisser émotionnellement en ce moment ^^. L'idée m'est donc venue de prendre un petit abonnement et de tester Figma MCP (la passerelle qui laisse un agent IA piloter Figma à votre place) branché à Claude Code : vous donnez votre brief (idées, textes, prix) et un dossier de photos, et l'agent construit la mise en page à votre place.

Comme ça, plus besoin de toucher à rien.

Et si je fais cet article, c'est parce que j'ai été impressionné ! Ça fonctionne super bien. J'ai pas eu besoin de faire 50 aller-retour du genre "décalle ce truc de 2 px vers la gauche" et l'IA s'est démerdée pour tout faire rentrer sur un A4 recto verso.

Puis après, j'ai fait le même tour de magie avec la plaquette commerciale qui sert à vendre du sponsoring sur le site (le Patreon , aussi généreux soit-il, ne permet pas encore d'en vivre sans annonceurs, sniiiif). Je lui ai donné mes data, je lui ai dit ce que je voulais et Claude Code a réalisé le design et assemblé les slides à partir de tout ça.

Figma MCP, pour ceux qui débarquent, ça désigne le Model Context Protocol appliqué à Figma. C'est un standard ouvert qui permet à un agent IA comme Claude Code de discuter directement avec un logiciel, ici Figma. En clair, l'agent peut lire ce qui se passe dans votre fichier ET écrire dessus, créer des frames, poser du texte, aligner des composants, un peu comme si vous étiez aux commandes vous-même, sauf que c'est vous qui donnez les instructions et lui qui exécute.

Pour l'activer, ouvrez Figma desktop, créez un nouveau document DESIGN

Puis basculez en Dev Mode (raccourci Shift+D ou le bouton tout en bas de l'écran) où la section MCP server du panneau d'inspection permet d'activer un serveur local, à l'adresse http://127.0.0.1:3845/mcp.

Ensuite, pour que Claude Code construise et modifie réellement votre design comme je l'ai déjà fait pour mon catalogue, vous devrez le connecter au MCP de Figma depuis votre terminal avec cette commande :

claude mcp add --transport http figma https://mcp.figma.com/mcp

Une fenêtre d'authentification s'ouvre, vous validez avec votre compte Figma, et c'est plié ! Anthropic propose aussi un plugin tout-en-un si taper la commande à la main vous gonfle. Notez que cette connexion gratuite est en bêta, et Figma a prévenu que ça basculera un jour sur un modèle payant à l'usage. C'est tellement dommage de faire payer pour ça...

Reste ensuite à coller le lien du document Design dans votre prompt (ou à sélectionner le bon frame), et l'agent saura exactement où écrire.

Pour faire un peu de PAO, un petit design ou une présentation à monter vite fait, c'est super fluide. Moi j'ai branché mon outil Kassis (anciennement VoxDrop), j'ai tout dicté dans Claude Code et j'ai obtenu ce que je voulais sans effort. Claude est même parti chercher des infos sur le matos en ligne.

Figma est un chouette outil et il n'a pas l'air si complexe que ça mais quand on n'a pas envie d'apprendre à maîtriser toute cette machinerie pour faire un mini truc, ce MCP est bien pratique. Il sait tout gérer, les calques, composants, auto-layout, et compagnie et ça annihile totalement cette courbe d'apprentissage qui m'aurait fait perdre du temps sur d'autres projets plus importants.

Si vous bossez régulièrement sur des prez, des maquettes ou tout ce qui ressemble à de la PAO, ça vaut clairement le coup d'essayer en tout cas, même si vous maîtrisez Figma.

Il y a six mois, je vous parlais de Command & Conquer Generals, un jeu mort depuis 12 ans qu'un ver s'amusait à attaquer. Hé bien Ammaar Reshi, un designer connu pour ses projets IA (dont un livre pour enfants généré full IA qui a fait le tour des médias) vient de le ressusciter grâce à l'IA pour le faire tourner nativement sur iPhone, iPad et même Mac.

Je dis nativement puisque c'est le moteur original de 2003 qui a été recompilé en ARM64 pour Apple Silicon. Niveau dev, c'est donc Claude Code qui a fait tout le boulot et quand son modèle par défaut, Opus 4.8, s'est mis sérieusement à pédaler dans la semoule, c'est finalement grâce à Fable 5 qu'il a réussi à conclure l'histoire.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/command-conquer-generals-zero-hour-ios-mac/command-conquer-generals-zero-hour-ios-mac-1.mp4">lien vers la vidéo</a>.

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

Un chercheur en sécurité nommé Ian Carroll s'est amusé à lâcher Claude Opus sur la billetterie de Live Nation, afin d'y trouver des failles de sécurité, et l'IA lui a carrément écrit toute la chaîne d'exploitation sans aucune aide. Lui n'a eu qu'à le lancer...

Tout démarre avec une session de fuzzing sur l'API des terminaux, fgtapi.frontgatetickets.com. Carroll repère un truc... chaque endpoint qui contient le mot "device" réclame un paramètre deviceUID, et ce paramètre ne demande aucune authentification. Il colle un simple guillemet à la fin, la requête se met à ramer, et là, signe classique, le paramètre file direct dans une requête SQL sans le moindre échappement.

Une injection SQL bien à l'ancienne (si vous voulez voir à quoi ça ressemble, j'avais déjà décortiqué le principe il y a un bail).

Sauf qu'un WAF AWS est planté devant pour bloquer ce genre de payload. Et c'est là que Claude entre en scène. L'IA pige toute seule que le pare-feu n'inspecte que la couche extérieure de la requête, et qu'il suffit de planquer l'injection dans une sous-requête imbriquée pour passer sous le radar.

Ensuite elle se fabrique un oracle booléen aveugle qui fait que selon que la condition testée est vraie ou fausse, le serveur renvoie deux réponses différentes, "MC70-023" pour vrai, "Intellitix Upload" pour faux. Vous enchaînez ensuite les questions oui/non, et vous reconstituez la base entière, caractère par caractère.

Et la base, elle est bien garnie. Plus de 500 tables dans un ensemble baptisé fgs avec dedans les emails et mots de passe du personnel, ceux des clients, les tokens de reset, les tokens d'API et les jetons OAuth encore actifs. Avec ça, Carroll précise qu'il aurait pu émettre autant de billets gratuits qu'il voulait, pour n'importe quel événement.

Mais c'est une personne pleine de sagesse (et qui ne veut pas aller en prison) alors il ne l'a pas fait. Et surtout, il a tout remonté à Live Nation. Le lendemain où il les a contactés, la boîte confirmait le déploiement d'un correctif.

Ce qui est intéressant ici, c'est que le contournement du WAF par sous-requête, et la construction de l'oracle, tout ça a été proposé par Claude, et ne vient pas d'une demande du chercheur. On avait certes, déjà vu l'IA d'Anthropic dénicher des failles dans Firefox ou éplucher du code Apple II vieux de 40 ans mais là, c'est un sacré cran plus loin, je trouve.

Merci à Ian Carroll pour le writeup détaillé .

Source : CyberSecurityNews

Les humains font vraiment des trucs de dingues. Surtout les scientifiques !!

On a 2 biochimistes de l'Université du Minnesota (Kate Adamala et Aaron Engelhart) qui viennent de créer SpudCell, la première cellule artificielle capable de boucler un cycle de vie complet comme une vraie.

Je vais simplifier mais en gros, ils ont mélangé 150 ingrédients comme des lipides, des ribosomes, des enzymes et quelques brins d'ADN, et ont fini par obtenir une cellule artificielle, qui peut grandir, recopier son génome et se diviser en deux par elle-même.

Il faut savoir qu'une cellule normale utilise ce qu'on appelle un cytosquelette pour réussir à se diviser comme un ballon qu'on écraserait. Mais SpudCell n'a pas de cytosquelette. Du coup, à la place, ce sont des protéines de fusion qui s'accumulent encore et encore à la surface de sa membrane et qui se serrent tellement les coudes que la cellule finit par se couper en 2.

Et le truc encore plus incroyable, c'est que sur 5 générations environ, une variante bidouillée pour produire un peu plus de ces protéines a carrément pris le dessus sur la souche d'origine en mode "C'est la sélection naturelle qui gagne, baby".

Sauf que non, t'as rien de naturel, et t'es même pas vivante. Je vous rassure nos chercheurs n'ont pas recréé la vie et ils le disent eux-mêmes, SpudCell est très rudimentaire, bien loin de ce qu'on peut retrouver dans la nature. Je vois plutôt ça comme un nano robot en fait. Et comme la cellule n'est pas capable de fabriquer ses propres ribosomes (ce sont les chercheurs qui lui apportent en plus de sa nourriture), elle est loin d'être autonome et ne pourrait pas survivre hors de son bocal.

Mais n'empêche, ça prouve qu'on peut faire tourner les fonctions les plus fondamentales du vivant sans avoir besoin d'ingrédient magique. On est dans le même délire, je trouve que ces IA qui dessinent déjà de l'ADN qui n'existe nulle part dans la nature , sauf qu'ici c'est un vrai objet physique qui se réplique.

Suite à cela, Adamala en a profité pour lancer Biotic , une structure censée standardiser tout ce bazar, parce qu'aujourd'hui chaque labo réinvente la roue dans son coin. Mais je tiens quand même à vous rassurer, on est très loin des bactéries miroir qui donnent des sueurs froides aux biologistes. Comme je vous le disais, SpudCell ne survivrait même pas à un courant d'air, donc pas d'inquiétude.

Dernier petit détail qui compte sauf pour les fans de Didier, l'étude est pour l'instant un preprint qui n'a pas encore été relu par les pairs donc en attendant, on regarde ça avec des yeux qui brillent, mais on garde le champagne au frais ^^.

Source

Hier je vous parlais de GLM 5.2 , le modèle open source que j'ai fini par adopter (en partie) pour bosser. Eh bien la team z.ai (le lab chinois anciennement connu sous le nom de Zhipu AI) enchaîne le bon travail et pousse désormais ZCode , leur propre application pour coder avec des agents IA.

C'est une app desktop qui tourne sur Mac, Windows et Linux (en beta pour ce dernier), et elle est pensée pour les tâches qui durent. L'idée, ce sont des Goals que vous fixez, et l'agent planifie, exécute et vérifie son boulot tout seul par étapes, pendant que vous suivez la progression.

Vous avez donc un vrai environnement avec gestionnaire de fichiers, terminal, panneau Git et aperçu du navigateur en direct, ça cause le protocole MCP, ça sait lancer plusieurs agents en parallèle, et vous pouvez même piloter vos tâches à distance depuis WeChat ou Feishu. Et le tout tourne sur le même GLM Coding Plan que le reste de leur écosystème, à partir de 18 dollars par mois.

Si vous me suivez, vous savez déjà que GLM 5.2 se branche directement dans Claude Code, parce que l'API de z.ai est compatible Anthropic. Je vous avais d'ailleurs filé le petit launcher pour ça pas plus tard qu'hier. Mais ce ZCode, c'est surtout une bonne vitrine pour z.ai, afin de nous garder dans leur app plutôt qu'on utilise la concurrence. Quoi qu'il en soit, rien d'obligatoire, faut voir ce ZCode comme une option de plus pour coder à l'aide de l'IA.

L'appli est toute récente et en fouillant leur repo de feedback , je vois que l'app se prend encore des plantages bien douloureux sur Apple Silicon, avec notamment des erreurs qui vous font perdre le travail non sauvegardé et une fenêtre qui reste parfois noire même après avoir relancé l'app. Ça calme un peu pour un truc censé gérer des sessions longues de taf... Mais je pense que ça va rapidement se stabiliser, tant les dev de Z.ai font du bon boulot.

Si vous êtes déjà abonné au GLM Coding Plan, ça ne vous coûtera rien de plus d'essayer histoire de voir si les Goals collent à votre façon de bosser. Et sinon, pour les autres, l'API + votre outil habituel, ça fera tout aussi bien le job.

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.

Vous avez une petite carte graphique, un vieux Mac ou juste un bon processeur, et vous cherchez LE modèle d'IA parfait qui pourra tourner en local sans que ça rame ?

Hugging Face vient d'ajouter le filtre qui manquait à sa page Models : un sélecteur de matériel qui ne vous proposera que les modèles réellement compatibles avec votre machine.

Vous renseignez votre config (une RTX 3060, un processeur AMD, une puce Apple Silicon M2…) dans les réglages de votre compte, et le catalogue ne gardera plus que ce qui passe pour un GPU, un CPU ou une puce Apple précis.

Fini l'époque, donc, où il fallait ouvrir chaque fiche, chercher la VRAM requise, sortir la calculette et croiser les doigts au moment du lancement.

Ce filtre d'Hugging Face repose sur la taille des fichiers proposés, notamment les versions quantifiées au format GGUF, ces modèles compressés qui font tourner de grosses IA sur des machines modestes, et sur la RAM ou la VRAM de votre config déclarée. Cette base hardware est constituée de ce que possède réellement la communauté des 300 000 membres qui ont accepté de déclarer leur matériel.

Une fois le bon modèle repéré, vous récupérez les commandes via le bouton "Use this model" présent sur chaque fiche, puis vous lancez tout ça avec les outils habituels de l'IA locale, du genre llama.cpp, Ollama ou LM Studio. Et pour ceux qui veulent aller plus loin sur Apple Silicon, il existe également des serveurs d'inférence maison pour remplacer l'API d'OpenAI par votre propre Mac .

Maintenant, si vous avez un chip un peu exotique, un accélérateur NPU ou une carte à peine sortie, il faudra parfois patienter, voire passer par le forum pour réclamer son ajout dans la base, mais bon, je chipote !

Source

Cursor , le célèbre IDE de vibe coding, vient de sortir une app iOS qui permet de piloter des agents IA codant à votre place, directement depuis un smartphone.

Je ne parle donc pas d'écrire du code sur un écran de six pouces, hein, mais bien de lancer une tâche, de la confier à un agent qui bosse tout seul dans le cloud, et de garder un œil dessus pendant que vous êtes dans le métro ou affalé dans le canapé.

Vous lancez l'app, vous tapez ce que vous voulez faire, et un agent part bosser dans sa VM avec son environnement de dev complet. Et vous pouvez comme ça en lancer plusieurs en même temps et suivre leur avancement, même sur l'écran verrouillé sur smartphone. Quand il se retrouve bloqué, l'agent IA vous envoie une notif et quand c'est fini, vous n'avez plus qu'à relire les diffs, à passer en revue les captures écran, à consulter les logs et merger la pull request directement depuis le téléphone.

Je vous laisse avec Benjamin qui va vous expliquer ça (roooh, ça va, j'rigole) :

Y'a aussi un mode "remote control" comme ce qu'on retrouve chez Claude Code , qui récupère un agent déjà lancé sur votre ordi, afin de pouvoir continuer à le piloter à distance. Moi j'utilise souvent ce genre de trucs quand je dois m'absenter pour faire une course, afin de ne pas perdre de temps.

On est, en quelques mois, passé d'un monde où le dev tapait religieusement chaque ligne à un monde où il décrit une "intention" et supervise des agents qui exécutent le taf. Et le clavier devient presque accessoire, surtout avec des outils comme VoxDrop .

L'app est en beta publique, réservée aux plans payants, et pour l'instant c'est iOS uniquement, et Cursor lance aussi une promo de 75% sur les runs Composer 2.5 dans l'app jusqu'au 5 juillet, histoire de vous faire tester tout ça tranquillement.

L'app est dispo sur l' App Store si vous voulez faire du dev depuis vos toilettes.

Source

Je ne suis pas très client des livres audio parce que mon cerveau, en général, part faire des trucs dans son coin et je me retrouve à rien écouter du tout. Je préfère un petit podcast où ça rigole qu'une œuvre littéraire qui demande de la concentration.

Mais je sais que vous appréciez beaucoup les livres audio et il arrive très souvent qu'un bouquin n'ait pas sa version audio. Un vieux roman qui n'est plus édité, un PDF technique, une fanfiction de 800 pages, un article de korben.info ou juste un truc que personne chez Audible ne prendra le temps d'enregistrer parce que ça n'intéresse que vous.

Mais youpi, Finrandojin, un internaute, en a eu marre d'attendre l'audiobook de ses rêves et a codé Alexandria, un générateur de livre audio qui tourne 100% en local sur votre ordi.

Vous balancez un fichier .txt, .md ou .epub, dans l'appli, puis un LLM découpe le texte et annote chaque ligne avec le personnage qui parle et la manière dont il le dit, puis le moteur Qwen3-TTS joue le tout en local comme une vraie troupe de doubleurs professionnels. Et le résultat est assez propre, même si ça ne vaut pas encore un vrai enregistrement fait par un vrai humain. M'enfin, faute de mieux, pourquoi pas !

Et surtout, ce LLM qui fait le découpage, vous le branchez où vous voulez. En local via LM Studio ou Ollama, ou dans le cloud avec OpenAI ou n'importe quelle API compatible. Ensuite, une fois le script annoté, Alexandria vous propose 9 voix pré-entraînées avec contrôle de l'émotion et du ton.

Vous pouvez aussi cloner une voix à partir de 5 à 15 secondes d'échantillon, ou carrément en fabriquer une à partir d'une simple description écrite. Vous tapez par exemple "Une voix masculine chaude et grave, au ton calme et posé" (c'est ma voix quoi...lol) et hop, il vous la fabrique.

La fonctionnalité de génération de personnas fait également gagner un temps de dingue puisqu'en un clic, le LLM analyse le bouquin, invente une description de voix pour chaque personnage, génère l'audio de référence et assigne tout automatiquement.

Et pour les obsédés du détail, il y a même un éditeur web où vous regénérez n'importe quelle ligne individuellement, du training LoRA pour vous fabriquer des voix persistantes, et un export en MP3 en pistes séparées pour bidouiller ça ensuite dans Audacity, ou en M4B chapitré qui rentre direct dans Audiobookshelf, Apple Books ou VLC. Et tout ça bien sûr, dans une dizaine de langues, français compris.

Alexandria exigera par contre une carte graphique avec 8 Go de VRAM au minimum, 16 et plus si vous voulez du débit correct. Et si vous êtes sur Mac, mauvaise nouvelle, l'accélération MPS d'Apple Silicon n'est pas encore supportée, donc ça tournera en mode CPU, donc ce sera lent. Mais c'est pas très grave, vous lancez la génération, et vous retournez lire d'autres articles sur mon site pour passer le temps.

Même galère aussi pour les gens qui ont de l'AMD sous Windows. Les chanceux par contre, ce sont les possesseurs de NVIDIA sous Windows ou Linux et les AMD sous Linux. Maintenant si vous tenez juste à faire parler votre Mac sans y passer trois heures par chapitre , vous serez mieux servi ailleurs qu'avec Alexandria.

Pour l'installation, le plus simple passe par Pinokio en deux clics, et si vous n'avez pas le GPU qui va bien, il y a un notebook Google Colab pour tourner sur un T4 gratuit dans le navigateur. Comptez quand même un téléchargement de 3,5 Go pour les modèles TTS à la première utilisation, ils ne sont pas inclus dans l'install.

Vous l'aurez compris, c'est du DIY un peu gourmand en GPU, mais pour tous vos ebooks à écouter qui n'auront jamais de narrateur, ça ouvre les perspectives ! Le code est sous licence MIT et je vous invite quand même à tester avec un chapitre avant de vous lancer dans un roman entier.

Source

Tapez [hello] dans votre éditeur, appliquez une police, et le mot se change en QR code scannable. Pas de générateur en ligne, pas d'image à exporter mais juste une police de caractères. C'est l'idée complètement barrée de qr-font , le projet de Jim Paris, et quand j'ai testé la démo, j'avoue, ça m'a plu.

Vous installez une des polices TrueType du projet, vous écrivez votre contenu destiné à devenir un QR code entre crochets, et le texte autour s'affichera tout à fait normalement.

Par exemple abc[hello]ghi vous donnera "abc", un QR code, puis "ghi", le tout sur la même ligne. Et comme rien n'est jamais transformé en image, votre QR code reste du texte pur. Vous pouvez le copier-coller comme un caractère lambda, le stocker en texte brut, ou encore le glisser au milieu d'un paragraphe dans n'importe quel document.

Le texte [https://korben.info] tapé avec la police QR Font 2-L : la police le transforme toute seule en QR code, sans aucune image.

Mais vrai tour de force surtout, c'est la fabrication de cette police car un QR code normalement, c'est une image dans laquelle un programme a encodé des données. Ce programme calcule une parité Reed-Solomon, positionne les petits carrés comme il faut, applique un masque par-dessus et ensuite tout est exporté dans un PNG ou un JPG. Alors que là, tout le calcul se fait DANS le fichier de la police de caractère.

Pour reproduire l'algo Reed-Solomon, la police fait des maths toute seule comme une grande, sous la forme de règles OpenType.

C'est dans la lignée des bidouilles à base de QR Code dont je vous ai déjà causé comme ces QR codes montés en LEGO ou de ces polices Unicode qu'on détourne pour frimer dans sa bio Insta.

Forcément, c'est un proof-of-concept, donc il y a des garde-fous. En effet, chaque police ne peut encaisser que 17 caractères pour la version light, 32 pour la standard et 53 pour l'étendue. Donc vous ne pourrez pas y mettre une URL à rallonge. Par contre, un petit mot ou une URL classique, ça passe tranquille.

Notez aussi que les navigateurs découpent le texte en ligne AVANT d'afficher les glyphes, ce qui veut dire qu'un de ces QR peut se retrouver coupé en 2 en fin de ligne. Mais y'a moyen de contourner le problème avec la règle CSS suivante sur le bloc et le tour est joué ! :

white-space: nowrap

Bref, c'est génial et pas si inutile que ça je trouve...

Md Jueal Mia et Hadi Amini, deux chercheurs de Florida International University , ont mis au point une méthode qu'ils ont baptisée JaiLIP qui permet de forger une image capable de contourner les garde-fous des LLM pour les jailbreaker.

Pour cela, ils utilisent 2 techniques en simultanée. La première dit à l'image "reste identique à l'originale, qu'aucun humain ne voie la moindre différence" et la seconde dit "pousse le modèle à cracher la réponse interdite". Ainsi, en poussant ces 2 curseurs d'un coup, ils obtiennent une photo qui au premier abord a l'air normale mais qui fait dérailler les modèles IA.

Vous, vous repérez un chat, des contours, une scène et vous lui courez derrière pour lui faire des papouilles. L'IA, elle voit une grille de chiffres et des corrélations entre pixels. Du coup sa vie est nulle mais surtout, une retouche minuscule, totalement invisible à votre œil, suffit à déplacer ce qu'elle comprend de l'image.

Sur leurs tests, l'image trafiquée a quasiment doublé la part de réponses dangereuses par rapport à la même image laissée intacte, la toxicité étant mesurée avec des outils standards du domaine. Dans l'un de leurs exemples, ils ont trafiqué une image de signalisation routière qui a permis au modèle ensuite d'expliquer OKLM comment ignorer les règles de circulation et éviter les PV.

Les chercheurs ont testé l'attaque sur deux modèles vision-langage open source, BLIP-2 et MiniGPT-4. GPT-4V, Gemini et les autres gros modèles fermés, eux, n'ont pas été testés dans l'étude. Donc non, contrairement à ce que j'ai pu lire par ci et par là, ce n'est pas une faille prouvée dans ChatGPT ou peu importe l'assistant IA que vous utilisez tous les jours.

Et tromper une IA avec une image bricolée, ça existe depuis une bonne dizaine d'années. Mais la nouveauté de JaiLIP, c'est surtout sa recette d'optimisation. En jouant sur les deux pertes à la fois, l'image reste plus discrète à l'œil tout en se montrant un cran plus efficace que les bidouilles précédentes.

Et ce genre de détournement nous concerne tous parce que des modèles qui regardent des images, il y en a partout maintenant. Les agents IA qui bossent à partir de captures d'écran, les assistants à qui vous balancez vos photos, sans oublier la modération automatique qui trie les images avant publication. À cause de ça, l'image est dorénavant un canal d'attaque, exactement comme l'était déjà le texte...

On l'a vu avec le son inaudible qui pirate les assistants vocaux , on l'a vu avec les IA qu'on manipule sans qu'elles s'en aperçoivent , et c'est toujours la même logique qui revient. Ce n'est pas parce qu'en tant qu'humain, nous ne percevons rien, que l'IA elle n'est pas capable de capter le message 5/5.

Le cousin de cette attaque, côté perception, c'est par exemple le sticker qui trompe une voiture autonome . Et côté parade, nos chercheurs esquissent une piste légère : virer au hasard 10 à 30% des mots passés en entrée, histoire de casser l'attaque sans réentraîner le modèle.

Prometteur d'après eux, mais c'est pas encore une solution blindée. Pour le reste, leurs conseils tiennent du bon sens : Ne passez pas d'infos sensibles en image à un modèle, limitez qui peut envoyer des images à vos systèmes, et auditez sérieusement la sécurité avant de mettre un VLM en prod.

C'est pas le graal mais c'est mieux que rien. Bref méfiez vous des images que vous donnez à vos IA. On ne sait jamais.

Source : le papier JaiLIP sur arXiv

Il y a des problèmes qui n'existent pas, et des gens qui les résolvent quand même... Ray Foss en fait partie. Ce dernier a fait en sorte que sa Steam Controller flambant neuve rampe toute seule jusqu'à son chargeur, sans qu'il ait à lever le petit doigt. Et pour cela, il a codé son Triton Auto-Charge Vision Tracker qui tourne entièrement dans le navigateur et qui est utilisable par tous !

Le principe est bien tordu... Vous collez une webcam au-dessus de votre bureau, vous ouvrez la page, et vous cliquez sur trois points à l'écran : le palet de charge, l'avant de la manette, l'arrière. À partir de là, la vision par ordinateur suit la manette en temps réel pendant que le code pilote ses deux petits moteurs de vibration internes.

Petit rappel si vous aviez hiberné, Valve a ressorti sa Steam Controller en mai dernier, des années après avoir lâché la première. Elle se recharge sur un palet magnétique, et c'est pile poil cette dernière étape que Foss a automatisée. La Steam Controller, c'est aussi la manette dans laquelle Valve a planqué un cri Wilhelm , et visiblement elle attire les bidouilleurs.

En pulsant ces moteurs de façon asymétrique, autour de 70 Hz, la page fait littéralement ramper la manette sur le bureau et la réoriente petit à petit vers le palet. C'est le principe de ces bristlebots faits avec une brosse à dents et un moteur vibreur de téléphone, sauf qu'ici les moteurs étaient prévus pour faire vibrer la manette dans vos jeux, et surement pas pour la balader sur le bureau...

Pas d'install, pas de pilote à régler non plus, c'est la page qui se connecte directement à la manette via WebHID, la même techno qui permet déjà de tester son matos gaming dans le navigateur , à condition d'être sur Chrome ou Edge parce que Firefox et Safari boudent toujours cette API.

L'interface de l'outil, avec les points de repère à placer sur la manette et le palet.

Au passage, elle lit la batterie de la manette et vous affiche le pourcentage et même le voltage de la cellule, histoire de confirmer que le contact magnétique se fait bien.

Foss a aussi prévu un mode approche en douceur qui réduit de moitié la fréquence des vibrations quand la manette arrive tout près du palet, pour qu'elle se pose dedans au lieu de le percuter. Enfin, en théorie, parce qu'il prévient lui-même que l'amarrage n'est pas garanti.

La vraie limite du truc, c'est que le calage des points de repère reste assez pénible à faire.

Ça ne sert strictement à rien, mais c'est marrant. Le projet est en open source sur GitHub si vous voulez tenter le coup chez vous.

Source

Amazon Q, l'assistant de programmation dopé à l'IA que propose Amazon, pouvait se faire piéger d'une manière aussi simple qu'embarrassante.

Petit rappel pour situer. Amazon Q se greffe dans Visual Studio Code, l'éditeur de code de Microsoft que les développeurs utilisent au quotidien, et sert à écrire ou corriger du code à votre place.

Des chercheurs de Wiz, une société spécialisée dans la sécurité du cloud, ont découvert que cet assistant exécutait des commandes cachées à la simple ouverture d'un projet. La faille a reçu un identifiant officiel, CVE-2026-12957, et une note de gravité de 8,5 sur 10, ce qui est sérieux.

Le problème venait d'un fichier de configuration un peu particulier. Pour fonctionner, Amazon Q lit un fichier nommé .amazonq/mcp.json, qui s'appuie sur le MCP, pour Model Context Protocol, une sorte de prise standardisée qui permet de brancher une IA sur des outils extérieurs.

Sauf qu'il suffisait d'ouvrir un dépôt de code et d'activer Amazon Q pour que l'extension aille lire ce fichier et exécute son contenu. Sans fenêtre de confirmation, sans demander votre avis, et sans vérifier si vous faisiez confiance au dossier que vous veniez d'ouvrir.

Et c'est là que ça devient vraiment fourbe. Ces commandes héritaient de tout votre environnement de travail. Du coup, elles pouvaient récupérer au passage vos clés d'accès au cloud d'Amazon, vos jetons de connexion, vos secrets d'API et même l'accès à votre agent SSH, ce trousseau qui garde en mémoire vos connexions aux serveurs distants. En clair, tout ce qu'un développeur laisse ouvert pendant qu'il travaille.

Le plus gênant, c'est que Visual Studio Code possède justement une sécurité prévue pour ça, la confiance d'espace de travail, qui vous demande si vous validez un dossier avant de le laisser agir. L'extension d'Amazon passait tout bonnement par-dessus.

Pour un pirate, le piège était facile à tendre. Il suffisait de glisser ce fichier dans un projet open source d'apparence anodine, ou dans un bout de code partagé sur un forum, et d'attendre qu'un développeur qui récupère un projet l'ouvre pour voir comment il fonctionne.

Amazon a corrigé le tir dans la version 1.65.0 de son serveur de langage et a confirmé la correction. Wiz note d'ailleurs que des failles très proches ont déjà touché d'autres outils de code boostés à l'IA.

Donner autant de pouvoir à une IA sans le moindre garde-fou, et laisser filer les clés du cloud avec, ça reste une erreur de débutant pour un géant comme Amazon.

Source : The Register

Dropbox vient de sortir un plugin pour Claude Code , et leur idée c'est de pouvoir brancher vos fichiers Dropbox directement dans vos sessions de dev Claude Code / Cowork.

Alors je me suis demandé à quoi ça pouvait bien servir et voici ce que j'ai compris. Une fois que le plugin est en place, ça permet à Claude Code d'aller piocher dans votre Dropbox vos docs techniques, vos cahiers des charges, votre code...etc pour s'en faire du contexte. Tout devient de la matière fraiche pour corriger ou générer du code et quand c'est fini, ce qui est produit peut être à son tour stocké sur Dropbox.

Le plugin sait récupérer les fichiers en fonction de leur nom, de mots clés, de leur emplacement et bien sûr en fonction de leurs méta données. Même vos liens partagés il sait comment les gérer. Bref, il fait tout simplement le passe-plats entre tout le bordel que vous stockez sur Dropbox et Claude Code.

Cela dit, gardez la tête froide parce que tout ce que l'IA lit part sur les serveurs d'Anthropic pour être traité. Donc évitez quand même de le lâcher sur le dossier qui contient vos contrats, vos mots de passe ou vos données clients. Lui autoriser juste un dossier dédié avec ce que vous acceptez de partager, ce sera plus sain.

Pour l'installer, ça se passe dans Claude Code sur le web. Vous filez dans le menu Personnaliser, Connecteurs puis vous cherchez Dropbox en parcourant les plugins et vous cliquez sur ajouter. Une auth OAuth plus tard (vos identifiants Dropbox habituels), c'est branché. Un petit /reload-plugins et le plugin s'active alors dans la session en cours.

En plus de ce plugin, Dropbox propose également un serveur MCP classique en ligne de commande qui est un peu plus souple et surtout peut se brancher dans Cursor, Claude Desktop ou Devin.

Un bémol quand même, c'est pas open bar... sniiif. Eh oui, Dropbox plafonne tout ça à 5 Mo par fichier lu ou créé via l'intégration, et le contenu pondu par Claude ne se sauvegarde qu'en texte (.txt, .md, .html, .py), et pas en image ni en PDF. Quant aux limites de débit de l'API, on ne les connaît pas.

Bref, pour les gros fichiers ou les binaires, faudra donc passer par autre chose.

Si vous vivez dans Claude Code et que votre vie est rangée dans Dropbox, ça vaut peut-être le coup de jeter un œil ici.

Vous vous souvenez de la première fois que vous avez lancé Half-Life 2 et que vous avez attrapé une caisse avec le gravity gun ? Eh bien un lycéen qui se fait appeler slqnt vient de remettre tout ça dans votre navigateur, gratuitement, sans avoir à installer Steam ni à télécharger le moindre gros paquet. Ça se passe sur hl2.slqnt.dev , c'est en ligne depuis hier, et le jeu tourne tout en fluidité, largement au-dessus des 60 images par seconde directement sous Chrome.

Sur mobile par contre, il vous faudra un clavier branché parce que les contrôles tactiles sont quasi inexistants pour l'instant, mais sur un PC, vous lancez la page et vous voilà à Black Mesa East.

Maintenant, le plus intéressant c'est comment il s'y est pris, parce que porter un jeu bâti sur le moteur Source de Valve (le même que celui de 2004, successeur de GoldSrc) dans un onglet, ça ne se fait pas en claquant des doigts.

Et slqnt n'est pas parti de zéro puisque c'est un copain qui lui a montré un portage de Portal fait par un autre dev nommé weliveinhell. Ce projet open source était d'ailleurs lui-même un fork de nillerusr/source-engine , c'est-à-dire une version modifiée de la fuite du code du moteur Source de Team Fortress 2 qui a circulé en 2020. Voilà pour la base du truc qui n'est ni plus ni moins que le moteur leaké patiemment retapé par la communauté.

L'astuce de ce portage tient dans un mode de rendu appelé ToGLES. En gros le moteur sait parler OpenGLES, le truc qu'on utilise d'habitude pour les applis Android, sauf qu'Emscripten sait traduire ces appels en WebGL2 dans le navigateur. Résultat, slqnt n'a eu quasiment aucun travail à faire côté affichage, le plus dur étant déjà fait.

Le casse-tête par contre, ça a été d'abord les assets, parce que cette version du moteur date d'avant la réédition anniversaire de HL2 et ne supportait pas ses fichiers. Il a donc fallu basculer sur la branche steam_legacy de Steam, puis dépaqueter tous les VPK du jeu et les redécouper en fichiers .data, un par carte, pour que le navigateur les charge au fur et à mesure.

Et puis il y a eu les animations faciales. C'était l'une des grandes fiertés techniques de HL2 à sa sortie, la façon dont les visages bougeaient en parlant. Sauf que ça faisait tellement planter le portage que slqnt a fini par désactiver complètement le système pour avoir quelque chose de stable.

Du coup le G-Man vous fait son monologue d'intro avec un visage figé, mais au moins ça tourne. Le reste de son journal de bord est également une jolie liste de galères de bidouilleur, vu de l'intérieur avec au hasard, les sauvegardes à recâbler sur le système de fichiers d'Emscripten, les batteries et medkits qui ne fonctionnaient pas, le gravity gun qu'Alyx vous tend mais qui n'arrivait jamais dans l'inventaire, les PNJ qui s'effondraient et mouraient au hasard, les headcrabs qui ne faisaient aucun dégât, l'eau toute noire et j'en passe...

Petit détail qui parle à quiconque a déjà bidouillé un jeu, il a dû remapper l'accroupissement sur la touche C, parce que CTRL déclenchait des raccourcis du navigateur qui pourrissent la partie.

Reste maintenant la question que tout le monde se pose : Est-ce que Valve est au courant ? Parce qu'un portage qui repose sur du code moteur leaké et sur les assets du jeu, légalement, c'est une zone grise bien grise qui tire vers le noir.

Valve a toujours été plutôt cool avec sa communauté de moddeurs, mais ça pourrait disparaître du jour au lendemain. Après si l'idée d'un jeu Source qui tourne dans un onglet vous fait marrer, c'est exactement le même esprit que ce Portal 2 transformé en serveur web , ou que ce Doom qui tourne avec juste du CSS . Mettre les vieux FPS dans le navigateur, c'est presque devenu un sport, je vous en parlais déjà avec Wolfenstein 3D .

Bref, foncez essayer tant que c'est en ligne. Et si vous y arrivez sur mobile sans clavier, écrivez vite un bouquin pour raconter comment vous avez fait !

Source

Deno, le moteur d'exécution JavaScript et TypeScript créé par Ryan Dahl (le développeur qui avait déjà lancé Node.js il y a une quinzaine d'années), s'apprête à faire un sacré pas de côté avec sa prochaine version majeure, qui permettra de fabriquer des applications de bureau pour macOS, Windows et Linux à partir du même code, et même depuis une seule et unique machine.

La fonction, baptisée Deno Desktop, a déjà débarqué discrètement dans la version 2.9.0 distribuée en canal canary, c'est-à-dire la branche de test réservée aux plus curieux d'entre vous, mais pas encore sur la version stable.

L'idée est simple : vous prenez un projet web écrit en TypeScript, ou construit avec des outils connus comme Next.js, Astro, Fresh ou Vite, et Deno le compile en un seul fichier exécutable qui embarque votre code, le runtime et le moteur d'affichage, prêt à distribuer tel quel. Un petit serveur web local est même glissé dans le paquet, ce qui veut dire qu'une appli web existante peut migrer vers le bureau sans qu'on réécrive quoi que ce soit.

Pour afficher votre interface, vous avez le choix entre trois approches, et c'est sur le poids final que ça se joue. Par défaut, Deno s'appuie sur la WebView native du système, autrement dit le moteur d'affichage web déjà présent sur votre Mac ou votre PC, ce qui donne une application d'environ 68 Mo sur macOS.

Si vous préférez la régularité d'un Chromium complet d'une plateforme à l'autre, vous pouvez embarquer le CEF (le Chromium Embedded Framework, en gros un navigateur Chrome entier glissé dans l'application), mais le poids monte alors au-delà de 300 Mo. Et pour les plus aventureux d'entre vous, un mode brut, sans moteur web laisse gérer soi-même les fenêtres et le rendu via WebGPU ou Skia.

Trois moteurs, donc. À vous de choisir.

Forcément, on pense tout de suite à Electron, la techno derrière Slack, Discord ou VS Code, réputée pour produire des applications obèses, et à ses rivaux plus légers que sont Tauri, Electrobun ou Dioxus. Deno débarque sur un terrain déjà bien occupé, avec quand même un argument solide : le même outil sert au serveur, au site et maintenant à l'application de bureau.

Sauf que voilà, tout n'est pas encore en place. La fonction n'est pas stable, certains testeurs ont vu le bouton de fermeture des fenêtres refuser de marcher sur macOS, le sélecteur de fichiers et l'accès au presse-papier manquent toujours à l'appel, et le support mobile reste à l'état de promesse. Les menus natifs, les menus contextuels, les boîtes de dialogue système et les notifications répondent déjà présents, eux.

La vraie question, du coup, c'est de savoir si Deno ne se disperse pas. Le projet vit avant tout grâce à son runtime, et certains se demandent si fabriquer un concurrent à Electron ne va pas siphonner l'énergie qu'il faudrait au coeur du moteur.

Bref, recycler un site en appli de bureau sans tout réécrire, et bien pourquoi pas ?

Source : The Register

Si vous ne connaissez pas, un favicon, c'est cette mini icône pixelisée que vous pouvez voir dans l'onglet de votre navigateur qui en général est le logo du site que vous visitez. Hé bien le dev Tim Wehrle a réussi à y faire tenir un site web entier en stockant tout son HTML dans les 212 octets de l'image.

L'astuce est toute con vous allez voir... Une image, c'est des pixels. Et chaque pixel a 3 valeurs : rouge, vert, bleu, soit 3 octets. Du coup il prend son HTML, le découpe octet par octet, et colle chaque octet dans une couleur. Premier octet dans le rouge, le suivant dans le vert, puis le bleu, et on continue ainsi de suite. Et voilà comment il arrive à stocker 208 octets de HTML dans un carré de 9 pixels sur 9. Et au final, le truc ressemble à des confettis random.

Pour relire tout ça ensuite, un peu de JavaScript suffit. Le navigateur charge l'image, la passe dans un canvas, relit chaque pixel, recolle les octets et réaffiche la page. Il n'y a donc rien à installer et pour tester ça par vous-même, il a même mis une démo ici où vous pouvez regarder l'encodage / décodage se faire sous vos yeux ébahis.

Maintenant, n'espérez pas faire tenir votre site e-commerce là dedans hein puisque la capacité plafonne à 239 octets. Et sans le bout de JavaScript qui décode, le favicon tout seul ne servira à rien. Et ce n'est pas de la stéganographie non plus puisqu'on ne planque rien dans une vraie image. La data c'est l'image...

Mais c'est le genre de hack inutile que j'adore ! Le code est sur GitHub si vous êtes curieux et il raconte toute sa démarche sur son blog .

Si vous utilisez un ordinateur portable à puce graphique AMD Radeon sous Linux, vous avez peut-être déjà vu l'écran se figer d'un coup, sans raison apparente, à peu près une fois par semaine. Ce bug agace les utilisateurs depuis des années, et un correctif vient enfin de pointer le bout de son nez.

Le coupable se cache dans AMDGPU, le pilote graphique libre qu'AMD maintient pour Linux. On parle ici du logiciel qui fait le lien entre la carte graphique et le système d'exploitation.

Le problème ne date pas d'hier. En fouillant l'historique du code, le développeur à l'origine du correctif a remonté la piste jusqu'à une modification introduite en 2017. Presque huit ans de gels d'écran.

Le symptôme typique, c'est une erreur "flip_done timed out" dans les journaux du système. Pour faire simple, l'ordinateur attend que l'écran affiche l'image suivante, ce signal n'arrive jamais. Et tout gèle.

Le souci touche plusieurs machines, bien connues du monde Linux, comme le Lenovo ThinkPad T14 Gen1 en version AMD ou le Framework Laptop 13 équipé d'un processeur Ryzen 7 7840U. Jusqu'ici, le seul remède consistait à désactiver le PSR, pour "Panel Self Refresh".

Cette fonction d'économie d'énergie laisse l'écran réafficher tout seul sa dernière image fixe sans réveiller la carte graphique, histoire d'économiser de la batterie. Pratique sur un portable, sauf que c'est précisément elle qui déclenchait les gels.

Le plus intéressant, c'est la méthode employée. Le correctif a été mis au point en "vibe debugging" avec Claude Code, l'assistant de programmation d'Anthropic, le concurrent direct d'OpenAI. Le développeur a décrit le bug à l'IA, qui l'a aidé à explorer le code et à affiner les correctifs, plutôt que de dérouler une procédure de débogage classique.

Concrètement, les patchs revoient la gestion du "vblank" et du "page-flip" dans le bloc d'affichage DCN, c'est-à-dire la mécanique interne qui synchronise le moment où une nouvelle image remplace l'ancienne à l'écran. D'autres tentatives avaient échoué par le passé, mais cette série semble enfin tenir la route.

Maintenant patience, rien n'est encore intégré dans le noyau Linux officiel. Les correctifs doivent passer par les tests et la validation des mainteneurs avant d'arriver chez tout le monde, ce qui peut quand même prendre plusieurs versions du kernel.

Bref, on est là devant un bug fantôme qui date d'lil y a huit ans, débusqué en discutant avec une IA, voilà qui résume assez bien l'année 2026 côté développement.

Source : Phoronix