Pour la première fois, des prototypes de la supercar Gordon Murray T.33 ont été surpris lors d’essais hivernaux en Europe du Nord.



Gaël Musquet, mon copain hacker, me parlait déjà de tracking TPMS en 2020. Du coup, quand je vois des chercheurs publier un document de recherche en 2026 pour "découvrir" qu'on peut pister une voiture via ses capteurs de pneus, bon, comment dire... je suis pas tombé de ma chaise.
Mais faut reconnaître que l'étude en question va quand même plus loin qu'une discussion entre 2 stands au FIC. En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !
un Raspberry Pi 4 avec un dongle RTL-SDR - Source
Car oui, vous ne le savez peut-être pas, mais les capteurs de pression des pneus (TPMS pour les intimes) émettent régulièrement dès que le véhicule roule, sur 433 MHz en Europe. Et ces signaux contiennent un identifiant unique... qui bien sûr est en clair ^^. Pas de chiffrement, pas d'authentification, QUE DALLE. Donc avec un logiciel open source comme rtl_433 , ça devient vite facile de capter tout ça à plusieurs dizaines de mètres à la ronde.
En croisant les identifiants captés par plusieurs récepteurs, les chercheurs ont pu reconstituer les trajets des véhicules, identifier leurs horaires de travail, détecter les jours de télétravail et même estimer les variations de charge du véhicule (et potentiellement déduire la présence de passagers, même si c'est encore approximatif). Le tout sans caméra, sans GPS, et sans accès au réseau du véhicule !
Il suffirait de trouver l'identifiant d'une voiture précise pour déclencher par exemple automatiquement un lâcher de confettis en papier parfaitement inoffensifs à son passage, si vous voyez ce que je veux dire.
Alors attention, tous les véhicules ne sont pas logés à la même enseigne. Les TPMS dits "directs" (dTPMS), qu'on trouve souvent chez Toyota, Peugeot, Citroën, Hyundai ou Mercedes, émettent ces fameux signaux radio captables. Alors que les systèmes "indirects" (iTPMS), utilisés par la plupart des modèles Volkswagen, Audi ou Skoda, se basent sur les capteurs ABS et n'émettent rien par radio. Bref, si vous roulez en Golf de base, y'a de bonnes chances que vous soyez tranquilles sur ce coup-là même si certaines versions sportives ou haut de gamme (Golf R, GTI selon les marchés) peuvent embarquer du dTPMS.
Et le pire dans tout ça c'est que la réglementation UN R155 sur la cybersécurité automobile n'impose pas explicitement le chiffrement des TPMS. En gros, les constructeurs ne sont pas forcés de sécuriser ces transmissions. Pirelli et Bosch bossent bien sur un "Cyber Tyre" en Bluetooth Low Energy, mais c'est réservé au haut de gamme et c'est pas demain que ça arrivera sur votre Clio.
Donc côté protection, soyons honnêtes, y'a pas grand-chose à faire côté utilisateur. Vous ne pouvez pas désactiver vos TPMS (c'est obligatoire depuis 2014 pour les voitures neuves en Europe), et les capteurs ne proposent aucune option de chiffrement. Sauf si vous roulez en véhicule vintage d'avant 2014, c'est open bar. Une des parades serait que les constructeurs implémentent un système de rotation d'identifiants, un peu comme le fait déjà le Bluetooth avec les adresses MAC aléatoires, mais pour l'instant on en est loin.
Cela dit, comme me le fait remarquer Mathieu Passenaud, faut quand même relativiser. Pour tracker une voiture, y'a déjà un identifiant bien plus pratique... la plaque d'immatriculation. Écrite en gros, visible à l'oeil nu. Une caméra et OpenCV, c'est moins cher et plus fiable qu'un setup SDR. Le numéro de VIN est aussi accessible publiquement au niveau du pare-brise, et celui-là permet carrément de remonter au hardware embarqué du véhicule ( Mathieu a d'ailleurs documenté le cas John Deere qui lie sa plateforme aux engins via le VIN visible sur le châssis).
Et puis y'a un détail technique que personne ne mentionne... le déplacement. Un message TPMS c'est 12 à 20 octets émis entre 5 et 10 kbps, soit 10 à 20 ms de transmission. Sauf qu'à 130 km/h, la voiture avance de 3 cm par milliseconde, ce qui complique sérieusement la captation. Ajoutez que le TPMS n'émet que toutes les minutes environ (faut être pile au bon endroit au bon moment), et le scénario du tracking massif en conditions réelles, c'est quand même autre chose qu'en labo.
Pour ceux qui veulent creuser le sujet, j'avais fait une rencontre avec Gaël Musquet il y a quelques années, où il expliquait déjà comment reprendre le contrôle de nos véhicules connectés. Et si vous voulez comprendre comment on hacke une voiture de manière plus générale, c'est un rabbit hole sans fond !
Bref, la prochaine fois que vous gonflez vos pneus... dites-leur bonjour de ma part.


Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.
Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.
Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.
Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.
L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec KRACK en 2017. Pas un amateur, quoi. Et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence NDSS 2026 .
Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).
La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.
Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en WPA2 ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !
Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils ont pu intercepter tout son trafic, ni vu ni connu.
Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.
Côté utilisateur, la solution est plus simple... VPN !! Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel réseau WiFi public , partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.
Le code source d' AirSnitch est dispo sur GitHub si vous voulez tester votre propre config mais notez que ça nécessitera une carte WiFi compatible avec le mode monitor comme les Alfa (lien affilié), donc pas celle de votre laptop de base.
Bref, la prochaine fois que le WiFi de l'hôtel vous demande d'accepter les CGU en échange d'un accès "sécurisé"... ben gardez votre VPN allumé, hein.



