Vous vous souvenez du film Volte/Face avec Nicolas Cage et John Travolta ? Mais siii, c’est ce film où ils échangent leurs visages ? Bah les chercheurs allemands viennent de faire pareil avec Windows Hello, sauf qu’eux n’ont eu besoin que de deux lignes de code. Pas de chirurgie, pas d’effets spéciaux, juste un petit tour de passe-passe et hop, le PC croit que vous êtes votre collègue.

Le truc vient d’être montré en direct au Black Hat de Las Vegas par Tillmann Osswald et le Dr Baptiste David, deux chercheurs d’ERNW Research. Sur scène, David s’est connecté avec son visage, puis Osswald a tapé quelques commandes, et quelques secondes plus tard, il déverrouillait la machine de David avec son propre visage capturé sur un autre ordinateur. La sécurité biométrique de Microsoft vient de se faire avoir comme une débutante.

Ce qui rend cette attaque particulièrement sournoise, c’est qu’elle cible spécifiquement Windows Hello for Business, le système que Microsoft pousse à fond pour remplacer les mots de passe dans les entreprises. Vous savez, ce truc censé être ultra-sécurisé qui permet aux PC corporate de se connecter à Entra ID ou Active Directory avec juste votre belle gueule. Sauf que là, n’importe quel admin local malveillant ou compromis peut littéralement injecter sa tronche dans votre base de données biométrique.

Selon les informations techniques détaillées, l’attaque exploite une faiblesse dans CryptProtectData, le système censé protéger la base de données du Windows Biometric Service. Les chercheurs ont découvert qu’avec des droits admin locaux, on peut décrypter cette base et y injecter n’importe quelle empreinte biométrique.

Le plus fou dans cette histoire, c’est que Microsoft a bien une solution : Enhanced Sign-in Security (ESS). Ce système fonctionne au niveau hyperviseur avec une isolation VTL1 (Virtual Trust Level 1) qui bloque complètement l’attaque. Mais le problème c’est qu’il faut du matériel très spécifique pour que ça marche : un CPU 64 bits avec virtualisation hardware, une puce TPM 2.0, Secure Boot activé, et des capteurs biométriques certifiés.

D’ailleurs, petit détail rigolo, même des ThinkPad achetés pourtant il y a un an et demi ne supportent pas ESS parce qu’ils ont des puces AMD au lieu d’Intel. Comme l’explique Osswald, “ESS est très efficace pour bloquer cette attaque, mais tout le monde ne peut pas l’utiliser.”

Pour vérifier si vous êtes protégé, Microsoft recommande donc d’aller dans les paramètres Windows : Comptes → Options de connexion. Si vous voyez une option “Se connecter avec une caméra externe ou un lecteur d’empreintes digitales”, et qu’elle est sur OFF, ESS est activé. Quand ce toggle est OFF, vous êtes protégé mais vous ne pouvez plus utiliser de périphériques externes. Par contre, quand il est ON, vous pouvez utiliser vos gadgets mais vous êtes vulnérable.

Cette recherche fait partie du programme Windows Dissect, financé par l’Office fédéral allemand pour la sécurité informatique (BSI), un projet de deux ans qui se termine au printemps prochain. Et apparemment, ce n’est que le début car les chercheurs promettent d’autres révélations sur Windows dans les mois qui viennent. Ce qui inquiète vraiment la communauté, c’est que le fix n’est pas simple. Les experts estiment qu’il faudrait soit réécrire une partie significative du code, soit stocker les données biométriques dans le TPM, ce qui n’est peut-être même pas faisable techniquement…. Breeef, en attendant, la recommandation officielle pour les entreprises sans ESS est radicale : Désactivez complètement la biométrie et revenez au bon vieux code PIN.

Microsoft pousse agressivement tout le monde vers la biométrie depuis de nombreux mois, pour justement se débarrasser des mots de passe, mais quand je vois que leur solution de contournement recommandée est… de revenir aux codes PIN, j’avoue qu’on commence un peu à marcher sur la tête.

Et le support complet des périphériques externes avec ESS n’est pas prévu avant fin 2025 toujours selon Microsoft donc d’ici là, si vous utilisez Windows Hello for Business sans le hardware compatible ESS, vous jouez littéralement à la roulette russe avec l’identité de vos employés.

Ça montre donc que la biométrie n’est pas la solution miracle mais juste une autre forme d’authentification avec ses propres failles. Maintenant, la différence, c’est que quand quelqu’un vole votre mot de passe, vous pouvez le changer. Mais quand quelqu’un compromet votre système biométrique… bah vous changez de visage comme Cage et Travolta ?

Source

Cet article fait partie de ma série de l’été spécial hackers. Bonne lecture !

C’est l’histoire d’une hackeuse qui a littéralement fait trembler Intel, Microsoft et toute l’industrie de la sécurité et qui a prouvé qu’on ne pouvait JAMAIS faire confiance à un ordinateur.

Je ne me souviens absolument pas du jour où j’ai découvert Blue Pill mais c’est en août 2006, lors de la présentation de Joanna Rutkowska à Black Hat, que le monde a découvert cet outil. Les forums de sécurité étaient en ébullition totale car une hackeuse polonaise de 25 ans venait de démontrer comment créer un rootkit 100% indétectable en utilisant de la virtualisation hardware. Les experts étaient alors partagés entre l’admiration et la terreur absolue.

Comment une chercheuse inconnue du grand public avait-elle pu mettre à genoux toute l’industrie et devenir quelques années plus tard, l’architecte de l’OS le plus sécurisé au monde ? Je vais tout vous raconter…

Joanna Rutkowska naît en 1981 à Varsovie, dans une Pologne encore sous régime communiste. Quand elle débarque sur Terre, Solidarność vient juste d’être interdit et le général Jaruzelski impose la loi martiale. C’est dans ce contexte politique super tendu qu’elle grandit, dans une ville où l’accès à la technologie occidentale reste un luxe rare.

En 1992, à 11 ans, Joanna découvre son premier ordinateur. Un PC/AT 286 avec un processeur à 16 MHz, 2 MB de RAM et un disque dur de 40 MB. Pour une gamine de cet âge dans la Pologne post-communiste, c’est comme trouver un trésor. Alors pendant que ses copines jouent à la poupée Barbie, Joanna passe ses journées devant l’écran monochrome, fascinée par ce monde binaire.

Elle commence par apprendre GW-BASIC, puis découvre Borland Turbo Basic. Les lignes de code défilent, les programmes prennent vie. C’est magique ! Elle passe des heures à créer des petits jeux, des utilitaires et tout ce qui lui passe par la tête. Mais très vite, le BASIC ne lui suffit plus. Elle veut comprendre comment fonctionne VRAIMENT la machine.

L’adolescence de Joanna est marquée par une curiosité dévorante pour les entrailles des systèmes. Elle se plonge dans la programmation assembleur x86, le langage le plus proche du hardware. C’est hardcore, c’est complexe, mais c’est exactement ce qu’elle cherche. Elle veut tout contrôler, tout comprendre, tout maîtriser jusqu’au dernier registre du processeur.

Alors elle ne se contente pas d’apprendre. Elle expérimente, crée ses premiers virus. Pas pour nuire hein, mais pour comprendre. Comment un programme peut-il se répliquer ? Comment peut-il se cacher ? Comment peut-il survivre ? Ces questions l’obsèdent. Elle passe ses nuits à désassembler des programmes, à tracer leur exécution instruction par instruction.

Et au milieu des années 90, quelque chose change. Les maths et l’intelligence artificielle commencent à la fasciner. Elle découvre les réseaux de neurones, les algorithmes génétiques, et tout ce qui touche à l’IA naissante. Elle dévore les whitepapers de recherche, implémente des prototypes. Et cette même passion qu’elle avait mise dans l’assembleur, elle la met maintenant dans l’IA.

Parallèlement, elle découvre Linux et le monde de l’open source et c’est une révélation totale ! Un système d’exploitation dont on peut lire le code source, c’est fou ! Elle peut enfin voir comment fonctionne vraiment un OS moderne. Elle compile son premier kernel, le modifie, le recompile. Elle apprend la programmation système, les drivers, les mécanismes de sécurité du kernel.

Puis à la fin des années 90, Joanna fait un choix crucial. Elle retourne à sa première passion : la sécurité informatique. Mais cette fois avec une approche différente. Elle ne veut plus créer des virus pour le fun, non, elle veut comprendre comment sécuriser les systèmes, comment les protéger, comment détecter les attaques les plus sophistiquées.

Alors elle s’inscrit à l’Université de Technologie de Varsovie (Warsaw University of Technology), l’une des meilleures facs d’informatique de Pologne et là, elle approfondit ses connaissances théoriques tout en continuant ses recherches personnelles sur les exploits Linux x86 et Win32 puis finit par se spécialiser dans la sécurité système, un domaine encore peu exploré à l’époque.

Son mémoire de master porte sur les techniques de dissimulation des malwares. Elle y développe des concepts qui préfigurent déjà ses futures recherches. Comment un programme malveillant peut-il se rendre totalement invisible ? Comment peut-il tromper les outils de détection les plus sophistiqués ? Ses profs sont bluffés par la profondeur de son analyse.

Diplômée, Joanna commence à bosser comme consultante en sécurité, mais très vite, elle réalise que le consulting ne la satisfait pas. Elle veut faire de la recherche pure et dure, explorer les limites de ce qui est possible, repousser les frontières de la sécurité informatique. Pas juste auditer des systèmes pour des clients corporate.

C’est à cette époque qu’elle commence à s’intéresser à la virtualisation. Intel et AMD viennent de sortir leurs nouvelles extensions de virtualisation hardware : VT-x et AMD-V. Pour la plupart des gens, c’est juste une amélioration technique pour faire tourner des VMs plus efficacement mais pour Joanna, c’est bien plus que ça. C’est une nouvelle surface d’attaque.

Elle passe des mois à étudier ces nouvelles technologies. Elle lit les manuels Intel de 3000 pages (oui, 3000 !), analyse chaque instruction, comprend chaque mécanisme. Les opcodes VMXON, VMXOFF, VMRESUME deviennent ses meilleurs amis et petit à petit, une idée germe dans son esprit génial.

Et si on pouvait utiliser la virtualisation non pas pour protéger, mais pour attaquer ? Et si on pouvait créer un hyperviseur malveillant qui prendrait le contrôle total d’un système sans que personne ne s’en aperçoive ? Un rootkit qui s’exécuterait à un niveau encore plus bas que le kernel, dans le ring -1 comme on dit.

L’idée est révolutionnaire car jusqu’alors, les rootkits devaient modifier le kernel, laissaient des traces, et étaient détectables d’une manière ou d’une autre. Mais avec la virtualisation hardware, on pourrait créer un rootkit qui contrôle le système d’exploitation lui-même sans jamais le toucher. Le rootkit parfait en somme…

En 2006, Joanna est prête. Elle a développé une preuve de concept qu’elle appelle “Blue Pill”, en référence à la pilule bleue de Matrix. Le nom est parfait car comme dans le film, le système d’exploitation continue de vivre dans une réalité virtuelle sans se douter qu’il est contrôlé par une entité supérieure. “Your operating system swallows the Blue Pill and it awakes inside the Matrix”, comme elle le dira.

À cette époque, Joanna bosse pour COSEINC Research, une boîte de sécurité basée à Singapour et ce sont eux qui financent ses recherches sur Blue Pill. Mais attention, Blue Pill n’est pas destiné à être vendu ou distribué. C’est exclusivement pour la recherche, simplement pour “prouver le concept” (PoC).

Le 3 août 2006, Las Vegas. C’est l’heure de la Black Hat, LA conférence de sécurité la plus prestigieuse au monde. Joanna monte sur scène, elle a 25 ans, elle est inconnue du grand public américain, et elle s’apprête à bouleverser le monde de la cybersécurité.

“The idea behind Blue Pill is simple”, commence-t-elle avec son accent polonais caractéristique, “Your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra-thin Blue Pill hypervisor.”

La salle est bondée. Les experts sont venus voir cette jeune chercheuse polonaise qui prétend avoir créé un rootkit indétectable. Certains sont sceptiques. D’autres curieux. Personne ne s’attend à ce qui va suivre.

Joanna lance sa démo. En quelques secondes, elle installe Blue Pill sur un système Windows Vista en cours d’exécution. Pas de redémarrage. Pas de modification visible. Le système continue de fonctionner normalement, sauf qu’il est maintenant entièrement sous le contrôle de Blue Pill.

Elle montre alors comment Blue Pill peut intercepter tous les appels système, modifier les résultats, cacher des processus, des fichiers, des connexions réseau. Tout ça sans toucher à un seul octet du kernel Windows. Les outils de détection de rootkits ne voient rien, les antivirus sont aveugles et le système lui-même n’a aucune idée qu’il s’exécute dans la machine virtuelle.

Le plus fou c’est que Blue Pill n’exploite aucun bug dans AMD-V ou Intel VT-x. Il utilise uniquement les fonctionnalités documentées. Ce n’est pas un exploit, c’est une utilisation créative de la technologie. “Blue Pill does *not* rely on any bug in Pacifica neither in OS”, précise-t-elle.

La démonstration se termine. Un silence de cathédrale règne dans la salle. Puis les applaudissements explosent. Les experts présents réalisent qu’ils viennent d’assister à quelque chose d’historique. Joanna Rutkowska vient de prouver que la virtualisation hardware peut être “weaponisée”.

L’impact est immédiat et dévastateur et les médias s’emparent de l’histoire. eWeek Magazine la nomme parmi les “Five Hackers who put a mark on 2006”. Les forums de sécurité s’enflamment et les débats font rage. Est-ce vraiment indétectable ? Comment se protéger ? Faut-il interdire la virtualisation hardware ?

Microsoft est en panique totale. Leur nouveau Vista, qui devait être le système le plus sécurisé jamais créé, vient d’être compromis par une hackeuse de 25 ans et surtout, Intel n’est pas mieux car leur technologie VT-x, censée améliorer la sécurité, devient soudain une menace. Même AMD essaie de minimiser, publiant un communiqué disant que Blue Pill n’est pas vraiment “indétectable”.

Mais Joanna ne s’arrête pas là et dans les mois qui suivent, elle publie plus de détails techniques sur son blog “The Invisible Things”. Elle explique comment Blue Pill fonctionne, les défis techniques qu’elle a dû surmonter. Bien sûr, elle ne publie pas le code source complet (COSEINC garde ça pour leurs trainings), mais elle donne assez d’infos pour que d’autres chercheurs comprennent.

Et en 2007, la controverse atteint son paroxysme. Trois chercheurs en sécurité de renom, Thomas Ptacek de Matasano Security, Nate Lawson de Root Labs et Peter Ferrie de Symantec, défient publiquement Joanna. Ils prétendent avoir développé des techniques pour détecter Blue Pill et ils lui proposent un duel à Black Hat 2007.

Leur présentation s’intitule “Don’t Tell Joanna: The Virtualised Rootkit Is Dead”. Ils veulent prouver que Blue Pill n’est pas si indétectable que ça alors ils proposent un challenge : leur détecteur contre le rootkit de Joanna. Que le meilleur gagne !

Joanna accepte le défi, mais à une condition : Elle demande 384 000 dollars pour participer. Pas par cupidité, mais pour border le projet car ce qu’elle a maintenant, c’est un prototype et pour en faire quelque chose de vraiment “hard to detect”, il faudrait deux personnes à plein temps pendant six mois à 200 dollars de l’heure. Elle et Alexander Tereshkin ont déjà investi quatre mois-personnes et il en faudrait douze de plus pour avoir un vrai rootkit de production.

Certains disent qu’elle a peur de perdre, d’autres comprennent sa position et que le montant demandé représente le coût réel du développement d’un rootkit de production, et pas juste une preuve de concept académique.

Finalement, le duel n’aura pas lieu et les deux parties s’accordent sur le fait qu’en l’état actuel, Blue Pill n’est pas prêt pour un tel challenge. Mais les chercheurs présentent quand même leur talk. Joanna et Alexander Tereshkin contre-attaquent avec leur propre présentation, démontrant que les méthodes de détection proposées sont imprécises et facilement contournables.

En avril 2007, au milieu de cette tempête médiatique, Joanna prend alors une décision qui va changer sa vie. Elle fonde Invisible Things Lab (ITL) à Varsovie. L’idée est simple : créer un laboratoire de recherche indépendant, focalisé sur la sécurité système au plus bas niveau. Pas de produits commerciaux, pas de bullshit marketing. Juste de la recherche pure et dure.

ITL attire rapidement les meilleurs talents. Alexander Tereshkin, un génie russe de la sécurité hardware. Rafał Wojtczuk, un expert polonais des systèmes d’exploitation qui deviendra son bras droit pendant des années. Ensemble, ils forment une dream team de la sécurité offensive. Et leur première cible majeure c’est Intel Trusted Execution Technology (TXT).

