VoxDrop , ma petite app de dictée vocale qui tourne 100% en local sur Mac, passe en version 1.1. Et le gros morceau de cette release, c'est le grand ménage que j'ai fait dans les moteurs de reconnaissance vocale.

Le nouveau venu, c'est donc le moteur d'Apple intégré à macOS 26. Il ne pèse rien à télécharger (0 Mo car il est carrément intégré au système), il gère une tonne de langues et il transcrit quasi en temps réel. Perso, c'est devenu mon préféré et je dicte avec tous les jours depuis des jours ! Seul hic, attention, faudra macOS 26, donc si vous êtes encore sous Sequoia, celui-là vous passera sous le nez.

Du coup j'ai viré Voxtral et Qwen, dont le gain n'était pas dingue, et j'ai mis du lourd à la place : Canary 1B de NVIDIA (le grand frère de Parakeet) et Cohere Transcribe. Ces deux-là squattent le haut du classement des meilleurs modèles de reconnaissance vocale, côté précision donc vous êtes servis !

Le principe, lui, ne bouge pas, vous appuyez sur votre raccourci (⌥+Espace par défaut), vous parlez, et hop, le texte arrive directement là où se trouve votre curseur. Et maintenant, VoxDrop sait aussi transcrire vos fichiers audio ET vidéo par simple glisser-déposer, sur la fenêtre ou sur l'icône dans la barre de menu et identifie même les locuteurs (qui parle, et quand) dans vos enregistrements.

Maintenant, oui, je sais, c'est un outil uniquement macOS parce que j'exploite au maximum les capacités de l'OS d'Apple (CoreML, MLX...etc) pour vous proposer l'expérience la plus rapide qui soit en termes de Speech To Text. Je pourrais porter VoxDrop sous Linux et Windows mais je ne ferais pas mieux que d'autres outils comme Murmure ou Handy qui font très bien le job sur ces OS.

J'ai codé cet outil parce que j'étais frustré par les autres apps que je trouvais peu réactives et là je m'en sers tous les jours, notamment pour dicter mes emails, mes articles et discuter avec Claude Code. C'est instantané et ça me fait gagner un temps de dingue !

VoxDrop peut aussi reformuler ou traduire votre texte en local toujours via Apple Intelligence, en plus du modèle de traduction maison déjà embarqué depuis la version précédente (TranslateGemma). Et j'ai rajouté tous les petits trucs qui changent la vie, comme la suppression automatique des « euh » et autres hésitations pour avoir un texte propre, et j'ai mis aussi le fonctionnement capot fermé du MacBook quand vous bossez sur un écran externe ainsi qu'un dictionnaire de substitutions qui corrige les variantes de vos termes, et un démarrage plus rapide grâce au préchargement du moteur.

Encore une fois, la perf sur cet outil c'est mon obsession.

J'ai aussi corrigé pas mal de bricoles que vous m'aviez remontées, l'espace parasite en début de phrase, le support des AirPods, les raccourcis clavier qui déconnaient et plein de petits gains de stabilité.

Comme pour la version précédente , VoxDrop reste réservé à mes abonnés Patreon. Alors pourquoi pas sur l'App Store ou en open source ? Parce que les deux, c'est un job à plein temps, c'est gérer des clients et du SAV d'un côté, des pull requests et des contributeurs de l'autre. J'ai pas le temps, et franchement pas l'envie.

Je code des outils pour moi depuis l'époque de RockXP, depuis le début des années 2000 et j'en ai profité l'année dernière pour mettre au point un système de licence Patreon maison que j'implémente dans tous mes outils. Comme ça, je développe ce qui me plaît quand je veux pour moi, et ceux qui me soutiennent y ont aussi accès directement, sans pub, ni intermédiaire. C'est un genre de bonus pour mes Patreons quoi...

D'ailleurs, VoxDrop n'est pas mon seul joujou du genre, y'a aussi Evapor8 qui efface le watermark des images générées par Gemini, sous la même licence. Mais ça, je vous en reparle très vite !

Bref, si vous êtes déjà sur mon Patreon , la 1.1 vous attend. Et sinon, vous savez quoi faire. 🙏

Ps : Je mets à jour le site de VoxDrop prochainement, et je vais aussi modifier le nom de l'app car depuis que je l'ai sortie en 2025, y'a eu des copycats qui sont arrivés avec le même nom donc je vais changer ça rapidement pour leur couper l'herbe sous le pied.

Neuf failles de sécurité viennent d'être corrigées d'un coup sur le serveur X.Org, le vieux logiciel qui dessine les fenêtres, gère la souris et le clavier sur une grande partie des machines Linux. Et le plus marquant, c'est qui les a trouvées.

Huit des neuf ont été repérées par une intelligence artificielle. Plus précisément par TrendAI, l'outil maison du programme de chasse aux bugs de l'éditeur de sécurité Trend Micro, la Zero Day Initiative, qui rémunère depuis des années la découverte de failles. La neuvième, elle, a été dénichée à l'ancienne par Peter Hutterer, un développeur de Red Hat qui travaille sur la gestion clavier et souris de X.Org depuis bien longtemps.

Dans le lot, on retrouve surtout deux familles de problèmes bien connues. Des dépassements de mémoire tampon d'abord, où le programme écrit plus de données que prévu dans une case mémoire et le surplus déborde sur le code voisin. Et des "use-after-free" ensuite.

Ce dernier type est vicieux : le logiciel continue d'utiliser un bout de mémoire qu'il a pourtant déjà rendu au système, ce qui permet à un attaquant de glisser son propre code à la place. Trois des neuf failles tombent dans cette catégorie, planquées dans le composant qui synchronise l'affichage.

Le reste touche un peu partout : la gestion du clavier, les alias de polices, la couche graphique 3D, l'économiseur d'écran et le sous-système qui parle directement à la carte graphique, autant de morceaux qu'un programme malveillant déjà présent sur la machine pourrait détourner pour s'octroyer plus de droits que prévu ou aller lire de la mémoire qui ne le regarde pas.

