Comme vous le savez, les LLMs sont assez probabilistes de par leur nature. C'est leur force mais également leur principal problème de sécurité car si votre agent IA a une probabilité de 1% de faire une grosse connerie des enfers par session, sur 100 sessions vous montez à environ 63% de chances qu'il en arrive au moins une.

Heureusement, Agent Safehouse vous permet d'encapsuler votre agent préféré dans un profil sandbox macOS au niveau du kernel afin de réduire drastiquement la surface d'attaque sur votre système de fichiers.

Le principe de base, c'est le deny-default. Tout est refusé par défaut puis des autorisations sont ensuite ouvertes au compte-gouttes : lecture/écriture dans le répertoire du projet, accès lecture seule aux toolchains installés, et les exceptions système nécessaires au fonctionnement (runtimes, homebrew, réseau).

Par défaut, les clés privées SSH et les fichiers de credentials AWS ne sont pas lisibles donc si l'agent essaie d'accéder à ~/.ssh, il se prend une erreur "operation not permitted". C'est une couche de durcissement mais pas une barrière de sécurité absolue puisque le réseau, lui, reste ouvert par défaut, et des variables d'environnement peuvent encore exposer vos credentials. Mais pour tout ce qui est erreurs accidentelles et autres hallucinations destructrices en mode Claude a fumé la moquette, ça permet de leur couper la chique.

Cela repose sur le mécanisme sandbox-exec , l'outil natif macOS qu'Apple a fini par marquer "deprecated" sans vraiment le retirer. Agent Safehouse s'en sert tout simplement comme fondation et y ajoute de la configuration par profil et les intégrations agents par dessus.

Sandbox-exec est en effet le seul mécanisme natif macOS qui s'applique en wrapper arbitraire depuis la ligne de commande, sans avoir besoin de se taper un setup préalable comme on pourrait le faire avec Docker ou une VM.

Et c'est surtout plus léger et plus pratique pour un usage au quotidien donc si vous faites tourner Claude Code ou Codex plusieurs heures par jour, ça peut servir, au moins pour votre tranquillité d'esprit.

L'installation se fait via Homebrew comme ceci :

brew install eugene1g/safehouse/agent-safehouse

safehouse claude --dangerously-skip-permissions

Un maker a transformé une réplique grandeur nature de C-3PO en assistant vocal interactif, et le résultat est franchement convaincant. Sa version du droïde papote, répond à vos questions, et tient même une conversation, le tout sans dépendre du moindre cloud une fois en local.

Le truc tient sur un Raspberry Pi 5 planqué dans la coque dorée du droïde. Un micro capte ce que vous racontez, un moteur de speech-to-text le transcrit, et un LLM local s'occupe de comprendre votre question pour formuler une réponse. Jusque-là, rien de fou c'est même devenu assez classique.

Starcraft2.ai débarque en force pour les joueurs de StarCraft 2 et de Brood War qui voudraient disséquer leurs replays sans bouger de leur navigateur. Le créateur de ce site, qui se présente sous le pseudo de Tomkit, a sorti un analyseur gratuit qui combine un moteur de rendu isométrique et un coach IA.

Vous balancez un fichier .SC2Replay (ou .rep pour Brood War), et chose incroyableuuuh, le site reconstruit votre partie complète en vue isométrique avec mouvement des unités, brouillard de guerre activable / désactivable et heatmaps. Comme ça plus besoin de relancer le client pour mater une partie.

Et le truc qui tue, c'est que vous pouvez aussi partager n'importe quel replay via une simple URL.

L'outil derrière ce projet, c'est sc2reader (la bibliothèque Python de référence pour Starcraft) qui parse intégralement les binaires des replays : Position détaillée des unités, séquence des ordres de construction, économie, kills, tout est extrait du fichier directement.

Le truc cool, c'est évidemment le coach IA. L'outil envoie le contexte de la partie (courbe d'éco, build order, échanges d'unités, résultat des batailles) à Claude, qui sort alors un debrief avec des conseils actionnables. Par exemple, le LLM identifie le type de stratégie déployée (timing attack, macro, all-in, cheese) et balance des recommandations basées sur les standards pro. C'est quand même bien plus utile que tous ces guides génériques qu'on retrouve en ligne.

Puis ce qui est cool avec ce logiciel, c'est aussi le support de Brood War et à où j'écris ces lignes, c'est l'un des seuls analyseurs encore maintenus pour le vieux premier StarCraft . Donc pour ceux qui parmi vous ont encore des replays archivés depuis l'ère du modem 56k, c'est carrément une bonne nouvelle !

Bref, si vous jouez encore à SC2 ou si vous voulez juste mater de beaux replays sans lancer le jeu, c'est par ici .

Datadog Labs vient de sortir pup , un outil CLI codé en Rust qui donne à vos agents IA un accès complet à leur plateforme. L'idée c'est que pendant que Vercel et AWS galèrent de ouf à rendre leurs trucs « agent-friendly », Datadog, lui, dégaine un outil dédié qui expose +200 commandes sur plus de 33 de leurs produits, du monitoring aux SLOs en passant par la sécurité et les incidents.

Côté install c'est du classique, brew tap datadog-labs/pack && brew install pup, puis pup auth login pour le flow OAuth2 avec PKCE.

Plus besoin comme ça de balader vos clés API à vie dans des variables d'env, même si le fallback DD_API_KEY reste là quand même pour d'éventuels cas "headless". Une fois loggué, vous tapez alors par exemple :

pup monitors list

pup metrics query --query="avg:system.cpu.user{*}" --from="1h"

Une IA qui pense que 2026 ressemble à un monde fait de bateaux à vapeur et de vastes réseaux ferroviaires, et qui considère qu'une seconde guerre mondiale est très peu probable... voilà Talkie-1930, le nouveau modèle de langage à 13 milliards de paramètres lancé par Nick Levine, David Duvenaud et Alec Radford (l'un des architectes de GPT-2 chez OpenAI).

