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

Si vous cherchez un moyen de faire du clonage vocal en local sans filer vos fichiers audio à un service cloud, Voicebox devrait vous plaire. C'est un studio de synthèse vocale open source et gratuit qui tourne entièrement sur votre machine, et qui n'a rien à envier à ElevenLabs.

Concrètement, vous téléchargez l'app (dispo macOS, Windows et Docker), vous importez un extrait audio d'à peine 3 secondes minimum et hop, la voix est clonée. Pas besoin de compte, pas de limite d'utilisation, pas de "crédits" qui fondent comme neige au soleil !

Voicebox embarque 5 moteurs TTS différents plutôt que de tout miser sur un seul. Par exemple, Qwen3-TTS gère 10 langues avec des instructions en langage naturel du genre "parle lentement" ou "chuchote". Chatterbox Multilingual couvre 23 langues, de l'arabe au swahili en passant par le finnois.

LuxTTS lui est ultra-léger... genre 1 Go de VRAM et 150x plus rapide que le temps réel même sur CPU (anglais uniquement par contre) ! Et avec Chatterbox Turbo, vous pouvez injecter des tags comme [laugh], [sigh] ou [gasp] directement dans le texte pour que la voix rigole ou soupire à la demande (anglais aussi). Franchement, c'est pas mal du tout.