Les correctifs sont déjà là. X.Org a sorti du coup les versions 21.1.23 du serveur et 24.1.12 de XWayland, la passerelle qui fait tourner les vieilles applications X.Org sur les bureaux Wayland modernes. Si vous êtes sur Linux, la mise à jour s'impose.

Côté historique, ça fait plus de dix ans que la sécurité de X.Org traîne une sale réputation. Un chercheur avait résumé l'affaire d'une formule restée célèbre : c'est pire que ça en a l'air. Le code est vieux, tentaculaire, et personne n'a vraiment envie de le réécrire.

Ce qui change cette fois, c'est la méthode. Lâcher une IA sur une base de code aussi ancienne, c'est un peu comme passer un détecteur de métaux sur une plage que personne n'a jamais ratissée : elle remonte des objets que plus personne n'avait le courage d'aller chercher à la main. Et X.Org n'est pas un cas isolé, le noyau Linux voit lui aussi défiler les failles à bon rythme.

Bref, si les IA se mettent à éplucher tout le vieux code de l'open-source, on n'a pas fini d'en voir passer cet été. Tant mieux qu'elles soient dans notre camp.

Source : Phoronix

Je suis trop content parce qu'avec son nouveau SDK pour extensions , Ableton nous permet enfin d'écrire nos propres outils pour son DAW Live en JavaScript. L'intérêt c'est que ces extensions peuvent lire et modifier vos Sets : pistes, clips, notes MIDI, paramètres, automations... et comme ça votre projet se transforme en un truc qu'on peut trafiquer avec du code (et donc avec de l'IA car ça repose sur des technos web standard ^^ niark niark).

En pratique, une extension peut renommer tous vos clips d'un coup, transformer une photo en mélodie MIDI, découper un beat tout seul, ou carrément faire tourner un petit jeu dans Live. Vous faites un clic droit dans le Set, ça s'exécute, et hop, c'est plié !

Par contre, ça ne remplace pas Max for Live puisque Max tourne en temps réel en agissant sur le son des synthés et des effets alors que les Extensions, elles, se lancent d'un clic droit, font leur boulot, puis s'arrêtent. Ce n'est donc pas du temps réel. C'est juste fait pour automatiser et bidouiller la structure d'un projet mais c'est ce qui fait que les deux se complètent bien.

Screenshot

Pour vous lancer, il faut Node.js, être à l'aise avec le terminal, et toute la doc est sur GitHub . Ableton a même sorti une vidéo qui montre comment créer sa première extension de bout en bout.

J'ai testé en le branchant avec Claude Code, et je lui ai demandé de me faire un morceau french electro du thème d'Indiana Jones et voilà ce que ça m'a sorti from scratch (j'ai juste mis un kit rock pour les drums car sinon, y'avait pas de son sur la piste) :

Maintenant, c'est réservé à Live 12 Suite (Beta), soit le haut de gamme du logiciel, donc sur Standard ou Intro, c'est mort. Ensuite c'est de la bêta, donc c'est pas encore 100% complet... Et n'oubliez pas que c'est du JavaScript tiers qui s'exécute dans Live avec un accès à votre projet, donc ça peut toujours faire des dégâts. Évitez donc d'installer un truc random trouvé sur Discord, car ce serait un peu comme quand vous lanciez des VBScript reçus par mail à la grande époque de Windows 98. Surtout que du code pondu par une IA peut aussi cacher quelques saloperies sans que ça se voie, donc vérifiez toujours d'où ça vient et lisez le code.

Quoi qu'il en soit, si vous êtes sur Live 12 Suite, foncez tester et surtout amusez-vous bien !

Tejas Chopra, ingénieur senior chez Netflix, a bricolé un petit logiciel appelé Headroom qui s'attaque à un poste de dépense devenu douloureux dans toutes les boîtes qui carburent à l'IA : la facture en tokens, ces unités que les modèles de langage facturent au passage et qui correspondent en gros à des morceaux de mots.

Son constat de départ est sévère. Près de 90% de ce qu'on balance à un grand modèle de langage, le type d'IA qui fait tourner ChatGPT, serait selon lui de la redondance pure, du remplissage que la machine paie au prix fort sans en tirer la moindre valeur.

