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.
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.
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 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 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.
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 .
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 !
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.
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.
Vous glissez une app dans la corbeille du Mac, elle disparaît du dossier Applications, et vous pensez que c'est réglé ? Que vous êtes naïfs ! Hé oui, ce que vous ne savez pas, c'est que ses préférences, ses caches et son container restent bien présent dans votre ~/Library, parfois pendant des années, encombrant votre espace disque pour rien.
Hé bien s'occuper de tout ce merdier, c'est le job de PureMac , une app native codée en SwiftUI qui piste ces fichiers-là pour libérer des ressources sur votre mac. Elle croise l'identifiant du bundle, celui de l'équipe de développement, les entitlements et les métadonnées Spotlight, selon trois niveaux d'agressivité en fonction de ce que vous voulez ratisser.
Elle sait aussi prendre le problème dans l'autre sens puisque son chercheur de fichiers orphelins parcourt ~/Library pour retrouver les restes d'applications que vous avez virées il y a trois ans et dont plus rien ne vous rappelle l'existence.
Et si vous développez, il y a de quoi récupérer bien plus de place avec les DerivedData, les runtimes de simulateur Xcode, les couches Docker, les caches npm, yarn, pnpm et Homebrew. Bon, ça vous savez déjà le faire avec docker system prune, deux ou trois autres commandes, ou avec
Mole en ligne de commande
dont je vous ai déjà parlé. Mais l'intérêt ici, c'est de tout voir d'un coup avant d'arbitrer.
Côté données, il n'y a rien à surveiller puisque PureMac n'embarque aucune télémétrie ni appel réseau. Et la licence, c'est du 100% licence MIT, là où d'autres outils similaires comme Pearcleaner ajoute une Commons Clause qui en interdit la revente, que AppCleaner, lui, s'arrête à la désinstallation, ou encore que CleanMyMac nécessite d'acheter une licence.
Pour le faire tourner, il vous faut macOS 13 au minimum, et ça s'installe en une ligne avec brew install --cask puremac. Sinon, il y a un .dmg signé et notarisé à récupérer directement.
Par contre, sachez que ça réclame le l'accès complet au disque, soit la permission la plus large que macOS distribue, et il ne garde aucun journal des chemins qu'il a supprimés. Surtout que quand un fichier est supprimé, il l'est pour de bon, donc vérifiez bien les choses avant de les supprimer.
Le nettoyeur de caches, est également une opération sans retour. Alors pour un cache ça n'a pas d'importance, puisqu'il se régénèrera tout seul. Mais pour un reste dans ~/Library qui contenait, j'sais pas, par exemple une licence, un wallet crypto ou vos réglages, c'est une autre affaire.
Donc soyez TRÈS prudent et lisez bien les chemins d'accès vers les fichiers avant de cliquer pour les supprimer, histoire de pas faire de conneries.
L'université de Cambridge prépare un petit satellite baptisé CosmoCube, pas plus gros qu'une valise cabine, qui partira se cacher derrière la Lune pour tenter d'entendre ce que l'univers racontait avant même l'allumage des premières étoiles.
Ce qu'il cherche, c'est la fameuse raie à 21 centimètres, un signal radio émis par l'hydrogène neutre pendant les âges sombres, cette période d'environ 150 millions d'années coincée entre le Big Bang et la naissance des premières étoiles.
À cette époque, aucun astre ne brille encore, donc aucun télescope classique n'a quoi que ce soit à regarder. L'hydrogène qui remplissait l'univers a en revanche laissé cette minuscule empreinte radio, et elle contient des informations sur la formation des toutes premières structures cosmiques.
Sauf que voilà, plus de treize milliards d'années d'expansion ont étiré ce signal vers les très basses fréquences, entre 10 et 100 MHz, exactement là où la Terre braille en permanence avec sa radio FM, ses communications et son ionosphère qui brouille tout.
D'où l'idée d'aller se réfugier derrière la Lune, l'endroit le plus silencieux du système solaire pour les ondes radio. Toute la mission tient sur une orbite de deux heures, dont environ 40 minutes de silence complet quand la Lune s'intercale entre le satellite et nous. C'est court. Mais c'est déjà infiniment mieux que tout ce qu'on peut espérer depuis la Terre, et l'antenne déployable couplée à un radiomètre étalonné aux petits oignons doit suffire à extraire ce murmure vieux de plus de treize milliards d'années.
Le budget reste raisonnable pour de la cosmologie, avec moins de 50 millions d'euros, dont plus de 2 millions de livres déjà posés par l'agence spatiale britannique, avec un décollage espéré d'ici cinq ans.
Il faudra juste faire vite. Les missions lunaires américaines et indiennes se multiplient, avec les satellites relais qui vont avec, et le dernier endroit vraiment silencieux du système solaire pourrait ne pas le rester très longtemps.
Source : Generation NT
À Milan, une affiche Apple montre un tout petit enfant qui tient un iPhone couvert d'une substance gluante, sous le slogan "Tutto ok, è iPhone", tout va bien, c'est un iPhone. L'autorité italienne de protection de l'enfance ne l'a pas du tout prise comme une blague.
Le visuel appartient à la campagne mondiale "Relax, it's iPhone", qui décline depuis des mois le même gag d'un téléphone qui ressort indemne des petites catastrophes du quotidien. Ici, la catastrophe a deux ans et les mains pleines de bouillie.
Une habitante de Milan, dérangée par l'image, l'a signalée à l'AGIA, l'autorité garante de l'enfance et de l'adolescence. Celle-ci a embrayé direct.
Pour l'autorité, cette affiche banalise le baby-sitting électronique, cette habitude de coller un smartphone dans les mains des très jeunes enfants pour avoir la paix, avec un risque de dépendance à la clé et des conséquences sur leur développement psychologique et cognitif.
Le dossier a du coup été transmis à trois organismes, le régulateur des communications, l'autorité de la concurrence et l'institut d'autodiscipline publicitaire, pour d'éventuelles suites. Aucune décision n'est tombée pour le moment. bien sûr, c'est un peu tôt encore.
Apple voulait probablement dire autre chose : votre téléphone survivra si le petit dernier s'en empare, l'écran encaisse la bave et la purée de carottes. Sauf que voilà, sur ce panneau, le double sens existe, et il ne reste qu'un bébé absorbé par un iPhone.
Le moment est mal choisi. Plusieurs pays débattent d'un âge minimum pour les réseaux sociaux, et les autorités de santé répètent depuis des années qu'avant trois ans, l'écran est à proscrire tout court.
On comprend le problème, et il faut dire que l'image est gênante pour une marque qui vante par ailleurs son mode Temps d'écran et ses outils de contrôle parental à chaque conférence.
Apple n'a pas commenté. La campagne, elle, poursuit tranquillement sa tournée mondiale.
Source : Mac4ever
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...
Si vous avez un serveur Pi-hole à la maison, il a dû vous arriver qu'un site déconne, qu'une image ne charge pas, ou qu'un simple bouton ne réponde plus. Alors pour remédier à ça, vous ouvrez un onglet vers l'admin Pi-hole, vous fouillez dans les requêtes bloquées, vous whitelistez au jugé, puis vous rechargez pour voir si ça marche. Ça prend 30 secondes à chaque fois, ça casse les couilles et ça arrive plus souvent que ce qu'on aimerait...
Mais heureusement, Holeberry met tout ça dans la barre de menus de macOS pour vous faire gagner grave de temps
L'app détecte l'onglet actif de Safari, Chrome ou Firefox et débloque le domaine correspondant en un clic. Comme ça, plus besoin de deviner lequel des quarante domaines bloqués casse la page. Elle affiche aussi les derniers blocages en direct, et permet de couper le filtrage pour une durée choisie, le temps de finir un achat en ligne qui n'aime pas les bloqueurs.
Elle peut aussi gérer deux instances Pi-hole en parallèle avec synchronisation, pratique quand on a un Pi principal et un secondaire qui prend le relais. Les identifiants partent dans la Keychain macOS et pas dans un fichier de conf qui traîne comme ça c'est sécurisé. Et surtout, ça supporte Pi-hole v5 et v6 aussi bien en local qu'à distance.
Si ça vous branche, notez que l'app n'est pas notarisée, donc Gatekeeper va faire la gueule. La commande pour passer outre est indiquée dans le README :
xattr -cr /Applications/Holeberry.app
Mais vous pouvez aussi utiliser Sentinel pour faire ça.
À récupérer sur GitHub pour ceux qui veulent !
Six chercheurs d'UC San Diego et d'Oberlin College ont présenté le 13 août dernier à l'USENIX Security Symposium de Baltimore un implant assez petit qui se branche sur un port de maintenance de la baie électronique d'un Boeing 737 et s'intercale ainsi entre le calculateur de vol et l'écran par lequel les pilotes le programment.
La trappe présente sur l'avion, qui y mène n'a ni serrure ni contrôle d'accès et est accessible depuis le sol, sans échelle. Les chercheurs estiment que ça peut se mettre en place en moins de 60 secondes, ouverture et refermeture comprises. Le boîtier, lui, disparaît sous le capuchon anti-poussière du connecteur.
Hé oui c'est un simple capuchon en plastique qui "protège" l'accès aux commandes de navigation d'un avion de ligne. C'est beau non ?
Ce connecteur donne un accès aux bus ARINC 429 qui transmette les échanges entre le calculateur, le FMC, et le clavier-écran du cockpit, le MCDU. La norme date de 1977 et ne prévoit aucune authentification et comme vous vous en doutez, c'est connu depuis longtemps, même si le plus souvent, les attaques envisagées sur les systèmes d'un avion visaient plutôt ses liaisons radio.
Toutefois, se brancher sur le bus ne suffit pourtant pas à le contrôler, puisque les autres équipements continuent d'émettre par-dessus. Sauf que les émetteurs légitimes passent par des résistances de 37,5 ohms qui brident leur courant, alors que le connecteur de maintenance, lui, attaque le bus en direct.
L'implant en profite alors pour pousser plus de courant que l'émetteur d'origine et écraser physiquement son signal. Les chercheurs appellent ça une attaque Bus Driver, et elle donne une interception complète du dialogue sans couper ni épisser le moindre fil.
Une fois ce dialogue sous contrôle, le boîtier ajoute un point de passage à la route programmée. Normalement, sur un 737, cette modification doit être confirmée par le pilote, qui appuie sur le bouton EXEC. Mais l'implant, lui, appuie tout seul, l'autopilote change de cap, et comme le voyant du bouton passe par le même bus, il reste éteint. Et comme les pages affichées sont réécrites en live pour montrer encore l'ancienne route, rien à l'écran ne trahit le changement.
Le même mécanisme peut servir aussi à fausser la masse de l'appareil saisie avant le départ, ou la température retenue pour calculer la poussée. Une masse sous-évaluée ou une température trop basse, et le calculateur commande alors une poussée insuffisante au décollage.
Bref, c'est la cata assurée... Et cela vaut pour tous les 737 NG et MAX.
Maintenant, reste à savoir dans quelles conditions cette attaque peut être réalisée. Car jusqu'à présent, tout a été validé mais uniquement sur un banc de vraies pièces de 737 câblées selon les schémas Boeing, et jamais sur un avion en service. Le Wi-Fi est bien intégré au boîtier, mais le papier précise que les auteurs n'ont pas pu tester si le signal de la cabine traverse le plancher de la baie.
Boeing a bien sûr été prévenu en avril 2020, et les chercheurs ont rejoué l'attaque avec succès sur le banc d'essai du constructeur en décembre 2023. Ils proposent de boucher ce type de connecteur, ou d'y déplacer les résistances de limitation. Boeing, lui, estime que "les couches de protection en place sur l'avion" limitent déjà "significativement la faisabilité et le risque d'attaques en conditions réelles".
Ouais les gars ont la flemme de sécuriser leur truc on dirait...
Un pirate qui se fait appeler ZeroBytes a revendiqué mercredi, sur un forum fréquenté par les cybercriminels, le vol de près de 680 000 lignes de données extraites d'un outil interne de la Direction générale des Finances publiques. Bercy a confirmé l'intrusion dès le lendemain.
L'attaque ne date pourtant pas d'hier. Elle remonte à la fin juin, au 26 très exactement selon le pirate, et l'administration l'avait détectée puis interrompue à l'époque, sans jamais en toucher un mot publiquement.
Dans le lot, on trouve des noms, des dates de naissance, des adresses et des informations foncières et cadastrales, pour environ 390 000 particuliers et 285 000 professionnels. Les mots de passe et les coordonnées bancaires ne figurent pas parmi les données citées.
ZeroBytes raconte s'être promené de serveur en serveur avant de décrocher un accès VPN, la porte d'entrée à distance du réseau, qui lui a ouvert plusieurs outils internes du fisc. La version officielle parle plus sobrement d'une usurpation d'identité ayant permis un accès illégitime.
Une seconde fuite circule aussi sur les mêmes forums et toucherait environ 2 millions de propriétaires, mais celle-là n'a rien d'officiel pour le moment.
L'ANSSI, le pompier informatique de l'État, enquête, et la CNIL a été prévenue comme la loi l'impose.
Le fisc n'en est pourtant pas à son coup d'essai. Entre fin janvier et mi-février, des pirates avaient déjà consulté frauduleusement 1,2 million de comptes bancaires dans le fichier FICOBA, en utilisant les identifiants compromis d'un agent. Deux intrusions en un an, ça commence à faire beaucoup.
Dans l'immédiat, méfiez-vous des mails, des SMS et des coups de fil qui se réclament des impôts, surtout s'ils alignent vos vraies informations personnelles pour vous mettre en confiance. Une adresse exacte et une date de naissance correcte ne prouvent plus rien du tout.
Reste à savoir quand chacun des 680 000 concernés recevra le petit message l'informant que ses données se baladent dans la nature.
Source : Cyberattaque.org
SpaceXAI, la maison d'Elon Musk née de la fusion entre SpaceX et xAI, a mis en ligne mardi la bêta de Grok Bot. L'outil installe des agents IA sur une machine distante qui leur appartient, et ces agents continuent d'avancer sur leurs missions une fois votre ordinateur, même refermé. Vous dormez, eux non.
Un bot garde le contexte de sa tâche pendant des heures et ne vous sollicite que pour valider un envoi ou trancher une décision qui l'a bloqué.
Quand un projet se découpe en plusieurs morceaux, les bots se le répartissent en discutant entre eux dans une messagerie commune, un peu comme le ferait une petite équipe dans un canal Slack.
Ces agents ouvrent vos applications et vos sites web avec vos propres identifiants, exactement comme vous le feriez au clavier, sans passer par les interfaces officielles que les logiciels s'offrent entre eux. Les agents d'OpenAI, d'Anthropic ou de Google savent déjà faire du travail de bureau, sauf que chez eux vous ouvrez la session vous-même avant de laisser la main. Ici, le bot se débrouille.
La bêta tourne sur Mac, iOS, Windows et Linux. Android suivra.
Il faut par contre y mettre le prix. SuperGrok Heavy coûte 300 dollars par mois, et les abonnés de Cursor, l'éditeur de code boosté à l'IA, y accèdent avec les formules à 120 ou 200 dollars. Aucun tarif en euros n'a été communiqué pour le moment, et les entreprises font la queue sur une liste d'attente.
SpaceXAI a annoncé en juin le rachat d'Anysphere, la maison mère de Cursor, pour 60 milliards de dollars, un record pour une startup. Les régulateurs n'ont pas encore donné leur feu vert, ce qui n'empêche visiblement pas les deux équipes d'avancer main dans la main. Grok 4.6, un modèle conçu pour tenir des tâches longues sans perdre le fil, est d'ailleurs sorti le lendemain de la bêta.
En juillet, Grok Build, l'outil de codage de la même maison, expédiait des dépôts Git entiers vers ses serveurs, avec les clés d'API dedans. Confier l'ensemble de ses comptes à un agent autonome demande du coup beaucoup de confiance.
C'est un usage de l'IA vraiment fascinant qui va clairement se généraliser dans les années à venir, j'ai hâte de voir ce que ça donnera.
Source : The Verge