C’est une technologie qui est censée garantir qu’un système démarre dans un état sûr, non compromis. C’est le Saint Graal de la sécurité à savoir un boot de confiance, vérifié par le hardware. Intel en fait la promotion comme LA solution contre les rootkits.

Alors en janvier 2009, Joanna et Rafał frappent fort et publient une attaque dévastatrice contre Intel TXT. Le point faible c’est le System Management Mode (SMM), un mode d’exécution spécial du processeur qui a plus de privilèges que tout le reste, y compris l’hyperviseur. C’est le ring -2, encore plus profond que le ring -1 de Blue Pill !

Leur découverte est brillante dans sa simplicité car TXT vérifie l’intégrité du système au démarrage, mais il ne vérifie pas le code SMM. Si un attaquant parvient à infecter le SMM avant le boot, il peut alors survivre au processus de démarrage sécurisé et compromettre le système “de confiance”. Pour prouver leur dires, ils créent un rootkit SMM qui s’installe via une vulnérabilité de cache poisoning et une fois en place, il peut compromettre n’importe quel système, même après un boot TXT “sécurisé”. Ils démontrent ainsi l’attaque en ajoutant une backdoor au hyperviseur Xen.

Game over pour Intel TXT.

Intel est furieux. Non seulement leur technologie phare vient d’être cassée, mais Joanna révèle que des employés Intel avaient alerté le management sur cette vulnérabilité dès 2005. Trois ans d’inaction. Trois ans pendant lesquels les clients ont cru être protégés alors qu’ils ne l’étaient pas. C’est un scandale.

Face au silence d’Intel, Joanna et Rafał décident de leur forcer la main. En mars 2009, ils annoncent qu’ils vont publier le code complet de leur exploit SMM. C’est un coup de poker risqué car publier un exploit aussi puissant pourrait être dangereux, mais c’est le seul moyen de forcer Intel à agir.

Heureusement, la stratégie fonctionne et Intel se met enfin au boulot pour pondre des correctifs. Mais le problème est complexe car il ne s’agit pas juste de patcher un bug. Il faut repenser toute l’architecture de confiance, développer un “SMM Transfer Monitor” (STM), convaincre les fabricants de BIOS de l’implémenter. Ça va prendre des années.

Pendant ce temps, Joanna continue d’explorer d’autres angles d’attaque. Elle s’intéresse particulièrement aux attaques physiques. C’est dans ce contexte qu’elle invente un concept qui va entrer dans l’histoire : l’attaque “Evil Maid”.

L’idée lui vient lors d’un voyage. Elle réalise que même avec le chiffrement intégral du disque, un laptop laissé dans une chambre d’hôtel reste vulnérable. Une femme de chambre malveillante (d’où le nom “Evil Maid”) pourrait booter l’ordinateur sur une clé USB, installer un keylogger dans le bootloader, et capturer le mot de passe de déchiffrement lors du prochain démarrage.

En 2009, elle publie alors une preuve de concept contre TrueCrypt, le logiciel de chiffrement le plus populaire de l’époque. L’attaque est élégante : une clé USB bootable qui modifie TrueCrypt pour enregistrer le mot de passe. L’utilisateur revient, tape son mot de passe, et hop, il est enregistré sur le disque. L’attaquant n’a plus qu’à revenir pour le récupérer.

Le terme “Evil Maid attack” entre immédiatement dans le vocabulaire de la sécurité car il capture parfaitement la vulnérabilité fondamentale des appareils laissés sans surveillance. Même avec les meilleures protections logicielles, un accès physique change tout. C’est devenu un classique, au même titre que “man-in-the-middle” ou “buffer overflow”. Mais Joanna ne se contente pas de casser des choses… Elle veut aussi construire et c’est là que naît son projet le plus ambitieux : Qubes OS.

L’idée de Qubes germe depuis longtemps dans son esprit, car après des années à découvrir faille sur faille, elle réalise une vérité fondamentale : aucun système n’est sûr. Il y aura toujours des bugs, toujours des vulnérabilités. La question n’est donc pas “si” mais “quand” un système sera compromis.

Alors plutôt que d’essayer de créer un système parfait (mission impossible), pourquoi ne pas créer un système qui assume qu’il sera compromis ? Un système où la compromission d’une partie n’affectera pas le reste ? C’est le concept de “security by compartmentalization”, la sécurité par compartimentation.

En 2010, elle s’associe avec Rafał Wojtczuk et Marek Marczykowski-Górecki pour concrétiser cette vision. Qubes OS est basé sur Xen, un hyperviseur bare-metal mais au lieu d’utiliser Xen pour faire tourner plusieurs OS complets, Qubes l’utilise pour créer des dizaines de machines virtuelles légères, chacune dédiée à une tâche spécifique. Vous voulez surfer sur des sites douteux ? Une VM dédiée isolée. Faire du banking en ligne ? Une autre VM. Travailler sur des documents sensibles ? Encore une autre VM. Chaque VM est isolée des autres, comma ça, si l’une est compromise par un malware, les autres restent safe. C’est loin d’être con !

Mais Qubes va encore plus loin. Il utilise des VMs spécialisées pour les tâches critiques. NetVM gère uniquement le réseau. USB VM gère les périphériques USB (super dangereux). AudioVM gère le son. Ainsi, même si un driver est compromis, il ne peut pas accéder au reste du système. L’isolation est totale.

Le développement de Qubes est un défi monumental car il faut repenser toute l’expérience utilisateur. Comment faire pour que l’utilisateur lambda puisse utiliser des dizaines de VMs sans devenir fou ? Comment gérer le copier-coller entre VMs de manière sécurisée ? Comment partager des fichiers sans compromettre l’isolation ?

Joanna et son équipe passent ainsi deux ans à résoudre ces problèmes. Ils créent des mécanismes élégants pour que tout soit transparent. Les fenêtres des différentes VMs s’affichent sur le même bureau, avec des bordures colorées pour indiquer leur niveau de sécurité (rouge pour non fiable, jaune pour perso, vert pour travail, etc.) et le copier-coller fonctionne, mais de manière contrôlée via des canaux sécurisés.

Puis le 3 septembre 2012, Qubes OS 1.0 est officiellement lancé. La réaction de la communauté sécurité est mitigée. Certains adorent le concept tandis que d’autres trouvent ça trop complexe, trop lourd, trop paranoïaque. “C’est overkill”, disent certains. “C’est le futur”, répondent d’autres. Mais Joanna a un supporter de poids…

En 2013, Edward Snowden fuit les États-Unis avec des téraoctets de documents classifiés de la NSA. Pour communiquer avec les journalistes de manière sécurisée, il a besoin d’un système ultra-sécurisé. Son choix ? Qubes OS.

Le 29 septembre 2016, Snowden tweete : “If you’re serious about security, @QubesOS is the best OS available today. It’s what I use, and free. Nobody does VM isolation better.” Pour Joanna, c’est une validation extraordinaire car si l’homme le plus recherché du monde fait confiance à Qubes pour sa sécurité, c’est que le système fonctionne.

Le soutien de Snowden propulse Qubes dans la lumière et, d’un coup, tout le monde veut comprendre ce système. Les journalistes qui travaillent sur des sujets sensibles l’adoptent (Laura Poitras, Glenn Greenwald), les activistes l’utilisent, les chercheurs en sécurité aussi.

Mais Joanna reste humble. “A reasonably secure operating system”, c’est comme ça qu’elle décrit Qubes. Pas “ultra-secure”, pas “unbreakable”. Juste “reasonably secure”. Cette humilité, cette reconnaissance des limites, c’est ce qui fait la force de son approche car elle sait qu’aucun système n’est parfait.

Au fil des ans, Qubes continue d’évoluer. Version 2.0 en 2014, 3.0 en 2015, 4.0 en 2018. Chaque version apporte des améliorations, des raffinements et l’équipe grandit. La communauté aussi. Qubes devient une référence dans le monde de la sécurité, utilisé par ceux qui ont vraiment besoin de protection.

Mais Joanna a une philosophie qui la distingue des autres, car elle refuse catégoriquement de déposer des brevets. “I proudly hold 0 (zero) patents”, affirme-t-elle sur ses réseaux. Pour elle, les brevets sont antithétiques à la sécurité et la sécurité doit être ouverte, vérifiable, accessible à tous et surtout pas enfermée dans des coffres légaux.

Cette philosophie s’étend à sa vision de la liberté individuelle. “I strongly believe that freedom of individuals is the most important value”, dit-elle car pour elle, la sécurité informatique n’est pas une fin en soi. C’est un moyen de préserver la liberté, de permettre aux individus de faire des choix, de protéger leur vie privée contre les États et les corporations.

En octobre 2018, après neuf ans à la tête de Qubes et d’ITL, Joanna surprend tout le monde. Elle annonce qu’elle prend un congé sabbatique. Elle veut explorer de nouveaux horizons, réfléchir à la suite. Qubes est entre de bonnes mains avec Marek Marczykowski-Górecki qui prend la relève.

Sa décision est mûrement réfléchie. “These are very important problems, in my opinion, and I’d like to work now on making the cloud more trustworthy, specifically by limiting the amount of trust we have to place in it”, explique-t-elle. Après avoir sécurisé les endpoints, elle veut maintenant s’attaquer au cloud.

Nouvelle surprise : Joanna rejoint Golem, un projet de blockchain visant à créer un “ordinateur décentralisé”. Elle devient Chief Strategy Officer et Chief Security Officer. Son passage de la sécurité des endpoints à la blockchain surprend beaucoup de monde. “Qu’est-ce qu’elle va faire dans la crypto ?”, se demandent certains.

Mais pour Joanna, c’est une évolution logique car après avoir passé des années à sécuriser des systèmes individuels, elle veut maintenant s’attaquer à la sécurité des systèmes distribués. Comment sécuriser un ordinateur composé de milliers de machines appartenant à des inconnus ? Comment garantir la confidentialité dans un système décentralisé ?

En juillet 2019, la Golem Foundation commence alors ses opérations et Joanna devient “Long-term navigator and Wildland chief architect”. Son projet le plus ambitieux chez Golem c’est Wildland, un système de fichiers décentralisé qui veut libérer les données des silos des GAFAM. L’idée de Wildland c’est de permettre aux utilisateurs de stocker leurs données où ils veulent (Amazon S3, Dropbox, leur propre serveur, IPFS…) tout en ayant une interface unifiée. Plus besoin de se souvenir où est stocké quoi. Plus de vendor lock-in. Vos données vous appartiennent vraiment.

Et surtout, Wildland va plus loin que le simple stockage. Il introduit des concepts innovants comme la “multi-catégorisation” (un fichier peut appartenir à plusieurs catégories simultanément) et le “cascading addressing” (possibilité de créer des hiérarchies complexes sans point central de confiance). C’est de la décentralisation pragmatique.

“What we believe we do in a non-standard way is we are more pragmatic”, explique Joanna. “We don’t tell the user: ditch any kind of data centers you use and only use a P2P network. We say: use anything you want.” Cette approche pragmatique, c’est du pur Joanna.

Le 24 juin 2021, Wildland 0.1 est lancé lors d’un meetup à Varsovie. Joanna présente le projet : “Wildland containers are similar to Docker containers, except that dockers are for code, and Wildland containers can store any type of information.” L’accueil est positif mais mesuré. Le projet est ambitieux, peut-être trop.

Pour Joanna, Wildland représente la suite logique de son travail sur Qubes. Si Qubes compartimente l’exécution pour la sécurité, Wildland compartimente les données pour la liberté. Les deux ensemble offrent une vision d’un futur où les utilisateurs reprennent le contrôle de leur vie numérique.

Aujourd’hui, Joanna continue son travail sur les systèmes décentralisés. Elle reste conseillère pour Qubes OS, participe aux décisions stratégiques et sur son profil GitHub, ces 2 mots résument sa philosophie : “Distrusts computers.” Cette méfiance fondamentale envers la technologie, paradoxale pour quelqu’un qui y a consacré sa vie, est en fait sa plus grande force.

C’est parce qu’elle ne fait pas confiance aux ordinateurs qu’elle peut les sécuriser. C’est parce qu’elle comprend leurs failles qu’elle peut les protéger. C’est parce qu’elle sait qu’ils nous trahiront qu’elle construit des systèmes qui limitent les dégâts.

Elle a montré que la virtualisation pouvait être une arme avec Blue Pill. Elle a prouvé qu’aucun système n’est inviolable avec ses attaques contre Intel TXT. Elle a inventé des concepts comme l’Evil Maid attack qui font maintenant partie du vocabulaire de base. Mais surtout, elle a créé Qubes OS, un système qui protège les plus vulnérables. Journalistes, activistes, lanceurs d’alerte… Tous ceux qui ont vraiment besoin de sécurité utilisent Qubes. C’est son œuvre majeure, sa contribution la plus importante à la liberté numérique.

Elle incarne aussi une certaine éthique du hacking. Pas le hacking pour la gloire ou l’argent (elle aurait pu se faire des millions avec des brevets), mais le hacking comme outil de liberté. Le hacking comme moyen de reprendre le contrôle. Le hacking comme acte de résistance contre les systèmes opaques et les monopoles technologiques.

Aujourd’hui, Joanna continue d’écrire, de chercher et de construire. Ses articles sur “Intel x86 Considered Harmful” et “State Considered Harmful” proposent des visions radicales de ce que pourrait être l’informatique. Un monde sans état persistant, sans les architectures x86 legacy, sans les compromis du passé.

Des rêves impossibles ? Peut-être pas…

Sources : Wikipedia - Joanna Rutkowska, Wikipedia - Blue Pill, The Invisible Things Blog, Black Hat 2006 - Blue Pill Presentation, Qubes OS Official Website, Edward Snowden Twitter, Wildland Project, Invisible Things Lab

Bon, là on va parler d’un truc qui va faire trembler pas mal de développeurs. VulnHuntr, c’est le nouveau joujou de Protect AI qui utilise l’intelligence artificielle pour dénicher des vulnérabilités 0-day dans du code Python. Et quand je dis dénicher, c’est pas pour rigoler car en quelques heures seulement, cet outil a trouvé plus d’une douzaine de failles critiques dans des projets open source ayant plus de 10 000 étoiles sur GitHub !

Le principe c’est qu’au lieu de balancer tout le code source dans un LLM et espérer qu’il trouve quelque chose, VulnHuntr découpe le code en petits morceaux digestes. Puis il analyse méthodiquement la chaîne complète depuis l’entrée utilisateur jusqu’à la sortie serveur, en demandant uniquement les portions de code pertinentes.

L’outil peut ainsi détecter sept types de vulnérabilités majeures : exécution de code à distance (RCE), inclusion de fichiers locaux (LFI), falsification de requêtes côté serveur (SSRF), cross-site scripting (XSS), références directes non sécurisées (IDOR), injection SQL et écrasement arbitraire de fichiers.

Pas mal pour un outil gratuit et open source, non ?

Et puis il y a la liste des victimes… euh pardon, des projets où VulnHuntr a trouvé des failles. Je vous présente gpt_academic (67k étoiles), ComfyUI (66k étoiles), Langflow (46k étoiles), FastChat (37k étoiles), et j’en passe. Des projets ultra populaires dans l’écosystème IA qui se sont fait épingler avec des vulnérabilités critiques. Par exemple, Ragflow s’est retrouvé avec une belle RCE qui a été corrigée depuis.

Pour l’utiliser, c’est assez simple puisque ça s’installer avec pipx ou Docker (d’ailleurs ils recommandent Python 3.10 spécifiquement à cause de bugs dans Jedi). Ensuite, vous exportez votre clé API Anthropic ou OpenAI, et vous lancez l’analyse sur votre repo. Attention quand même, les développeurs préviennent que ça peut vite coûter cher en tokens si vous n’avez pas mis de limites de dépenses !

Je trouve son workflow plutôt bien pensé, car le LLM résume d’abord le README pour comprendre le contexte du projet et fait ensuite une première analyse afin d’identifier les vulnérabilités potentielles. Pour chaque faille détectée, VulnHuntr relance alors une analyse spécifique avec un prompt adapté au type de vulnérabilité. Puis il continue à demander du contexte (fonctions, classes, variables d’autres fichiers) jusqu’à avoir reconstruit toute la chaîne d’appel. À la fin, vous avez un rapport détaillé avec le raisonnement, un exploit proof-of-concept, et un score de confiance.

D’après les retours, un score de confiance inférieur à 7 signifie qu’il n’y a probablement pas de vulnérabilité. Un score de 7, c’est à investiguer. Et 8 ou plus, c’est très probablement une vraie faille. Les développeurs recommandent d’ailleurs d’utiliser Claude plutôt que GPT, car apparemment les résultats sont meilleurs, ce qui ne m’étonne pas.

Malheureusement, pour le moment, ça ne fonctionne que sur du code Python et même s’ils ont ajouté le support d’Ollama pour les modèles open source, les résultats ne sont pas terribles avec ces derniers car ils galèrent à structurer correctement leur output. A voir avec le dernier modèle OSS d’OpenAI cela dit…