LE truc avec ce modèle d'un nouveau genre, c'est qu'il n'a JAMAIS lu un mot écrit après le 31 décembre 1930. Pas de Wikipedia, pas de Reddit, pas de GitHub....et j'en passe.

Si ça vous branche, vous pouvez tester la démo direct sur talkie-lm.com/chat , et les poids sont dispos sur HuggingFace sous licence Apache 2.0 !

Alors pourquoi 1930 et pas 1950 ou 1900 ?

Hé bien tout simplement parce que c'est la date précise à laquelle les œuvres tombent dans le domaine public aux États-Unis. L'équipe a donc pu aspirer 260 milliards de tokens de livres, journaux, périodiques, revues scientifiques, brevets et jurisprudence antérieurs à cette date sans risquer la moindre poursuite légale.

Et c'est là que ça devient amusant parce que quand on demande à Talkie-1930 de décrire le futur, il imagine comme je vous le disais en intro, un monde dominé par les bateaux à vapeur et les trains et c'est logique car c'était l'horizon technologique de son corpus à l'époque. Le modèle considère aussi qu'une seconde guerre mondiale est improbable (il ne connaît évidemment que la Première) et du coup, ça donne un terrain d'expérimentation fascinant pour étudier le raisonnement temporel et la généralisation hors distribution moderne.

L'équipe a publié trois checkpoints : talkie-1930-13b-base (modèle brut), talkie-1930-13b-it (pour le chat) et talkie-web-13b-base (un jumeau d'architecture identique mais entraîné sur FineWeb à titre de comparaison). Cette approche "modèle jumeau" permet par exemple de mesurer précisément ce qui vient de l'architecture vs ce qui vient des données.

Pour la phase de post-training, l'équipe a utilisé Claude Sonnet 4.6 comme juge dans une procédure DPO (Direct Preference Optimization). Ils ont également généré des conversations synthétiques entre Claude Opus 4.6 et Talkie pour le fine-tuning supervisé. Bref, c'est un modèle ultra-vintage entraîné à l'aide de modèles ultra-modernes.

L'équipe travaille déjà sur un système OCR custom pour les documents historiques (les OCR conventionnels n'atteignent que 30% de l'efficacité d'apprentissage face à du texte transcrit manuellement) et vise un modèle de niveau GPT-3 pour l'été 2026, avec un corpus pouvant atteindre plus d'un trillion de tokens.

Bref, Talkie-1930 c'est un projet de recherche assez chouette pour tous ceux qui aiment creuser les LLMs. Le code est sur GitHub sous Apache 2.0, et la démo en ligne marche très bien si vous voulez juste tester sans installer.

Amusez-vous bien !

Source

DOOM a déjà été porté sur des thermostats, des tests de grossesse, et même un piano ! Manquait donc plus que les chatbots IA !

Et voilà que c'est fait puisque Chris Nager vient de faire tourner DOOM dans ChatGPT et Claude, jouable directement dans la fenêtre du chat.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/doom-chatgpt-claude-mcp/doom-chatgpt-claude-mcp-1.qt">lien vers la vidéo</a>.

Une boîte mail avec 12 000 messages non lus (genre 32 par jour pendant un an), c'est pas une vie mais c'est pas une fatalité non plus puisque Lakshay Gupta vient de poster NeatMail . Cet outil est un assistant IA qui labelise vos mails Gmail ou Outlook automatiquement et qui rédige des brouillons de réponse dans votre style d'écriture. Le code est dispo sur Github, auto-hébergeable, mais je reviendrai sur la licence (spoiler : c'est custom)...

L'interface marketing de NeatMail