Roborock lance en France, dès le 26 février 2026, deux nouvelles gammes d’aspirateurs-robots issues du CES : Saros 20 et Qrevo Curv 2 Flow, avec offres de lancement pour tous.
Depuis quelques années, Roborock s’est imposé comme l’un des noms majeurs du nettoyage robotisé. Son catalogue couvre aujourd’hui plusieurs gammes, du milieu de gamme au très haut de gamme avec une présence en Europe. On y croise par exemple des références populaires comme les Q8 Max/Q8 Max+ côté milieu de gamme, la famille Qrevo avec station tout-en-un, et des modèles vitrine S8 Pro Ultra ou S8 MaxV Ultra pour le très haut de gamme.
Pour 2026, la série Saros 20 vise le premium avec la navigation StarSight 2.0 (3D ToF) et le châssis AdaptiLift 3.0, capable d’aborder seuils et tapis tout en délivrant jusqu’à 36 000 Pa. De son côté, le Qrevo Curv 2 Flow mise sur la serpillière-rouleau SpiraFlow, une pression de 15 N et une station tout-en-un pour un entretien largement automatisé. On fait les présentations d’usage !
Avec le Saros 20, Roborock fait clairement évoluer sa série premium “Saros” : l’objectif est d’automatiser davantage le nettoyage, y compris dans les logements “difficiles” (seuils marqués, tapis épais, meubles bas). Le robot conserve un format très fin pour passer sous les meubles (jusqu’à 7,95 cm) et s’appuie sur la navigation StarSight 2.0 (détection 3D ToF) capable de reconnaître plus de 300 objets afin d’éviter câbles, jouets ou gamelles.

La comparaison avec le Saros 10 est assez parlante : on passe d’une aspiration annoncée à 22 000 Pa à 36 000 Pa sur le Saros 20, avec un gain immédiat attendu sur les tapis et les saletés incrustées. Surtout, la mobilité progresse fortement : le Saros 10 était annoncé pour franchir des seuils jusqu’à 4 cm, quand le Saros 20 revendique 8,8 cm (en “double niveau”). Enfin, la station monte en température : lavage des serpillières jusqu’à 100°C (contre 80°C sur Saros 10), avec séchage à air chaud et vidage automatique jusqu’à 65 jours selon la marque.
Il se décline en deux versions très proches : le Saros 20 Set et le Saros 20X. Les deux dénominations désignent le même robot, mais pas le même circuit ni le même package. Le Set est vendu en ligne (Roborock/Amazon) et inclut 2 sacs + 2 serpillières supplémentaires. Le 20X vise les enseignes (Boulanger/Fnac Darty) avec un pack différent, et un prix public légèrement inférieur après l’offre de lancement.
| Caractéristique Techniques | Roborock Saros 20 |
|---|---|
| Dimensions | Robot : 353 × 350 × 79,8 mm Station : 381 × 475 × 488 mm |
| Poids | Robot : 5,05 kg Station : 10,54 kg |
| Capacité de franchissement d’obstacles | seuils à double niveau jusqu’à 8,8 cm (4,5 + 4,3 cm) |
| Puissance d’aspiration | 36 000 Pa |
| Pression vers le sol | 8 N en lavage “standard” (jusqu’à 13 N) |
| Double serpillière rotative | 200 tr/min |
| Batterie | Li-ion 14,4 V / 6 400 mAh |
| Autonomie/Temps de charge | 180 min/150 min |
| Bacs robot | bac à poussière : 259 mL réservoir d’eau propre : 65 mL |
| Volume du sac à poussière | 2,5 L |
| Capacité du réservoir d’eau propre / usée | 4,0 L/3,5 L |
| Prix | 1 499 € |
Avec le Qrevo Curv 2 Flow, Roborock introduit une approche “rouleau” pour le lavage, pensée pour rester propre pendant tout le cycle. Le système SpiraFlow alimente le rouleau en eau fraîche et évacue l’eau sale, tandis que la marque annonce une pression de 15 N et une rotation jusqu’à 220 tr/min pour mieux décoller les taches. À l’aspiration, on retrouve 20 000 Pa, complétés par les fonctions DirTect (adaptation au type de saleté) et Reactive AI avec plus de 200 objets reconnus pour éviter les obstacles.

