Depuis ce week-end, bonne nouvelle les zamis, puisque ce bon vieux ffmpeg sait maintenant fabriquer des images qui n'ont jamais été filmées. Oui oui ! Et ça c'est possible grâce à un filtre qui s'appelle fruc_vulkan, qui permet de calculer le mouvement entre deux images grâce au bloc dédié des GeForce RTX, pour ensuite synthétiser ce qui manque entre les deux. Grâce à ça, un 24 images par seconde ressort sans souci en version 60 images par seconde.

La cadence de sortie se paramètre, donc vous pouvez aussi faire du 25 vers du 50, du 30 vers 60, ou n'importe quelle valeur intermédiaire. C'est donc beaucoup plus souple que le filtre équivalent côté AMD, frc_amf, qui ne sait que doubler la fréquence et ne fonctionner qu'en DirectX...

Fabriquer ce genre d'images intercalaires n'a rien de neuf, cela dit... L'outil RIFE convertissait déjà du 24 fps en 96 en 2020. Mais ce qui change ici, c'est qu'il n'y a plus de chaîne externe, plus d'aller-retour par des milliers de PNG, puisque tout tient dans le graphe de filtres, entre le décodage et l'encodage.

Le filtre logiciel historique de ffmpeg, minterpolate, existe pourtant depuis des années mais c'était loin d'être du temps réel. Alors que là, le vrai gain avec cette nouvelle feature, c'est qu'on passe en full temps réel. Ça veut dire que sur un catalogue à réencoder, l'interpolation cesse d'être l'élément qui bloque toute la chaîne de conversion.

Pour l'essayer il vous faut une RTX 30 ou plus récente. Il faut aussi compiler une version de développement car ce filtre est arrivé après la sortie de ffmpeg 9.0, ce qui veut dire que pour le moment, il n'est dans aucune release et ne sera dans aucun paquet avant la prochaine.

La commande suit ensuite le motif habituel des filtres Vulkan, qui veulent les images en mémoire GPU :

ffmpeg -init_hw_device vulkan=vk:0 -filter_hw_device vk -i entree.mp4 -vf "format=yuv420p,hwupload,fruc_vulkan=fps=60,hwdownload,format=yuv420p" sortie.mp4

L'auteur du filtre prévient quand même qu'en 2160p24, les réglages par défaut ne suivront pas en temps réel et qu'il faudra alors descendre la qualité d'estimation du mouvement. Ça s'écrit comme ceci :

fruc_vulkan=fps=60:perf=medium:grid=2

En traitement par lots maintenant, la question ne se pose pas, c'est juste plus lent.

Maintenant, les pros de l'encodage, redescendez de votre chaise parce que j'ai quand même quelques mauvaises nouvelles... Tout d'abord, on n'a aucune stat indépendante sur le débit ou la qualité. Et il y a aussi un défaut que l'auteur du patch documente lui-même... En fait, dans les zones sans texture, le moteur invente un mouvement faux mais cohérent, qui laisse des "fantômes" autour des objets. La parade existe heureusement, mais c'est une heuristique, qui demande quelques réglages à la main sur des échantillons.

Et il y a aussi un coût qu'on oublie... Car doubler la cadence, c'est donner deux fois plus d'images à avaler à l'encodeur, donc, il y a toujours une espèce de goulot d'étranglement. Et puis après il y a le rendu... un film de cinéma en 24 images par seconde qu'on monte à 60 prend immédiatement un aspect téléfilm que les cinéastes détestent !! Imaginez l'Odyssée de Nolan avec l'aspect visuel de Plus Belle La Vie... Ahahaha. Après sur de l'animation ou un ralenti, ça se défend bien sûr mais sur du cinéma, c'est un choix à prendre et pas une amélioration. En tout cas, c'est mon avis.

Ah et dernier point, parce que la confusion est déjà partout dans les commentaires sur le net : Tout ça se passe à l'encodage ! Je répète : A L'ENCODAGE ! Le fichier qui sort de ffmpeg est une vidéo NORMALE. Absolument personne n'aura besoin d'une carte graphique GeForce pour la regarder ! OK ? 😘

Source : Phoronix

Hier, je suis tombé sur ce tweet :

Kuber, un développeur de 19 ans a demandé à Claude Code, de lui pondre un pilote pour sa vieille imprimante pour macOS. Et visiblement, ça a intéressé pas mal de monde puisque le tweet a fait +3 millions de vues.

Il a ensuite publié le dépôt sur Github et la transcription complète de la session. Et ce que ça raconte c'est surtout un bras de fer avec macOS, et un montage bidouillesque au possible qui finit par tenir sur une machine virtuelle Linux et un daemon root.

Pour la petite histoire, son imprimante est une HP Laser 1008a. C'est en réalité une Samsung rebrandée car HP a racheté la division impression de Samsung , il y a une dizaine d'années. Et ces machines parlent un langage un peu niche qui est le SPL3. C'est un langage maison qui n'est ni du PostScript ni du PCL standard. Et comme vous vous en doutez, HP n'a jamais sorti de pilote macOS pour cette gamme. Donc officiellement, cette imprimante ne peut pas imprimer depuis un Mac.

La mission a donc consisté à recompiler SpliX, un pilote libre qui parle le SPL3 et à se battre avec macOS pour qu'il puisse causer via l'interface USB de l'imprimante déclarée en IPP-over-USB. Il a fallu ensuite ruser en mettant en place une VM Linux afin de faire tourner h24 un codec de HP uniquement dispo sous Linux. Et voilà ! La file d'impression envoie le travail sur un port local, un daemon root le récupère, le fait passer par le codec dans cette VM, et écrit le résultat directement sur l'USB.

Bref, ça marche et ça imprime maintenant depuis n'importe quelle application.

Alors vous l'aurez compris, ce n'est pas vraiment un dev de pilote pour macOS mais plutôt une espèce d'assemblage de différents éléments pour la plupart libres, afin de réussir à imprimer sous macOS avec ce modèle d'imprimante. Mais ce qui est intéressant, c'est que le mainteneur de SpliX a débarqué sur le dépôt de Kuber avec une archive de fichiers de test et une série de questions. Cela veut dire que si lui et Kuber trouvent l'octet qui diffère, la VM Linux et le daemon root vont disparaître et il ne restera plus qu'un paquet tout ce qu'il y a de plus classique à installer.

Voilà c'est finalement la seule partie de l'histoire où on répare vraiment quelque chose. Mais ça reste quand même une belle histoire où l'IA permet de s'affranchir des limites techniques imposées par les fabricants et éditeurs de logiciels. Et ça, moi j'adore !

Source : le fil de Kuber sur X , avec la transcription intégrale de la session et le dépôt du projet .

Allez, on va faire un jeu. Cherchez un disque dur externe sur Amazon et regardez où pointe le premier lien de la page. Bingo, ça part sur une adresse en /sspa/click, autrement dit un emplacement publicitaire. Et c'est pas le mieux noté, c'est pas le moins cher, non, c'est juste celui qui a payé le plus pour être là.

Et moi, ce qui me saoule vraiment, c'est que les filtres n'y peuvent rien.

Pour remédier à cela il faut sortir l'artillerie. J'ai d'abord pensé à faire un filtre uBlock Origin, puis à me coder une extension Firefox, avant de me rappeler que Tampermonkey tournait déjà dans mon navigateur.

Direction le repo Greasy Fork, donc, où traîne un script qui fait exactement ça . Une cinquantaine de règles CSS, qui dégagent du DOM les résultats sponsorisés de la recherche, les carrousels promo, les encarts publicitaires de la fiche produit, l'upsell Prime et les bannières de marque.

On passe ainsi de ça :

À ça :

Et ça fonctionne super sur toutes les versions d'Amazon, y compris Amazon.fr.

Trois réglages attendent dans le menu du gestionnaire de scripts. Un compteur qui affiche en bas de page ce qui a été retiré et pourquoi, une journalisation console pour les curieux, et une option qui redirige les pages de navigation vers la vraie liste de résultats.

Attention quand même à ce qui saute en plus des pubs. Le bloc "Les gens qui ont acheté ça, ont aussi acheté ça". Le script s'attaque aussi à Rufus, l'assistant d'achat maison et côté installation, il vous faut Tampermonkey, Violentmonkey ou Greasemonkey. Sur Firefox, ça s'arrête là. Par contre sur Chrome, depuis la version 138, il faut en plus activer un switch "Allow User Scripts" sur la fiche de l'extension, coupé par défaut sur toute extension fraîchement installée.

Voilà, j'espère que ça vous aidera à avoir un Amazon un peu plus propre. Maintenant, n'oubliez pas, Amazon, c'est le mal, donc si vous avez les moyens de payer 2x plus cher la même chose et que vous aimez passer votre vie dans les transports ou en bagnole à faire une espèce de chasse au trésor à travers toute la ville, pour trouver le produit qu'il vous faut, le mieux reste encore et toujours d'acheter dans des magasins physiques. Lol.