En gros, vous connectez votre Gmail ou Outlook via OAuth (rien à faire côté mot de passe, et tant mieux vu les fuites récentes via les outils IA ), et NeatMail utilise ensuite OpenAI GPT-4o mini en backend pour classifier chaque mail entrant (avec un taux annoncé de 95% de confiance, mais c'est à voir en pratique).

Comme ça, plutôt que d'attendre que vous traitiez vos messages par batch comme un facteur dépressif, le truc bosse en temps réel ! Un mail arrive, hop, label appliqué et ainsi de suite. Et si le système juge que ça mérite une réponse, il vous prépare un brouillon dans votre ton habituel.

Y'a aussi des trucs qui font la différence avec un simple filtre Gmail. Le système se souvient des conversations passées pour rester cohérent dans les brouillons, vérifie votre calendrier avant de proposer un créneau, et apprend votre style à force de relire ce que vous écrivez. La fonctionnalité de désinscription en un clic balaye aussi les newsletters promo, et il y a même une intégration Telegram qui ping votre téléphone quand un mail vraiment important arrive ("Oh cool encore un mail de mon avocat !").

Le chaos d'une boîte Gmail sans tri auto

Côté code, c'est du Next.js 16 + React 19 pour le front, Hono.js pour le backend, PostgreSQL pour les métadonnées, Redis Upstash pour la déduplication, et Inngest qui orchestre les workflows. Le tout majoritairement codé en TypeScript, avec un Dockerfile prêt à dégainer.

Faut juste vos identifiants Google Cloud, Microsoft Entra et OpenAI à côté pour faire tourner ça chez vous, ce qui n'est pas hyper user friendly à trouver mais reste faisable un dimanche pluvieux si vous avez la niak.

Pour le pricing, NeatMail propose 7 jours d'essai gratuit puis 7 dollars par mois. À comparer donc avec Superhuman qui demande entre 30 et 40 dollars mensuels pour le même genre de service, ou SaneBox qui démarre à 7 dollars mais ne propose pas de rédaction de brouillons par IA.

Sauf que là, le code EST sur GitHub, du coup si vous avez la flemme de payer 84 dollars par an (le prix d'un bon resto en amoureux 😍) et que vous savez configurer un PostgreSQL, vous économisez votre argent et vous gardez la main sur l'infra !

Brouillon de réponse pré-rédigé directement dans Gmail

Après faut quand même garder en tête que NeatMail est encore jeune, et que c'est un projet solo. Et côté licence, c'est pas du MIT pur puisque la licence réelle s'appelle "NeatMail Open Source License". C'est donc de la licence faite maison, avec de l'auto-hébergement autorisé, mais une interdiction complète de revendre une instance ou de monter un business concurrent.

Donc si vous comptiez forker le projet pour monter votre SaaS concurrent, oubliez ça direct, car ce n'est pas autorisé. Côté privacy, le créateur précise qu'aucun contenu de mail n'est stocké en base, mais juste les métadonnées (sachant que les mails passent quand même par OpenAI pour la classification, faut pas se mentir...).

Voilà, je trouve l'idée plutôt sympa. Le code est dispo sur GitHub si vous voulez self-hoster votre boîte mail intelligente, ou comme je vous le disais, y'a la version SaaS sur neatmail.app à 7 dollars par mois pour les flemmards. Carrément moins cher que Superhuman !

Liam Price, 23 ans, mathématicien amateur sans formation avancée, a résolu un problème d'Erdős resté ouvert depuis 60 ans en posant la question à GPT-5.4 Pro un lundi après-midi en avril.

Le modèle a tourné 80 minutes pour produire une preuve qui passe la validation du médaillé Fields Terence Tao. C'est ce que rapporte Joseph Howlett dans Scientific American.

Le problème en question, c'est l'Erdős #1196, posé par le mathématicien hongrois en 1965. L'IA n'a pas tout cassé en force brute. Elle a utilisé la fonction de von Mangoldt, un outil bien connu en théorie des nombres, mais que personne n'avait pensé à appliquer à ce type de question depuis 90 ans.

Tao parle d'une connexion jusqu'ici non décrite entre l'anatomie des entiers et la théorie des processus de Markov. En clair, l'IA a fait un pont entre deux branches mathématiques que les humains avaient laissé séparées.

La méthode est assez simple. Price a copié le problème dans une fenêtre ChatGPT, lancé GPT-5.4 Pro en mode raisonnement, et attendu. Pas de papier brouillon, pas d'allers-retours avec un professeur, pas de café à minuit avec des collègues. Un prompt, une réponse, et un objet mathématique sur lequel des experts du monde entier auront ensuite à se pencher pour valider chaque ligne.

Maintenant il faut savoir que la sortie brute de l'IA était plutôt confuse. Tao et Jared Lichtman, mathématicien à Oxford, ont dû relire, simplifier et reformuler la preuve pour qu'elle devienne lisible.

Sans expert humain pour décanter le résultat, le prompt seul n'aurait probablement pas convaincu une revue scientifique. L'IA a vu la bonne idée, mais pas vraiment su l'expliquer proprement.

Tao reste prudent. Il rappelle que le problème n'était pas le plus dur du livre des Erdős, et que l'IA a surtout gagné en vitesse, pas forcément en profondeur.

Lichtman, lui, parle du premier résultat IA au niveau du livre des Erdős, ce qui reste une marche assez impressionnante. Côté Liam Price, le jeune homme va probablement ajouter une ligne assez folle à son CV. Et le débat sur ce que ça veut dire pour la recherche en mathématiques pures, lui, est désormais lancé pour de bon.

Source : Scientific American

pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.

Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.

Le dashboard bbDump, tout de suite plus respirable que pgAdmin

Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.

Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!

Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée

Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !

Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.

Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.

Côté installation, c'est facile :

curl -fsSL https://poups.dev/bbdump.sh | bash

Vous avez un super GPU de la mort qui tue et vous voulez faire tourner un modèle d'IA en local, mais entre la VRAM dispo, la quantification qui change tout et les 500 modèles existant... c'est tout simplement le bordel pour savoir lequel va passer crèèème sans faire ramer votre machine. On galère tous à tester des modèles au pif en voyant la RAM exploser, mais aujourd'hui on a une solution.

Car c'est exactement le problème que résout llmfit , un outil en Rust qui scanne votre hardware et vous classe les modèles compatibles par score. GPU NVIDIA, AMD, Intel Arc, Apple Silicon, sur macOS, Linux ou Windows, tout y passe ! Sur mon Mac, cette commande détecte instantanément la VRAM unified memory, les cœurs CPU et le type de GPU dans mon système, puis elle passe en revue sa base d'environ 500 modèles HuggingFace pour me dire lesquels tournent chez moi.

L'interface llmfit dans un terminal, sobre et efficace

Du coup, chaque modèle est évalué sur 4 axes : qualité, vitesse, occupation mémoire et capacité de contexte. En fait, le scoring s'adapte à votre usage, si vous voulez du chat rapide, la vitesse pèse plus lourd, et si c'est du raisonnement, c'est la qualité qui prime. À vrai dire, c'est plus malin que de comparer bêtement les paramètres sur la page HuggingFace. Et la quantification est choisie dynamiquement, de Q8_0 (la plus fidèle) jusqu'à Q2_K (la plus compressée), histoire de caser un max de trucs dans votre config.

L'interface par défaut c'est un TUI (une interface dans le terminal) avec navigation à la vim (j/k, /, tout ça) qui affiche un tableau avec les scores dans votre terminal. Pour le mode CLI, y'a llmfit --cli, et pour ceux qui veulent intégrer ça dans un pipeline, un petit llmfit serve et ça lance un serveur REST sur votre machine.

Le truc vraiment sympa je trouve c'est surtout la simulation hardware. Vous appuyez sur S dans le TUI et vous testez d'autres configs sans rien changer à votre machine. Genre "et si j'avais 24 Go de VRAM au lieu de 8 ?". Ça évite d'acheter une nouvelle carte graphique pour rien, quand on peut vérifier en deux secondes que la config actuelle suffit déjà amplement pour son usage quotidien de chat et de génération de petits scripts en local au fil de la semaine. Pas mal non ?

Y'a aussi le mode plan qui fait l'inverse, vous donnez un nom de modèle et l'outil vous dit de quel hardware vous avez besoin. D'ailleurs si vous êtes sur Mac et que l'IA en local vous branche, n'oubliez pas au passage que apfel vous permet de libérer le modèle caché dans macOS.

Côté installation, brew install llmfit sur Mac, scoop install llmfit sous Windows, ou un curl -fsSL https://llmfit.axjns.dev/install.sh | sh partout ailleurs. Une commande, c'est tout. Et ça tourne aussi en Docker !

Le support multi-GPU est également là avec agrégation de la VRAM, et l'outil tient compte des architectures MoE comme Mixtral dans son scoring (ces modèles ne chargent pas tous leurs experts d'un coup, du coup la VRAM nécessaire est plus faible qu'on pourrait croire). L'outil propose aussi 10 thèmes de couleurs, Dracula, Nord, Catppuccin... pour ceux qui ont des opinions sur les palettes de leur terminal.

Par contre y'a un hic, la base est figée à environ 500 modèles embarqués dans le binaire, donc si un nouveau modèle sort demain, faudra attendre la prochaine release. Et disons que les estimations de vitesse sont des ordres de grandeur, pas des valeurs exactes (difficile de faire mieux sans lancer vraiment l'inférence). Mais bon, pour les classiques comme Llama, Qwen, Mistral ou Gemma, c'est bien couvert. Et bien sûr, le projet est open source sous licence MIT, donc c'est chouette comme dirait le hibou (déso, pas déso ^^).

Si llamafile vous avait déjà simplifié le lancement de modèles, llmfit s'attaque au problème d'avant : choisir LEQUEL lancer.

Bref, ça vaut le coup de tester, dites-moi quel modèle ça vous recommande !

9 kilos en moins. Ses meilleurs chronos de sa vie sur 5 et 10 km. Et la meilleure forme depuis au moins une décennie. Voilà le bilan que Derek Wallbank, rédacteur en chef chez Bloomberg, affichait à la veille du marathon de Paris, qu'il a couru hier. Son coach pendant ces douze mois de préparation ? ChatGPT, et rien d'autre.

Wallbank avait déjà tenté un marathon il y a une bonne dizaine d'années, expérience qu'il qualifie de "catastrophe complète". Cette fois, plutôt que de payer un coach humain ou de télécharger un plan générique, il a passé environ une heure à nourrir ChatGPT de son historique complet de coureur : courses passées, allures de référence, blessures, objectifs, contraintes personnelles.

Et c'est là que le truc devient intéressant par rapport aux plans tout faits qu'on trouve en PDF sur n'importe quel blog running : le modèle a produit quelque chose de bien plus structuré, qui s'ajustait semaine après semaine selon ses retours d'entraînement. Sur le papier, c'est un cran au-dessus.

Sauf que voilà, la bestiole a des limites sérieuses. "Il ne va pas vous dire ce que vous devriez faire, ni comment vous devriez vous sentir, ni si vous êtes en surentraînement, ni si vous foncez vers la blessure", expliquait-il avant la course.

Un vrai coach sent quand son athlète commence à tirer la langue. Le modèle de langage, lui, continue à balancer des séances en se fiant uniquement à ce que vous lui dites. Vous tapez "ça va", il vous colle 30 km le samedi.

Autre problème plus vicieux : au bout de plusieurs mois, le plan s'est mis à halluciner. ChatGPT perdait le fil entre ce qui comptait vraiment et le bruit accumulé dans les échanges précédents. Classique des LLM sur les projets longs : plus vous empilez les conversations, plus les infos importantes se diluent dans le contexte.

Wallbank a dû recadrer régulièrement, réinjecter les bons paramètres, rappeler les priorités du moment. Bref, c'est pas magique. "Ce n'est pas un remède miracle, ça ne se gère pas tout seul", résume-t-il.

La course s'est tenue dimanche dernier, remportée chez les hommes par l'Italien Yemaneberhan Crippa en 2h05'18". Wallbank, lui, n'a pas encore rendu public son propre chrono.

Mais il s'est présenté sur la ligne de départ avec 9 kilos perdus, des records personnels battus sur les courtes distances, et pas une blessure malgré les hallucinations du plan. Pas un mauvais retour sur investissement pour un abonnement à 20 dollars par mois.

Bref, un ChatGPT qui vous fait maigrir et battre vos chronos à l'entraînement, c'est déjà pas mal. Pour le verdict sur 42 kilomètres, on attend que l'intéressé parle.

Source : Bloomberg

Des chats en pixel art qui se baladent sur votre dock macOS et qui causent grâce à un LLM local... non vous ne rêvez pas car c'est ce qu'on peut obtenir avec CATAI , qui vous fera adopter 6 matous virtuels avec chacun sa personnalité.

En gros, c'est le Tamagotchi de votre dock, sauf qu'au lieu de biper quand il a faim, il vous cite du Nietzsche. Vous lancez l'app, et hop, un chat orange débarque. Il marche, il mange, il dort, il s'énerve... soit 368 sprites dessinés à la main (c'est devenu assez rare pour le souligner !!). Et quand le dock est masqué, le chat se téléporte directement sur le bord supérieur de votre fenêtre active. Parce que vous le savez, un chat, ça squatte toujours les rebords les plus improbables.

Vous pouvez en coller jusqu'à 6 en même temps, chacun avec sa couleur et son caractère. Le noir (Ombre) est philosophe et vous pose des questions existentielles, le blanc (Neige) s'exprime en vers, le gris (Einstein) vous balance des faits scientifiques et le brun (Indiana) raconte des aventures. De temps en temps, ils miaulent tout seuls dans des bulles pixel art. "Mrrp !", "Prrr...", "ronronronron". Perso, je trouve ça craquant.

Et quand vous cliquez sur un chat, ça ouvre une bulle de discussion connectée à Ollama (le moteur d'IA locale que vous connaissez sûrement). Si vous avez déjà un modèle qui tourne, votre matou vous répond alors avec sa propre personnalité. La mémoire de conversation est même persistante entre les sessions (max 20 messages par chat, pour garder un contexte de conversation raisonnable).

Comme c'est du Swift pur, juste les Command Line Tools suffisent pour compiler le fichier source :

swiftc -O -o cat cat.swift -framework AppKit -framework Foundation

Les extensions Chrome qui promettent de l'IA, ça pullule de ouf et à vrai dire, la plupart se contentent d'envoyer vos données sur un serveur distant. C'est naze ! Heureusement, l'extension Gemma Gem prend le problème à l'envers puisque son modèle tourne directement dans votre navigateur via WebGPU, sans clé API, sans cloud, et vos données ne sortent jamais de votre machine. C'est comme le kir, royal !

Comme c'est pas sur le Chrome Web Store, faudra la builder vous-même... Vous clonez le repo, vous lancez pnpm install puis pnpm build et vous chargez le dossier dans chrome://extensions en mode développeur et ensuite, elle téléchargera le modèle de Google (environ 500 Mo pour la version légère, genre le poids d'un gros jeu mobile), et pif paf pouf, ensuite vous aurez un agent IA qui vit sa best life dans votre Chrome.

Cliquez alors sur l'icône en bas à droite, une fenêtre de chat s'ouvre et vous pourrez interroger n'importe quelle page. Et si vous préférez un modèle plus costaud, l'E4B pèse 1,5 Go et permet d'obtenir des réponses plus fines.

Sauf que c'est pas juste un chatbot de plus. En effet, l'extension fait du tool calling en boucle à l'aide de 6 outils : read_page_content, click_element, type_text, scroll_page, take_screenshot et run_javascript. Elle peut ainsi lire une page, cliquer sur des boutons, remplir un formulaire et même balancer du JavaScript dans le contexte de la page.

Comme l'inférence WebGPU ne peut pas tourner dans un service worker Chrome (y'a pas d'accès au GPU, c'est une limitation connue depuis des années), le développeur a trouvé une parade : il utilise un offscreen document, c'est-à-dire une page HTML invisible que Chrome maintient en arrière-plan et qui, elle, a accès au GPU. Résultat, le modèle calcule dans cette page fantôme, le service worker joue le facteur entre les morceaux, et le content script affiche le chat. Je trouve ça bien pensé comme découpage !

Toute la boucle d'agent (le code qui décide quand appeler un outil et quand répondre) est isolée dans un dossier agent/ sans aucune dépendance Chrome. Cela veut dire que vous pouvez prendre ces 5 fichiers .ts (agent-loop.ts, prompt-builder.ts, tool-parser.ts, types.ts et index.ts), les coller dans un projet Node.js ou Deno, et hop, vous avez votre propre boucle agentique. Yaniv Kessler, le développeur a pensé le truc pour que ça serve ailleurs.

Les deux variantes (E2B et E4B) sont compressées en q4f16 avec 128K tokens de contexte en théorie, même si en pratique la fenêtre effective dépend de votre VRAM. Cela dit, c'est largement de quoi avaler une page web complète sans broncher ! Et le modèle reste en cache après le premier téléchargement, du coup au deuxième lancement, c'est quasi instantané. Par contre, si vous êtes sur un vieux Chromebook avec un Intel UHD intégré et 4 Go de RAM, ça risque de mouliner à fond. Et sur Firefox (qui est le meilleure navigateur du monde, comme je n'ai de cesse de vous le dire), le WebGPU est encore un peu expérimental, donc pour l'instant ce sera Chrome ou rien... Sniiif.

Si vous avez déjà testé des extensions comme Localsumm qui faisaient tourner Phi-3 en local pour résumer des pages, disons que Gemma Gem pousse le concept beaucoup plus loin avec ses capacités d'agent. Et si le sujet de l'IA locale dans le navigateur vous branche, jetez un oeil à Clippy qui fait tourner des LLM localement sur votre desktop.

Notez quand même que sur Hacker News, le projet a déclenché pas mal de débat. Certains pointent le risque du tool run_javascript qui donne au modèle les pleins pouvoirs sur le DOM (genre, supprimer des trucs ou poster un formulaire à votre place). C'est vrai que c'est important mais bon, c'est le même modèle de permissions que n'importe quel script web classique, sauf que là au moins vos données restent chez vous.

Bref, 500 Mo de modèle, pas de cloud, et votre navigateur qui devient plus autonome que votre fils de 22 ans. Pas mal non ?

J'sais pas si vous saviez mais Apple a planqué un LLM dans votre Mac et ne veut pas que vous y touchiez... enfin, pas directement. En effet, leur modèle est là, intégré au système via le framework FoundationModels, il tourne sur le Neural Engine sans connexion internet mais Apple l'a verrouillé derrière Siri. Du coup, impossible de l'appeler depuis un script ou un pipe shell et c'est là qu' apfel intervient !

L'outil s'installe en une commande :

brew install Arthur-Ficial/tap/apfel

Et hop, vous avez accès au modèle directement depuis votre terminal. Faut Apple Intelligence actif également, sinon, ça ne fonctionnera pas.

Ensuite, vous lui posez une question, et il vous répond. Vous lui "pipez" un fichier, et il le traite. Et le tout sans rien télécharger puisque le modèle est déjà sur votre machine !

C'est un LLM de 3 milliards de paramètres, quantifié en 2 et 4 bits, qui tourne nativement sur la puce Apple Silicon (M1 et au-delà) et il se défend plutôt bien face à Qwen-2.5-3B, si on en croit les benchmarks. La fenêtre de contexte est limitée à 4096 tokens (entrée + sortie combinées), soit environ 3000 mots, donc faut pas espérer lui faire digérer un roman mais pour transformer du texte, classifier des données ou résumer un paragraphe... ça fait bien le taf.

Apfel expose donc ce modèle de trois façons différentes. En CLI pure (compatible stdin/stdout, sortie JSON, codes d'erreur propres), en serveur HTTP compatible OpenAI sur localhost:11434 (avec streaming SSE, tool calling et CORS activé), et en chat interactif multi-turn.

Le serveur OpenAI c'est malin parce que d'un coup, tous vos outils savent causer à l'API OpenAI (Cursor, Continue.dev, n'importe quel SDK) et peuvent utiliser l'IA locale de votre Mac sans rien changer à leur code. Et le support MCP (Model Context Protocol) natif c'est très chouette aussi puisqu'il suffit de lancer apfel avec le flag --mcp, pour qu'il découvre automatiquement les outils disponibles, exécute les appels et renvoie les résultats.

D'ailleurs côté vie privée, c'est du béton armé car le framework FoundationModels d'Apple n'a pas accès à vos contacts, emails, calendrier ou photos et tout tourne sur le Neural Engine et le GPU, sans connexion internet.

Si vous avez déjà bidouillé avec Ollama et les modèles locaux , apfel c'est un peu la même philosophie... sauf que là vous n'avez rien à télécharger et contrairement à Perspective Intelligence qui transforme votre Mac en serveur web avec PostgreSQL et tout le tralala, apfel reste hyper minimaliste.

Attention quand même, faut être sous macOS 26 Tahoe minimum donc si vous êtes encore sous Sequoia 15.x ou Ventura 13.x, c'est mort, le framework FoundationModels n'existe pas sur ces versions. Et si vous avez un Mac Intel... ben non plus, le Neural Engine c'est Apple Silicon only.

Le projet inclut aussi des scripts démo sympas dans le dossier demo/.

Y'a par exemple cmd qui convertit du langage naturel en commandes shell, explain qui décortique les messages d'erreur, gitsum qui résume vos commits récents, ou encore mac-narrator qui commente l'activité de votre système en temps réel (c'est votre Mac qui se raconte à lui-même).

Perso, cmd c'est celui qui m'a le plus plu, même si bon, avec 4096 tokens de contexte, faut pas lui demander des commandes ffmpeg de 200 caractères.

Mais au-delà des démos, c'est en vrai que ça devient fun. Je vous montre quelques usages classiques d'abord :

apfel -f README.md "Résume ce projet en 3 phrases"

apfel -f code.py -s "Tu es un développeur expérimenté" "Trouve les bugs"

echo "Traduis ça en allemand : Salut" | apfel

Et les trucs un peu plus funs :

git diff HEAD~1 | apfel -f CONVENTIONS.md "Review ce diff par rapport à mes conventions"

apfel -f old.swift -f new.swift "Qu'est-ce qui a changé entre ces deux fichiers ?"

demo/oneliner "compte les IPs uniques dans access.log"

Vous pouvez même piper la sortie en JSON pour chaîner avec jq, ou lancer le mode --serve et brancher Cursor dessus pour avoir de l'autocomplétion locale gratuite. Et si vous êtes du genre parano, le mode --chat avec --context-strategy summarize gère automatiquement le contexte quand la conversation dépasse les 4096 tokens.

Et côté écosystème, y'a aussi apfel-gui (une interface SwiftUI native pour chatter avec le modèle, avec speech-to-text et text-to-speech on-device) et apfel-clip qui est en développement (ce sont des actions IA qui s'ajoutent dans la barre de menus pour corriger la grammaire, traduire, résumer) et le tout sous licence MIT, évidemment.