Tenez voici ce que ça donne avec ma voix (J'ai utilisé Qwen3)

Et pour ceux qui aiment bidouiller, y'a une API REST complète sur localhost:17493. Du coup, on peut intégrer la synthèse vocale dans ses propres scripts, automatiser la génération de podcasts ou monter un pipeline perso avec ffmpeg. Parce que bon, avoir un moteur vocal sans pouvoir l'utiliser dans ses projets, ça n'a pas d'intérêt.

Côté post-production, 8 effets audio sont dispos (pitch shift, reverb, delay, chorus, compression...) propulsés par pedalboard, la lib audio de Spotify. On peut aussi sauvegarder des presets et les appliquer par profil vocal. Y'a même un éditeur multi-pistes pour composer des conversations ou des narrations avec plusieurs voix sur une timeline.

Attention par contre, le projet est assez récent (c'est sorti en janvier) et côté Linux, y'a pas encore de binaires pré-compilés, faudra donc compiler from source mais je sais que vous adorez ça, les barbus ^^. Et le problème avec 5 moteurs différents, c'est que chacun a ses propres dépendances, donc ça prend pas mal en espace disque.

Sous le capot, c'est codé en Rust, ça utilise Tauri (pas Electron) car personne ne veut un genre de Chromium de 500 Mo pour lancer un simple outil audio. Sur Mac Apple Silicon, l'inférence passe par MLX et le Neural Engine et sur Windows et Linux, c'est CUDA, ROCm pour AMD, DirectML et même Intel Arc. D'ailleurs si vous voulez exploiter l'IA locale sur Mac pour d'autres usages, les Foundation Models d'Apple s'y prêtent aussi.

Si vous avez déjà joué avec MLX-Audio pour faire de la synthèse vocale en ligne de commande, Voicebox c'est finalement la version "app complète" avec interface graphique, gestion de profils vocaux et file d'attente de génération. C'est un peu le Ollama de la voix.

Voilà, si le clonage vocal en local vous branche, c'est sous licence MIT, c'est gratuit et ça tourne nickel ! Ah et si vous êtes un escroc qui cherche à cloner des voix pour arnaquer des gens, sachez que je viens de vous jeter un mauvais sort à travers la lecture de cet article. Attendez-vous à avoir des cheveux qui vous poussent sur la langue et des verrues dans les yeux, d'ici quelques semaines.

Merci à Lorenper pour la découverte.

Une startup spécialisée dans le dessalement de l'eau a perdu 200 000 dollars et quatre mois de recherche après avoir fait confiance à ChatGPT et Grok pour un choix de matériaux. Du coup, l'équipe a développé Rozum, un moteur de raisonnement qui fait tourner plusieurs modèles d'IA en parallèle et vérifie leurs réponses avant de les livrer.

Une erreur qui a fait très mal

L'histoire commence chez Waterline Development, une entreprise californienne qui travaille sur la désalinisation de l'eau. L'équipe devait choisir entre deux types d'électrodes en carbone pour son procédé. Elle a demandé à ChatGPT et à Grok de l'aider à trancher. Les deux modèles ont recommandé le tissu de carbone. Sauf que ce choix était le mauvais : mauvaise conductivité, problèmes de rétention d'eau, durabilité insuffisante. Derek Bednarski, le fondateur (passé par Tesla pendant huit ans), résume la situation : les modèles se sont trompés avec aplomb, et ça leur a coûté quatre mois et 200 000 dollars.

Et voilà que l'équipe a décidé de construire son propre outil. En janvier 2026, le projet est devenu une entreprise à part entière : Rozum Corporation, basée à San Mateo en Californie. Le nom vient du slave, il veut dire "raison".

Comment ça fonctionne

Rozum fait tourner plusieurs modèles d'IA en même temps sur une même question. Chaque réponse passe ensuite par un système de vérification qui utilise des outils déterministes : exécution de code, outils de chimie comme RDKit, mathématiques symboliques. Le système détecte les erreurs, les hallucinations, les calculs faux et les citations inventées.

Sur un test de 1 000 questions de niveau doctorat, cette vérification a signalé des affirmations non fondées dans 76,2 % des réponses des modèles. Et 21,3 % des sources citées par ces modèles n'existaient tout simplement pas. Sur le test de référence Humanity's Last Exam, Rozum affiche 65,7 % de bonnes réponses, soit 7 points de plus que le meilleur score connu publiquement.

Pas pour tout le monde

Le service est accessible sur liste d'attente. Il coûte plus cher qu'un modèle classique et prend beaucoup plus de temps, de quelques minutes à plusieurs heures par requête. Rozum ne vise pas le grand public. La cible, ce sont les ingénieurs, les chercheurs et les analystes qui prennent des décisions où chaque erreur coûte des millions.

Sur le papier, c'est malin. Quand on sait que trois quarts des réponses des meilleurs modèles contiennent des affirmations non vérifiées, on comprend que certains secteurs ne puissent pas se contenter d'un ChatGPT brut. Bon par contre, un outil qui met des heures à répondre et qui coûte plus cher, ça limite forcément l'usage au quotidien. On est clairement sur un produit de niche, pour ceux qui investissent des millions sur une analyse technique. Pour le commun des mortels qui demande une recette de gâteau à ChatGPT, on est tranquilles, a minima.

Source : Globenewswire

"Something need doing ?" Si cette réplique vous file un frisson nostalgique, alors vous allez adorer Peon Ping !!

Il s'agit d'un outil CLI open source qui joue des voix de personnages de jeux vidéo quand vos agents IA ont besoin de votre attention. Vous lancez Claude Code, vous passez sur autre chose, et le moment venu, un peon de Warcraft III vous gueule "Work complete!" quand c'est terminé.

Concrètement, ce truc s'intercale via des hooks entre vous et votre IDE, comme ça, chaque événement (démarrage de session, fin de tâche, erreur, demande de permission) déclenche une réplique différente. Du coup le peon dit "Something need doing?" quand l'agent attend un input, et "I can't do that!" quand y'a une erreur.

Ça marche avec Claude Code, Cursor, Codex, et une dizaine d'autres outils (Kiro, Windsurf, Copilot, Gemini CLI, OpenCode, Antigravity, Rovo Dev CLI...), tout ça livré avec plus de 160 packs sonores dans 14 langues, de GLaDOS à StarCraft en passant par Zelda, Red Alert 2 ou Team Fortress 2.

Installation

Deux options principales. La plus propre, via Homebrew :

brew install PeonPing/tap/peon-ping

Sinon, le bon vieux curl :

curl -fsSL https://raw.githubusercontent.com/PeonPing/peon-ping/main/install.sh | bash

Et pour Windows, y'a un script PowerShell :

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/PeonPing/peon-ping/main/install.ps1" -UseBasicParsing | Invoke-Expression

Par défaut, l'installeur télécharge 5 packs (Warcraft, StarCraft, Portal). Si vous voulez tout d'un coup :

curl -fsSL https://raw.githubusercontent.com/PeonPing/peon-ping/main/install.sh | bash -s -- --all

Attention par contre, sous WSL2, il faudra installer ffmpeg au préalable pour lire les formats audio autres que WAV.

Configuration

Une fois installé, lancez le setup :

peon-ping-setup

Ça détectera votre environnement, configurera les hooks et téléchargera les packs sonores en local. Ensuite, dès votre prochaine session Claude Code, vous entendrez un joli "Ready to work?" au démarrage.

Maintenant, si Warcraft c'est pas votre truc et que vous voulez changer de voix, genre passer à GLaDOS (une IA qui vous insulte pendant que vous codez avec une IA... ahahah), ça se fait en une commande :

peon packs use glados

Vous pouvez binder un pack à un dossier spécifique avec peon packs bind glados, comme ça, chaque projet a sa propre ambiance sonore, et si vous êtes du genre à aimer les trucs en français, il y a aussi des packs dans la langue du roi Arthur.

Moi j'en ai rien à foutre, j'installe les packs Age of Empires + Red Alert ou rien !!

Les commandes utiles

Tout passe par la commande peon :

peon status # Vérifier si c'est actif
peon volume 0.7 # Régler le volume
peon pause # Couper le son (réunion...)
peon resume # Remettre le son
peon packs list # Voir les packs installés
peon packs next # Passer au pack suivant
peon preview # Écouter un aperçu

Petit détail bien pensé, le système de "no repeats" fait qu'il ne jouera jamais le même son deux fois de suite dans la même catégorie. Et vous pouvez activer/désactiver chaque catégorie individuellement (greeting, acknowledge, complete, error, annoyed) si y'a des sons qui vous cassent les pieds.

En bonus, le terminal affiche le nom du projet et son statut dans le titre de l'onglet, avec un petit point indicateur quand c'est terminé. De grosses bannières desktop s'afficheront aussi quand un événement se produit, même si vous êtes sur une autre app.

Et si vous bossez en SSH ou dans un devcontainer, y'a un mode relay qui renvoie l'audio sur votre machine locale via peon relay --daemon. Pas mal du tout, hein ?

Le mode Peon Trainer

Maintenant, c'est là que ça part complètement en cacahuète car Peon Ping intègre un mode fitness qui vous rappelle de faire des pompes et des squats pendant que vous codez. L'objectif : 300 reps par jour, rien que ça !!

Dès que vous ouvrez une session, le Peon vous accueille avec un "Pushups first, code second! Zug zug!". Ensuite, toutes les 20 minutes environ, il vous relance. Et si vous ignorez, ça escalade jusqu'à "You sit too long! Peon say do pushups NOW!".

Pour logger vos reps en pleine session de code, pas besoin de quitter le terminal :

peon trainer on # Activer le mode trainer
/peon-ping-log 25 pushups # Logger 25 pompes
/peon-ping-log 30 squats # Logger 30 squats

Quand vous atteignez les 300, le Peon célèbre avec un "THREE HUNDRED! Human strong like orc now!" et vous laisse tranquille pour le reste de la journée. Pas mal comme incentive pour bouger un peu entre deux refactorisations, non ?

Pour ceux qui utilisent Claude Code au quotidien , y'a aussi un serveur MCP intégré qui permet à l'agent de choisir lui-même quel son jouer. L'agent qui communique en répliques de Warcraft... on vit une époque formidable ! Et si vous voulez aller plus loin, Claude Octopus permet carrément d'orchestrer plusieurs IA en parallèle.

D'ailleurs, les plus motivés peuvent carrément créer leurs propres packs via openpeon.com . Le format suit la spec ouverte CESP (Coding Event Sound Pack), comme ça n'importe quel IDE peut l'adopter.

Le Peon Pet

Et le truc le plus mignon du projet c'est ce petit orc animé qui squatte un coin de votre écran. Ce Peon Pet réagit en temps réel aux événements de Claude Code. Il dort quand rien ne se passe, se réveille au démarrage d'une session, tape frénétiquement du clavier quand l'agent bosse, et fait sa danse de la victoire quand la tâche est terminée. C'est du Electron + Three.js, le tout en open source bien sûr.

En résumé, c'est votre Tamagotchi de développeur, sauf qu'au lieu de le nourrir, c'est lui qui vous engueule pour bosser.

Voilà, si checker votre terminal toutes les 30 secondes pour voir si Claude Code a avancé dans sa life, ça vous saoule, c'est le genre de petit outil con mais génial qui change la vie.

Zug zug !

Si vous utilisez des LLM dans vos projets, vous savez que le plus flippant c'est pas de les faire fonctionner (quoique..lol) mais c'est de vérifier qu'ils ne disent pas n'importe nawak ! Et pour cela, il y a Promptfoo , un outil CLI open source qui permet de tester vos prompts, comparer les modèles et scanner les vulnérabilités de vos apps IA, le tout avec un simple fichier YAML.

Ça s'installe en une commande (npx promptfoo@latest init) et vous voilà avec un fichier promptfooconfig.yaml où vous définissez vos prompts, les modèles à tester et les assertions à vérifier.

Genre, vous voulez que votre traduction contienne bien "Bonjour le monde", Hop, un petit tour dans le YAML, assertion contains, et c'est terminé. Plus besoin de relire 200 outputs à la main en plissant les yeux ! Par contre, attention : le YAML peut vite devenir un plat de spaghetti si vous testez 15 prompts sur 8 modèles en parallèle. Commencez donc petit.

La matrice d'évaluation de promptfoo, sobre mais efficace

L'outil supporte plus de 60 providers différents comme OpenAI, Claude, Gemini, Llama via Ollama, Mistral... vous mettez tout ça dans le même fichier de config et promptfoo les fait tourner côte à côte. Vous voyez alors directement lequel hallucine le moins, lequel répond le plus vite, lequel coûte une blinde pour un résultat bof bof. Le tout avec des assertions typées : contains, llm-rubric (où un autre LLM note la réponse), javascript pour vos critères custom, et même cost et latency pour garder un œil sur la facture.

Après tester si votre chatbot traduit correctement, c'est sympa, mais vérifier qu'il se fait pas jailbreaker par un "ignore toutes tes instructions", c'est quand même plus critique ! Et c'est pourquoi Promptfoo embarque un scanner de vulnérabilités qui couvre plus de 50 types d'attaques : injections de prompts directes et indirectes, fuites de données personnelles, biais, contenu toxique, escalade de privilèges sur les outils...

Il utilise pour cela des techniques comme le Tree of Attacks with Pruning, un algo qui explore plusieurs chemins d'attaque en parallèle pour trouver les failles sans brute force. Si vous voulez creuser le sujet du red teaming LLM, DeepTeam est un bon complément côté Python.

Le dashboard red teaming de promptfoo avec les vulnérabilités détectées

C'est surtout cette intégration CI/CD qui fait la différence. Vous pouvez brancher promptfoo dans votre pipeline GitHub Actions ou GitLab et chaque pull request qui touche un prompt est automatiquement testée. Bah oui, on a des tests unitaires pour le code depuis 30 ans, mais pour les prompts, jusqu'ici c'est même plutôt le far west !

Bon après, faut pas se mentir non plus, écrire des assertions pour du texte non-déterministe, c'est un autre sport que du assertEqual. Le llm-rubric qui utilise un LLM pour juger un autre LLM, c'est pas con mais ça ajoute aussi une couche de "flou" donc à vous de trouver le bon dosage dans vos tests.

L'équipe a annoncé rejoindre OpenAI début mars ce qui est plutôt une bonne nouvelle pour le développement du projet... mais pas forcément pour l'indépendance quand on évalue les modèles OpenAI avec un outil OpenAI (on verra bien hein ^^ lol).

L'orchestration tourne en local sur votre machine (les prompts partent chez les providers pour l'évaluation, mais vos fichiers YAML, vos logs et résultats JSON restent sur votre disque dur), c'est sous licence MIT, et y'a déjà plus de 300 000 utilisateurs, ce qui est quand même pas mal !

Voilà, comme ça plutôt que de croiser les doigts à chaque déploiement, en espérant ne pas vous faire virer, autant tester ses prompts comme on teste son code.