Une PS5, au fond, c'est juste un PC comme les autres. Elle a un processeur AMD x86-64 (c'est du Zen 2, en gros un Ryzen) ainsi qu'une puce graphique RDNA 2, ce qui est grosso merdo la même came que ce qu'il y a dans votre tour de gamer.

Et pour ça que le pari d' AnyPS5 est possible ! L'objectif de ce projet c'est qu'au lieu de lancer un n-ième émulateur qui "imite" la console pendant que vous jouez, l'outil prend le code binaire d'un jeu PS5, le décompile et le recompile intégralement sous la forme d'un vrai programme Linux ou Windows, que votre système peut ensuite lancer comme n'importe quel autre.

Pour y parvenir, ce projet repose sur 2 briques. D'abord il y a un "relinker", qui lit l'exécutable du jeu et le reconstruit au format natif de la cible, c'est à dire ELF pour Linux ou PE pour Windows. Mais comme le jeu continue d'appeler des fonctions système PS5 que votre PC ne connait pas, AnyPS5 réimplémente les bibliothèques de Sony, libc, libkernel et toute la famille libSce, en bibliothèques dynamiques que le chargeur de votre OS peut alors lier au programme converti.

Résultat, le jeu tourne comme un processus normal, sans runtime à part... C'est beau non ?

Mais tout n'est pas réécrit d'avance pour autant puisque côté graphique, le jeu envoie ses files de commandes comme s'il causait à la puce AMD de la console, et c'est donc la version maison du projet de libSceAgcDriver qui les interprète pendant l'exécution. Les shaders RDNA, eux, sont recompilés en SPIR-V pour Vulkan quand le jeu les demande, puis rangés dans un cache sur le disque pour les lancements suivants. Donc ça veut dire que certes, le code processeur tourne en natif, mais la partie GPU, elle, est traduite à la volée.

La conversion elle-même, après c'est juste une ligne de commande. Vous indiquez l'exécutable du jeu et son dossier sce_module côte à côte, et vous choisissez le nom du binaire cible (le .exe quoi) :

relinker source/input.elf app.elf
relinker --windows source/input.elf app.exe

Sur un processeur Intel, ajoutez le paramètre --to-intel, qui convertira les instructions propres aux puces AMD qu'il connaît.

Et quand le jeu touche à quelque chose que le projet ne gère pas encore, AnyPS5 lève une exception, en affiche la raison dans le terminal et le processus s'arrête. Ça veut dire qu'un jeu qui boote n'est pas forcément un jeu auquel vous pourrez jouer jusqu'au bout.

Et justement, qu'est-ce qui va jusqu'au bout ?

Hé bien la liste de compatibilité officielle est trèèès courte puisqu'elle ne contient qu'un seul jeu : Dreaming Sarah. C'est un jeu de plateforme 2D sorti sur Steam en 2015 et vendu moins de 5 € (1,49 € en promo au moment où j'écris).

Sous Windows, après recompilation, il est noté "in game, playable", à 60 images par seconde sur une GTX 1050 Ti et 36 sur une puce Intel HD 620 et sous Linux, on ne connait pas encore les stats même si l'ELF Linux a été généré.

Bien sûr, comme toujours avec ces projets de recompilation ou d'émulation, aucun firmware, ni jeu, ni clé n'est fourni. Et comme vous le savez, pour déchiffrer un jeu et l'extraire, il faut un exploit du firmware en cours, autrement dit une console débridée. Donc ça limite un peu les ambitions de pas mal de monde. Mais ça n'en reste pas moins possible pour qui a un peu de volonté (et une PS5 jailbreakée).

Sachez que ce projet AnyPS5 nécessite une carte graphique Vulkan 1.1, que les manettes Xbox ou PlayStation reconnues par SDL fonctionnent avec sticks et gâchettes analogiques, et que le clavier se remappe sans souci dans un fichier anyps5-input.ini que vous devez éditer.

Voilà... Les émulateurs PS5 dont je vous ai parlé, recréent la console autour du jeu alors qu'AnyPS5 tente de recréer le jeu pour n'importe quelle machine. On verra qui y parvient massivement en premier, mais en tout cas, la course à l'émancipation de la PS5 et de ses jeux est lancée !

Source : AnyPS5

Mise à jour du 8 octobre 2026 : depuis la publication de cet article, j'ai découvert les idées que diffuse DHH, le créateur d'Omarchy. Je ne recommande plus cette distribution, et je vous explique pourquoi dans Omarchy, non merci .

Omarchy-apple-dev , c'est un projet qui vous permet de compiler une app codée en SwiftUI, l'installer sur votre iPhone via le cable USB et l'envoyer à TestFlight d'Apple, tout ça depuis une machine Linux sous Omarchy... Oui oui, sans Mac !

Le gros du boulot est assuré par xtool , qui sait déjà compiler, signer et installer une app iOS sous Linux, mais ce dépôt omarchy-apple-dev y ajoute un script ship.sh, qui permet de créer le .ipa, d'y renseigner les clés de build que le traitement App Store lit, puis d'envoyer tout ça à Apple comme un grand.

Bref, en langage clair, ça veut dire que vous pouvez être développeur iOS depuis votre PC Linux. Cool hein ?

Pour l'installer, c'est juste 3 lignes avec install du SDK d'Apple.

git clone https://github.com/joshuaswarren/omarchy-apple-dev
cd omarchy-apple-dev
./install-toolchain.sh

Les morceaux du SDK iOS n'existant que dans la distribution Xcode d'Apple, il faut donc télécharger le Xcode.xip sur developer.apple.com avec un Apple ID gratuit, depuis n'importe quel OS. Vous relancez ensuite le script avec XCODE_XIP=/chemin/Xcode.xip, puis device-run.sh installera l'app sur l'iPhone branché. Un compte gratuit suffit pour ça, mais Apple le limite à 3 apps par appareil avec des profils qui expirent au bout de 7 jours. Pour TestFlight, il faudra par contre un compte développeur payant et une clé d'API App Store Connect.

Après, les CGU d'Apple pour Xcode et ses SDK disent bien que ces logiciels ne sont autorisés uniquement sur un produit de marque Apple tournant sous macOS, et que tout autre usage est une violation du contrat. Sa clause 2.5 interdit aussi d'utiliser les SDK séparément ou de les faire tourner sur du matériel qui n'est pas Apple. Or le SDK que le script installe vient forcément d'un Xcode d'Apple. Voilà, au moins vous savez...

Bref, pour bricoler sur votre iPhone avec un compte gratuit, ça peut le faire... Après, pour l'App Store, sachez qu'Apple exige en plus depuis avril dernier, que vos apps soient compilées avec Xcode 26 ou plus récente alors qu'ici, ce bon vieux script contourne ça... Donc à voir si vous voulez tenter votre chance.

Au pire, pour la phase finale (la compilation de la release de votre app), vous sortez un Mac rien que pour ça et le reste du temps, vous codez et compilez vos tests à 100% dans Omarchy. A vous de voir :)

Windows 11 dans une machine virtuelle sur un Mac Apple Silicon, ça se fait depuis looooongtemps avec des outils comme Parallels ou UTM. Mais tart, l'outil en ligne de commande qui crée et clone des VM comme on le ferait avec des conteneurs, n'en est pas capable, parce que la virtualisation d'Apple sur laquelle il repose ne gère officiellement que macOS et Linux.

Sauf qu'un dev nommé Mustafa Akin, vient de publier un fork qui permet d'installer Windows 11 avec tart sans un seul clic.

Je viens de le tester sur mon Mac Studio M4 Max avec l'ISO française de Windows 11 et j'ai trouvé que ça fonctionnait super, d'où ce petit tuto.

Ce qu'il vous faut avant de commencer