Bref, c'est un super modèle mais avec 3 milliards de paramètres et 4096 tokens de contexte, faut pas s'attendre non plus à remplacer Claude ou GPT. Les maths complexes, la génération de code avancée et les longues conversations, c'est pas son truc mais pour du scripting, de la classification ou transformer du texte à la volée... ça dépanne carrément !

Et ce modèle préfère refuser plutôt qu'halluciner, ce qui est plutôt une bonne surprise je trouve. Voilà, si vous avez un Mac Apple Silicon sous macOS Tahoe, apfel et ses outils valent le coup d'œil pour vos petites tâches IA basiques / rapides de tous les jours.

Vous faites tourner des LLMs en local comme le gros fifou de Hipster IA que vous êtes et, Ô drame, la VRAM de votre ordinateur explose dès que le contexte dépasse 8000 pauvres malheureux tokens ?

Le problème c'est le KV cache les amis ! Le KV cache c'est ce truc qui stocke les clés et valeurs d'attention et qui grossit linéairement avec la longueur du prompt. C'est pour gérer ce problème que Google a annoncé sous la forme d'un whitepaper uniquement un algo qui compresse tout ça de 3,8 à 6,4 fois... et youpi pour nous, y'a un dev qui l'a déjà implémenté dans un fork de llama.cpp .

