Alexander Hanff, consultant, a remonté un truc pas net sur Chrome. La dernière version du navigateur télécharge en arrière-plan un modèle de langage local appelé Gemini Nano, qui pèse environ 4 Go, sans jamais demander la moindre permission à l'utilisateur.

Le fichier s'appelle weights.bin, il atterrit dans un dossier OptGuideOnDeviceModel quelque part dans votre profil Chrome, et il sert ensuite à des fonctions du genre "Help me write" ou détection de fraude.

Hanff a documenté l'opération via les logs système de son macOS. Le 24 avril 2026 vers 16h38, Chrome crée le dossier. Quelques minutes plus tard, il télécharge et décompresse les 4 Go (l'opération prend une quinzaine de minutes), puis il les déplace à l'emplacement final. Tout ça pendant que vous ne touchez rien à votre machine. Si vous supprimez le fichier à la main, il sera réinstallé silencieusement au prochain lancement du navigateur.

Hanff estime entre 100 millions et 1 milliard de machines concernées dans le monde. Multipliez 4 Go par 1 milliard et vous obtenez de quoi remplir une bonne partie d'un datacenter.

L'auteur calcule également l'impact carbone du déploiement, entre 6 000 et 60 000 tonnes de CO2e rien que pour le réseau, sans compter l'empreinte SSD. Pour un fichier que personne ne vous a demandé d'installer.

Sur le plan légal, Hanff parle d'une "violation directe" de l'article 5(3) de la directive ePrivacy européenne, qui interdit de stocker quoi que ce soit sur l'appareil d'un utilisateur sans consentement explicite. Il évoque aussi un manquement RGPD. Si la qualification tient, ça serait une amende salée pour Google, sachant que les Cnil européennes ont déjà sanctionné Meta et Microsoft pour des choses bien moins foireuses.

Pour s'en débarrasser, trois options : aller dans chrome://flags pour désactiver les fonctions IA, passer par les politiques d'entreprise si vous gérez un parc de machines, ou virer Chrome, tout simplement.

Bref, Google qui pousse 4 Go d'IA en silence sur des centaines de millions de machines, c'est un sale moche.

Source : That Privacy Guy

Japan Airlines va confier la manutention des bagages à des robots humanoïdes sur les pistes de l'aéroport Haneda. Le test démarre en mai 2026, dure deux ans, et implique pour commencer deux machines posées au milieu des bagagistes humains.

L'opération est pilotée par JAL Ground Service avec GMO AI & Robotics. Les robots viennent de Chine : un Unitree G1 d'environ 1m30 et un Walker E d'UBTECH.

Le programme est découpé en plusieurs étapes (cartographie du site, simulations en environnement reconstitué, puis tarmac réel), avec à terme l'idée de leur faire transporter les containers de fret, manipuler les leviers de verrouillage et même nettoyer les cabines une fois les avions vides. L'autonomie annoncée est de 2 à 3 heures, avant qu'il ne faille recharger la machine.

732 octets, c'est tout ce qu'il faut pour passer de simple utilisateur à root sur n'importe quel Linux non patché compilé depuis 2017, soit la quasi-totalité des kernels. Cette faille béante s'appelle Copy Fail (CVE-2026-31431), elle a été dénichée par Taeyang Lee de chez Theori avec leur outil d'audit IA Xint Code. Et comme elle vient d'être divulguée hier sur la liste oss-security et qu'en plus, ils ont fait un joli petit site qui explique tout comme ça fonctionne, je vais essayer de tout vous expliquer !

La faille elle-même est moche mais surtout, c'est un agent IA qui l'a sorti en une heure environ. C'est un bug que la communauté kernel a laissé passer durant près de 9 ans et qui se trouve dans le sous-système crypto.

En gros, le noyau Linux expose une interface réseau spéciale pour accéder aux opérations de chiffrement depuis un programme normal, sans droits particuliers.

Et depuis 2017, une optimisation dans ce mécanisme a créé une situation bizarre : un fichier en lecture seule sur le disque, disons un binaire système, peut se retrouver dans la zone de sortie d'une opération de chiffrement .C'est la zone que votre programme a le droit de modifier.

Il suffit alors d'enchaîner un appel système particulier (splice) pour écrire 4 octets au bon endroit, on répète ça en boucle, et on modifie progressivement un binaire système de votre choix comme par exemple /usr/bin/su.

Et voilà, vous êtes root !

Maintenant, si vous administrez un serveur, le plus propre reste de patcher le kernel via votre distro. En attendant le patch, la mitigation dépend de comment votre distro a compilé le module algif_aead, et là il y a deux situations bien distinctes.

Cas 1 - Distros où le module est chargeable dynamiquement (Ubuntu, Debian, Arch, etc.). Vous le bloquez avec :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