Ce mois-ci, je suis en mode déménagement / vidage de cartons / montage de meubles Ikea et bien sûr, j'en profite pour réinstaller mon matos... Mon système d'alarme, mes caméras et un peu de domotique.

Sauf que la domotique, c'est pas mon kif car même si j'aime l'idée d'avoir des automatisations chez moi, ça fonctionne un moment, puis après ça ne fonctionne plus, souvent parce que les Raspberry Pi passent leur temps à corrompre les cartes SD... Puis surtout, je manque de temps pour me prendre la tête à régler des scénarios au poil de cul.

Mais là, c'est aussi un peu les vacances et y'a plusieurs paramètres qui ont changé. Déjà la nouvelle maison est plus petite. J'ai aussi un mini PC à disposition qui ne faisait pas grand chose. J'ai également une caisse de matos divers et variés (Zigbee / Zwave et autre) qui prend la poussière. Et puis les nouveautés dans ma vie, c'est bien sûr l'IA et Alexa.

Je me suis donc chauffé un peu, et je vais vous raconter ce que j'ai mis en place ces derniers temps.

Étape 1 : le mini PC qui dormait dans un carton

Le point de départ, c'est ce mini PC. Un NiPoGi Pinova P1 (lien affilié) que j'avais acheté en 2023, un Ryzen 3 4300U avec 16 Go de RAM et 1 To de SSD, qui n'avait jamais vraiment trouvé sa vocation. Complètement surdimensionné pour de la domotique, vous vous en doutez, et c'est exactement pour ça qu'il est parfait.

Parce que le vrai sujet, c'est pas la puissance, c'est le stockage. Mes install précédentes mouraient toutes de la même façon : une carte SD qui rend l'âme au bout de quelques mois d'écritures permanentes. Là, le système tourne sur un SSD, et rien que ça, ça règle le problème qui m'avait dégoûté les fois d'avant.

J'ai donc collé Home Assistant OS dessus, ce qu'on appelle HAOS pour les intimes. C'est la version "système d'exploitation" qui prend la machine entière et qui pilote tout elle-même, sans Linux à administrer en dessous ni Docker à maintenir. Et puis avec cette version, vous récupérez au passage le magasin d'add-ons et les sauvegardes automatiques, sans rien configurer. Sur une machine dédiée qui ne fait que ça, c'est franchement le mode le plus tranquille.

Et là, premier petit piège à savoir au niveau du BIOS si vous vous lancez... Pour démarrer, HAOS exige en effet que le mode UEFI soit activé et que le Secure Boot soit désactivé. Si vous zappez ça, votre clé USB ne bootera jamais et vous allez tourner en rond un bon moment.

Et tant que vous êtes dans le BIOS, y'a un troisième réglage dont la doc ne parle pas et qui est pourtant le plus important sur la durée : le comportement après une coupure de courant. Ça s'appelle "Restore on AC Power Loss", "After Power Failure" ou "AC Back Function" selon les marques, et il faut le passer sur "Power On". Sans ça, la moindre micro-coupure vous laisse une maison sans domotique jusqu'à ce que quelqu'un rentre appuyer sur le bouton. Et ça, croyez-moi, on n'en veut pas quand on est parti en vacances.

Le reste après, c'est du classique. Vous récupérez l'image générique x86-64 et vous la flashez sur une clé USB avec Balena Etcher. Attention à bien prendre haos_generic-x86-64 et pas une version pour Raspberry Pi ou pour machine virtuelle, sinon vous allez vous demander longtemps pourquoi ça ne démarre pas. Ensuite vous bootez le mini PC sur la clé, l'installeur écrit le système sur le SSD interne, et c'est plié. Vous retirez la clé, ça reboote, et l'interface vous attend :

http://homeassistant.local:8123

Si ça ne répond pas, c'est que votre box ne fait pas de mDNS, allez juste chercher l'IP dans sa liste de clients. Et voilà, un Home Assistant tout neuf.

Maintenant, passons à la suite parce que j'ai une caisse pleine de matos à réveiller.

Première galère : Faire parler le Zigbee