Pour vous lancer là dedans, il vous faut donc un Mac Apple Silicon sous macOS 26.6 ou 27, Xcode pour compiler tout ça, et bien sûr une ISO de Windows 11 ARM64 ( faudra vous démerder ensuite avec la licence ). Par contre, faut le savoir, ce fork repose sur deux réglages privés d'Apple, non documentés, qu'une mise à jour de macOS pourra shooter à tout moment. Donc ne montez pas votre futur homelab là dessus sans un plan de repli.

Compiler tart et créer la VM

Sur son site, Mustafa Akin publie un binaire tout fait, mais j'ai préféré compiler le programme car le script de création du paquet de son fork signe proprement l'application en local avec le droit de virtualisation qui va bien.

git clone --branch windows-guest-extras https://github.com/mustafaakin/tart.git
cd tart
git checkout e4c623c
./scripts/package-windows-preview.sh 0.1.0-windows-preview
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

La commande export rend ce tart.app accessible au niveau du système prioritaire devant un éventuel tart déjà installé. Il ne reste alors qu'à lui passer votre ISO... tart téléchargera alors les pilotes virtio-win et WinFsp, fabriquera son propre média d'installation et démarrera Windows sans rien demander de plus.

tart create win11 --from-iso ~/Downloads/Win11_Arm64.iso

Ça m'a pris en tout et pour tout 26 minutes pour obtenir cette VM Windows fonctionnelle. Notez également que l'installation force l'anglais américain et que d'autres langues peuvent poser souci mais avec mon ISO française, l'interface est bien restée en français. Seul le clavier est resté en QWERTY au départ.

Installer le pilote et l'agent à la mano

L'auteur écrit sur son blog que l'install de l'agent doit se faire manuellement pour l'instant mais ce qu'il a oublié de préciser c'est que le pilote viosock, celui qui relie le Mac à la VM, n'est pas dans la liste des pilotes que tart injecte (viostor, viogpudo, NetKVM, viorng et viofs). Résultat, chez moi, tart exec ne fonctionnait pas. Comme ce pilote se trouve dans l'ISO virtio-win que tart a gardée dans son cache, il suffit donc de le copier dans un dossier partagé, contenant l'agent publié avec la préversion :

hdiutil attach -readonly -nobrowse ~/.tart/cache/windows/sha256:303f7ae40dad495d6ae474fdc571df58958a4dbc5c37a522d80f9a203867949d.iso
mkdir -p ~/tart-share
cp -R /Volumes/virtio-win-0.1.302/viosock/w11/ARM64 ~/tart-share/viosock
hdiutil detach /Volumes/virtio-win-0.1.302
curl -L -o ~/tart-share/tart-guest-agent.exe https://github.com/mustafaakin/tart/releases/download/windows-preview-0.1.0/tart-guest-agent.exe
tart run win11 --dir=share:$HOME/tart-share

Comme la commande tart run garde la main, laissez-la tourner et ouvrez un second terminal pour la suite, en y refaisant l'export ci-dessous depuis le dossier tart, sinon vous appellerez un autre tart.

export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

Au démarrage, la session admin (mot de passe admin) s'ouvre alors toute seule et vous arrivez sur le bureau. Le dossier partagé apparaît sur le lecteur Z:, dans un dossier share. Ouvrez PowerShell en administrateur (et n'oubliez pas que le clavier est en QWERTY) pour installer le pilote, puis déclarer l'agent comme tâche lancée à l'ouverture de session, parce que c'est dans cette session que sont le presse-papiers et le bureau :

pnputil /add-driver Z:\share\viosock\viosock.inf /install
mkdir "C:\Program Files\Tart"
copy Z:\share\tart-guest-agent.exe "C:\Program Files\Tart\"
$a = New-ScheduledTaskAction -Execute "$env:SystemRoot\System32\conhost.exe" -Argument '--headless "C:\Program Files\Tart\tart-guest-agent.exe" --run-agent'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
$p = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName "Tart Guest Agent" -Action $a -Trigger $t -Settings $s -Principal $p
Start-ScheduledTask -TaskName "Tart Guest Agent"
Get-Service VirtioSocketWSP

Le service VirtioSocketWSP doit alors afficher Running. S'il n'existe pas, c'est que le pilote n'est pas passé et tart exec ne répondra pas. Relisez alors la sortie de pnputil et vérifiez que le dossier viosock contient bien viosock.inf.

Vérifier que le terminal de Windows répond

Retournez ensuite dans le terminal du Mac et entrez cette commande pour connaitre le numéro de version du Windows :

tart exec win11 cmd /c ver
Microsoft Windows [version 10.0.26200.8037]

Informations système dans la VM : Windows 11 Famille, build 26200, sur une "Apple Virtualization Generic Platform" en ARM64

L'intérêt de tout ça c'est surtout d'avoir un Windows jetable. Vous devez arrêtez d'abord la VM de base avec tart exec win11 shutdown /s /t 0 puis pour cloner la VM, faites un : tart clone win11 w1 . C'est instantané, et y'a plus qu'à la démarrer avec un tart run w1 --no-graphics.

Avec --no-graphics ça démarre sans fenêtre et vous pouvez alors lancer ce que vous voulez avec tart exec. Ensuite pour tout stopper, un petit tart stop w1, et un tart delete w1 pour supprimer la VM et voilà...

Ce qui ne marche pas

En tout cas, n'en faites pas votre Windows de tous les jours car il n'y a ni son ni accélération graphique, pas de possibilité de suspendre le Windows et la virtualisation imbriquée se fige dès que Windows veut démarrer WSL2 ou Hyper-V.

La commande Get-Tpm confirme aussi l'absence de TPM. Et selon l'auteur, le disque est le point faible de ce Windows ARM 64 sous tart, en partie parce que tart rempli très vite les SSD avec ses logs. Pensez aussi à changer le mot de passe, puisque le compte est admin avec le mot de passe admin, et que SSH est ouvert sur le réseau interne de tart.

Mais pour tester des logiciels Windows ou scripter des trucs, ça tient bien la route.

Source : Mustafa Akin

Hier, le bidouilleur Yash Garg a publié sur son blog une astuce incroyable permettant de diffuser le contenu de sa PS5 sur Discord sans avoir besoin de carte d'acquisition. Son astuce c'est tout simplement de faire croire à sa console que son Mac EST le serveur de Twitch qui doit recevoir la vidéo et comme j'ai trouvé ça cool, je vous explique.

Le point de départ en fait, c'est que Yash diffuse souvent ses parties à des potos sur Discord. Pourtant, cette bonne vieille PS5 ne sait pas partager le stream de ses jeux aussi facilement. Elle peut juste diffuser par défaut vers YouTube et Twitch, à condition d'y être connecté via une option prévue pour ça par Sony. Cela veut dire que pour streamer vers Discord, sa seule vraie option c'est donc la carte d'acquisition, mais celles qui marchent bien coûtent un rein et notre ami ne voulait pas investir.

Il s'est donc mis à utiliser Remote Play qui permet de jouer à la PS5 depuis un Mac. Grâce à ça, la console se connecte à son MacBook et il partage l'écran du Mac sur Discord. Sauf que cela exige de brancher la manette et les écouteurs sur le Mac, et en plus, parfois ça lag de fou au niveau des commandes. Sans parler de la qualité de l'image, qui est choisie par la console, sans possibilité de réglage par l'utilisateur. Pas cool.

Alors, il a imaginé une solution qui je pense va vous intéresser si vous voulez streamer vos parties de PS5 ailleurs que sur Twitch et Youtube. En fait, comme la PS5 ne connaît pas par cœur l'adresse de Twitch, elle la demande aux serveurs DNS à chacune des diffusions. Du coup, celui qui contrôle ce DNS contrôle où se dirige le flux. Yash a donc monté sur son Mac un petit serveur DNS maison qui renvoie tout simplement l'adresse IP du Mac à la place de celle de Twitch.

