Si vous en avez marre de perdre vos recettes de cuisine dans des apps comme Whisk ou Paprika qui ferment tous les 6 mois, ou de devoir scroller 14 pages de storytelling avant d'arriver aux ingrédients... y'a un truc qui devrait vous plaire. Ça s'appelle Cooklang , et c'est un langage de markup pour écrire vos recettes en texte brut et les garder à vie !

En gros, vous créez un fichier .cook avec Notepad, Sublime Text ou votre terminal favori, vous écrivez votre recette en français normal et vous ajoutez quelques marqueurs type : @farine{200%g} pour un ingrédient avec sa quantité, #fouet{} pour un ustensile, ~{25%minutes} pour un minuteur.

Du coup, à partir de ce petit fichier texte, l'outil génère alors automatiquement la liste de courses, les minuteurs et un joli rendu lisible. Y'a pas de compte à créer, ni de serveur Notion à monter... C'est juste vos recette chez vous !

Et le truc vraiment sympa, c'est que la syntaxe reste parfaitement lisible même sans l'outil... en fait votre recette de carbonara reste une recette de carbonara, et pas un fichier XML avec 47 balises imbriquées. D'ailleurs si vous versionnez vos fichiers avec un Git, vous pouvez tracer l'évolution de vos recettes au fil du temps, pour voir par exemple quand vous avez décidé de mettre plus d'ail dans la marinade et pourquoi votre tarte aux pommes de 2024 était meilleure que celle de 2023.

La syntaxe Cooklang : lisible par un humain, exploitable par la machine

Côté écosystème, c'est très complet pour un projet open source et complètement gratuit ! Y'a un CLI écrit en Rust qui fait serveur web intégré ( la démo est ici ), des apps iOS et Android avec synchronisation, des plugins pour VS Code, Vim et Emacs (pour les puristes), un plugin Obsidian pour afficher vos recettes directement dans votre vault, et même un mode Raspberry Pi Zero pour héberger votre précieux livre de recettes familial sur le réseau WiFi local.

Comme ça, un petit cookcli server et tout le monde à la maison peut consulter les recettes depuis son téléphone. Par contre, attention, y'a pas de mode collaboratif en temps réel, c'est chacun son fichier... c'est pas Google Docs non plus.

Le système de mise à l'échelle est pas mal non plus. Quand vous triplez les quantités de votre blanquette pour le repas du dimanche, le sel et le poivre restent fixes (parce que non, on ne triple pas la quantité de pincées de sel quand on passe à 6 personnes). Sauf que ça marche pas pour tout : les temps de cuisson, faut quand même les ajuster vous-mêmes et si une recette dépend d'une autre, genre votre sauce hollandaise maison, vous pouvez la référencer directement dans votre préparation avec @./sauces/Hollandaise{150%g}.

D'ailleurs, y'a une astuce que je trouve carrément cool, c'est que si vous trouvez une recette en ligne qui vous plaît, vous pouvez coller cook.md/ devant l'URL et ça la convertit automatiquement au format Cooklang, prête à être intégrée dans votre collection de recette. Comme ça, pas besoin de tout retaper à la main comme un scribe du Moyen Âge !

Le projet existe depuis janvier 2021 et c'est sous licence MIT. Dans un monde (prenez une grosse voix grave) où chaque app de cuisine veut votre email, vos données et 5 euros par mois, la vraie résistance s'organise avec des fichiers texte de cuisine de 2 Ko qu'on peut ouvrir dans n'importe quel éditeur de texte , synchroniser via Syncthing ou balancer sur une clé USB.

Et si tout ce qui vous intéresse c'est uniquement la bouffe, il y a des recettes ici et des recettes là .

Bref, créez un fichier boeufbourguignon.cook, balancez-y votre recette avec les marqueurs et lancez cookcli server pour voir le résultat... il manque plus qu'un git blame pour savoir qui a mis trop d'oignons !

Merci à Fabien pour la découverte !