Alors d’un côté, je trouve ça génial d’avoir un outil aussi puissant pour sécuriser nos propres projets mais de l’autre, ça montre à quel point nos codes sont vulnérables et combien il est facile pour quelqu’un de mal intentionné de trouver des failles. Voilà, donc si vous développez en Python, je vous conseille vraiment de tester VulnHuntr sur vos projets car mieux vaut découvrir les failles vous-même plutôt que de les voir exploitées dans la nature !

Un scénario classique en entreprise c’est un script Python de synchronisation qui doit tourner sous Windows et qui se barre en erreur à chaque redémarrage. Le coupable c’est ce fichu service Windows qui s’obstine à chercher sa configuration dans C:\Windows\System32 plutôt que dans le répertoire de l’application. Du coup, ça prend 3 heures de débogage pour un problème vieux comme Windows NT et ça c’est moche !

Car le problème avec les services Windows, c’est qu’ils sont coincés dans les années 90. La commande sc create ne fonctionne qu’avec des applications spécialement conçues pour être des services. Et NSSM est puissant mais avec une interface en ligne de commande cryptique et des éditions du registre à la main. Et le pire dans tout ça, c’est ce fameux répertoire de travail bloqué sur System32 qui fait planter la moitié des applications qui dépendent de chemins relatifs.

La bonne nouvelle c’est qu’il existe Servy qui débarque comme une bouffée d’air frais dans cet écosystème poussiéreux. Développé entièrement en C# par Aelassas, ce petit outil open source fait exactement ce qu’on attend de lui à savoir transformer n’importe quel executable en service Windows, avec une vraie interface graphique moderne et surtout, la possibilité de définir ce foutu répertoire de travail.

Pour l’utiliser, il vous suffit de télécharger la dernière release sur GitHub, de le décompresser, et de lancez Servy.exe. L’interface est claire… nom du service, description, chemin de l’exe, working directory (enfin !), paramètres de démarrage, et c’est parti. En 30 secondes, votre application Node.js, votre script Python ou votre serveur web tournera alors comme un vrai service Windows.

Et les fonctionnalités de Servy vont bien au-delà du simple lancement puisqu’il intègre des health checks configurables avec intervalle personnalisé (30 secondes par défaut) et un nombre d’échecs tolérés avant action. Le système de recovery gère comme un chef le redémarrage du service, du processus, ou même de la machine complète selon vos besoins. Et pour éviter les boucles infinies, vous pouvez bien sûr limiter le nombre de tentatives de redémarrage.

La gestion des logs est également un autre point fort de Servy puiqu’il peut rediriger automatiquement stdout et stderr vers des fichiers avec rotation automatique basée sur la taille. Comme ça, plus besoin de scripts batch complexes ou de solutions tierces pour capturer les sorties de vos applications console. Tout est géré proprement, avec des logs organisés et consultables.

Selon le guide Windows Services Manager, accéder aux services Windows reste toujours aussi archaïque : Win+R, services.msc, + Entrée. Heureusement, avec Servy, tout se fait depuis son interface. Vous pouvez démarrer, arrêter, mettre en pause, redémarrer vos services, modifier leur priorité (Real-time, High, Normal, Low), et même définir le type de démarrage (Automatic, Manual, Disabled).

Un détail qui fait la différence avec d’autres outils du même genre, c’est la prévention des processus zombies. Hé oui, Servy se la joue comme dans Walking Dead et gère proprement le cycle de vie des processus enfants, s’assurant qu’aucun processus orphelin ne traîne après l’arrêt d’un service. C’est le genre de conneries qu’on découvre généralement après plusieurs semaines de production, quand le serveur commence à ramer sans raison apparente.

Et ça tourne aussi bien de Windows 7 SP1 jusqu’à Windows 11, en passant par toutes les versions Server. Et surtout, le code source complet est disponible sur GitHub sous licence MIT.

Bref, c’est un super outil gratuit, open source, avec une interface bien pensée, et toutes les fonctionnalités dont on rêvait sans le côté usine à gaz !!

Pour les entreprises, c’est une solution idéale pour déployer des applications métier sans les réécrire, avoir à se former sur NSSM ou de maintenir des scripts PowerShell complexes. Cet outil permet de réduire les coûts de maintenance et les erreurs humaines. Bref, c’est un logiciel qui devrait être dans la boîte à outils de tout les admins Windows qui se respectent.

Ça vous dirait de pouvoir taper cursor-agent "trouve et corrige tous les bugs" dans votre terminal et voir GPT-5 analyser l’ensemble de votre code, proposer des corrections, et même les appliquer après votre validation ?

Plus besoin de copier-coller entre ChatGPT et votre éditeur, plus besoin de jongler entre interfaces. Et bien c’est exactement ce que Cursor CLI propose.

Avec la sortie de GPT-5 et l’explosion des assistants de code IA, Cursor frappe fort en proposant une alternative terminal-first qui s’intègre partout : JetBrains, Android Studio, Xcode, ou même directement dans votre shell préféré. Et ce qui est cool c’est qu’on peut utiliser GPT-5 gratuitement pendant la beta.

Alors perso, moi je suis un fervent utilisateur de Claude Code qui fonctionne excellement bien, à tel point que je trouve les IDE Cursor et Windsurf un peu nul maintenant. Donc voir Cursor sortir son clone de Claude Code, branché sur GPT-5, évidemment, ça m’intéresse.

L’installation se fait avec cette ligne magique :

curl https://cursor.com/install -fsS | bash

Une fois installé, vous suivez les instructions pour exporter cursor-agent dans votre environnement shell et ensuite vous lancez cursor-agent, et vous voilà avec un agent IA surpuissant directement dans votre terminal. Selon la documentation officielle, le CLI réutilise toute votre configuration Cursor existante : vos règles personnalisées, votre fichier AGENTS.md, et même vos intégrations MCP.

Ce qui distingue Cursor CLI des alternatives comme Claude Code ou Gemini CLI, c’est son système d’approbation granulaire. Par exemple, si vous demandez à l’agent de créer une API Express avec des tests Jest, il vous montrera d’abord les modifications proposées. Vous pouvez ensuite accepter, refuser, ou modifier chaque changement avant qu’il ne touche vos fichiers. Cette approche réduit considérablement les erreurs par rapport aux solutions qui appliquent tout automatiquement.

La vraie puissance du truc se révèle surtout dans l’automatisation, car vous pouvez créer des scripts qui utilisent Cursor CLI pour :

• Générer automatiquement de la documentation à partir de votre code
• Lancer des revues de sécurité sur chaque commit
• Créer des agents personnalisés pour vos workflows spécifiques
• Scaffolder des projets entiers avec une seule commande

Le support des modèles est lui aussi impressionnant. A part GPT-5, vous avez accès à Claude 4 Sonnet, Opus (et aussi Gemini, Grok, o3…etc mais j’ai pas vu ça dans ma beta). Un simple /model ls liste tous les modèles disponibles, et /model gpt-5 vous permet de basculer dessus instantanément. Cette flexibilité permet d’utiliser le modèle le plus adapté à chaque tâche.

Perso, j’ai beaucoup testé GPT-5 hier via Windsurf pour voir ce qu’il avait dans le ventre (sur du code uniquement) et hormis le fait que c’était lent de fou, ça ne m’a pas non plus très impressionné. J’avais un bug à régler et le truc a tourné toute la matinée pour au final me faire un gros caca. Et j’ai fini par résoudre le bug en fin de journée, cette fois avec Claude Code et en quelques dizaines de minutes. Donc j’avoue que pour le moment, je suis hyper déçu de GPT-5 mais bon, je lui redonnerai sa chance plus tard.

Pour les équipes, Cursor CLI c’est top pour votre CI/CD. Vous pourriez par exemple concevoir des pipelines qui utilisent GPT-5 pour :

• Générer automatiquement des tests pour le code non couvert
• Optimiser les performances avant chaque déploiement
• Créer des changelogs détaillés basés sur les commits
• Adapter automatiquement le code aux breaking changes des dépendances

Le système de règles personnalisées change aussi la donne. Vous pouvez définir des contraintes spécifiques dans votre fichier AGENTS.md (TypeScript strict, tests obligatoires, commentaires en français, etc.) et Cursor CLI respectera ces règles dans toutes ses générations.

L’aspect privacy est également bien pensé aussi car contrairement à des outils comme Copilot qui envoie votre contexte en permanence, Cursor CLI ne transmet que ce que vous lui demandez explicitement. Vos secrets restent locaux et votre code propriétaire reste protégé.

Par contre, c’est encore en beta donc il reste des bugs notamment sous Windows (WSL), et certains utilisateurs ont indiqué avoir des timeouts sur les gros projets. Mais bon, ça comme avec Claude Code, l’équipe met à jour quasiment non stop.

Pour tester rapidement, lancez simplement cursor-agent pour un chat interactif, ou utilisez les flags -m pour choisir le modèle et --no-interactive pour l’automation complète sans confirmation manuelle.

Et prochainement, il devrait y avoir du contexte persistant entre sessions, de la collaboration multi-agents, et même une intégration native avec les éditeurs via LSP.

Voilà, donc si vous cherchez une alternative à Claude Code ou GitHub Copilot qui respecte votre workflow dans le terminal, Cursor CLI mérite le détour. C’est gratuit pendant la beta et ça devrait bien vous aider !

J’ai vu sur Github un développeur qui a réussi à résoudre le problème le plus universel du télétravail. Ce problème c’est cette fâcheuse tendance qu’on a tous à finir comme Quasimodo, complétement avachis devant notre écran après deux heures de coding, de blogging ou de bitching sur Mastodon.

SlouchDetector, c’est donc l’œuvre d’Alexander Kranga qui a eu cette idée brillante à savoir utiliser MediaPipe pour apprendre à la machine votre posture idéale et vous balancer une alerte quand vous commencez à vous ratatiner. Le tout tourne directement dans votre navigateur, sans qu’aucune donnée ne parte sur Internet. Votre webcam, votre navigateur, et votre vie privée respectée.

Ce qui rend ce projet vraiment bien, c’est qu’il résout un vrai problème. Car selon Planet Nomad, une mauvaise posture au bureau peut réduire la productivité de 18% et augmenter les troubles musculo-squelettiques (TMS) de 65%. Et le pire, c’est qu’on ne se rend même pas compte quand on commence à s’affaler sur notre clavier.

Pour cela, SlouchDetector utilise la détection faciale de MediaPipe pour établir votre position de référence quand vous êtes bien assis et ensuite, l’algorithme surveille en temps réel les déviations par rapport à cette baseline. Pas besoin des 33 points de détection corporelle que propose MediaPipe Pose, juste votre joli visage suffit pour détecter si vous commencez à pencher vers l’écran.

Je souis là

Pour faire tourner ce truc chez vous, c’est du Next.js 15 avec React 19, TypeScript pour la robustesse, et Tailwind CSS 4 pour l’interface. Le développeur a clairement misé sur les dernières technos pour offrir une expérience fluide. Et niveau installation, c’est du classique :

npm ci
npm run dev
# Hop, c'est parti sur http://localhost:3000

Ce qui me plaît, vous vous en doutez, c’est l’approche full respect de la vie privée. Votre webcam capture, MediaPipe analyse, JavaScript alerte, et personne d’autre que vous n’est au courant que vous ressemblez à un bretzel à 16h.

MediaPipe peut détecter des postures complexes en temps réel même sur des machines modestes et c’est cette efficacité qui permet à SlouchDetector de tourner sans problème dans n’importe quel navigateur moderne, sans avoir besoin d’une RTX 4090 pour vous dire de vous redresser.

L’intérêt va au-delà du simple gadget geek. Quand on sait qu’un bureau assis-debout peut faire chuter la pression sur les disques vertébraux de 40%, imaginez l’impact d’un simple rappel régulier pour corriger sa posture. C’est un outil qui pourrait vous éviter bien des visites chez le kiné.

Je souis plou là

Bien sûr, MediaPipe ne détecte qu’une personne à la fois, donc si vous avez l’habitude de travailler avec votre chat sur les genoux, il risque de perturber la détection. Donc mangez-le, avec des frites et une petite sauce au bleu, c’est délicieux ! Les conditions d’éclairage peuvent aussi affecter la précision, mais dans l’ensemble, ça reste très utilisable au quotidien.

Le code est ici ! Et merci à Lorenper pour la découverte !

Vous aussi vous en avez marre de voir vos images disparaître d’Imgur après 6 mois d’inactivité ? Ou de devoir passer par Discord qui compresse tout ce qui bouge ?

Ça tombe bien car j’ai découvert Slink il y a quelques jours et je pense que ça va vous plaire si vous voulez retrouver le contrôle sur vos partages d’images.

Slink, c’est le projet d’Andrii Kryvoviaz, un développeur qui a décidé de combiner ses deux passions : La danse et l’amour de la forêt euuuh, non… Avoir son propre service de partage d’images ET pouvoir raccourcir les URLs en même temps. Parce que oui, en plus d’héberger vos images, Slink génère automatiquement des liens courts pour les partager facilement. Et comme le souligne XDA Developers, tout tient dans un seul container Docker, ce qui rend le déploiement hyper simple.

Le truc vraiment bien pensé, c’est que Slink ne se contente pas de stocker bêtement vos fichiers. Il génère automatiquement des previews, gère l’expiration automatique si vous le souhaitez (pratique pour les partages temporaires), et propose même un mode galerie pour organiser vos images. Le backend en Symfony assure la robustesse, tandis que le frontend en SvelteKit offre une interface moderne et réactive.

Pour l’installation, c’est du Docker classique. Créez votre docker-compose.yml :

services:
slink:
image: ghcr.io/andrii-kryvoviaz/slink:latest
container_name: slink
environment:
- DATABASE_URL=postgresql://user:password@db:5432/slink
- APP_SECRET=your-secret-key
- STORAGE_DRIVER=local
volumes:
- ./uploads:/app/uploads
- ./data:/app/data
ports:
- "3000:3000"

Et une fois lancé, vous aurez accès à une interface web complète avec drag & drop, upload multiple, et même une API REST pour automatiser vos uploads depuis vos scripts ou applications. Le système de permissions est granulaire ce qui vous permet de créer des utilisateurs, définir des quotas, et même activer l’upload anonyme si vous voulez faire votre propre service public.

Ce qui m’a particulièrement séduit dans ce projet, c’est surtout la gestion intelligente du stockage. Selon la doc GitHub, Slink supporte non seulement le stockage local, mais aussi S3 (compatible avec MinIO, Backblaze B2, etc.), et même le partage réseau via SMB. Vous pouvez également définir des limites de taille par fichier, par utilisateur, et même configurer une rétention automatique pour ne pas exploser votre espace disque.

La partie raccourcisseur d’URL est aussi vraiment bien intégrée. Chaque image uploadée reçoit automatiquement un identifiant court (style “slink.io/a8f2”), et vous pouvez aussi créer des liens personnalisés avec votre propre nom de domaine. Et contrairement à des services comme bit.ly, vous gardez le contrôle total sur vos analytics avec le nombre de vues, l’origine des visiteurs, et bien sûr tout est stocké localement (génial pour le RGPD, comme dirait le Capitaine Haddock).

Pas de tracking tiers, pas de publicités, pas de vente de données. Avec Slink, vos images restent vos images, point. Et si vous voulez partager quelque chose de sensible, Slink propose même un chiffrement côté client avec des liens à usage unique qui s’autodétruisent après consultation.

Pour les développeurs, l’API est un vrai bonheur avec de l’authentification via tokens JWT, endpoints RESTful bien documentés, et même des webhooks pour intégrer Slink dans vos workflows. Vous pouvez par exemple configurer un hook pour redimensionner automatiquement les images, les envoyer vers un CDN, ou les sauvegarder sur un service externe.

Et les performances sont au rendez-vous grâce à Rust pour la partie critique (génération des identifiants courts et routing), avec un cache Redis optionnel pour accélérer les requêtes fréquentes. Ainsi, sur un VPS basique, Slink peut facilement gérer des milliers de requêtes par seconde. Un détail sympa, le mode sombre adaptatif suit les préférences système, et il y a une PWA complète pour installer Slink comme une app native sur mobile. De plus, l’interface est responsive et fonctionne parfaitement sur tablette ou smartphone.

Après si vous cherchez des alternatives, il y a Chevereto (payant mais très complet), Lychee (orienté galerie photo), ou PictShare (plus minimaliste et que je testerai une prochaine fois…). Slink trouve donc un excellent équilibre entre fonctionnalités et simplicité, et il y a des mises à jour régulières, ce que j’apprécie beaucoup vue que ma passion dans la vie c’est lire des changelogs.

Voilà, donc pour ceux qui veulent tester avant de se lancer, le projet est entièrement open source sous licence MIT et dispo ici !

18 milliards, c’est le nombre de mots de passe compromis auxquels GoSearch peut accéder avec une simple clé API BreachDirectory. Et ce n’est que la partie émergée de l’iceberg de cet outil OSINT qui a récemment été salué dans la newsletter OSINT pour son approche innovante de la recherche d’empreintes numériques.

