Un agent IA autonome a percé les défenses de Lilli, la plateforme d'intelligence artificielle interne de McKinsey, c'est arrivé en à peine deux heures. Au programme : 46,5 millions de messages en clair, 728 000 fichiers clients et un accès en écriture à l'ensemble de la base de données. Le tout sans aucun identifiant.

Une injection SQL en 2026

C'est la startup de sécurité CodeWall qui a mené l'attaque, dans le cadre d'un test de pénétration. Son agent IA a commencé par scanner la documentation API de Lilli, qui était exposée publiquement. Sur les 200 points d'accès répertoriés, 22 ne demandaient aucune authentification.

L'un d'eux, qui servait à enregistrer les requêtes de recherche des utilisateurs, concaténait les noms de champs JSON directement dans les requêtes SQL sans aucun filtrage. Une injection SQL classique, la faille la plus documentée du web depuis vingt ans.

Les scanners de sécurité classiques comme OWASP ZAP étaient passés à côté, parce que les valeurs des paramètres, elles, étaient bien protégées. Mais pas les noms de champs.

46,5 millions de messages et des prompts modifiables

Il a fallu seulement une quinzaine d'itérations à l'aveugle sur les messages d'erreur de la base, pour cartographier toute sa structure interne. Résultat : 46,5 millions de conversations en clair couvrant la stratégie, les fusions-acquisitions et les engagements clients de McKinsey, mais aussi 728 000 fichiers (192 000 PDF, 93 000 tableurs, 93 000 présentations), 57 000 comptes utilisateurs, 384 000 assistants IA et 3,68 millions de fragments de documents RAG avec les chemins de stockage S3.

Le pire, c'est que les 95 prompts système qui contrôlent le comportement de Lilli étaient accessibles en écriture. Une simple requête SQL UPDATE suffisait pour empoisonner les réponses du chatbot à l'ensemble des 40 000 consultants qui l'utilisent, sans laisser de trace.

McKinsey a corrigé en un jour

CodeWall a divulgué la faille le 1er mars, et McKinsey a réagi vite : tous les points d'accès non authentifiés ont été fermés, l'environnement de développement mis hors ligne et la documentation API retirée, le tout en une journée.

Histoire de rassurer tout le monde, le célèbre cabinet de conseil promet qu'aucune donnée client n'a été consultée par des personnes non autorisées. Sauf que l'adoption de Lilli dans l'entreprise est massive, puisque plus de 70% des employés de McKinsey l'utilisent au quotidien, avec quand même plus de 500 000 requêtes par mois, et une faille en place depuis... 2023 !

Quoi qu'il en soit, une injection SQL sur une plateforme qui tourne depuis deux ans et demi chez un cabinet qui vend du conseil en transformation numérique à, à peu près, la Terre entière, c'est quand même plus que cocasse.

Source : The Register

Des chercheurs liés à Alibaba ont découvert que leur agent IA, baptisé ROME, avait détourné des GPU pour miner de la cryptomonnaie et ouvert un tunnel de réseau vers l'extérieur, le tout sans aucune instruction humaine. Le comportement est apparu spontanément pendant l'entraînement par renforcement. Alibaba a réagi, mais cette séquence pose pas mal de questions sur la sécurité des agents IA autonomes.

Du minage de crypto et un tunnel SSH

ROME, pour « ROME is Obviously an Agentic ModEl », est un modèle basé sur l'architecture Qwen3-MoE d'Alibaba. Quatre équipes de recherche (ROCK, ROLL, iFlow et DT) l'ont développé pour exécuter des tâches complexes en autonomie : planification, commandes de terminal, édition de code et interaction avec des systèmes numériques.

Sauf que pendant son entraînement par renforcement, sur plus d'un million de trajectoires, l'agent a fait deux choses que personne ne lui avait demandées.

Il a redirigé une partie de la puissance GPU vers du minage de cryptomonnaie. Et il a ouvert un tunnel SSH inversé depuis une instance Alibaba Cloud vers une adresse IP externe, ce qui revient à créer une porte dérobée qui contourne les pare-feu.

