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.
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.
2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.
En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.
> - Écrire dans un fichier (et tout écraser)echo "Salut" > fichier.txt
Ça redirige stdout vers fichier.txt. Si le fichier existe déjà... c'est mort, il est écrasé sans sommation. Du coup, faites gaffe avec vos logs, une commande mal placée et ce sont des heures de données qui disparaissent.
D'ailleurs, si vous êtes du genre parano (et oui, vous avez raison !), set -o noclobber dans votre .bashrc empêchera > d'écraser un fichier existant lors d'une commande tapée à la main. Pour y arriver, il faudra utiliser >| pour forcer.
>> - Ajouter à la suiteecho "Ligne 2" >> fichier.txt
Même principe que >, sauf que ça ajoute à la fin au lieu d'écraser. C'est ce que vous voulez 99% du temps pour des logs (sauf si vous voulez repartir de zéro, là > fait le job). Une lettre de différence entre "tout va bien" et "où sont passés mes logs, boudiouuu ???".
2> - Rediriger les erreurscommande_foireuse 2> erreurs.log
Le 2 c'est stderr, en gros (y'a pas d'espace entre le 2 et le >, sinon bash croit que 2 est un argument). Tout ce qui sort en erreur finit dans erreurs.log au lieu de polluer votre terminal. Perso, je trouve ça super pratique pour garder une trace propre quand vous lancez des scripts via crontab -e.
Et 2>> existe aussi, pour cumuler les erreurs au fil du temps au lieu d'écraser le fichier à chaque exécution.
2>&1 - Fusionner erreurs et sortie normalecommande > output.log 2>&1
Le fameux ! Le &1 dit à bash "le 1 c'est un file descriptor, pas un fichier qui s'appelle littéralement 1". Du coup stderr (2) est redirigé vers le même endroit que stdout (1), ou plutôt vers là où stdout pointe au moment où bash évalue la ligne. Ça va, vous suivez toujours ? ^^
Attention, l'ordre compte ! Bash lit les redirections de gauche à droite. > output.log 2>&1, stdout pointe vers le fichier, puis stderr suit... tout va dans le fichier. 2>&1 > output.log, stderr copie stdout qui pointe ENCORE vers le terminal, puis stdout est redirigé vers le fichier. Résultat, les erreurs restent dans votre terminal. Le piège classique.
Et &> fait la même chose en plus court :
commande &> output.log
&> est super pratique, mais spécifique à bash / zsh donc pour la portabilité, préférez quand même > fichier 2>&1.
2>/dev/null - Le trou noirfind / -name "*.conf" 2>/dev/null
/dev/null, c'est le trou noir d'Unix. Tout ce que vous envoyez là-dedans disparaît. Super pratique avec find qui vous crache 200 "Permission denied" pour un seul résultat utile.
Et si vous voulez TOUT faire disparaître (stdout + stderr) ? Un petit &>/dev/null et c'est réglé. Pratique dans vos scripts /etc/cron.d/ quand vous voulez zéro bruit (bon, j'exagère un chouïa, je sais...).
Si vous aimez les raccourcis bash , j'ai aussi ce qu'il faut.
Bref, voilà ce sont juste 5 opérateurs à retenir, et avec ça vous couvrez à peu près tout. Donc la prochaine fois que vous copierez un 2>&1, au moins vous saurez pourquoi.
Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...
En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !
Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.
Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"
Et la réponse des devs : Won't Fix. Circulez les relous !
En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.
D'ailleurs,
en 2013 je vous expliquais comment activer ces étoiles manuellement
avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.
Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...
Alors pour désactiver ces jolies zétoiles :
sudo visudo
Et ajoutez cette ligne à la fin de /etc/sudoers :
Defaults !pwfeedback
Sauvegardez (Ctrl+X sous nano), et c'est réglé. Attention, ne touchez à rien d'autre dans ce fichier, une erreur de typo et sudo ne marchera plus. Grâce à cette manip, ce sera retour au trou noir ! Youpi !
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.
Les 404, c'est la plaie du web... J'en sais quelque chose, je fais la chasse à ça en permanence sur mon propre site. C'est vrai que c'est relou parce que vous bookmarkez un projet cool, vous y retournez trois mois après... et pouf, ça a disparu. Le dev n'a pas renouvelé son nom de domaine, l'hébergeur a fermé boutique, le contenu s'est évaporé ou que sais-je encore... En fait, sur le web, RIEN n'est permanent.
PinMe prend le problème à l'envers en collant vos fichiers directement sur IPFS . En gros, au lieu de dépendre d'un serveur unique qui peut tomber n'importe quand, vos pages sont distribuées sur un réseau décentralisé et identifiées par un hash CID unique. Du coup, tant que le réseau tourne, votre contenu existe. Pas besoin de renouveler quoi que ce soit, pas besoin de payer un hébergeur... ça fonctionne tout seul.
L'installation se fait en une ligne :
npm install -g pinme
Pour déployer votre site statique, c'est hyper simple :
pinme upload dist/
L'outil détecte le dossier de build, ou plutôt il le devine tout seul selon votre framework : dist/ pour Vite et Vue, build/ pour Create React App, out/ pour Next.js en export statique. Ça évite d'avoir à se palucher de la config.
Côté limites, on est sur 200 Mo par fichier et 1 Go au total ce qui est largement suffisant pour une landing page ou une démo ! Et c'est GRATUIT. Pour ceux qui veulent un domaine lisible plutôt qu'un hash cryptique, y'a aussi des domaines ENS (les .eth sur Ethereum) ou des sous-domaines en .pinit.eth.limo. Après pour les domaines custom faudra un compte VIP par contre.
Le truc sympa c'est que vos fichiers restent accessibles via n'importe quelle passerelle IPFS, genre dweb.link ou w3s.link. Ainsi, si votre hébergeur ferme ou que votre domaine expire comme je le disais en intro, on s'en fiche ! Le contenu est toujours là, épinglé quelque part sur le réseau. C'est du stockage immuable, basé sur le contenu lui-même... du coup personne ne peut modifier ou supprimer ce que vous avez publié. (Et en fait vous non plus, faut le savoir.)
Et y'a aussi des commandes pour exporter en fichiers CAR et réimporter ailleurs, ce qui est pratique pour archiver ou migrer entre passerelles.
Voilà c'est gratuit pour 1 Go de stockage, c'est open source (licence MIT) et c'est par là . Merci à Lorenper pour la découverte !
Si vous avez déjà tapé [ss -tulnp](https://www.it-connect.fr/lister-les-ports-en-ecoute-sous-linux-avec-lsof-netstat-et-ss/) dans un terminal, vous savez que c'est moche. Genre, VRAIMENT moche. Les colonnes qui se chevauchent, les adresses tronquées, bref c'est un festival du bordel. Mais c'était sans compter sur ce dev qui a pondu
Snitch
, un outil en Go sous licence MIT qui vient concurrencer ss et netstat... sauf que pour une fois, c'est lisible, regardez :
L'interface de Snitch en action, sobre et lisible
En gros, c'est un ss moderne avec une interface TUI interactive. Vous lancez la commande dans votre terminal et tadaaa, vous avez un tableau propre avec toutes vos connexions réseau, les processus associés, les ports, les protocoles... le tout avec des couleurs et une navigation au clavier. Rien à voir donc avec le pavé monochrome habituel !
Le truc cool aussi ce sont les filtres. Vous pouvez taper snitch ls proto=tcp state=listen pour ne voir que les sockets TCP en écoute, ou snitch ls proc=nginx pour traquer votre serveur web. Y'a même un filtre contains= pour chercher dans les adresses... genre contains=google pour voir tout ce qui cause avec Mountain View.
D'ailleurs, côté commandes c'est en fait bien fichu. snitch ls pour un tableau statique, snitch json pour du JSON brut si vous voulez scripter, et snitch watch -i 1s pour streamer les connexions en temps réel. Du coup ça s'intègre nickel dans vos pipelines.
La TUI elle-même vaut le détour. Vous naviguez avec j/k (comme dans Vim, forcément), vous basculez TCP/UDP avec t/u, et le plus jouissif... vous pouvez killer un processus directement avec la touche K. Plus besoin de noter le PID et d'ouvrir un autre terminal ! Sauf que attention, sur Linux faut quand même lancer en root pour avoir les infos complètes sur les processus, parce que l'outil va lire dans /proc/net/*. Ça ne marche pas non plus sur Windows, c'est Linux et macOS uniquement.
Pour ceux qui aiment personnaliser leur terminal (oui, je vous connaîs...), y'a une quinzaine de thèmes, Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox... la config se fait dans ~/.config/snitch/snitch.toml et l'outil peut aussi conserver vos préférences de filtres entre les sessions (faut activer remember_state dans la config).
Côté installation, c'est pas la mer à boire. brew install snitch sur macOS, go install github.com/karol-broda/snitch@latest si vous avez Go, yay -S snitch-bin sur Arch, et y'a même des images Docker pour les plus prudents !
Donc si vous êtes du genre à surveiller votre trafic réseau ou à garder un oeil sur vos outils de diagnostic Linux , c'est clairement à tester.
Perso, pour du debug réseau rapide, je trouve que c'est carrément plus agréable que de se taper un ss -tulnp.
MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.
Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !
La licence c'est de l'Apache 2.0 comme ça y'a pas de contrainte virale, vous faites ce que vous voulez avec. Et c'est d'ailleurs sûrement la raison numéro un pour laquelle le projet cartonne.
Côté perfs, les devs annoncent 2,3x plus rapide que MinIO sur des petits objets de 4 Ko (testé sur un modeste 2 coeurs Xeon avec 4 Go de RAM). Bon, c'est un benchmark maison, à prendre avec des pincettes hein... mais finalement Rust pour du I/O intensif, ça se tient comme argument, car y'a pas de garbage collector qui vient foutre le bazar.
Pour l'installer, Docker en une ligne :
docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest
Et voilà, l'API tourne sur le port 9000 et la console web sur le 9001 (identifiants par défaut : rustfsadmin/rustfsadmin, changez-les vite fait hein). Y'a aussi du Kubernetes via Helm, un script d'install one-click, du Nix, ou un bon vieux git clone pour compiler vous-même (attention, sur macOS faut un ulimit à 4096 sinon ça ne marche pas).
Le conteneur Docker tourne en non-root (UID 10001), donc c'est plutôt propre niveau sécu. Pensez juste à faire un petit chown -R 10001:10001 data logs sur vos répertoires avant de lancer, sinon ça casse au démarrage.
Petit bonus appréciable, y'a aussi de la détection de corruption intégrée, et même du versioning de buckets pour les plus méfiants côté intégrité des données. D'ailleurs, côté monitoring, c'est déjà câblé pour envoyer vos métriques dans Grafana, vos traces dans Jaeger et le reste dans Prometheus. Un petit docker compose --profile observability up -d et c'est plié.
Par contre, on est encore en alpha et le mode distribué et le KMS sont en phase de test. Donc c'est PAS le genre de truc que vous mettrez en prod demain matin pour vos données critiques... mais pour du dev, du lab, ou des tâches pas trop sensibles... ça tourne impecc !
Bref, si l'AGPL de MinIO vous gave et que vous cherchez une alternative S3-compatible, en Rust, sous licence + permissive, allez jeter un œil à RustFS.
Merci à Lorenper pour le partage !
Les Ray-Ban Meta, c'est quand même le gadget parfait pour les voyeurs technophiles. Ce sont quand même des lunettes qui filment, prennent des photos et diffusent en live... le tout sans que PERSONNE autour ne s'en rende compte (ou presque). Alors forcément, quelqu'un a fini par coder une app pour les détecter !
Nearby Glasses , c'est une application Android développée par Yves Jeanrenaud qui scanne en permanence les signaux Bluetooth Low Energy autour de vous. Chaque appareil BLE diffuse en fait des trames pour s'annoncer avec un identifiant constructeur et les lunettes caméra de Meta utilisent les IDs 0x01AB et 0x058E (Meta Platforms) ainsi que 0x0D53 (Luxottica/Ray-Ban). Donc cette app écoute ces identifiants et vous balance une alerte dès qu'elle en capte un.
La détection repose sur le RSSI, en gros la puissance du signal reçu et par défaut, le seuil est à -75 dBm, soit environ 10-15 mètres en extérieur et 3-10 mètres en intérieur. Donc c'est pas foufou non plus mais c'est configurable, évidemment. Vous pouvez donc le durcir un peu pour ne choper que les lunettes vraiment proches, ou l'assouplir pour ratisser large (au prix de faux positifs en pagaille).
Les faux positifs, parlons-en d'ailleurs... Les casques Meta Quest utilisent les mêmes identifiants constructeur, du coup ça ne marche pas à tous les coups. Par exemple, si votre voisin joue en VR, votre téléphone va sonner ! L'app détecte aussi les Snap Spectacles (0x03C2)... pour les trois personnes qui en portent encore ^^.
Ah et l'app est UNIQUEMENT pour Android. La version iOS serait "on the way" selon le développeur... faut donc pas être pressé mais au moins c'est open source (AGPL-3.0), du coup n'importe qui peut vérifier ce que l'app fait de vos données Bluetooth.
Si le sujet vous parle, vous connaissez peut-être Ban-Rays , un projet hardware à base d'Arduino et de LEDs infrarouges qui détecte les Ray-Ban Meta via infrarouge et Bluetooth ! Hé bien Nearby Glasses, c'est l'approche 100% logicielle plutôt que hardware, ce qui est plus accessible mais forcément plus limitée... pas besoin de fer à souder, cela dit ^^.
C'est une rustine mais bon, c'est mieux que de se retrouver à poil sans permission sur le web.
Amazon, fournisseur officiel de mauvaises idées en matière de vie privée depuis 1870 vient de nous pondre une nouvelle trouvaille !! À partir du 25 mars, si quelqu'un vous achète un cadeau via votre liste de souhaits Amazon, le vendeur tiers récupère votre adresse de livraison. Oui, votre VRAIE adresse !! Après en tant que français on a l'habitude que tous les escrocs de la planète aient nos infos persos . Mais rassurez-vous, Amazon a trouvé une solution ! Est-ce qu'il s'agit de corriger le problème ? Que nenni !! Ils nous recommandent simplement d'utiliser une boîte postale. Sympa !
Parce que jusqu'ici, quand un pote vous envoyait un truc depuis votre wishlist, le vendeur tiers voyait votre ville et votre région... c'est déjà pas top, mais bon. Sauf que maintenant, c'est l'adresse COMPLÈTE qui part chez le vendeur. Numéro, rue, code postal, la totale...
Et vous vous en doutez, ça touche en premier lieu les créateurs de contenu, les streamers, et tous les crevards qui ont une wishlist publique pour que leur communauté puisse leur offrir des trucs net d'impôts ^^.
Donc suffit qu'un harceleur crée un faux compte vendeur sur Amazon Marketplace (La vérification d'identité ? Minimale !), met un article à 3 euros, attend qu'un fan l'achète via la wishlist de sa cible... et hop, il a l'adresse complète récupérée. Pas besoin d'être un génie. Ou alors suffit d'attendre que le vendeur tiers laisse fuiter le fichier Excel dans lequel il stocke ses commandes... La vie est toujours pleine de surprises quand il s'agit de leaker des données perso.
EDIT : Merci à Matthieu qui m'a envoyé la preuve ! Amazon.fr vient d'envoyer un email à ses utilisateurs pour confirmer que ce changement arrive bien en France à compter du 25 mars 2026. L'option permettant de restreindre les achats auprès de vendeurs tiers pour les articles de vos listes sera supprimée. Donc c'est plus une hypothèse, c'est confirmé... faites le ménage dans vos wishlists MAINTENANT.
En Europe, le RGPD impose que le partage de données personnelles repose sur une base légale. Consentement explicite, intérêt légitime, ou exécution d'un contrat et pas une case pré-cochée planquée dans les CGU.
Le problème, c'est qu'Amazon change les règles du jeu en cours de route, sans demander un consentement spécifique pour ce nouveau partage d'adresse avec des tiers. Et bien sûr, le moment venu, la CNIL pourrait avoir deux mots à dire là-dessus... après, on sait comment ça se passe, les amendes mettent des années à tomber. D'ailleurs, Amazon s'est déjà pris 746 millions d'euros par le Luxembourg en 2021 pour non-respect du RGPD mais visiblement, ça ne les a pas trop calmés.
Pour ceux qui s'intéressent à la suppression de leurs données perso en ligne , c'est le genre de truc qui fait grincer des dents.
Maintenant concrètement, voici ce que vous pouvez faire (ça ne marche pas à 100% mais c'est mieux que rien) :
Allez dans votre compte Amazon, section "Listes" puis "Gérer la liste". Vérifiez que votre wishlist est bien en mode "Privée" si vous ne voulez pas que n'importe qui la voie. Attention, le réglage par défaut c'est "Publique"... donc si vous n'avez jamais touché à ça, c'est probablement ouvert aux quatre vents.
Et si vous VOULEZ la garder publique (streamers, créateurs), utilisez une adresse qui n'est pas votre domicile. En France, une boîte postale La Poste coûte ~50 euros par an. Y'a aussi les Amazon Locker ou les points Mondial Relay... ce qui revient quand même à dire "débrouillez-vous", j'en ai bien conscience.
Le fond du problème, vous l'aurez compris, n'est pas technique. C'est qu'Amazon traite l'adresse de livraison comme une donnée de transaction banale alors que c'est une info sensible. Mais non, une adresse postale c'est pas un numéro de commande. Et surtout ça casse tout le principe d'anonymat des wishlists surtout quand la plateforme encourage les wishlists publiques depuis des années.
Bref, c'est confirmé pour la France au 25 mars, alors prenez les devants et prévenez votre influenceur préféré de faire le switch.
Vous voulez désactiver l'IA dans votre navigateur ? Bonne chance pour les couillons qui utilisent Chrome... faut passer par 5 réglages planqués dans chrome://settings et chrome://flags, tripatouiller des flags expérimentaux, bref, c'est un vrai parcours du combattant. Firefox 148, de son côté, a eu une idée folle : Mettre UN bouton. Hop, terminé.
Mozilla vient en effet de sortir la version 148 de Firefox et le gros morceau, c'est la section "Contrôles de l'IA" dans les paramètres (about:preferences#ai). Un seul toggle " Bloquer les améliorations IA " et paf, toutes les fonctions IA du navigateur sont coupées d'un coup. Traductions automatiques, regroupement d'onglets, previews de liens, texte alternatif des PDF, et même les chatbots de la barre latérale (ChatGPT, Claude, Gemini, Copilot, Le Chat). Tout dégage !
C'est le top pour les fragilous qui refusent le progrès ^^... Roohh ça va je blague ! Et le vrai intérêt du truc, c'est que ça verrouille les futures fonctions IA aussi. Du coup, si Mozilla ajoute de nouvelles features IA plus tard, elles seront automatiquement bloquées. Pas besoin de revenir fouiller dans les paramètres à chaque update. D'ailleurs, toutes les fonctions IA sont déjà désactivées par défaut... faut donc les activer manuellement si vous en voulez.
Et attention, ça ne bloque pas les extensions tierces qui intègrent leur propre IA, genre les "résumeurs" de page ou les assistants de rédaction. Le toggle, lui, garantit uniquement que les fonctions NATIVES restent coupées quoi qu'il arrive.
Et maintenant comparons avec la concurrence, parce que c'est là que ça pique les yeux.
Comme je vous le disais dans mon intro trollesque, chez Google, désactiver l'IA dans Chrome (et ses dérivés) relève carrément du sport extrême. Faut couper Gemini (chrome://settings/ai), désactiver le mode IA et Help Me Write (chrome://flags), bloquer la recherche IA dans l'historique, et pour les AI Overviews... ben y'a pas vraiment de bouton.
Brave fait un peu mieux heureusement ! Leur assistant Leo est opt-in par défaut, tourne dans un profil isolé qui ne peut pas accéder à vos données de navigation, et applique une politique zéro log. Même leur mode "agentic AI" en Nightly est désactivé de base. C'est propre, mais y'a pas de kill switch global comme Firefox. Du coup, si vous voulez la solution radicale plutôt que du cas par cas, Firefox gagne.
Et pour ceux qui se demandent pourquoi Firefox investit dans l'IA tout en permettant de la couper... en fait, Mozilla joue la carte de la transparence. Les modèles locaux utilisés par Firefox sont supprimés du disque quand vous désactivez les fonctions et tout est vérifiable dans about:processes si vous êtes du genre parano.
Au passage, cette version corrige également une quarantaine de failles de sécurité et embarque la Sanitizer API , ce qui est une première parmi les navigateurs. Et si vous êtes encore sur Firefox ESR, ça ne marchera pas... faudra donc attendre la prochaine ESR pour en profiter.
Voilà, si l'IA dans votre navigateur vous gave, vous savez où aller -> Firefox, tout simplement.