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 !

Le ministère des Transports britannique vient de publier un appel d'offres pour trouver un développeur C++ capable de maintenir le NAPAM, le modèle qui prédit la répartition des passagers dans les aéroports du pays. Le programme tourne sur 10 000 lignes de code avec Excel comme interface. Budget prévu : 100 000 livres sur trois ans.

10 000 lignes de C++ et un fichier Excel

Le NAPAM (pour National Aviation Passenger Allocation Model), est le logiciel qui permet au gouvernement britannique de prévoir comment les passagers se répartissent entre les aéroports du pays. Il couvre 29 aéroports britanniques qui gèrent des vols internationaux, plus quatre hubs à l'étranger : Amsterdam, Dubaï, Francfort et Paris.

Le programme tourne dans un environnement .NET en C++ et se nourrit de données via des fichiers Excel. Il effectue des calculs itératifs jusqu'à atteindre certains seuils définis par l'utilisateur, comme la capacité maximale de passagers d'un aéroport donné. Le tout tient en 10 000 lignes de code. Pour un outil qui influence les décisions de politique aérienne du Royaume-Uni, on est sur quelque chose d'assez artisanal.

Un appel d'offres à budget serré

Cet appel d'offres a été lancé pour un contrat de trois ans, avec un budget de 100 000 livres, soit l'équivalent de 120 000 euros. Le poste consiste à fournir un support technique ad hoc aux analystes et économistes de l'équipe Aviation Appraisal and Modelling.

Le modèle existe depuis au moins 2010 et a été mis à jour en 2017, 2022 et 2024. Le précédent contrat de maintenance avait été attribué au cabinet américain Jacobs, qui avait facturé environ 97 000 livres rien que pour les mises à jour de 2020. Le ministère précise quand même que le budget est « non engageant » et qu'il ne garantit ni le volume de travail ni les dépenses.

Un cas d'école du logiciel legacy

Ce genre de situation est un classique dans les administrations : un outil développé il y a quinze ans par un prestataire, maintenu au fil de l'eau par un consultant externe, et dont personne en interne ne maîtrise vraiment le code.

Le NAPAM est quand même utilisé pour orienter les investissements aéroportuaires et les projections de trafic du pays. Si le développeur sous contrat décide de partir à la retraite ou de changer de métier, c'est tout le modèle de prévision qui se retrouve en difficulté.

Et avec 10 000 lignes de C++ legacy plus des macros Excel, on imagine la joie du prochain développeur qui reprendra le dossier.

C'est quand même un peu vertigineux de se dire que les prévisions du trafic aérien d'un pays du G7 dépendent d'un programme en C++ maintenu par un seul prestataire pour 33 000 livres par an.

Avec ce budget, on est à peine sur le tarif d'un développeur junior à mi-temps à Londres. On ne dit pas que le modèle est mauvais, mais la dépendance à une seule personne sur du code legacy avec Excel comme interface, ça fait quand même un peu froid dans le dos.

Source : The Register

Un développeur a créé un langage de programmation dont le code source est composé de M&M's colorés. Six couleurs, six familles d'instructions, et les programmes se compilent sous forme d'images PNG. Le plus rigolo ? On peut même prendre en photo de vrais bonbons posés sur une table pour générer du code exécutable. Le projet, baptisé MnM Lang, cartonne.

Des bonbons à la place du code

L'idée est partie d'un paquet de GEMS (l'équivalent indien des M&M's) ouvert un peu trop fort. Mufeed VH, développeur et auteur du projet, a vu les confiseries former une sorte de flèche sur le sol et s'est dit que ça ferait un bon point de départ pour un langage de programmation. Le résultat s'appelle MnM Lang, un langage dit "ésotérique" où le code source est écrit sous forme de rangées de bonbons.

Six couleurs sont utilisées, chacune correspondant à un type d'instruction : le bleu gère le flux de contrôle (sauts, appels, arrêt), le vert s'occupe des variables et de la pile, le jaune traite les opérations mathématiques, l'orange gère les entrées/sorties, le marron s'occupe des labels et des chaînes de caractères, et le rouge de la logique booléenne et de la manipulation de pile. Le nombre de bonbons dans une rangée détermine l'opcode : six bonbons à la suite, par exemple, ça donne la valeur 5.

Du vrai code dans une image PNG

Dans un premier temps, les programmes sont écrits en ASCII, puis compilés en PNG. Dans l'image, chaque lettre est remplacée par un Sprite de bonbon. Et le truc assez fou, c'est que ça marche aussi dans l'autre sens : on peut prendre une photo de vrais bonbons posés sur un fond blanc, et le décodeur d'image reconstitue le code source à partir des couleurs détectées.

Côté limitations, les images ne sont pas très douées pour stocker du texte. Les chaînes de caractères et les variables initiales passent donc par un fichier JSON séparé qui accompagne le programme.

Malgré cette contrainte, MnM Lang permet d'écrire de vrais programmes : Hello World, FizzBuzz, factorielle. Un terrain de jeu interactif est disponible sur le site du projet, avec un éditeur en ligne, un rendu visuel des bonbons et même un affichage de l'arbre syntaxique.