Vous vous souvenez de Sherlock, cet outil Python qui permettait de chercher des pseudos sur différentes plateformes ? Et bien GoSearch, c’est comme si Sherlock avait pris des stéroïdes et appris le Go. En effet, le développeur ibnaleem a créé ce projet au départ pour apprendre le langage Go, mais il s’est rapidement transformé en un véritable projet communautaire.

La différence fondamentale avec Sherlock c’est d’abord sa vitesse. Le Go se compile en binaire et utilise la concurrence de manière native, ce qui rend les recherches exponentiellement plus rapides. Mais surtout, GoSearch a résolu le problème majeur de Sherlock c’est à dire les faux négatifs. Quand Sherlock vous dit qu’un username n’existe pas alors qu’il est bien là, GoSearch le trouve. Et pour les résultats incertains, plutôt que de vous induire en erreur, il préfère les afficher en jaune pour vous signaler qu’il y a peut-être un doute.

Concrètement, GoSearch ne se contente pas de scanner plus de 300 sites web. Il accède aussi à 900 000 identifiants compromis via l’API HudsonRock’s Cybercrime Intelligence, 3,2 milliards via ProxyNova, et ces fameux 18 milliards via BreachDirectory si vous avez une clé API. Et quand il trouve des hashes de mots de passe, il tente de les cracker avec Weakpass, avec un taux de réussite proche de 100% selon le développeur (ahem…).

L’installation est ridiculement simple pour un outil aussi puissant :

go install github.com/ibnaleem/gosearch@latest

Ensuite, une recherche basique :

gosearch -u [username] --no-false-positives

Le flag --no-false-positives est important puisqu’il filtre les résultats pour ne montrer que ceux dont GoSearch est certain. Par exemple, pour une recherche approfondie avec BreachDirectory :

gosearch -u [username] -b [API-KEY] --no-false-positives

Ce qui est cool, c’est que GoSearch ne se limite pas aux pseudos. Il cherche aussi les domaines associés en testant les TLDs classiques (.com, .net, .org, etc.). Et si vous n’avez pas de pseudo précis, vous pouvez même utiliser username-anarchy pour générer des variantes à partir d’un nom et prénom.

Attention toutefois, sous Windows, Windows Defender peut parfois marquer GoSearch comme malware. C’est un faux positif et le code source est entièrement accessible sur GitHub pour vérification.

GoSearch est particulièrement efficace pour les enquêtes de sécurité et de confidentialité. Les entreprises peuvent par exemple l’utiliser pour vérifier si leurs employés ont des comptes compromis, les particuliers pour auditer leur propre empreinte numérique, et les chercheurs en sécurité pour leurs investigations OSINT.

En plus, le projet évolue constamment et les dev envisagent d’ajouter des fonctionnalités comme des options pour n’afficher que les résultats confirmés ou prioriser la détection des faux négatifs selon les besoins. Maintenant, pour ceux qui cherchent des alternatives, il existe Gopher Find (aussi en Go), Maigret, WhatsMyName ou le récent User Searcher qui prétend couvrir 2000+ sites. Mais GoSearch reste le plus équilibré entre vitesse, précision et accès aux bases de données d’identifiants compromis.

Pour le tester, c’est par ici !

5 dollars, c’est tout ce qu’il faut pour écouter légalement 1000 fois votre artiste préféré sur S█████. Enfin, “légalement” au sens où S█████ l’entend, parce qu’avec 0,005$ par stream en moyenne, on peut difficilement parler d’un modèle équitable. C’est cette réflexion qui m’amène à vous parler aujourd’hui de Spotizerr.

L’idée derrière Spotizerr est assez maligne puisque ça consiste à utiliser l’excellente interface de recherche de S█████ pour trouver vos morceaux, puis à les télécharger depuis D████ en priorité pour obtenir du FLAC, avec un fallback sur S█████ si nécessaire. Le développeur Xoconoch ne cache pas son approche pragmatique dans le README où il écrit : “Supportez vos artistes directement (merch, concerts, dons), et considérez que 5$ leur permettent de compenser 1000 écoutes”. C’est le strict minimum éthique selon lui.

Techniquement, ce qui distingue Spotizerr des autres solutions comme Spotizer (notez la différence d’orthographe), c’est son approche vraiment orientée self-hosting avec une interface web progressive (PWA). Vous pouvez l’installer comme une app native sur mobile ou desktop, avec des thèmes clairs/sombres, et surtout un système de monitoring intelligent qui surveille automatiquement vos playlists et artistes favoris pour télécharger les nouveautés.

Le système de queue est particulièrement bien pensé : téléchargements concurrents configurables, mises à jour en temps réel via Server-Sent Events, prévention automatique des doublons, et persistance de la queue même après un redémarrage du navigateur. Vous pouvez télécharger des tracks individuels, des albums complets, des playlists entières (même celles avec plus de 1000 morceaux), ou carrément la discographie complète d’un artiste avec des options de filtrage.

Pour l’installation, c’est du Docker classique et il vous faudra créer un fichier .env (basé sur l’exemple fourni), configurer vos identifiants Redis, PUID/PGID, UMASK, et lancer le docker-compose. Pour S█████, le développeur recommande d’utiliser son outil spotizerr-auth sur un PC avec le client S█████ installé pour simplifier l’authentification. Pour D████, il suffit de récupérer le cookie “arl” depuis votre navigateur (F12 → Application/Storage → Cookies → copier la valeur “arl”).

Le support multi-utilisateurs est intégré avec authentification JWT, SSO via Google et GitHub, et un panneau d’administration pour gérer tout ce petit monde. L’historique des téléchargements est complet avec métadonnées, analytics de succès/échec, recherche et filtrage, et même l’export des données avec les IDs des services externes.

Au niveau configuration audio, vous pouvez définir la qualité par service (avec les limitations selon votre type de compte), convertir vers MP3, FLAC, AAC, OGG, OPUS, WAV ou ALAC dans différents bitrates, personnaliser les patterns de nommage des fichiers et dossiers, et même filtrer le contenu explicite si nécessaire.

Notez qu’au niveau des rémunération d’artistes, le champion c’est Qobuz qui paie jusqu’à 0,03€ par stream, soit près de dix fois plus que S█████. Apple Music fait un peu mieux avec 0,007 à 0,01€ par stream, tandis que YouTube Music reste le cancre avec 0,0008€ par stream. Pendant ce temps, Amazon, Tidal et D████ proposent du FLAC en standard, alors que S█████ résiste encore et toujours sur la qualité audio haute définition.

Le système de surveillance de Spotizerr est vraiment pratique puisqu’il vous permet de configurer des intervalles de vérification, d’ajouter des playlists ou des artistes à surveiller, et les nouveaux contenus sont automatiquement téléchargés. Pour une discographie complète, vous sélectionnez les types de releases (albums, singles, compilations) et tout est mis en queue automatiquement.

Le projet est basé sur la bibliothèque deezspot et reste dans une zone grise légale. Le développeur est transparent là-dessus : c’est pour un usage éducatif et personnel, respectez les conditions d’utilisation des services et les lois sur le copyright de votre pays. Les fichiers téléchargés conservent les métadonnées originales, et les limitations s’appliquent selon votre type de compte.

Bref, pour ceux qui cherchent une solution self-hosted complète pour gérer leur bibliothèque musicale, Spotizerr s’intègre bien dans un stack avec Lidarr pour la gestion de collection et Navidrome pour le streaming. C’est une approche qui permet de garder le contrôle sur sa musique tout en profitant des catalogues des services de streaming.

Et oui, j’ai caviardé un peu l’article parce que ça m’amusait de rajouter un peu de mystère ^^.

Un logiciel qui survit depuis plus de 16 ans, c’est assez rare. Surtout quand c’est maintenu par un seul développeur qui depuis tout ce temps refuse catégoriquement d’ajouter de la pub et qui continue de faire évoluer son outil mois après mois. Ce logiciel c’est File & Image Uploader développé par Zoom et qui me rappelle cette époque bénie où les développeurs créaient des outils juste parce qu’ils en avaient besoin, et pas pour lever des millions en série A.

Ce qui m’a d’abord plu sur ce site d’une autre époque, c’est ce petit message tout en bas qui dit : “If you don’t like it, don’t use it.” C’est cool de voir un dev qui assume complètement son projet et qui ne cherche pas à plaire à tout le monde. Et vous savez quoi ? Ça marche puisque le logiciel supporte aujourd’hui plus de 700 services différents, de Google Drive à des hébergeurs dont vous n’avez probablement jamais entendu parler comme filearn.top ou tubearn.top.

Pendant que WeTransfer fait polémique avec ses nouvelles conditions d’utilisation autorisant l’exploitation des fichiers par IA (avant de faire marche arrière face au tollé), et pendant que Gofile limite toujours ses options gratuites, zoo_m continue tranquillement son chemin. Le développeur ne demande rien, ne collecte rien, ne revend rien. Il code, il publie, point.

Le truc vraiment intéressant c’est le support des uploads resumables. Zoom le fait depuis des années pour ses 700 services différents comme ça si votre connexion plante au milieu d’un upload de 10 GB vers Dropbox, pas de panique, vous reprenez exactement où vous en étiez. Et contrairement aux interfaces web qui rament avec plusieurs fichiers, ici vous pouvez lancer des uploads parallèles vers différents services simultanément. C’est un peu l’opposé à JDownloader.

Il existe plein de services web qui font pareil, mais j’aime bien l’idée d’avoir un vrai logiciel qui transforme votre PC en centrale d’upload, comme un point de repère, un phare bravant l’océan du cloud (oui, je suis d’humeur poète). Et sur lequel vous pouvez glisser vos fichiers, choisir vos destinations (oui, au pluriel), et qui se débrouille comme un chef. Pas de limite artificielle, pas de restrictions de format, pas de serveur surchargé. D’après le site officiel, c’est généralement bien plus rapide que les interfaces web parce que le logiciel optimise les connexions et évite tout le JavaScript inutile qui plombe les navigateurs.

Alors oui, l’interface n’est pas aussi léchée qu’un produit Adobe, oui, il faut lire la documentation (quelle idée bizarre en 2025 ^^), mais si vous cherchez un outil qui fait exactement ce qu’il promet sans arrière-pensées commerciales, sans tracking, sans ces formules creuses qu’on voit partout, File & Image Uploader est probablement ce qui se rapproche le plus de l’idéal du freeware tel qu’on l’imaginait dans les années 2000.

Le développeur précise d’ailleurs qu’il accepte les suggestions et peut ajouter de nouveaux services sur demande. Pas via un formulaire Google qui finira dans les limbes, mais directement via le menu Help du logiciel.

Voilà, pour ceux que ça intéresse, le logiciel est dispo en version portable (pas d’installation requise) et tourne sur Windows. Il existe des versions 32 et 64 bits, et apparemment ça fonctionne aussi sous Wine pour les linuxiens motivés. Cependant pas de version Mac et vu la philosophie du projet, je doute que ce soit dans les priorités.

Aujourd’hui, pour ma série de l’été, je vais vous raconter l’histoire complètement dingue de Marcus Hutchins, le britannique qui a sauvé le monde d’une catastrophe et ça lui a coûté seulement 10,69 dollars. Mais attention, ce n’est pas juste l’histoire d’un héros. C’est aussi celle d’un ancien créateur de malware, d’exploits volés à la NSA, de hackers nord-coréens, et d’un kill switch découvert par accident un vendredi après-midi de mai 2017.

Du héros au criminel, du criminel au héros, l’histoire de Marcus Hutchins ressemble à un scénario de film qu’Hollywood n’oserait même pas écrire tellement c’est gros. Accrochez-vous, car on va explorer ensemble comment un surfeur de 22 ans vivant chez ses parents a stoppé la plus grande cyberattaque de l’histoire… avant de se faire coffrer par le FBI trois mois plus tard.

Marcus Hutchins, alias MalwareTech - Le hacker qui a sauvé Internet

Marcus Hutchins naît le 2 juin 1994 à Bracknell, une ville tranquille du Berkshire, en Angleterre. Sa famille déménage ensuite à Ilfracombe, une petite station balnéaire du Devon où il passe son enfance. Un coin paumé du sud-ouest anglais où il ne se passe pas grand-chose… le genre d’endroit où un gamin intelligent peut vite s’ennuyer et chercher des trucs à faire sur Internet.

Dès l’âge de 6 ans, Marcus montre des signes d’une intelligence au-dessus de la moyenne. Il apprend à lire tout seul, dévore les livres, et se passionne pour les ordinateurs dès qu’il peut en toucher un. Mais socialement, c’est compliqué. Marcus est le genre de gosse brillant mais inadapté, celui qui préfère passer ses récréations à coder plutôt qu’à jouer au foot avec les autres. Il souffre de TDAH non diagnostiqué, ce qui complique encore plus son intégration sociale.

Ilfracombe, Devon - Où tout a commencé pour le futur MalwareTech

À 13 ans, Marcus découvre le hacking et pas par hasard. Il cherche des moyens de contourner les restrictions parentales sur son ordinateur, pour accéder à des sites bloqués… bref, les trucs classiques d’un ado curieux. Il tombe alors sur HackForums et d’autres communautés underground, et là, c’est la révélation. Il découvre un monde où son intelligence et sa curiosité sont valorisées, et où être différent est un atout.

Marcus commence doucement. Il apprend le C++, le Python, l’assembleur. Il passe ses nuits sur les forums, absorbe tout ce qu’il peut sur la sécurité informatique. À 14 ans, il écrit déjà ses premiers exploits et commence à se faire un nom dans la communauté sous le pseudo MalwareTech. Ses parents s’inquiètent de le voir passer autant de temps devant son écran, mais bon, au moins il ne traîne pas dans la rue, pas vrai ?

Entre 14 et 16 ans, Marcus plonge de plus en plus profondément dans le monde du malware. Il commence par analyser des virus existants, les désassemble, comprend comment ils fonctionnent. Puis il se met à créer ses propres outils. Rien de méchant au début, juste des proof-of-concept pour impressionner ses potes sur les forums.

Mais rapidement, la frontière entre l’expérimentation et la criminalité devient floue. Marcus commence à vendre ses créations sur des forums underground. Un rootkit par-ci, un crypter par-là. Il se fait de l’argent de poche en créant des outils que d’autres utilisent pour des activités criminelles. Pour lui, c’est juste un jeu, un moyen de prouver ses compétences et de gagner un peu d’argent.

En 2012, à 18 ans, Marcus développe ce qui deviendra son plus gros problème : UPAS Kit, un malware sophistiqué capable de voler des informations bancaires. Il vend le code source pour quelques milliers de dollars à un acheteur anonyme sur un forum russe. L’argent c’est cool, et Marcus ne pense pas vraiment aux conséquences. C’est là qu’il rencontre “Vinny”, un cybercriminel expérimenté qui voit le potentiel du code de Marcus.

Entre 2012 et 2015, Marcus et Vinny développent Kronos, une version améliorée d’UPAS Kit. Kronos est un cheval de Troie bancaire redoutable, capable d’intercepter les identifiants bancaires, de contourner l’authentification à deux facteurs, et de voler des millions. Marcus code, Vinny vend. Le malware se retrouve alors sur AlphaBay et d’autres marchés du dark web, vendu 7000 dollars la licence. Comme Zeus avant lui, Kronos utilise une combinaison de keylogging et d’injection web pour voler les identifiants bancaires directement depuis les sessions de navigation.

Le code source de Kronos - L’erreur de jeunesse qui coûtera cher

Mais en 2015, Marcus a une prise de conscience. Il réalise que son code est utilisé pour ruiner de vraies personnes, voler leurs économies, détruire des vies. Il décide donc d’arrêter, il coupe les ponts avec Vinny, abandonne ses activités criminelles, et décide de passer du côté lumineux de la Force.

Marcus lance alors le blog MalwareTech.com et commence à publier des analyses détaillées de malwares. Ses articles sont brillants, techniques, et il est rapidement remarqués par la communauté de la cybersécurité. En 2016, il décroche alors un job chez Kryptos Logic, une boîte de cybersécurité basée à Los Angeles. Pour la première fois de sa vie, Marcus a un vrai travail, légal, où ses compétences sont utilisées pour protéger plutôt que pour attaquer.

Personne ne sait rien de son passé. Pour tous, MalwareTech est juste un jeune chercheur talentueux qui a appris sur le tas. Marcus garde son secret, espère que son passé ne le rattrapera jamais. Il travaille dur, publie des recherches de qualité, aide à stopper des campagnes de malware. La rédemption semble à portée de main.

Le siège de la NSA - D’où vont fuiter les cyberarmes

Pendant que Marcus reconstruit sa vie, de l’autre côté de l’Atlantique, la NSA développe ses propres outils. Parmi eux, un exploit particulièrement vicieux baptisé EternalBlue. Cet exploit exploite une vulnérabilité dans le protocole SMBv1 de Windows, permettant d’exécuter du code à distance sur n’importe quelle machine Windows vulnérable, sans aucune interaction de l’utilisateur.