La comparaison la plus logique se fait avec le Qrevo Curv 2 Pro / ProX, lancé juste avant à 1299 €. Ce dernier a été reconnu pour son format ultra-fin, dû au capteur LiDAR rétractable, et sa puissance d’aspiration plus élevée (25 000 Pa), avec un lavage assuré par double serpillières rotatives. À l’inverse, le Curv 2 Flow assume un gabarit plus haut (11,9 cm), mais mise sur un lavage plus “continu” grâce au rouleau et sur une protection tapis dédiée : rouleau relevable jusqu’à 15 mm et le module Roller Shield qui fait barrière à l’humidité.
En France, la gamme se décline en deux versions : Qrevo Curv 2 Flow et Qrevo Curv 2 FlowX. Sur le produit FlowX (circuit revendeurs), le contenu du carton mentionne notamment 2 sacs et 1 filtre. Côté tarifs, Roborock annonce un prix de lancement à 699 € du 26 février au 11 mars 2026, puis 899 €. Bien sûr, cela le rend beaucoup plus agressif sur les tarifs que son prédécesseur !
| Caractéristique Techniques | Roborock Saros 20 |
|---|---|
| Dimensions | Robot : 353 × 353 × 119 mm Station : 450 × 450 × 450 mm |
| Poids | Robot : 5,30 kg Station : 8,93 kg |
| Capacité de franchissement d’obstacles | jusqu’à 2,0 cm |
| Puissance d’aspiration | 20 000 Pa |
| Pression vers le sol | jusqu’à 15 N |
| Double serpillière rotative | 220 tr/min (max) |
| Batterie | Li-ion 14,4 V / 5 200 mAh |
| Autonomie/Temps de charge | 220 min / 180 min |
| Bacs robot | bac à poussière : 324 mL réservoir d’eau propre : 102 mL |
| Volume du sac à poussière | 2,5 L |
| Capacité du réservoir d’eau propre / usée | 4,0 L/3,0 L |
| Prix | 899 € |
En bref, Roborock déroule une stratégie très lisible en France : Saros 20 pour ceux qui veulent le meilleur (puissance, franchissement, navigation et station ultra complète), et Qrevo Curv 2 Flow pour viser plus large avec un lavage à rouleau pensé “propreté en continu” à un tarif nettement plus accessible, surtout pendant l’offre de lancement !
Les deux gammes arrivent dès le 26 février 2026, avec promos jusqu’au 11 mars : de quoi rendre l’entrée sur le marché encore plus agressive ! Allez vous vous laisser tenter ? Ou préférez-vous attendre les autres sorties de l’année chez la concurrence féroce ?