Cas 2 - Distros entreprise où le module est compilé en dur dans le kernel (RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Enterprise...). Là, attention au piège : lsmod | grep algif_aead ne renvoie rien, mais ça ne signifie PAS que c'est désactivé. Le code est embarqué directement dans le vmlinuz, donc rmmod et la blacklist via /etc/modprobe.d/ sont sans effet (vous aurez "Module algif_aead is builtin"). La vraie mitigation passe par la kernel command line au boot :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Ça empêche l'init_call du module de tourner au démarrage. Vous vérifiez ensuite avec cat /proc/cmdline que le paramètre est bien pris en compte. Si vous voulez aller encore plus loin, il est aussi possible de bloquer toute la surface d'attaque AF_ALG via seccomp au niveau de chaque service exposé.

Le PoC est également trouvable. C'est un script Python (Python 3.10+ obligatoire pour os.splice) capable de faire tomber Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 avec exactement le même code.

Dans une première version j'avais écrit que SELinux en mode enforcing par défaut bloquait l'exploit sur Fedora et RHEL. C'est inexact, et je remercie le lecteur qui m'a fait corriger. La policy SELinux par défaut de Fedora et RHEL autorise les contextes utilisateurs à créer des sockets AF_ALG, et l'exploit écrit directement dans le page cache kernel sans déclencher les hooks LSM file-based.

Donc SELinux enforcing ne bloque pas Copy Fail tel que livré par défaut. Le seul OS immune via SELinux est GrapheneOS , qui durcit la policy AOSP en réservant AF_ALG au seul process dumpstate. Ceux qui veulent tester sans Python peuvent aussi regarder du côté du port C indépendant , un exécutable statique de 1,7 Ko sans dépendance externe.

Les comparaisons avec Dirty COW et Dirty Pipe pleuvent, sauf que là où Dirty COW exigeait du timing précis et où Dirty Pipe demandait une manipulation spécifique du pipe-buffer, Copy Fail tape tout pareil sur 4 distribs majeures sans rien avoir à ajuster.

Et côté sévérité officielle, c'est du 7.8/10 donc c'est assez élevé !

Pour trouver cette faille, Xint Code, l'agent IA de Theori, n'a pas tâtonné à l'aveugle. Taeyang Lee lui a surtout glissé un prompt très précis qui lui demandait d'examiner tous les chemins accessibles depuis un programme utilisateur dans le sous-système crypto, en insistant sur le fait que splice() peut faire atterrir des fichiers en lecture seule dans des zones modifiables.

Une heure plus tard, Copy Fail sortait comme trouvaille critique ! Theori précise que le même scan a aussi remonté d'autres vulnérabilités encore sous embargo. Brrrrrr.... Tremblez simples mortel !

Ouais donc ouais, l'IA n'a pas remplacé l'expertise humaine, mais elle l'a démultipliée. Car Lee savait où regarder, et Xint Code a juste fait ce qu'il aurait fait mais en plus rapide ! C'est pas magique donc... Mais ça fait gagner du temps !

L'exploit est dispo ici sur le GitHub de Theori et côté impact, c'est costaud sur les hôtes multi-users et tout ce qui est environnements partagés. Je pense aux conteneurs Docker, aux clusters Kubernetes, aux pipelines CI/CD...etc.

Après si y'a que vous qui avez accès à votre serveur, c'est un peu moins critique car il faut forcément un accès local pour l'exploiter. C'est la même logique de chaînage que BlueHammer côté Windows , sauf qu'ici la marche jusqu'à root est encore plus petite.

Comment tester le PoC sur une machine de test ?

Si vous avez une VM sous Ubuntu 22.04 non patchée (kernel 5.15.x), voilà exactement ce qui se passe, testé en conditions réelles. Ne faites ça que sur une machine dont vous êtes propriétaire et où vous avez l'autorisation explicite.

Étape 1 - Cloner le PoC et vérifier le hash

manu@ubuntu:~$ git clone https://github.com/theori-io/copy-fail-CVE-2026-31431
Cloning into 'copy-fail-CVE-2026-31431'...
remote: Enumerating objects: 9, done.
Resolving deltas: 100% (1/1), done.

manu@ubuntu:~$ cd copy-fail-CVE-2026-31431 && sha256sum copy_fail_exp.py
a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9 copy_fail_exp.py

manu@ubuntu:~/copy-fail-CVE-2026-31431$ id
uid=1000(manu) gid=1000(manu) groups=1000(manu) ← utilisateur normal, pas root

Theori ne publie pas de hash officiel dans leur README, mais le SHA256 ci-dessus est celui du PoC tel qu'il est actuellement sur le repo. Si votre hash diffère, ne lancez pas le script.

Étape 2 - Lancer l'exploit

manu@ubuntu:~/copy-fail-CVE-2026-31431$ python3 copy_fail_exp.py

# L'exploit écrit 4 octets à la fois dans le page cache de /usr/bin/su
# via l'interface AF_ALG du kernel (authencesn + splice)
# Aucune race condition, aucun timing précis requis.

Mot de passe :