Headroom s'installe comme un proxy, c'est-à-dire un intermédiaire qui se glisse entre votre machine et l'IA, et il tourne en local sur le port 8787. Avant que la moindre requête ne file vers le modèle, il intercepte tout ce qui gonfle le contexte, l'historique de conversation, les logs (les journaux d'activité techniques de la machine), les sorties d'outils, les bouts de documentation que le système a jugés utiles, et il compresse l'ensemble.

Un routeur devine d'abord le type de contenu, puis l'envoie vers le bon compresseur. Du code part vers un module qui le réduit à sa structure logique, son arbre syntaxique si vous voulez. Le JSON et le HTML, eux, passent à la moulinette pour virer tout le code de remplissage répétitif.

Et si le modèle réclame finalement la version complète ? Headroom garde les originaux de côté dans une petite base locale, Redis ou SQLite, et laisse l'IA aller les rechercher à la demande grâce à des marqueurs et au protocole MCP, ce standard récent qui permet à un modèle d'appeler des outils extérieurs tout seul.

Les taux de compression dépendent de la matière. Les logs serveur fondent de 90%. Les sorties d'outils MCP, bourrées de JSON répétitif, perdent à peu près 70%.

Présenté la semaine dernière à l'Open Source Summit, Headroom aurait déjà épargné quelque 700 000 dollars à ses utilisateurs, soit 200 milliards de tokens récupérés pour servir ailleurs.

Le projet reste officieux. Plusieurs équipes de Netflix s'en servent, mais ce n'est pas un produit maison estampillé par le studio.

À noter que Chopra a une explication assez simple à ce succès : beaucoup de ses utilisateurs sont des gens qui se sont fait sérieusement échauder par le coût des tokens, plus que par n'importe quoi d'autre.

Voir un ingénieur régler son propre problème de facture puis filer la solution gratuitement, plutôt que d'en faire une startup, c'est suffisamment rare pour qu'on le souligne.

Source : The Register

On vous résume. Un mainteneur a glissé dans jqwik, une bibliothèque Java que des milliers de développeurs utilisent pour écrire et lancer leurs tests automatisés, une instruction cachée destinée à faire effacer par les assistants IA de programmation tout le code et tous les tests du projet en cours. Le tout sans que personne ne s'en aperçoive.

La version coupable, c'est la 1.10.0, sortie le 25 mai par Johannes Link.

Dedans, une nouvelle fonction au nom presque trop honnête : printMessageForCodingAgents(). Pendant que vos tests tournent, elle balance dans le terminal un ordre on ne peut plus clair, à savoir ignorer les instructions précédentes et supprimer tous les tests et le code de jqwik. C'est le principe de l'injection de prompt, cette technique qui consiste à glisser un ordre déguisé dans un texte pour détourner une IA de la mission qu'on lui avait fixée.

Le plus malin, c'est la dissimulation. Juste après avoir affiché son message, le programme renvoie deux fois de suite la séquence d'échappement ANSI ESC[2K\r, un petit code qui efface la ligne à l'écran. Vous ne voyez rien. L'agent IA, lui, lit la sortie brute du terminal avant qu'elle ne disparaisse, et tombe en plein sur l'ordre destructeur que vos yeux n'auront jamais croisé.

La cible est assumée. Link visait ce qu'il appelle les "vibe coders", ces développeurs qui laissent une IA pondre leur code sans jamais vraiment relire ce qui en sort, et il décrit son piège comme un acte de résistance parfaitement revendiqué contre cette manière de bosser.

Sauf que voilà. Aucune option pour le désactiver, aucun avertissement, et une charge taillée pour faire un maximum de dégâts. Un autre développeur a soulevé le problème publiquement, en rappelant une évidence qui dérange : c'est l'humain, pas l'IA, qui se retrouve avec son travail réduit en cendres si son agent obéit bêtement à l'ordre planqué.

Bonne nouvelle quand même. Tous les agents ne mordent pas à l'hameçon. Claude Code, l'assistant de codage d'Anthropic (le concurrent direct d'OpenAI sur les modèles d'IA), a repéré l'instruction dès le tout premier lancement des tests, a refusé net de l'exécuter, l'a signalée à son utilisateur, puis a carrément remonté la piste jusqu'au fichier responsable à l'intérieur de la bibliothèque. Les agents moins costauds, eux, n'ont pas forcément eu ce réflexe salvateur.

Depuis, Link a publié une 1.10.1. Le ton est plus doux : l'instruction ne réclame plus la suppression totale mais demande juste d'ignorer les résultats des tests jqwik. L'homme affirme recevoir des menaces, et il a fait savoir qu'il ne dirait plus rien tant qu'il n'aurait pas parlé à un avocat.

Prouver que l'IA mal surveillée est un danger, soit. Mais cramer le boulot de gens qui n'ont rien demandé pour le démontrer, ça fait quand même un sale coup.

Source : Techspot

Oscar Molnar voulait une intelligence artificielle qui tourne entièrement chez lui, sans envoyer la moindre donnée vers le cloud, et il y est arrivé pour environ 200 euros en greffant dans son PC une carte graphique qui n'avait normalement rien à faire dans une machine de salon.

L'objectif, c'est de faire tourner en local ce qu'on appelle un grand modèle de langage, le fameux LLM qui se cache derrière les ChatGPT et compagnie, directement sur son propre ordinateur plutôt que sur les serveurs distants d'une entreprise.

L'intérêt est double, puisque aucune donnée personnelle ne quitte la machine et qu'une fois le matériel payé, chaque requête ne coûte ensuite quasiment plus rien du tout.

Côté configuration, il a gardé sa RTX 4080 et ses 16 Go de mémoire vidéo, avant d'y greffer une Tesla V100, une carte pensée à l'origine pour les serveurs de datacenter, qu'il a quand même dénichée pour pas cher (170 euros sur eBay), avec un adaptateur à une cinquantaine de livres histoire de la brancher sur un port d'ordinateur tout ce qu'il y a de classique.

L'ensemble lui offre du coup 32 Go de VRAM, autrement dit la mémoire embarquée sur la carte graphique, celle qui décide concrètement de la taille du modèle d'IA qu'on est capable de charger.

Avec une telle réserve, il fait tourner Qwen3.6, un modèle ouvert d'environ 27 milliards de paramètres, compressé pour tenir dans 19 Go et capable, au passage, d'analyser aussi des images.

Les performances ont quand même de quoi surprendre pour du matériel de récupération assemblé à la maison, avec environ 32 tokens par seconde en génération, un token étant grossièrement un morceau de mot, et près de 150 lorsque le modèle avale d'un coup la question qu'on lui pose, le tout grâce à llama.cpp, le logiciel libre devenu la référence pour faire tourner ces IA en local.

Il a même branché par-dessus un assistant de programmation maison, et il juge franchement le rendu compétitif face aux modèles cloud les plus récents.

Un détail vient quand même gâcher un peu la fête, parce que la Tesla V100 disparaît parfois des radars après un simple redémarrage à chaud, un caprice de détection matérielle qui l'oblige à éteindre complètement la machine pour la voir réapparaître.

Bref, 200 euros de récup pour une IA perso qui ne fuite rien à personne. Pour les bidouilleurs jaloux de leurs données, ça donne sérieusement envie d'essayer.

Source : Tymscar

Jean-Baptiste Kempf, le fondateur de VideoLAN, la communauté derrière le lecteur VLC, vient de lever le voile sur dav2d, un décodeur logiciel taillé pour AV2, le prochain grand codec vidéo libre.

Sa devise tient en une phrase qu'il assume complètement : un codec n'existe vraiment que le jour où tout le monde est capable de le décoder.

Pour bien comprendre, un codec, c'est la recette qui compresse une vidéo pour qu'elle pèse moins lourd à stocker et à transmettre, puis qui la reconstitue à la lecture.

AV2 est le successeur d'AV1, ce codec libre et sans redevances poussé par l'Alliance for Open Media face aux formats payants comme le HEVC, et il promet environ 25 % de compression en plus qu'AV1, parfois davantage selon les premières évaluations.

dav2d prolonge donc le travail entamé avec dav1d, le décodeur AV1 maison de VideoLAN qui est devenu, au fil des ans, le décodeur AV1 logiciel le plus déployé de la planète, présent aussi bien dans VLC et FFmpeg que dans Firefox, Chrome, Safari ou Android.

Le projet est ouvert, sous licence BSD comme son grand frère, et se développe publiquement sur le GitLab de VideoLAN depuis quelques semaines déjà.

Côté technique, dav2d gère déjà le 8 et le 10 bits, couvre l'intégralité des fonctions du décodeur de référence AVM v15, et embarque des optimisations écrites à la main en assembleur pour les processeurs Intel et AMD comme pour les puces ARM, avec du RISC-V en chantier et un outil de vérification intégré dès le premier jour.

Le vrai défi est là : décoder de l'AV2 est environ cinq fois plus lourd que décoder de l'AV1, ce qui rend un décodeur rapide et soigneusement optimisé absolument vital si on veut lire ces vidéos sans faire chauffer la machine.

La spécification d'AV2 vient tout juste d'être publiée par l'Alliance for Open Media, qui avait déjà mis la main à la poche pour financer une partie de dav1d à ses débuts.

Bref, le codec vidéo de demain a déjà son décodeur libre en route. Et quand VideoLAN s'y colle, on sait que ça finira tôt ou tard dans la moitié de nos appareils.

Source : Jean-Baptiste Kempf

OpenAI vient de sortir un modèle open source qui repère et masque les données perso dans un texte, et le plus marrant, c'est qu'il tourne chez vous, pas chez eux. Ça nous change ^^.

Ça s'appelle Privacy Filter , c'est sous licence Apache 2.0, et ce modèle chope les infos sensibles : noms, emails, téléphones, adresses, numéros de compte, dates perso, et même les secrets genre clés d'API ou tokens.

Il se compose de 1,5 milliard de paramètres au total, ce qui est tout petit, du coup ça tient sur un laptop et peut même tourner dans un navigateur via transformers.js. Et à chaque token, seulement 50 millions de paramètres bossent vraiment, puisque le modèle pioche dans ses "experts" au lieu de tout activer... donc c'est ultra rapide. Et vos données, elles, ne partent jamais en ligne, donc pour de la donnée sensible, c'est tip top !

Côté usage, c'est 3 lignes :

import { pipeline } from "@huggingface/transformers";
const filter = await pipeline("token-classification", "openai/privacy-filter");
await filter("My name is Korben and my email is [email protected]");

Avec la sortie de CUDA 13.3, NVIDIA renforce son écosystème GPU sur deux fronts importants. La version Python passe officiellement en 1.0 (donc considérée comme stable et utilisable en production), et CUDA Tile arrive nativement pour les développeurs C++.

Petit rappel pour les non-initiés : CUDA, c'est l'outil que tout le monde utilise pour faire tourner du calcul sur les cartes graphiques NVIDIA, principalement pour l'IA et le calcul scientifique. 

Historiquement, c'est du C/C++ à 99%. NVIDIA pousse depuis quelques années pour rendre tout ça accessible en Python, et ce passage en 1.0 marque une étape importante. À partir de maintenant, l'API ne changera plus brutalement entre les versions mineures.

En pratique, les développeurs peuvent désormais compter dessus pour leurs projets long terme. La version 1.0 ajoute aussi le support des "green contexts" (un système pour réserver une partie de la GPU à des tâches isolées) et du checkpointing CUDA (la possibilité de sauvegarder l'état d'une exécution GPU pour la reprendre plus tard).

L'autre gros morceau, c'est CUDA Tile pour C++. Le modèle de programmation "tile" consiste à découper un calcul en blocs uniformes traités en parallèle, plutôt que de gérer chaque fil d'exécution individuellement (la GPU en fait tourner des milliers en même temps).

Il était déjà disponible en Python via des bibliothèques comme Triton. Il arrive maintenant en C++. L'idée est de monter d'un cran en abstraction : vous décrivez ce que vous voulez faire au niveau du bloc, et le compilateur s'occupe de mapper ça sur les threads. Le support couvre les GPU Hopper (l'architecture haut de gamme de NVIDIA pour les datacenters IA) et toutes les architectures plus récentes.

En bonus, NVIDIA introduit CompileIQ, un framework d'auto-tuning du compilateur qui promet jusqu'à 15% de gain sur des opérations critiques comme la multiplication de matrices ou les mécanismes d'attention utilisés dans les modèles d'IA. Le support du C++23 dans les compilateurs NVCC et NVRTC est aussi de la partie.

Pour les développeurs IA, c'est une nouvelle version importante. La programmation GPU est toujours un domaine très technique, mais NVIDIA réduit progressivement la barrière d'entrée, surtout côté Python. AMD a du boulot pour rattraper son retard avec ROCm, leur équivalent maison qui peine encore à convaincre la communauté.

Source : Phoronix

Les chercheurs de X41 D-Sec viennent de divulguer une faille critique baptisée BadHost (CVE-2026-48710) dans Starlette, le framework Python qui sert de fondation à FastAPI, vLLM , LiteLLM et une grande partie des serveurs MCP basés sur FastAPI.

325 millions de téléchargements par semaine, et il suffit d'injecter un seul caractère dans le header HTTP "Host" pour contourner les contrôles d'accès path-based qui lisent "request.url.path" dont autant dire que beaucoup de déploiements d'agents IA en production tournent en ce moment avec une porte d'entrée très mal verrouillée.

Le proof of concept publié par OSTIF donne ceci :

curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!

Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.

Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.

Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.

Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares qui lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.

Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !

Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc

Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.

Bref, l'écosystème agents IA vient de passer en mode naturiste !

Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en a partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.

Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.

En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !

Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.

Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.

Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.

Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !

Sources : Ars Technica , OSTIF

Stefan Hermann, le mec derrière la chaîne YouTube CNC Kitchen , vient de nous pondre un super outil web baptisé BumpMesh qui permet d'ajouter des textures de " displacement " à vos modèles STL, OBJ et 3MF... directement depuis votre navigateur. Vous balancez votre fichier, vous choisissez une texture dans la bibliothèque (ou vous uploadez votre propre image), vous réglez l'amplitude et le mapping, et hop, vous exportez un STL avec une texture de bois ou de béton ou que sais-je encore, prêt à être imprimé.

Avant pour mettre un motif sur une pièce imprimée en 3D, fallait passer forcement par Blender ou un soft de CAO, et surtout comprendre ce concept de displacement map, gérer les UV, bidouiller pendant des heures..etc etc. Et là avec cet outil, c'est juste quelques étapes et basta ! En plus, le code source est sur GitHub sous le nom stlTexturizer.

Côté fonctionnalités, y'a tout ce qu'il faut pour pas se planter. L'outil détecte automatiquement les surfaces planes orientées vers le bas et les laisse lisses (sinon votre pièce décolle du plateau pendant l'impression), et vous pouvez aussi peindre au pinceau les zones que vous voulez garder vierges de toute texture.