Hey mais on dirait bien que c'est Red Hat qui débarque sur le marché des apps desktop pour conteneurs... mais lol ! Car oui, pendant que Docker Desktop trône depuis des années et qu'OrbStack séduit de plus en plus d'utilisateurs macOS, Red Hat se réveille ENFIN avec sa propre version Enterprise de Podman Desktop .
Bah mieux vaut tard que jamais !
Pour ceux qui débarquent (bouuuuh) Podman Desktop, c'est un outil open source qui existe depuis des années pour gérer vos conteneurs, images et pods via une interface graphique. C'est dispo sous Linux, macOS, Windows et le projet a même rejoint la CNCF (rien à voir avec les trains... lool) en janvier 2025 en même temps que d'autres briques Red Hat (Buildah, Skopeo, bootc, Composefs... chacun en projet séparé).
Interface de Podman Desktop
Et donc Red Hat a décidé de lancer sa propre "build" enterprise de cette app de conteneurs. En gros, c'est la même base que Podman Desktop, mais avec une couche admin par-dessus. Les responsables IT peuvent donc verrouiller des paramètres au niveau de la flotte tels que les registry mirrors, proxies HTTP, certificats custom... On est dans une ambiance un peu plus corporate quoi.
Côté Kubernetes, c'est également plutôt bien pensé. Vous créez vos pods en local, l'outil génère le YAML correspondant, et hop, déploiement sur Kind, Minikube ou directement sur OpenShift, les doigts dans le nez.
Pour ceux qui se demandent si ça remplace Docker Desktop, bah, ça dépend en fait. Podman tourne sans daemon et en rootless, du coup c'est un vrai plus côté sécurité. Mais par contre, le support Docker Compose passe par un système d'aliasing... ça marche bien, sauf si vous avez des configs Docker très exotiques... là faudra tester avant de tout basculer comme le early adopter fifou que vous êtes.
D'ailleurs, si vous êtes sur RHEL, Podman est déjà inclus dans votre abonnement et Red Hat a aussi bossé sur des extensions pour les images bootable OCI et le mode image RHEL.
Le truc, c'est que Red Hat arrive tard. TRÈS tard. Docker Desktop, c'est le standard de facto depuis des lustres, OrbStack a conquis les devs macOS avec sa légèreté sans oublier que Rancher Desktop et Portainer Business Edition occupent aussi le terrain. Du coup, leur stratégie c'est de cibler les boîtes déjà full Red Hat plutôt que d'essayer de convertir les utilisateurs Docker. C'est une ambition plutôt réaliste, je trouve.
Ça vient donc de passer en disponibilité générale via les canaux développeurs Red Hat, c'est gratuit, open source, et plutôt bien fichu pour ceux qui bossent dans un environnement RHEL au quotidien. Après, c'est pas non plus la révolution car ça reste Podman Desktop avec un petit chapeau d'entreprise.
Je pense que pour un usage hors Red Hat, Docker Desktop ou OrbStack restent devant. Mais si vous avez l'abonnement RHEL, ça peut valoir le coup d'y jeter un oeil.

Les clés API Google que vous collez dans votre JavaScript pour afficher une carte Maps... hé bien elles ne sont plus si inoffensives. Car depuis que Gemini est entré dans la danse, ces mêmes clés donnent maintenant accès à vos fichiers privés et surtout à votre facture IA.
Et personne ne nous a prévenu...
En gros, Google utilise un format de clé unique, les fameuses AIza..., aussi bien pour Maps et Firebase (public, collé dans le HTML, tout le monde s'en fout) que pour
Gemini
(privé, accès aux fichiers, facturation). Le problème c'est que quand vous activez l'API Gemini sur un projet Google Cloud, TOUTES les clés existantes de ce projet héritent automatiquement de l'accès Gemini. Sans warning, sans notification, sans rien... Ouin !
Les chercheurs de
TruffleSecurity
ont ainsi trouvé presque 3000 clés API Google valides dans le dataset Common Crawl de novembre 2025. Des clés qui trainent dans du code JavaScript, des pages HTML, des repos GitHub publics... et qui fonctionnent sur l'endpoint Gemini. Il suffit d'un simple curl avec une clé Maps récupérée sur un site web, et hop, vous accédez à l'API Gemini du propriétaire. Fichiers privés, contenu en cache, facturation sur son compte.
Et parmi les victimes, on trouve des institutions financières, des boîtes de cybersécurité, et... Google eux-mêmes (oui oui, vraiment).
Le 21 novembre 2025, TruffleSecurity signale donc le problème et la réponse de Google le 25 novembre c'est : "intended behavior" (comportement normal)... Sauf que le 2 décembre, Google a reclassifié ça en bug, puis le 13 janvier 2026, ça passe finalement en Tier 1. On est donc passé du "c'est normal les frérots" à "ah oui quand même, oupsi oups", en 7 semaines.
Maintenant, pour ceux qui se demandent si leurs clés API Google sont concernées, direction console.cloud.google.com , section "APIs & Services" puis "Identifiants".
Si vous voyez l'API " Generative Language " de Gemini API activée sur un projet avec des clés non restreintes... attention, c'est le moment de faire le ménage. Ajoutez des restrictions IP ou HTTP referrer, et surtout, utilisez des comptes de service plutôt que des clés API pour tout ce qui touche à Gemini (sauf si vous aimez les surprises sur votre facture ^^).
Le truc tordu, c'est que la doc Firebase dit noir sur blanc que les clés API ne sont pas des secrets. Google Maps vous dit carrément de les coller dans votre HTML. Et maintenant, ces mêmes clés donnent accès à une IA qui peut lire vos fichiers. Du CWE-1188 pur et dur ! Et c'est pas la première fois que Google se fait taper sur les doigts pour ce genre de souci avec Gemini .
Du coup, Google a annoncé des nouvelles mesures, du scoped defaults, du blocage de clés fuités, des notifications proactives...etc. Reste donc à voir si ça arrivera avant que les presque 3000 clés exposées soient exploitées par des gens moins bien intentionnés.
Bref, dix ans à dire que c'est public, et hop, aujourd'hui c'est devenu top secret. Bien joué Google !!