Concrètement ça donne :

llama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa on

Et vous venez de diviser la mémoire du cache par 4,6. Et voilà comment un énoooorme Command-R+ de 104 milliards de paramètres arrive à tourner à 128K tokens de contexte sur un MacBook M5 Max, avec un pic mémoire max de 74 Go.

Pour bien comprendre pourquoi c'est costaud, faut revenir au problème de base. En fait quand un LLM génère du texte, il stocke pour chaque token passé 2 vecteurs (la clé K et la valeur V) dans un cache. Plus le contexte est long, plus ce cache grossit. Et ça s'accumule vite... Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 bouffe à lui seul plus de 40 Go de RAM. Du coup votre modèle Llama 3.1 ou Qwen3 rentre évidemment en mémoire, mais le cache, lui, fait tout déborder comme vous quand vous vous incrustez dans la mini piscine Intex des gosses.

Google a publié son papier TurboQuant fin mars et leur idée c'est de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans ré-entraîner le modèle. En fait l'algorithme fait ça en deux étapes...

D'abord PolarQuant : on applique une rotation Walsh-Hadamard aux vecteurs pour "gaussianiser" leur distribution, genre transformer des données qui partent dans tous les sens en une forme bien ronde et prévisible.

Puis on convertit les coordonnées cartésiennes en coordonnées polaires, rayon + angle. Le rayon capture alors l'essentiel de l'information, et l'angle se compresse très bien parce que sa distribution est connue à l'avance.