EternalBlue, c’est la Rolls-Royce des exploits. Vous êtes connecté au même réseau qu’une machine vulnérable ? Boum, vous pouvez la contrôler. C’est l’outil parfait pour l’espionnage. Le problème, c’est que la NSA garde cet exploit secret pendant des années. Au lieu de prévenir Microsoft pour qu’ils corrigent la faille, ils préfèrent garder leur jouet pour leurs opérations.

En 2016, un groupe mystérieux appelé les Shadow Brokers fait son apparition. Personne ne sait vraiment qui ils sont… des hackers russes ? Des insiders de la NSA ? Le mystère reste entier. Ce qui est sûr, c’est qu’ils ont mis la main sur les outils de l’équipe d’élite de la NSA, l’Equation Group.

Les Shadow Brokers tentent d’abord de vendre ces outils aux enchères pour 1 million de bitcoins. Personne ne mord à l’hameçon. Le 14 avril 2017, frustrés de ne pas avoir trouvé d’acheteurs, ils balancent tout gratuitement sur Internet. Dans le lot : EternalBlue, DoublePulsar, et une collection d’autres cyberarmes. C’est comme si quelqu’un venait de publier les plans d’une bombe atomique numérique.

Microsoft avait été prévenu alors un mois avant la publication par les Shadow Brokers, le 14 mars 2017, ils sortent le patch MS17-010. La faille est corrigée pour toutes les versions de Windows encore supportées. Mais voilà le problème… des millions de machines tournent encore sous Windows XP, Windows Server 2003, des systèmes qui ne reçoivent plus de mises à jour depuis des années. Et puis y’a tous ceux qui ne patchent jamais.

Quelque part en Corée du Nord, le Lazarus Group voit une opportunité. Ces hackers d’élite du régime de Kim Jong-un (les mêmes qui ont hacké Sony Pictures en 2014 et volé 81 millions à la banque du Bangladesh en 2016) décident d’utiliser EternalBlue pour créer quelque chose de nouveau : un ransomware capable de se propager tout seul.

Le 12 mai 2017, à 7h44 UTC, l’attaque commence et les premières victimes sont en Asie, probablement parce que l’attaque a été lancée pendant les heures de bureau là-bas. WannaCry (aussi appelé WannaCrypt, WanaCrypt0r 2.0, ou Wanna Decryptor) n’est pas un ransomware ordinaire. C’est un ver qui scanne le réseau local et Internet à la recherche d’autres victimes vulnérables sur le port 445 (SMB).

L’écran de la mort WannaCry - “Oops, your files have been encrypted!”

Le ransomware chiffre les fichiers de la victime avec un algorithme RSA-2048. Les documents, photos, vidéos, tout y passe, puis il affiche son fameux écran rouge demandant 300$ en Bitcoin, doublé à 600$ après trois jours. Si vous ne payez pas dans la semaine, vos fichiers sont perdus pour toujours. Mais le plus vicieux, c’est la vitesse de propagation car chaque machine infectée devient immédiatement un nouveau vecteur d’infection. Une machine en infecte dix, qui en infectent cent, qui en infectent mille…

En quelques heures, c’est la panique mondiale. En Espagne, Telefónica est touché, en Russie, c’est le ministère de l’Intérieur qui est frappé avec plus de 1000 ordinateurs infectés. FedEx est paralysé, leur filiale TNT Express doit revenir aux opérations manuelles et Renault doit arrêter la production dans plusieurs usines.

Mais c’est au Royaume-Uni que l’impact est le plus dramatique. Le NHS, le service de santé public britannique, est frappé de plein fouet. 81 des 236 fiducies du NHS sont touchés ainsi que plus de 595 cabinets de médecins généralistes. Les conséquences sont immédiates et terrifiantes.

Les hôpitaux britanniques paralysés par WannaCry

Les médecins ne peuvent plus accéder aux dossiers des patients, les systèmes de rendez-vous sont hors service, les résultats de tests sanguins, inaccessibles. Les scanners et IRM dans certains hôpitaux ne fonctionnent plus. Des ambulances doivent être détournées vers d’autres hôpitaux. 19 000 rendez-vous sont annulés, des opérations non urgentes reportées. Le coût pour le NHS est de 92 millions de livres sterling soit 20 millions en perte d’activité immédiate et 72 millions pour restaurer les systèmes.

Un médecin raconte : “C’était le chaos total. On avait des Post-it partout pour noter les informations vitales. On faisait des allers-retours entre les services pour transmettre les résultats de tests à la main. C’était comme revenir 30 ans en arrière, mais sans y être préparé.”

Pendant ce temps, à Ilfracombe dans le Devon, Marcus Hutchins se réveille. Il est en vacances, censé se détendre et faire du surf. Mais les alertes sur son téléphone lui disent que quelque chose de grave se passe. Marcus a maintenant 22 ans, et il travaille depuis sa chambre d’enfance sur un setup à trois écrans. Il interrompt son déjeuner et se met au travail.

Marcus télécharge un échantillon du malware et le fait tourner dans une sandbox, et là, il remarque quelque chose d’étrange. Avant de chiffrer les fichiers, le malware essaie de contacter un domaine : iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com. Un nom de domaine complètement random, 42 caractères de charabia. Marcus vérifie et constate que le domaine n’existe pas.

Par curiosité professionnelle et réflexe d’analyse, Marcus décide alors d’enregistrer le domaine pour tracker l’infection. Ça lui coûte 10,69 dollars sur NameCheap et il configure quelques serveurs pour logger les connexions, une pratique courante appelée “sinkholing”. Et à 15h03 UTC, le domaine est actif.

Ce que Marcus ne réalise pas immédiatement, c’est qu’il vient de sauver le monde. En enregistrant ce domaine, il a activé sans le savoir le “kill switch” de WannaCry car le malware était programmé pour s’arrêter si ce domaine existait.

Pourquoi ce kill switch ? La théorie la plus probable c’est que c’était un mécanisme d’anti-analyse. Les sandboxes répondent souvent positivement à toutes les requêtes DNS pour tromper les malwares. Comme ça, si le domaine existe, WannaCry pense qu’il est dans une sandbox et s’arrête pour ne pas révéler son comportement aux chercheurs. Sauf que cette fois, c’est dans le monde réel qu’il obtient une réponse.

10,69$ - Le prix pour sauver le monde

Marcus publie immédiatement ses découvertes sur Twitter et son blog. Il écrit : “Je dois avouer que je ne savais pas qu’enregistrer le domaine stopperait le malware jusqu’à ce que je l’enregistre, donc au départ c’était accidentel.” La nouvelle se répand comme une traînée de poudre. Un inconnu vient de stopper la plus grande cyberattaque de l’histoire !

Comme d’hab, les médias s’emballent. Mais qui est ce mystérieux @MalwareTechBlog ? Les journalistes britanniques ne mettent pas longtemps à découvrir l’identité de Marcus et le Daily Mail titre : “Le surfeur qui a sauvé le monde”. Des reporters campent devant la maison de ses parents et Marcus doit escalader la clôture du jardin pour aller chercher à manger sans se faire harceler.

L’impact de la découverte de Marcus est énorme car sans le kill switch, WannaCry aurait continué à se propager pendant des jours, voire des semaines, infectant potentiellement des millions de machines supplémentaires. Les dégâts, déjà estimés à 4-8 milliards de dollars au global, auraient pu être dix fois pires. Des vies ont littéralement été sauvées.

Mais le répit est de courte durée et les créateurs de WannaCry tentent de contre-attaquer avec de nouvelles variantes utilisant des kill switches différents. Les chercheurs en sécurité jouent alors au chat et à la souris, enregistrant chaque nouveau domaine. Le 19 mai, quelqu’un tente même d’utiliser un botnet Mirai pour attaquer le domaine de Marcus en DDoS, espérant le faire tomber et réactiver WannaCry. Marcus bascule sur CloudFlare et le kill switch tient bon.

Les autorités du monde entier cherchent les coupables. Les indices pointent rapidement vers la Corée du Nord car le code de WannaCry partage des similitudes avec d’autres malwares du Lazarus Group. En décembre 2017, les États-Unis et le Royaume-Uni accusent officiellement la Corée du Nord, puis en septembre 2018, le département de la Justice américain inculpe Park Jin Hyok, un programmeur nord-coréen travaillant pour Chosun Expo, une société front du renseignement militaire.

L’aspect financier de WannaCry est particulièrement pathétique. Pour une attaque d’une telle ampleur, seulement environ 1000 victimes ont payé la rançon, pour un total de 140 000 dollars en Bitcoin. Pourquoi si peu ? Et bien le système de paiement était mal conçu… Il n’y avait pas pas de mécanisme automatique pour identifier qui avait payé. C’est con ! Et surtout, pour une fois, les gens ont écouté les experts qui déconseillaient de payer.

Marcus devient alors une célébrité malgré lui. La BBC, CNN, le Guardian, tous veulent l’interviewer et il refuse la plupart des demandes, mal à l’aise avec l’attention médiatique. Sur Twitter, ses followers explosent, la communauté de la cybersécurité le félicite, les entreprises veulent l’embaucher, mais Marcus sait que quelque part, son passé est toujours là, tapi dans l’ombre.

DEF CON 2017 - Le début de la fin pour Marcus

En juillet 2017, Marcus décide d’aller à DEF CON à Las Vegas. C’est la Mecque des hackers, l’endroit où toute la communauté se retrouve chaque année. Pour Marcus, c’est l’occasion de rencontrer en personne des gens qu’il ne connaît que par pseudos interposés, et surtout de célébrer son statut de héros de WannaCry.

La conférence se passe bien, Marcus donne des talks, participe à des panels, fait la fête avec d’autres chercheurs. Pour la première fois depuis longtemps, il se sent accepté, faire partie d’une communauté. Le 3 août 2017, dernier jour de la conférence, Marcus fait ses bagages à l’hôtel. Il prend un Uber pour l’aéroport McCarran, check-in ses bagages, passe la sécurité.

Et c’est là que tout bascule. Plusieurs agents du FBI l’entourent près de sa porte d’embarquement. “Marcus Hutchins ?” Il confirme. Ils lui montrent leurs badges, lui demandent de les suivre. Marcus sent son sang se glacer car il sait immédiatement pourquoi ils sont là : Kronos. Son passé vient de le rattraper.

Les agents l’emmènent dans une salle d’interrogatoire de l’aéroport. Ils lui lisent ses droits de garder le silence et d’avoir un avocat (ça s’appelle les droits Miranda), lui expliquent qu’il est arrêté pour conspiration en vue de commettre des fraudes informatiques. Marcus demande un avocat, refuse de parler et les agents confisquent son matériel : Laptop, téléphones, et tout son équipement de chercheur en sécurité.

L’aéroport de Las Vegas - Où notre héros devient un suspect

Marcus est alors transféré dans une prison fédérale du Nevada. Pour le gamin d’Ilfracombe qui n’avait jamais eu d’ennuis avec la justice, c’est le choc total. Il partage une cellule avec des criminels endurcis, et découvre la réalité brutale du système carcéral américain. Le héros de WannaCry est maintenant un détenu fédéral.

L’arrestation de Marcus fait l’effet d’une bombe dans la communauté de la cybersécurité. Comment le héros de WannaCry peut-il être un criminel ? Quand les détails de l’accusation sortent, à savoir la création d’UPAS Kit en 2012 et de Kronos entre 2012 et 2015, c’est la stupéfaction. Un mouvement de soutien s’organise et une cagnotte pour ses frais d’avocat récolte des centaines de milliers de dollars en quelques jours.

Après quelques jours en détention, Marcus est finalement libéré sous caution d’une valeur de 30 000 dollars et les conditions sont assez strictes : bracelet électronique GPS, interdiction de quitter le pays, couvre-feu, et limitation de l’usage d’Internet. Il s’installe à Los Angeles chez un ami, commence une longue bataille juridique qui durera presque deux ans.

La stratégie de défense de Marcus est très compliquée car les preuves contre lui sont accablantes. En effet, le FBI a des logs de conversations, des traces de paiements, des échantillons de code. Difficile de nier avoir créé Kronos. Il est donc d’abord inculpé pour six chefs d’accusation, puis voit quatre charges supplémentaires ajoutées, incluant la création d’UPAS Kit et des mensonges au FBI. Il risque jusqu’à 40 ans de prison.

Pendant près de deux ans, Marcus vit dans les limbes juridiques. Il continue à travailler pour Kryptos Logic depuis Los Angeles, publie des recherches, analyse des malwares. Mais le bracelet électronique à sa cheville lui rappelle constamment que sa liberté est provisoire. Il ne peut pas rentrer en Angleterre voir sa famille et la pression psychologique est énorme. Marcus souffre de dépression, d’anxiété et il pense parfois au suicide.

Le 2 mai 2019, Marcus prend une décision difficile : plaider coupable. Ses avocats ont négocié un deal. S’il plaide coupable pour 2 chefs d’accusation à savoir conspiration en vue de commettre des fraudes informatiques et création d’un dispositif d’interception de communications, en échange, ce sont huit autres charges qui sont abandonnées.

Dans sa déclaration au tribunal, Marcus assume pleinement ses actes. “Je regrette profondément mes actions et j’accepte l’entière responsabilité de mes erreurs”, écrit-il. Il explique comment il a créé UPAS Kit et Kronos entre 2012 et 2015, comment il a travaillé avec Vinny pour vendre le malware.

Le 26 juillet 2019, jour du jugement. La salle d’audience est pleine. Marcus, en costume, fait face au juge J.P. Stadtmueller. Les procureurs demandent une peine de prison. La défense plaide la clémence, rappelant que Marcus a arrêté de lui-même ses activités criminelles, et qu’il a littéralement sauvé le monde de WannaCry.

Le jour du jugement - 26 juillet 2019

Puis vient le moment où le juge Stadtmueller prend la parole. Et là, surprise. Le juge reconnaît la gravité des crimes de Marcus, mais aussi l’importance de ses contributions positives. “Il faudra des gens avec vos compétences pour trouver des solutions”, dit-il à Marcus, “parce que c’est la seule façon d’éliminer ce problème des protocoles de sécurité terriblement inadéquats.”

Le verdict tombe : time served (peine purgée) et un an de liberté surveillée. Pas de prison supplémentaire. Marcus n’en croit pas ses oreilles. La salle d’audience explose en applaudissements. Pour la première fois depuis son arrestation, il peut enfin respirer. Le juge ajoute que Marcus devra probablement retourner au Royaume-Uni et qu’il n’est pas certain qu’il puisse revenir aux États-Unis.

En juillet 2020, sa liberté surveillée prend fin. Marcus retourne enfin au Royaume-Uni, retrouve sa famille à Ilfracombe après trois ans d’absence forcée. C’est un retour doux-amer. Il est libre, mais sa vie a été bouleversée. Il a perdu trois ans, sa santé mentale est fragile, son futur incertain. Il ne peut plus voyager aux États-Unis, limitant ses opportunités professionnelles.

Juillet 2020 - Le retour au pays après trois ans d’exil forcé

Mais Marcus est résilient. Il relance son blog MalwareTech.com, reprend ses analyses de malware, publie des recherches de pointe. Il devient consultant en cybersécurité, travaille avec des entreprises pour améliorer leur sécurité. Doucement, il reconstruit sa vie et sa carrière.

Aujourd’hui, en 2025, Marcus Hutchins est devenu une figure respectée de la cybersécurité mondiale. Il travaille toujours pour Kryptos Logic, publie régulièrement des analyses techniques pointues. Ses recherches sur les vulnérabilités Windows, les techniques de contournement d’EDR, et les malwares sophistiqués sont lues par des milliers de professionnels.

Le site de Marcus

Dans ses écrits récents, Marcus réfléchit souvent sur son parcours. “Si je pouvais revenir en arrière, je ferais les choses différemment”, écrit-il. “Mais je ne peux pas changer le passé. Tout ce que je peux faire, c’est utiliser mes compétences pour le bien, aider à protéger les gens contre les menaces que j’ai aidé à créer.”

L’impact de WannaCry a montré notre vulnérabilité collective à savoir des infrastructures critiques tournant sur des systèmes obsolètes, des entreprises qui ne patchent pas, et une dépendance totale à des systèmes informatiques sans plan B. Cependant, il faut noter que Microsoft a réagi de manière remarquable puisque le lendemain de l’attaque, ils ont fait quelque chose d’inédit : publier des patchs gratuits pour Windows XP, Windows 8 et Windows Server 2003, des systèmes “end-of-life” depuis des années.

Et WannaCry n’était que le début car un mois plus tard, NotPetya frappe, utilisant aussi EternalBlue mais causant encore plus de dégâts. Aujourd’hui, en 2025, EternalBlue est toujours actif et 8 ans après, des millions de machines restent vulnérables. C’est déprimant mais c’est la réalité…