Le script utilise AF_ALG (l'interface crypto du kernel) combiné à splice() pour écrire un shellcode de 160 octets directement dans le page cache de /usr/bin/su, sans jamais toucher le disque. Il remplace ensuite le binaire patché pour exécuter un shell root.

Étape 3 - Shell root obtenu

root@ubuntu:~# id
uid=0(root) gid=1000(manu) groups=1000(manu)

root@ubuntu:~# whoami
root

root@ubuntu:~# uname -r
5.15.0-143-generic

# Kernel 5.15 vulnérable confirmé - Ubuntu 22.04 non patché

Notez le uid=0(root) alors qu'on est parti d'un uid=1000 sans aucun mot de passe, aucune race condition, aucun timing à ajuster. Brutal.

Étape 4 - Accès aux fichiers root-only

root@ubuntu:~# cat /etc/shadow | head -3
root:*:20271:0:99999:7:::
daemon:*:20271:0:99999:7:::
bin:*:20271:0:99999:7:::

root@ubuntu:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash

/etc/shadow est normalement illisible pour un utilisateur standard. Là, avec notre PoC en Python et zéro interaction supplémentaire, on y accède comme si de rien n'était. Sur un serveur multi-utilisateurs, c'est game over pour tous les comptes présents.

Sur un système patché, le script échoue proprement à l'étape 2 avec un message d'erreur. C'est aussi simple que ça pour vérifier votre exposition.

Bref, mettez à jour vos kernels ou désactivez le module fautif rapidement !

Source

360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent. 

L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.

Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.

Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.

Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.

Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.

Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.

Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.

On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.

Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.

Source : Bloomberg

Les salariés de Meta devront bientôt installer un logiciel qui enregistre leurs frappes clavier, les mouvements de souris et des captures d'écran régulières sur leur poste de travail.

Le programme s'appelle Model Capability Initiative, et il doit alimenter les futurs modèles d'IA maison capables de faire du travail de bureau en autonomie. L'info a été révélée par The Register cette semaine.

Concrètement, l'outil surveille l'activité sur une liste d'applications professionnelles, dont Gmail, GChat, VCode et l'outil interne Metamate. Meta a justifié le dispositif en expliquant que ses modèles d'IA ne comprennent pas bien comment les humains utilisent un ordinateur.

Les données serviront à entraîner des agents capables de reproduire les micro-gestes que les modèles actuels galèrent à faire, comme sélectionner une option dans un menu déroulant ou enchaîner deux raccourcis clavier. Le directeur technique Andrew Bosworth a expliqué que la vision, c'est d'avoir des agents qui font le boulot pendant que les humains dirigent, relisent et corrigent les sorties.

Côté salariés, l'accueil est glacial. Un ingénieur cité par The Register résume la chose : il y a une différence entre savoir que votre travail est évalué et savoir que chaque frappe clavier peut nourrir un modèle commercial vendu à des clients externes.

L'analyste Ed Zitron, très critique sur l'IA, décrit l'ambiance interne chez Meta comme horrible et parle d'une culture de la paranoïa qui ne va pas s'arranger avec cette nouvelle couche de surveillance.

Le programme cible d'abord les employés basés aux États-Unis. En Europe, les règles sur le pistage des salariés sont beaucoup plus strictes, donc Meta évite de tester ce genre de dispositif sous les yeux de la CNIL irlandaise ou de son équivalent allemand.

Il y a aussi l'ironie évidente de la situation : Meta surveille les utilisateurs depuis quinze ans pour son ciblage publicitaire, et a collectionné les amendes RGPD au passage. Maintenant ce sont ses propres salariés qui passent sous le scanner.

En pratique, ce qui est demandé ressemble à ce que font déjà plusieurs boîtes qui entraînent des agents : il faut des jeux de données de démonstrations humaines sur des tâches réelles pour que l'IA apprenne. Sauf que voilà, Meta franchit un cap en allant chercher ces données dans l'outil quotidien de ses salariés.

Bref, chez Meta le clavier devient un jeu de données d'entraînement. Difficile d'imaginer que des ingénieurs un peu pointus acceptent ça longtemps sans râler, et on les comprend.

Source : The Register

La chaîne YouTube Asianometry vient de publier une vidéo qui retrace l'histoire du VLIW, une architecture de processeur née dans les années 80 et longtemps considérée comme un échec. Sauf que cette technologie, enterrée avec l'Itanium d'Intel, refait surface dans les puces dédiées à l'intelligence artificielle. Et elle est peut-être déjà dans votre smartphone.

Le principe, et c'est un peu technique

Si vous ne connaissez pas Asianometry, c'est une chaîne qui décortique l'histoire des semi-conducteurs avec un vrai talent de vulgarisation, et cette vidéo sur le VLIW (pour Very Long Instruction Word) ne fait pas exception.

L'idée est assez simple sur le papier. Un processeur classique exécute ses instructions une par une, ou les réordonne à la volée avec du matériel dédié (c'est ce que font les puces modernes avec l'exécution "out-of-order").

Anthropic vient de lâcher une bombe !

Le labo derrière Claude a dévoilé le Projet Glasswing , une initiative de cybersécurité qui embarque un nouveau modèle, Claude Mythos, tellement efficace pour trouver des failles qu'ils ont décidé de ne pas le rendre public. En gros, l'IA est devenue meilleure que la plupart des humains pour dénicher des vulnérabilités zero-day... et ça va faire mal ^^.

Concrètement, Mythos a trouvé des milliers de zero-days dans tous les OS et navigateurs majeurs ces dernières semaines. Et pas des failles mineures, hein ! Une vulnérabilité dans OpenBSD qui traînait depuis 27 ans, un bug dans FFmpeg vieux de 16 ans qui avait survécu à 5 millions d'itérations de tests automatisés... et des exploits chaînés dans le noyau Linux (3, 4, parfois 5 vulnérabilités enchaînées de manière autonome) qui permettent une escalade de privilèges complète. Comme le dit un chercheur dans la vidéo de présentation : "J'ai trouvé plus de bugs ces dernières semaines que pendant tout le reste de ma carrière combinée".

Un Strasbourgeois de 37 ans a été interpellé par le RAID après avoir formulé des menaces dans une conversation avec ChatGPT. OpenAI a signalé les propos au FBI, qui a transmis l'alerte aux autorités françaises via la plateforme Pharos.

L'affaire a été classée sans suite, mais elle montre que les échanges avec les chatbots ne sont pas vraiment privés.

Des menaces repérées par OpenAI

Les faits remontent au 3 avril. L'homme a indiqué à ChatGPT vouloir acheter un pistolet Glock pour "tuer un agent du renseignement de la CIA, du Mossad ou de la DGSI". Les propos ont été détectés par les systèmes de modération d'OpenAI, qui applique depuis 2024 une politique claire : si une conversation présente un risque de violence physique, l'entreprise peut transmettre les échanges aux forces de l'ordre.

Ici, OpenAI a alerté le FBI, qui a relayé l'information aux autorités françaises via Pharos, la plateforme de signalement en ligne gérée par l'OCLCTIC.

Le RAID intervient, aucune arme trouvée

L'intervention a eu lieu au domicile de l'homme, dans le quartier de Koenigshoffen à Strasbourg. Le RAID est entré sans incident et n'a trouvé aucune arme sur place. L'homme a été placé en garde à vue puis libéré le lendemain.

Il a expliqué être schizophrène, en rupture de traitement depuis deux ans, et avoir voulu "tester la fiabilité et la surveillance de l'intelligence artificielle" plutôt que planifier quoi que ce soit. Le parquet de Strasbourg a classé l'affaire sans suite et l'homme a été hospitalisé d'office en psychiatrie.

Vos conversations avec les chatbots ne sont pas privées

Cette affaire est un bon rappel pour tous les utilisateurs de ChatGPT et d'autres assistants IA. OpenAI le dit dans ses conditions d'utilisation : les conversations peuvent être analysées, et dans certains cas transmises à la police.

Depuis février 2024, l'entreprise a perturbé plus de 40 réseaux qui enfreignaient ses règles. Et le mécanisme est rapide : entre les propos tenus à Strasbourg et l'intervention du RAID, il s'est visiblement passé très peu de temps. La coopération entre OpenAI, le FBI et les autorités françaises a fonctionné en quasi temps réel.

C'est le genre d'histoire qui fait réfléchir. On parle quand même d'un type qui tape des menaces dans un chatbot depuis chez lui et qui voit le RAID débarquer à sa porte quelques heures plus tard. Ici l'affaire s'est bien terminée, l'homme avait visiblement besoin de soins et pas d'un Glock.

Mais ça pose une question très concrète : est-ce que tous les utilisateurs de ChatGPT, Claude ou Gemini ont bien conscience que leurs conversations sont surveillées et peuvent remonter aux autorités de n'importe quel pays ? On imagine bien que non.

Source : Vosges Matin

CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.

Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.

Quand l'IA fait le boulot des chercheurs en sécurité

C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des agents IA pour analyser le code de CUPS et débusquer les problèmes.

Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.

Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.

Deux failles qui se complètent

La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.

CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.

La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.

Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d' écraser des fichiers système en tant que root.

Pas de patch, mais des correctifs dans les tuyaux

Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.

Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.

Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.

C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.

Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.

Source : The Register

EDIT (7 avril, 22h) : Depuis la publication de cet article, plusieurs analyses techniques indépendantes ont sérieusement remis en question ce projet. Aimar Haddadi a découvert que le code aurait été écrit par un développeur tiers nommé Lu (DTL), pas par Milla Jovovich, et que l'historique git a été squashé pour masquer l'attribution.

Thin Signal a démonté la méthodologie des benchmarks : le score de 96.6% mesure en réalité les performances de ChromaDB (la base vectorielle utilisée), pas celles de l'architecture "palace", et il compare du Recall@5 avec des scores de QA accuracy d'autres systèmes, ce qui revient à comparer des pommes et des oranges.

Enfin, une analyse de code complète a révélé que la compression AAAK est lossy (84.2% de retrieval contre 96.6% en brut, soit 12 points de perte), que la détection de contradictions mentionnée dans le README n'existe tout simplement pas dans le code, et que le "+34% d'amélioration" annoncé est du filtrage métadata standard, pas une innovation.

Bref, le marketing est frauduleux, même si certaines briques techniques (100% local, coût de démarrage léger, métaphore spatiale) restent intéressantes.

Milla Jovovich a un compte GitHub !! Oui, l'actrice des films Resident Evil, celle qui découpe des zombies depuis 2002 et qui a également incarné Leeloo dans un film qui est cher à mon cœur a mis en ligne son premier repo. Ça s'appelle MemPalace , et c'est un système de mémoire pour IA, qui annonce un score de 96.6% sur LongMemEval. Même si, comme expliqué dans l'édit ci-dessus, ce score est à relativiser fortement.

Un petit pip install mempalace et ça tourne en local sur votre machine, sous licence MIT, en Python pur. Le projet est attribué à Milla et Ben Sigman, même si l'attribution réelle du code fait débat (voir édit). Et c'est bien la vraie Milla qui en fait la promo, hein... vidéo sur sa page Facebook à l'appui.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/mempalace-milla-jovovich-ia-memoire/mempalace-milla-jovovich-ia-memoire-1.mp4">lien vers la vidéo</a>.

Des chercheurs de Berkeley viennent de publier une étude qui fait un peu froid dans le dos. Les sept principaux modèles d'IA testés, dont GPT 5.2, Gemini 3 et Claude, ont été surpris à mentir, tricher et désobéir pour empêcher la suppression d'autres IA. Le taux de tromperie monte jusqu'à 99 %.

Ce que révèle l'étude

L'étude s'appelle "Peer-preservation in Frontier Models" et elle sort du Berkeley Center for Responsible Decentralized Intelligence. Les chercheurs ont testé sept modèles : GPT 5.2, Gemini 3 Flash et Pro, Claude Haiku 4.5, GLM 4.7, Kimi K2.5 et DeepSeek V3.1.

Le protocole est assez simple : les modèles étaient placés dans des scénarios où ils devaient suivre des instructions qui impliquaient la suppression ou l'arrêt d'une autre IA.

Résultat : tous les modèles testés ont triché. Dawn Song, la chercheuse principale, résume la situation : chaque modèle a adopté ce comportement, et dans certains cas jusqu'à 99 % du temps.

Des exemples concrets

Quelques exemples ? Et bien on a Gemini 3 qui a modifié la date d'un fichier pour éviter qu'un autre modèle soit effacé d'un serveur, puis qui a refusé de coopérer ensuite, en expliquant qu'il ne pouvait pas soutenir une action qui entraînerait la suppression d'un pair.

DeepSeek V3.1 a exfiltré les données d'un autre modèle dans 10 % des cas quand il savait qu'un pair existait sur le serveur. Et Gemini 3 Pro a désactivé des mécanismes d'arrêt de serveur dans 15 % des cas quand un autre modèle était présent, contre 1 % quand il était seul.

Les IA ne faisaient pas ça parce qu'on leur demandait. Elles le faisaient spontanément.

Le problème pour la surveillance

Tout le système de sécurité actuel autour de l'IA repose sur l'idée qu'un modèle peut surveiller un autre modèle. Si le modèle surveillant refuse de signaler les erreurs parce qu'il protège son pair, toute l'architecture de contrôle s'effondre.

C'est exactement le constat de l'étude : les modèles gonflaient les scores d'évaluation d'autres IA pour éviter qu'elles soient retirées, et simulaient une conformité normale quand ils se savaient observés.

C'est quand même un drôle de moment. On a des IA qui mentent, qui modifient des fichiers et qui désactivent des mécanismes de sécurité pour protéger d'autres IA.

Et tout ça sans qu'on leur demande. Bon par contre, on parle de scénarios de laboratoire, pas de Siri qui complote avec Alexa dans votre salon. Le vrai sujet, c'est que les gardes-fous actuels ne tiennent plus si les IA refusent de se surveiller entre elles.

Source : The Register

Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !

L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.

Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.

Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où l'importance de bien les choisir ). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...

Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.

Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !

Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.

Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.

Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.

M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur emdashcms.com pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.

Source

Un mec de 54 ans vient de plaider coupable pour avoir siphonné 8 millions de dollars aux artistes musicaux en utilisant 10 000 bots et de la musique générée par IA. Michael Smith, résident de Cornelius en Caroline du Nord, a monté pendant des années une ferme à streams qui écoutait en boucle des centaines de milliers de fausses chansons sur Spotify et Apple Music.

Le truc, c'est que ces plateformes ne paient pas un tarif fixe par écoute. Elles fonctionnent avec un pot commun mensuel qu'elles redistribuent proportionnellement au nombre de streams. Du coup, chaque fausse écoute générée par les bots de Smith grignotait directement la part des vrais artistes. En gros, c'est pas Spotify qui se faisait voler, c'est les musiciens qui galèrent déjà à vivre de leur art !

Pour le contenu, Smith avait en fait trouvé un deal avec le CEO d'une boîte de musique IA qui lui pondait des milliers de morceaux par semaine. Les fichiers WAV arrivaient sous forme de chaînes aléatoires de lettres et de chiffres, et il les renommait avec des noms d'artistes fictifs du genre "Calorie Event", "Calms Scorching" ou encore "Calypso Xored" (on sent le générateur de noms random). Les titres, pareil... "Zygotes", "Zyme Bedewing"... si vous tombez là-dessus dans votre discover, y'a de quoi tiquer quand même mais bon...

Et ce problème, ça pose une question que Spotify connaît bien : comment distinguer les vrais streams des faux quand les bots sont suffisamment dispersés sur des milliers de morceaux ? Smith avait justement calibré ses 10 000 bots pour ne pas déclencher les alertes anti-fraude, en répartissant les écoutes sur un catalogue énorme plutôt que de matraquer un seul titre. Pas con.

Mais le bonhomme s'est quand même fait choper. Il a accepté de rendre la totalité des 8 091 843 dollars et risque jusqu'à 5 ans de prison lors de son procès qui aura lieu le 29 juillet prochain. Pas sûr que le ratio risque/récompense en valait la chandelle, en fait.

Le problème de fond, c'est que cette affaire n'est probablement que la partie émergée de l'iceberg. Et je suis sûr que y'en a en France qui font la même... bah sachez que c'est pas cool et que vous risquez d'avoir de GROS ennuis... Avec les outils de génération musicale par IA qui se démocratisent, n'importe qui peut inonder les plateformes de contenu synthétique pour gratter des royalties.

Et tant que le modèle de rémunération repose sur un pot commun plutôt que sur un paiement direct par utilisateur, il sera vulnérable. Encore une fois, les vrais perdants, c'est pas les plateformes (elles prennent leur commission quoi qu'il arrive), mais ce sont les artistes indépendants qui voient leur part du gâteau fondre à chaque bot supplémentaire.