Dans ma caisse, y'avait notamment un dongle USB Sonoff (lien affilié) pour le Zigbee. Je le branche, et je décide de partir sur Zigbee2MQTT plutôt que sur ZHA, l'intégration native. Le choix se paye tout de suite en complexité (il faut un broker MQTT à côté, Mosquitto en l'occurrence), mais il se rembourse largement après, parce que Zigbee2MQTT expose absolument tous les réglages internes des appareils. Vous verrez plus bas pourquoi c'est déterminant.

Le mini PC qui va me faire oublier mes galères avec le Raspberry Pi

Sauf que rien ne s'est passé comme prévu. J'installe les modules recommandés, et Zigbee2MQTT n'apparaît tout simplement pas dans la liste. Bon. Une fois que j'ai réussi à le sortir de sa cachette, c'est la configuration du port série de la clé qui m'a offert un vrai moment de solitude : on modifie, on clique sur "Submit", ça a l'air de sauvegarder... et la page revient vierge, sans plus rien à sélectionner. Allez savoir si le réglage est passé ou pas !

Le truc à retenir en fait, c'est qu'il faut désigner la clé par son identifiant stable et pas par un /dev/ttyUSB0 qui peut changer au reboot. Le chemin ressemble à ça :

/dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_...-if00

Une fois ça compris, le bridge est monté et n'a plus bougé. Mais c'est ce genre de conneries qui font lâcher la domotique à pas mal de monde, je pense.

Deuxième galère : mes appareils étaient otages du cloud

Deuxième claque, et celle-là est plus vicieuse. Mes prises connectées Meross, je les avais appairées à l'époque avec l'app du fabricant. Résultat, elles étaient déjà mariées au cloud Meross, et impossible de les récupérer proprement depuis l'app iPhone pour les basculer ailleurs.

La solution est donc passée par HACS, le magasin de composants communautaires, et un custom component qui s'appelle Meross LAN. L'intérêt, c'est qu'il parle aux prises en local, sur votre réseau, sans faire l'aller-retour par les serveurs du fabricant. Même logique avec l'app Sonoff LAN pour un interrupteur USB que j'avais (lien affilié). Vos automatisations continuent donc de tourner même quand le cloud du constructeur est dans les choux ou quand votre fibre est coupée.

J'ai aussi buté sur un cas plus tordu avec du matos Tuya car j'ai des appareil qui sont vendus sous une autre marque, avec leur app maison, et qui n'existent pas dans le cloud Smart Life sur lequel s'appuie l'intégration Tuya standard. Donc intégration cloud inutilisable... C'est vraiment le problème numéro un de l'objet connecté grand public, et c'est pour ça que je vous conseille de vérifier si un appareil a besoin du cloud avant de l'acheter, pas après.

Du coup, HACS est devenu mon meilleur pote sur ce chantier. J'y ai pris Meross LAN pour les prises, Sonoff LAN pour l'interrupteur, Alexa Media Player pour mes Echo et l'intégration Dyson. Il n'y a que mon capteur de qualité d'air air-Q qui était supporté nativement, sans rien avoir à installer.

Et pour faire tout ça, j'ai une arme secrète : Claude Code !

Et maintenant, la partie qui a vraiment tout débloqué. Parce que jusqu'ici, j'avais du matériel qui répondait, mais toujours zéro automatisation. Et c'est précisément là que je décrochais avant car l'éditeur graphique de Home Assistant devient vite limitant, et dès qu'on veut une condition un peu fine, on se retrouve à taper du YAML avec des templates Jinja et à se planter d'indentation ou de paramètres.

Du coup j'ai fait un truc très à la mode en ce moment... J'ai branché Claude Code directement sur mon Home Assistant via un serveur MCP conçu spécialement pour ça . En gros, le MCP c'est ce qui donne des outils concrets à l'IA. Grâce à ça elle peut lister mes entités, lire leur état en direct, et surtout écrire les automatisations dans HA. Je décris ce que je veux en français, il va regarder ce que j'ai réellement comme capteurs chez moi, et il écrit le scénario.

Et ça pour moi, ça change complètement le rapport tordu que j'ai à ma domotique. Et voilà comment en quelques jours, je me suis retrouvé avec 21 automatisations qui tournent, ce que je n'aurais jamais fait à la main. Pas parce que l'IA est magique, mais parce qu'elle supprime la friction. Je n'ai qu'à formuler les idées qui me passent par la tête et l'IA fait le job sans que j'ai à me galérer avec du paramétrage.

À noter que Home Assistant a aussi sa propre intégration Model Context Protocol Server depuis la version 2025.2, mais elle fait plutôt l'inverse : elle expose vos appareils à un assistant. Moi je voulais un truc qui écrive la config à ma place.

Mon vrai défi : Passer l'été sans clim

Voilà le scénario dont je suis le plus fier, parce qu'il résout un problème que j'ai vraiment dans cette nouvelle maison : pas de clim, et un bureau qui monte en température. Ce n'est pas que je ne veux pas en installer , c'est que je viens d'arriver, que y'a pénurie de ventilos et de pompes à chaleur et en plus je suis en location, donc ce n'est pas si simple que ça. Mes seules armes pour le moment, c'est donc un Dyson qui filtre et qui brasse, et des fenêtres à ouvrir au bon moment.

Mon fidèle ventilo !

Ce que j'ai fait du coup, c'est que le Dyson démarre tout seul quand l'air se charge en pollution et s'arrête quand c'est redevenu propre. Concrètement il se lance quand les PM2,5 dépassent 10 µg/m³ ou les PM10 dépassent 18 µg/m³ pendant 5 minutes d'affilée. Les 5 minutes de délai, c'est important car sans ça, un simple passage devant le capteur déclenche tout.

Mais le truc dont je suis vraiment content, c'est qu'il ne souffle pas pareil selon si je suis là ou pas. Si le capteur de présence me détecte, il démarre à 20% seulement, histoire de rester silencieux pendant que je bosse. Si je suis absent, il part direct à 100% et il purge la pièce à fond. Même logique pour les COV : au-dessus de 1000 ppb, c'est 30% en ma présence et 100% quand j'ai le dos tourné.

Le reste suit la même idée : une purge à fond pendant mon absence, un régime plus doux dès que je rentre dans la pièce, le mode nuit uniquement si je suis présent, et une alerte quand les filtres arrivent en bout de course.

Mais le vrai casse-tête, c'était l'aération. Parce que oui, quand l'air intérieur devient mauvais, la solution évidente c'est d'ouvrir les fenêtres. Sauf qu'en pleine canicule, ouvrir c'est la pire idée du monde : vous virez vos polluants et vous encaissez 35 degrés à la place. Je me suis retrouvé au départ plusieurs fois avec Alexa qui me disait d'aérer alors que c'était juste pas possible.

La solution que j'ai trouvé, c'est donc de mettre en place un scénario qui ne me conseille d'ouvrir que si quatre conditions sont réunies en même temps : il fait plus de 26 degrés chez moi, il fait au moins 2 degrés de moins dehors, l'air extérieur est plus sec que le mien, et la qualité de l'air extérieur est correcte. Alors let's go, Alexa me dit d'ouvrir les fenêtres. Et ça, elle le réévalue toutes les 10 minutes.

La condition sur l'humidité est celle à laquelle je n'avais pas pensé au départ, et que Claude Code m'a conseillé de lui-même, et c'est pourtant la plus utile. Comparer les températures toutes seules, ça ne suffit pas, c'est pourquoi le scénario compare les points de rosée, et pas les pourcentages d'humidité. Parce que de l'air à 24 degrés bien humide vous rafraîchit beaucoup moins que de l'air à 25 degrés bien sec, et vous vous retrouvez avec une pièce moite que vous mettrez la nuit à assécher.

Les notifs que j'ai sur le smartphone et qui sont lues par Alexa

Petite subtilité technique au passage : je ne regarde pas la température qu'il fait dehors, mais la plus chaude des deux prochaines heures. Ça évite d'ouvrir dix minutes avant que ça remonte. Et ça oblige à passer par un helper, parce qu'un template Home Assistant ne peut pas appeler un service tout seul... il faut donc une automatisation qui va chercher la prévision et la dépose dans une variable, toutes les 10 minutes.

Et surtout, il me dit quand refermer, avant que la chaleur ne revienne. Là, je referme quand la fraîcheur est acquise, quand la prévision annonce que c'est fini, ou quand l'air du dehors se dégrade. Et le message diffusé par Alexa m'explique laquelle des trois raisons s'applique.

Deux petits helpers mémorisent aussi qu'une aération est déjà en cours, histoire qu'Alexa ne me répète pas la même chose toutes les cinq minutes. Et si je m'absente pendant l'opération, j'ai droit à un rebriefing en rentrant.

Au passage, j'ai fait deux erreurs de débutant. La première c'est que j'avais posé mon capteur de qualité d'air juste à côté de la fenêtre. Il mesurait donc l'air de la rue et pas celui de mon bureau, et les scénarios se déclenchaient n'importe quand. Déplacé au fond de la pièce, tout est redevenu cohérent. Bref, placez vos capteurs là où vous vivez, pas là où c'est pratique à brancher.

La seconde, c'est que j'ai fini par limiter les annonces vocales sur la plage 8h-22h parce que se faire réveiller à 3h du matin par une enceinte qui vous parle de particules fines, ça vous passe l'envie de la domotique très vite !

Et si vous n'avez pas de clim non plus et que vous cherchez plus radical, Vincent avait aussi testé un rafraîchisseur pendant la canicule .

Le petit capteur qui a tout changé

Dans ma caisse à domotique, y'avait aussi un détecteur de présence Moes (lien affilié) en Zigbee, à ondes millimétriques, ce qu'on appelle un capteur mmWave. Un petit module qui coûte trois fois rien, et c'est clairement ma meilleure surprise de tout ce chantier.

Parce qu'un détecteur de mouvement classique, un PIR, détecte la chaleur qui bouge. Donc quand vous êtes assis à votre bureau en train de lire ou de regarder une vidéo, au bout de deux minutes il décide que la pièce est vide et vous éteint la lumière. Alors que le mmWave, lui, détecte la présence statique : il vous voit même immobile, parce qu'il capte les micro-mouvements et la respiration. Pour un bureau, c'est le jour et la nuit !

Le capteur AirQ à gauche / Le capteur mmWave à droite

Et c'est ici que le choix de Zigbee2MQTT paye enfin, parce qu'il expose tous les réglages internes du capteur. J'ai pu fixer la distance de détection à 225 cm, les sensibilités de mouvement et de présence statique à 4 sur 5, et un délai avant extinction de 20 secondes. Ce réglage de distance est important puisque le capteur peut porter jusqu'à 6 mètres, et à pleine portée il traverse allègrement une cloison pour aller détecter la pièce d'à côté.

Le résultat, c'est que quand j'approche de mon bureau, ma barre lumineuse BenQ s'allume toute seule via mon interrupteur Sonoff. Une deuxième automatisation allume la lampe d'ambiance sur une prise Meross, et une troisième éteint tout quand je quitte la pièce.

Et surtout, le déclencheur n'est pas la présence, mais la distance : la barre s'allume quand la cible passe sous 175 cm et ce chiffre-là, je ne l'ai pas sorti de mon chapeau. J'ai relevé 25 mesures en me plaçant assis, debout et en circulant derrière le bureau. Comme ça, un seuil serré exclut proprement tout ce qui n'est pas moi devant mon écran. Si vous devez retenir une chose sur le mmWave, c'est de bien noter vos vraies distances avant de choisir un seuil, sinon vous passerez des semaines à corriger des déclenchements bizarres.

Rien de spectaculaire au final, mais c'est un super confort !

Et forcément, des trucs ont cassé

Parce que non, même avec l'IA tout ne marche pas du premier coup. Une nuit, je quitte le bureau juste après minuit, et le lendemain matin je retrouve toutes les lumières allumées. Huit heures dans le vide. L'automatisation d'extinction sur absence n'était pourtant pas cassée : elle n'a simplement jamais eu l'information qu'il fallait pour se déclencher.

Le coupable, c'est le défaut classique des radars mmWave : la cible fantôme. Le capteur s'est verrouillé sur un écho statique et a continué à annoncer quelqu'un dans la pièce, en oscillant tranquillement entre 241 et 269 cm toute la nuit. Pour Home Assistant, j'étais donc toujours là. C'est ça la contrepartie de la détection statique... quand un radar voit quelqu'un d'immobile, il ne sait pas faire la différence entre vous et un artefact.

La parade, c'est donc une automatisation garde-fou : si la cible reste au-delà de 175 cm pendant 90 minutes d'affilée alors que les lumières sont allumées, on éteint tout. Le seuil reprend la calibration de la barre BenQ, et les 90 minutes valent le double de la plus longue plage légitime que j'aie observée sur trois jours (49 minutes). Elle ne remplace pas l'extinction sur absence, mais rattrape le cas où celle-ci n'a jamais pu partir.

Bref, l'IA écrit vite les scénarios c'est sûr, mais elle ne les teste pas en conditions réelles dans votre vraie maison. Un scénario parfait sur le papier peut très bien ne jamais se déclencher parce qu'un capteur ment donc il faut comprendre ce qui a été écrit, et surtout aller regarder l'historique quand quelque chose cloche.

Et puis y'a les petites morts silencieuses... Une de mes prises connectées est passée en "unavailable" et y est restée plusieurs jours sans que je m'en rende compte. C'est un autre piège de la domotique... Quand un truc tombe, rien ne vous prévient, ça arrête juste de marcher. D'où l'intérêt d'avoir aussi des automatisations qui surveillent votre installation elle-même, et pas seulement votre maison.

Voilà, c'est un petit début, mais ça me permet de me remettre en selle tranquillement. En tout cas, l'option mini PC + LLM est un bon choix pour avoir une install domotique rapidement fonctionnelle, je pense.

La suite du programme

Ce que j'ai fait aussi c'est installer Tailscale sur le mini PC, pour accéder à mon Home Assistant depuis l'extérieur sans ouvrir le moindre port sur ma box. C'est de loin la méthode la plus propre, et c'est gratuit pour un usage perso.

Ensuite, je pense que je vais sortir les ESP32 du tiroir. L'add-on ESPHome est déjà installé, il ne me manque plus que le courage de m'y mettre. Si ça vous tente, j'avais montré comment transformer un ESP32 à 5 euros en capteur domotique.

J'ai aussi pas mal de matos Z-Wave à recycler, donc je pense que je vais aussi prendre une petite clé Z-Wave à rajouter sur l'ordi.

Voilà pour ce début d'aventure domotique dans mon nouveau chez moi. Pour le moment, je me suis surtout concentré sur l'aération, la pollution, la gestion de la chaleur mais je pense que j'aurais de nouveaux scénarios qui viendront peupler mes rêves dans les semaines qui viennent et je ne manquerai pas de vous en causer.

Ce serait trop cool non, si avec un double-clic sur un .docx dans votre gestionnaire de fichiers Linux, Word s'ouvrait directement ? Et je ne vous parle pas d'un bureau Windows complet en plein écran ou d'une session de bureau à distance. Juste une fenêtre Word tout ce qu'il y a de plus classique, avec son icône dans votre barre des tâches, épinglable et "alt-tabbable" comme le reste.

Hé bien, c'est ce que fait WinPodX , qui fait tourner un conteneur Windows sous KVM en arrière-plan et découpe l'affichage application par application via FreeRDP RemoteApp. Comme ça, les liens mailto: partent vers Outlook ou les schémas slack: ou vnc: vers l'application qui les a déclarés.

Tout ce qui est presse-papiers, son, imprimantes et votre dossier personnel sont partagés d'office, et le conteneur se met en pause tout seul quand personne ne s'en sert.

Jusque-là, WinApps dont je vous ai déjà causé, qui fait tourner Office sous Linux , faisait déjà l'essentiel avec les fenêtres détachées, le dossier personnel partagé, le clic droit qui envoie un fichier vers une application Windows. Mais WinPodX se distingue aussi dans l'autre sens puisque vos applications Linux remontent également dans le menu "Ouvrir avec..." du Windows, et dans un dossier "Linux Apps" du menu Démarrer. Bref, l'accès aux apps et aux fichiers marche dans les 2 sens, pour plus de transparence dans vos usages.

Si ça vous intéresse, sachez qu'il vous faut une licence Windows valide, car WinPodX ne la fournit pas (logique), que la virtualisation doit être activée dans le BIOS, avoir un accès à /dev/kvm, 8 Go de RAM et une trentaine de gigas de libre. La première installation prend cinq à dix minutes le temps de télécharger l'ISO, et les suivantes sont quasi instantanées.

Pour l'installer :

curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash

Il y a également un paquet pour openSUSE, Fedora, Debian, Ubuntu, Arch et NixOS, un AppImage pour les autres. C'est sous licence MIT, et sans aucune télémétrie puisque celle de Windows a été elle-même coupée par défaut. Ah et l'interface du OuinOuin peut être configurée en français.

Par contre, pas d'accélération GPU, ce qui exclut les jeux et la 3D à moins de monter un passthrough à la main. Préférez Wine pour ça...

Je suis trop content, le numéro d'août du magazine officiel Raspberry Pi est sorti avec un dossier spécial cyberdeck en couverture, et ses 132 pages sont téléchargeables gratuitement en PDF.

Un cyberdeck, si ça ne vous dit rien, c'est un ordinateur portable bricolé à la main. Petit écran, clavier physique, look cyberpunk assumé. On fabrique la machine que le commerce ne vend pas, pour un usage qui n'appartient qu'à soi. J'en ai déjà montré un y'a pas longtemps, même si faut encore voir ce que ça donne une fois posé sur un bureau.

Le dossier de Raspberry Pi Magazine en aligne une dizaine. Un Amstrad PPC 640 de 1987 vidé de ses entrailles pour loger un Raspberry Pi 3 et une appli de narration qui se déclenche à l'insertion d'une disquette. Une machine à écrire Smith Corona de 1989 refaite à neuf autour d'un Raspberry Pi 4. Un sac à dos qui trimballe un labo mobile, radio logicielle et outils Kali Linux...etc. Y'a de quoi faire !

On y croise aussi un Hackberry Pi monté en outil de pentest, une pochette rose façon clutch avec un Pi Model A+, et le PiDex Doomsday Companion, caisse étanche à panneau solaire qui embarque Wikipedia sur clé USB.

Vient ensuite le montage pas à pas. Brian Corteil y déroule la construction d'une machine logée dans une valise étanche de type Pelican (lien affilié), avec un Raspberry Pi 5, un écran tactile 7 pouces, un clavier Bluetooth, une carte son USB et une batterie LiPo protégée par un fusible.

Et rassurez-vous, le tuto ne se contente pas d'aligner des références à commander sur Amazon... Non, il détaille même le calcul d'alimentation à faire à la main, I = P/V, soit 28 W et environ 5,6 A pour un Pi 5 et son écran à pleine luminosité. Il conseille également de prototyper en carton votre cyberdeck avant de vous lancer dans la CAO, et préfère un power bank au LiPo pour ceux qui ne veulent pas jouer avec les batteries (BOUM !).

Pour récupérer le fichier PDF du magazine, le lien passe d'abord par une page de don. Si vous êtes un gros radin, le bouton No thanks, take me to the free PDF déclenchera quand même le téléchargement sans compte ni adresse mail. C'est en anglais bien sûr et pour ceux qui aiment le toucher du papier, l'édition physique coûte 7,99 livres.

Ah et le contenu est sous licence Creative Commons BY-NC-SA 3.0, sauf mention contraire. Amusez-vous bien !!

Vous rentrez de soirée à moitié bourré, vous ouvrez Paramètres, Applications, Applications installées, et vous cherchez OneDrive Photos pour le virer... Mais il n'y est pas ! Rassurez-vous, ce n'est pas à cause des effets de l'alcool car l'application est pourtant bien sur la machine, avec son icône moche dans le menu Démarrer et son interface photo qui s'ouvre très bien quand on clique dessus... ALORS POURQUOI NE PEUT ON PAS VIRER CETTE COCHONNERIE ???

Hé bien Microsoft a reconnu avoir distribué cette nouvelle interface "photo" plus largement que prévu sur Windows 11 sans anticiper que des gens auraient envie de le virer. Le déploiement était involontaire, mais le résultat est quand même arrivé sur votre disque et vu la réputation de OneDrive côté dark patterns , l'envie de nettoyer tout de suite se comprend...

Mais rassurez-vous, je vais vous aider !

Étape 1 - Trouver ce qui est réellement installé

OneDrive Photos n'est pas une application séparée, c'est le binaire OneDrive.App.exe livré à l'intérieur du client de synchronisation OneDrive.

Voilà pourquoi Windows ne lui donne aucune entrée de désinstallation.

Son emplacement dépend en réalité du mode d'installation du client. En installation par utilisateur, il atterrit dans votre profil. En installation pour toute la machine, il va dans Program Files. Cette commande ci-dessous teste donc les deux et affiche la version trouvée.

Get-ChildItem "$env:LOCALAPPDATA\Microsoft\OneDrive","$env:ProgramFiles\Microsoft OneDrive","${env:ProgramFiles(x86)}\Microsoft OneDrive" -Filter OneDrive.App.exe -ErrorAction SilentlyContinue | Select-Object FullName,@{n='Version';e={$_.VersionInfo.FileVersion}}

Étape 2 - Supprimer les raccourcis

Ce que Windows vous laisse supprimer facilement par contre, ce sont les raccourcis. Ils se posent au niveau de la machine et dans votre profil, donc menu Démarrer et bureau. Par contre, ouvrez PowerShell en administrateur sinon, vous ne pourrez pas les virer.

"$env:ProgramData\Microsoft\Windows\Start Menu\Programs","$env:APPDATA\Microsoft\Windows\Start Menu\Programs","$env:PUBLIC\Desktop","$env:USERPROFILE\Desktop" | ForEach-Object { Get-ChildItem $_ -Filter "OneDrive Photos.lnk" -ErrorAction SilentlyContinue } | Remove-Item -Verbose

Le script affiche alors chaque raccourci retiré. Tapez ensuite "OneDrive Photos" dans le menu Démarrer, et vous verrez plus rien ne remonte.

Pourquoi ça ne suffit pas ?

Mais vous l'avez compris, le binaire, lui, n'a pas bougé. Vous avez nettoyé le point d'entrée, mais pas désinstallé l'application. Un double-clic sur OneDrive.App.exe rouvrira l'interface photo comme avant, et une mise à jour du client peut très bien rétablir le raccourci...

Et non, il n'existe aucune clé de registre ni stratégie de groupe pour bloquer proprement cette application, même sur un parc géré. Pas d'interrupteur à débrancher comme avec RemoveWindowsAI face à Copilot . Les scripts qui circulent suppriment des .lnk, rien d'autre.

Alors comment on fait ? Hé bien on passe à l'étape 3 !

Étape 3 - Retirer OneDrive en entier

Car la seule suppression réelle aujourd'hui, c'est de désinstaller le client OneDrive en entier, ce qui n'a de sens que si vous ne vous en servez pas. Le dossier d'installation part avec, donc le binaire photo aussi. Avant de lancer quoi que ce soit, si vous utilisez les fichiers à la demande, faites donc un clic droit sur les dossiers qui comptent et cochez "Toujours conserver sur cet appareil".

winget uninstall --id Microsoft.OneDrive

Le même résultat s'obtient depuis Paramètres > Applications installées > Microsoft OneDrive > Désinstaller. La synchronisation locale s'arrête là, mais vos données restent en ligne et rien n'est supprimé côté Microsoft.

Pour vérifier le résultat, relancez alors la commande de l'étape 1. Plus aucun chemin affiché, le binaire a quitté les emplacements contrôlés. Si un chemin encore là, c'est qu'un client OneDrive traîne toujours, souvent dans un autre profil utilisateur.

Ensuite, pour revenir en arrière, il faudra réinstaller OneDrive depuis le site officiel de Microsoft. Mais si la synchro de vos fichiers revient, sachez que l'interface photo aussi. Les deux voyagent ensemble comme des bro incels soudés à la vie à la mort.

Alors que faire ?

Hé bien faudra attendre septembre..

Car oui, youpi, Microsoft annonce pour septembre 2026 un contrôle qui retirera OneDrive Photos seul, sans couper la synchronisation. Donc si vous tenez à OneDrive, attendre quelques semaines vous coûtera moins cher qu'une désinstallation complète.

Source

Diagram-design , c'est un skill pour Claude Code, Codex et Pi qui vous fabrique un schéma technique sous forme de fichier HTML autonome. Vous double-cliquez, ça s'ouvre dans le navigateur, et le diagramme est là, super clean et sans avoir à faire de build ou importer des images.

27 types de diagrammes sont couverts, du schéma d'architecture au diagramme de séquence en passant par la machine à états, le Gantt et le quadrant, chacun en 3 variantes : claire, sombre et éditoriale. Bref, de quoi illustrer une doc ou un article de blog sans dessiner les boîboîtes vous-même, une par une comme dans un Excalidraw .

Le type Loop, avec son moyeu de mémoire partagée. Les pointillés sont les écritures en retour.

Il sait aussi partir de ce que vous avez déjà. Vous lui pointez un fichier draw.io ou un bloc Mermaid planqué dans un README, et il le reprend. Attention, ce n'est pas une conversion hein, mais un re-dessin (ça se dit ?? j'sais pas mais je m'en fous) complet. Il va même récupérer le diagramme embarqué dans un .drawio.png, vous savez, celui qui ressemble à du charabia quand vous ouvrez le fichier dans un éditeur.

Ce qu'il jette au passage ce sont les coordonnées de la source, sa palette, ses polices, les connecteurs en diagonale de draw.io et la mise en page automatique de Mermaid. Ce qu'il garde par contre, ce sont les composants, les relations, les regroupements et le sens de lecture.

À la fin de l'import, il rend même un genre de relevé de fidélité en vous indiquant les noeuds en entrée, les noeuds qu'il a dessinés et les noeuds orphelins qu'il a supprimé.

Un fichier draw.io de 12 nœuds redessiné en niveau de détail équilibré, pour un billet de blog.

La sortie se règle ensuite sur 4 critères. Le format d'abord, HTML, SVG ou PNG. Puis la taille, qui ne touche pas que le cadre. Une planche 16:9 destinée au vidéoprojecteur reçoit des libellés en 16px, une image de doc en reçoit des 12px.

Le troisième critère élague votre dessin, avec 24 nœuds au maximum en mode fidèle, 12 en équilibré, 7 en simplifié, et la coupe suit toujours le même ordre : les décorations, puis les doublons, puis les grappes de feuilles, puis l'infrastructure.

Le quatrième change le vocabulaire, mais pas le nombre de boîtes pour s'adapter au public à qui est destiné le diagramme. Pratique pour passer d'un diagramme hyper technique à quelque chose qui pourra être compris de la direction ou des commerciaux.

Reste l'allure du diagramme... Vous lui donnez par exemple l'URL de votre site, il lit la page d'accueil, en tire la couleur de fond, celle du texte, celle des boutons et la pile de polices, puis range tout ça dans des rôles, et voilà vous avez le design de vos rêves.

Mais surtout, avant d'écrire quoi que ce soit, il contrôle le contraste en AA. Si une de vos couleurs ne tient pas la route à la taille où vivent les libellés, entre 9 et 12px, il propose une valeur corrigée et explique pourquoi. Vous validez le diff, et le guide de style du skill est mis à jour pour tous les schémas suivants.

Et au premier schéma dans un nouveau projet, il refusera même de partir sur le thème par défaut sans vous demander. Il vous proposera naturellement d'aller consulter votre site, de coller vos couleurs à la main, ou encore d'assumer le défaut en connaissance de cause.

Côté installation, ça passe par les plugins pour Claude Code et Codex, par npx pour Codex, par une ligne pour Pi. C'est sous licence MIT et c'est gratuit. Tout est ensuite produit en local, et l'import Mermaid se contente de lire le texte, sans rendu ni appel réseau. Il n'y a que l'export PNG qui réclame un extra, à savoir Playwright, à installer à côté.

Maintenant, c'est pas le même usage qu'un bloc Mermaid qui lui est destiné à évoluer en permanence. Là c'est vraiment pour faire des rendus sous la forme d'une image finie et jolie. Donc à vous de voir !

À découvrir ici !

Bonne nouvelle les amis, je viens de vous mettre en ligne un sélecteur de distribution Linux !! 35 distributions dans la balance, vingt questions max et à l'arrivée, le nom du Linux qu'il vous faut !

Parce que oui, la "meilleure" distribution Linux n'existe pas dans l'absolu. En fait, le bon choix dépend de votre machine, de votre usage et du temps que vous acceptez d'y passer. Posez la question à deux personnes, l'une répondra Linux Mint, l'autre CachyOS, et les deux auront raison !

L'outil vous demande vos usages et ce que vous avez sous la main... L'âge de la machine, la RAM, la carte graphique, un Windows à garder à côté, et ce que vous comptez en faire, jouer compris.

Le questionnaire se raccourcit ensuite selon ce que vous avez déjà répondu et au final, vous repartez avec une distribution, sa fiche technique et 2 alternatives si celle-là ne vous branche pas.

J'ai remarqué que ce qui manquait à la plupart des classements de ce type, c'était le "pourquoi pas cette distrib ?". C'est pour cela que mon sélecteur affiche aussi les distributions écartées avec la raison de leur élimination, et celles qui ne démarreront même pas chez vous. Hé oui, un vieux PC en 32 bits n'a plus grand monde à se mettre sous la dent depuis que Debian 13 a supprimé son noyau i386.

Et quand Linux n'est pas la réponse à votre besoin, il vous prévient. Par exemple, si votre travail dépend de la suite Adobe ou d'un jeu avec un système anti-triche, l'outil ne fera pas semblant du contraire.

Et bien sûr, tout cela tourne exclusivement dans votre navigateur, et rien ne part ailleurs dans le cloud. En plus c'est gratuit ! 35 distributions ne font évidemment pas tout l'écosystème Linux, et j'ai dû faire des choix mais ça vous donne déjà un nom précis sur lequel vous lancer en toute sérénité.

Et si vous voulez découvrir les autres services Korben c'est par ici .

Je m'en doutais un peu mais c'est confirmé, derrière chaque session GeForce NOW tourne un vrai Windows, et cette machine virtuelle est moins verrouillée qu'elle en a l'air. En effet, une démo du moddeur Zortos montre le service qui s'ouvre non pas sur un jeu, mais sur un bureau complet, avec barre des tâches, menu démarrer et icônes.

La manip passe par le jeu Trove... Pendant le lancement, Zortos ouvre le navigateur web intégré de Steam, se balade dans les dossiers de la machine, récupère un exécutable et remplace quelques chemins dans le répertoire du jeu. Au démarrage suivant, Windows s'affiche alors à la place du jeu. Tout ça repose sur SalsaNOW , un outil open source signé dpadGuy.

Une fois le bureau ouvert, la machine encaisse à peu près tout ce qui ne réclame pas de droits administrateur. Zortos y a fait tourner Wallpaper Engine pour les fonds animés et LM Studio avec le modèle Gemma 4. Et pour les logiciels qui exigent une installation privilégiée, ils peuvent sans souci être préparés en version portable sur son propre PC, puis décompressés là-haut.

Reste que ce bureau est un bac à sable. La session tourne en compte utilisateur simple, donc pas de droits administrateur, pas d'anticheat noyau, et beaucoup d'installations qui finissent sur un refus d'accès.

L'autre mur, c'est la persistance. Sans l'option de stockage payante, tout disparaît à la déconnexion. Et même en la prenant, la machine ne conserve que vos Documents, l'AppData du compte, baptisé kiosk, et le contenu du lecteur I:. Tout le reste repart de zéro à la session suivante, et fermer l'explorateur de fichiers coupe la connexion sur-le-champ.

Dernier filtre, et pas le moindre, ça ne fonctionne que sur les abonnements payants, ceux dont je détaillais les formules quand Nvidia a sorti son client Linux natif . L'offre gratuite est hors jeu, tout comme les GeForce NOW opérés par les partenaires alliance.

Si vous avez un Mac Apple Silicon et que vous en avez assez de payer des tokens à chaque requête, Rapid-MLX vaut le détour. C'est un moteur d'inférence local maintenu par Raullen Chai, qui tape directement dans les kernels MLX d'Apple, sans repli sur llama.cpp ni couche Metal intermédiaire. Et si le nom vous dit vaguement quelque chose, c'est normal puisque c'est un fork de vLLM-MLX, le serveur de Wayner Barrios dont je vous parlais en mai . Rapid-MLX a juste pris un rythme de publication plus soutenu des deux.

Ce que ça vous donne, c'est donc un serveur HTTP qui parle le même langage que l'API d'OpenAI et celle d'Anthropic. Vos scripts, Cursor, Aider, LangChain ou Claude Code continuent de fonctionner, sauf qu'ils tapent sur votre machine au lieu d'un datacenter.

Donc je vous propose de voir ensemble comment installer ça.

Étape 0 : Vérifier que votre Mac est éligible

Le script d'installation contrôle plusieurs choses avant de lancer quoi que ce soit, et autant les connaître d'avance. Il faut une puce Apple Silicon et il n'y a pas de version Linux ni Windows, ni de support CUDA ou AMD.

Le script d'installation accepte encore macOS 13 Ventura, mais le vrai plancher est macOS 14 Sonoma. La formule Homebrew l'exige, et surtout MLX, la brique Apple sur laquelle tout repose, ne publie de paquets macOS que pour les versions 14, 15 et 26. Sur un Mac resté en Ventura, ça cassera donc à l'installation des dépendances, quel que soit le chemin choisi.

Dernier point à avoir en tête, c'est pensé pour votre machine à vous et pas pour un serveur. Vous n'y trouverez donc ni authentification multi-utilisateurs, ni quotas de requêtes.

Étape 1 : Installer Rapid-MLX

Le plus simple, c'est Homebrew :

brew install rapid-mlx

Si vous gérez déjà vos environnements Python vous-même, les autres chemins existent :

uv tool install rapid-mlx@latest
python3.12 -m pip install rapid-mlx

Il y a aussi un installeur en une ligne (curl -fsSL https://rapidmlx.com/install.sh | bash) qui détecte votre RAM et vous propose un modèle adapté. Il crée un venv isolé dans ~/.rapid-mlx/ et pose le binaire dans ~/.local/bin/. Un curl | bash reste un curl | bash. La formule Homebrew fait exactement le même boulot, donc l'installeur en ligne perd de son intérêt.

L'installation de base pèse dans les 460 Mo et la vision, l'audio et les embeddings sont des extras optionnels, vous les ajouterez seulement si vous en avez l'usage.

Étape 2 : Choisir un modèle qui tient dans votre RAM

C'est là que la plupart des gens se plantent, en chargeant un modèle trop gros et en concluant que "ça rame". Sur Mac, la RAM est unifiée, donc le modèle mange directement dans la mémoire que se partagent le CPU et le GPU.

Les paliers recommandés par le projet :

RAM	Modèle conseillé
8 à 23 Go	`qwen3.5-4b-4bit`
24 à 47 Go	`gpt-oss-20b-mxfp4-q8`
48 à 95 Go	`qwen3.6-35b-8bit`
96 Go et plus	`gpt-oss-120b-mxfp4-q8`

Le catalogue complet se liste avec la commande rapid-mlx models, et rapid-mlx info <alias> vous donne le profil détaillé d'un modèle. Si vous voulez sortir du catalogue maison, le filtre matériel de Hugging Face que je vous montrais fin juin fait exactement ce tri à votre place.

Pour utiliser un autre modèle que celui par défaut, il suffit de reprendre l'alias affiché par rapid-mlx models et de le passer en argument. Et si vous préférez télécharger les poids à l'avance, sans rien lancer, c'est le boulot de rapid-mlx pull, qui accepte aussi bien un alias du catalogue qu'un identifiant Hugging Face :

rapid-mlx pull qwen3.5-9b-4bit

Le modèle atterrit dans le cache Hugging Face de votre machine, et ensuite rapid-mlx chat qwen3.5-9b-4bit ou rapid-mlx serve qwen3.5-9b-4bit chargeront ce modèle-là. Le pull préalable reste facultatif, chat et serve téléchargent d'eux-mêmes ce qui manque, mais autant rapatrier les gigas tranquillement avant plutôt qu'au moment où vous voulez bosser.

Étape 3 : Vérifier que ça tourne

Avant de bricoler des intégrations, testez en direct :

rapid-mlx chat

Ça part sur qwen3.5-4b-4bit par défaut, télécharge les poids au premier lancement (comptez 2,5 Go) et vous lâche dans une interface (REPL). /help listera les commandes slash, et /exit vous permettra de quitter le chat.

Une subtilité qui évite de mal interpréter ce premier test, c'est que dans le chat, le raisonnement est coupé par défaut, histoire que le modèle ne vous déballe pas sa réflexion à l'écran. En mode serveur par contre c'est l'inverse, et ça change la vitesse ressentie du tout au tout. J'y reviens plus bas.

Étape 4 : Lancer le serveur

Le vrai intérêt, c'est le mode serveur :

rapid-mlx serve qwen3.5-4b-4bit

Vous récupérez un endpoint sur http://localhost:8000. Le test qui confirme que tout est en place :

curl http://localhost:8000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{"model":"default","messages":[{"role":"user","content":"Dis bonjour !!"}]}'

Et côté Python, vous gardez le SDK OpenAI tel quel, seule l'URL de base change :

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
print(client.chat.completions.create(
 model="default",
 messages=[{"role": "user", "content": "Say hello"}],
).choices[0].message.content)

Pointez n'importe quel client compatible OpenAI sur http://localhost:8000/v1 et c'est réglé. Cursor, Aider, LibreChat, Open WebUI, LangChain, tous marchent avec ce seul changement d'URL. Il y a aussi /v1/embeddings pour du RAG local et /v1/responses pour le Codex CLI.

Étape 5 : Brancher Claude Code dessus

C'est le morceau le plus intéressant du lot, et il tient en deux variables d'environnement. Serveur lancé d'un côté, puis dans un autre terminal :

ANTHROPIC_BASE_URL=http://localhost:8000 ANTHROPIC_API_KEY=not-needed claude

Attention quand même, l'URL de base doit être la racine, sans /v1 à la fin. Le SDK Anthropic ajoute /v1/messages tout seul, donc si vous mettez /v1 vous obtenez /v1/v1/messages et ça casse.

Depuis la 0.10.14, l'appel d'outils passe par une grammaire contrainte activée par défaut, donc plus besoin de bidouiller un --tool-call-parser à la main pour que les tool calls soient parsables. Pour du Claude Code sérieux, visez plutôt un gros modèle, la doc officielle recommande par exemple qwen3.6-35b-4bit en exemple.

Quand ça coince

Le réflexe à avoir avant de chercher ailleurs :

rapid-mlx doctor

Les trois pannes les plus courantes sont toujours les mêmes.

Débit décevant côté serveur, c'est le raisonnement : les Qwen 3.5 et 3.6 démarrent en mode réflexion, donc ils pensent à voix haute avant de répondre, et --no-think règle l'affaire.

Plantage mémoire, votre modèle est trop gros pour la RAM disponible, redescendez d'un palier ou prenez une quantification plus agressive. Appels d'outils qui arrivent en texte brut, la récupération automatique gère la plupart des cas, sinon vous forcez le parser correspondant à votre modèle.

Voilà, grâce à ça, votre Mac est maintenant un serveur d'IA super rapide ! Plus de facture au token, et vos prompts ne sortent plus de la pièce.

Merci à Philobois pour le lien !

Si vous avez un Raspberry Pi et que Chromium commence à vous fatiguer, le VRAI Chrome, celui des chads que vous êtes, est enfin dispo en ARM64 !! Enfin, dispo... Si vous savez où chercher, parce que la page de téléchargement de Google vous propose toujours l'installeur amd64, qui ne tournera jamais sur votre machine. C'est Joey Sneddon, d'OMG! Ubuntu, qui a trouvé la combine en bidouillant l'URL depuis son Pi 5.

Avant toute chose, vérifiez que vous êtes bien en 64 bits, parce qu'un système 32 bits refusera le paquet :

dpkg --print-architecture

Si ça répond arm64, le fichier est là , 126 Mo. Il s'installe comme n'importe quel .deb local, en laissant apt gérer les dépendances :

wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb
sudo apt install ./google-chrome-stable_current_arm64.deb

Le RPM existe aussi pour les distributions qui préfèrent, en remplaçant la fin du nom par aarch64.rpm.

J'ai ouvert le paquet pour regarder ce qu'il y avait dedans. Son fichier de contrôle annonce google-chrome-stable en version 150.0.7871.186, architecture arm64, un peu plus de 400 Mo une fois installé. Soit exactement la même version que le paquet x86 poussé le même soir. Le même Chrome, à la même révision.

Et le canal stable n'est pas seul. Le dépôt de Google sert aussi la beta (151.0.7922.47), la dev (152.0.7967.2) et la canary (152.0.7974.0) pour les puces ARM, et son fichier Release déclare noir sur blanc les deux architectures. Les quatre canaux ont été publiés dans la même minute que leurs équivalents x86.

Est-ce qu'on se retrouve coincé sur cette version, à re-télécharger le .deb à la main tous les mois ? Non. Le script de post-installation contenu dans le paquet ajoute le dépôt Google en précisant l'architecture, et les cinq paquets y sont indexés en arm64 exactement comme en x86. Les mises à jour ont donc de quoi arriver par apt, comme d'habitude.

Alors pourquoi s'embêter, puisque Chromium tourne sur ARM depuis des années ? Pour deux trucs. D'abord ma synchro du compte Google, qui ramène favoris, mots de passe et extensions. Et ensuite, Widevine, le module DRM, qui est ici un vrai binaire aarch64 et pas une couche de compatibilité comme l'émulateur FEX financé par Valve . Netflix et les autres plateformes à DRM s'ouvriront enfin sur un SBC !!!

Mais avec une nuance à connaître avant de vous réjouir qui est que sous Linux, Widevine reste au niveau "Software Secure". Cela veut dire que sur Netflix, la qualité plafonnera entre 720p et 1080p. De la HD donc et pas de la 4K. Désoléééé !

Google avait promis tout ça en mars, pour le deuxième trimestre et son billet annonçait même une installation via chrome.com/download pour les autres distributions, ce qui est malheureusement le morceau qui manque aujourd'hui.

Cela veut dire aussi que rien ne garantit que ce paquet soit considéré comme étant prêt par ses auteurs donc si votre machine doit rester stable, laissez passer quelques semaines avant de vous y essayer.

Manque plus que quelqu'un chez Google ait le courage d'appuyer sur "publier".

Source

J'aime bien lire les articles de l'EFF (l'Electronic Frontier Foundation, la Quadrature du Net des américains quoi...) et là ils viennent de publier un truc m'a fait plaisir : un vrai plaidoyer pour la défense du RSS .

Vous connaissez mon avis là dessus et c'est vrai que depuis que Google a signé l'arrêt de mort de cette techno au profit d'algo à la con type Discover , y'a énormément moins de monde qui l'utilise. Et je trouve ça triste.

Alors que les flux RSS, c'est la liberté ! Ça décloisonne le contenu d'un site pour le faire atterrir dans l'appli de votre choix, ça permet d'en extraire des choses, de le faire traiter par exemple par un programme...etc. Et surtout c'est vous qui gérez la façon dont vous voyez le contenu. Vous pouvez le filtrer, l'ordonner comme vous voulez et surtout le lire avec le lecteur de flux de votre choix.

C'est super pratique, et ça permet par exemple de parcourir uniquement les titres des articles, et de ne s'arrêter que sur ceux qui vous intéressent. Moi y'a plein de trucs qui m'intéressent en ce moment et que j'ai envie de partager. Je suis hyper actif et atteint de FOMO, donc ça bombarde. En plus j'ai que ça à foutre de la journée en général, donc bon, désolé ! ^^ Mais heureusement, avec les flux RSS vous pouvez faire une sélection plus fine et éviter de lire des trucs qui ne vous intéressent pas.

Perso, ça fait des années que je fais de la veille, c'est une partie importante de mon boulot. J'ai commencé sur un lecteur de flux tout pourri, puis je suis passé par Netvibes, Google Reader (paix à son âme), puis Feedly et aujourd'hui j'expérimente Inoreader. Le RSS ne m'a jamais quitté et quand les sites n'en proposent pas, je m'arrange toujours avec des scripts ou des outils customs pour m'en faire un que je peux importer dans mon lecteur !

J'aime tellement ça que sur korben.info, que je vous propose des flux RSS complets (qui contiennent tout le contenu). Le premier, /feed , c'est le flux tech que vous connaissez, historique, exactement comme vous l'aimez. Que de la techno, du code, de la sécu, de l'open source.

Et le petit nouveau c'est /feedfull , qui propose les même sujets tech qu'au-dessus + des sujets un peu plus grand public / mainstream. Dernièrement, j'avais envie envie d'ouvrir un peu plus les portes du site et écrire aussi pour ceux qui ne bidouillent pas et qui veulent juste être au courant d'un truc utile ou deux. Et heureusement, Vincent m'aide dans cette nouvelle aventure !

Bref, c'est vous qui choisissez votre flux, je ne vous l'impose pas ! Et c'est la même logique sur la page d'accueil avec ce petit switch dans le header.

"Complet", c'est l'affichage par défaut, vous voyez tout. Et si vous cliquez sur "Techos", hop, le contenu grand public disparaît. Votre choix est mémorisé dans le local storage de votre navigateur, et voilà.

Si vous n'avez pas encore de lecteur RSS, n'importe lequel fera l'affaire, de Feedly cité plus haut à un truc plus moderne comme MrRSS . Vous copiez l'adresse du flux, vous la collez, c'est réglé. Et tant qu'on y est, vous pouvez aussi reprendre la main sur votre actu côté Google avec cette manip.

Bref, deux flux, un switch, et c'est vous qui tenez le barre !

Source

*-- Contient des liens affiliés -- *

La Steam Machine de Valve vient à peine d'arriver dans les salons que le youtubeur ETA Prime l'a déjà éventrée sur son établi. Et je sais pas vous, mais moi j'ai bien envie de voir ça avant de lâcher les 1039 euros qu'elle va couter. Ce petit cube vient de sortir d'usine avec ses 16 Go de mémoire et un SSD de 512 Go ou 2 To, et la vraie question que tous les geeks se posent c'est ... roulements de tambour ... : Est-ce qu'on peut l'ouvrir et bidouiller dedans ?

ET BIEN OUI ! Et c'est même plus facile que ce que vous pensez !!!

À tous les nostalgiques de la Nintendo 64 et notamment de Super Mario 64, j'ai un petit truc cool à vous montrer. Tobi Friedly vient de sortir un portage du jeu sur Nintendo DS, et pas n'importe lequel, puisque celui-ci tourne sur la vraie console de 2004, et pas seulement sur la DSi qui embarquait quatre fois plus de mémoire vive. Et comme si ça suffisait pas, il y a même mis un mode deux joueurs.

C'est vrai que le truc qui coince d'habitude, c'est que la DS originale n'a pas assez de RAM pour charger toute la ROM du jeu d'un coup. Tobi a donc contourné le problème en faisant streamer les assets à la demande via NitroFS , le système de fichiers des cartouches DS.

Du coup, au lieu de tout balancer en mémoire d'un bloc, le jeu va piocher les niveaux et les textures au fur et à mesure qu'il en a besoin. C'est grâce à cette méthode ingénieuse qu'il a pu débloquer son portage sur la vraie DS, là où le portage précédent de Hydr8gon restait coincé sur DSi faute de place.

C'est d'ailleurs grâce au boulot de Hydr8gon que Tobi a construit le sien, en le modifiant et en l'adaptant suffisamment pour qu'il tourne sur tous les modèles de DS.

Au passage il a rebouché aussi deux bugs qui traînaient, et maintenant le jeu est finissable à 120 étoiles, et le son fonctionne enfin (avant c'était silence radio). La stabilité générale a aussi pris un bon coup de polish.

Le mode multijoueur, lui, réclame deux DS, chacune avec sa propre copie du jeu. C'est du coop local, parfait pour explorer le château à deux ou juste pour déconner ensemble, entre moustachus, dans un niveau de Mario.

Une équipe issue de l'université de Berkeley vient de publier OpenCAL, une version libre et documentée d'une technique d'impression 3D qui ne ressemble à rien de ce qu'on connaît, et le projet est désormais reproductible chez soi avec des composants qu'on trouve dans le commerce.

Le principe porte un nom un peu barbare, la lithographie axiale calculée (Computed Axial Lithography, ou CAL), mais l'idée derrière est étonnamment simple.

Une imprimante 3D classique à résine fabrique un objet en empilant des centaines de tranches horizontales, l'une après l'autre, comme on poserait des feuilles de papier les unes sur les autres jusqu'à obtenir un volume. C'est lent, et chaque couche laisse une petite marque parfois visible.

La CAL fait l'inverse. Au lieu de découper l'objet en strates, elle projette de la lumière dans un petit récipient de résine liquide qui tourne lentement sur lui-même, et l'image projetée change en permanence selon l'angle de rotation.

Cette technique reprend en fait le fonctionnement d'un scanner médical, mais à l'envers. Un scanner prend une multitude de clichés d'un corps sous tous les angles pour reconstituer une image en volume. Ici, on part de l'objet en 3D et un logiciel calcule toutes les projections à renvoyer dans la résine pendant qu'elle tourne.

Là où la lumière s'accumule suffisamment, la résine durcit. Partout ailleurs, elle reste liquide. Et comme le calcul concentre l'énergie sur l'ensemble du volume en même temps, la pièce entière se solidifie d'un coup, en quelques dizaines de secondes parfois, là où une imprimante normale mettrait de longues minutes voire des heures.

Pas de couches, donc pas de stries, pas de film FEP à changer (cette membrane transparente au fond des bacs à résine qui s'use vite), et aucun de ces cycles d'arrêt et de redémarrage qui ralentissent les machines habituelles.

La technologie n'est pas nouvelle, elle est née vers 2019 d'une collaboration entre Berkeley et le laboratoire de Lawrence Livermore, mais elle restait cantonnée à la recherche, hors de portée du grand public. C'est tout l'intérêt d'OpenCAL.

Le projet propose désormais une documentation tout à fait complète, un dépôt GitHub avec tout le code source, les plans pour monter la machine et même la recette pour mélanger soi-même la résine adaptée. Le logiciel tourne sur un simple Raspberry Pi et la lumière vient d'un vidéoprojecteur grand public, en l'occurence ici un NexiGo Nova Mini.

Le tout est publié sous licence GPL3, libre pour un usage non commercial, recherche et éducation. L'équipe travaillait surtout sur un serveur Discord avant de tout formaliser proprement.

Une réserve quand même, et elle est importante. La résine maison repose sur des produits photochimiques toxiques, et la documentation ne s'en cache pas. Pour ceux qui préfèrent éviter de manipuler ça, un partenariat avec FormLabs propose une résine prête à l'emploi.

Côté qualité, la résolution reste comparable à celle de vieilles imprimantes à résine, rien de spectaculaire. Mais la vitesse, elle, n'a rien à voir.

Bref, voir une technologie de labo digne d'un réplicateur de Star Trek atterrir sur un Raspberry Pi et un projecteur à moins de 200 euros, c'est quand même bien sympa.

Source : Hackaday

Une mise à jour récente du noyau Linux a cassé le support de certains adaptateurs Bluetooth MediaTek, ceux qui sont intégrés aux puces Wi-Fi qu'on trouve sur beaucoup de cartes mères modernes.

Le résultat : votre clavier sans fil, votre souris ou votre casque Bluetooth ne se connectent plus après la mise à jour. Pour les utilisateurs Linux, c'est le genre de régression franchement pénible, pour rester poli.

Al Williams raconte sur Hackaday avoir traqué le problème jusqu'à un fichier précis du noyau : btmtk.c, le pilote qui gère les puces Bluetooth MediaTek. Deux lignes de code suffisent à contourner le problème. Sa rustine consiste à remplacer une fonction de gestion d'erreur par une instruction qui marque la sortie comme "non terminée" et continue. C'est pas génial sur le papier, mais ça fait remarcher le matériel le temps qu'un correctif officiel arrive en amont.

Le problème, c'est que ce n'est pas un simple paramètre à changer. Il faut récupérer les sources du noyau, installer la boîte à outils de compilation, patcher la ligne concernée, recompiler juste le module problématique, l'installer dans /lib/modules, et rebooter.

Deux lignes. Pour un développeur Linux, c'est la routine. Pour un utilisateur lambda qui a juste envie que sa souris remarche, c'est franchement relou.

Al teste sa rustine sur OpenSUSE Tumbleweed (une distribution Linux à mises à jour continues), mais la procédure marche aussi sur Debian, Ubuntu et la plupart des autres distros, avec quelques ajustements de chemins. Il insiste : c'est temporaire. Le bug est connu des développeurs du noyau, et le correctif définitif devrait remonter dans les prochaines versions stables.

Le truc un peu naze, c'est que Bluetooth sur Linux a longtemps eu la réputation d'être un cauchemar. La situation s'était nettement améliorée ces dernières années avec BlueZ (la pile Bluetooth officielle de Linux) et le support natif dans la plupart des distros. Voir une régression d'envergure refaire surface en 2026 sur du matériel grand public, ça refait grincer des dents les vieux Linuxiens qui pensaient avoir refermé ce chapitre.

Et puis ça illustre bien le modèle de développement du noyau. Les régressions arrivent parce que le code évolue très vite et que tout le matériel ne peut pas être testé en permanence. Quand ça pète, la communauté patche. Quand le patch est validé, il remonte. C'est lent, mais ça finit toujours par marcher. Le truc, c'est qu'entre les deux, vous restez avec votre clavier Bluetooth en rade .

Si vous êtes touché par le problème, l'article complet d'Al Williams sur Hackaday donne toutes les commandes pas à pas . Le fix est documenté ligne par ligne, ça prend une trentaine de minutes pour quelqu'un qui est très à l'aise avec un terminal.

Source : Hackaday

Riley Testut et Shane Gill viennent de sortir une bêta d' AltStore Classic (la 2.3b1 ), qui supprime enfin le besoin d'avoir un ordinateur pour sideloader des apps sur iPhone. AltStore, pour ceux qui débarquent, c'est la boutique alternative qui installe des apps qu'Apple ne veut pas sur son store, sans jailbreak et pour l'utiliser jusqu'ici, il fallait garder un Mac ou un PC allumé avec AltServer pour réinstaller vos apps tous les 7 jours.

Mais maintenant, une simple connexion Wi-Fi suffit !!

Pour s'en servir, vous allez dans les réglages d'AltStore Classic et vous renseignez l'URL d'un "serveur anisette" et hop, l'app se mettra à causer directement aux serveurs d'Apple pour signer et rafraîchir vos installations, sans passer par AltServer. Pour l'instant c'est réservé aux AltStore Patrons (les abonnés Patreon), avec un déploiement grand public prévu une fois la bêta stabilisée.

L'anisette, c'est la donnée d'authentification que les serveurs d'Apple exigent pour valider une demande de signature. Avant, AltServer la générait depuis votre ordinateur, d'où l'obligation de l'avoir sous la main. En déportant ça sur un serveur anisette distant, AltStore se débrouille maintenant tout seul depuis le téléphone.

C'est bien pensé ! Du coup le refresh hebdomadaire se fait en silence, et gérer le plafond de 3 apps imposé par Apple devient indolore même si cette limite des 3 apps reste...

SideStore , un fork open source d'AltStore, fait du sideloading sans ordinateur depuis un bon moment, en montant un VPN WireGuard local qui fait croire à l'iPhone qu'un ordi est branché, donc oui c'est vrai, AltStore Classic arrive un peu après la bataille mais avec une approche différente, ce serveur anisette plutôt que le VPN.

Mais ces serveurs anisette, faut bien que quelqu'un les fasse tourner et quand ils tombent, votre sideloading tombe avec.... Les habitués de SideStore connaissent bien la chanson. Vous pouvez bien sûr héberger le vôtre si vous êtes du genre à bidouiller, mais sinon vous dépendrez d'un serveur communautaire... et de sa bonne santé.

Tout cela permet de reprendre un peu la main sur un iPhone qu'Apple a tenu verrouillé à double tour depuis bien trop longtemps. C'est grâce à ça que pas mal de gens peuvent aujourd'hui installer des émulateurs à l'ancienne comme Provenance , ou que la pression a fini par pousser Apple à accepter les émulateurs rétro sur son propre store.

Bref, si vous êtes Patron AltStore et sous iOS 17.4 ou plus, vous pouvez tester dès maintenant. Sinon, encore un peu de patience...

Source

Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?

Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.

Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".

Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...

Pourquoi Git laisse passer ça

Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.

Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.

Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :