Un développeur a créé une police OpenType capable de convertir des opcodes hexadécimaux du processeur Z80 en instructions assembleur lisibles.

Il suffit de coller le code machine dans un traitement de texte, de changer la police, et les mnémoniques s'affichent en clair. Le projet, disponible sur GitHub, détourne les tables de substitution de glyphes de manière plutôt rigolote.

Une police, pas un logiciel

L'idée est en fait assez simple. Vous balancez une suite de caractères hexadécimaux dans LibreOffice Writer, puis vous sélectionnez cette police, Z80 Sans donc, et sous vos yeux ébahis, le texte se transforme en instructions assembleur.

Pas besoin d'installer un désassembleur, pas besoin de ligne de commande. La police fait tout le travail.

Derrière cette apparente simplicité, le développeur nevesnunes a exploité deux composants du standard OpenType que l'on retrouve habituellement dans des usages bien plus classiques : la table de substitution de glyphes (GSUB) et la table de positionnement (GPOS).

Ce sont les mêmes mécanismes qui permettent d'afficher correctement l'arabe ou de fusionner deux lettres en une ligature comme le "æ". Ici, ils servent à reconnaître des séquences hexadécimales et à les remplacer par les mnémoniques Z80 correspondants.

458 752 combinaisons à gérer

Le Z80 est un processeur 8 bits qui accepte des adresses sur 16 bits et plusieurs registres comme opérandes. Résultat : une seule instruction peut donner jusqu'à 458 752 combinaisons possibles.

Et comme les octets hexadécimaux sont encodés dans un ordre différent de celui dans lequel ils doivent être affichés en assembleur, le problème se corse vite. Les adresses en little-endian et les offsets signés en complément à deux ajoutent encore une couche de difficulté.

Pour s'en sortir, nevesnunes a construit un parseur par descente récursive qui génère automatiquement toutes les règles de substitution nécessaires. Chaque quartet (0 à f) dispose de ses propres glyphes, soit 96 au total pour la partie numérique.

Le tout repose sur une édition directe des fichiers .ttx, la représentation XML des données de police, à partir de Noto Sans Mono et Droid Sans Mono.

Du détournement de police à l'art de la bidouille

Z80 Sans n'est pas le premier projet à détourner les capacités des polices OpenType. On a déjà vu Fontemon, un jeu vidéo complet caché dans une police, ou encore Addition Font, capable d'additionner deux nombres rien qu'avec le rendu typographique.

Il y a même eu Llama.ttf, qui embarquait un modèle d'IA directement dans un fichier de police. Mais un désassembleur complet pour un jeu d'instructions entier, c'est quand même autre chose en termes de complexité.

Visiblement, le projet comporte encore quelques petits bugs d'affichage sur certaines instructions complexes, et le code est qualifié par son propre auteur de "qualité CTF", ce qui veut dire bidouille assumée.

Mais bon, on parle d'un type qui a réussi à faire rentrer un désassembleur Z80 dans une police de caractères. Les puristes de l'assembleur apprécieront le côté complètement absurde de la démarche, et les fans de rétro-informatique vont adorer.

Source : Lobste.rs

La recompilation statique , je vous en avais parlé avec Zelda 64 et Sonic Unleashed. Le principe, en gros c'est qu'au lieu d'émuler bêtement le processeur et la mémoire d'origine, on traduit tout simplement le code assembleur du jeu directement en C natif. Du coup le jeu tourne nativement sur votre machine, sans couche d'émulation.

Et la bonne nouvelle du jour c'est que cette technique vient de parvenir jusqu'à la Game Boy avec GB Recompiled .

Vous filez à cet outil un fichier .gb et il vous sort OKLM un dossier avec du code C, un CMakeLists.txt et tout ce qu'il faut pour le compiler. Vous lancez cmake puis ninja, et votre vieux Pokemon Bleu tourne nativement sur votre PC plutôt que de passer par un émulateur qui simule le processeur Z80 à chaque frame.

Plutôt chouette non ???

Pour réussir ce tour de force, le recompilateur parse les opcodes Z80 de la cartouche, construit un graphe de contrôle de flux et résout les sauts indirects (genre les tables de jump, le truc qui rend la décompilation galère parce que l'adresse de destination dépend de la valeur d'un registre). Le taux de découverte dépasse alors les 98% même sur des RPGs bien touffus... pas mal pour de l'analyse purement statique !

Côté compatibilité, 7 jeux sont pour le moment validés : Tetris, Pokemon Blue, Donkey Kong Land, Kirby's Dream Land, Zelda Link's Awakening, Castlevania et Super Mario Land.

Par contre, attention, tous les jeux ne passent pas encore. Le runtime embarque un rendu PPU scanline , un système audio 4 canaux et les contrôleurs mémoire MBC1, MBC2, MBC3 et MBC5. Et comme tout ça tourne avec SDL2, du coup ça compile tranquillou sur macOS, Linux et Windows sans broncher !

Y'a aussi des outils de vérification assez bien pensés. Par exemple, un mode différentiel lance le binaire recompilé et un interpréteur Z80 côte à côte, puis compare l'exécution cycle par cycle avec une implémentation de référence. Tant que ça colle, le portage est fidèle !

Et y'a aussi un script Python basé sur PyBoy qui génère des traces d'exécution pour repérer les instructions que l'analyse statique aurait loupées. Voilà, ce que je veux vous dire c'est que c'est pas juste un traducteur tout bête. Y'a vraiment tout un pipeline de tests derrière pour assurer le meilleur portage possible.

Si vous avez suivi les autres projets autour de la portable de Nintendo, comme le GB Interceptor qui espionne le bus mémoire avec un adaptateur USB ou le Game Bub et son FPGA Xilinx, GB Recompiled choisit plutôt l'angle purement logiciel. Là où le FPGA reproduit les circuits et l'émulateur simule le CPU, la recompilation traduit le code source. Ce sont 3 philosophies différentes mais qui ont un seul et même objectif : Faire en sorte que ces jeux ne crèvent pas avec leurs cartouches en plastique gris.

Pour tester chez vous, c'est du classique : un petit terminal, un petit git clone, un cmake, un ninja, et vous passez votre fichier .gb au recompilateur.

git clone https://github.com/arcanite24/gb-recompiled.git
cd gb-recompiled
cmake -G Ninja -B build .
ninja -C build

# Générer le code C depuis la ROM
./build/bin/gbrecomp path/to/game.gb -o output/game

# Compiler la nouvelle version en C
cmake -G Ninja -S output/game -B output/game/build
ninja -C output/game/build

# Optionnel: Baisser ou augmenter le niveau d'optimisation
cmake -S output/game -B output/game/build -DGBRECOMP_GENERATED_OPT_LEVEL=2

# Et on lance !
./output/game/build/game

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

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

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

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

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

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

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

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

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

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

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

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

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

Monter un pipeline RAG, c'est un peu le parcours du combattant... entre le choix de la base vectorielle, le modèle d'embedding, l'orchestrateur, le parser de documents, vous en avez pour des heures de config avant de pouvoir poser la moindre question à vos PDF.

Mais c'était sans compter sur OpenRAG qui emballe tout ça dans un seul paquet prêt à l'emploi !

En gros, c'est un package open source (Apache 2.0) qui vous colle un orchestrateur visuel, un moteur de recherche vectorielle et un parser de documents hyper costaud, le tout déjà branché ensemble. Bon, dit comme ça, on dirait juste un assemblage de trucs existants... sauf que l'architecture est propre (FastAPI derrière, Next.js devant) et que tout est câblé d'entrée.

L'installation tient en une commande : uv run openrag (il vous faudra Python 3.10+ et uv, le gestionnaire de paquets rapide en Rust) et ensuite vous aurez un serveur local avec une interface de chat prête à bouffer vos documents. Vous uploadez vos fichiers (PDF, Word, HTML, Markdown...), le système les découpe, les indexe, et vous pouvez commencer à poser des questions dessus. Pas besoin de choisir un modèle d'embedding, de configurer une base Chroma ou Qdrant, ni de câbler un pipeline LangChain à la main. C'est plutôt confortable comme outil !

Et c'est pas juste un chatbot documentaire puisque la plateforme déploie une couche agentique qui va bien au-delà de la simple recherche de similarité. En fait, quand vous posez une question, le système ne se contente pas de chercher le passage le plus proche dans vos documents... il reformule, il croise plusieurs sources, il re-classe les résultats par pertinence. Et tout ça se configure visuellement dans Langflow, en mode drag-and-drop, sans écrire une ligne de code.

L'interface d'OpenRAG

D'ailleurs, pour ceux qui veulent aller plus loin, y'a des SDK Python et JavaScript pour intégrer ça dans vos propres apps. Un petit pip install openrag-sdk et vous pouvez interroger votre base documentaire depuis n'importe quel script. Et l'autre truc super chouettos, c'est le serveur MCP intégré : un pip install openrag-mcp et vous connectez directement votre base de connaissances à Claude Desktop ou Cursor. J'utilisais pour ma part LEANN jusqu'à présent mais je pense que je vais basculer rapidement sur OpenRAG. Et grâce à ça votre IDE / Claude Code / Ce que vous voulez, a accès à toute votre documentation technique sans quitter l'éditeur.

Côté technique, le projet est porté par l'équipe de Langflow (DataStax), ce qui explique la qualité de l'intégration. Et le déploiement se fait aussi en Docker, Podman ou Kubernetes pour ceux qui veulent du plus fiable.

Après comme c'est une solution tout-en-un, ça embarque pas mal de dépendances. OpenSearch à lui seul est connu pour être gourmand en ressources et si vous avez déjà votre propre stack RAG bien rodée avec une base vectorielle légère comme LEANN , c'est peut-être overkill. En fait, OpenRAG s'adresse plutôt à ceux qui partent de zéro ou qui veulent un truc clé en main pour une équipe, parce que tout est déjà branché.

Prêt à chatter avec vos docs ?

Le vrai intérêt par rapport à un assistant comme Khoj , c'est le côté plateforme extensible. Langflow vous permet de construire des workflows RAG personnalisés visuellement, d'ajouter des étapes de filtrage, de brancher plusieurs LLM en parallèle, ou de créer des agents spécialisés par type de document. C'est donc clairement plus "usine" que "bricolage"... mais parfois c'est ce qu'il faut, surtout si vous bossez en équipe et que le bricolage perso finit toujours par casser au bout de 3 mois.

Si vous en avez marre de bricoler vos pipelines de recherche augmentée à la main, allez jeter un œil !

Splitter son terminal en plusieurs panneaux, gérer des sessions persistantes, le tout avec les mêmes raccourcis que tmux... mais sous un bon gros Windows des familles, nativement, en Rust et sans avoir besoin de se galérer avec WSL !

C'est exactement ce que fait psmux , un multiplexeur de terminal conçu pour PowerShell et cmd.exe qui utilise directement l'API ConPTY de Windows 10/11. Du coup, pas de couche d'émulation Unix, pas de Cygwin, pas de MSYS2... ça tourne direct sur votre bécane.

Pour ceux qui débarquent, un multiplexeur de terminal ça permet de découper votre console en plusieurs zones (des "panes" que j’appellerai "panneau" parce que merde c'est + français), de jongler entre plusieurs sessions, et surtout de retrouver votre boulot exactement là où vous l'avez laissé même après une déconnexion. Sous Linux, tout le monde utilise tmux pour ça mais sous Windows, jusqu'ici c'était soit WSL (installer tout un sous-système Linux juste pour splitter un terminal, c'est un peu overkill quand même !), soit des splits basiques via Windows Terminal qui ne gèraient ni les sessions persistantes ni le détachement. Snif...

psmux en action sous PowerShell

L'installation est rapide. Un petit winget install psmux et hop, c'est réglé. Ça passe aussi par Cargo, Scoop ou Chocolatey pour les puristes. Ensuite, vous tapez psmux dans PowerShell 7 et vous retrouvez vos marques : Ctrl+B pour le prefix, les mêmes commandes split-window, new-session, attach... L'outil implémente 76 commandes tmux avec plus de 126 variables de formatage. Et y'a même un mode copie Vim avec 53 raccourcis clavier.

Bref, si vous avez une mémoire musculaire ultra développée pour tmux, vous êtes chez vous !

Et le truc cool, c'est que psmux lit directement vos fichiers .tmux.conf existants. Du coup, vos raccourcis custom et pas mal de thèmes (Catppuccin, Dracula, Nord...) fonctionneront directement, même si les configs tmux les plus complexes avec des scripts bash ou TPM peuvent nécessiter des ajustements. Et y'a aussi Tmux Plugin Panel pour vous accompagner dans l'ajout de plugins et de thèmes.

Alors je vous connais les raloux sous OuinOuin, vous allez me dire "Windows Terminal fait déjà des splits avec Alt+Shift+D"... sauf que non, c'est pas pareil. Windows Terminal découpe votre fenêtre visuellement mais ne gère ni les sessions persistantes, ni le scripting, ni le détachement. Avec psmux, vous lancez une session le lundi, vous fermez votre terminal, vous revenez le mardi et tout est encore là : vos panneaux, vos processus, votre historique. C'est ça la vraie différence avec un simple split visuel.

D'ailleurs, si vous utilisez Claude Code ou d'autres agents IA en ligne de commande , psmux intègre un support pour les agent teams qui permet à chaque agent de spawner dans son propre panneau automatiquement.

Côté support souris, c'est complet : clic pour sélectionner un panneau, drag pour redimensionner les bordures, molette pour remonter dans l'historique du buffer. Tout est activé par défaut, pas besoin de rajouter set -g mouse on comme sous tmux. L'outil tourne sous Windows 10 et 11, et le projet est sous licence MIT.

Après c'est encore jeune et y'a quelques galères connues notamment le support des caractères CJK et UTF-8 multi-octets qui peut se planter comme une merde sur des textes longs. Et split-window -c ne préserve pas toujours le répertoire courant (oubliez pas de vérifier votre pwd après un split). Par contre, le dev répond en quelques heures, et des PR externes sont mergées régulièrement... donc c'est bon signe !

Bref, c'est propre, c'est natif, et ça lit vos .tmux.conf ! Que demande le peuple barbu emprisonné sous Windows, finalement ? Eh bien pas grand chose de plus pour être heureux.

Un TUI en Rust pour gérer vos coffres Obsidian sans quitter le terminal c'est ce que propose Basalt qui détecte automatiquement vos vaults, affiche le markdown avec un rendu visuel, et depuis la v0.12.3, y'a même un mode vim intégré. Le tout sans avoir besoin que la vraie app tourne en arrière-plan !

Et c'est là toute la différence avec le CLI officiel d'Obsidian dont je vous parlais il y a quelques jours. Car le CLI a besoin de l'app qui tourne via un socket local. Basalt, lui, lit en fait vos fichiers .md directement sur le disque. Du coup, ça marche en SSH, sur un serveur headless, ou sur n'importe quelle machine où vous avez juste vos fichiers markdown. C'est carrément pratique !

L'installation se fait en une commande :

cargo install basalt-tui

Au premier lancement, l'outil va alors chercher automatiquement vos coffres en lisant le fichier de config (sous macOS c'est dans ~/Library/Application Support/obsidian/obsidian.json). Comme ça, hop hop, vos vaults apparaissent, vous naviguez au clavier et vous passez d'un coffre à l'autre avec Ctrl+G. Vous pouvez aussi passer par aqua ou télécharger un binaire pré-compilé sur la page releases si vous préférez.

Basalt en action, navigation dans un vault Obsidian

Vous ouvrez alors une note et le markdown s'affiche avec un rendu visuel : les # disparaissent au profit d'indicateurs plus colorés, les blocs de code ont un fond distinct, les callouts > [!NOTE] sont reconnus, et les wiki-links [[Ma Note]] sont également parsés. D'ailleurs, quand vous renommez une note avec r, tous les wiki-links qui pointent vers elle sont mis à jour automatiquement dans tout le vault. Pas de search-replace à la main, ça fait toujours du bien !

Après faut pas s'attendre à un clone complet non plus. Y'a pas de rendu pour le gras, l'italique ou les tableaux. Pas de recherche dans les notes. Pas de graph view. L'éditeur intégré est expérimental (pas d'undo, pas de copier-coller, pas de sélection). C'est assumé de ce que j'ai pu voir, car le projet se présente comme un compagnon minimaliste.

Et c'est justement pour ça que le mode vim est le bienvenu, à vrai dire. Vous pouvez activer ça dans votre config TOML comme ceci :

vim_mode = true

Le mode vim en action dans Basalt

Et là vous avez hjkl pour naviguer, gg / G pour sauter en haut et en bas, w / b pour les mots, i pour l'insertion. C'est pas forcément aussi complet qu'un vrai vim, mais franchement, pour parcourir vos notes c'est agréable.

Le vrai kiff, c'est la config TOML qui permet de lancer un éditeur externe sur la note en cours :

[global]
key_bindings = [
 { key = "ctrl+alt+e", command = "exec:vi %note_path" },
]

Du coup, le workflow devient : Basalt pour naviguer et lire et un raccourci clavier pour ouvrir dans vim (ou n'importe quel éditeur) quand vous voulez éditer sérieusement. C'est le genre de combo qui fonctionne bien quand vous bossez en full terminal .

Le projet est sous licence MIT, écrit en Rust avec ratatui, et tourne sur Linux, macOS et Windows. Tiens, la v0.12.3 ajoute aussi la création de notes et dossiers directement depuis l'explorateur avec n et N... Ça avance plutôt vite comme projet !!

Voilà, si vos notes vivent dans des coffres et que le terminal c'est votre habitat naturel, Basalt fera bien le boulot.

Conductor c'est une app macOS qui vous permet de lancer plusieurs agents Claude Code ou Codex en parallèle, chacun dans son propre worktree git histoire qu'ils ne se marchent pas dessus. Le tout est développé par Melty Labs, et c'est gratuit !! (enfin l'app en elle-même, parce que les tokens Claude ou OpenAI, c'est vous qui casquez hein ^^).

Vous ouvrez l'app, Cmd+N pour créer un workspace, et ensuite, chaque agent bosse dans son coin sur sa propre branche git comme ça y'a pas de conflits ni de merge foireux au milieu du boulot ! Et grâce à cet outil, vous voyez d'un coup d'oeil ce que chacun fabrique via le diff viewer intégré. Ensuite, vous reviewez, et quand c'est bon vous mergez. Comme un chef de chantier en fait, sauf que vos ouvriers ce sont des LLM.

Y'a plus qu'à vous acheter un casque !

Côté modèles, ça supporte Claude Code (avec votre clé API ou votre abonnement Pro/Max) et Codex d'OpenAI. Et la dernière release a d'ailleurs ajouté GPT-5.4 tout frais démoulé.

Le truc cool c'est surtout cette isolation par git worktrees. Chaque workspace étant un worktree séparé, les agents peuvent ainsi modifier des fichiers en parallèle sans se marcher dessus. Si vous avez déjà essayé de faire tourner deux sessions de vibe coding en même temps sur le même repo... vous savez que ça finit en général en carnage.

Attention quand même, chaque worktree bouffe de l'espace disque (genre un repo de 2 Go × 5 agents, ça peut piquer...) donc pensez-y si votre repo est un peu lourd.

L'app intègre aussi le MCP (Model Context Protocol) pour brancher des outils externes, des slash commands custom, et un système de checkpoints qui permet de revenir en arrière tour par tour si un agent part en vrille (genre il supprime un fichier critique... ça arrive). Perso, le diff viewer c'est pas mal du tout car ça évite de jongler entre le terminal et VS Code.

Après dommage que ce soit pour macOS seulement. Déso hein ^^

En tout cas, vu le rythme des mises à jour, c'est un projet qui avance vite. Des devs de chez Linear, Vercel, Notion ou Stripe l'utilisent déjà, et ça a l'air suffisamment solide pour de la prod (mais testez bien avant hein, faut jamais me faire confiance ^^).

Et si vos fichiers .env se transformaient en un joli tableau avec des astérisques partout afin d'assurer la confidentialité de vos clés API et autres crédentials ? Hé bien c'est exactement ce que propose Dotenv Mask Editor , une extension VS Code qui remplace carrément l'éditeur texte par une grille.

Du coup, vos clés API, tokens AWS, mots de passe PostgreSQL et autres STRIPE_SECRET_KEY s'affichent sous forme de ****** et vous pouvez bosser dessus même si quelqu'un mate par-dessus votre épaule.

En gros, dès que vous ouvrez un fichier .env (ou .env.local, .env.production... bref, tout ce qui matche le pattern), l'extension vous présente vos variables dans un tableau à deux colonnes. Les clés à gauche, les valeurs masquées à droite. Pour modifier une valeur, hop, vous cliquez dessus et elle se dévoile le temps de l'édition. Vous cliquez ailleurs, c'est re-masqué. Pas de sauvegarde manuelle à faire, ça se fait tout seul.

Le masquage se déclenche à partir de 6 caractères (en dessous, c'est probablement pas un secret... genre PORT=3000 ou DEBUG=true, on s'en fiche). Et le truc cool, c'est que tout tourne en local sur votre machine.

Si vous vous dites "mais attends, y'a pas déjà Camouflage pour ça ?"... oui et non. Camouflage masque vos secrets avec un overlay pendant les démos et le partage d'écran, mais vous continuez à éditer dans l'éditeur texte classique. Dotenv Mask Editor, lui, change complètement l'interface, c'est un éditeur de tableau dédié aux variables d'environnement. Deux approches différentes du coup, et rien ne vous empêche d'utiliser les deux.

L'extension est sous licence MIT, fonctionne sur toutes les plateformes (Windows, Linux, macOS, même VS Code Web) et vous pouvez ajouter des patterns de fichiers personnalisés dans vos settings.json.

D'ailleurs, si vous voulez l'installer, c'est du classique : Ctrl+Shift+X dans VS Code (Cmd+Shift+X sur Mac), vous tapez "dotenv mask" et voilà.

Avec ça, vos secrets restent secrets mais faut quand même pas oublier de mettre votre .env dans le .gitignore hein. ^^

yt-dlp, tout le monde connaît. C'est l'outil parfait pour télécharger des vidéos depuis à peu près n'importe quel site. Sauf que bon, la ligne de commande, c'est pas le truc de tout le monde. Du coup, les interfaces graphiques pour habiller tout ça, y'en a un paquet... mais trouver celle qui est jolie ET sous licence libre, c'est pas gagné.

Heureusement, VidBee est un nouveau venu qui coche pas mal de cases. L'appli tourne sur Windows, macOS et Linux, elle est sous licence MIT, et l'interface est plutôt clean. On colle une URL, on choisit le format MP4 ou MKV, on sélectionne la qualité entre 720p et 8K et hop, ça télécharge.

Fastoche !

Interface principale de VidBee

Bon, jusque-là, vous allez me dire que Stacher7 fait déjà ça. Sauf que VidBee a un petit truc en plus qui vaut le détour : un système de flux RSS intégré. En gros, vous vous abonnez à vos chaînes YouTube préférées via RSS, et l'outil télécharge automatiquement les nouvelles vidéos en arrière-plan. Comme ça, y'a plus besoin de vérifier manuellement si votre créateur favori a sorti un truc. Attention par contre, prévoyez du stockage parce que ça peut vite remplir un disque dur si vous suivez plusieurs chaînes...

Côté technique, ça gère les résolutions jusqu'à la 8K (si votre écran suit), l'extraction audio seule en MP3, les sous-titres dans plus de 50 langues au format SRT, et même le téléchargement de playlists entières ou de contenus privés si vous êtes connecté à votre compte. Y'a aussi un support proxy pour contourner les restrictions géographiques (genre si votre FAI bloque certains sites) et une extension navigateur pour lancer les téléchargements en un clic.

File de téléchargement VidBee

Et pour les plus bidouilleurs d'entre vous, VidBee propose carrément un mode serveur avec une API Fastify et une interface web, le tout déployable en Docker. Perso, c'est ça que je trouve le plus malin. Un docker compose up -d, l'API écoute sur le port 3100, l'interface web sur le 3000, et vous avez votre propre service de téléchargement accessible depuis n'importe quel appareil du réseau local. Attention quand même à pas le rendre accessible publiquement non plus, hein... sauf si vous voulez des ennuis ^^.

Le projet est plutôt actif, codé en TypeScript et basé sur Electron pour le desktop. D'ailleurs, le monorepo inclut aussi une extension navigateur et un site de doc complet. Par contre, c'est encore en développement très actif, du coup y'a forcément des bugs qui traînent par-ci par-là et des trucs qui cassent de temps en temps mais vu la qualité du service rendu, c'est pas bien grave !

Bref, c'est gratuit, c'est open source, et ça marche sur Windows, macOS et Linux. Allez voir !

Merci à Lorenper pour le partage !

Vous avez combien de dossiers test sur votre machine ? Dix ? Cinquante ? Deux cents ? Tobi Lütke, le mec qui a cofondé Shopify, avait le même problème... Alors il a pondu try , un petit script Ruby qui donne un vrai foyer chaleureux à vos expérimentations de dev déjanté.

Le principe est hyper simple. Vous tapez try redis dans votre terminal, et magie magie, soit ça vous envoie direct dans votre dossier d'expérimentation Redis existant, soit ça vous propose d'en créer un nouveau avec la date du jour en préfixe, genre 2025-08-17-redis-experiment. En fait c'est con, mais rien que le préfixe de date, ça change tout... car 3 semaines plus tard, quand vous cherchez ce bout de code pondu à 2h du mat en rentrant de soirée, hé bien vous le retrouvez !

La recherche fuzzy fait le boulot, comme ça par exemple vous tapez pgres, ça matche postgres-local. Vous tapez connpool, ça retrouve connection-pool. Et ce sont les résultats les plus récents qui remontent en premier, parce que bon, ce que vous avez touché hier est souvent plus pertinent que le truc d'il y a 6 mois. Et y'a même un petit score de pertinence affiché à côté de chaque résultat !

Côté installation, un gem install try-cli suivi d'un eval "$(try init)" dans votre .zshrc, et c'est terminé. Ça marche aussi avec Fish et via Homebrew pour ceux qui préfèrent. D'ailleurs, le cœur du truc tient dans un seul fichier Ruby, par contre, faut Ruby 3.0 minimum (le Ruby livré avec macOS est trop vieux, donc un petit brew install ruby avant si besoin).

Y'a aussi quelques bonus plutôt pas mal. Par exemple la commande try . (si vous êtes dans un repo Git) crée un worktree du repo courant dans votre dossier d'expérimentations, ce qui est super pratique pour tester un truc sans polluer votre branche principale. Et try clone URL_GITHUB clone un repo direct dans un dossier daté, genre 2025-08-17-nom-du-repo. Si vous aimez les outils jetables bien rangés , c'est exactement le délire.

Bon, vous pourriez faire un alias bash à la place, mais finalement la recherche fuzzy et le classement par date, c'est quand même autre chose qu'un bête mkdir. Tous vos dossiers vivent dans ~/src/tries par défaut (changeable via TRY_PATH), avec une petite interface en mode texte qui affiche le temps écoulé depuis votre dernier passage. Le README dit que c'est pensé pour les cerveaux qui papillonnent... et franchement, si vous êtes comme moi, du genre à avoir 15 projets en cours, c'est pile le délire qui va vous sauver !! Si vous passez votre vie dans le terminal , c'est un de ces projets qu'on installe et qu'on n'oublie plus.

Attention quand même, le projet est encore jeune et quelques bugs trainent côté Homebrew et avec Ruby 4.0.

Amusez-vous bien !

Les 404, c'est la plaie du web... J'en sais quelque chose, je fais la chasse à ça en permanence sur mon propre site. C'est vrai que c'est relou parce que vous bookmarkez un projet cool, vous y retournez trois mois après... et pouf, ça a disparu. Le dev n'a pas renouvelé son nom de domaine, l'hébergeur a fermé boutique, le contenu s'est évaporé ou que sais-je encore... En fait, sur le web, RIEN n'est permanent.

PinMe prend le problème à l'envers en collant vos fichiers directement sur IPFS . En gros, au lieu de dépendre d'un serveur unique qui peut tomber n'importe quand, vos pages sont distribuées sur un réseau décentralisé et identifiées par un hash CID unique. Du coup, tant que le réseau tourne, votre contenu existe. Pas besoin de renouveler quoi que ce soit, pas besoin de payer un hébergeur... ça fonctionne tout seul.

L'installation se fait en une ligne :

npm install -g pinme

Pour déployer votre site statique, c'est hyper simple :

pinme upload dist/

L'outil détecte le dossier de build, ou plutôt il le devine tout seul selon votre framework : dist/ pour Vite et Vue, build/ pour Create React App, out/ pour Next.js en export statique. Ça évite d'avoir à se palucher de la config.

Côté limites, on est sur 200 Mo par fichier et 1 Go au total ce qui est largement suffisant pour une landing page ou une démo ! Et c'est GRATUIT. Pour ceux qui veulent un domaine lisible plutôt qu'un hash cryptique, y'a aussi des domaines ENS (les .eth sur Ethereum) ou des sous-domaines en .pinit.eth.limo. Après pour les domaines custom faudra un compte VIP par contre.

Le truc sympa c'est que vos fichiers restent accessibles via n'importe quelle passerelle IPFS, genre dweb.link ou w3s.link. Ainsi, si votre hébergeur ferme ou que votre domaine expire comme je le disais en intro, on s'en fiche ! Le contenu est toujours là, épinglé quelque part sur le réseau. C'est du stockage immuable, basé sur le contenu lui-même... du coup personne ne peut modifier ou supprimer ce que vous avez publié. (Et en fait vous non plus, faut le savoir.)

Et y'a aussi des commandes pour exporter en fichiers CAR et réimporter ailleurs, ce qui est pratique pour archiver ou migrer entre passerelles.

Voilà c'est gratuit pour 1 Go de stockage, c'est open source (licence MIT) et c'est par là . Merci à Lorenper pour la découverte !

Si vous avez déjà tapé [ss -tulnp](https://www.it-connect.fr/lister-les-ports-en-ecoute-sous-linux-avec-lsof-netstat-et-ss/) dans un terminal, vous savez que c'est moche. Genre, VRAIMENT moche. Les colonnes qui se chevauchent, les adresses tronquées, bref c'est un festival du bordel. Mais c'était sans compter sur ce dev qui a pondu Snitch , un outil en Go sous licence MIT qui vient concurrencer ss et netstat... sauf que pour une fois, c'est lisible, regardez :

L'interface de Snitch en action, sobre et lisible

En gros, c'est un ss moderne avec une interface TUI interactive. Vous lancez la commande dans votre terminal et tadaaa, vous avez un tableau propre avec toutes vos connexions réseau, les processus associés, les ports, les protocoles... le tout avec des couleurs et une navigation au clavier. Rien à voir donc avec le pavé monochrome habituel !

Le truc cool aussi ce sont les filtres. Vous pouvez taper snitch ls proto=tcp state=listen pour ne voir que les sockets TCP en écoute, ou snitch ls proc=nginx pour traquer votre serveur web. Y'a même un filtre contains= pour chercher dans les adresses... genre contains=google pour voir tout ce qui cause avec Mountain View.

D'ailleurs, côté commandes c'est en fait bien fichu. snitch ls pour un tableau statique, snitch json pour du JSON brut si vous voulez scripter, et snitch watch -i 1s pour streamer les connexions en temps réel. Du coup ça s'intègre nickel dans vos pipelines.

La TUI elle-même vaut le détour. Vous naviguez avec j/k (comme dans Vim, forcément), vous basculez TCP/UDP avec t/u, et le plus jouissif... vous pouvez killer un processus directement avec la touche K. Plus besoin de noter le PID et d'ouvrir un autre terminal ! Sauf que attention, sur Linux faut quand même lancer en root pour avoir les infos complètes sur les processus, parce que l'outil va lire dans /proc/net/*. Ça ne marche pas non plus sur Windows, c'est Linux et macOS uniquement.

Pour ceux qui aiment personnaliser leur terminal (oui, je vous connaîs...), y'a une quinzaine de thèmes, Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox... la config se fait dans ~/.config/snitch/snitch.toml et l'outil peut aussi conserver vos préférences de filtres entre les sessions (faut activer remember_state dans la config).

Côté installation, c'est pas la mer à boire. brew install snitch sur macOS, go install github.com/karol-broda/snitch@latest si vous avez Go, yay -S snitch-bin sur Arch, et y'a même des images Docker pour les plus prudents !

Donc si vous êtes du genre à surveiller votre trafic réseau ou à garder un oeil sur vos outils de diagnostic Linux , c'est clairement à tester.

Perso, pour du debug réseau rapide, je trouve que c'est carrément plus agréable que de se taper un ss -tulnp.

Si vous utilisez Notion au quotidien et que vous avez toujours rêvé de piloter vos bases de données depuis un terminal... y'a enfin un truc qui tient la route.

Ça s'appelle notion-cli , c'est un binaire Go qui embarque 39 commandes couvrant TOUTE l'API Notion. Il s'agit d'un seul exécutable pour macOS, Linux et Windows (amd64 et arm64) sans dépendance qui vous permet de gérer pages, bases de données, blocs et commentaires sans jamais ouvrir un navigateur.

L'installation, c'est du classique : brew install 4ier/tap/notion-cli sur macOS, go install pour les puristes, npm install -g notion-cli-go ou même Docker. Il faut juste un token d'intégration Notion (le ntn_xxxxx que vous générez sur notion.so/my-integrations), vous le collez dans ~/.config/notion-cli/config.json ou en variable NOTION_TOKEN, et c'est parti.

notion-cli en action dans le terminal

Le truc cool, ce sont les filtres humain-friendly. Au lieu de se taper du JSON pour filtrer une base, vous écrivez Status=Done et l'outil se débrouille tout seul. En fait, il détecte le type de chaque propriété (texte, date, sélection...) et adapte le filtre automatiquement. C'est carrément pas mal, je trouve.

Et côté Markdown, c'est la fête ! Vous exportez une page entière avec notion block list <page-id> --md --depth 3, et inversement, vous injectez un fichier .md dans Notion via notion block append <page-id> --file notes.md. Pour ceux qui bossent avec de la doc technique, ça simplifie sérieusement les choses. Bon, ça ne marche pas avec les blocs synchronisés ou les embeds exotiques, mais pour le reste c'est nickel.

D'ailleurs le mode "pipé" est vraiment malin. Car dans le terminal, l'outil affiche de jolies tables colorées mais dès que vous le "pipez" vers jq ou un script, il bascule en JSON automatiquement. Du coup, intégrer ça dans un pipeline shell ou un cron... c'est aucun parsing à faire. Voilà quoi.

Après des CLI pour Notion, y'en a déjà quelques-uns. Sauf que la plupart sont soit limités aux tâches (comme notion-cli-go qui gère surtout le côté todo), soit cantonnés à l'export (et souvent liés à un OS ou un langage précis).

Celui de 4ier, c'est donc le premier à couvrir l'API en entier : pages, bases, blocs, commentaires, fichiers, utilisateurs, et même un accès REST brut via notion api GET /v1/endpoint. En gros, c'est le gh de GitHub, mais pour Notion (et pour une fois, c'est pas juste du blabla marketing ^^).

Les cas d'usage qui tuent c'est par exemple un script cron qui crée une entrée hebdo avec notion page create <db-id> --db "Name=Weekly" "Status=Todo". Un backup qui exporte vos pages critiques en Markdown toutes les nuits. Ou un CI/CD qui met à jour un changelog Notion à chaque deploy. Quelques lignes de bash et c'est réglé, car l'outil gère tout le reste ! C'est hyper rare un CLI qui couvre autant de terrain.

Y'a aussi le côté agent-friendly pour ceux qui kiffent l'IA. L'outil retourne des codes de sortie propres, du JSON exploitable, et s'installe comme skill agent via npx skills add 4ier/notion-cli. Dans la lignée de Gemini CLI , on voit de plus en plus d'outils pensés terminal-first... et je trouve que c'est carrément bien.

Après comme souvent quand je vous présente des outils, le projet est tout frais (v0.3.0, licence MIT), avec une petite communauté donc attention, car comme tout ce qui dépend d'une API tierce, si Notion bouge ses endpoints... voilà quoi. Mais c'est propre, c'est testé, et ça tourne déjà très bien.

Votre navigateur va pouvoir souffler un peu.

Intégrer un formulaire de contact sur un petit projet ou un MVP, c'est souvent la plaie. Soit on s'embête avec un backend dédié, soit on finit par payer un abonnement chez Typeform ou FormSpree parce qu'on a dépassé le quota gratuit en trois jours.

Et c'est LÀ qu'intervient GitForms .

Le concept est tout bête mais fallait y penser. En fait l'idée c'est d'utiliser les GitHub Issues comme base de données pour vos formulaires comme ça, au lieu de stocker les messages dans une DB SQL ou NoSQL obscure, chaque soumission de formulaire crée automatiquement une nouvelle issue dans le dépôt GitHub de votre choix.

Pratique, non ?

Côté technique, c'est du solide puisqu'on est sur du Next.js 14, du TypeScript et du Tailwind CSS. Et pour le mettre en place, c'est vraiment l'affaire de 5 minutes... vous clonez le repo, vous générez un token GitHub, et vous déployez ça sur Vercel, Netlify ou même via Docker. Et hop, vous avez un formulaire fonctionnel avec des notifications par email automatiques (merci le système de notifs de GitHub).

L'outil est super personnalisable, vous pouvez changer les couleurs, les textes et même ajouter des langues en bidouillant simplement des fichiers JSON, sans même avoir à toucher au code source. C'est idéal pour ceux qui veulent un truc propre et rapide sans sortir la carte bleue toutes les cinq minutes.

Attention quand même, car niveau RGPD, ne croyez pas que c'est magique. Certes, c'est auto-hébergeable, mais vos données transitent par GitHub. Il faudra donc veiller à ce que votre dépôt soit privé si vous collectez des données personnelles, histoire de ne pas afficher les emails de vos prospects à la vue de tous. Notez aussi que GitHub a des limites de taux (rate limits) pour la création d'issues, donc si vous recevez 10 000 messages par jour, ça risque de coincer.

Enfin, un petit mot sur la licence, le projet semble être sous CC BY-NC-SA 4.0 ce qui veut dire qu'il est parfait pour vos projets perso ou vos tests, mais pour un usage purement commercial, il faudra peut-être vérifier si ça colle avec vos besoins.

Bref, si vous cherchez une solution simple, propre et qui exploite intelligemment les outils que vous utilisez déjà, jetez un œil à GitForms. C'est open source et ça dépanne bien pour les petits projets qui n'ont pas besoin d'une artillerie lourde.

Source

Apple vient de lâcher une bombe pour tous les développeurs pommés de leur écosystème. Si vous pensiez que l'IA dans l'IDE se limitait à de l'autocomplétion un peu boostée, accrochez-vous parce que la version 26.3 de Xcode arrive (enfin, sa Release Candidate pour l'instant) et elle apporte avec elle le "codage agentique". Aaah je l'attendais depuis looongtemps !

Concrètement, ça veut dire qu'au lieu d'avoir un simple assistant qui vous suggère la fin de votre boucle "for", vous avez maintenant de véritables agents capables de prendre des initiatives. Donc intégration directe de Claude (Anthropic) et de Codex (OpenAI). Apple qui ouvre les vannes et vous laisse choisir votre moteur préféré parmi ces deux-là au lancement, c'est fou !

Le délire est assez poussé puisque ces agents ne se contentent pas d'écrire du code dans un coin. Ils ont accès à la structure complète de votre projet, à la doc officielle d'Apple (histoire de privilégier les dernières APIs) et peuvent même lancer des builds ou des tests pour vérifier que leur tambouille fonctionne. Si ça plante, ils analysent l'erreur et tentent de corriger le tir tout seuls. C'est un peu comme ce qu'on retrouve déjà dans Cursor et Windsurf.

Perso, ce qui me botte le plus, c'est l'utilisation du Model Context Protocol (MCP) parce que je me sers tout le temps de ça. Pour ceux qui ne suivent pas, c'est un protocole ouvert qui permet d'interfacer Xcode avec des agents compatibles.

Et côté interface, c'est plutôt propre. Y'a un petit panneau à gauche pour donner vos ordres en langage naturel ("Ajoute-moi une vue SwiftUI pour gérer le profil utilisateur avec une image ronde et un dégradé"), et tadaaa, l'agent découpe la tâche en petites étapes. On voit le code changer en temps réel, avec des surbrillances pour ne pas être perdu. D'ailleurs, si le résultat est foireux (ça arrive, hein), Xcode crée des "milestones" à chaque modification effectuée par l'agent pour revenir en arrière en un clic. Pas de panique donc.

Si vous voulez mettre les mains dedans tout de suite, la Release Candidate est dispo depuis ce 3 février sur le site développeur d'Apple. Attention quand même aux prérequis puisque même si Xcode 26.3 tourne sur macOS Sequoia 15.6+, pour profiter des fonctions d'intelligence (l'agentic coding, quoi), il vous faudra impérativement un Mac avec une puce Apple Silicon sous macOS Tahoe.

Et pour ceux qui veulent vraiment monter en compétence, Apple organise un atelier "code-along" ce jeudi 5 février sur son site développeur. C'est l'occasion de voir comment dompter ces agents sans qu'ils ne transforment votre projet en plat de spaghettis.

Bref, le métier de dev est en train de muter sévère et ce nouvel Xcode 26.3 pose une sacrée brique.

A vous de jouer maintenant !

Source

Vous connaissez sûrement TradingView pour suivre les cours de la bourse / crypto, et son fameux langage Pine Script. C'est top pour bidouiller des indicateurs techniques sans se prendre la tête, mais dès qu'on veut sortir du bac à sable pour intégrer ça dans un bot perso ou un backend, ça se corse sévère. Alors moi je fais pas tout ça, ni trading, ni dev autour du trading, mais je sais qu'on peut se retrouver souvent bloqué par les limites de la plateforme.

Hé bien bonne nouvelle pour tous les traders en culottes courtes qui n'ont pas encore compris que le DCA c'est + efficace que le day-trading, Alaa-eddine (un lecteur fidèle, coucou !) a bossé sur un projet qui va vous plaire : PineTS .

PineTS ce n'est pas encore l'un de ses parseurs bancal mais un vrai transpiler ET un runtime complet qui permet d'exécuter du code Pine Script directement dans un environnement Javascript ou TypeScript. Il vous faudra évidemment Node.js et votre bon vieux navigateur pour que ça fonctionne.?

Vous prenez votre script ta.rsi(close, 14), vous lancez un npm install pinets et hop, ça tourne sur votre serveur. PineTS gère la "transpilation" (non, c'est pas quand on a chaud sous les bras ^^) à la volée et fournit une implémentation des fonctions standard de Pine Script (v5 et v6). Il supporte déjà plus de 60 indicateurs techniques (SMA, EMA, MACD, Bollinger...), le multi-timeframe et même le streaming de données temps réel.

Du coup, ça ouvre des portes assez dingues ! Et si vous vous demandez si Pine Script est similaire à JavaScript, la réponse est "pas tout à fait", mais PineTS fait le pont entre les deux mondes. Vous pouvez grâce à ça récupérer des données de marché via n'importe quelle API (CCXT, Binance...), les passer à la moulinette PineTS, et utiliser le résultat pour trigger des ordres ou nourrir une IA.

Attention par contre, tout n'est pas encore supporté à 100%. Sauf si vous restez sur du standard, là c'est royal... Mais si vous utilisez des fonctions graphiques très exotiques, faudra vérifier tout pour ne pas finir sur la paille. Le seul truc qui manque peut-être, c'est une compatibilité totale avec les scripts v4, mais bon, on est en v6 maintenant et pour la logique de trading pure, c'est propre.

D'ailleurs, pour ceux qui utilisent ChatGPT pour écrire du Pine Script, sachez que vous pouvez maintenant intégrer ces snippets générés par l'IA directement dans vos propres applis Node.js. C'est quand même plus flexible que de copier-coller ça dans TradingView à chaque fois.

Et ce n'est pas tout (hé oui ^^) car pour la partie visuelle, il a aussi sorti également QFChart , une bibliothèque dédiée pour afficher le tout avec de jolis graphiques financiers. C'est le combo gagnant pour se faire un dashboard de trading sur mesure sans dépendre de l'infra de TradingView.

Perso, je trouve ça génial pour ceux qui veulent garder la main sur leur exécution ou faire du backtesting sérieux avec leurs propres données. En fait, c'est exactement ce qu'il manquait aux traders-developpeurs pour coder leur propre logique de A à Z. Le projet est open source et dispo sur GitHub et y'a même un playground pour tester vos scripts en live et voir la transpilation en temps réel.

Si vous faites du trading algo, ça vaut clairement le coup d'œil.

PineTS est à découvrir ici ! Et un grand merci à Alaa-eddine pour le partage !

Il y a quelques jours, un lecteur (merci Benjamin !) m'a envoyé un outil qu'il a bricolé lui-même avec Codex d'OpenAI et ça touche une petite corde sensible chez moi, d'où le fait que je vous en parle.

C'est pas souvent que je bosse avec des clients sur autre chose que des articles mais il m'est arrivé par le passé qu'un client m'envoie ses retours par mail, avec des captures d'écran floues, des flèches rouges partout et des commentaires du genre "le truc là, à gauche, je sais pas trop ??".

Alors de mon côté, j'ai testé pas mal de solutions pour évier ça mais j'ai rien trouvé de foufou... Figma par exemple c'est top pour les retours mais faut que le client crée un compte (et ça, c'est jamais gagné), Marker.io c'est bien fichu mais c'est payant. J'avais même essayé Loom à un moment, mais bon, leur demander d'enregistrer leur écran c'était trop compliqué.

Alors que UxNote, lui, règle exactement ce problème sans rien de tout ça !

En fait, ça permet d'intégrer une balise JavaScript dans votre page (juste avant le </body>) et hop, une petite toolbar apparaît.

<script src="https://github.com/ninefortyonestudio/uxnote/releases/download/v1.0.0/uxnote.min-v1.0.0.js"></script>

Votre client peut alors surligner du texte, épingler des éléments avec des badges numérotés, ajouter des commentaires... et surtout, exporter tout ça proprement en JSON ou l'envoyer direct par mail.

Comme ça, fini le chaos habituel des retours clients façon "j'ai annoté le PDF que j'ai imprimé puis scanné". Là, les commentaires sont directement contextualisés sur la page, exactement là où ils doivent être. C'est vrai que des outils d'annotation web existent depuis des lustres, mais UxNote a choisi le stockage 100% local (via le localStorage) plutôt que de monter un backend avec des comptes utilisateurs. Et c'est ce qui fait toute la différence niveau simplicité, avec les autres outils.

Par contre attention, si votre client vide son cache navigateur, il perd ses annotations... Perso je vous recommande donc de faire l'export JSON dès que possible pour éviter les mauvaises surprises.

L'outil propose aussi un mode "assombrissement" qui met en évidence la zone annotée (pratique pour se concentrer), des couleurs personnalisables, et même la possibilité de bloquer certains éléments de l'annotation avec l'attribut data-uxnote-ignore. Ça fonctionne sur les environnements de staging, en local, et même sur les SPA ... sauf si vous avez une CSP ultra stricte, auquel cas faudra autoriser le script et les styles inline dans votre config.

Bref, si vous bossez avec des clients qui ont du mal à exprimer leurs retours autrement qu'en pièces jointes de 15 Mo, UxNote pourrait bien sauver les quelques cheveux qu'il vous reste. Et en plus c'est gratuit, open source et disponible sur GitHub .

Que demande le peuple ???

Merci Benjamin !

Vous vous souvenez des cassettes VHS ?

Bon, là rien à voir avec le magnétoscope de mémé qui clignote à 12:00 mais je suis quand même content de vous présenter VHS , un petit outil open source concocté par la team Charm dont je vous ai déjà parlé.

Y'a pas longtemps, je cherchais un moyen propre de faire une petit démo d'un projet perso et je ne sais pas si vous connaissez Terminalizer (j'en avais déjà parlé), mais là pour le coup, j'ai préféré l'approche de VHS parce qu'au lieu d'enregistrer votre terminal en "live" comme Terminalizer et de me faire stresser à chaque faute de frappe, ça me permet de scripter entièrement en amont ma démo.

En fait vous écrivez un fichier ".tape" avec vos instructions, et l'outil génère un rendu (GIF, MP4, WebM) nickel chrome. C'est donc le rêve de tous les perfectionnistes comme moi qui recommencent 15 fois la même capture parce qu'ils ont oublié un sudo ou qu'ils ont bafouillé sur le clavier.

Pour l'installer, comme d'hab :

brew install vhs

Output demo.gif
Set FontSize 20
Set Width 1200
Type "echo 'Salut les amis !'"
Sleep 500ms
Enter
Sleep 2s

vhs demo.tape

Si vous êtes comme moi et que vous vivez dans Apple Notes parce que c'est fluide, synchronisé partout, et que ça marche sans qu'on ait à se poser de questions, cet outil va vous plaire.

Parce que oui, voilà, le jour où vous voulez bidouiller vos notes en ligne de commande, les exporter en Markdown, ou simplement éviter de vous retrouver coincé dans votre prison dorée Apple... Et bien c'est la galère. J'ai longtemps cherché une solution propre. Je me suis même dit à un moment que j'allais coder un script Python foireux pour scrapper la base SQLite locale, mais j'ai vite abandonné l'idée.

Pourquoi ? Parce que j'ai découvert Stash , un petit outil en ligne de commande qui fait le pont entre vos notes Apple et des fichiers Markdown.

Et le truc cool, c'est que ça marche dans les deux sens. Vous pouvez exporter vos notes Apple en Markdown (comme ici : Exporter pour vos backups ), mais aussi éditer vos fichiers Markdown et renvoyer les changements directement dans Apple Notes. C'est une vrai synchro bidirectionnelle qui vous rend vraiment maître de vos données.

J'ai testé ça sur macOS Tahoe avec un dossier de notes en vrac. J'ai lancé le bousin, et ça m'a fait plaisir de voir mes fichiers .md popper proprement dans le terminal, prêts à être commités ensuite sur un GitHub ou édités dans VS Code.

L'installation est toute bête, via Homebrew :

brew tap shakedlokits/stash https://github.com/shakedlokits/stash
brew install shakedlokits/stash/stash

stash pull "Ma Super Note"

stash push "Ma Super Note.md"