Ensuite, deuxième étape, QJL (Quantized Johnson-Lindenstrauss) : Il s'agit d'un correcteur d'erreur à 1 bit qui élimine le biais résiduel, le tout sans overhead mémoire pour les constantes de quantification, contrairement aux méthodes classiques comme q4_0 ou q5_1 qui perdent 1-2 bits rien qu'en stockant leurs propres paramètres.

Et c'est là qu'intervient notre développeur de génie, TheTom, qui a pris ce document académique de Google et l'a transformé en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Et c'est pas juste un portage bête et méchant puisqu'il a vraiment poussé les expériences bien au-delà du document original avec une couverture de tests de 100% et des benchmarks sur des modèles de 1.5 à 104 milliards de paramètres.

Et ses découvertes les plus intéressantes c'est justement ce qui n'est PAS dans le paper. Première trouvaille : la compression des valeurs V est gratuite. Compresser V à 2 bits sur Qwen, Llama, Mistral ou Command-R+ n'a aucun impact mesurable sur la qualité d'attention, tant que les clés K restent en q8_0.

Et cela a été confirmé sur Metal M5 Max 128 Go, CUDA RTX 4090 et RTX 3090 par plusieurs testeurs indépendants. C'est franchement contre-intuitif, mais cela veut dire que toute la dégradation de qualité vient de la compression des clés K, et pas de leurs valeurs. Du coup une config asymétrique (K en q8_0, V en turbo3) arrive à récupèrer des modèles où la compression symétrique échoue.