On a donc là un projet rigolo et coloré, et ça change un peu ! MnM Lang ne va pas remplacer Python ou Swift. Ce genre de truc nous rappelle que la programmation, ce n'est pas qu'un outil de travail et de production, mais ça peut aussi être du fun et de l'amusement, même si le niveau d'ingénierie derrière (compilateur, décodeur d'images, terrain de jeu web) montre que le projet est loin d'être une simple blague. Bref, si vous avez un paquet de M&M's qui traîne et un dimanche après-midi devant vous, vous savez quoi faire.

Source : Hackaday

MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

En ce magnifique mardi matin, moi et mon mal de crâne, nous avons découvert un truc assez cool qui est un genre de wiki personnel en markdown, comme Obsidian ou Notion, mais avec un super pouvoir qui est que vous pouvez y écrire du code qui s’exécute directement dans vos notes !! Hé oui, du vrai code ! Pas des plugins, pas des extensions, mais du code Lua intégré dans votre texte comme si vos notes étaient devenues un environnement de dev à part entière.

Ça s’appelle SilverBullet , c’est open source (licence MIT), et franchement, si vous avez déjà bidouillé des configs Neovim ou des scripts Redis, vous allez kiffer car c’est beaucoup plus simple ^^.

Ça ressemble à n’importe quel wiki markdown moderne. Vous écrivez vos notes en local, elles sont stockées en fichiers statiques .md, vous avez des liens bidirectionnels pour connecter vos idées, et l’interface est optimisée avec des raccourcis clavier. C’est évidemment une Progressive Web App qui fonctionne 100% hors ligne ( comme expliqué sur leur site ), et vous gardez le contrôle total sur vos données, puisque tout est auto-hébergé sur votre machine ou votre serveur.

Ainsi, avec le scripting Lua intégré, vous pouvez littéralement taper ${10 + 2} dans une note et le résultat s’affichera en temps réel : 12 (vous l’aviez les matheux ?? ^^). Et si vous voulez une liste de vos 5 dernières pages modifiées qui se met à jour automatiquement, suffit d’écrire un petit bout de Lua, et hop, votre wiki devient “vivant”.

Alors oui, je sais ce que vous allez me dire, Obsidian a Dataview, Logseq a ses requêtes en Datalog…etc donc c’est pareil non ?

Et bien pas vraiment parce que Dataview ça vous demande quand même d’apprendre un DSL (Domain Specific Language) avec une syntaxe bizarroïde et de vous palucher les 50 pages de doc. Logseq quand à lui vous balance du Datalog sans trop d’explications. Alors que SilverBullet, lui, vous laisse écrire du Lua. Et le Lua, c’est simple, c’est dispo partout (Neovim, Redis, les addons World of Warcraft, OSB, etc.), c’est documenté, et c’est fait pour être embarqué dans des applications.

Si vous êtes data scientist, vous connaissez sûrement les Jupyter Notebooks qui sont markdown avec du code Python exécutable dedans. Hé bien SilverBullet fait exactement la même chose, mais pour vos notes personnelles. Vos notes ne sont plus des fichiers inertes, mais deviennent des mini-programmes qui peuvent calculer, générer du contenu, réagir à des événements…etc

Tenez par exemple, vous pouvez définir une fonction custom directement dans une page :

-- Additionner deux nombres
function adder(a, b)
 return a + b
end

command.define {
 name = "Insérer signature",
 run = function()
 local date = os.date("%Y-%m-%d")
 editor.insertAtCursor("---\nÉcrit le " .. date, false, true)
 end
}

slashCommand.define {
 name = "todo",
 run = function()
 editor.insertAtCursor("- [ ] |^|", false, true)
 end
}

event.listen {
 name = "page:save",
 run = function(e)
 local content = editor.getText()
 local word_count = select(2, content:gsub("%S+", ""))
 editor.flashNotification("Nombre de mots : " .. word_count)
 end
}

chmod +x silverbullet
mkdir mes-notes
./silverbullet mes-notes

.\silverbullet.exe mes-notes

docker run -p 3000:3000 -v ~/mes-notes:/space ghcr.io/silverbulletmd/silverbullet

Si vous utilisez Claude Code, le nouvel assistant de programmation d’Anthropic qui vit directement dans votre terminal, vous allez kiffer ce que je vais vous montrer aujourd’hui. Y’a un développeur nommé Anton Knoery (NomenAK sur GitHub) qui vient de sortir SuperClaude, un framework de configuration qui transforme Claude Code en véritable machine de guerre pour les développeurs.

Attention, ce n’est pas encore un outil avec 150 dépendances Node.js à la con qui va foutre le bordel dans votre système. Non non, SuperClaude c’est de la pure configuration, zéro code, zéro dépendance externe. Le truc s’installe tranquillement dans votre dossier ~/.claude/ et améliore discrètement les capacités de Claude Code dans tous vos projets.

65 milliards de dollars, c’est le marché estimé du low-code en 2025. Incroyable !! Qui aurait pu se douter que ça reviendrait en force alors que dans les années 90, nos oncles et grand mères créaient des apps maison avec HyperCard en moins de 15 minutes ?

Et aujourd’hui, créer la même chose demande 3 frameworks, 2 bases de données et un diplôme d’ingénieur. Heureusement, 2 développeurs ont décidé de ramener la magie de l’époque avec Scrappy.