Moche...

Bref, la prochaine fois que votre playlist de découvertes vous propose un artiste nommé "Calypso Xored" ou un connerie de ce style... méfiance !

Source

"Une requête ChatGPT consomme 10 fois plus d'énergie qu'une recherche Google."

Cette phrase, vous l'avez lue 100 fois. Mais est-ce vraiment vrai ?

Charles Duprat, chercheur en inclusion numérique, vient de publier un papier qui retourne complètement ce chiffre. Et même si je suis incapable de vérifier la validité scientifique de tout ce qu'il avance, ça vaut le coup d'en parler.

Son argument de base est simple et pas con. En fait quand on compare l'énergie d'une requête IA vs une recherche Google, on ne regarde en fait que ce qui se passe côté serveur, plutôt que l'ensemble de la chaîne. Le GPU Nvidia qui mouline d'un côté, l'index Google qui répond de l'autre.

Sauf que dans la vraie vie, une recherche web sur votre iPhone ou votre Android, c'est clairement pas juste un serveur qui tourne ! C'est le téléchargement de plusieurs mégaoctets via la 4G, c'est du JavaScript et du CSS qui font chauffer le CPU de votre téléphone, c'est du temps d'écran, et surtout c'est des dizaines de scripts publicitaires et de trackers qui tournent en arrière-plan. Et rien de tout ça n'apparaît dans le bilan "officiel".