Il a ensuite paramétré son routeur (un GL.iNet sous OpenWrt) pour forcer l'utilisation de ce DNS pour sa console, sans rien modifier sur la PS5. Cette dernière pousse alors son flux en 1080p à 60 fps vers le Mac, qui le lit, tout ça avec moins d'une seconde de délai avant de le diffuser sur Discord. L'ami Yash s'en sert chaque jour depuis quelques semaines et pour le moment, il n'a pas rencontré le moindre souci.

Par contre, ça ne passe pas avec YouTube car la console envoie bien sa vidéo au Mac, mais vérifie également régulièrement auprès de YouTube que le direct est bien en cours de diffusion. Et comme rien n'arrive, bah elle coupe tout simplement la diffusion au bout d'une minute.

Voilà, si ça vous intéresse, il a fait un article complet où il détaille tout, du DNS au routeur, avec le code de sa petite application qu'il a écrite et qui se loge dans la barre de menu de son Mac. Voilà, si ça vous tente, c'est par ici.

Jev, je ne l'ai jamais utilisé mais Kev, en revanche, je l'ai branché dans mon outil de sélection de sujets de veille pour qu'il me dise notamment si un sujet correspond à ce qui me plaît ou pas. C'est en cours de test, donc je ne vais pas vous livrer de conclusion hâtive sur si ça fonctionne bien ou pas, mais si je vous en parle, c'est parce que Sylvain Peyronnet, le papa du moteur de recherche français Ibou , publie à son tour 3 modèles de la même famille, baptisés ArseneLupin, conçu également pour faire du décisionnel

Pour ceux qui ne suivent pas l'actualité IA, le nouveau truc à la mode en ce moment, c'est Jev, un modèle maison de TypeSafe qui est le premier de ce qu'ils appellent les modèles System One. Au lieu de générer du texte qu'il faut ensuite parser, ce reçoit un état (un texte, un ticket, un objet JSON) et des questions typées : oui ou non (noul), un choix parmi plusieurs options (choice) ou une note sur une échelle (score). Et il renvoie pour chacun de ces choix, des probabilités que votre code peut ensuite exploiter directement pour trier, faire du routage ou prendre des décisions. Par exemple, avec ça, on peut faire de la qualification de tickets de bug ou de l'anti-spam, ce genre de choses.

Alors forcément, suite à ça, des clones ouverts ont débarqué. Le premier que j'ai découvert, c'est Kev , de Jared Palmer, qui s'appuie sur Qwen3.5 et Qwen3.8, soit 0,8 à 27 milliards de paramètres, et laya qui part d'un encodeur ModernBERT-large pour 421 millions de paramètres au total.

Perso, avec Kev dans mon outil de veille, Pour le moment, j'ai un peu de mal à voir si c'est mieux qu'une décision prise par un Qwen 3.6 classique qui génère une réponse textuelle mais Kev a été entraîné sur des textes de 384 tokens au max, et les articles qui tombent dans ma veille dépassent largement ce gabarit...

ArseneLupin, c'est donc la version d'Ibou, annoncée par Sylvain la semaine dernière. Sa v1.1 repose donc sur Qwen3.5-4B, la mini sur Qwen3.5-0.8B et ArseneLupinstral sur Ministral 8B. Les poids sont sous licence Apache 2.0 et le code pour s'en servir et l'intégrer est fourni, mais pas le code d'entraînement ni les données.

C'est encore jeune, donc il n'y a pas eu de benchmark indépendant, mais Ibou en a fait et voici ce qu'ils obtiennent avec une classification d'intentions de recherche en dix catégories. Avec la 1.1, ils obtiennent 50,7 % de bonnes réponses, contre 39,7 % pour la mini et 43,9 % pour Jev 1.13.

Bref, ce sont leurs mesures, mais si elles sont justes, ça veut dire qu'Arsène Lupin est plus efficace que Jev.

Installer ArseneLupin v1.1

Alors pour ce tuto, j'ai pris la v1.1 qui est la plus "balèze".

À la fin de cette section, vous aurez donc un serveur local qui crache du JSON accessible sur le port 8000. Il vous faut Python 3.11 ou une version plus récente et une 10aine de Go libre puisque le modèle complet pèse 9,3 Go en bfloat16.

J'exclus au téléchargement le dossier gguf, qui contient la version 8 bits de 4,5 Go destinée à llama.cpp. Pour démarrer, il faut donc créer un environnement virtuel, puis récupèrer le modèle, et installe le code de service avec la version de transformers qui va bien, c'est à dire la 5.17.0 :

python3 -m venv lupin && source lupin/bin/activate
pip install -U huggingface_hub
hf download IBOU-SEARCH/ArseneLupin-v1.1 --local-dir arsenelupin-v1.1 --exclude "gguf/*"
cd arsenelupin-v1.1
pip install ./code "transformers==5.17.0"

Par défaut, le fichier serve.yaml envoie le modèle sur une carte NVIDIA (cuda:0). Sur un Mac, il faudra donc le basculer sur le GPU d'Apple (mps), et sur une machine sans GPU, ce sera cpu. Je pense que je ne vous apprends rien, vous avez l'habitude,

Ensuite, on lance le serveur. Notez juste que sous Linux, le sed s'écrit sans les deux apostrophes après le -i. :

sed -i '' 's/cuda:0/mps/' serve.yaml
python -m arsenelupin serve --config serve.yaml --calibration calibration/default.json --port 8000

Le serveur ArseneLupin v1.1 à l'écoute sur le port 8000, poids chargés

Au bout de quelques secondes, le serveur écoutera sur 127.0.0.1:8000. Quant à la version GGUF, vous pouvez, si vous voulez, le faire tourner dans un llama.cpp ou équivalent à condition d'en avoir un assez récent qui connait l'archi de Qwen3.5.

Poser vos premières questions

Pour tester, je me suis inspiré de mon outil de veille. On donne au modèle le titre et le résumé d'un sujet et on lui demande si ça parle d'un outil qu'on peut installer, dans quelle rubrique il faut le ranger et à quel point ça pourrait intéresser des gens comme vous, c'est à dire des lecteurs technophiles / bidouilleurs.

Placez donc ça dans un fichier nommé veille.json, dans le dossier du modèle :

{
 "state": {
 "titre": "ArseneLupin, trois modèles de décision publiés par Ibou",
 "resume": "Le moteur de recherche français Ibou publie sur Hugging Face trois modèles qui répondent par oui ou non, par un choix ou par une note, avec des probabilités. Les poids sont sous licence Apache 2.0 et le code de service est fourni."
 },
 "questions": {
 "installable": {"type": "noul",
 "instructions": "Le texte présente-t-il un outil que le lecteur peut installer lui-même ?"},
 "rubrique": {"type": "choice",
 "instructions": "Dans quelle rubrique ranger ce sujet ?",
 "criteria": {"ia": "Intelligence artificielle et modèles de langage",
 "dev": "Outils pour développeurs et infrastructure",
 "securite": "Sécurité informatique, failles et vie privée",
 "materiel": "Matériel, gadgets et bricolage électronique"}},
 "interet": {"type": "score",
 "instructions": "Ce sujet intéressera-t-il un lecteur technophile qui aime tester des outils ?",
 "criteria": ["Pas du tout", "Un peu", "Beaucoup"]}
 }
}

Puis dans un second terminal ouvert dans le même dossier, tapez la ligne de commande curl suivante pour lancer l'évaluation avec ArseneLupin.

curl -s http://127.0.0.1:8000/v1/systemone -H 'Content-Type: application/json' -d @veille.json | python3 -m json.tool

La réponse à la requête de veille : "ia" à 0,72, un oui/non hésitant à 0,53 et un score de 1,47