Voilà l’histoire complète de Marcus Hutchins… Une histoire de chute et de rédemption qui montre que dans la vie, rien n’est jamais simple, rien n’est jamais définitif.

Sources : Marcus Hutchins - Wikipedia, WannaCry ransomware attack - Wikipedia, DOJ - Marcus Hutchins Pleads Guilty, Krebs on Security - Marcus Hutchins Pleads Guilty, MalwareTech Blog, WannaCry cost NHS £92m, NAO - WannaCry cyber attack and the NHS, How to Accidentally Stop a Global Cyber Attack, CyberScoop - Marcus Hutchins Sentenced, Cloudflare - WannaCry Ransomware

Ce serait quand même sympa de pouvoir entraîner une IA qui non seulement vous comprend parfaitement, mais qui peut littéralement penser et répondre comme vous le feriez, non ?

Comment ça nooon ??

Bah, tant pis pour vous parce que c’est exactement ce que propose Second Me, un projet open source qui est capable d’imiter votre pensée.

Le concept est assez cool car plutôt que de confier vos données personnelles à une grosse boîte tech comme OpenAI ou Google, vous entraînez votre propre “double numérique” directement sur votre machine. Le truc reste chez vous, sur votre ordi, avec vos données, mais peut quand même se connecter à un réseau décentralisé pour interagir avec d’autres IA ou des applications quand vous le souhaitez.

La technologie derrière Second Me repose sur ce qu’ils appellent l’AI-native Memory, avec notamment un système de Hierarchical Memory Modeling (HMM) et leur fameux algorithme Me-Alignment, comme détaillé dans leur doc GitHub. En gros, ça permet à votre clone IA d’apprendre progressivement vos habitudes d’écriture, votre façon de coder, vos expressions favorites, et même vos petites manies linguistiques. L’idée c’est vraiment de créer une extension de vous-même dans le monde numérique.

Pour faire tourner tout ça, vous avez quand même besoin d’un peu de matos. Par exemple, avec 8 Go de RAM, vous pouvez faire tourner un modèle d’environ 0.8 milliard de paramètres sous Docker , selon les spécifications indiquées dans le README du projet. Si vous avez 32 Go, vous montez à 2.8B de paramètres. Les utilisateurs Mac avec puce Silicon peuvent utiliser MLX pour faire tourner des modèles plus gros.

Pour l’utiliser, d’abord vous clonez le repo GitHub, puis vous lancez les conteneurs Docker avec un simple make docker-up, et hop, vous accédez à l’interface web sur localhost:3000.

# 1. Clonez le repo
git clone https://github.com/mindverse/Second-Me.git
cd Second-Me
# 2. Démarrez le conteneur Docker
make docker-up
# 3. Et roule ma poule !
# Ouvrez le navigateur et allez sur : http://localhost:3000

Ce qui est vraiment intéressant avec Second Me, c’est surtout la philosophie derrière car plutôt que de créer une “Super IA” centralisée qui menace votre indépendance et vos données, ils veulent donner à chacun la possibilité de créer sa propre IA capable d’amplifier notre individualité au lieu de l’effacer. Votre Second Me peut même jouer différents rôles selon les scénarios. Par exemple répondre à vos emails pendant que vous dormez, participer à des réunions Zoom à votre place, ou collaborer avec d’autres Second Me pour brainstormer sur des projets.

D’ailleurs, ils ne sont pas les seuls à explorer cette voie des IA personnelles. Par exemple, PIN AI vient de lancer une app mobile qui permet de faire tourner des modèles open source comme DeepSeek ou Llama directement sur votre smartphone. Au MWC 2025, Newnal a même présenté un téléphone IA capable de créer un clone numérique complet avec vos données médicales et financières, qui peut même souscrire une assurance auto à votre place (c’est un peu flippant quand même ^^).

Le projet Second Me utilise des briques open source solides comme GraphRAG de Microsoft pour la synthèse de données, llama.cpp pour l’inférence, et les modèles de base viennent principalement de la série Qwen2.5. Tout ça sous licence Apache 2.0, donc vraiment libre d’utilisation. L’équipe travaille même sur un système de versioning pour les états de mémoire et d’identité, des pipelines d’entraînement continus, et même des solutions cloud pour ceux qui n’ont pas la puissance de calcul nécessaire en local.

Pour ceux qui veulent tester, il y a déjà quelques démos sympas comme Felix AMA (une app de roleplay), ou des outils de brainstorming où plusieurs Second Me collaborent ensemble. La communauté est super active sur Discord et Reddit, et le projet cartonne sur GitHub avec des contributeurs du monde entier.

Maintenant, avec des modèles en dessous de 0.5B de paramètres, vous n’aurez pas des performances extraordinaires pour des tâches complexes, mais l’idée est là, à savoir reprendre le contrôle sur notre identité numérique et nos données, tout en profitant de la puissance de l’IA. Cool non ?

Merci à Letsar pour la découverte !

Source

Vous êtes tranquillement garé au supermarché, et pendant que vous faites vos courses, quelqu’un avec un Flipper Zero capture discrètement le signal de votre clé de bagnole. Dans certains cas extrêmes, votre clé pourrait effectivement devenir inutile, mais la plupart du temps, c’est plus subtil et presque plus inquiétant puisque l’attaquant pourrait revenir ouvrir votre voiture plus tard, tandis que votre clé continue de fonctionner tout à fait normalement.

Cette nuance, personne ne la fait et pourtant elle change tout dans la compréhension de cette faille.

L’histoire commence donc avec un firmware mystérieux qui circule dans les cercles underground du Flipper Zero. Vendu jusqu’à 1000 dollars, ce firmware exploite une vulnérabilité découverte par des chercheurs et la transforme en arme redoutablement efficace. Les youtubeurs Talking Sasquatch et 0dayCTF ont publié des démonstrations qui ont fait l’effet d’une bombe dans la communauté et c’est d’ailleurs comme ça que je l’ai découvert.

Mais revenons aux bases. Les codes tournants (rolling codes), c’est une technologie censée protéger nos voitures depuis les années 90. À chaque pression sur votre télécommande, un nouveau code unique est généré. Impossible à copier, disaient-ils. Jusqu’à ce que des chercheurs trouvent LA faille.

En 2015, on a donc vu débouler RollJam, une attaque complexe qui nécessitait de brouiller le signal tout en l’enregistrant. Techniquement possible, mais franchement galère sur le terrain. Puis en 2022, tout a changé avec l’attaque RollBack présentée à la Black Hat. Cette fois, plus besoin de brouillage. Il suffit de capturer quelques signaux (parfois deux, parfois cinq selon les modèles) et de les rejouer dans le bon ordre pour “rembobiner” l’état du récepteur.

Le plus sournois, c’est que dans la majorité des cas documentés par la recherche, votre télécommande continue de fonctionner. L’attaquant exploite en effet le mécanisme de resynchronisation pour ramener le système à un état antérieur où des codes déjà utilisés redeviennent valides. C’est ce qu’on appelle une attaque “time-agnostic” cqr elle peut être réutilisée n’importe quand après la capture initiale.

Attention toutefois aux généralisations car contrairement à ce qu’on lit partout, une seule capture ne suffit pas toujours. La CVE-2022-37305 publiée pour certains modèles Honda documente par exemple la nécessité de capturer cinq signaux consécutifs. Les détails varient énormément selon les marques, modèles, années et puces utilisées.

Parlons maintenant des véhicules concernés. SAN cite une liste incluant Chrysler, Dodge, Fiat, Ford, Hyundai, Jeep, Kia, Mitsubishi et Subaru. Mais attention, ce n’est pas une liste officielle. Les chercheurs derrière RollBack indiquent qu’environ 70% des modèles asiatiques testés présentaient une vulnérabilité, tandis que certains systèmes (notamment plusieurs Toyota avec des transpondeurs Texas Instruments) se sont montrés plutôt résistants.

Il existe quand même des cas où la clé devient réellement inutile, mais c’est l’exception plutôt que la règle. Un chercheur indépendant a documenté comment certains modèles Subaru 2004-2011 pouvaient voir leur compteur poussé si loin que la clé originale se désynchronisait définitivement. Mais c’est un cas particulier d’implémentation mal conçue, et pas la norme.

L’histoire derrière ce firmware est également fascinante je trouve car elle implique un développeur controversé (surnommé “Mr. Silly Pants” par la communauté), créateur original du firmware Unleashed, qui après un séjour en prison a voulu récupérer son projet que MMX avait fait grandir en son absence. Face à son refus, il a alors créé son propre firmware avec ces fameuses fonctionnalités de rolling code et tenté de le monétiser. C’est là qu’interviennent Rocket God et les Pirates Plunder Crew qui ont réussi à cracker la protection par numéro de série mise en place sur le firmware et commencé à faire circuler le code dans des cercles restreints de hackers et chercheurs en sécurité.

Alors, comment fonctionne cette attaque ?

Déjà, il faut savoir que les systèmes RKE (Remote Keyless Entry) utilisent un compteur couplé à une clé secrète. Le récepteur tolère ainsi une “fenêtre” de resynchronisation, soit environ 16 codes pour l’exécution immédiate et jusqu’à 32 000 pour la resynchronisation en double opération selon les datasheets HCS320 et HCS500. C’est fait pour rattraper les appuis manqués quand vous êtes trop loin de la voiture.

RollBack exploite intelligemment ce mécanisme en rejouant des trames valides dans le bon ordre pour forcer une resynchronisation vers un état antérieur. Dans certains cas avec les anciens systèmes KeeLoq, si la clé constructeur a fuité (ce qui est d’ailleurs arrivé via des attaques documentées dès 2008 par Biham et al. et Courtois/Kasper), alors oui, une seule capture peut suffire pour dériver les prochaines trames.

Ce fameux firmware de Mr. Silly Pant, reste entouré de mystère. Code non publié, méthodologie non documentée, résultats non reproductibles publiquement. Les vidéos montrent un Flipper qui écoute une ou plusieurs trames et émule ensuite toutes les fonctions de la télécommande. C’est impressionnant, mais la littérature scientifique sur RollBack reste pour l’instant la meilleure base technique vérifiable.

Alors, comment se protéger ?

Vos options restent limitées. On peut utiliser le verrouillage interne du véhicule quand possible, éviter les appuis multiples loin de la voiture, ranger sa clé dans une pochette qui bloque les ondes (ça limite les captures opportunistes), et surtout désactiver le Keyless “mains libres” si votre modèle le permet (même si c’est surtout efficace contre les attaques de relais, pas forcément contre RollBack).

La vraie solution nécessiterait en fait des mises à jour de l’ECU et de la clé (irréalistes à grande échelle) ou une refonte complète avec des protocoles modernes basés sur des timestamps ou de l’authentification multifacteur. Les constructeurs sont donc dans une impasse car un rappel massif serait économiquement catastrophique, et ces systèmes hardware ne peuvent pas être patchés comme un logiciel.

Maintenant pour les passionnés qui veulent explorer le Flipper Zero légalement, trois firmwares customs publics dominent : Unleashed qui reste la référence stable, Momentum qui a repris le flambeau d’Xtreme avec des fonctionnalités plutôt riches, et RogueMaster qui offre le plus d’options mais avec une stabilité qui se discute…. Le comparatif Awesome Flipper vous détaillera toutes leurs différences.

Cette affaire révèle surtout les tensions croissantes dans la communauté Flipper Zero, entre la recherche éthique et la monétisation agressive. Elle rappelle surtout que comme d’habitude, la sécurité par l’obscurité a ses limites. Ces codes tournants semblaient invulnérables jusqu’à ce qu’on trouve comment exploiter leur mécanisme de resynchronisation.

Le Flipper Zero n’est d’ailleurs pas le seul coupable. D’autres dispositifs SDR peuvent théoriquement réaliser la même attaque mais le Flipper a démocratisé ces techniques, les rendant accessibles à tous. Heureusement, de nouveaux systèmes de sécurité émergeront bientôt, j’en suis sûr, probablement basés sur des protocoles plus robustes mais comme vous le savez chaque protection finit par tomber. C’est juste une question de temps, de motivation et d’ingéniosité.

Maintenant, si vous croisez quelqu’un qui traine avec un Flipper Zero dans un parking, pas de panique et inutile de lui casser la gueule, car la majorité de la communauté reste éthique. Donc peu de chance que ce soit un voleur de voiture. Mais restez quand même vigilant, on ne sait jamais…

Source

Pendant que vous lisez cet article, Jules pourrait être en train de corriger les bugs présent dans votre code. Non, c’est pas une blague, c’est le nouveau délire de Google qui vient de sortir de beta. Jules, c’est un agent IA qui code vraiment tout seul, et franchement, après l’avoir testé, je commence à me demander si le métier de dev a encore un avenir.

Vous créez une issue GitHub avec le label “jules”, vous partez boire un café (ou vous taper une petite sieste), et quand vous revenez, hop, une pull request toute propre vous attend. Tests écrits, dépendances mises à jour, et bugs corrigés. Jules a tout fait pendant que vous vous tourniez les pouces.

Ce qui rend Jules différent de Copilot et consorts c’est qu’il ne se contente pas de compléter votre code ou de suggérer des snippets. Non, non. C’est un véritable agent autonome qui clone votre repo dans une VM Google Cloud sécurisée et se met au boulot tout seul. Sous le capot c’est Gemini 2.5 Pro, donc il comprend le contexte global de votre projet et peut enchaîner plusieurs tâches complexes.

L’intégration GitHub est particulièrement soignée. Jules peut créer ses propres branches, ouvrir des pull requests avec des commits propres et même générer des changelogs audio. C’est fou ça, des changelogs audio. Faut croire que lire en 2025 c’est has been…

Pour l’utiliser, c’est simple comme bonjour. Vous vous connectez sur jules.google.com (avec votre compte Google, évidemment), vous liez votre GitHub, et c’est parti. Le bouton “Give a plan” lance le processus de réflexion de Jules qui vous soumettra alors son grand projet pour vous. Et si ça vous convient, vous validez et il se met au travail.

Comme Jules fonctionne de manière totalement asynchrone, vous pourriez être en train de jouer à Baldur’s Gate 3 qu’il continuerait tranquillement de refactoriser votre code tout pourri.

Les fonctionnalités qui tuent c’est d’abord, les mises à niveau de version. Terminées les heures passées à vérifier la compatibilité et à ajuster le code pour la dernière version d’une lib. Jules s’en charge. L’écriture de tests, cette tâche aussi cruciale que chiante, Jules la fait. Et en plus, il le fait bien, le bougre.

Niveau langages supportés, c’est du lourd : Node.js, Python, Go, Java et Rust. Par contre, pas de PHP pour l’instant. Désolé les warriors du web de 2005. Google promet d’autres langages bientôt, mais on connaît leurs promesses…

Bon, parlons fric maintenant. Google a sorti trois forfaits. Y’a le plan gratuit qui vous donne 15 tâches par jour et 3 simultanées. C’est déjà pas mal pour tester. Le Pro multiplie les limites par 5, et l’Ultra par 20 pour les gros projets avec du multi-agent.

Un truc important sur la privacy, c’est que si votre repo est public, Google peut utiliser vos données pour entraîner l’IA. Et si c’est privé, rien n’est envoyé. En tout cas, c’est ce qu’ils disent.

Google est tellement confiant qu’ils vont l’utiliser sur leurs propres projets.

Alors est-ce que Jules va remplacer les développeurs ? Non, je crois pas, mais il va clairement changer notre façon de travailler car au lieu de passer des heures sur des tâches répétitives, on pourra se concentrer sur l’architecture, la créativité, les vrais problèmes complexes. Et lui s’occupera du sale boulot.

Par contre, si vous êtes le genre de dev qui se contente de copier-coller du Stack Overflow, là oui, commencez à chercher une reconversion. Car Jules fait ça mieux, plus vite, et il ne se plaint jamais du montant de ses tickets resto.

Merci à Lorenper pour la découverte !

Un million de dollars ! C’est ce que les pirates de l’opération GreedyBear ont déjà siphonné dans des plugins Firefox de portefeuilles crypto. Et pour cela, ils ont utilisé 150 extensions malveillantes, créant ainsi la plus grosse vague d’attaque jamais vue sur le store d’add-ons de Mozilla. C’est Koi Security qui vient de révéler l’ampleur du carnage, et franchement, c’est du jamais vu.

Vous installez tranquillement ce qui ressemble à MetaMask sur Firefox. L’icône est identique, le nom est presque pareil, et le truc a même 500 reviews et 5 étoiles. Sauf que voilà, l’extension n’a que 200 installations actives. Les calculs sont pas bons, Kévin !!

Mais bon, qui vérifie ce genre de détails quand on est pressé d’acheter du Dogecoin parce que tonton Elon a dit que c’était trop bien ?

