Vos empreintes digitales, votre photo et jusqu'à votre ADN, voilà ce que les États-Unis aimeraient consulter directement dans les fichiers de police européens. Le deal s'appelle Enhanced Border Security Partnership (EBSP), et la monnaie d'échange, vous la connaissez bien si vous avez déjà voyagé aux États-Unis. C'est ce petit formulaire ESTA que vous remplissez avant de filer à New York ou ailleurs (celui qui vous évite le visa).
Le projet d'accord, vous n'étiez pas censé le lire, mais l'ONG Statewatch l'a publié en avril dernier et son article 3 range dans les données biométriques vos empreintes, vos photos et vos données génétiques (oui, votre ADN). Washington réclame cet accès depuis février 2022 à tous les pays dont les citoyens, comme vous, voyagent sans visa, et le Conseil de l'UE a autorisé la Commission à négocier le 16 décembre 2025.
Bruxelles jure vouloir un système de requête ponctuelle (c'est-à-dire un tuyau d'accès), avec ce que le mandat du Conseil appelle "une limitation claire des finalités des données échangées, avec des déclencheurs très spécifiques". Sauf que la demande américaine d'origine, elle, parle de cribler "de façon routinière" les bases biométriques des pays partenaires.
Entre les deux il y a donc un gouffre !
Et le texte ne s'arrête d'ailleurs pas à la biométrie puisqu'il prévoit de faire circuler des "indications de risque" pour déterminer si votre entrée "poserait un risque réel pour la sécurité publique ou l'ordre public". Traduisez : votre profil, vos fréquentations, vos opinions. Vous vous souvenez de ce touriste refoulé à cause d'un mème sur JD Vance ? Ou toutes ces histoires de douaniers qui fouillent votre téléphone à l'arrivée ? Bah je vous laisse imaginer la cata...
Statewatch pointe surtout la contradiction avec le droit européen lui-même. L'article 9 du RGPD interdit en principe de traiter les données génétiques, et le projet se contente de "garanties appropriées". En effet, la Charte protège les Européens contre la discrimination fondée sur les opinions politiques mais ça, le texte qui cadre ce Enhanced Border Security Partnership, n'en dit rien.
La Cour de justice de l'UE avait retoqué en 2022, dans son arrêt sur le PNR (Passenger Name Record), les traitements automatisés qui décident sans humain dans la boucle, et voilà que ça revient sur le devant de la scène d'une autre manière.
Franchement, c'est relou. On nous impose des bandeaux cookies sur chaque site de recettes de cuisine, on fait tenir un registre de traitement au moindre club de pétanque et pendant ce temps-là, le Conseil européen négocie tranquillou un accès que j'estime abusif pour une administration étrangère à des fichiers d'empreintes (biométriques) nationaux. Ça fait un peu mal au cul vous ne trouvez pas ???
Alors, certes, on voyage sans visa, même si, quelque part, l'ESTA c'est un peu un visa qui ne dit pas son nom. Enfin, moi, je vois pas trop la différence sur le fond... Et puis dans cette Europe à deux vitesses, on a quand même la Bulgarie, Chypre et la Roumanie qui, eux, ont besoin d'un visa. Donc on n'est pas très solidaire sur le coup.
Puis je vous rappelle que les fichiers d'identité français ne sont pas franchement des coffres-forts quand on pense par exemple à l'ANTS qui s'est fait siphonner 19 millions de dossiers via une faille basique . Et sur le sérieux de nos amis américains, je repense à cette grand-mère américaine qui a passé six mois en prison à cause d'un faux positif de reconnaissance faciale, et je me dis que si on y ajoute un croisement transatlantique automatisé des données, ça va pas être joli joli en termes de bourdes...
Bref, pour le moment rien n'est signé et les États membres se déchirent encore sur la portée et les durées de conservation de NOS données qu'ils vont offrir aux États-Unis. Et on verra bien si le Parlement va donner son feu vert, mais en tout cas c'est maintenant que tout se joue.
Voilà, surveillez ce dossier de près et je vous invite à aller lire l'analyse de Statewatch parce qu'elle est plutôt salée.
Aujourd'hui je vais vous parler d'un jeu de karting façon Mario Kart qui fonctionne sans moteur 3D et sans même une seule ligne de code.
En réalité, il s'agit d'un modèle de 130 millions de paramètres qui est capable de deviner à quoi doit ressembler l'image suivante. Cela a été mis en ligne hier soir par Asankhaya Sharma, c'est le gars derrière OptiLLM . Ça s'appelle Neural Drive et ça imite Super Tux Kart , le Mario Kart libre dont je vous ai déjà parlé.
Neural Drive est donc un modèle qui regarde les sept dernières images ainsi que les touches que vous enfoncez sur votre clavier. Son job c'est simplement de peindre l'image suivante. Ainsi, si vous appuyez sur la flèche du haut, il dessinera une carte qui avance, si vous tournez à gauche, il dessinera un virage...etc.
Donc, il n'y a aucun code derrière, c'est juste une hallucination que vous pilotez en 384 x 192.
Les 262 Mo du fichier ONNX se téléchargent dans votre onglet et c'est votre carte graphique qui transpire ensuite, avec le WebGPU. Il y a donc zéro serveur derrière, exactement comme l'agent Gemma que je vous montrais en avril .
Je l'ai testé chez moi sur mon Mac Studio dans Firefox et je suis à 2,5 frames par seconde, ce qui représente 405 millisecondes de génération par image sur mon GPU Apple. Donc autant vous prévenir qu'à ce rythme-là c'est injouable. Vous appuyez sur une touche, le monde se redessine mollement, et vous conduisez comme dans un rêve où vos jambes ne répondent plus... Mais ça reste dingue quand même !
Sharma annonce que sur les MacBook M récents on peut obtenir environ 10 images par seconde, et sur des GPU ça devrait approcher le temps réel, 15 à 20 images par seconde. L'écart avec ma mesure vient sûrement du fait que je suis en train de compiler tout un tas de conneries au moment où j'écris cet article... donc testez plutôt que de me croire sur parole. Et si vous êtes sur mobile, les petits boutons sous l'écran servent de contrôles tactiles, si vous avez de la patience.
Aucune de ces images n'existe dans un fichier de jeu. Le chrono en haut à droite est illisible parce que le modèle le repeint à chaque frame.
Le plus marrant, c'est tout ce qu'il vous dessine en plus de la route. Il régénère aussi l'interface : le compteur de tours, la minimap en bas à gauche, les petites têtes de Tux empilées sur le côté, le chrono en haut à droite. Sauf qu'il ne sait pas ce qu'est un chrono. Du coup les chiffres bavent, se réécrivent tout seuls, vous annoncent un tour 1 sur 300 ! Ce modèle ne compte pas le temps écoulé, il peint simplement des pixels qui ressemblent à du temps. Et pendant ce temps-là le décor fond carrément en haut de l'image, avec des bouts de falaise qui coulent dans le ciel.
Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé thunderbird-patch-review .
Il s'agit d'une extension pour Thunderbird qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.
Ensuite, si la série des patchs vous convient, vous pouvez tous les approuver directement sur votre dépôt local avec la commande git-am sans jamais avoir à quitter votre client mail.
Pour lancer Git, l'extension utilise une API expérimentale maison qui embarque tout le nécessaire dans son paquet sans host de messagerie native à installer séparément. Ça fait un truc en moins à configurer et l'addon vérifie que tout est OK dans un worktree jetable, avant de valider la review.
Comme ça, s'il y a un conflit, le bouton Apply se grise et les erreurs remontent dans l'interface pour que vous puissiez toutes les revoir une par une et faire un retour propre à l'auteur.
Cet add-on a été vibe-codé avec GLM 5.2 et construit pour répondre aux besoins de son équipe. Il hésitait sincèrement à le partager parce que le monde n'est pas encore prêt pour le Vibe Coding, mais il explique sur son site qu'il y avait un sérieux manque d'outils dans l'écosystème pour pouvoir travailler sur des revues de patch directement dans son client mail.
Donc tant pis, yolo, il l'a publié quand même et je pense que ça devrait vous intéresser. Comme quoi faire bosser un agent pour soi n'oblige pas à le planquer.
Maintenant, les patches qui arrivent en pièce jointe ne sont pas encore gérés, les mails en HTML seul non plus, et la collecte d'une série ne cherche que dans le dossier du message ouvert. De plus, l'add-on n'est pas encore publié sur le store Thunderbird, donc vous devrez le packager vous-même en .xpi depuis la racine du projet :
git clone git://mccd.space/thunderbird-patch-review
cd extension && zip -qrX ../patch-review.xpi .
Ensuite, vous chargez le fichier obtenu via le menu engrenage du gestionnaire de modules complémentaires (Installer un module depuis un fichier) et c'est réglé ! Rien de méchant si vous avez déjà bidouillé des extensions Thunderbird, genre Send Later pour planifier vos envois dont je vous parlais il y a un petit moment maintenant.
Voilà, si vous faites déjà du git par email, ça vaut le détour. Le code est en EUPL 1.2, et tout se passe ensuite sur la mailing list de Marc.
NVIDIA a débranché GameStream, son système maison pour envoyer les jeux de votre PC vers une Shield ou un laptop. Sauf que le protocole, lui, n'est pas mort : Moonlight , le client open source qui le réimplémente, tourne toujours sur Windows, macOS, Linux, Steam Link, Raspberry Pi 4, Apple TV et Xbox, et même sur des Switch et des Vita en homebrew.
Et surtout, Hans Gaiser bricole depuis début 2024 une pièce qui manquait côté serveur, Moonshine , qui commence à être sérieusement utilisable.
Moonlight n'étant qu'un client, il affiche l'image et renvoie votre clavier, votre souris et votre manette. Derrière, il faut donc forcément une machine qui capture le jeu et qui encode la vidéo en temps réel.
Bref, comme je vous le disais, depuis que NVIDIA a rangé GameStream au placard début 2023, ce rôle revient à des serveurs communautaires. Le seul que la FAQ Moonlight recommande, c'est Sunshine , du collectif LizardByte. C'est codé en C++ sous licence GPL-3 et ça tourne sous Windows, Linux, macOS et FreeBSD. Sauf que Sunshine capture une session de bureau existante ce qui veut dire que sur une machine sans écran, il faut composer avec ça, et c'est de là que vient toute la littérature sur les dongles HDMI factices et autres écrans virtuels...
Alors que Moonshine, lui, est codé en Rust et prend un autre chemin. En fait, chaque session de streaming tourne dans son propre environnement isolé, qui est totalement séparé de votre bureau. Du coup, vous n'avez plus besoin de session active du tout... Une simple tour sans écran fera parfaitement le boulot.
Voilà, si vous avez une machine Linux qui dort dans votre placard avec un GPU dedans, ça peut vous permettre de lancer Moonlight depuis votre canapé à distance, et c'est le serveur qui gérera la session rien que pour vous.
Après, c'est du Linux uniquement, testé sur Arch même si ça remonte que ça tourne aussi sur d'autres distribs, avec systemd obligatoire pour lancer et gérer tout ce qui est processus. Et du côté du GPU, il vous faudra de l'encodage vidéo Vulkan, donc, vous l'aurez compris, une Nvidia RTX ou une AMD RDNA2 ou plus récente, voire une Intel Arc pour les plus motivés.
Voilà, toutes vos vieilles GTX resteront sur le banc de touches... Sans oublier que vous aurez besoin du client Moonlight en version 6.0.0 minimum et que la compatibilité avec les portages non officiels n'est pas garantie.
Les codecs supportés, c'est du H.264, H.265 et AV1, avec du HDR en 10 bits. L'AV1 est marqué expérimental et Hans Gaiser prévient lui-même qu'il fait gonfler la taille des images au fil du temps sur les cartes NVIDIA. Sauf que c'est réglé depuis : NVIDIA a sorti le correctif dans son pilote Vulkan beta 595.44.3.0 et Hans Gaiser a confirmé début avril, mesures à l'appui, que la qualité était revenue à la normale. Son README, lui, n'a pas suivi et vous conseille encore de rester en H.264 ou H.265. Donc si l'AV1 vous tente, prévoyez le pilote Vulkan beta, pas celui de votre distrib.
Notez aussi que Moonshine n'est pas conçu pour être utilisé sur des réseaux publics puisque le protocole GameStream sous-jacent a des limites qui font que le trafic n'est pas entièrement chiffré au niveau applicatif. Donc, si vous vous y mettez, n'exposez jamais les ports de Moonshine directement sur internet. Préférez passer par Tailscale ou un WireGuard par exemple.
Bref, Moonlight, Sunshine, Moonshine... si comme moi, vous vous emmêlez dans les noms, c'est parfaitement normal. N'empêche que c'est un super truc, encore en dev, certes, mais ça promet pour le futur...
Balaji Bikshandi avait un rêve ! Il voulait booter sa machine directement sur un LLM sans avoir à passer par le moindre environnement de bureau ! Et il y est parvenu avec son outil BMASS , qui s'installe sur une clé USB de 8 Go, et qui embarque Alpine Linux, llama.cpp et un modèle Qwen3 0.6B évidemment quantisé.
Vous allumez l'ordi portable, Alpine démarre depuis la clé et vous tombez sur un prompt BMASS>. Et voilà à partir de là, vous pouvez causer à votre ordinateur en langage naturel. Ensuite, quand vous demandez à BMASS de faire des trucs, celui-ci injecte la commande qui va bien dans une balise
Operator: Which operating system is this?
Assistant: <shell>cat /etc/os-release</shell>
Tout le code de BMASS tient en 399 lignes de Python, et nécessite de faire tourner un llama-server en background sur le port 8080 avec 2048 tokens de contexte et 2 threads. Et ensuite lui fait le pont entre le modèle et le shell. Y'a rien de sorcier donc mais comme ça tourne sur du CPU, que c'est hors-ligne, et que ça peut se mettre sur des vieilles machines, c'est plutôt cool...
Voilà je vous laisse avec la vidéo que Balaji a filmée, ça montre le démarrage complet de son IA bootable :
Ah et petite subtilité qui va vous plaire, le code de BMASS contient une regex baptisée FALSE_EXECUTION_CLAIM dont le boulot est de détecter quand le modèle prétend avoir exécuté une commande alors qu'il n'a rien lancé du tout. Le runtime lui renvoie alors une correction pour lui dire qu'aucune commande n'a été exécutée lors de ce tour. Faut dire que la 0.6B de Qwen hallucine tellement parfois, qu'il lui fallait obligatoirement un garde-fou.
Donc, voilà, côté sécu c'est super léger... y'a juste une regex qui bloque les sudo, doas, pkexec et autres su, mais c'est tout. Pas de conteneur, encore moins de namespace et surtout pas de liste blanche, donc si vous vous lancez, ce sera à déployer uniquement pour rigoler sur une vieille machine sans importance, parce que si demain, le modèle décide de lancer un rm -rf, faudra pas venir chialer ^^.
Petit service au passage si vous voulez tester, la doc d'installation vous fait copier le prompt système dans /opt/bmass/config/system-prompt.txt, sauf que le launcher le cherche dans /opt/bmass/system-prompt.txt.
Dans le genre modèle local qui tient dans presque rien, j'en ai parlé avec Llamafile qui fait tourner un LLM depuis un fichier unique. Et si les bidouilles minimalistes vous amusent, il y a aussi ce mini-PC Linux piloté entièrement en morse .
Perso, je doute que ça serve à grand-chose. Mais le concept est marrant !
Maik Klotz, un développeur allemand, a sorti une app menu bar qui repeint votre Mac aux couleurs de Snow Leopard, System 6, Windows 98 ou encore BeOS. Elle s'appelle RetroMac et elle ne touche pas une ligne de votre système, donc pas de risques de tout casser.
Le catalogue des thèmes couvre à peu près tout ce qui nous a fait vieillir : le System 6 de 1988 en noir et blanc 1 bit avec ses barres de titre à rayures et sa police Chicago, Mac OS 9 et son Control Strip, l'Aqua bleu bonbon de 2001, le Snow Leopard de 2009, Windows 98, Windows XP et même BeOS. Chaque thème embarque son dock d'époque, ses curseurs, ses icônes et son écran de démarrage animé.
Les économiseurs d'écran sont de la partie aussi, un par thème avec 3D Pipes, FlowerBox, Flying Toasters, Flurry. Si vous ne voyez pas de quoi je parle, c'est que vous êtes trop jeune. Vous en avez de la chance !!
Par-dessus, y'a une trentaine de shaders qui simulent les vieilles dalles : CRT Royal, Sony Trinity, NTSC Composite, VHS, VCR, Game Boy. Vous pouvez les balancer en plein écran, sur un seul moniteur si vous en avez plusieurs, ou sur une seule fenêtre.
Le shader CRT Royal, scanlines et bombement d'écran compris
Le truc auquel je ne m'attendais pas, c'est la caméra virtuelle. RetroMac s'expose également comme une webcam système donc vous débarquez en réunion Zoom, Meet ou Teams avec une tête de VHS mal rembobinée. Effet garanti !! lol.
Et comme RetroMac se contente de peindre un shader par-dessus ce qui est déjà à l'écran, vos apps, vos fichiers et vos réglages système restent totalement intacts, donc c'est sans risques.
Après les thèmes, eux, modifient bel et bien des réglages du dock, de la barre de menus, des icônes du bureau et du fond d'écran, mais c'est rien d'irréversible. Et surtout RetroMac embarque un Health check et un bouton de restauration qui remet tout en place en un clic
Et le rythme de dev est assez dingue puisque le dépôt date du 22 mai et il en est déjà à sa dix-neuvième version. La 2.2, sortie il y a deux jours, ajoute Warcraft I et II qui tournent nativement sur le moteur open source Stratagus , avec le shader CRT qui se pose par-dessus le jeu.
Après le reste, c'est carré de chez Carré, il y a un binaire universel Intel et Apple Silicon. Et côté tarifs, tous les thèmes, tous les curseurs et une vingtaine de shaders sont gratuits. Après il y a un mode pro qui coûtera 8,88 euros une fois pour toutes et ajoutera le shader webcam et le fond d'écran animé.
Autrement, il n'y a pas d'abonnement. Et les sources sont sous GitHub sous licence GPL 3.0 avec même les fonctions payantes dedans. Donc c'est plutôt très ouvert mais pas encore complètement libre.
J'avais déjà parlé de ShaderBeam pour retrouver la netteté du CRT sur un écran moderne, d' Infinite Mac pour glisser un vieux Mac dans une page web, et du Virtual OS Museum et ses 1700 systèmes mais RetroMac la joue autrement, puisqu'il ne vous colle pas un vieil OS dans une fenêtre, mais déguise celui dont vous vous servez ;).
Voilà, si l'idée de faire booter votre M4 comme un Mac de 2001 vous amuse, c'est par ici . Et le jour où ça vous saoule, un clic et tout revient en place.
Votre CV en ligne sur le site de France Travail, un métier en tension, un rendez-vous raté il y a 2 ans ? Ce sont 3 des 26 variables qu'un algorithme épluche pour décider si votre dossier part au contrôle. Voilà où on en est.
La Quadrature du Net a publié aujourd'hui, avec la cellule investigation de Radio France, le document interne qui le décrit, présenté au comité d'éthique IA de France Travail le 10 décembre dernier. Son petit nom, c'est "Ciblage du Contrôle de la Recherche d'Emploi" et sous ce titre pompeux, se trouve un arbre de décision entraîné sur 60 000 contrôles passés, qui vous range dans un profil "suspect" ou "non suspect". Les suspects atterrissent alors sur une liste de gens à contrôler en priorité.
Pour l'instant, il tourne sur les ruptures conventionnelles, via 2 campagnes de 7 000 tests environ, mais France Travail veut déjà "étendre l'utilisation du modèle à d'autres publics" et "transmettre chaque mois des listes de contrôle ciblés".
On a donc la liste des 26 variables, mais pas les règles. Personne ne sait donc comment l'arbre les combine, ni à partir de quel seuil vous basculez du côté "suspect". La Quadrature le reconnaît elle-même : "nous ne sommes donc pas en mesure de déterminer, via des simulations, quelles populations sont les plus ciblées par cet outil". Ils ont demandé le code source mais n'y croient pas trop...
Du coup personne ne peut vérifier si le truc discrimine ou pas ! Parmi les variables retenues, y'a la présence d'une activité non salariée, exactement le critère que la CNAF utilise dans son algorithme de scoring pour dégrader la note des gens en emploi précaire, donc si vous bricolez 3 heures en micro-entreprise pour arrondir vos fins de mois, bah ça se paye niveau algo, apparemment :-((. Fallait pas se bouger.
En mai 2025, le directeur général de France Travail déclarait à la Commission d'accès aux documents administratifs "qu'aucun algorithme n'est utilisé dans le cadre du "CRE rénové"", en réponse à une saisine de journalistes de Cash Investigation et voilà que quelques mois plus tard, en interne, on présentait au comité d'éthique cet algorithme "Ciblage du Contrôle de la Recherche d'Emploi".
Alors c'est vrai, les deux formulations ne désignent pas EXACTEMENT le même bout de la chaîne, ok mais apparemment on n'a pas la même définition de ce qu'est une IA "éthique" et "transparente". À mon avis, leur charte est sérieusement à revoir. Dans le document trouvé par la Quadrature, au paragraphe "Pourquoi recourir à l'IA ?", la réponse c'est que ça permettrait une "suppression des a priori" en proposant "des dossiers à contrôler sur la base de critères objectifs" sauf que choisir qui on contrôle, c'est une décision politique, et pas un problème de tri.
La Quadrature parle de "* la transformation d'un problème politique ... en un problème purement technique*", et perso je vois surtout que plus personne n'a à signer la décision maintenant puisque c'est l'IA magique qui décide tout... C'est facile la vie.
Et pendant ce temps, c'est une machine à contrôler les gens qui monte fortement en régime avec 200 000 contrôles en 2017, 730 000 en 2025, et un objectif gouvernemental de 1,5 million en 2027, annoncé par Gabriel Attal.
Avec les allocataires du RSA, inscrits d'office à France Travail depuis le 1er janvier 2025, ça fait plus de 6 millions de personnes potentiellement profilées chaque mois, et vous en faites peut-être partie sans le savoir. Le contrôle lui-même reste mené par un agent (pas une IA, un vrai humain, je précise parce que ce mot agent est trompeur de nos jours ^^), mais c'est la machine qui désigne qui passe sur le grill !
Et l'opacité n'est pas un accident de parcours puisque France Travail a refusé de communiquer la moindre info sur MatchFt, l'IA qui vous envoie des SMS d'offres d'emploi, et sur ChatFt, celle déployée auprès des conseillers. Même pas la documentation technique ou l'analyse d'impact. Pire, face à la CADA , l'institution "n'a même pas pris la peine de motiver sa décision". Même pas un courrier ! Voilà, pour la transparence, on repassera...
C'est pour moi, le même délire que le blocage administratif sans juge ou la reconnaissance faciale en libre-service pour la police dont je vous parlais. C'est une décision unilatérale qui vous tombe dessus, sans explication, et sans recours facile à mettre en œuvre. Sauf qu'ici c'est votre allocation chômage qui est sur la table... J'avais déjà creusé ce que l'IA fait à nos institutions , vous pouvez y jeter un œil.
Bref, La Quadrature appelle à l'abandon de l'algorithme et le document complet est en ligne, donc allez-y jeter un œil.
Hugging Face vient de raconter sur son site comment son infra de production s'est fait défoncer par un essaim d'agents IA autonomes. Le point de départ, c'est un dataset piégé déposé sur la plateforme qui exploitait deux chemins d'exécution de code dans le pipeline qui traite les datasets. Ajoutez à ça un loader qui accepte du code distant et une injection de template dans une config, et hop, on obtient du code qui tourne sur un worker maison.
À partir de là, l'attaquant est monté en accès node-level, a ramassé des credentials cloud et cluster, puis s'est promené latéralement dans plusieurs clusters internes. Le tout durant tout un week-end, tranquillou ! Hugging Face parle de "plusieurs milliers d'actions individuelles à travers un essaim de sandboxes éphémères, avec un command-and-control auto-migrant hébergé sur des services publics". Et en plus, ils ne savent toujours pas quel modèle pilotait le truc !
Ce qui a été touché, c'est donc un ensemble limité de datasets internes et plusieurs credentials utilisés par leurs services. Côté public, rien n'a bougé sur les modèles, les datasets et les Spaces, et leur supply chain logicielle est saine. Nuance importante quand même, ils disent n'avoir trouvé aucune trace d'altération, pas que rien n'a été altéré. Ils cherchent encore si des données partenaires ou clients ont morflé. Les concernés seront prévenus directement.
La divulgation publiée par Hugging Face le 16 juillet 2026.
Pour analyser les logs de l'attaque, Hugging Face a d'abord fait ce que vous auriez fait, c'est à dire envoyer tout ça à des modèles frontier derrière des API commerciales. Refus ! Les garde-fous se déclenchaient sur les vraies commandes d'attaque, les payloads d'exploit et les artefacts de command-and-control, sans savoir faire la différence entre un attaquant et une équipe de réponse à incident.
Du coup ils se sont rabattus sur GLM 5.2, le modèle open-weight de Z.ai, tournant sur leur propre infra. C'est celui dont je vous parlais fin juin , le premier modèle open source qui m'a vraiment convaincu.
Et voici leur conclusion : "*Nous ne savons pas quel modèle alimentait les agents de l'attaquant, un modèle hébergé jailbreaké ou un open-weight sans restrictions. Dans les deux cas, l'attaquant n'était contraint par aucune politique d'usage, alors que notre propre travail forensique était bloqué par les garde-fous des modèles hébergés que nous avions essayés en premier. *"
La leçon qu'ils en tirent, c'est d'avoir un modèle capable comme GLM 5.2, validé, et prêt à tourner sur sa propre infra avant l'incident. Ça évite le blocage par garde-fous d'OpenAI ou Anthropic et surtout ça évite surtout que les données de l'attaquant et vos credentials partent se balader chez un tiers.
Le versant moins déprimant, c'est que l'IA a aussi bossé côté défense. Leur détection d'anomalies fait du triage LLM sur la télémétrie pour séparer le vrai signal du bruit quotidien, et des agents d'analyse ont reconstitué toute la timeline à partir de plus de 17 000 événements enregistrés. En heures, là où ça prendrait des jours à la main.
Côté ménage, ils ont surtout viré le point d'ancrage de l'attaquant, reconstruit les nœuds compromis, révoqué et tourné les credentials et tokens concernés avec une rotation plus large des secrets par précaution, déployé des garde-fous et des contrôles d'admission plus stricts sur les clusters, et amélioré la détection pour alerter les équipes en quelques minutes, 24h/24. Maintenant, si vous avez un compte là-bas, ils vous recommandent de faire tourner vos tokens d'accès et de jeter un œil à l'activité récente.
Ce genre d'histoire commence à devenir une vraie série... j'en parlais avec GitLost où un seul mot glissé au bon endroit suffisait parfois à faire cracher ses dépôts privés à l'IA de GitHub.
Bref, allez renouveller vos tokens Hugging Face et si votre pipeline exécute du code venu d'ailleurs, c'est le moment de regarder ça de plus près.
Pi-hole sur un Raspberry Pi, c'est cool, mais ça vous coûte quand même quelques dizaines d'euros (lien affilié) et ça squatte une prise en permanence. C'est pourquoi M-Abozaid a fait tenir la même chose dans une clé ESP32-C3 à pas cher (lien affilié). Son firmware bloque ainsi 537 000 domaines de pub en utilisant à peine 50 Ko de RAM, et est capable de répondre à une requête bloquée en 10 millisecondes.
Maintenant que j'ai toute votre attention, je vais vous expliquer comment ça marche. En fait, un Pi-hole classique charge toute sa liste de blocage en RAM, sauf que l'ESP32 lui, comme il n'a que quelques centaines de Ko de mémoire vive et pas de PSRAM, il est donc techniquement impossible d'y caser un demi-million de domaines comme ça simplement. Du coup notre cher développeur a dû ruser en hashant chacun des domaines bloqués à max 5 octets chacun (40 bits max).
Tous ces hashes sont ensuite triés une fois pour toutes, puis gravés directement dans la flash de la puce (4 Mo suffisent). Puis quand une requête DNS arrive, le firmware hashe le domaine demandé et fait une recherche par dichotomie dans la flash. Environ 18 lectures suffisent pour trancher parmi les 537 000 entrées, d'où les fameux 10 ms. Et la RAM ne sert jamais à stocker la liste, mais juste à faire tourner le bazar réseau.
Et là où c'est vraiment malin, c'est que 40 bits de hash restent quasi sans collision. Il n'en a eu aucune jusqu'à 141 000 domaines, et une seule à 537 000 donc autant dire rien du tout !
Après il y a peu de chances que ça remplace Pihole, en tout cas pour le moment, parce qu'il n'y a pas de serveur DHCP. Et activer les mises à jour OTA du firmware demande d'avoir deux partitions, du coup la capacité de l'ESP 32 tombe à 250 000 domaines.
Après le dashboard est plutôt sympa, ça tourne en mDNS sur l'adresse c3adblock.local, avec des compteurs de blocage par client, le bannissement d'un appareil et la possibilité d'ajouter vos propres noms de domaines à bloquer.
Voilà moi je vois vraiment ça comme un espèce de résolveur de secours plutôt qu'un vrai remplaçant pour Pi-hole. Vous le placez derrière votre serveur DNS principal et le jour où celui-ci est en panne, la petite clé prendra le relais pour pas cher. En plus comme on le voit dans la vidéo, ça peut s'alimenter sur le port USB de n'importe quel routeur, donc c'est pratique.
C'est totalement open source sous licence MIT et c'est livré avec un script python qui permet de construire la table des hashes à partir des listes StevenBlack et Hagezi. Pour plus tard, le développeur prévoit un Bloomfilter en mémoire RAM pour zapper la lecture flash sur les 99 % des requêtes qui ne matchent aucun domaine et puis le serveur DHCP dont je vous parlais.
Si les DNS auto-hébergés vous parlent, je vous ai déjà présenté Technitium qui remplace carrément Pi-hole, Unbound et BIND . Et pour les bidouilles ESP32 à quelques euros, y'en a plein, genre celle qui remplace le Touch ID d'Apple .
Bref, un demi-million de domaines de pub bloqués par une puce plus petite qu'une clé USB c'est bien joué !! Le repo est sur GitHub si ça vous tente.
Pour une raison que je ne m'explique pas, parfois quand j'upload des vidéos sur mon WordPress, celles-ci ne fonctionnent pas correctement une fois l'article publié. Je pense que c'est parce qu'elles sont mal encodées et que par conséquent le navigateur ne sait pas les lire. Pour remédier à ça, je faisais donc un petit coup de FFmpeg , mais ouvrir le terminal et recoller les mêmes paramètres à chaque fois, c'était un peu lourdingue.
Alors j'ai repris un peu l'idée
Magicbrake
, mais en version automatique gérée directement dans le Finder de macOS. Un clic droit sur une ou plusieurs vidéos, et hop, le MP4 apparaît à côté de l'original sous le nom compressed_nom-original.mp4 et la source est préservée.
Je vous ai tout mis dans cette archive ZIP qui réunit le script, l'installateur, le désinstallateur et le mode d'emploi. Tout est sous licence MIT , donc modifiable et redistribuable.
Le seul prérequis est FFmpeg. Installez-le d'abord via Homebrew si nécessaire, puis lancez ceci dans le Terminal :
brew install ffmpeg
Décompressez l'archive. Dans le Terminal, tapez cd avec une espace, glissez le dossier compresser-video-macos dans la fenêtre et validez avec Entrée. Lancez ensuite :
chmod +x *.sh
./install.sh
L'installateur copie le convertisseur dans votre bibliothèque utilisateur et crée une Action rapide Automator dans le Finder. Du coup, aucune app de conversion à garder ouverte ni réglage à refaire.
L'Action rapide installée dans Automator, avec son unique script shell
Le hic, c'est que l'Action peut ne pas apparaître tout de suite. Relancez le Finder, ouvrez Actions rapides et cliquez sur Personnaliser… tout en bas. Activez ensuite Compresser la vidéo dans les
extensions du Finder
. Elle reste aussi disponible dans Services. Et si votre clic droit est désactivé, faites un Ctrl + clic sur le fichier.
Sélectionnez une vidéo, ou carrément plusieurs, puis faites clic droit > Actions rapides > Compresser la vidéo. La conversion tourne en arrière-plan et, pour les vidéos un peu longues, un pourcentage d'avancement s'affiche dans la barre des menus en haut de l'écran. Une notification vous prévient quand le nouveau MP4 est prêt, dans le même dossier que sa source.
Le script ajoute compressed_ devant le nom, remplace l'extension par .mp4 et ne touche pas à l'original. Si ce nom existe déjà, il ajoute -2, puis -3. Pas d'écrasement !
Si l'Action ne marche pas, le détail est dans ~/Library/Logs/Compresser-la-video.log. Depuis le dossier du kit, lancez ./compress.sh "/chemin/vers/video.mov" pour voir FFmpeg pédaler. Si un fichier d'un lot échoue, les conversions réussies restent à côté de leurs sources.
La sortie est un MP4 en H.264, avec une image plafonnée à 1080p, une cadence moyenne limitée à 30 images par seconde et une piste AAC stéréo si la source contient du son. J'ai choisi un CRF de 22 car je voulais un compromis simple entre poids et qualité. Une petite vidéo n'est pas agrandie, et faststart place l'index MP4 au début pour accélérer la lecture web.
J'ai testé du 60 i/s, du 24 i/s et une définition impaire. La première est tombée à 30, la deuxième a gardé ses 24 et la troisième a reçu des dimensions paires pour libx264 et yuv420p. Finalement, ça marche !
Perso, je garde ce réglage. Après pour mieux maîtriser la taille finale, utilisez HandBrake avec un débit moyen et deux passes .
Par contre, ce bouton vise les vidéos SDR courantes à partager et ne garantit pas une sortie plus petite. Il ne conserve que la première piste vidéo et la première piste audio. Attention, les sous-titres, les pistes supplémentaires et le HDR demanderont un réglage sur mesure.
Et si ça ne vous convient pas, pour retirer l'Action rapide, retournez dans le dossier du kit et lancez ./uninstall.sh.
Bref, vous avez maintenant la compression vidéo directement sous le clic droit... En tout cas, même si le besoin est niche, moi ça va me servir.
Amusez-vous bien !