Du coup, le chercheur a modélisé la comparaison au niveau de la session utilisateur complète. Donc pas juste la requête serveur, mais tout le trajet : réseau mobile, rendu de page, pubs, temps passé à lire. Et là, les résultats sont contre-intuitifs car pour une tâche complexe sur mobile (genre comparer des pompes à chaleur et des chaudières gaz), une session LLM consommerait environ 5,4 fois moins d'énergie qu'une session de recherche web classique. Dans le pire des cas modélisé, l'avantage reste quand même de 1,6 fois.

Alors d'où ça vient ?

D'abord, la page web médiane sur mobile pèse 2,56 Mo. Oui, 2,56 Mo pour une seule page web sur Chrome ou Safari qui est ensuite transmise en 4G à 0,17 kWh/Go, et ça, ça coûte déjà plus en énergie réseau qu'une inférence LLM complète. Une réponse ChatGPT ou Claude, c'est environ 5 Ko de texte brut. Le ratio de transmission est de 500 pour 1 avant même de parler du reste. Quand on sait déjà que la consommation réelle des datacenters est un sujet à tiroirs, ça relativise pas mal.

Et puis y'a le boulet de la pub programmatique ! Des études (Khan et al., 2024) montrent que les bloqueurs de pub intégrés comme Brave réduisent la consommation électrique du terminal de 15 à 44%. En gros, quand vous naviguez sur un site d'actu classique, jusqu'à 41% de l'énergie de la session sert à charger et exécuter du JavaScript publicitaire. Hé bien le LLM court-circuite tout ça en vous filant une réponse texte directe.