Google n'a jamais sorti d'API publique pour NotebookLM , son outil qui transforme vos documents en podcasts, quiz et autres résumés grâce à l'IA. Pas de SDK, pas de CLI, y'a rien du tout alors on est tous triiiiiste. A peine juste une interface web avec ses boutons moches et ses menus déroulants, mais impossible à scripter ou à intégrer dans le moindre pipeline bash.

Mais un dev bien inspiré a reverse-engineeré les endpoints REST internes et a pondu notebooklm-py, une lib Python de 168 Ko qui fait tout ce que le web UI refuse de faire. Franchement, c'était pas trop tôt ! Vous en avez rêvé, lui l'a fait !

Un pip install notebooklm-py et voilà, vous avez accès à toute la machinerie Notebook LM à savoir : créer des notebooks, injecter des sources (URLs, PDF, vidéos YouTube, fichiers Google Drive, documents Word, images PNG), poser des questions à vos docs, et surtout générer du contenu... podcasts audio en MP3, vidéos explicatives en MP4, quiz, flashcards, slides en PPTX, infographies en PNG, mind maps en JSON.

Carrément dingue ! Et tout ça pilotable depuis votre terminal zsh ou en script Python async.

En fait, le vrai bonus c'est que la lib déverrouille des fonctionnalités que l'interface web ne propose même pas comme télécharger tous vos podcasts d'un coup en batch au lieu de cliquer un par un sur chaque fichier MP3, exporter vos 50 flashcards en JSON structuré au lieu de juste les afficher à l'écran ou encore récupérer vos slides en PPTX éditable plutôt que le PDF figé.

Ce genre de features, on avait fini par accepter que Google s'en fiche mais pourtant, extraire l'arbre complet d'une mind map en JSON pour la balancer dans D3.js ou Mermaid... clairement c'est un truc que Google aurait dû proposer depuis le début !

Côté CLI, c'est propre. Vous vous authentifiez une fois via notebooklm login (ça ouvre Chromium via Playwright pour choper les cookies de session Google), puis vous enchaînez les commandes.

notebooklm create "Ma Recherche" pour créer un notebook vide,

notebooklm source add ./mon-rapport.pdf pour balancer vos fichiers,

notebooklm generate audio "rends ça punchy" --wait pour lancer la génération de podcast,

et notebooklm download audio ./podcast.mp3 pour récupérer le MP3 sur votre disque.

On peut même éditer ses slides individuellement avec des prompts en langage naturel, du genre "ajoute un graphique sur cette slide-là" !

Pour ceux qui veulent brancher ça dans leurs pipelines, y'a comme je le disais l'API Python async complète. Vous pouvez donc monter un petit cron qui ingère vos derniers bookmarks le vendredi soir, et génèrer un résumé audio de 5 minutes, puis balancer le MP3 directement sur votre NAS Synology.

D'ailleurs, si vous avez déjà joué avec des outils pour booster votre productivité avec l'IA , c'est un peu dans la même veine... sauf qu'ici on tape directement dans les tripes des serveurs Google, sans intermédiaire. Ça tourne avec du Python, et y'a même un mode "agent" (un skill en fait) pour brancher ça dans Claude Code ou Codex. Pas mal, hein ?

Le fait que ça gère aussi la recherche web et Drive avec import automatique des résultats dans vos notebooks, c'est top, un peu comme Oboe qui génère des cours complets via IA , mais en version terminal. Et surtout, pas d'abonnement mensuel à payer, c'est votre propre compte Google qui fait tourner la machine.

Bien sûr, ça reste du reverse-engineering d'APIs non-documentées de Google, ce qui fait que les endpoints REST peuvent changer du jour au lendemain et tout péter. Le projet le dit clairement, c'est plutôt taillé pour du prototypage, de la recherche ou des projets perso et SURTOUT PAS pour de la prod sur un serveur Nginx en front avec 10 000 utilisateurs prêts à ruer dans les brancards en cas de panne.

Et puis faut quand même s'authentifier via un vrai compte Google avec Playwright et Chromium, donc pas question de faire tourner ça sur un serveur headless sans un minimum de config.

Bref, tant que Google ne coupe pas ses endpoints, c'est open bar.

Profitez-en !

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 :