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

Ansible, c'est bien. Mais du YAML à perte de vue pour configurer trois serveurs c'est pas non plus l'idéal. Hé bien ça tombe bien car y'a maintenant pyinfra , qui fait tout pareil sauf qu'on écrit du Python. En gros, votre script de déploiement c'est juste du code Python normal avec des imports, des boucles, des conditions... tout ça, tout ça...

Ce projet existe depuis 2014, il est sous licence MIT et côté perfs, c'est de ce que j'ai lu, jusqu'à 10 fois plus rapide qu'Ansible sur des déploiements massifs (genre plusieurs milliers de machines). Bon, sur le papier c'est bien, mais en fait ça dépend surtout de votre infra SSH et de la latence réseau.

Alors ça marche comment ?

Hé bien vous installez le bazar avec uv tool install pyinfra et hop, vous pouvez déjà lancer des commandes sur vos serveurs comme ceci :

pyinfra mon-serveur.net exec -- echo "hello world"

Ça fonctionne en SSH sur le port 22, sur des conteneurs Docker, ou même en local. Le truc est complètement agentless, du coup pas besoin d'installer quoi que ce soit sur les machines cibles. Suffit d'un accès shell POSIX tout ce qu'il y a de plus classique et c'est réglé.

Bon, ça c'est pour l'ad-hoc mais en fait le vrai kiff, ce sont les opérations déclaratives. Je vous montre... Vous créez un fichier deploy.py et dedans, vous mettez ça :

from pyinfra.operations import apt, systemd

apt.packages(
 name="Install nginx",
 packages=["nginx"],
)

systemd.service(
 name="Ensure nginx is running",
 service="nginx.service",
 running=True,
 enabled=True,
)

targets = ["@docker/ubuntu", "mon-serveur.net", "autre-serveur.net"]

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