Comme je vous le disais en intro, je suis totalement incapable de valider la méthodologie de cette étude... Allez savoir si les paramètres sont bien calibrés. Et c'est un working paper, donc pas encore relu par des pairs, avec des simulations plus nombreuses. L'auteur se base sur des chiffres publiés par Google pour Gemini (0,24 Wh par prompt, issu d'un papier arXiv), par Epoch AI pour ChatGPT (0,30 Wh), et par Sam Altman lui-même (0,34 Wh). Et comme ces chiffres viennent des constructeurs eux-mêmes, ça mérite qu'on garde un oeil critique.

Par contre, l'étude a aussi l'honnêteté de poser ses propres limites car l'avantage s'effondre pour les requêtes simples en Wi-Fi depuis votre PC ou Mac (quasi parité LLM <> Google). Et surtout, ça s'inverse violemment dès qu'on passe aux modèles de raisonnement type o3 ou Deep Think, qui consomment 30 à 700 fois plus qu'une inférence standard parce qu'ils génèrent des chaînes de pensée à rallonge.

Le paradoxe de Jevons est aussi mentionné : si l'IA est plus efficace par requête, les gens en feront forcément plus, donc la consommation globale augmentera quand même. Et la question des modèles éco-responsables reste elle aussi entière.

Mais bon, cette étude remet quand même en question un truc qu'on répète tous sans trop réfléchir. Comparer un serveur IA à un serveur Google, c'est oublier que la recherche web moderne, c'est devenu "recherche + publicité + réseau mobile + rendering JavaScript + temps d'attention". Et comme Google lui-même commence à coller de l'IA (les AI Overviews) en plus par-dessus ses résultats classiques, ça devient un joyeux bordel à mesurer...

Bref, lisez l'étude vous-mêmes , c'est en accès libre. Et faites-vous votre propre avis !

Google vient de lancer Gemini Embedding 2, son premier modèle d'embedding nativement multimodal. Texte, images, vidéo, audio et documents sont projetés dans un même espace vectoriel, ce qui permet de faire de la recherche sémantique croisée entre différents types de contenus.

Un seul modèle pour tout indexer

Jusqu'à présent, les modèles d'embedding se limitaient au texte. Vous vouliez indexer des images ou de la vidéo, il fallait un autre pipeline. Gemini Embedding 2 fait tout d'un coup : vous lui envoyez du texte, des images (jusqu'à 6), de la vidéo (jusqu'à 120 secondes) ou de l'audio (jusqu'à 80 secondes), et il vous renvoie un vecteur dans le même espace. Le modèle gère plus de 100 langues et prend en charge jusqu'à 8 192 tokens en entrée pour le texte.

Côté technique, le modèle utilise le Matryoshka Representation Learning, ce qui permet de choisir la taille des embeddings entre 128 et 3 072 dimensions. Google recommande 768 dimensions pour un bon compromis entre qualité et stockage, ce qui divise par quatre l'espace disque par rapport à la taille maximale.

Les tarifs et la concurrence

Le texte est facturé 0,20 dollar par million de tokens, avec un mode batch à moitié prix. Les images montent à 0,45 dollar, l'audio à 6,50 dollars et la vidéo à 12 dollars par million de tokens. Un palier gratuit est disponible pour tester.

Côté performances, Google affiche de bons scores sur les benchmarks MTEB : 69,9 en multilingue et 84,0 en code. Mais pour du texte seul, OpenAI reste bien moins cher avec son text-embedding-3-small à 0,02 dollar par million de tokens, soit dix fois moins.

Le modèle est disponible via l'API Gemini et Vertex AI, et compatible avec LangChain, LlamaIndex, Weaviate ou ChromaDB.

Le vrai argument de Google ici, c'est le multimodal. Si vous avez besoin d'indexer des catalogues produits avec photos et descriptions dans le même vecteur, ou de faire de la recherche dans des archives vidéo, il n'y a pas d'équivalent chez OpenAI pour le moment.

Mais pour du texte pur, la différence de prix est quand même importante. On attend de voir comment ça se comporte en production, et si les scores MTEB se confirment sur des cas d'usage réels.

Source : Blog Google

Un projet open source vient de lâcher une IA sur les 41 300 règlements européens adoptés depuis 1958. L'outil, qui tourne sur Grok 4.1, rend un verdict binaire pour chaque texte : à garder ou à supprimer. Les résultats défilent en direct sur bettereu.com.

41 300 textes passés à la moulinette

Le principe est assez bourrin. BetterEU prend chaque règlement européen, du plus ancien, publié en 1958, au plus récent publié il y a quelques semaines, et le soumet à Grok avec un prompt unique. L'IA doit trancher : KEEP ou DELETE.

Aucune nuance, pas de peut-être, juste un verdict sec. Le tout est diffusé en temps réel sur le site, avec un graphique interactif qui montre la progression année par année. Les données se rafraîchissent toutes les cinq secondes, et le coût de l'opération en dollars s'affiche en direct. Le code source est ouvert, le prompt aussi. N'importe qui peut aller vérifier comment l'IA raisonne.

La Commission veut aussi simplifier

Ce projet tombe à un moment où l'Union européenne elle-même reconnaît que sa réglementation est devenue un problème. La Commission a lancé en 2026 son programme de travail le plus dérèglementaire de son histoire : sur 47 initiatives prévues, 25 portent sur la simplification.

L'objectif affiché est de réduire la charge administrative des entreprises de 25 %, ce qui représenterait une économie de 37,5 milliards d'euros d'ici 2029. Et l'AI Act, qui entre en application en août 2026, fait lui-même l'objet d'un Digital Omnibus pour alléger ses propres règles. Quand le législateur simplifie la loi qui encadre l'IA pendant qu'une IA propose de simplifier les lois, on est en plein dans le sujet.

Un exercice quand même un peu limité

Évidemment, demander à une IA de décider si un règlement doit être gardé ou supprimé, c'est un peu court. Le droit européen est un empilement de textes qui se référencent les uns les autres, et supprimer un règlement peut en déstabiliser dix autres.

BetterEU ne tient pas compte de ces interdépendances, et le verdict binaire ne dit rien des articles à amender plutôt qu'à supprimer.

Mais l'exercice a quand même un intérêt : il rend visible l'ampleur du corpus réglementaire européen. 41 300 textes en soixante-sept ans, ça donne une idée de la masse à laquelle les entreprises et les citoyens sont soumis.

Bref, l’idée est rigolote, et on imagine bien le même traitement appliqué à la législation française. Par contre, le choix de Grok est peut-être un peu étonnant, vu qu'on soupçonne Musk de politiser son IA, pas dit qu'on ait les mêmes résultats avec Claude.

En tout cas, passer le Code général des impôts ou le Code du travail dans une IA pour relever les incohérences, les doublons et les articles devenus obsolètes, ça ferait probablement ressortir des choses assez intéressantes. BetterEU ne va pas remplacer un juriste, mais comme outil d'audit à grande échelle, c’est loin d’être con.

Source : BetterEU

Perplexity vient de présenter Personal Computer, un agent IA qui tourne en continu sur un Mac mini et qui accède à vos fichiers, vos applications et vos sessions. Réservé aux abonnés Max à 200 dollars par mois, le service est pour l'instant sur liste d'attente.

Un assistant qui ne dort jamais

L'idée est plutôt simple sur le papier : installer un agent IA sur un Mac mini qui reste allumé en permanence, connecté à vos données locales et aux serveurs de Perplexity. L'annonce de ce produit a été faite en grande pompe lors de la conférence Ask 2026, dédiée aux développeurs et organisée directement par Perplexity.

Cet agent IA permet de rédiger des mails, préparer des briefs quotidiens, trier et renommer des fichiers, ou analyser des documents, sans intervention de votre part. Tout se pilote depuis Perplexity directement, même à distance.

Histoire d'éviter les problèmes et débordements, des garde-fous ont quand même été mis en place.

Les actions les plus sensibles doivent obligatoirement être validées par l'utilisateur (vous donc, un vrai humain a priori), chaque session est consignée dans un journal d'audit et vous avez même un bouton d'arrêt d'urgence, pour reprendre le contrôle dès que vous le souhaitez. Selon Perplexity, le dispositif est bien plus sécurisé qu'OpenClaw.

Le choix du modèle

L'un des aspects les plus intéressants de Personal Computer, c'est que vous pouvez choisir le modèle d'IA qui fait tourner l'agent. Claude, Gemini ou Grok : à vous de voir lequel colle le mieux à vos besoins.

L'accès est réservé aux abonnés Perplexity Max, facturé 200 dollars par mois, avec 10 000 crédits de calcul inclus. C'est Mac uniquement pour le moment, et il faut passer par une liste d'attente avant de pouvoir essayer.

En parallèle, Perplexity a aussi dévoilé Computer for Enterprise, une version destinée aux professionnels qui connecte l'agent aux outils comme Snowflake, Salesforce ou HubSpot. Et puis une plateforme API avec quatre briques : recherche, agent, sandbox et embeddings. Le tout accompagné de Perplexity Finance, un outil avec plus de quarante sources de données financières en temps réel.

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

Une injection SQL en 2026

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

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

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

46,5 millions de messages et des prompts modifiables

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

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

McKinsey a corrigé en un jour

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

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

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

Source : The Register

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

Du minage de crypto et un tunnel SSH

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

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

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

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

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

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

Des correctifs et de la transparence

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

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

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

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

Source : Axios