Comme vous pouvez le voir, pas une ligne de texte généré, chaque question revient avec ses probabilités. On voit donc que la rubrique "ia" l'emporte à 0,72, loin devant "dev" à 0,19, et le niveau "Beaucoup" ressort à 0,59 pour l'intérêt, ce qui donne un score moyen de 1,47 sur une échelle qui va de 0 à 2. Par contre, pour savoir si c'est un outil installable, le modèle hésite quand même un peu avec un timide 0,53 de probabilité pour le oui.

Il renvoie quand même une indication qui est plutôt importante à savoir là décision : "decision": true, car aucun seuil n'est appliqué côté serveur (c'est ce que dit le "decision_status": "unthresholded"). C'est donc à votre code de décider qu'en dessous de 0,7, par exemple, la décision revient à un humain plutôt que de partir dans la base de données automatiquement. Sur mon Mac Studio M4 Max, la requête a pris entre 2,4 et 2,8 secondes pour ces huit options.

J'ai fait un 2ème essai avec un commentaire de spam bien grossier : "Super article !!! Pour gagner 500 € par jour depuis chez vous, cliquez vite sur mon profil, places limitées." La v1.1 le classe en spam à 0,86 et lui colle un ton positif à 0,78, ce qui est vrai au premier degré. Et la version mini du modèle répond deux fois plus vite, en 0,8 seconde, mais descend à 0,76 sur le spam et hésite sur le ton... À voir donc si ça suffit pour vous d'utiliser le modèle mini ou pas, selon vos besoins.

Comment ArseneLupin prend ses décisions

Le code livré avec le modèle se lit facilement et la mécanique est plutôt simple à capter. En fait chaque option devient une question oui/non posée au Qwen affiné, du genre "ce candidat décrit-il la bonne réponse ?".

Ainsi, 4 catégories pour classer un contenu se résume en 4 questions sur le même texte accompagnée d'une petite tête de lecture (2 561 paramètres sur la v1.1) qui transforme le dernier état caché du modèle en score. Un softmax répartit ensuite ces scores en probabilités, et la confidence n'est rien d'autre que la plus forte d'entre elles...

Pour que ça reste rapide malgré toutes ces passes, le serveur lit une seule fois le texte commun aux options, puis calcule toutes les options simultanément.

En fait avec ArseneLupin, on reproduit le principe de Jev mais avec un LLM ouvert (Qwen) en ne lui faisant produire qu'un seul token, limité aux choix proposés. Ce qu'apporte Ibou, c'est donc un modèle LLM ultra affiné (Autant qu'un bon Saint Nectaire) pour ce type d'exercice de prise de décision.

Reste ensuite la confiance à accorder à ces probabilités. Dans le dossier calibration, vous verrez des températures ajustées selon les trois workflows d'exemple fournis par Ibou, et il y a également, dans le fichier default.json, une calibration par défaut. C'est celle-là qu'on a utilisée dans notre exemple, mais vous pouvez aussi régler vous-même votre propre température ajustée selon vos usages.

Maintenant, avant de lui confier quoi que ce soit, posez-vous un peu et donnez-lui une cinquantaine d'exemples que vous avez déjà classés à la main. Comme ça, vous pourrez comparer ArsèneLupin et le LLM que vous utilisez d'habitude pour savoir qui est le plus fiable. N'hésitez pas à y mettre aussi des textes plus ou moins longs parce que le serveur accepte jusqu'à 32 768 tokens par option. Ça tombe bien parce que ça me gênait un peu dans mon intégration avec Kev sur mon outil de veille. Donc je pense que je vais rapidement basculer sur ArsèneLupin pour ma veille en remplacement de Kev.

Et si vous venez de Jev, attention, la requête a la même forme mais pas la réponse !! Pour une question oui/non, Jev renvoie un champ noul là où ArseneLupin renvoie un p_yes, et pour une note, ArseneLupin range ses probabilités dans une liste quand Jev utilise un dictionnaire.

Cela veut dire qu'un client écrit pour l'API de TypeSafe ne lira pas du tout le résultat de ArseneLupin tel quel, donc prévoyez une petite couche de conversion avant de mettre les deux en concurrence sur vos data.

Depuis que X a shooté Nitter et XCancel à grands coups de lettres d'avocat fin août, lire X sans compte c'est redevenu une méga galère. Mais il reste pourtant un outil que plein de gens utilisent sans le savoir, parce qu'il tourne dans les coulisses de Discord et Telegram. Son nom ?

FxTwitter !

À la base, le projet FxEmbed , qui fait tourner FxTwitter et FixupX, sert à réparer les aperçus de liens X. Vous mettez fx devant twitter.com (ou fixup devant x.com) et Discord affiche enfin la vidéo, le sondage ou toutes les images du post. Sauf que derrière, il y a surtout une API publique et gratuite, api.fxtwitter.com, qui affiche n'importe quel post public en JSON sans avoir besoin de compte ou de clé API facturé une couille. Ché Elon !

Alors oui, les rageux diront que x.com affiche encore n'importe quel post isolé à un visiteur déconnecté, même les longs, mais sur un profil, ça s'arrête à 5 posts avant de vous demander de "Continuer sur X". Et surtout, ça ne vous affichera pas les vidéos et ça ne vous permettra pas d'avoir ça sous la forme d'un flux RSS.

Alors que FxTwitter, lui, nous sort tout ça sans avoir à ouvrir x.com !

Lire un post dans le navigateur

Maintenant pour nos tests, prenons un vieux de la vieille, un vétéran, le post numéro 20 de @jack, publié le 21 mars 2006 et dont l'URL est x.com/jack/status/20. Le nombre à la fin, c'est l'identifiant du post.

Collez tout simplement cet identifiant au cul de api.fxtwitter.com/2/status/ et ouvrez ça dans votre navigateur :

https://api.fxtwitter.com/2/status/20

Et vous obtiendrez un gros pavé en JSON avec dedans le texte du post dans le champ "text", l'auteur dans "author", et un peu plus bas vous trouvez les likes, les reposts, les réponses et la date.

Le post 20 de @jack vu par l'API : le texte dans le champ text, l'auteur juste en dessous.

Et si vous avez la flemme de recopier l'identifiant (vous êtes toujours dans l'abus, vous ^^), remplacez simplement x.com par api.fxtwitter.com dans l'adresse complète du post et voilà ! Ça marche à tous les coups, même si c'est le retour de l'ancienne version de l'API, conservée pour la compatibilité.

Le texte et sa traduction avec curl

Pour utiliser ça avec un script, je vous conseille d'utiliser curl pour faire la requête et jq pour trier tout ça ( jq, c'est le petit utilitaire qui extrait un champ précis d'un JSON ).

Ainsi, pour n'afficher que le texte du post :

curl -s "https://api.fxtwitter.com/2/status/20" | jq -r '.status.text'

Et si le post n'est pas en français, ajoutez ?lang=fr à l'adresse et hop, magie magie, l'API glisse alors un bloc "translation" dans la réponse, avec le texte en français :

curl -s "https://api.fxtwitter.com/2/status/20?lang=fr" | jq -r '.status.translation.text'

Le texte d'origine du post 20, puis sa traduction demandée avec ?lang=fr.

La traduction provient de X lui-même quand elle existe (sur ce post, le champ "provider" indiquait "grok"), sinon l'API se rabat avec joie sur un service de traduction. Et pour un profil, c'est le même principe avec /2/profile/ : api.fxtwitter.com/2/profile/jack qui affichera la bio de @jack, son nombre d'abonnés et sa date d'inscription. Les autres "routes" qui récupèrent les fils, les abonnés ou les médias d'un compte sont dans la documentation de l'API .

Elle est pas belle la vie ?

Récupérer une vidéo

Maintenant, on va rentrer dans le dur parce qu'ici, pour récupérer une vidéo, vous n'avez pas besoin d'API. Suffit de jouer avec l'adresse.

Mettez d. devant fxtwitter.com et le lien vous renverra directement le fichier, sans HTML autour. Avec curl, ça donne ça (le -L sert à suivre la redirection) :