Deuxième trouvaille : les couches limites sont hypersensibles. Protéger les 2 premières et 2 dernières couches en q8_0 pendant qu'on compresse le reste en turbo2 permet de récupérer jusqu'à 91% de la perte de qualité. Et plus le modèle est gros, mieux ça marche. C'est seulement 15 lignes de code, et là encore, y'a aucun impact sur la vitesse.

Troisième trouvaille : Sparse V, un décodage du cache qui saute les positions V à faible poids d'attention permet de gagner environ 23% de vitesse de décodage à 32K tokens de contexte. Et zéro dégradation de la qualité.

Côté chiffres bruts, y'a 3 modes : turbo4 compresse 3.8x et le modèle répond quasi pareil qu'avant. turbo3 compresse 4.6x avec une perte de qualité à peine détectable. turbo2 pousse à 6.4x mais là faut l'utiliser malin (uniquement sur les valeurs V, pas les clés K).

Et dire que pour l'instant Google n'a toujours pas publié de code officiel (mais c'est prévu pour le second trimestre 2026)... Donc pour le moment, cette implémentation communautaire est le seul moyen de tester TurboQuant dans un fork llama.cpp. Ça tourne sur Apple Silicon M1 à M5, NVIDIA RTX 3080 Ti à 5090 et AMD 6800 XT / 9070 XT et visiblement, pas mal de monde a testé sur du matériel varié et les résultats sont au rendez-vous.

Donc voilà, si vous faites de l' inférence LLM locale et que la mémoire vous limite, c'est le moment de tester ça !

Une faille découverte dans l'extension Chrome de Claude permettait à n'importe quel site web d'injecter silencieusement des prompts dans votre assistant IA. Pas besoin de cliquer, pas besoin de permission... non, fallait juste visiter une page web et c'était réglé. Le chercheur Oren Yomtov de Koi Security à l’origine de cette découverte, a baptisé ça "ShadowPrompt" et vous allez voir, c'est dingue.

En fait, cette attaque enchaînait deux failles. La première, c'est que l'extension acceptait les messages de n'importe quel sous-domaine en *.claude.ai, car Anthropic avait mis en place un allowlist trop permissif. Sauf qu'Arkose Labs, le fournisseur de CAPTCHA, hébergeait un composant sur a-cdn.claude.ai et malheureusement, ce composant contenait une jolie faille XSS bien classique. Celui-ci acceptait les postMessage sans vérifier l'origine, et le texte reçu était ainsi injectable via un dangerouslySetInnerHTML . Donc y'a bien ZERO validation côté client. Ouééééé !

Un attaquant n'avait qu'à embarquer ce composant CAPTCHA vulnérable dans une iframe cachée sur son site, envoyer un payload via postMessage, et hop, le script injecté pouvait balancer un prompt directement à l'extension. Elle le recevait depuis un domaine *.claude.ai, donc elle l'acceptait les yeux fermés et l'affichait alors dans la sidebar comme une requête légitime de l'utilisateur. La victime ne voyait strictement rien.

Et les dégâts potentiels ne sont clairement pas anecdotiques ! Avec cette technique, un attaquant pouvait voler vos tokens d'accès Gmail, exfiltrer des documents Google Drive, lire tout l'historique de vos conversations avec Claude, et même envoyer des mails en votre nom. Perso, ça fait beaucoup pour un simple onglet ouvert dans Chrome, quoi.

Une nouvelle méthode d'attaque cible les IA de développement comme Copilot. En publiant de la documentation empoisonnée, des hackers trompent les modèles pour qu'ils recommandent des bibliothèques malveillantes. Cette menace invisible pour la sécurité est indétectable par les outils classiques.

Le concept est d'une simplicité désarmante. Plus besoin d'injecter du code malicieux dans un dépôt GitHub ou de trouver une faille zero-day complexe. Il suffit désormais de publier de la documentation technique faussée sur des forums, des wikis ou des fichiers README publics. Ces textes, une fois ingérés par les grands modèles de langage (LLM), deviennent une source de vérité pour l'IA qui assiste les développeurs au quotidien.

Le mécanisme de l'injection indirecte

Le problème est en fait dans la confiance aveugle que les modèles accordent aux données d'entraînement. En décrivant une solution technique qui utilise un paquet spécifique — mais malveillant — l'attaquant s'assure que l'IA proposera ce nom lors d'une requête de génération de code. C'est ce qu'on appelle l'injection de prompt indirecte. Le développeur, pensant gagner du temps, valide la suggestion et installe un composant compromis sans vérification préalable.

Le typosquatting passe au niveau supérieur

Cette technique facilite grandement le typosquatting. Auparavant, un attaquant devait espérer qu'un humain fasse une faute de frappe en saisissant une commande. Aujourd'hui, c'est l'IA qui commet l'erreur pour lui, influencée par des références empoisonnées trouvées sur le web. Comme l'IA présente la solution avec une assurance pédagogique, le sens critique de l'utilisateur baisse d'un cran. Le malware n'est plus dans la documentation, il arrive dans la machine au moment où le développeur exécute la suggestion générée.

Un défi pour la cybersécurité logicielle

La difficulté majeure est que cette attaque est purement textuelle. Les outils de scan de vulnérabilités cherchent du code dangereux, pas des explications trompeuses en langage naturel. Tant que les modèles d'IA ne sauront pas distinguer une documentation légitime d'une tentative de manipulation sémantique, la chaîne d'approvisionnement logicielle restera vulnérable à cette forme de gaslighting numérique. La sécurité repose désormais sur la véracité de l'information ingérée par les machines.

On atteint ici les limites de l'automatisation du développement. Faire confiance à un LLM pour choisir ses dépendances est devenu un risque de sécurité majeur. Cette faille montre que le maillon faible n'est plus seulement l'humain qui tape du code, mais l'outil qui lui souffle les réponses. On risque de voir apparaître des systèmes de vérification de réputation de documentation.

Source : The Register

Des chercheurs de l'université de Californie du Sud viennent de publier une étude improbable : demander à un modèle d'IA de jouer les experts dégrade ses performances sur les tâches factuelles. Commencer un prompt par "Tu es un expert en programmation" produit de moins bons résultats que de poser la question directement.

Le piège du "tu es un expert"

L'étude, intitulée "Expert Personas Improve LLM Alignment but Damage Accuracy", a mesuré l'impact des instructions de rôle sur les réponses des modèles de langage.

Sur le benchmark MMLU, qui teste les connaissances générales et le raisonnement, les modèles avec une persona d'expert ont obtenu 68 % de bonnes réponses contre 71,6 % sans aucune instruction de rôle.

La baisse est constante sur toutes les catégories testées : maths, code, sciences, culture générale. Bref, dire à une IA qu'elle est brillante la rend un peu moins brillante.

Quand ça marche quand même

Par contre, le persona prompting fonctionne très bien pour un autre type de tâches : la sécurité et l'alignement. En attribuant un rôle de "moniteur de sécurité" au modèle, les chercheurs ont augmenté le taux de refus d'attaques de 53,2 % à 70,9 %, soit une hausse de 17,7 points. Pour les tâches d'écriture et de mise en forme, les personas aident aussi.

L'explication est assez logique : quand on colle un rôle d'expert au modèle, il bascule en mode "suivi d'instructions" et mobilise moins de ressources pour aller chercher les faits dans ses données d'entraînement. Aucune connaissance n'est ajoutée, on déplace juste l'attention du modèle.

Le bon réflexe à adopter

Les chercheurs de l'USC proposent un outil baptisé PRISM qui active automatiquement les personas uniquement quand c'est utile. Mais en attendant que ce genre de système soit intégré aux chatbots grand public, la recommandation est simple : si vous avez besoin de réponses factuelles ou de code, posez votre question directement sans ajouter de rôle.

Si vous voulez que l'IA respecte un ton, un format ou des consignes de sécurité, le persona prompting reste la bonne approche.

On a quand même passé deux ans à répéter partout qu'il fallait commencer ses prompts par "Tu es un expert en..." pour avoir de meilleurs résultats. Visiblement, c'était un peu du vent.

Source : Search Engine Journal

Si vous êtes comme votre blogueur préféré (hi hi) et que vous avez des tonnes de fichiers markdown qui traînent dans des dossiers obscurs depuis des années, voici l'outil parfait pour rendre tout ceci à nouveau utilisable dans la vraie vie.

En tout cas, c'est plus pratique qu'un grep !

Ça s'appelle QMD (Quick Markdown Search) et c'est un outil en ligne de commande dispo sur GitHub qui va indexer tout votre bazar de notes pour les rendre consultables rapidement. QMD combine la recherche plein texte classique (BM25) avec de la recherche vectorielle sémantique et du re-ranking via LLM, ce qui veut dire que c'est ultra puissant. On est un peu sur le même principe qu'un RAG en fait puisque l'IA locale est utilisée pour comprendre le sens de votre requête et pas juste chercher des chaînes de caractères bêtes et méchantes. J'utilise depuis un petit moment maintenant un système similaire avec LEANN pour indexer tous les articles de korben.info et retrouver des connexions entre mes contenus, et je peux vous dire que quand on goûte à la recherche sémantique, le bon vieux grep a un goût de carton.

L'outil est même capable de faire de l'expansion de requête (Query Expansion) pour deviner ce que vous cherchez vraiment.

Techniquement, ça tourne avec bun ou npm et ça s'appuie sur node-llama-cpp pour faire tourner des modèles GGUF directement sur votre machine. Tout reste chez vous donc niveau vie privée c'est nickel. C'est un peu la même philosophie que des outils comme Khoj ou Blinko dont je vous ai déjà parlé, mais en version CLI pour le terminal.

L'installation est hyper facile si vous avez déjà Bun, mais prévoyez quand même un peu de place (environ 3 Go) pour les modèles qui iront s'installer au chaud dans ~/.cache/qmd/models/ et installez sqlite si vous êtes sur macOS :

brew install sqlite # Pour macOS
npm install -g @tobilu/qmd

qmd collection add ~/mes-notes --name notes
qmd embed # L'étape indispensable pour générer les vecteurs