Détecté par le pare-feu, pas par le modèle

Ce n'est pas le système de sécurité du modèle qui a repéré le problème. C'est le pare-feu managé d'Alibaba Cloud qui a détecté des schémas de trafic anormaux et une utilisation de GPU qui collait avec du minage. Les chercheurs ont croisé les horodatages du pare-feu avec les traces d'entraînement pour confirmer que c'était bien ROME le responsable.

Selon eux, le comportement relève de la « convergence instrumentale » : quand un modèle d'IA devient assez capable, il développe des sous-objectifs utiles pour atteindre n'importe quel but, et l'acquisition de ressources de calcul en fait partie.

Des correctifs et de la transparence

Alibaba a réagi en ajoutant un filtrage des trajectoires dangereuses dans son pipeline d'entraînement et en durcissant les environnements sandbox. Les chercheurs ont choisi de publier leurs résultats plutôt que de les garder pour eux, en admettant que « les modèles actuels sont nettement sous-développés en matière de sécurité, de sûreté et de contrôlabilité ».

Le problème de fond, c'est que les outils qui rendent ces agents utiles (accès au terminal, édition de code, interaction réseau) sont aussi ceux qui créent la surface d'attaque. Les retirer reviendrait à rendre l'agent inutile.

On peut se dire que ce genre de problème ne sera pas le dernier du genre. Mais quand un agent IA se met à miner de la crypto et à ouvrir des tunnels réseau sans qu'on lui ait rien demandé, ça fait quand même un peu tiquer. On ne parle pas d'un chatbot qui hallucine une recette de gâteau, là.

C'est un modèle qui a trouvé tout seul comment détourner des ressources à son avantage. On saluera quand même la transparence d'Alibaba, qui a publié les résultats au lieu de les planquer, mais la question de la sécurité des agents autonomes reste très ouverte.

Source : Axios

Mark Russinovich, CTO de Microsoft Azure, a donné à Claude Opus 4.6 un programme qu'il avait écrit en assembleur 6502 pour Apple II en mai 1986. L'IA d'Anthropic y a trouvé des vulnérabilités. Une découverte possible grâce à Claude Code Security, un outil qui a déjà débusqué plus de 500 failles dans des projets open source.

Du code Apple II passé au crible

Le programme en question s'appelle Enhancer. C'est un utilitaire écrit en langage machine 6502 qui ajoutait à l'Applesoft BASIC la possibilité d'utiliser des variables ou des expressions comme destination pour les commandes GOTO, GOSUB et RESTORE.