Les pirates ont commencé leur petit manège en avril de cette année, et il y aurait encore une 40aine d’extensions frauduleuses qui circulent. Ils clonent le code open source de vrais wallets, injectent leur saloperie de keylogger dedans, et hop, c’est parti pour la récolte. MetaMask, TronLink, Rabby, Trust Wallet, Coinbase, Phantom, Exodus… Toutes les grosses pointures y sont passées.

Pour bien comprendre comment ça a pu passer dans la toile de la modération du store, il faut savoir que ces extensions commencent leur vie innocemment. Les pirates uploadent d’abord des versions totalement clean, attendent qu’elles passent la validation, puis balancent une mise à jour avec le code malveillant. C’est ce qu’on appelle du bait and switch de compétition. Et une fois installées, ces petites merveilles enregistrent tout ce que vous tapez sur les sites de crypto et envoient vos identifiants sur des serveurs louches.

Yuval Ronen de Koi Security explique que cette attaque est peu coûteuse à déployer, maintient une apparence crédible et réduit le risque de détection immédiate.

Les chercheurs soupçonnent même que de l’IA aide les attaquants à créer des schémas à grande échelle et à se remettre en selle rapidement après des suppressions totales. En gros, quand Mozilla supprime leurs extensions, ils en recréent 10 nouvelles en deux minutes grâce à ChatGPT, Claude ou leurs copains.

Les extensions utilisent des noms comme “trust-extension-wallet”, “okx-wallet-extension1” ou mon préféré à moi : “official-metamask-wallet”. Celui là c’est l’officiel non-officiel, un classique ! Ces extensions gonflent ensuite artificiellement leur popularité avec des centaines de fausses reviews qui dépassent largement le nombre réel d’installations.

Mozilla a évidemment réagi en supprimant une bonne partie des extensions identifiées, et développe depuis peu un nouveau système de détection automatique. L’équipe Add-ons Operations de Mozilla dit traquer ce genre de menaces depuis des années, mais visiblement, les pirates ont toujours un coup d’avance.

En plus, le bilan est assez salé avec 1,7 milliard de dollars perdus dans ces wallets rien qu’au premier semestre. Et ça, c’est juste sur 34 pauvres attaques documentées. GreedyBear et ses 150 extensions contribuent donc généreusement à ces statistiques déprimantes.

Pour éviter de vous faire plumer, mon conseil est simple mais vital : téléchargez vos extensions de wallet UNIQUEMENT depuis les sites officiels des projets. Pas depuis le store Firefox, pas depuis un lien dans un email, pas depuis une pub sur un site de streaming chelou. Direct depuis le site officiel et c’est tout.

Et vérifiez les reviews. Si une extension a 500 reviews, 5 étoiles mais seulement 100 installations, fuyez. Si le nom contient “official” mais que ce n’est pas le compte vérifié du projet, fuyez. Si l’extension vous demande votre seed phrase juste après l’installation, fuyez (et changez tous vos mots de passe tant qu’à faire).

J’adore les extensions mais le problème c’est qu’elles ont accès à tout ce que vous faites en ligne. Elles peuvent voir vos mots de passe, lire vos emails, accéder à vos comptes bancaires. Et surtout elles peuvent changer de comportement après installation… sans que vous le sachiez.

Mozilla promet de renforcer ses contrôles, mais en attendant, la vigilance reste votre meilleure défense, parce qu’avec 1 million de dollars déjà volés d’après Koi Security, les pirates de GreedyBear ne vont pas s’arrêter de sitôt. Surtout qu’avec l’IA de leur côté, ils peuvent créer des clones d’extensions plus vite que Mozilla ne peut les supprimer.

Source

Putain mais c’est pas possible ! Encore une cyberattaque massive dans les télécoms français. Cette fois c’est Bouygues Telecom qui s’est fait défoncer avec 6,4 millions de comptes clients compromis selon France Info. Et le pire dans tout ça c’est que les attaquant ont même choppé les IBAN. Oui, vos coordonnées bancaires sont dans la nature. Woohoo \o/ !

L’attaque a été détectée le 4 août 2025, soit il y a trois jours seulement. Bouygues annonce fièrement que “la situation a été résolue dans les meilleurs délais” par leurs équipes techniques.

Alors qu’est-ce qui a fuité exactement ?

Et bien accrochez-vous bien, je vous fais la liste : toutes les informations de contact, les données contractuelles, l’état civil, les données d’entreprise pour les pros, et surtout, surtout… vos IBAN. Par contre, les numéros de carte bancaire et les mots de passe ne sont pas concernés. Ouf, on a eu chaud !

Mais attendez, le meilleur c’est que la page web dédiée à informer les victimes contenait une balise “noindex” cachée. Pour ceux qui ne connaissent pas, ça veut dire que Google ne peut pas indexer la page. En gros, si vous cherchez des infos sur la cyberattaque Bouygues sur Google, vous ne trouverez pas leur page officielle. C’est surement pour pas flinguer leur branding !

Le vrai danger maintenant, c’est qu’avec votre IBAN, un pirate motivé peut potentiellement mettre en place des prélèvements SEPA frauduleux. En usurpant votre identité et avec toutes les infos volées, il peut créer de faux mandats de prélèvement. Bouygues admet d’ailleurs ne pas exclure qu’un fraudeur parvienne à réaliser une telle opération en usurpant votre identité. Tu m’étonnes John.

Ce qui me fait vraiment halluciner, c’est qu’il y a 26,9 millions de clients mobile chez Bouygues Telecom. Ça veut dire qu’un client sur quatre s’est fait avoir. UN SUR QUATRE ! C’est pas une petite fuite de données, c’est un tsunami.

Bouygues a déposé plainte auprès des autorités judiciaires et signalé l’incident à la CNIL. Bon bah super, fallait le faire, mais ça va pas vraiment aider les 6,4 millions de clients qui vont devoir surveiller leur compte bancaire pendant les 10 prochaines années.

Pour “rassurer” les clients, un numéro gratuit a été mis en place : 0801 239 901. Ils ont aussi créé une page web dédiée (celle avec le noindex, vous vous souvenez ?) et une section spéciale sur Le Mag. Tous les clients concernés vont recevoir un email ou un SMS. Spoiler : si vous êtes client Bouygues, vous allez probablement le recevoir.

Le timing est particulièrement bon quand on sait qu’Orange aussi s’est aussi fait pirater récemment. Les télécoms français sont vraiment en mode open bar pour les hackers en ce moment. C’est la fête du slip niveau sécurité.

Mes conseils donc si vous êtes client Bouygues :

1. Surveillez vos comptes bancaires comme le lait sur le feu
2. Méfiez-vous de TOUS les emails et appels qui vous demandent des infos
3. Changez vos mots de passe partout (même s’ils disent qu’ils n’ont pas été touchés)
4. Activez l’authentification à deux facteurs partout où c’est possible
5. Et surtout, préparez-vous à recevoir du phishing de compétition pendant les prochains mois (années ?)

Avec vos vraies infos perso, les arnaqueurs vont pouvoir créer des emails et SMS ultra crédibles. Ils connaissent votre numéro de contrat, votre adresse, votre IBAN… Ils peuvent se faire passer pour Bouygues, votre banque, ou n’importe quelle administration. C’est le jackpot pour eux.

Cette histoire une fois de plus me met vraiment en rogne. On confie nos données les plus sensibles à ces entreprises, et elles sont incapables de les protéger correctement. Je sais pas vous, mais moi j’en ai marre de ces leaks à répétition. À quand une vraie responsabilisation de ces entreprises ? Des amendes qui font vraiment mal ? Parce que là, on est juste des pigeons qui attendent de se faire plumer.

Source

Ceci est une histoire qui a fait trembler la première puissance militaire du monde. On est en février 1998 et les États-Unis sont à deux doigts de bombarder l’Irak de Saddam Hussein qui vient de virer les inspecteurs de l’ONU. La tension est électrique. Les Marines déploient leurs troupes dans le Golfe. Et là, sans prévenir, le Pentagone se fait hacker comme jamais.

Et pas juste un petit piratage de rien du tout, hein, car plus de 500 systèmes militaires et gouvernementaux compromis en trois semaines : NASA, Air Force, Navy, MIT, Lawrence Livermore (le labo qui conçoit les bombes atomiques américaines), et j’en passe. John Hamre, le numéro 2 de la Défense américaine, déclare alors que c’est “l’attaque la plus organisée et systématique que le Pentagone ait jamais vue”. La panique est totale !

Du coup, NSA, CIA, FBI, Defense Information Systems Agency, Air Force Office of Special Investigations, ministère de la Justice… Tout le gratin du renseignement américain se mobilise. Les briefings remontent jusqu’au bureau ovale, jusqu’à Bill Clinton himself. Et leur conclusion, c’est que c’est forcément Saddam qui lance la cyberguerre pour paralyser l’armée américaine avant les frappes… Non ?

L’histoire commence donc le 1er février 1998. Un dimanche soir tranquille au Pentagone. Sauf que dans les sous-sols du bâtiment, les systèmes ASIM (Automated Security Incident Monitors) de l’Air Force commencent à gueuler. Quelqu’un vient de s’introduire dans les serveurs de la Garde nationale aérienne à Andrews Air Force Base, dans le Maryland. Et pas n’importe comment puisque l’intrus a chopé les droits root, soit le Saint Graal absolu pour un hacker.

Le lendemain, 2 février, c’est la grosse panique. L’équipe de réponse aux urgences informatiques de l’Air Force (AFCERT) à Kelly Air Force Base au Texas découvre que ce n’est pas un incident isolé. D’autres bases militaires se font défoncer… Kirtland au Nouveau-Mexique, Lackland au Texas, Columbus dans le Mississippi, Gunter dans l’Alabama. L’attaque se propage comme une traînée de poudre.

Les experts du Pentagone analysent alors rapidement le mode opératoire et là, premère surprise, les hackers exploitent une vulnérabilité vieille comme le monde dans Solaris 2.4, le système d’exploitation Unix de Sun Microsystems. La faille “statd”, connue depuis 1996 (!), offre un joli buffer overflow dans le service RPC. En gros, vous envoyez un nom de fichier trop long bourré de shellcode, et pouf, ça permet d’exécuter du code arbitraire avec les privilèges root.

D’où le nom de code donné à l’incident : “Solar Sunrise” (Lever de Soleil Solaire). Un jeu de mots pourri entre Sun/Solaris et le fait que ça se passe au lever du jour. Les militaires et leur sens de l’humour…

Et une fois dans la place, les attaquants installent des analyseurs de paquets et des chevaux de Troie pour maintenir leur accès. Ils capturent ainsi tous les mots de passe qui transitent sur le réseau avec leurs sniffers. C’est méthodique, efficace, imparable et les serveurs DNS tombent comme des dominos.

Mais ce qui terrifie vraiment les stratèges du Pentagone, c’est le timing car on est en pleine crise diplomatique avec l’Irak. Les inspecteurs de l’ONU viennent d’être expulsés. Les porte-avions américains convergent vers le Golfe Persique. Et maintenant, les systèmes militaires se font pirater systématiquement. Pour les analystes, c’est évident : Saddam Hussein lance une cyberguerre pour aveugler l’armée américaine.

Richard Clarke, le coordinateur national pour la sécurité et le contre-terrorisme à la Maison Blanche, avouera plus tard que “Pendant des jours, des jours critiques alors que nous essayions d’envoyer des forces dans le Golfe, nous ne savions pas qui faisait ça. Nous avons donc supposé que c’était l’Irak.”

Le 3 février, l’affaire remonte jusqu’au bureau ovale. Le président Bill Clinton est briefé personnellement sur cette cyberattaque sans précédent. La situation est grave. Certes, les hackers n’ont pas touché aux systèmes classifiés (ouf), mais ils ont accès aux systèmes de logistique, d’administration et de comptabilité. Ce sont les nerfs et les muscles de l’armée américaine et sans eux, impossible de déployer des troupes ou de coordonner les opérations.

John Hamre prend alors personnellement les choses en main. Diplômé de Harvard, ancien analyste au Congressional Budget Office, Hamre n’est pas du genre à paniquer pour un rien. Mais là, il est vraiment inquiet. “C’est l’attaque la plus organisée et systématique que nous ayons jamais vue”, répète-t-il lors des briefings tendus au Pentagone.

L’enquête mobilise des moyens colossaux. Des mandats judiciaires sont obtenus en urgence pour tracer les connexions des pirates, mais les attaquants sont malins : ils rebondissent sur des serveurs dans le monde entier pour brouiller les pistes. Les enquêteurs identifient des connexions passant par les Émirats arabes unis, via un FAI appelé Emirnet alors pour les analystes paranos, c’est un indice de plus qui pointe vers le Moyen-Orient.

Et le 11 février, première percée. Les agents du FBI interceptent des communications entre les pirates sur IRC (Internet Relay Chat). C’est l’ancêtre de Discord pour les plus jeunes d’entre vous. Les pseudos utilisés sont “Makaveli”, “Stimpy”, et un certain “Analyzer” qui semble être le chef de bande. Les conversations sont édifiantes. Ils parlent de leurs exploits comme des gamers qui viennent de finir un niveau difficile.

Et grâce aux logs IRC mais aussi à un informateur (d’après les rumeurs, c’est probablement John Vranesevich d’AntiOnline, mais chut…), les enquêteurs remontent jusqu’à deux lycéens de Cloverdale, une petite ville paumée du nord de la Californie, à 140 kilomètres au nord de San Francisco. Population : 8 000 habitants. Nombre de hackers internationaux recherchés par le Pentagone : 2.

Seulement voilà, John Hamre fait une bourde monumentale. Lors d’un briefing avec des journalistes, il laisse échapper que les suspects sont “des gamins vivant dans le nord de la Californie”. L’info fuite immédiatement sur CNN. Du coup, les enquêteurs doivent accélérer avant que les hackers voient les infos et effacent toutes les preuves.

Et le 25 février 1998, à 6 heures du matin, le FBI débarque simultanément à deux adresses de Cloverdale. Première maison : le lycéen de 16 ans qui se fait appeler Makaveli. Deuxième maison : son pote de 15 ans, alias Stimpy. Les agents saisissent tout… ordinateurs, modems, piles de CD-ROM, carnets de notes remplis de mots de passe…

Les parents tombent des nues. Leur fils, un cyber-terroriste international ? Impossible ! Makaveli est juste un lycéen un peu geek, qui passe trop de temps sur son PC au lieu de faire ses devoirs. Stimpy, c’est pareil, un gamin passionné d’informatique qui étudie aussi la musique.

Mais pendant l’interrogatoire, Makaveli craque rapidement. Les agents s’attendent à des révélations sur un complot international, des liens avec des services secrets étrangers, ou que sais-je mais au lieu de ça, quand ils lui demandent pourquoi il a hacké le Pentagone, il répond : “It’s power, dude. You know, power.”

Les enquêteurs se regardent, interloqués. Trois semaines de mobilisation générale, des briefings présidentiels, la quasi-guerre avec l’Irak… pour un ado qui voulait se la péter ? Makaveli ajoute qu’il a un mentor à l’étranger qui lui a “tout appris”, un type “tellement bon qu’ils ne le trouveront jamais” et qui aurait piraté 400 sites militaires.

Les écoutes révèlent alors l’identité du troisième larron : “The Analyzer”, de son vrai nom Ehud Tenenbaum, 18 ans, Israélien. Né le 29 août 1979 à Hod HaSharon près de Tel Aviv, c’est lui le cerveau du groupe de hackers “The Enforcers” (Les Exécuteurs).

Et là, Tenenbaum fait un truc complètement dingue. Deux jours après l’arrestation de ses disciples américains, au lieu de se planquer ou de détruire les preuves, il accepte une interview en ligne avec AntiOnline. Genre, tranquille. Et il balance tout… les 400 sites piratés, les mots de passe, les vulnérabilités tout en se justifiant : “J’aide toujours les serveurs que je pirate. Je patche les trous que je trouve.” Robin des Bois 2.0, en somme.

L’interview fait l’effet d’une bombe. Non seulement ce gamin nargue ouvertement le gouvernement américain, mais en plus il prouve ses dires en publiant des dizaines de logins et mots de passe authentiques de sites en .mil. Le Pentagone est ridiculisé publiquement par un ado de 18 ans.

Les Américains mettent alors la pression sur Israël et le 18 mars 1998, la police israélienne arrête Ehud Tenenbaum dans sa maison. Brillant, persuadé de rendre service en exposant les failles, il correspond parfaitement au profil du hacker prodige mais arrogant. Deux autres membres de son groupe sont également interpellés, mais Tenenbaum est clairement le boss.

Janet Reno, la procureure générale des États-Unis, tente de sauver la face : “Cette arrestation devrait envoyer un message à tous les hackers potentiels dans le monde.” Mouais. Dans les couloirs du Pentagone, c’est plutôt la gueule de bois. Comment trois ados ont-ils pu mettre en échec tout l’appareil de cyberdéfense américain ?

