Connexion
Meeting Recorder , c'est un enregistreur de réunions pensé pour Omarchy, la distribution Linux de DHH basée sur Arch et Hyprland. Et y'a pas besoin d'inviter à bot chelou dans votre visio puisque l'app se contente d'écouter votre micro et ce que joue votre ordinateur. Donc ça fonctionne avec n'importe quel logiciel de réunion, et tout est ensuite transcrit sur votre machine, 100% en local
Le micro et le son de l'ordinateur sont ainsi enregistrés sur deux pistes séparées, et deux jauges vous montrent avant de lancer que les deux arrivent bien. C'est comme ça que l'outil sait qui parle... ce qui passe par le micro, c'est vous, et ce que joue l'ordinateur, ce sont les autres. Et s'il y a plusieurs personnes en face, Nemotron 3 Diarization, un modèle de NVIDIA qui tourne en local, sépare simplement leurs voix en "Remote 1", "Remote 2"...etc, que vous pouvez ensuite renommer.
L'écran de fin, Maya au micro, Tom côté ordinateur, et les deux pistes dans la forme d'onde
À la fin de l'appel, c'est whisper qui transcrit tout ce basar, avec le modèle large-v3-turbo par défaut (environ 1,6 Go à télécharger une seule fois), pendant qu'une animation façon années 90 vous fait patienter. Et pas besoin de carte graphique puisque d'après l'auteur, le processeur d'une machine récente boucle un appel court en quelques secondes. Ah et puis trop cool, le français fait partie des langues proposées, donc vous pouvez l'utiliser si vous avez séché les cours d'anglais.
Vous récupérez ensuite le texte, avec l'heure et l'intervenant sur chaque ligne, et un lecteur audio au-dessus. Cliquez alors sur une ligne et la lecture repartira de là. Et si whisper s'est gourré, vous survolez la ligne pour la corriger, la donner à l'intervenant suivant ou la supprimer. Chaque réunion finissant dans un simple dossier de ~/Documents/Meetings, avec l'audio et un fichier transcript.md, vous pouvez tout récupérer et même glisser sur la fenêtre un vocal ou un appel enregistré ailleurs, et Nemotron pourra y détecter jusqu'à 8 voix sans problème.
Pour les réunions de trois minutes ou plus, il y a aussi du chapitrage et c'est l'agent de code réglé par défaut dans Omarchy (Claude Code, Codex...) qui découpe la transcription une fois que c'est terminé. Donc, si vous ne voulez pas que ça parte dans le cloud, il faut prendre le temps de ne régler aucun agent par défaut sur Omarchy.
Et n'oubliez pas non plus de prévenir les gens en début de réunion, car l'article 226-1 du Code pénal punit l'enregistrement de paroles privées sans leur consentement. Hé ouaiiiis !
Côté installation, l'outil est dans le dépôt de paquets d'Omarchy, pour l'instant uniquement sur le canal edge. Sinon, en attendant la prochaine version d'Omarchy, ce script d'une ligne installera le même paquet.
Bref, c'est l'un ou l'autre :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) yay -S omarchy-meeting-recorder
ou
curl -fsSL https://raw.githubusercontent.com/jankeesvw/omarchy-meeting-recorder/main/install.sh | bash
Attention, au moment où j'écris ces lignes, la version 1.1.1 plante dès la première transcription sur les processeurs sans AVX-512, un Ryzen 5 5500 ou un Core Ultra 9 285K par exemple. L'audio est bien enregistré, mais vous n'aurez pas de texte, parce que le binaire publié a hérité des instructions AVX-512 de la machine qui l'a compilé. Heureusement, un contributeur a déjà proposé un correctif, donc, soyez patient. Mais si vous êtes vraiment pressé, il faudra juste compiler vous-même l'appli (cargo build --release, les étapes sont dans le README).
Et si vous n'êtes pas sous Omarchy ? Faut chialer ?
Non, car l'app prendra alors l'apparence standard de libadwaita, mais sans l'agent par défaut d'Omarchy. Donc adieu les chapitres. Sous Windows, l'application Meetily fait le même genre de travail en local, Avec mon application macOS Kassis , on peut faire ça aussi. Il suffit de glisser-déposer l'enregistrement de la réunion sur l'appli. Les interlocuteurs sont reconnus et on obtient un transcript en quelques secondes. Enfin, pour transcrire vos enregistrements directement sur un serveur, il y a Speakr, dont je vous ai déjà parlé .
Voilà, en tout cas, je trouve que son dev a bien bossé ! Meeting Recorder c'est sous licence MIT, et le code est sur GitHub pour ceux qui ont un Omarchy sous la main !
Après avoir lu cet article de XDA , j'ai voulu savoir ce que pesait vraiment l'index de recherche sur mon Windows 11 tout neuf. En vrai pas grand chose... A peine quelques Mo. Puis j'ai déposé un dossier de travail assez gros dedans, et l'index a grossi comme prévu... mais ensuite quand j'ai supprimé ce dossier, l'index lui n'a jamais remaigri.
Cette base de données, c'est elle qui répond quand vous tapez trois lettres dans le menu Démarrer pour avoir des suggestions d'app et de fichiers. Tout est contenu dans le fichier Windows.db sous Windows 11 et Windows.edb sous Windows 10, et malheureusement, ce fichier peut grossir jusqu'à devenir problématique.
Windows 11 propose 2 périmètres. Le mode Classique, celui qui est actif si vous n'avez rien touché, et qui s'occupe de vos dossiers Documents, Images et Musique, plus le Bureau. Et le mode "Amélioré", qui lui, parcourt l'ensemble du PC.
Ça peut se régler dans les paramètres :
Le mode Classique est celui d'origine : Documents, Images, Musique et le Bureau.
Mais ce qui est mal expliqué dans la doc de Microsoft, c'est que Windows n'indexe pas QUE les noms de fichiers. Et oui, quand les fichiers contiennent du texte, leur contenu est également indexé, ce qui vous permet de rechercher par mots-clés présents dans le contenu du fichier.
Et comme le périmètre est défini par un emplacement et jamais par un volume, tout ce qui atterrit dans Documents entre dans l'index. Que ce soit vos 3 lettres de motivation ou un dossier projet contenant 40 000 fichiers... Windows ne fait pas la différence.
3 profils sont donc aux premières loges : ceux qui ont basculé sur le mode Amélioré, ceux dont le dossier Documents pointe en réalité vers leur OneDrive ou un autre dossier synchronisé, et ceux qui rangent leurs projets ou leurs machines virtuelles dans Documents.
Si vous n'êtes dans aucun des trois, la suite vous dira en trente secondes que tout va bien, vous verrez ^^
Le nombre d'éléments dans cet index se lit sans aucun droit particulier. Suffit d'aller dans Paramètres, puis Confidentialité et sécurité, puis Rechercher. Le compteur "Indexé" est en haut de la page, et c'est aussi là que se trouve le choix du périmètre.
La taille du fichier, elle, demande une console administrateur. Ouvrez donc PowerShell en tant qu'administrateur et collez :
[math]::Round((Get-Item "$env:ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db" -Force).Length / 1MB, 2)
Vous obtiendrez alors un nombre en mégaoctets. Mais pour savoir s'il est réellement gros, c'est le compteur d'éléments qui fait la différence, plus que le poids. Je m'explique...
Microsoft donne des repères dans sa doc. Moins de 30 000 éléments c'est OK chez un utilisateur ordinaire. Pour un gros utilisateur, rien de choquant de monter jusqu'à 300 000 éléments. Par contre, au-delà de 400 000, des problèmes de performances peuvent commencer à apparaître. Et si vous vous demandez jusqu'où vous pouvez aller, sachez que le plafond technique est à un million d'éléments, après quoi l'indexeur se plantera comme une merde ou fera grimper le processeur, la mémoire et le disque dans les nuages.
La même commande sans les droits administrateur répond "Accès refusé".
J'ai monté une petite expérience pour l'occasion dans une machine virtuelle Windows 11 Pro 25H2, avec quatre cœurs et 8 Go. Départ à 462 éléments et 6,71 Mo. J'y ai déposé ensuite 3 000 fichiers texte, soit 15,94 Mo de contenu, et j'ai regardé l'index monter à 3 466 éléments pour 18,66 Mo. La base pèse donc presque aussi lourd que les fichiers qu'elle vient d'avaler !! C'est du texte brut partout, ce qui est le pire cas possible pour elle puisqu'il faut en indexer le contenu.
Ensuite j'ai supprimé les 3 000 fichiers et le compteur d'éléments est bien redescendu à 465, celui du départ, mais Windows.db lui, était toujours à 16,81 Mo. Alors que mes 465 éléments tenaient dans 6,71 Mo une heure plus tôt.... Bref, l'index a libéré ses entrées, mais pas son espace, la place étant réservée pour la prochaine fois...
Alors pour reprendre la main sur son espace disque, le bon geste, c'est l'exclusion ciblée. Allez dans Paramètres, Confidentialité et sécurité, Rechercher, puis "Ajouter un dossier exclu".
Les cibles qui valent le coup sont celles qui changent sans arrêt ou qui ne pèsent rien dans une recherche. Je pense aux dossiers de dépendances d'un projet, aux dossiers de compilation, aux caches, aux disques de machines virtuelles, au .git, aux bibliothèques de jeux et j'en passe...
Vous saurez ainsi tout de suite si ça a marché. Remontez en haut de la même page de réglages et regardez le compteur "Indexé". Il devrait diminuer du nombre de fichiers que contenait le dossier, sans que vous ayez rien d'autre à faire.
En revanche, n'excluez pas Documents ou le Bureau d'un seul bloc, et ne coupez surtout pas le service. En effet, ce bon vieux menu Démarrer ne cherche que dans l'index et Outlook classique s'appuie aussi dessus pour retrouver vos mails. Un dossier exclu devient invisible à la recherche et, ce serait dommage de ne plus pouvoir retrouver un mail, par exemple.
Le second truc à faire, c'est la reconstruction, car c'est elle qui récupère l'espace. Ouvrez les Options d'indexation avancées depuis la même page de réglages, cliquez sur Avancé, puis sur Reconstruire dans la section Dépannage. Windows prévient alors que les résultats seront incomplets pendant l'opération, mais on s'en fout, et c'est normal puisqu'il repart de zéro !! Microsoft conseille d'ailleurs de laisser l'indexeur travailler jusqu'à 24 heures, alors ne lancez pas ça cinq minutes avant d'avoir besoin de retrouver un fichier.
Le bouton Reconstruire est planqué sous Dépannage, dans les Options avancées.
Sur ma machine, l'index gonflé à 16,81 Mo est ainsi redescendu à 1 Mo, pour exactement les mêmes 465 éléments. Quatre minutes de reconstruction plus tard, et le fichier ne pesait plus que six pour cent de sa taille d'avant. Une fois que c'est fait, vous pouvez relancer la commande PowerShell. Si le chiffre n'a pas bougé d'un poil, c'est que votre index était déjà à sa taille utile, et dans ce cas, bon courage, ça veut dire que votre problème d'espace disque est ailleurs.
Source : XDA Developers
Vous avez un dossier plein d'enregistrements de réunions, d'entretiens ou de notes vocales que vous avez dictées en marchant, et vous ne les avez jamais réécoutés. Forcément, réécouter doit se faire en temps réel, et un fichier baptisé REC_20260812_143301.m4a ne permet pas forcement de savoir de quoi ça cause... Alors que faire ?
Hé bien le projet Speakr s'attaque exactement à ce problème. Vous y déposez vos fichiers, ou vous enregistrez directement depuis le navigateur en captant le micro, le son du système, ou les deux mélangés. Et en sortie, vous récupérez un texte en clair, cherchable, découpé par intervenant, avec un résumé et les actions à retenir.
Et si vous cliquez sur une ligne du texte transcrit, la lecture se lancera à cet instant précis. Mais Speakr va encore plus loin grâce à sa fonctionnalité Inquire. Grâce à ça, plus besoin de farfouiller dans un enregistrement. Vous posez simplement une question à toute la bibliothèque d'un coup du genre "qu'est-ce qu'on avait décidé sur le tarif, et qui n'était pas d'accord ?".
Un mode agent optionnel, encore en bêta, va même lire les enregistrements concernés un par un avant de répondre, avec des liens numérotés qui ouvrent chaque extrait à la seconde citée. Et chacun décide si ses résumés et ses notes privées sont lisibles par cet agent.
Reste la question qui fâche, parce que le projet se vend comme un truc auto-hébergé, donc privé. Et en creusant un peu, je me suis rendu compte qu'il y avait quand même des choses qui sortaient de la machine. Il y a d'abord la transcription, qui envoie l'audio au moteur qui le transforme en texte. Et celui du texte ensuite, qui expédie la transcription au modèle qui écrit les résumés, les titres et les réponses du chat.
Et dans la configuration de base, les deux usages IA pointent chez un tiers : une clé OpenAI pour l'audio, une clé OpenAI (ou OpenRouter) pour le texte. Votre serveur, lui, ne stockera que des fichiers...
Alors, il faudra bien penser, si vous voulez que ça reste en local, à brancher Ollama à la place d'OpenAI et OpenRouter. Mais couper celui de l'audio se paiera car pour réussir à transcrire de l'audio, il vous faudra quand même une bonne carte graphique et un gros modèle Whisper comme expliqué dans le guide d'installation .
Sans carte, ça tourne quand même, rassure-vous, mais ce sera plus lent.
Pour le reste, c'est du Docker avec SQLite ou PostgreSQL, 2 Go de RAM annoncés pour l'application seule, et tout ce qu'on attend d'un truc qui s'utilise à plusieurs : comptes, authentification unique, partages, API et webhooks signés.
C'est sous licence AGPLv3, doublée d'une licence commerciale pour ceux qui ne veulent pas s'y contraindre.
Niveau outils semblables, il y a Scriberr, dont je vous ai déjà parlé , transcrit en local sans jamais rien envoyer dehors, mais son auteur vient d' annoncer une pause dans le développement . On a aussi l'application Meetily , qui elle, vise le poste de travail plutôt que le serveur d'équipe, et réserve la séparation des voix à son offre payante. Et si c'est de la dictée en direct sur Mac dont vous avez besoin plutôt que d'exploiter des enregistrements déjà faits, j'ai codé Kassis pour ça, qui reste en local lui aussi.
Alors finalement, pourquoi ne pas donner sa chance à Speakr ?
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.
Vous rentrez de soirée à moitié bourré, vous ouvrez Paramètres, Applications, Applications installées, et vous cherchez OneDrive Photos pour le virer... Mais il n'y est pas ! Rassurez-vous, ce n'est pas à cause des effets de l'alcool car l'application est pourtant bien sur la machine, avec son icône moche dans le menu Démarrer et son interface photo qui s'ouvre très bien quand on clique dessus... ALORS POURQUOI NE PEUT ON PAS VIRER CETTE COCHONNERIE ???
Hé bien Microsoft a reconnu avoir distribué cette nouvelle interface "photo" plus largement que prévu sur Windows 11 sans anticiper que des gens auraient envie de le virer. Le déploiement était involontaire, mais le résultat est quand même arrivé sur votre disque et vu la réputation de OneDrive côté dark patterns , l'envie de nettoyer tout de suite se comprend...
Mais rassurez-vous, je vais vous aider !
OneDrive Photos n'est pas une application séparée, c'est le binaire OneDrive.App.exe livré à l'intérieur du client de synchronisation OneDrive.
Voilà pourquoi Windows ne lui donne aucune entrée de désinstallation.
Son emplacement dépend en réalité du mode d'installation du client. En installation par utilisateur, il atterrit dans votre profil. En installation pour toute la machine, il va dans Program Files. Cette commande ci-dessous teste donc les deux et affiche la version trouvée.
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\OneDrive","$env:ProgramFiles\Microsoft OneDrive","${env:ProgramFiles(x86)}\Microsoft OneDrive" -Filter OneDrive.App.exe -ErrorAction SilentlyContinue | Select-Object FullName,@{n='Version';e={$_.VersionInfo.FileVersion}}
Ce que Windows vous laisse supprimer facilement par contre, ce sont les raccourcis. Ils se posent au niveau de la machine et dans votre profil, donc menu Démarrer et bureau. Par contre, ouvrez PowerShell en administrateur sinon, vous ne pourrez pas les virer.
"$env:ProgramData\Microsoft\Windows\Start Menu\Programs","$env:APPDATA\Microsoft\Windows\Start Menu\Programs","$env:PUBLIC\Desktop","$env:USERPROFILE\Desktop" | ForEach-Object { Get-ChildItem $_ -Filter "OneDrive Photos.lnk" -ErrorAction SilentlyContinue } | Remove-Item -Verbose
Le script affiche alors chaque raccourci retiré. Tapez ensuite "OneDrive Photos" dans le menu Démarrer, et vous verrez plus rien ne remonte.
Mais vous l'avez compris, le binaire, lui, n'a pas bougé. Vous avez nettoyé le point d'entrée, mais pas désinstallé l'application. Un double-clic sur OneDrive.App.exe rouvrira l'interface photo comme avant, et une mise à jour du client peut très bien rétablir le raccourci...
Et non, il n'existe aucune clé de registre ni stratégie de groupe pour bloquer proprement cette application, même sur un parc géré. Pas d'interrupteur à débrancher comme avec RemoveWindowsAI face à Copilot . Les scripts qui circulent suppriment des .lnk, rien d'autre.
Alors comment on fait ? Hé bien on passe à l'étape 3 !
Car la seule suppression réelle aujourd'hui, c'est de désinstaller le client OneDrive en entier, ce qui n'a de sens que si vous ne vous en servez pas. Le dossier d'installation part avec, donc le binaire photo aussi. Avant de lancer quoi que ce soit, si vous utilisez les fichiers à la demande, faites donc un clic droit sur les dossiers qui comptent et cochez "Toujours conserver sur cet appareil".
winget uninstall --id Microsoft.OneDrive
Le même résultat s'obtient depuis Paramètres > Applications installées > Microsoft OneDrive > Désinstaller. La synchronisation locale s'arrête là, mais vos données restent en ligne et rien n'est supprimé côté Microsoft.
Pour vérifier le résultat, relancez alors la commande de l'étape 1. Plus aucun chemin affiché, le binaire a quitté les emplacements contrôlés. Si un chemin encore là, c'est qu'un client OneDrive traîne toujours, souvent dans un autre profil utilisateur.
Ensuite, pour revenir en arrière, il faudra réinstaller OneDrive depuis le site officiel de Microsoft. Mais si la synchro de vos fichiers revient, sachez que l'interface photo aussi. Les deux voyagent ensemble comme des bro incels soudés à la vie à la mort.
Alors que faire ?
Car oui, youpi, Microsoft annonce pour septembre 2026 un contrôle qui retirera OneDrive Photos seul, sans couper la synchronisation. Donc si vous tenez à OneDrive, attendre quelques semaines vous coûtera moins cher qu'une désinstallation complète.
Si vous cherchez un logiciel de dictée vocale sérieux sur Mac, vous avez sûrement remarqué que le marché ressemble à un désert. Nuance a débranché Dragon pour Mac en octobre 2018, la dictée intégrée de macOS dépanne pour 2 SMS mais s'essouffle sur un vrai document, et la plupart des services actuels envoient votre voix mouliner sur un serveur à l'autre bout du monde. Et quand vous êtes avocat, médecin, journaliste ou juste quelqu'un qui dicte des trucs confidentiels, bah ça pique un peu.
Alors comme vous le savez, j'ai fini par coder ma propre solution, et bonne nouvelle, Kassis débarque aujourd'hui sur le Mac App Store ! Jusqu'ici, mon app de saisie vocale était réservée à mes abonnés Patreon (je vous en parlais ici à sa sortie), mais vous pouvez maintenant l'installer en 2 clics et la tester gratuitement, sans compte, sans carte bleue.
Le principe reste le même : vous laissez le doigt appuyé sur un raccourci clavier (⌥ + Espace par défaut), vous parlez, vous relâchez, et hop, le texte atterrit pile là où se balade votre curseur. Dans Mail, Slack, Word, votre terminal ou n'importe quelle autre app macOS. Moi, je m'en sers vachement pour discuter avec Claude Code, notamment. Ça fait gagner un temps de dingue et surtout votre voix ne quittera jamais votre Mac. Puis une fois les modèles téléchargés, ça pourra même marcher sans connexion.
Je l'ai pensé pour un usage professionnel, donc que ce soit le secret médical, les dossiers clients, les sources d'une enquête journalistique... Absolument rien ne part dans le cloud. Et contrairement à d'autres solutions, il n'y a même pas besoin de vous créer un compte.
Côté moteurs, vous avez le choix entre 5 modèles de reconnaissance vocale. Tout d'abord, Parakeet qui est ultra rapide et qui est mon préféré au quotidien. Mais également Whisper d'OpenAI, un classique un peu plus costaud, mais très fiable. Et puis des modèles un peu plus confidentiels comme Canary de Nvidia (le grand frère de Parakeet) ou encore Cohere qui est vachement précis. Sans oublier le moteur d'Apple intégré à macOS 26 qui utilise le Neural Engine pour retranscrire votre voix instantanément !
La détection de langue est également automatique parmi 99 langues, donc vous dictez par exemple en français, en anglais ou en japonais sans avoir à toucher un réglage.
Et Kassis ne fait pas que de la dictée ! L'outil sait également faire de la transcription audio en texte à partir d'un fichier audio ou vidéo que vous glissez-déposez sur la fenêtre. Avec ça, il vous ressortira en texte dans le presse-papier tout ce qui a été dit dans le son ou la vidéo, avec l'identification des locuteurs (qui parle et quand). C'est super pratique pour les réunions enregistrées, les interviews, les podcasts, les mémos vocaux ou encore les rushs vidéo.
Le texte qui sort est nickel, et vous pouvez le coller tel quel. Les "euh" et les hésitations dégagent tout seuls, la ponctuation et les majuscules tombent où il faut (typographie française comprise, avec ses espaces avant les points d'interrogation), et y'a même un dictionnaire de substitutions qui apprend vos termes techniques, vos noms propres et vos abréviations. Et les noms de marque que les moteurs massacrent d'habitude ? Une correction phonétique optionnelle se charge de les rattraper.
Et le texte transcrit, vous pouvez également le retravailler en local à l'aide de 7 styles de reformulation (professionnel, concis, structuré, décontracté...), ou une traduction dans 13 langues, toujours sans cloud. Genre vous marmonnez votre brouillon en français, vous relâchez la touche, et c'est un email propre en anglais prêt à partir.
Perso, je m'en sers tous les jours pour dicter mes emails, mes articles et mes prompts, et visiblement je ne suis pas le seul accro, puisque la version 1.1 doit également beaucoup aux retours des utilisateurs de la première heure. Par contre, les possesseurs de vieux Mac Intel, désolé, c'est mort... il vous faudra une puce Silicon.
Côté tarifs, la version gratuite offre donc 2 000 mots pour vous faire une idée et Kassis Pro passe en illimité pour 7,99 € par mois ou 49,99 € par an, avec 7 jours d'essai gratuit sur la formule annuelle. Les allergiques à l'abonnement ont également le choix d'opter pour une licence à vie à 129,99 €, et mes soutiens Patreon gardent leur accès direct, comme avant. L'app est dispo sur l'App Store du monde entier, avec une fiche traduite en 15 langues (même en japonais, 音声入力 !).
Bref, si votre Mac vous sert à écrire, foncez essayer Kassis sur le Mac App Store , la version gratuite suffit pour vous faire une idée.
Kassis fait partie des nombreux logiciels que je développe sous le nom Korben et que vous pouvez tous retrouver sur ma page Korben Logiciels .
Vous avez peut-être remarqué un petit point rouge tout en bas de mon site, avec un nombre à côté. Il s'agit du nombre de personnes passées sur le site durant la dernière heure.
Je voulais remettre ce truc depuis un bail, bien à l'ancienne comme dans les années 2000 mais sur un site statique, qui plus est sans tracker de stats JS type Google Analytics ou Matomo, et sans cookies de tracking, c'était pas franchement une option... jusqu'à maintenant !
Le compteur, en vrai, tout en bas de korben.info.
La solution évidente sur des sites statiques, c'est souvent un petit Worker Cloudflare qui compte les visiteurs et servirait le chiffre, mais ça se facture à chaque requête. À 390 000 pages vues par jour, ça grimpe vite à des dizaines de millions d'invocations par mois, soit dans les 6 à 7 dollars. C'est pas super cher mais pour un compteur qui n'est utile qu'à satisfaire mon égo tout en sachant s'il y a du monde aujourd'hui, ça ne sert strictement à rien ! Donc le Worker, je l'ai écarté direct.
Du coup j'ai fait ça à l'ancienne. Un petit script Python tourne sur la machine qui héberge le site, une fois par minute. Il pose une seule question à Cloudflare, à savoir combien d'adresses IP distinctes ont chargé une page durant la dernière heure (ou demi-heure, ou quart d'heure ou 5 min, c'est vous qui paramétrez), il écrit la réponse dans un minuscule fichier live.json de quelques centaines d'octets, et c'est tout. Ce fichier, Cloudflare le sert ensuite depuis son cache comme il servirait une image, gratuitement. Zéro Worker, zéro base de données, zéro abonnement, j'ai exactement le même résultat sans dépenser une thune.
Maintenant, faut que je sois clair sur ce que ce chiffre raconte. C'est le nombre de navigateurs distincts ayant chargé une page durant la dernière heure, hors trafic interne de Cloudflare. C'est un "*combien de monde est passé récemment *", pas un "combien lisent là tout de suite".
Et les bots là-dedans ?
En fait, les bots pourris , ceux qui scrapent en boucle, se font bloquer en amont par le Super Bot Fight Mode de Cloudflare, donc ils n'arrivent même pas jusqu'à mon site. Restent les gentils bots, du genre de Googlebot et compagnie, que je laisse passer exprès, parce que les bloquer reviendrait à me flinguer mon référencement. Sur les 7 derniers jours, Cloudflare classe à peine 4% comme bots vérifiés. Donc c'est une goutte d'eau, surtout qu'ils tournent sur une poignée d'IP. Donc oui, mon compteur avale deux ou trois crawlers au passage, mais je ne voulais pas vous mentir en écrivant "zéro bot". Mais l'essentiel c'est que les nuisibles, eux, ne soient pas comptabilisés.
J'ai aussi dû gérer un petit piège car l'API de Cloudflare plafonne sa réponse à 10 000 lignes. Et comme sur une heure entière de trafic ça peut se remplir vite, si je crève ce plafond, la requête sous-compterait sans rien dire. Donc le script lève un flag et le compteur affiche "10 000 personnes ou plus" plutôt qu'un faux nombre. Quand j'y serai aux 10 000 et plus, je pense que je réduirai alors le delta temps en passant de 1h à 30 min...etc.
Côté vie privée, c'est carré également. Cloudflare renvoie à mon serveur une liste JSON des IP passées dans l'heure, mon script en compte le nombre de distinctes, et efface cette liste de sa mémoire dans la milliseconde qui suit. Aucune IP n'est stockée, aucune n'atterrit dans un log, aucun fichier avec les IPs n'est créé sur le disque... Il ne reste qu'un entier. Comme je vous le disais, pas de cookie , pas de traceur, et rien qui touche votre navigateur . Et comme le compteur ne s'affiche jamais en dessous de 10 personnes, impossible d'isoler qui que ce soit.
Maintenant, si vous voulez le même chez vous, sachez que j'ai tout balancé en open source sur GitHub , sous licence MIT, donc servez-vous. Voici les pré-requis :
live_count.py sur votre serveur et vous le lancez une fois par minute (ou toutes les 5 ou 10 min) via un cron.span dans vos pages, tout se règle par des attributs, aucun script inline, donc ça passe même avec une politique de sécurité stricte.Le seul truc sur lequel ne pas vous louper, c'est de mettre un temps de cache court à live.json. Si c'est trop long, tous vos visiteurs verraient un chiffre périmé.
Voilà. Un petit compteur maison simili-live sans tracking et qui ne me coûte rien, c'est le bonheur !
Afska, le développeur derrière une flopée d'outils pour Game Boy Advance, a eu avec son studio [r]labs une idée géniale ! Ça s'appelle EmuDevz, et c'est un jeu vidéo dans lequel vous devez coder votre propre émulateur NES. Et pas en cliquant sur des boutons comme un loser, hein mais en pissant du vrai code pour le processeur, la puce graphique et la puce audio de la console de Nintendo.
L'émulation, normalement, c'est un truc réputé aride où vous passez des semaines le nez dans la nesdev wiki à piger comment le 6502 gère ses cycles d'horloge. Et pourtant, là, tout devient clair et facile puisque vous avez un éditeur de code intégré façon shell Unix, et vous implémentez le CPU, le PPU et l'APU dans l'ordre que vous voulez. Puis au fil de votre progression, vous débloquez des ROMs et des homebrews à faire tourner dans l'émulateur que vous venez de pondre. Et pour vérifier que votre code tient la route, le jeu fournit même des tests unitaires, des tests vidéo et des tests audio.
Mais le truc qui m'a scotché dans ce "jeu", c'est le debugger. Dans celui-ci, vous avez droit à un visualiseur de mémoire, un log d'instructions, les nametables, la CHR, les sprites, les palettes, les canaux APU affichés un par un, le monitoring du contrôleur... l'arsenal complet du mec qui développe pour de vrai, mais emballé dans une interface gaming. Y'a même un tuto interactif pour apprendre l'assembleur 6502 si vous débarquez sans rien connaître...
Voilà, c'est génial pour apprendre des concepts liés à l'émulation et au développement de jeux retro. On savait déjà qu'il était possible d' apprendre Prolog grâce aux Pokemon ou de recréer une carte 3dfx de zéro et voilà que maintenant, on nous propose carrément de dompter l'émulation de la NES.
Puis surtout, une fois que vous maitriserez un peu plus, le mode libre de EmuDevz vous permettra de commencer à coder des émulateurs pour d'autres systèmes. Ah et y'a même une bande son retro-synthwave dans l'appli pour se mettre dans l'ambiance.
Et je vous l'ai dit ou pas que c'était open source, trouvable sur Steam mais surtout jouable directement depuis votre navigateur ???
La vie est belle ! Et bonne canicule à tous 🥵 !
Si vous ne connaissez pas, un favicon, c'est cette mini icône pixelisée que vous pouvez voir dans l'onglet de votre navigateur qui en général est le logo du site que vous visitez. Hé bien le dev Tim Wehrle a réussi à y faire tenir un site web entier en stockant tout son HTML dans les 212 octets de l'image.
L'astuce est toute con vous allez voir... Une image, c'est des pixels. Et chaque pixel a 3 valeurs : rouge, vert, bleu, soit 3 octets. Du coup il prend son HTML, le découpe octet par octet, et colle chaque octet dans une couleur. Premier octet dans le rouge, le suivant dans le vert, puis le bleu, et on continue ainsi de suite. Et voilà comment il arrive à stocker 208 octets de HTML dans un carré de 9 pixels sur 9. Et au final, le truc ressemble à des confettis random.
Pour relire tout ça ensuite, un peu de JavaScript suffit. Le navigateur charge l'image, la passe dans un canvas, relit chaque pixel, recolle les octets et réaffiche la page. Il n'y a donc rien à installer et pour tester ça par vous-même, il a même mis une démo ici où vous pouvez regarder l'encodage / décodage se faire sous vos yeux ébahis.
Maintenant, n'espérez pas faire tenir votre site e-commerce là dedans hein puisque la capacité plafonne à 239 octets. Et sans le bout de JavaScript qui décode, le favicon tout seul ne servira à rien. Et ce n'est pas de la stéganographie non plus puisqu'on ne planque rien dans une vraie image. La data c'est l'image...
Mais c'est le genre de hack inutile que j'adore ! Le code est sur GitHub si vous êtes curieux et il raconte toute sa démarche sur son blog .
Si vous passez votre vie dans un terminal et que vous avez réussi un jour à quitter tout seul Vi / Vim, voici une application qui va vous intéresser. Il s'agit de Tanko , signé Alexandro Mendez, un outil en ligne de commande qui permet de lire et télécharger vos mangas préférés directement depuis un terminal. C'est, en gros, le même concept que youtube-dl mais pour les scans japonais.
Pour installer Tanko, ouvrez un terminal et entrez la commande suivante : pnpm install -g tanko (npm marche aussi). Une fois que c'est fait, y a plus qu'à lancer tanko. Plus besoin d'aller sur les sites en question, vous entrez vos critères de recherche et hop, vous lisez votre chapitre directement. Les chapitres que vous téléchargez en PDF atterrissent dans $HOME/tanko/downloads/.
Après, Tanko affiche les vraies pages en image, à condition d'utiliser un terminal moderne comme Kitty, Ghostty ou WezTerm qui gèrent les protocoles graphiques (Kitty graphics, Sixel). Mais surtout dans un terminal basique, genre le terminal intégré de VS Code ou le bon vieux CMD de Windows, Tanko basculera en mode ASCII Art.
J'suis sûr que vous voyez où je veux en venir... Votre boss passe derrière vous, voit des caractères bizarres défiler dans VS Code, et repart convaincu que vous compilez un truc alors que pendant ce temps-là vous suivez peinard le dernier chapitre de One Piece... niark niark niark.
Côté fonctions, vous avez l'historique de lecture, un menu de config, les notifications et le support de plusieurs sources de scans. Attention quand même, certaines sources scrappent les sites via un navigateur, donc il faudra installer Firefox avec npx playwright install firefox. Après c'est pas non plus obligatoire et vous pouvez vous contenter des sources qui n'en ont pas besoin.
L'outil est cool mais après en ce qui me concerne, lire un manga en ASCII Art c'est marrant 30 secondes, mais pour de la vraie lecture je vous conseille vraiment d'opter pour l'un des terminaux avec support des images que je vous ai cités plus haut.
Et si votre but c'est juste d'aspirer des tonnes de scans, le vieux mangal est plus complet, même s'il est archivé depuis avril 2025 et que plus personne ne le maintient... sniiif. Dans le même style, ça me rappelle aussi Lue qui vous lit vos ebooks en audio dans le terminal et si vous préférez un truc avec une vraie bibliothèque, jetez plutôt un œil à Kavita .
Et enfin, roulements de tambours, pour savoir où trouver vos scans sans finir en correctionnelle, j'avais fait un guide sur le manga et le scantrad .
Bref, c'est gratuit, mais à consommer avec modération pendant les heures de boulot, bande d'ennemis du capitalisme ^^ !!
Je suis trop content parce qu'avec son nouveau SDK pour extensions , Ableton nous permet enfin d'écrire nos propres outils pour son DAW Live en JavaScript. L'intérêt c'est que ces extensions peuvent lire et modifier vos Sets : pistes, clips, notes MIDI, paramètres, automations... et comme ça votre projet se transforme en un truc qu'on peut trafiquer avec du code (et donc avec de l'IA car ça repose sur des technos web standard ^^ niark niark).
En pratique, une extension peut renommer tous vos clips d'un coup, transformer une photo en mélodie MIDI, découper un beat tout seul, ou carrément faire tourner un petit jeu dans Live. Vous faites un clic droit dans le Set, ça s'exécute, et hop, c'est plié !
Par contre, ça ne remplace pas Max for Live puisque Max tourne en temps réel en agissant sur le son des synthés et des effets alors que les Extensions, elles, se lancent d'un clic droit, font leur boulot, puis s'arrêtent. Ce n'est donc pas du temps réel. C'est juste fait pour automatiser et bidouiller la structure d'un projet mais c'est ce qui fait que les deux se complètent bien.
Screenshot
Pour vous lancer, il faut Node.js, être à l'aise avec le terminal, et toute la doc est sur GitHub . Ableton a même sorti une vidéo qui montre comment créer sa première extension de bout en bout.
J'ai testé en le branchant avec Claude Code, et je lui ai demandé de me faire un morceau french electro du thème d'Indiana Jones et voilà ce que ça m'a sorti from scratch (j'ai juste mis un kit rock pour les drums car sinon, y'avait pas de son sur la piste) :
Maintenant, c'est réservé à Live 12 Suite (Beta), soit le haut de gamme du logiciel, donc sur Standard ou Intro, c'est mort. Ensuite c'est de la bêta, donc c'est pas encore 100% complet... Et n'oubliez pas que c'est du JavaScript tiers qui s'exécute dans Live avec un accès à votre projet, donc ça peut toujours faire des dégâts. Évitez donc d'installer un truc random trouvé sur Discord, car ce serait un peu comme quand vous lanciez des VBScript reçus par mail à la grande époque de Windows 98. Surtout que du code pondu par une IA peut aussi cacher quelques saloperies sans que ça se voie, donc vérifiez toujours d'où ça vient et lisez le code.
Quoi qu'il en soit, si vous êtes sur Live 12 Suite, foncez tester et surtout amusez-vous bien !
FROST, c'est le nom d'une nouvelle attaque qui transforme votre SSD en mouchard. Des chercheurs de l'université de Graz, avec Daniel Gruss au générique (un des cerveaux derrière Spectre et Meltdown), ont montré qu'un simple site web peut deviner quels autres sites et applis vous avez ouverts et cela juste en mesurant les micro-ralentissements de votre disque. Oui, je sais c'est geudin !
Le principe ?
Quand vous ouvrez la page piégée, elle crée discrètement un gros fichier sur votre disque via une API du navigateur baptisée OPFS ( Origin Private File System ), présente aujourd'hui dans tous les navigateurs modernes. C'est ce fichier qui sert de sonde.
Le JavaScript passe son temps à lire dedans et chronomètre chaque lecture au poil de cul et dès qu'une autre appli ou un autre onglet sollicite le SSD, ça crée un embouteillage minuscule sur le disque... que le code peut repérer sous forme de ralentissement.
Sauf que des variations de timing, ça reste du bruit illisible pour un humain. Du coup les chercheurs ont balancé toutes ces mesures dans un réseau de neurones (un CNN, le même genre de bidule qui reconnaît des choses sur des photos).
Entraîné sur des tonnes de traces, le modèle apprend alors la signature de chaque appli et de chaque site web et voilà comment à partir de ça, il devine ce que vous avez ouvert !
Sur un Mac, dans les tests présentés cette semaine, le truc retrouve le bon site parmi un top 50 dans près de 9 cas sur 10, et grimpe à plus de 95% pour reconnaître les applications ouvertes. Le tout sans la moindre action de votre part, à part avoir cliqué sur le lien. C'est totalement invisible.
Mais avant de débrancher votre PC, renvoyer votre box internet et vous lancer à temps complet dans la culture de chanvre, faut relativiser, car cette attaque a plusieurs limites... Le hic numéro un, c'est que le fichier-sonde doit être énorme, genre 1 Go ou plus, et un site qui se met à bouffer autant de place sur votre disque, ça se remarque vite. Le hic numéro deux, c'est que ce fichier doit être sur le même SSD que le navigateur sinon l'attaque est aveugle.
Les chercheurs ont fait tourner l'attaque complète sur un Mac M2, et démontré que la brique de base fonctionne aussi sous Linux (sans dérouler la classification complète), mais n'ont pas testé Windows. Et surtout, personne n'a encore vu FROST exploité dans la nature.
Perso, je trouve que cette attaque est trop bancale / incertaine pour faire du tracking de masse, en tout cas aujourd'hui...
Pensez donc à fermer les onglets dont vous ne vous servez plus comme ça, y'a moins d'activité à mesurer et pour les plus paranoïaques, vous pouvez toujours vous mettre à surveiller les fichiers OPFS créés par des sites web inconnus. Après comme tout repose sur du JavaScript, bloquer le JS sur les sites pas nets (avec un NoScript ou équivalent) ça coupe aussi l'attaque à la racine.
Les chercheurs proposent aussi aux éditeurs de navigateurs de plafonner la taille de ces fichiers OPFS. Ce serait dans la lignée de ce que fait par exemple Firefox avec le pistage, qui a récemment musclé son anti-fingerprinting .
Bref, pas de panique, personne ne fouille votre SSD en douce mais la technique reste intéressante. Les détails techniques complets sont dans le papier de recherche , qui sera présenté à la conférence DIMVA en juillet. Bonne lecture !
Y'a des gens trop habitués à Linux, qui tapent htop par réflexe alors que sous Windows, la commande ne fait rien. Pour que ça fonctionne, faut installer WSL, configurer un sous-système Linux entier, et tout ça juste pour surveiller quelques processus... C'est un peu overkill comme on dit.
Mais heureusement, pstop arrive pour corriger ça !
Pstop est un moniteur système TUI pour Windows PowerShell, écrit en Rust, qui pèse ~1 Mo et qui tourne nativement sur Windows 10 et 11 sans aucune dépendance !
L'interface s'organise en quatre onglets : l'onglet principal avec CPU, mémoire et liste des processus, puis des onglets dédiés aux I/O disque, au réseau et au GPU. Le CPU y est affiché par cœur avec un code couleur pour distinguer le temps user, système et virtuel ce qui est très pratique je trouve pour repérer d'un coup d'œil si c'est votre code ou le kernel qui vous pompe les ressources.
Le réseau s'adapte en auto-scaling à la bande passante utilisée, et la liste des processus peut s'afficher en arborescence pour voir les relations parent/enfant. Par contre, l'onglet GPU sera vide si vous n'avez pas de GPU dédié.
Côté navigation, y'a F3 pour chercher, F4 pour filtrer, F2 pour changer de thème, F9 ou k pour tuer un processus....etc. Bref, les raccourcis F1-F10 suivent la convention htop, donc si vous avez la mémoire musculaire d'htop sous Linux, vous retrouverez vos marques immédiatement. Bon après, les vim keys sont disponibles aussi en option si vous êtes des geudins.
Pour l'installer :
# Via winget (le plus simple)
winget install marlocarlo.pstop
# Via cargo
cargo install pstop
Le projet est développé par le même dev derrière psmux, le tmux natif pour Windows que j'avais déjà couvert ici. Finalement, on dirait bien qu'il a décidé de rééquiper le terminal Windows en profondeur, et franchement c'est une bonne nouvelle pour tous ceux qui bossent sous PowerShell !
Par contre, pstop est Windows-only, x86_64 uniquement pour l'instant (pas d'ARM) et si vous cherchez un outil cross-platform pour Linux ou macOS, btop++ reste bien sûr l'option de référence.
C'est sous licence MIT, en open source sur GitHub !
Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'eteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.
La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.
Concrètement ça donne ça :
from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé
Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !
La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...
Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.
Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !
Sur le terrain anti-bot, ça se compare bien à
Botasaurus
dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.
Détail sympa pour les bidouilleurs : y'a également un serveur MCP est intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.
Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.
Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.
Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .
Et merci à Letsar pour le lien !
Distribuer des paquets binaires en WebAssembly, c'est galère. Vous téléchargez le .tar.gz, vous le gunzippez, vous l'extrayez en mémoire... et ça rame sévèrement !! Mais youpi, Jeroen Ooms (qui contribue à webR et bosse chez ROpenSci) vient de publier
tar-vfs-index
, un petit npm package qui casse cette malédiction des enfers en sautant carrément l'étape extraction.
L'astuce est toute bête ! Au lieu d'extraire l'archive, on génère un fichier d'index qui liste la taille et l'offset de chaque fichier dans le tar. Du coup le navigateur n'a plus qu'à monter le blob du tar comme un système de fichiers virtuel, et chaque lecture devient alors un simple slice du blob à la bonne position. Pas d'extraction donc, mais juste du slicing à la demande !
Sous le capot, ça repose sur 3 propriétés alignées. 1/ le format tar est un layout plat : une suite de headers de 512 octets suivis des données du fichier, le tout contigu et adressable à l'octet près. 2/ Emscripten propose un backend filesystem appelé WORKERFS, prévu pour servir les lectures d'un Blob sans le copier dans le heap WASM. Et 3/ les navigateurs ont une API native, DecompressionStream , qui gunzippe efficacement pendant le téléchargement.
Concrètement, vous installez le truc avec npm install tar-vfs-index (y'a aucune dépendance externe) puis vous lancez npx tar-vfs-index archive.tar.gz. Et hop, le package vous sort un JSON dans ce genre :
{
"files": [
{ "filename": "mypackage/DESCRIPTION", "start": 512, "end": 548 },
{ "filename": "mypackage/R/code.R", "start": 1536, "end": 1563 }
],
"remote_package_size": 3072
}
Les valeurs start et end sont tout simplement les offsets dans les données tar décompressées, et remote_package_size indique la taille totale (pour que WORKERFS sache combien préallouer). Ensuite, côté navigateur, ça donne du JavaScript du genre :
const [metaRes, dataRes] = await Promise.all([
fetch('archive.tar.gz.json'),
fetch('archive.tar.gz'),
]);
const metadata = await metaRes.json();
const blob = await new Response(
dataRes.body.pipeThrough(new DecompressionStream('gzip'))
).blob();
FS.mkdir('/pkg');
FS.mount(WORKERFS, { packages: [{ metadata, blob }] }, '/pkg');
Le cas d'usage qui a motivé tout ça, c'est
webR
, le portage du langage R en WebAssembly. Les paquets R sont distribués en .tar.gz et avant cette astuce, charger un paquet voulait dire copier des trucs partout. Maintenant le temps et la mémoire de chargement reviennent à peu près au coût du téléchargement et du gunzip, ce qui est nettement plus léger qu'une extraction complète en RAM. Et ça marche pour n'importe quel bundle distribué en tar.gz : assets de jeu, datasets pour du machine learning, runtimes Python via Pyodide, bref tout ce qui ressemble à une archive lourde côté navigateur !
Y'a également un mode --append qui colle l'index directement à la fin du tarball (le format tar autorise ce genre de bidouille). Ça donne donc un .tar.gz autonome qu'un loader peut monter sans aller chercher un fichier de métadonnées séparé !
Bref, c'est plutôt joli comme façon de faire et ça vaut le coup d'œil si vous trimballez du tar.gz dans du WebAssembly.
Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !
L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.
Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.
Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où
l'importance de bien les choisir
). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...
Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.
Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !
Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.
Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.
Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.
M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur
emdashcms.com
pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.