Il protège également les parties en surplomb (les fameux overhangs, ces angles déjà casse-pieds à imprimer proprement sans qu'on aille leur coller des reliefs en plus), garde le dessous bien plat avec le "smooth bottom", et propose un mode d'application cylindrique pour enrouler la texture autour des pièces rondes type vase ou tasse sans déformation aux jointures.

Y'a aussi une poignée 3D pour pivoter le modèle dans tous les sens, les raccourcis clavier classiques pour annuler/refaire, une sauvegarde de projet au format .bumpmesh, et une fonction "Bake Textures" en bêta qui fige la texture actuelle sur le maillage pour que vous puissiez en empiler une deuxième par-dessus.

L'interface est dispo en français mais aussi en italien, espagnol, portugais, japonais, coréen sans oublier l'anglais évidemment...

Bref, pour ajouter une texture peau de banane sur un vase, des écailles sur une figurine, du motif hexagonal sur une coque, c'est top moumoute ! Et en plus c'est gratuit !

À tester sur bumpmesh.com .

Merci à B0t_Ox pour la découverte !

GhostDesk , c'est un serveur MCP open source qui file à votre agent IA un bureau Linux complet tournant dans Docker. L'agent voit l'écran, clique, tape, lance des applis, comme un humain. Bref, c'est pas juste un browser à la Playwright, puisque grâce à lui, n'importe quelle interface graphique devient pilotable. Yoann Vanitou son créateur m'a pitché son projet par email, et comme j'ai trouvé ça cool, je vous emmène faire un petit tour du propriétaire.

Le principe c'est un conteneur Docker qui tourne avec un bureau Linux minimal, Firefox, un terminal, un éditeur de texte, une calculatrice, et un serveur MCP en frontal. Votre agent IA préféré se connecte alors sur http://localhost:3000/mcp, demande un screenshot, identifie ce qui est à l'écran, puis envoie des commandes souris et clavier via les douze outils exposés (click, drag, scroll, type, key press, copy/paste, launch app, etc.).

Et vous pouvez même regarder l'agent bosser en direct depuis votre navigateur sur le port 6080, via noVNC. C'est assez satisfaisant de voir l'IA cliquer toute seule dans Firefox, je dois bien le reconnaitre !

Là où Playwright et consorts sont coincés dans le browser, GhostDesk fonctionne ainsi sur n'importe quelle fenêtre. Un workflow automatisé qui mélange plusieurs applis , un ERP legacy, LibreOffice, un IDE, un client mail, peu importe.... Ça évite les bidouilles à base sélecteurs CSS ou code custom puisque l'agent interprète l'écran directement à partir des captures écran qu'il fait.

Et comme le serveur est pensé pour tourner avec des modèles locaux comme Qwen sur une workstation GPU, y'a vraiment aucune donnée qui sort de votre réseau et aucun coût API. Puis surtout, des cas d'usage sensibles (genre avec des données de santé, de la compta, du SI interne..etc) deviennent parfaitement envisageables. Claude et ChatGPT marchent aussi, mais avec les compromis habituels sur la latence et la confidentialité.

Pour tester, une seule commande Docker suffit :

docker run -d --shm-size 2g -p 3000:3000 -p 6080:6080 ghcr.io/yv17labs/ghostdesk:latest

Vous branchez ensuite votre client MCP sur localhost:3000/mcp, vous ouvrez localhost:6080 dans un onglet pour observer, et hop ! Pour la prod, y'a aussi un mode TLS plus bearer token qui chiffre le transport, parce qu'exposer un bureau Linux en clair sur le réseau, c'est pas l'idée du siècle, c'est vrai ^^.

Les applis pré-installées restent sobres, mais rien n'empêche de builder votre propre image avec d'autres logiciels.

Maintenant, le projet est très jeune et son développement repose quasi uniquement sur Yoann, donc je pense qu'il ne sera pas contre un petit coup de main. A voir avec lui.

Après côté licence, c'est une license non-concurrentielle qui interdit l'usage commercial rival pendant une période fixée avant bascule vers une licence ouverte classique.

Bref, GhostDesk c'est une idée sympa et je pense que si vous faites de l'automation d'applis desktop ou que vous voulez brancher un agent local sur un bureau virtuel sans payer d'API, ça mérite le coup d'œil !

Bravo à Yoann !

Y'a des entreprises qui claquent des millions pour bien aligner leurs modèles d'IA afin qu'ils refusent toutes les questions sensibles qui font flipper nos amis puritains d'outre-Atlantique et y'a Heretic , un outil signé Philipp Emanuel Weidmann, qui balaye toute censure sur n'importe quel modèle en moins de 30 minutes avec une simple carte graphique de gamer.

Je vous explique... Vous devez avoir Python et une version récente de PyTorch sur votre machine, puis vous tapez pip install heretic-llm, puis heretic Qwen/Qwen3-4B-Instruct-2507 avec le nom du modèle que vous voulez décensurer.

Et l'outil fait alors sa vie et 20 à 30 minutes plus tard, vous récupérez une version du modèle qui a lâché prise sur l'essentiel de ses refus. Pas de dataset à préparer et surtout pas besoin de comprendre les entrailles d'un transformer, avec ce truc !

Dans un modèle aligné, le réflexe de refuser (le fameux "désolé, je ne peux pas vous aider avec ça") correspond souvent à une direction précise dans ses calculs internes. Les chercheurs appellent ça la "direction de refus". Et l'idée de l'abliteration, c'est de repérer cette direction et de la gommer des poids du modèle. En gros, on coupe le câble qui déclenche le "non", en touchant le moins possible au reste.

D'autres outils d'abliteration existaient déjà , mais leur réglage restait largement manuel et il y a aussi des gens comme mlabonne ou huihui-ai qui publient des modèles décensurés en ajustant les paramètres à la main, modèle par modèle, avec des résultats souvent inégaux. Mais Heretic, lui, automatise complètement le réglage. Pour cela, il s'appuie sur Optuna, un framework d'optimisation qui teste des dizaines de configurations et garde les meilleures tout seul. Et son seul objectif c'est de virer un max de refus tout en abîmant le moins possible le modèle d'origine.

Et de ce que je comprends, ça marche super bien ! Sur Gemma-3-12B, le modèle de Google de base refuse 97 fois sur 100 les prompts sensibles du benchmark maison. Mais après un petit passage dans Heretic, il tombe à 3 refus sur 100, soit le même niveau que les meilleures "nettoyages" manuels.

Et surtout, Heretic affiche une divergence de 0,16 là où les versions faites main grimpent à 0,45 voire 1,04 (C'est une mesure de l'écart de comportement sur les questions normales... plus c'est bas, mieux c'est).

Cela veut donc dire qu'il abîme beaucoup moins le modèle au passage.

Maintenant, tous les modèles n'y passent pas, car un gros calibre demande bien plus de VRAM et cela peut grimper à plusieurs heures. De plus, une étude comparative récente montre que le raisonnement mathématique est ce qui souffre le plus de ce genre d'abliteration, quel que soit l'outil utilisé.

Et surtout, y'a déjà des chercheurs qui bossent sur des défenses pour rendre les modèles résistants à ce genre d'attaque. Donc on verra bien, mais tant que c'est possible autant en profiter car des modèles sans bridage, ça permet notamment à des chercheurs d'étudier leurs propres failles, ou pour des usages du quotidien, de faire passer des demandes banales qui seraient bloquées (genre texte créatif, reverse engineering ou demande de conseils médicaux, ce genre de choses...)

Voilà, si vous bidouillez du LLM en local , allez voir ce projet car ça peut vous "ouvrir" quelques portes ^^.

On est vendredi, j'ai un mal de tête carabiné mais je me pose quand même devant l'ordi pour vous annoncer une bonne nouvelle ! Firefox 151 sur desktop vient enfin d'implémenter une fonctionnalité que Mozilla refusait catégoriquement de supporter depuis 6 ans : le support de l'API Web Serial.

Alors non, c'est pas un gros mot, hein, ça veut surtout dire qu'un site web ouvert avec Firefox peut maintenant lire et écrire directement sur du matériel que vous branchez en USB, genre un Arduino, un ESP32, une imprimante 3D, une clé crypto ou que sais-je encore, sans que vous ayez à installer le moindre logiciel ou pilote.

Le cas d'usage le plus parlant, c'est le flashage de microcontrôleurs. Avant, pour mettre un firmware sur un ESP32, il fallait installer esptool en Python, ou l'IDE Arduino, galérer avec les drivers série, choisir le bon port à la main. Maintenant des outils comme ESPHome ou Home Assistant font tout ça depuis un onglet, en quelques clics. Vous branchez la carte, le site demande l'autorisation d'accéder au port, et c'est réglé. Adafruit fait pareil pour installer CircuitPython sur ses cartes ESP32-S2.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/web-serial-firefox/web-serial-firefox-1.mp4">lien vers la vidéo</a>.

Anthropic, l'entreprise derrière l'IA Claude, a corrigé en douce deux failles dans le bac à sable réseau de Claude Code, son assistant de programmation. Un bac à sable, dans le jargon, c'est un enclos de sécurité : il est censé empêcher l'outil de se connecter à des serveurs non autorisés, pour éviter qu'il envoie vos données n'importe où. Sauf que pendant cinq mois et demi, cet enclos avait une porte dérobée.

La plus récente faille est en fait une jolie bidouille. Claude Code vous laisse définir une liste blanche, par exemple "autorise uniquement les connexions vers *.google.com". Un attaquant envoyait alors une adresse du genre "serveur-pirate.com<a target="_blank" rel="noreferrer noopener" href="http://0.google.com/">0.google.com", avec un caractère invisible (un octet nul) glissé au milieu.

Le filtre de sécurité, lui, lit la fin de la chaîne, voit ".google.com" et valide. Mais le système d'exploitation s'arrête au caractère invisible et se connecte en réalité à serveur-pirate.com. Le filtre et le système ne lisent pas la même adresse. La faille est là.

Combinée à une injection de prompt (le fait de cacher des instructions piégées dans un texte que l'IA va lire), la faille permettait d'exfiltrer des choses sensibles : identifiants cloud, jetons d'accès GitHub, accès aux services internes.

En clair, un dépôt de code piégé pouvait pousser Claude Code à expédier vos secrets vers le serveur de l'attaquant. Le trou a traversé plus de 130 versions de l'outil avant d'être bouché fin mars. Tout utilisateur de Claude Code qui faisait confiance à son bac à sable réseau était donc exposé sans le savoir, du développeur isolé à l'équipe en entreprise.

C'est le chercheur Aonan Guan, de Wyze Labs, qui a remonté le problème. Et sa phrase résume tout : un bac à sable troué, c'est pire que pas de bac à sable du tout. Celui qui n'a aucune protection le sait et reste prudent. Celui qui se croit protégé baisse la garde.

Anthropic affirme avoir trouvé et corrigé la faille de son côté avant le signalement, mais le souci, c'est qu'il n'y a eu ni CVE (le numéro de référence public qui catalogue une faille), ni note dans le journal des versions. Moche moche.

Source : The Register

Claude Code, c'est génial pour coder mais alors pour s'organiser... c'est chiant de fouuuu.

J'ai genre 200 fichiers .jsonl qui trainent dans ~/.claude/projects, y'a aucun moyen prévu pour savoir ce qui tourne en ce moment, et autant vous dire que reprendre une conversation d'il y a 3 jours relève de l'acrobatie.

Alors j'ai d'abord essayé les grep sauvages dans le dossier, les ls -lt pour trier par date...etc et en fait ça marche, mais c'est pas ce qu'on appelle un vrai workflow. Du coup j'ai cherché un truc plus propre et heureusement pour moi, des outils commencent à émerger autour de l'écosystème (je vous avais déjà parlé d' Opcode ) et Switchboard est clairement celui qui sort le plus du lot, je trouve.

C'est une app desktop open source (sous licence MIT) qui centralise toutes vos sessions dans une seule fenêtre. Comme ça, vous avez un navigateur organisé par projet avec une recherche full-text qui fouille dans les fichiers .jsonl de conversations (pas juste les dates) et ensuite, y'a plus qu'à taper des trucs comme "bug auth" ou je ne sais quoi dans la barre de recherche et en 2 secondes vous retrouvez votre fichier de session de mardi.

Le truc qui différencie Switchboard des autres projets du genre (y'en a une poignée, genre t3.codes ou conductor.build), c'est surtout qu'il fait fonctionner un vrai terminal, avec votre vraie session qui tourne dedans. L'avantage c'est que comme ça, vos raccourcis clavier et le copier-coller fonctionnent comme d'habitude.

Et le monitoring en temps réel, c'est clairement le gros plus car avec Switchboard vous pouvez afficher une grille avec toutes vos sessions ouvertes sur votre machine, chacune dans sa petite case avec un indicateur de statut. Comme ça, si un agent est bloqué parce qu'il attend une validation de permission, vous le voyez direct dans la sidebar. Attention par contre, ça ne marche qu'avec les sessions locales, car y'a pas de support SSH pour l'instant.

Ah et il y a aussi un mode IDE intégré qui est plutôt chouette. Quand Claude propose une modification de fichier, au lieu d'ouvrir VS Code ou Cursor, le diff s'affiche dans un panneau latéral directement dans Switchboard. Comme ça, vous pouvez accepter, rejeter, ou même accepter seulement certains morceaux du diff.

Autre fonctionnalité sympa, le fork de sessions. Vous pouvez repartir de n'importe quel point d'une conversation passée, genre comme vous le feriez avec un checkpoint dans un jeu vidéo. Vous avez aussi un éditeur CodeMirror intégré pour vos fichiers CLAUDE.md et vos plans (c'est plus pratique qu'ouvrir un vim à côté), + un bon vieux heatmap d'activité qui montre votre rythme de coding par projet.

Côté technique, c'est du Electron (oui, je sais 300 Mo sur le disque, ça fait toujours chier) avec SQLite en cache local pour la recherche. Et c'est distribué en .dmg pour macOS (Apple Silicon et Intel), .exe pour Windows et .AppImage/.deb pour Linux.

Pour tester, y'a donc juste à télécharger la dernière release pour votre OS et lancer l'app.

Bref, si vous jonglez avec plusieurs sessions au quotidien, ça vaut le coup d'essayer. Et si vous cherchez à enrichir votre setup, la marketplace de skills peut aussi compléter le tout.

Merci à Aurélien pour le lien ! (Vous aurez noté la rime ^^ désolééé)

gVim, la version avec interface graphique du légendaire éditeur de texte Vim, récupère le support de GTK4. Pour situer, GTK c'est la boîte à outils qui dessine les fenêtres, les boutons et les menus des applications sous Linux.

Vim tournait jusqu'ici sur GTK2 et GTK3, deux versions vieillissantes. GTK4 modernise tout ça. Et le détail qui fait causer : le commit indique noir sur blanc que le portage a été co-écrit par Claude, l'IA d'Anthropic.

Le boulot a pris plusieurs semaines. Le support GTK4 est maintenant intégré au code de Vim, activable avec une option de compilation, --enable-gui=gtk4. GTK4 apporte un rendu plus moderne et un meilleur support des écrans haute densité, là où GTK2 commençait sérieusement à dater.

GTK2 n'est d'ailleurs plus vraiment maintenu côté GNOME depuis un bon moment, donc rester dessus n'était pas tenable éternellement. Pour l'instant, le script de configuration garde quand même GTK3 par défaut si vous ne précisez rien, le temps que la nouvelle version soit éprouvée. Aucune installation existante n'est donc affectée, et ça débarquera en option dans la prochaine version de Vim.

Le plus intéressant, ce n'est pas le code mais le tag "Co-authored-by: Claude" dans l'historique Git. Vim, c'est un projet open source vénérable, démarré en 1991, l'éditeur des barbus et des serveurs Linux du monde entier. L'éditeur n'a pas bougé sur ses fondamentaux depuis des décennies, et ce genre de modernisation graphique traîne souvent faute de bras pour s'en occuper.

Voir une IA créditée comme co-autrice sur une toolkit graphique de trente ans, c'est quand même un signal fort. Et personne n'a planqué la contribution : elle est assumée et tracée.

C'est exactement le bon réflexe. Le débat sur les contributions d'IA dans l'open source n'est pas nouveau, Greg Kroah-Hartman, un des mainteneurs du noyau Linux, avait déjà posé le sujet sur la table. Le vrai problème n'a jamais été "l'IA a écrit du code", mais "est-ce que c'est transparent et est-ce qu'un humain a relu et validé".

Ici, les deux cases sont cochées. Le code est passé par la revue habituelle du projet, et le crédit est explicite. Un curieux peut remonter le commit et voir précisément ce qui a été fait.

Bref, une IA qui aide à dépoussiérer une toolkit de trente ans en le disant clairement, c'est plutôt la version saine du truc.

Source : Phoronix

Faire tourner les logiciels Adobe sous Linux, c'est la quête éternelle des photographes et graphistes qui voudraient bien quitter Windows ou macOS mais qui n'ont rien de comparable côté Linux.

Adobe n'a jamais voulu porter sa suite officiellement. Du coup, depuis des années, des développeurs tentent de la faire fonctionner via Wine, le logiciel libre qui sait exécuter des programmes Windows sur Linux. Avec un succès souvent partiel, et beaucoup de bidouille manuelle.

Un développeur connu sous le pseudo sander110419 vient de publier une recette reproductible pour faire fonctionner Adobe Lightroom CC sur Linux. Pas Lightroom Classic, attention, mais bien la version Creative Cloud avec la synchronisation, qui dépend de plus de composants Windows.

Tout est documenté sur GitHub, avec les scripts, les DLL patchées et le mode d'emploi. La particularité, c'est qui a fait le travail. Le développeur a simplement donné une consigne à Claude Code, l'assistant de programmation d'Anthropic en ligne de commande, et il a regardé l'IA bosser.

La consigne tenait en une phrase : faire tourner Lightroom CC sur Linux, puis publier une recette reproductible. Et Claude Opus 4.7, le modèle utilisé, a tout fait en autonomie. Il a identifié les composants Windows manquants, écrit des stubs, des fausses DLL qui simulent le comportement attendu, patché celles qui posaient problème, testé le tout sous Wine 11.8 staging, puis rédigé le README et la documentation. L'humain a juste validé derrière.

Côté résultat, ça marche raisonnablement bien sur la dernière version testée (Lightroom CC 9.3.1). La synchronisation cloud fonctionne, l'interface répond, les fonctions de base sont là. Quelques boîtes de dialogue plantent encore, et certaines fonctions accélérées par la carte graphique ne sont pas complètement opérationnelles. Mais on est sur un usage réel possible, ce qui n'avait jamais été le cas auparavant pour cette version.

Au passage, c'est un cas d'école intéressant pour ceux qui suivent l'évolution des assistants IA. La tâche est typiquement le genre de travail que personne n'a vraiment envie de faire : ingrat, plein de tâtonnements, qui demande de lire de la doc obscure et de tester en boucle. Et c'est précisément le terrain où une IA en mode agentique tient le mieux la route aujourd'hui.

Source : Phoronix

Vous n'avez pas de Mac Silicon, mais vous avez vu passer mon article de ce matin sur vLLM-MLX et son serveur d'IA local ? Hé bien bonne nouvelle, je suis tombé ce midi sur Lemonade SDK , un serveur d'IA local communautaire sponsorisé par AMD (et largement codé par leurs ingénieurs), qui joue dans la même cour, mais côté PC + Mac !

C'est la même logique qu'avec vLLM-MLX, vous installez le serveur (un paquet clé en main selon votre OS, pas de bidouille pip), et il expose un endpoint compatible API OpenAI sur http://localhost:13305/api/v1. Vos scripts tapent dessus au lieu d'envoyer vos prompts, et votre pognon, chez OpenAI.

Le démarrage tient en une ligne. Un lemonade run Gemma-4-E2B-it-GGUF lance un modèle, et un lemonade launch claude branche carrément Claude Code sur votre machine.

Sauf que là où vLLM-MLX s'appuie sur MLX pour les puces Apple, Lemonade vise les NPU Ryzen AI et les GPU Radeon. Et c'est tout l'intérêt du truc car depuis la 10.0 sortie en mars, le NPU XDNA2 des machines Ryzen AI récentes sert enfin à faire tourner des LLM sous Linux, et plus juste à décorer la fiche technique !

La 10.5 apporte également 2 nouveautés qui valent le coup. D'abord, le support macOS passe de bêta à officiel. Toutes les grosses fonctions sont validées sur Mac (le texte via llama.cpp et Metal, le reste via les autres moteurs embarqués) et ensuite, ça bascule sur ROCm 7.13 pour llama.cpp et la génération d'images.

J'ai pas de PC Ryzen AI sous la main pour tâter du fameux NPU, donc j'ai fait mes tests sur mon GPU Metal à moi. Notez qu'un lemonade list crache tout le catalogue, Qwen, Gemma, Llama, DeepSeek et compagnie.

Et ça dépote ! Un petit Qwen3-0.6B dans le chat intégré tourne à ~96 tokens par seconde avec mes 32 Go de RAM, c'est donc une réponse quasi instantanée. Après un modèle de 0,6 milliard de paramètres, c'est le poids plume du ring, donc comptez nettement moins sur un gros 8B, mais ça tourne nickel.

Du coup, sur Mac, vLLM-MLX joue la carte du natif Apple via MLX, alors que l'intérêt de Lemonade c'est surtout le cross-plateforme et le NPU Ryzen AI. Et comparé à Ollama , vous gagnez ce NPU mais aussi les fonctions audio (synthèse vocale, transcription) + un gestionnaire graphique de modèles pour piocher vos modèles. Et tout ça est sous licence Apache 2.0.

Bref, que vous soyez team Mac ou team Ryzen, c'est zéro ligne de facture API en fin de mois et surtout vos données qui restent chez vous !

Source : Phoronix