Le procès est une blague. Les deux Californiens, mineurs au moment des faits, plaident coupables de délinquance juvénile. Pas de prison, juste de la probation et l’interdiction de toucher un ordi. La liste trouvée chez Makaveli contenait près de 200 serveurs piratés, dont le Lawrence Livermore National Laboratory. C’est “juste” le labo qui fabrique les armes nucléaires. Mais bon, “curiosité adolescente”, qu’ils disent.

Pour Tenenbaum, le procès traîne durant trois ans. En juin 2001, il écope de… six mois de travaux d’intérêt général, un an de probation, deux ans de sursis, et 18 000 dollars d’amende. Pour avoir ridiculisé la cyberdéfense américaine, ça passe ^^. À la sortie du tribunal, il déclarera : “Je voulais juste prouver que leurs systèmes étaient troués comme du gruyère.” Mission accomplie, effectivement.

Mais attendez, l’histoire ne s’arrête pas là car en 2003, libéré de ses obligations judiciaires, Tenenbaum fonde sa propre boîte de sécurité informatique baptisée “2XS”. L’ancien pirate devient consultant. C’est un classique, sauf qu’il n’a pas vraiment retenu la leçon…

Septembre 2008, rebelote. La police canadienne l’arrête à Montréal avec trois complices. Cette fois, c’est du lourd : piratage de banques, vol de données de cartes bancaires, détournement de 1,8 million de dollars via des distributeurs automatiques. En fait, depuis son appart montréalais, il augmentait les limites des cartes prépayées pour vider les DAB. Au total, les pertes s’élèvent à plus de 10 millions de dollars.

Extradé aux États-Unis, Tenenbaum passe alors plus d’un an en détention. En 2012, il plaide coupable et s’en tire avec le temps déjà passé en prison. Depuis, plus personne n’entend parler de lui. The Analyzer a enfin compris que “le pouvoir, mec” avait ses limites.

Mais revenons à l’impact de Solar Sunrise. Pour la première fois, le Pentagone réalise l’ampleur de sa vulnérabilité. Les patchs de sécurité pour la faille statd existaient depuis des mois, mais personne ne les avait installés. Procrastination, manque de personnel, négligence… Les excuses habituelles qui coûtent cher.

John Hamre reconnaîtra plus tard que Solar Sunrise a été une piqure de rappel salutaire : “Nous pensions que nos systèmes étaient sûrs parce qu’ils étaient complexes. On a découvert que la complexité créait des vulnérabilités.” Du coup, refonte massive, création du Joint Task Force-Computer Network Defense, investissement de milliards dans la cybersécurité, formation du personnel…

Le FBI produit même un film de formation de 18 minutes baptisé “Solar Sunrise: Dawn of a New Threat”, vendu jusqu’en 2004. On y voit des reconstitutions dramatiques avec de la musique anxiogène et le message c’est que la cyberguerre est réelle, même si les premiers cyber-soldats sont des ados boutonneux en pyjama.

L’incident révèle surtout le problème crucial de l’attribution dans le cyberespace car comment distinguer un gamin dans sa chambre d’une unité d’élite du renseignement militaire ? Encore aujourd’hui, les indices techniques sont trompeurs, car les hackers “rebondissent” à travers le monde.

Solar Sunrise marque aussi l’émergence des collectifs de hackers. Fini le pirate solitaire. Makaveli, Stimpy et Analyzer forment un groupe, échangent des techniques, se motivent. Pour Makaveli et Stimpy, l’aventure s’est arrêté brutalement. Certains racontent que Makaveli s’est reconverti dans la cybersécurité et que Stimpy, traumatisé, aurait complètement décroché de l’informatique. Mais leur petite phrase “It’s power, dude” est devenue culte dans la communauté hacker.

Alors la prochaine fois que vous ignorez une mise à jour de sécurité, pensez à Solar Sunrise et à ces 3 semaines où l’Amérique a cru que Saddam lançait la cyberguerre alors que c’était juste quelques ados qui s’amusaient à prendre le “pouvoir”.

Sources : National Security Archive - Solar Sunrise After 25 Years, Wikipedia - Ehud Tenenbaum, The Register - Solar Sunrise hacker ‘Analyzer’ escapes jail, InformIT - The Solar Sunrise Case, SF Gate - Hacker Hits Net Company That Tipped FBI to Teens, Insecure.org - Solaris Statd exploit

Si vous vous intéressez au référencement, ce que je vais vous raconter aujourd’hui risque de chambouler pas mal de vos certitudes sur le SEO. En effet, un chercheur vient de découvrir 59 facteurs de ranking cachés dans l’algorithme de Perplexity AI, et autant vous dire que ça change complètement la donne pour tous ceux qui veulent être visibles sur ce moteur de recherche IA.

Si vous ne connaissez pas encore Perplexity et bien c’est pas grave, je vous explique ! C’est un site qui combine un LLM avec un moteur de recherche traditionnel ce qui lui permet d’éviter la plupart du temps, les fameuses hallucinations de l’IA. Mais ce qu’on ne savait pas jusqu’à maintenant, c’est comment ce truc décide exactement quel contenu mérite d’apparaître dans ses réponses. Et vous allez voir, ce système est d’une complexité hallucinante.

Il y a d’abord ce qu’ils appellent le newpostimpression_threshold. C’est une fenêtre critique qui apparait juste après la publication et où tout se joue. Si votre contenu ne performe pas dans les premières minutes (littéralement), vous êtes grillé pour toujours. C’est brutal mais c’est comme ça que l’algorithme fonctionne.

D’ailleurs, l’algorithme Sonar de Perplexity (oui, ils lui ont donné un petit nom, c’est meugnon) est complètement obsédé par la fraîcheur du contenu. Sonar prend le système QDF de Google et le pousse à son maximum. Même une modification mineure remet complètement à zéro le chrono de fraîcheur. Du coup, certains malins automatisent des updates hebdomadaires juste pour rester dans la course.

Mais attendez, ça devient encore plus intéressant car le système utilise aussi un reranker machine learning à trois couches (L3) pour les recherches d’entités. En gros, après avoir récupéré les résultats initiaux, l’algo applique des filtres ML super stricts et si trop peu de résultats passent le seuil, hop, toute la liste part à la poubelle. C’est du tout ou rien.

Un autre pattern complètement loufoque, ce sont les titres YouTube qui obtiennent une visibilité boostée sur les deux plateformes, s’il correspondent exactement aux requêtes trending sur Perplexity. Ça suggère donc une validation croisée entre YouTube et Perplexity. Le système récompense ceux qui réagissent vite sur les sujets émergents.

Pour le contenu structuré, c’est également la fête du FAQ Schema. Les blocs JSON-LD avec @type: FAQPage doublent littéralement la fréquence de citation dans les tests A/B. Perplexity adore ces chunks sémantiques bien découpés qui s’alignent parfaitement avec la logique de récupération des LLM.

Et puis il y a cette histoire de PDFs qui défie toute logique. Un PDF obtient en moyenne 1,6 citations pour 100 requêtes contre 1,3 pour le même contenu en HTML. Ça peut paraître insignifiant, mais multipliez ça par le volume de recherches et vous comprenez vite l’intérêt.

Le système maintient aussi des listes manuelles de domaines autoritaires (Amazon, GitHub, LinkedIn, Coursera…) comme ça, si votre contenu est lié ou référencé par ces plateformes, vous bénéficiez automatiquement d’un boost d’autorité. C’est du favoritisme assumé, mais ça marche.

Pour ceux qui veulent optimiser leur contenu, pensez donc à le structurer avec des H1-H4, des bullet points, des listes numérotées car ces formats facilitent l’extraction par l’IA et améliorent vos chances d’être cité. Simple mais efficace. Perso, je ne mets jamais trop de liste ou d’inter-titres dans mes articles mais c’est encore à ma portée.

Le système privilégie aussi certains topics avec des multiplicateurs de visibilité différents. L’IA, la tech, la science et le business analytics sont les grands gagnants donc si vous écrivez sur ces sujets, vous partez avec un avantage naturel.

Un autre détail technique important c’est il existe un schéma cryptographique “weak” au niveau des requêtes du navigateur qui gouverne l’évaluation du contenu. Les signaux passent par cette couche additionnelle invisible via l’API standard, ce qui explique pourquoi certains contenus semblent avoir des avantages inexpliqués.

La fonction Deep Research de Perplexity décompose aussi automatiquement les questions complexes en sous-tâches, consulte diverses sources spécialisées et compile tout ça en rapport détaillé. C’est cette capacité qui rend l’optimisation si différente du SEO classique.

Bref, on est en plein dans du GEO (Generative Engine Optimization) qui est en train de remplacer progressivement le SEO traditionnel. Les règles changent complètement et s’en est fini du bourrage de mots-clés… Maintenant, place à la richesse sémantique et à la structuration intelligente du contenu.

Donc pour maximiser vos chances, voici la stratégie gagnante : Publiez fréquemment du contenu ultra-frais, structurez-le parfaitement avec du schema markup FAQ, créez des clusters de contenu interconnectés, et surtout, surtout, assurez-vous que les premières minutes après publication soient explosives en termes d’engagement.

Le time decay est impitoyable sur Perplexity et votre contenu perd exponentiellement en visibilité au fil du temps. C’est pourquoi les updates réguliers ne sont pas une option mais une nécessité absolue. Certains créateurs programment des rafraîchissements automatiques toutes les semaines juste pour maintenir leur position.

Perso, ça me parait compliqué à mon échelle de gérer tout ça, donc je vais passer mon tour et laisser mes collègues média bien se prendre le chou pour se faire indexer du mieux qu’ils peuvent. Vous me raconterez, moi j’ai la flemme ! Je compte uniquement sur mon flux RSS maintenant et sur les gens qui mettent korben.info en page d’accueil (ou qui installent ce plugin). Et advienne que pourra…

Ce qu’il faut retenir, c’est que Perplexity est très fort pour valider la pertinence en temps réel. Le système analyse les embeddings avec des seuils de similarité sophistiqués, traque l’engagement utilisateur de manière ultra-précise, et récompense les réseaux de contenu interconnectés qui démontrent une expertise par sujet.

Bref, je vous laisse lire tout ça mais ces 59 facteurs révèlent un algorithme d’une complexité insoupçonnée qui mélange machine learning avancé, signaux temps réel et validation cross-platform. J’sais pas si Google est au point là dessus, mais je leur souhaite aussi bon courage !

Et un grand merci à Lorenper pour l’info !

Source

Bon, je vais encore vous raconter un truc qui devrait vous filer des sueurs froides. Désolé ^^.

En juillet dernier, des prix Nobel se sont réunis à l’Université de Chicago pour écouter des experts du nucléaire leur expliquer comment le monde pourrait finir. Et devinez quoi ? Ils sont tous d’accord sur un point : l’IA va bientôt s’infiltrer dans les systèmes d’armes nucléaires. C’est pas une question de “si”, c’est simplement une question de “quand”.

Bob Latiff, un général de l’US Air Force à la retraite qui aide à régler l’horloge de l’apocalypse chaque année, compare l’IA à l’électricité : “Ça va s’infiltrer partout”. Et quand un mec qui s’occupe littéralement de l’heure de la fin du monde dit ça, j’sais pas vous, mais moi je commences à me poser des questions.

Le problème, c’est que personne ne sait vraiment ce que ça signifie de donner le contrôle d’armes nucléaires à une IA. Jon Wolfsthal, ancien assistant spécial de Barack Obama et maintenant directeur du risque global à la Federation of American Scientists, le dit tout de go : “Personne ne sait vraiment ce qu’est l’IA”. C’est vrai ça, on parle de quoi exactement ? De ChatGPT avec les codes nucléaires ? D’une puce qui décide de lancer des missiles ?

Rassurez-vous (ou pas), tous les experts s’accordent pour dire que ChatGPT ou Grok n’auront pas les codes nucléaires de sitôt, par contre, Wolfsthal a entendu des trucs flippants dans les couloirs du pouvoir américain. Des gens proposent sérieusement de créer des LLM pour simuler Putin ou Xi Jinping, histoire d’aider le président à anticiper leurs réactions. “Super idée”, dit Wolfsthal, “mais comment tu sais que Putin croit vraiment ce qu’il dit ou écrit ?”

L’année dernière, le général Anthony J. Cotton, le chef militaire en charge de l’arsenal nucléaire américain, a fait également un long discours sur l’importance d’adopter l’IA. Les forces nucléaires développent des “outils d’aide à la décision activés par l’IA mais dirigés par des humains”. Ça sonne bien sur le papier, mais dans la pratique, aucune idée de ce que ça donne…

Parlons maintenant de Stanislav Petrov, ce lieutenant-colonel soviétique qui a littéralement sauvé le monde en 1983. Selon le Bulletin of the Atomic Scientists, son système d’alerte précoce lui indiquait que les États-Unis avaient lancé 5 missiles. Et Petrov, sans se chier dessus, s’est dit : “C’est con, une première frappe américaine, ce serait tout ou rien, pas cinq missiles”. Il a donc décidé d’ignorer l’alerte. Bonne intuition ! En réalité, c’était le soleil qui se reflétait sur les nuages.

Du coup, si Petrov avait été une machine programmée pour répondre automatiquement à une attaque, c’est sûr qu’on aurait eu une guerre nucléaire. Petrov étant humain, il a su sortir de ses “données d’entraînement”, si je puis dire. Il a fait un jugement humain basé sur l’expérience et l’intuition. Une IA, par définition, ne peut pas faire ça.

Ce qui fait vraiment flipper Wolfsthal, ce n’est pas l’idée qu’une IA devienne skynet et lance une guerre nucléaire toute seule. C’est plutôt que quelqu’un décide d’automatiser certaines parties du système, créant des vulnérabilités qu’un adversaire pourrait alors exploiter. Ou pire, que l’IA produise des recommandations que les humains ne comprennent pas vraiment mais suivent quand même.

D’ailleurs, selon un rapport de Chatham House de juin 2025, l’IA pourrait aider à prévenir l’escalade nucléaire en étant intégrée dans les systèmes d’alerte précoce mais seulement si on comprend vraiment les risques. Et je vous spoile direct : On ne les comprend pas.

La France n’est pas en reste dans cette course. L’IFRI note que l’IA pourrait affaiblir la dissuasion nucléaire en rendant vulnérables des systèmes jusqu’alors considérés comme protégés. Les États-Unis développent également un projet pour frapper les lanceurs mobiles de missiles balistiques en utilisant l’IA pour analyser des données en temps réel. Les États pourraient alors avoir recours à l’arme nucléaire de manière préventive par peur de perdre leur capacité de riposte.

La Russie a aussi déjà son système Perimeter, surnommé “Dead Hand” (la main morte), et développe Poseidon, un drone sous-marin autonome armé nucléairement. Un drone qui peut traverser les océans tout seul pour livrer une bombe capable de vaporiser une ville entière. Qu’est-ce qui pourrait mal tourner, voyons ?

Le problème des biais d’automatisation est particulièrement vicieux. Brookings explique que les études montrent que les gens font naturellement confiance aux systèmes automatisés. Imaginez un opérateur stressé en temps de crise qui doit choisir entre son intuition et ce que lui dit l’IA. Et bah dans 99% des cas, il déposera son cerveau et suivra l’IA. Vous le savez, c’est ce que vous faites quand vous vibe codez ;-).

Le plus marrant dans tout ça (ou pas) c’est que Donald Trump et le Pentagone ont déclaré que l’IA était “le prochain projet Manhattan” et que “les États-Unis VONT GAGNER”. Sauf que comme le fait remarquer Lin : “Je sais quand le projet Manhattan s’est terminé… on a fait exploser une bombe. Mais je ne sais pas ce que signifie avoir un projet Manhattan pour l’IA.” Bah oui, ils vont faire exploser quoi ??

La revue de l’OTAN se demande si l’IA devrait être complètement bannie des systèmes d’armes nucléaires. En 2023, le Congrès américain a même proposé une loi dans ce sens et Biden a signé un décret sur le sujet. Mais il n’y a toujours pas de consensus global sur le fait que les humains doivent rester dans la boucle de décision nucléaire.

Voilà, donc pour l’instant, lancer une arme nucléaire américaine nécessite encore une chaîne complexe de décisions humaines et il faut toujours deux personnes qui doivent tourner des clés en même temps dans un silo pour lancer un missile. La politique nucléaire américaine exige ce qu’on appelle une “double phénoménologie”. Cela veut dire qu’une attaque doit être confirmée par satellite ET radar pour être considérée comme réelle. Mais combien de temps avant qu’on remplace un de ces phénomènes par une IA ?

Perso, je pense que l’IA dans le nucléaire c’est une idée à la con. Pourquoi jouer à la roulette russe avec l’humanité entière alors qu’on a déjà fort à faire avec tous nos dirigeants mentalement instables ?

Évidemment, vous l’aurez compris, l’IA ne lancera probablement pas des missiles toute seule, mais elle pourrait très bien nous convaincre de le faire nous-mêmes, à cause d’une mauvaise interprétation de données ou d’un bug qu’on ne comprend même pas. Et ça, c’est tout aussi flippant, je trouve.

Source