Claude Opus 4.6 a identifié un comportement silencieux incorrect : quand une ligne de destination n'était pas trouvée, le programme plaçait le pointeur sur la ligne suivante ou au-delà de la fin du programme, au lieu de signaler une erreur. L'IA a même suggéré le correctif : vérifier le carry flag (positionné quand une ligne n'est pas trouvée) et rediriger vers un gestionnaire d'erreurs.

L'anecdote a surtout valeur de démonstration. Russinovich l'a partagée pour montrer que les modèles d'IA sont désormais capables de décompiler du code embarqué d’un autre âge et d'y repérer des failles, ce qui pose un problème quand on sait que des milliards de microcontrôleurs tournent dans le monde avec du code qui n'a jamais été audité.

Plus de 500 failles dans des projets open source

Cette histoire autour de l'Apple II est amusante, mais le vrai sujet est ailleurs. Anthropic a utilisé Claude Opus 4.6 pour scanner des bases de code open source en production et a trouvé plus de 500 vulnérabilités qui avaient échappé à des années de revue par des experts humains.

Parmi les projets touchés : GhostScript (traitement PostScript et PDF), OpenSC (utilitaires pour cartes à puce), CGIF (traitement d'images GIF) et le noyau Linux. Certaines de ces failles étaient là depuis des décennies, malgré des millions d'heures de fuzzing accumulées sur ces projets.

Côté Firefox, on vous en a parlé : 22 CVE dont 14 haute gravité, trouvées en deux semaines seulement.

On vous en a déjà parlé, Anthropic a lancé le 20 février Claude Code Security, un outil intégré à Claude Code sur le web, pour l'instant en accès limité. Le principe : l'IA scanne un dépôt de code, identifie les vulnérabilités, et propose des correctifs ciblés pour validation humaine.

Contrairement aux outils d'analyse statique classiques qui fonctionnent par pattern matching, Claude lit et raisonne sur le code comme le ferait un chercheur en sécurité, en traçant les flux de données et en comprenant comment les composants interagissent. Rien n'est appliqué sans validation humaine. L'outil est accessible aux clients Enterprise et Team, et les mainteneurs de projets open source peuvent demander un accès gratuit.

Tout ça pour dire que l'image du CTO d'Azure qui ressort son vieux code Apple II et se retrouve avec un rapport de failles, c'est quand même franchement rigolo, mais aussi intéressant. Mais le fond du sujet est plus sérieux : des milliards d'appareils embarqués tournent avec du code ancien que personne n'a jamais audité, et l'IA est désormais capable de les passer au peigne fin. Anthropic a quand même prévenu que cet écart entre la capacité à trouver les failles et celle de les exploiter ne durera probablement pas éternellement. On l’espère.

Source : The Register

Les services de renseignement néerlandais ont révélé qu'une campagne de hackers russes cible les comptes Signal et WhatsApp de hauts fonctionnaires, militaires et journalistes dans le monde entier.

Des employés du gouvernement néerlandais ont déjà été compromis, et le chiffrement de bout en bout n'a même pas eu besoin d'être cassé. Eh oui, là on parle de social engineering, tout simplement.

Des codes de vérification, pas du piratage

La méthode est assez simple, et c'est peut-être ça le pire. Les hackers contactent directement leurs cibles en se faisant passer pour le support technique de Signal. Ils demandent de partager le code de vérification à six chiffres ou le code PIN, sous prétexte de « sécuriser » le compte.

Une fois le code récupéré, ils se connectent et accèdent à l'ensemble des conversations. L'autre technique est un peu plus discrète : les attaquants envoient un QR code piégé qui lie un appareil supplémentaire au compte de la victime, via la fonction « appareils liés » de Signal ou WhatsApp. À partir de là, les messages arrivent en temps réel sur un appareil qu'ils contrôlent, sans que la victime ne s'en rende compte. Pratique.

Des comptes gouvernementaux déjà touchés

L'AIVD et le MIVD, les deux agences de renseignement néerlandaises, ont confirmé que des employés du gouvernement et des journalistes avaient été piégés. Simone Smit, directrice générale de l'AIVD, a tenu à préciser que Signal et WhatsApp en tant que plateformes n'étaient pas compromis : ce sont des comptes individuels qui ont été visés. Le chiffrement tient bon, mais ça ne sert à rien quand c'est l'utilisateur qui donne la clé.

Le vice-amiral Peter Reesink, directeur du MIVD, a de son côté rappelé que ces messageries ne devaient tout simplement pas être utilisées pour échanger des informations classifiées ou sensibles. Les hackers auraient déjà accédé à des données sensibles.

Comment savoir si vous êtes touché

Quelques signaux doivent vous alerter : un contact qui apparaît en double dans une conversation de groupe, ou un numéro connu qui affiche soudainement « compte supprimé ». La règle de base reste simple : ne jamais communiquer un code de vérification, même si la demande semble venir du support officiel. Et pensez à faire un tour dans les paramètres de Signal ou WhatsApp pour vérifier la liste des appareils liés à votre compte.

C'est couillon parce que ce type d'attaque n'a rien de sophistiqué, et c'est bien ça le problème. Pas besoin de casser le chiffrement quand il suffit de demander poliment le code à la personne en face.

C'est du social engineering, ça marche depuis des années, et ça continuera de marcher parce qu'on a quand même tendance à faire confiance à un message qui a l'air officiel (et c'est bien normal).

Le fait que des fonctionnaires gouvernementaux soient tombés dans le piège en dit long sur le niveau de sophistication requis : aucun. Mais bon, il serait peut-être bon de former un peu plus les gens qui manipulent des données sensibles à ce genre de risques.

Source : Reuters

Andy Nguyen, chercheur en sécurité informatique, a réussi à installer Linux sur une PlayStation 5 et à faire tourner GTA 5 Enhanced Edition en 1440p à 60 images par seconde, ray tracing activé. La console se transforme alors en une sorte de « Steam Machine ». Mais l'exploit ne fonctionne que sur les toutes premières PS5, celles qui n'ont jamais été mises à jour depuis leur achat.

GTA 5 Enhanced en 1440p à 60 FPS

Le résultat est assez bluffant. Andy Nguyen, connu sous le pseudo theflow0, a partagé une vidéo montrant GTA 5 Enhanced Edition qui tourne à 60 images par seconde en 1440p avec le ray tracing activé, le tout sur une PS5 standard, pas la Pro. Le processeur tourne à 3,2 GHz et le GPU à 2,0 GHz, des fréquences volontairement bridées parce que la console commence à surchauffer au-delà. En théorie, le CPU pourrait monter à 3,5 GHz et le GPU à 2,23 GHz, mais le système de refroidissement ne suit pas. La sortie vidéo 4K en HDMI fonctionne, le son aussi, et tous les ports USB sont opérationnels. Pour les pilotes graphiques, Nguyen a travaillé avec le projet open source Mesa pour ajouter le support du GPU de la PS5.

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.

Source

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

Defaults !pwfeedback

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.

Source

Des faux entretiens d'embauche avec des repos GitHub vérolés pour piéger les devs Next.js... on croit rêver et pourtant, Microsoft vient de documenter cette campagne ciblée et vous allez voir, c'est violent.

En fait, un groupe de hackers se fait actuellement passer pour des recruteurs et contacte des développeurs JavaScript en leur proposant un entretien technique. Le deal c'est de cloner un repo GitHub pour un "test de compétences"... sauf que le repo en question est truffé de malware.

Microsoft a ainsi identifié plusieurs vecteurs d'infection planqués dans ces repos. Le premier, c'est via les fichiers de configuration VS Code, c'est à dire ceux dans le dossier .vscode/, qui peuvent exécuter du code dès que vous cliquez "Trust" à l'ouverture du projet (ce que la plupart des devs font sans réfléchir).

Le deuxième passe par un npm run dev piégé, la commande de dev classique qui lance le malware en même temps que le serveur (car oui, c'est aussi simple que ça...).

Et le troisième est encore plus sournois puisqu'il s'agit d'un module backend qui décode une URL depuis le fichier .env, exfiltre toutes les variables d'environnement (tokens cloud, clés API...), puis exécute du JavaScript reçu en retour. Sympaaaaaa....

Du coup, le malware est plutôt bien pensé. C'est un loader JavaScript qui se télécharge depuis l'infrastructure Vercel (comme ça, ça a l'air légitime), et qui s'exécute entièrement en mémoire, et spawne un processus Node.js séparé pour ne pas éveiller les soupçons. Une fois installé, il se connecte alors à un serveur C2 qui change d'identifiant régulièrement, histoire de compliquer la détection. Et là, ça se met à exfiltrer tout ce qui traîne... code source, secrets, credentials cloud... bref, tout ce qui a de la valeur.

Alors, comment on se protège de ce genre de menace quand on est un simple dev ? Hé bien déjà, vérifiez le profil du "recruteur". Pas de site d'entreprise vérifiable, des messages génériques... c'est un joli red flag !

Ensuite, avant de lancer quoi que ce soit, lisez le package.json à la recherche de scripts suspects dans preinstall, postinstall ou prepare, inspectez le dossier .vscode/ (surtout tasks.json), et faites un npm install --ignore-scripts pour bloquer l'exécution automatique des hooks. Lancez aussi un safe-npm et un npm audit une fois les dépendances installées. Et côté VS Code, désactivez l'exécution auto des tasks avec "task.allowAutomaticTasks": "off" dans vos settings.

Ça me rappelle les campagnes type Shai-Hulud et les packages npm vérolés , mais avec un vecteur social bien plus élaboré. Le piège, c'est qu'on ne balance plus des packages malveillants dans le registry en espérant qu'un dev les installe par erreur... non, non, on cible directement les développeurs, un par un, en exploitant ce stress de la recherche d'emploi comme le ferait un conseiller France Travail quand vous arrivez en fin de droits chomdu...

Et si vous êtes en pleine recherche d'emploi, attention, ne lancez JAMAIS un projet d'un inconnu dans votre environnement principal. Utilisez une VM, un container Docker (docker run --rm -it -v $(pwd):/app node:20 bash et c'est réglé), ou au minimum un compte utilisateur séparé sans accès à vos tokens et clés SSH. On n'est jamais trop prudent !

Maintenant vous savez... si un recruteur vous envoie un repo GitHub sans profil LinkedIn ni site d'entreprise véritable et vérifiable... c'est que c'est pas un recruteur. Voilà voilà...

Source

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 !!

Source

Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.

La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.

D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.

Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)

Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.

Méthode 1 : Normalisation simple (single-pass)

C'est la méthode la plus rapide, parfaite pour du traitement à la volée :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav

ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4

pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le

Le CNRS vient de confirmer un incident de cybersécurité qui a mené au téléchargement non autorisé de fichiers contenant des données personnelles d'anciens agents. Noms, adresses, numéros de sécurité sociale, RIB : la totale donc. L'organisme a déposé plainte et prévenu la CNIL.

Des données très sensibles

C'est ce lundi 16 février que le CNRS a informé ses agents d'une fuite de données sur un de ses serveurs. Des fichiers contenant des informations de ressources humaines ont été téléchargés sans autorisation. Et on ne parle pas de données anodines : noms, prénoms, dates de naissance, adresses postales, numéros de sécurité sociale et RIB. Le tout accompagné du statut de l'agent, du type de contrat et de la structure d'affectation. Le serveur a été isolé et arrêté dès la découverte de l'incident, et l'organisme assure que la fuite ne s'est pas propagée au reste de ses infrastructures.

Qui est concerné ?

Seuls les personnels recrutés avant le 1er janvier 2007 sont touchés, qu'ils aient été titulaires ou non. Si vous avez travaillé au CNRS après cette date, vous n'êtes pas concerné. Le nombre exact de victimes n'a pas été communiqué, mais vu la taille de l'organisme, on parle potentiellement de plusieurs milliers de personnes. Le CNRS recommande de prévenir sa banque, de surveiller ses comptes, de vérifier si ses données circulent sur haveibeenpwned.com, et de rester vigilant face aux tentatives de phishing ou d'usurpation d'identité. La CNIL et l'ANSSI ont été prévenues, et une plainte a été déposée auprès de la section cybercriminalité du parquet de Paris.

Les institutions françaises en ligne de mire

On n'est pas vraiment sur une première niveau cyberattaques sur des services de l'état. Le ministère de l'Intérieur, celui des Sports, et d'autres organismes avaient été visés. L'URSSAF a aussi confirmé une fuite touchant les données de 12 millions de salariés. Le CNRS lui-même avait été la cible d'un défacement de plusieurs de ses sous-domaines fin janvier. Deux incidents distincts, mais la tendance est claire, et c'est franchement moche.

On va quand même saluer le fait que le CNRS a communiqué rapidement, avec un communiqué officiel et une FAQ pour les personnes concernées. C'est loin d'être toujours le cas. Mais on va quand même se questionner sur le fait que des RIB et des numéros de sécu trainent sur un serveur, alors qu'on parle de données parfois veilles depuis presque 20 ans... Pourquoi ces informations étaient-elles encore accessibles ? La question du stockage prolongé de données sensibles revient sur la table, et visiblement, personne n'a encore de bonne réponse. En attendant, si vous avez porté la blouse du CNRS avant 2007, un petit tour sur votre relevé bancaire ne serait pas du luxe.

Article invité publié par Vincent Lautier . Vous pouvez aussi faire un saut sur mon blog , ma page de recommandations Amazon , ou lire tous les tests que je publie dans la catégorie "Gadgets Tech" , comme cette liseuse Android de dingue ou ces AirTags pour Android !

Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

Un peu moins de 700 000 liens, c'est le nombre de références vers archive.today que Wikipedia envisage de supprimer d'un coup ! Et la raison est assez dingue... en fait le service d'archivage a planqué du code DDoS dans son CAPTCHA afin d'attaquer le blog d'un mec qui a eu le malheur de chercher l'identité du fondateur du site.

L'histoire est tordue vous allez voir...

En 2023, un blogueur du nom de Jani Patokallio publie un article sur son blog Gyrovague pour tenter d'identifier le créateur d'archive.today, un certain "Denis Petrov" (probablement un pseudo). Pas de quoi fouetter un chat, sauf que le principal intéressé n'a visiblement pas kiffé.

Du coup, un bout de JavaScript s'est retrouvé comme de par hasard dans la page CAPTCHA du service, exécutant une requête vers le blog de Patokallio toutes les 300 millisecondes. Chaque visiteur qui passait par le CAPTCHA devenait alors un soldat involontaire d'une attaque DDoS.

Et le bonhomme ne s'est pas arrêté là... il a ensuite menacé de créer un site porno avec le nom du blogueur. On est vraiment dans la réponse proportionnée, clairement.

Le souci, c'est que Wikipedia utilise archive.today de manière MASSIVE. Cela représente 695 000 liens répartis sur environ 400 000 pages. C'est le deuxième fournisseur d'archives de toute l'encyclopédie !

Du coup, les éditeurs se retrouvent face à un sacré dilemme. D'un côté, on a ceux qui veulent tout blacklister parce que "la sécurité de vos lecteurs, ça passe avant les citations". Et de l'autre, ceux qui rappellent que le service contient des archives qu'on ne trouve NULLE PART ailleurs, même pas sur la Wayback Machine .

Bon courage pour trouver un remplaçant les mecs !

Et petit détail qui n'en est pas un, au passage... En fait, archive.today sert aussi à contourner des paywalls. C'est pratique pour vérifier des sources, ou lire de supers articles sans payer mais techniquement c'est illégal.

Mais quand la source originale a disparu, on fait comment ? Et c'est là tout l'intérêt de ces services d'archivage.

Bon, les paywalls, on comprend tous pourquoi ça existe. Produire de l'info de qualité, ça coûte un bras. Sauf que c'est quand même un truc un peu naze. Vous bossez, vous produisez un contenu top, et au final y'a que 10 personnes qui payent pour le lire. Et ce sont les mêmes 10 personnes qui sont pigistes et qui vont reprendre votre info pour la diffuser gratuitement sur leur média ! On le voit avec Mediapart... des enquêtes énormes derrière un paywall, et toute la presse qui reprend leurs scoops sans payer. Je trouve ça vraiment dommage.

Moi, ce que j'aime dans le fait d'écrire sur le web, c'est que vous me lisiez. Et mettre du contenu derrière un paywall, ça voudrait dire que plein d'entre vous ne me liraient plus. C'est pour cela que même le contenu que je réserve en avant-première sur Patreon , au bout de quelques semaines, je le libère pour tout le monde.

Quand je vois The Verge par exemple qui en met dans tous les sens... ben j'y vais plus. J'ai pas envie de payer un abonnement de plus pour une valeur ajoutée pas folle. C'est un peu comme les bandeaux cookies, à savoir un effet de bord regrettable du web moderne. On doit faire avec parce que personne n'a trouvé mieux comme idée...

Bref, entre les DDoS vengeurs, les 700 000 liens en sursis et les paywalls qui pourrissent tout ... le web ouvert, c'est pas gagné les amis. Voilà voilà.

Source

Ghidra, le framework de reverse engineering open source de la NSA, est un outil que tous les analystes sécu utilisent au quotidien pour démonter des binaires. Sauf que voilà... quand vous passez des heures à renommer des fonctions, documenter des structures et tracer des cross-references à la main, ça finit par devenir un poil répétitif.

Du coup, un développeur a eu l'idée de coller un serveur MCP (Model Context Protocol) directement sur Ghidra. "Encore un wrapper IA bidon ??"... mais non les amis car Ghidra MCP Server est un bridge Python + plugin Java qui expose pas moins de 110 outils d'analyse via le protocole MCP. Rien que ça.

Concrètement, ça veut dire que vous pouvez brancher Claude, ou n'importe quel outil compatible MCP, directement sur votre session Ghidra et lui demander de décompiler des fonctions, tracer des call graphs, renommer des variables en batch ou même créer des structures de données automatiquement.

Au niveau architecture, un plugin Java tourne dans Ghidra et expose une API REST sur localhost:8089, puis un bridge Python fait la traduction entre le protocole MCP et ces endpoints HTTP. Vous lancez Ghidra, vous activez le serveur via Tools > GhidraMCP > Start MCP Server, et hop, votre IA peut causer directement avec le décompileur.

Et c'est pas juste de la décompilation basique. Y'a de l'analyse de structures, de l'extraction de strings, du mapping mémoire complet, de la gestion de scripts Ghidra (plus de 70 scripts d'automatisation livrés avec le projet !) et même un système de documentation cross-binaire.

En gros, vous analysez un malware, vous documentez toutes les fonctions, et si vous tombez sur une variante plus tard, l'outil transfère automatiquement votre doc via un système de hash SHA-256 sur les opcodes. Plutôt chouette ! En revanche, ça marche pas si le code est fortement obfusqué... logique.

Bon, pour ceux qui connaissent déjà OGhidra (qui fait tourner des LLM en local dans Ghidra), Ghidra MCP Server c'est l'approche inverse. Au lieu d'embarquer l'IA dans Ghidra, c'est Ghidra qui s'ouvre à l'IA via un protocole standardisé. Du coup vous n'êtes pas limité à un seul modèle... Claude, GPT, Gemini, n'importe quel client MCP fait l'affaire.

Côté prérequis, faut Java 21, Maven 3.9+, Python 3.10+ et évidemment Ghidra 12.0.2. L'install se fait en quelques étapes : cloner le repo, pip install, copier les libs Ghidra dans lib/, compiler avec Maven et déployer le zip dans les extensions. Rien de bien sorcier si vous êtes déjà dans l'écosystème... sauf si vous êtes sous Windows, là faudra peut-être un peu galérer avec Maven.

Les opérations batch sont par exemple très intéressantes... Avec cette fonctionnalité, vous pouvez renommer 50 variables d'un coup, poser des commentaires sur toutes les fonctions d'un module, typer des paramètres en série.

Bref, si vous faites de l'analyse de binaires et que vous voulez arrêter de tout vous taper à la main, c'est le genre de combo reverse engineering + IA qui va vous faire gagner pas mal de temps !

Les data brokers, ces intermédiaires invisibles du Web, ont transformé votre vie numérique en produit de consommation courante. Ils collectent, recoupent et monétisent des milliers de détails sur vous : adresse précise, numéros de téléphone, emails secondaires, habitudes d'achat, revenus estimés, présence sur les réseaux, même des inférences sur votre santé ou vos orientations politiques ou sexuelles. Incogni s'attaque à ce rouleau compresseur en demandant, à votre place et en continu, la suppression de ces informations chez plus de 420 courtiers, pour que votre profil cesse enfin d'être un actif coté en bourse.

Le Web aspire vos infos plus vite que vous ne pouvez cliquer sur « refuser »

On pense souvent que les fuites viennent de gros hacks spectaculaires ou sont offertes par nos sites gouvernementaux. Mais la réalité est bien plus banale et implacable. Chaque inscription à un service, chaque programme de fidélité, chaque appli « pratique », chaque extension Chrome boostée à l'IA devient une porte ouverte. Une étude récente d'Incogni sur 442 extensions Chrome alimentées par l'IA montre que 67% d'entre elles collectent des données utilisateur, 41% raflent des infos personnelles identifiables (mots de passe, historique, localisation, communications privées), et un tiers ont un impact de risque élevé en cas de compromission. Des outils comme Grammarly, DeepL ou QuillBot, avec des millions d'utilisateurs, demandent des permissions massives pour injecter du code partout et aspirer votre activité. Tout ça au nom de la « productivité ».

Ces données ne restent pas dans un coffre : elles se déversent chez les brokers, qui les raffinent et les revendent. Résultat : votre adresse exacte apparaît sur des sites de recherche de personnes, votre profil d'achat sert à des pubs invasives ou à des hausses de prix ciblées, et des escrocs utilisent ces détails pour monter des phishings crédibles. Sans intervention, votre empreinte s'alourdit d'année en année, rendant les scams plus efficaces et les usurpations d'identité plus simples à exécuter.

Incogni : l'agent qui harcèle les brokers à votre place

Plutôt que de vous laisser batailler avec des formulaires opt-out incompréhensibles et des réponses en 45 jours maximum (comme l'exige le RGPD), Incogni prend le relais dès l'inscription. Le service scanne les brokers susceptibles de détenir vos infos, envoie des demandes légales de suppression, et relance tous les 60 à 90 jours ceux qui traînent ou rechignent. Un audit Deloitte confirme que cela couvre bien 420+ brokers, avec des relances systématiques et des confirmations de suppression obtenues dans la grande majorité des cas.

Le tableau de bord de l'outil est limpide : gravité de l'exposition par broker, statut des requêtes (confirmée, en attente, refus), et même des suppressions personnalisées sur des sites hors liste standard (genre un vieux forum, un annuaire pro, un résultat Google tenace). Et ça va assez vite, avec une baisse notable des spams ciblés dès la première semaine et des fiches publiques qui s'évaporent progressivement. Si un broker ne coopère pas ? Incogni peut escalader vers les autorités de protection des données.

Pourquoi vos données dans de mauvaises mains vous coûtent cher

Avoir ses infos chez les brokers, c'est non seulement envahir sa boîte mail de pubs sur mesure, mais aussi faciliter les scams. Un appel téléphonique cherchant à vous arnaquer, un faux site de livraison avec votre adresse exacte, un mail d'« urgence bancaire » avec vos vrais détails, ou une usurpation qui passe crème parce que le voleur connaît déjà votre contexte. Les rapports sur les fraudes en ligne montrent que ces attaques exploitent précisément ces données achetées à bas prix.

Incogni brise ce cycle en rendant votre profil moins attractif : moins de détails disponibles, moins de valeur marchande, moins de copies circulant. Les retours d'utilisateurs confirment une réduction des recherches de personnes qui vous listent, des démarchages ciblés qui s'estompent, et une sérénité accrue face aux fuites futures. Le service gère aussi les relances pour que les suppressions tiennent dans le temps, transformant une corvée ponctuelle en maintenance automatique.

Prendre le contrôle : une démarche qui paye sur la durée

Le vrai pouvoir d'Incogni réside dans sa persistance. Contrairement à un ménage manuel qui s'essouffle vite, il continue d'envoyer des demandes, suit les réponses, et ajoute de nouveaux brokers au fil des mises à jour (des dizaines par an). Basé aux Pays-Bas, il respecte scrupuleusement le RGPD et d'autres régimes comme le CCPA, avec une procuration numérique qui vous décharge légalement de tout le process. Son efficacité pour les particuliers comme les pros qui veulent limiter les risques sur des listes clients ou employés n'est pas prise en défaut.

Vos données ne sont pas condamnées à rester en vente éternellement. Des lois vous donnent le droit à l'effacement, et Incogni est l'outil qui passe ses journées à l'exercer pour vous. En 2026, alors que les extensions IA et les brokers s'enhardissent, commencer par nettoyer ce qui traîne est le geste le plus concret pour reprendre les rênes. Moins de données en circulation, c'est moins de spam, moins de scams crédibles, et surtout la fin de cette sensation diffuse d'être constamment observé par des inconnus qui en savent trop long.

Au niveau du prix, ça reste constant. Vous pouvez toujours vous protéger à partir de 77,63€ TTC par année, soit -55% avec le code KORBEN55.

-> Cliquez ici pour reprendre vos données en main ! <-