curl -L -o video.mp4 "https://d.fxtwitter.com/NASA/status/2102748685792596449"

Grâce à ça, on peut par exemple récupérer le MP4 de cette vidéo bien kitchou de 30 secondes de la NASA. Et ajouter .mp4 à la fin d'une adresse fxtwitter.com fera la même chose. Et pour choisir la qualité, jetez un œil au JSON du post, où la liste des formats de media.videos donne chaque version de la vidéo avec son adresse et son bitrate.

Suivre un compte en RSS

Dernier truc que je trouve pratique avec cet outil c'est que chaque compte public peut avoir son flux RSS. Il suffit d'ajouter /feed.xml après le nom du compte :

https://fxtwitter.com/korben/feed.xml

Collez ensuite ça dans votre lecteur RSS et vous suivrez le compte X de vos rêves sans avoir à y mettre les pieds. Le flux remonte ainsi les 90 derniers posts par défaut, et le paramètre ?count= permet de réduire ce nombre ou de l'augmenter jusqu'à 100 maximum. Et si vous remplacez feed.xml par media.xml vous ne verrez dans le flux que les posts contenant des photos ou des vidéos. Et si vous ajoutez ?with_replies=1 vous verrez aussi les réponses.

Ce qui coince

Maintenant ce qui peut être relou, c'est que l'API n'encaisse que 1 000 requêtes par minute et par adresse IP. Par contre, si vous pensiez absorber tout x.com sans la moindre vergogne, vous allez vite vous retrouver coincé.

Attention aussi au domaine que vous tapez. Les seuls officiels sont fxtwitter.com, twittpr.com, fixupx.com, xfixup.com et fxbsky.app pour Bluesky. Je précise ça parce qu'il y a eu, par exemple un fxtwiter.com avec un t en moins, qui a été signalé sur le dépôt du projet et qui renvoyait les gens vers des arnaques.

Comme d'hab, une faute de frappe et c'est le drame... Soyez très vigilants.

Maintenant, si vous êtes un petit peu curieux comme moi, vous vous êtes sûrement demandé comment FxTwitter récupérait tout ça ??

Eh bien, comme le fait Nitter, ou plutôt comme le faisait Nitter , il récupère les données en utilisant de vrais comptes X sur lesquels il répartit les requêtes. Et comme c'est ce qui a été reproché à Nitter, je me dis qu'il y a des chances qu'à un moment FxEmbed soit visé aussi.

On verra bien, mais si un jour le service tombe, sachez que le code est bien dispo sous licence MIT, donc vous pouvez le faire tourner chez vous sans problème dans un Docker. Et si vous n'utilisez pas de compte X connecté dessus, ça marchera quand même avec, c'est vrai, des limites de requêtes plus basses et surtout sans accès au contenu NSFW (Et ça, je sais que ça vous rend super triste.)

Source : GitHub

Ce matin, lors de mon live sur Twitch , je présentais un petit peu les nouveautés que j'avais mises en place sur mon site, et parmi elles, les kits IA.

Et je me suis dit que c'était un peu con parce que je ne vous en ai pas parlé publiquement. Donc on va régler ça ici, maintenant, tout de suite !

Vous le savez, je suis toujours à la recherche d'idées un peu sympas, d'innovations, de trucs un peu cool à faire sur mon site. Et comme il m'arrive souvent de faire des tutoriels pour vous expliquer comment installer telle ou telle saloperie sous Linux, sur un Docker, sur un Windows, etc., je me suis dit qu'en plus du tutoriel, ce que je pouvais vous proposer, c'était des petits fichiers zip qui embarquaient tout le savoir de mon tuto.

Des kits avec une vraie expérience derrière, afin que votre agent IA puisse installer le même outil que moi en autonomie complète. Voici donc le genre d'encadré que vous pourrez retrouver dans certains de mes articles :

Comme ça, au lieu de suivre le tuto et de taper vous-même les lignes de commande, vous donnez mon zip et le prompt qui va bien fourni avec à votre agent, qui peut être Claude Code, ChatGPT, Codex ou encore des choses open source et locales, comme par exemple une combinaison de Qwen 3.7 avec OpenCode. Et ensuite, celui-ci se débrouille sur votre machine pour faire tourner l'outil qui vous fait envie.

Maintenant, pour produire ces kits IA, je ne fais pas ça n'importe comment : ça repose sur de vraies installations réalisées de A à Z, ça repose aussi sur la doc officielle du projet, ce qui permet comme ça, d'anticiper les problèmes que vous pourriez avoir sur votre machine. Comme ça, l'agent sait ce qu'il a à faire, si jamais il rencontre un petit blocage parce que vous avez un souci de permission ou qu'une version de Python n'est pas la même, etc. Et cela peu importe l'OS.

Et comme dans le kit, ce sont essentiellement des fichiers Markdown accompagnés de scripts Python, Shell, PowerShell, etc, vous pouvez évidemment tout relire, tout vérifier...etc.

Voilà, si ça vous intéresse, vous pouvez retrouver l'ensemble des kits IA ici . Il n'y en a pas encore beaucoup, mais à chaque fois que je ferai un tuto, j'en ferai un.

Par contre, pour en profiter, il faudra évidemment être abonné à mon Patreon ^^.

Enjoy !

L'équipe Next-gen Kaldi de Xiaomi a sorti OmniVoice, un modèle de synthèse vocale qui parle 646 langues et qui est capable de "recopier" une voix à partir d'un extrait de huit secondes minimum. Et tout ça en local et gratuitement !

Le français y est d'ailleurs la cinquième langue du corpus d'entraînement, avec 23 675 heures d'audio de référence sur les 581 000 qu'ils ont avalées. Autant dire que le modèle a entendu du français toute sa vie, et ça s'entend au résultat.

Voilà donc comment cloner votre propre voix, du début à la fin. Comptez 3,3 Go de poids que la première génération ira chercher toute seule, donc prévoyez une connexion pour ce coup-là, et quelques minutes de manipulation une fois qu'ils sont sur votre disque.

Installer OmniVoice

Pour cela, il vous faut Python 3.10 à 3.13 (PyTorch 2.8 n'existe pas encore pour 3.14, vous vous prendriez un "No matching distribution found"), et un environnement isolé (sinon vous allez casser autre chose). Sur Mac, les deux lignes suivantes suffiront puisque le modèle utilise le GPU intégré via MPS :

python3 -m venv ~/omnivoice-env && source ~/omnivoice-env/bin/activate
pip install torch==2.8.0 torchaudio==2.8.0
pip install omnivoice num2words

Sur Linux et Windows, ça devra se faire avec une carte NVIDIA (sous Windows, l'environnement s'active avec omnivoice-env\Scripts\activate) sauf que PyTorch doit venir de l'index CUDA, donc remplacez la deuxième ligne par celle-ci :

pip install torch==2.8.0+cu128 torchaudio==2.8.0+cu128 --extra-index-url https://download.pytorch.org/whl/cu128

Notez que sans carte graphique du tout, ça marche quand même. J'ai rejoué la même installation dans un conteneur Linux en processeur seul, elle passe sans rien changer... mais il m'a fallu cinq fois la durée de l'audio en temps de calcul.

Une fois installé, pour savoir que c'est en place, tapez omnivoice-infer --help et là, la liste des options doit s'afficher, sans la moindre erreur d'import. Le num2words de la troisième ligne, lui, ne sert qu'au chemin Python dont je parle plus bas, alors gardez-le sous le coude.

Les 8 secondes qui font tout

C'est l'étape que tout le monde bâcle et c'est pourtant celle qui est décisive pour avoir un bon résultat. Le projet recommande entre 3 et 10 secondes, pas plus car au-delà, ça ralentit le calcul et ça dégrade le clonage. Prenez donc un passage où vous parlez sans blanc, sans "euh", sans musique derrière, et découpez-le proprement comme ceci avec ffmpeg (ou autre logiciel de votre choix) :

ffmpeg -i mon-enregistrement.m4a -ss 12 -t 8 -ac 1 -ar 24000 moi.wav

La qualité de cet extrait est très importante donc si vous enregistrez votre voix, mettez bien le micro près de la bouche, dans une pièce sans écho, et évitez les MP3 récupéré à partir de YouTube .

Écrivez ensuite dans un fichier ce que dit exactement l'extrait, mot pour mot. Vous pouvez sauter cette étape (le modèle transcrit alors tout seul avec Whisper), sauf qu'il téléchargera 1,6 Go de plus pour ça et qu'il se plante parfois sur un nom propre, ce qui abîme le clonage.

C'est le moment de générer !

Avant de taper quoi que ce soit, relisez bien votre texte et réécrivez les chiffres en toutes lettres. La ligne de commande n'a aucune option de normalisation, donc "2345" sortira n'importe comment alors que "deux mille trois cent quarante-cinq" se lit tout seul. C'est du côté Python que la normalisation se fait, avec normalize_text=True, la langue passée en language="fr" et le num2words de tout à l'heure... sans la langue, votre texte français part chez le normaliseur anglais qui réclamera même une lib sans version précompilée pour les Mac Apple Silicon.

Voici la commande complète :

omnivoice-infer --model k2-fsa/OmniVoice \
 --text "Bonjour, ceci est un test de clonage de voix en français réalisé avec OmniVoice." \
 --ref_audio moi.wav --ref_text "$(cat moi.txt)" \
 --language fr --num_step 32 --output ma-voix.wav

Vous devez voir passer un "Saved to ma-voix.wav" au bout de quelques secondes. Sur mon M4 Max, j'ai compté 4 à 6 secondes de calcul pour 5,4 secondes d'audio, et moitié moins avec --num_step 16 au prix d'un peu de netteté. Au passage, le facteur 40 fois plus rapide que le temps réel qu'annonce le projet sur son site, ça a été mesuré sur un H100 avec des noyaux d'accélération maison, et pas sur un ordi de bureau...

Si la ligne de commande vous rebute, vous pouvez aussi passer par la commande : omnivoice-demo --ip 127.0.0.1 --port 8001 qui permet de faire la même chose mais dans le navigateur, avec le bouton d'import pour l'extrait et un menu déroulant pour la langue. Pensez juste à lancer export GRADIO_ANALYTICS_ENABLED=False avant, parce que l'interface web appelle les serveurs de Gradio au démarrage et qu'on n'a pas envie de leur filer nos data à ceux-là.

L'audio, lui, ne bouge pas de votre machine.

L'extrait de référence de 8 secondes chargé à gauche, la langue calée sur French, et la sortie de 5 secondes à droite une fois le clonage terminé.

Et si vous voulez vraiment débrancher la machine du réseau, faites-le dans le bon ordre, sinon la commande de génération part chercher les poids et se vautre sur un httpx.ConnectError suivi d'un LocalEntryNotFoundError. Récupérez donc le modèle d'abord, dans un dossier bien à vous :

hf download k2-fsa/OmniVoice --local-dir ~/omnivoice-modele

Ensuite vous coupez tout et vous passez ce dossier à --model à la place du nom du dépôt. Ça marche même sur une machine qui n'a jamais vu Internet, il suffit d'y copier le dossier. Et si vous préférez garder le cache par défaut, un export HF_HUB_OFFLINE=1 fait la même chose. J'ai rejoué la génération avec toutes les sorties réseau refusées par le système, le fichier sort quand même en 8 secondes... donc non, votre voix ne part chez personne.

Maintenant, une fois que c'est fait, écoutez le fichier avant d'en faire quoi que ce soit, parce que le modèle avale parfois des morceaux de phrase. Sur mes 24 générations de la même phrase, 5 ont perdu ou déformé un mot. C'était presque toujours le premier ou le dernier... et ce n'est pas une surprise, c'est un bug connu de l'outil. Faut donc relancer parfois plusieurs fois pour avoir un résultat OK.

Dernier truc pour ceux qui passeront par Python : la voix se sauvegarde une fois pour toutes. model.create_voice_clone_prompt() puis .save("ma_voix.pt") produisent un fichier minuscule que les sessions suivantes rechargeront sans repasser par l'extrait ni par la transcription. Regénérez alors une phrase avec, et comparez à l'oreille : si c'est bien la même voix, vous pouvez ranger le WAV de référence.

Voici l'extrait que j'ai généré avec ma voix. Ces 6 secondes d'audio ont pris 14 secondes à la génération sur mon Mac Studio :

Pour fabriquer une application Windows native, le passage par Visual Studio était jusqu'ici la voie normale. Mais c'était sans compter sur Microsoft qui a publié winapp , un outil en ligne de commande qui permet de faire tout pareil directement depuis un terminal : il crée le projet, le construit, le lance avec son identité de paquet et sort le résultat sous la forme d'un fichier d'installation MSIX.

C'est encore estampillé en version "expérimentale" par ses auteurs, mais ça fonctionne déjà très bien pour des trucs basiques. C'est pour ça qu'aujourd'hui, je vous propose un petit tuto pour afficher un Hello World dans une vraie fenêtre Windows. Vous allez voir, c'est fastoche !

Ce qu'il faut avant de commencer

Il vous faut donc Windows 10 version 1809 au minimum, le mode développeur activé dans Paramètres, Système, Options avancées, et le SDK .NET 10 ou plus récent. Visual Studio, non par contre, y'en a pas besoin. Les deux installations se font via winget, dans un terminal normal :

winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget

Faites ensuite un winapp --version et vous saurez si le CLI répond.

Créez le projet

La commande new fabrique l'application à partir des modèles WinUI 3 officiels, qu'elle télécharge toute seule dès qu'on la lance. Sans option elle vous pose des questions, mais avec celles que je vous mets ci-dessous, elle ne demandera rien et prendra le modèle le plus dépouillé du lot :

winapp new --template winui --name HelloKorben --use-defaults
cd HelloKorben

Vous récupérez alors un projet C# complet, avec son manifeste de paquet et ses icônes. Et surtout, le modèle winui vous donne une fenêtre vide, ce qui tombe bien puisqu'on va écrire dedans. Notez que le pack de modèles est encore publié en 0.0.6-alpha, donc si un nom de fichier a bougé depuis, winapp new --list vous sortira la liste de ce que le vôtre propose.

Écrire le Hello World

Attention, là y'a un petit piège ! Le fichier qui décrit la fenêtre s'appelle MainWindow.xaml, sauf que ce n'est pas celui-là qu'il faut toucher. Ouvrez plutôt MainPage.xaml, qui est à la racine du projet, et remplacez son <Grid /> vide par ces quelques lignes :

<Grid>
 <TextBlock Text="Hello World !"
 HorizontalAlignment="Center"
 VerticalAlignment="Center"
 FontSize="48" />
</Grid>

Ensuite, un petit winapp run construira le projet, l'enregistrera auprès de Windows avec une identité de paquet qui pointe droit sur votre dossier de build, et le lancera. Votre fenêtre s'ouvre alors avec le Hello World au milieu :

winapp run

La fenêtre HelloKorben ouverte par winapp run, et derrière, le terminal qui vient de la construire en 12 secondes

Bon, là, on a fait un Hello World, mais bien sûr, si vous faites chauffer une IA là-dessus, vous pouvez faire des trucs un peu plus complexes sans forcément savoir coder, et tout ça, une fois encore, sans Visual Studio.

Sortir le fichier d'installation

Maintenant, à quoi bon empaqueter ?

Cette identité de paquet, ce n'est pas de la paperasse. En fait c'est elle qui ouvre à votre application les notifications natives, les associations de fichiers, les protocoles maison et les API d'IA locale de Windows. Donc si vous voulez du sérieux, il faut publier l'application compilée dans un dossier, et ça, c'est possible comme ceci directement dans votre terminal :

dotnet publish -o ./publish

L'empaquetage fabrique au passage un certificat de développement et l'installe dans le magasin Personnes de confiance de la machine mais faut que je vous prévienne, la commande qui suit réclame un terminal ouvert en admin dans lequel il faudra refaire le cd vers votre dossier de projet pour qu'il s'y retrouve.

winapp pack ./publish --generate-cert --install-cert

Le MSIX signé sort dans le dossier du projet, nommé d'après le GUID du paquet

Vous obtenez alors un .msix signé, nommé d'après l'identité du paquet, sa version et son architecture, qui s'installe chez vous d'un double clic. Et cette identité, le modèle la génère sous forme de GUID : ne cherchez pas le nom de votre application dans le nom du fichier. Par contre, ne l'envoyez pas tel quel à un collègue, parce que le paquet réclamera le runtime Windows App SDK. Ajoutez --self-contained à la commande pack et le runtime partira dans le paquet. Le certificat, lui, reste un certificat de développement local : sur le PC d'en face, Windows refusera le paquet tant que ce certificat n'y sera pas installé aussi.

Maintenant, si vous vous demandez à quoi sert vraiment ce CLI, c'est surtout l'étape MSIX qui sera moins douloureuse car vous n'aurez pas besoin de lancer Visual Studio.

Source : Neowin

Depuis ce week-end, bonne nouvelle les zamis, puisque ce bon vieux ffmpeg sait maintenant fabriquer des images qui n'ont jamais été filmées. Oui oui ! Et ça c'est possible grâce à un filtre qui s'appelle fruc_vulkan, qui permet de calculer le mouvement entre deux images grâce au bloc dédié des GeForce RTX, pour ensuite synthétiser ce qui manque entre les deux. Grâce à ça, un 24 images par seconde ressort sans souci en version 60 images par seconde.

La cadence de sortie se paramètre, donc vous pouvez aussi faire du 25 vers du 50, du 30 vers 60, ou n'importe quelle valeur intermédiaire. C'est donc beaucoup plus souple que le filtre équivalent côté AMD, frc_amf, qui ne sait que doubler la fréquence et ne fonctionner qu'en DirectX...

Fabriquer ce genre d'images intercalaires n'a rien de neuf, cela dit... L'outil RIFE convertissait déjà du 24 fps en 96 en 2020. Mais ce qui change ici, c'est qu'il n'y a plus de chaîne externe, plus d'aller-retour par des milliers de PNG, puisque tout tient dans le graphe de filtres, entre le décodage et l'encodage.

Le filtre logiciel historique de ffmpeg, minterpolate, existe pourtant depuis des années mais c'était loin d'être du temps réel. Alors que là, le vrai gain avec cette nouvelle feature, c'est qu'on passe en full temps réel. Ça veut dire que sur un catalogue à réencoder, l'interpolation cesse d'être l'élément qui bloque toute la chaîne de conversion.

Pour l'essayer il vous faut une RTX 30 ou plus récente. Il faut aussi compiler une version de développement car ce filtre est arrivé après la sortie de ffmpeg 9.0, ce qui veut dire que pour le moment, il n'est dans aucune release et ne sera dans aucun paquet avant la prochaine.

La commande suit ensuite le motif habituel des filtres Vulkan, qui veulent les images en mémoire GPU :

ffmpeg -init_hw_device vulkan=vk:0 -filter_hw_device vk -i entree.mp4 -vf "format=yuv420p,hwupload,fruc_vulkan=fps=60,hwdownload,format=yuv420p" sortie.mp4

L'auteur du filtre prévient quand même qu'en 2160p24, les réglages par défaut ne suivront pas en temps réel et qu'il faudra alors descendre la qualité d'estimation du mouvement. Ça s'écrit comme ceci :

fruc_vulkan=fps=60:perf=medium:grid=2

En traitement par lots maintenant, la question ne se pose pas, c'est juste plus lent.

Maintenant, les pros de l'encodage, redescendez de votre chaise parce que j'ai quand même quelques mauvaises nouvelles... Tout d'abord, on n'a aucune stat indépendante sur le débit ou la qualité. Et il y a aussi un défaut que l'auteur du patch documente lui-même... En fait, dans les zones sans texture, le moteur invente un mouvement faux mais cohérent, qui laisse des "fantômes" autour des objets. La parade existe heureusement, mais c'est une heuristique, qui demande quelques réglages à la main sur des échantillons.

Et il y a aussi un coût qu'on oublie... Car doubler la cadence, c'est donner deux fois plus d'images à avaler à l'encodeur, donc, il y a toujours une espèce de goulot d'étranglement. Et puis après il y a le rendu... un film de cinéma en 24 images par seconde qu'on monte à 60 prend immédiatement un aspect téléfilm que les cinéastes détestent !! Imaginez l'Odyssée de Nolan avec l'aspect visuel de Plus Belle La Vie... Ahahaha. Après sur de l'animation ou un ralenti, ça se défend bien sûr mais sur du cinéma, c'est un choix à prendre et pas une amélioration. En tout cas, c'est mon avis.

Ah et dernier point, parce que la confusion est déjà partout dans les commentaires sur le net : Tout ça se passe à l'encodage ! Je répète : A L'ENCODAGE ! Le fichier qui sort de ffmpeg est une vidéo NORMALE. Absolument personne n'aura besoin d'une carte graphique GeForce pour la regarder ! OK ? 😘

Source : Phoronix

Hier, je suis tombé sur ce tweet :

Kuber, un développeur de 19 ans a demandé à Claude Code, de lui pondre un pilote pour sa vieille imprimante pour macOS. Et visiblement, ça a intéressé pas mal de monde puisque le tweet a fait +3 millions de vues.

Il a ensuite publié le dépôt sur Github et la transcription complète de la session. Et ce que ça raconte c'est surtout un bras de fer avec macOS, et un montage bidouillesque au possible qui finit par tenir sur une machine virtuelle Linux et un daemon root.

Pour la petite histoire, son imprimante est une HP Laser 1008a. C'est en réalité une Samsung rebrandée car HP a racheté la division impression de Samsung , il y a une dizaine d'années. Et ces machines parlent un langage un peu niche qui est le SPL3. C'est un langage maison qui n'est ni du PostScript ni du PCL standard. Et comme vous vous en doutez, HP n'a jamais sorti de pilote macOS pour cette gamme. Donc officiellement, cette imprimante ne peut pas imprimer depuis un Mac.

La mission a donc consisté à recompiler SpliX, un pilote libre qui parle le SPL3 et à se battre avec macOS pour qu'il puisse causer via l'interface USB de l'imprimante déclarée en IPP-over-USB. Il a fallu ensuite ruser en mettant en place une VM Linux afin de faire tourner h24 un codec de HP uniquement dispo sous Linux. Et voilà ! La file d'impression envoie le travail sur un port local, un daemon root le récupère, le fait passer par le codec dans cette VM, et écrit le résultat directement sur l'USB.

Bref, ça marche et ça imprime maintenant depuis n'importe quelle application.

Alors vous l'aurez compris, ce n'est pas vraiment un dev de pilote pour macOS mais plutôt une espèce d'assemblage de différents éléments pour la plupart libres, afin de réussir à imprimer sous macOS avec ce modèle d'imprimante. Mais ce qui est intéressant, c'est que le mainteneur de SpliX a débarqué sur le dépôt de Kuber avec une archive de fichiers de test et une série de questions. Cela veut dire que si lui et Kuber trouvent l'octet qui diffère, la VM Linux et le daemon root vont disparaître et il ne restera plus qu'un paquet tout ce qu'il y a de plus classique à installer.

Voilà c'est finalement la seule partie de l'histoire où on répare vraiment quelque chose. Mais ça reste quand même une belle histoire où l'IA permet de s'affranchir des limites techniques imposées par les fabricants et éditeurs de logiciels. Et ça, moi j'adore !

Source : le fil de Kuber sur X , avec la transcription intégrale de la session et le dépôt du projet .

Allez, on va faire un jeu. Cherchez un disque dur externe sur Amazon et regardez où pointe le premier lien de la page. Bingo, ça part sur une adresse en /sspa/click, autrement dit un emplacement publicitaire. Et c'est pas le mieux noté, c'est pas le moins cher, non, c'est juste celui qui a payé le plus pour être là.

Et moi, ce qui me saoule vraiment, c'est que les filtres n'y peuvent rien.

Pour remédier à cela il faut sortir l'artillerie. J'ai d'abord pensé à faire un filtre uBlock Origin, puis à me coder une extension Firefox, avant de me rappeler que Tampermonkey tournait déjà dans mon navigateur.

Direction le repo Greasy Fork, donc, où traîne un script qui fait exactement ça . Une cinquantaine de règles CSS, qui dégagent du DOM les résultats sponsorisés de la recherche, les carrousels promo, les encarts publicitaires de la fiche produit, l'upsell Prime et les bannières de marque.

On passe ainsi de ça :

À ça :

Et ça fonctionne super sur toutes les versions d'Amazon, y compris Amazon.fr.

Trois réglages attendent dans le menu du gestionnaire de scripts. Un compteur qui affiche en bas de page ce qui a été retiré et pourquoi, une journalisation console pour les curieux, et une option qui redirige les pages de navigation vers la vraie liste de résultats.

Attention quand même à ce qui saute en plus des pubs. Le bloc "Les gens qui ont acheté ça, ont aussi acheté ça". Le script s'attaque aussi à Rufus, l'assistant d'achat maison et côté installation, il vous faut Tampermonkey, Violentmonkey ou Greasemonkey. Sur Firefox, ça s'arrête là. Par contre sur Chrome, depuis la version 138, il faut en plus activer un switch "Allow User Scripts" sur la fiche de l'extension, coupé par défaut sur toute extension fraîchement installée.

Voilà, j'espère que ça vous aidera à avoir un Amazon un peu plus propre. Maintenant, n'oubliez pas, Amazon, c'est le mal, donc si vous avez les moyens de payer 2x plus cher la même chose et que vous aimez passer votre vie dans les transports ou en bagnole à faire une espèce de chasse au trésor à travers toute la ville, pour trouver le produit qu'il vous faut, le mieux reste encore et toujours d'acheter dans des magasins physiques. Lol.

Je m'en doutais un peu mais c'est confirmé, derrière chaque session GeForce NOW tourne un vrai Windows, et cette machine virtuelle est moins verrouillée qu'elle en a l'air. En effet, une démo du moddeur Zortos montre le service qui s'ouvre non pas sur un jeu, mais sur un bureau complet, avec barre des tâches, menu démarrer et icônes.

La manip passe par le jeu Trove... Pendant le lancement, Zortos ouvre le navigateur web intégré de Steam, se balade dans les dossiers de la machine, récupère un exécutable et remplace quelques chemins dans le répertoire du jeu. Au démarrage suivant, Windows s'affiche alors à la place du jeu. Tout ça repose sur SalsaNOW , un outil open source signé dpadGuy.

Une fois le bureau ouvert, la machine encaisse à peu près tout ce qui ne réclame pas de droits administrateur. Zortos y a fait tourner Wallpaper Engine pour les fonds animés et LM Studio avec le modèle Gemma 4. Et pour les logiciels qui exigent une installation privilégiée, ils peuvent sans souci être préparés en version portable sur son propre PC, puis décompressés là-haut.

Reste que ce bureau est un bac à sable. La session tourne en compte utilisateur simple, donc pas de droits administrateur, pas d'anticheat noyau, et beaucoup d'installations qui finissent sur un refus d'accès.

L'autre mur, c'est la persistance. Sans l'option de stockage payante, tout disparaît à la déconnexion. Et même en la prenant, la machine ne conserve que vos Documents, l'AppData du compte, baptisé kiosk, et le contenu du lecteur I:. Tout le reste repart de zéro à la session suivante, et fermer l'explorateur de fichiers coupe la connexion sur-le-champ.

Dernier filtre, et pas le moindre, ça ne fonctionne que sur les abonnements payants, ceux dont je détaillais les formules quand Nvidia a sorti son client Linux natif . L'offre gratuite est hors jeu, tout comme les GeForce NOW opérés par les partenaires alliance.

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

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

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

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

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

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

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

Étape 1 : Installer Rapid-MLX

Le plus simple, c'est Homebrew :

brew install rapid-mlx

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

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

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

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

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

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

Les paliers recommandés par le projet :

RAM	Modèle conseillé
8 à 23 Go	`qwen3.5-4b-4bit`
24 à 47 Go	`gpt-oss-20b-mxfp4-q8`
48 à 95 Go	`qwen3.6-35b-8bit`
96 Go et plus	`gpt-oss-120b-mxfp4-q8`

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

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

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

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

Étape 3 : Vérifier que ça tourne

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

rapid-mlx chat

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

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

Étape 4 : Lancer le serveur

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

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

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

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

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

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

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

Étape 5 : Brancher Claude Code dessus

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

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

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

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

Quand ça coince

Le réflexe à avoir avant de chercher ailleurs :

rapid-mlx doctor

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

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

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

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

Merci à Philobois pour le lien !

*-- Contient des liens affiliés -- *

La Steam Machine de Valve vient à peine d'arriver dans les salons que le youtubeur ETA Prime l'a déjà éventrée sur son établi. Et je sais pas vous, mais moi j'ai bien envie de voir ça avant de lâcher les 1039 euros qu'elle va couter. Ce petit cube vient de sortir d'usine avec ses 16 Go de mémoire et un SSD de 512 Go ou 2 To, et la vraie question que tous les geeks se posent c'est ... roulements de tambour ... : Est-ce qu'on peut l'ouvrir et bidouiller dedans ?

ET BIEN OUI ! Et c'est même plus facile que ce que vous pensez !!!

À tous les nostalgiques de la Nintendo 64 et notamment de Super Mario 64, j'ai un petit truc cool à vous montrer. Tobi Friedly vient de sortir un portage du jeu sur Nintendo DS, et pas n'importe lequel, puisque celui-ci tourne sur la vraie console de 2004, et pas seulement sur la DSi qui embarquait quatre fois plus de mémoire vive. Et comme si ça suffisait pas, il y a même mis un mode deux joueurs.

C'est vrai que le truc qui coince d'habitude, c'est que la DS originale n'a pas assez de RAM pour charger toute la ROM du jeu d'un coup. Tobi a donc contourné le problème en faisant streamer les assets à la demande via NitroFS , le système de fichiers des cartouches DS.

Du coup, au lieu de tout balancer en mémoire d'un bloc, le jeu va piocher les niveaux et les textures au fur et à mesure qu'il en a besoin. C'est grâce à cette méthode ingénieuse qu'il a pu débloquer son portage sur la vraie DS, là où le portage précédent de Hydr8gon restait coincé sur DSi faute de place.

C'est d'ailleurs grâce au boulot de Hydr8gon que Tobi a construit le sien, en le modifiant et en l'adaptant suffisamment pour qu'il tourne sur tous les modèles de DS.

Au passage il a rebouché aussi deux bugs qui traînaient, et maintenant le jeu est finissable à 120 étoiles, et le son fonctionne enfin (avant c'était silence radio). La stabilité générale a aussi pris un bon coup de polish.

Le mode multijoueur, lui, réclame deux DS, chacune avec sa propre copie du jeu. C'est du coop local, parfait pour explorer le château à deux ou juste pour déconner ensemble, entre moustachus, dans un niveau de Mario.