NotebookLM : Google a pondu un outil génial, un développeur solo lui a donné des ailes — l'API qui humilie Mountain View

Google a créé NotebookLM en 2023. Un assistant de recherche dopé à Gemini qui lit vos documents, vous fait des podcasts, des slides, des quiz, des infographies. Résultat : carton viral. Problème : aucune API publique. Pendant trois ans. Jusqu'à ce qu'un développeur nommé Teng Lin en ait assez. Il a reverse-engineeré le bousin, construit une bibliothèque Python qui expose plus de fonctionnalités que l'interface web officielle, et récolté 17 800 étoiles GitHub en quelques mois. Ce n'est pas une success story ordinaire. C'est un camouflet.

Le bijou que Google a mis sous cloche

Rembobinons. NotebookLM naît en mai 2023 sous le nom de code « Project Tailwind ». L'idée est simple : vous balancez vos documents — PDF, URLs, vidéos YouTube, Google Docs — et Gemini les digère. Il vous répond avec des citations précises, chapitre, paragraphe. Pas de bullshit probabiliste : chaque réponse est ancrée dans une source.

En septembre 2024, Google lâche la fonctionnalité qui va tout changer : les Audio Overviews. Deux voix synthétiques discutent de vos documents comme un podcast NPR. C'est bluffant, c'est viral, c'est repris par Spotify pour le Wrapped 2024. En octobre, NotebookLM perd son étiquette « expérimental ». En décembre, une version payante NotebookLM Plus débarque pour les entreprises. En février 2025, les particuliers y ont droit via Google One AI Premium.

Le produit s'étoffe à vitesse grand V : Video Overviews, slides decks, infographies, quiz, flashcards, data tables, mind maps. Plus de 80 langues. Une version cinématique des vidéos. Le tout propulsé par Gemini 3.5.

Bref, NotebookLM est probablement l'outil IA le plus sous-coté de Google. Pas un concurrent de ChatGPT — un complément. Là où ChatGPT invente, NotebookLM cite. Là où Claude raisonne dans le vide, NotebookLM travaille sur vos sources.

Et pourtant.

Pas. D'API. Publique.

Pas de pip install google-notebooklm. Pas de clé API à coller dans un script. Pas de webhook pour déclencher un podcast quand un nouveau document arrive. Rien. Le néant. L'interface web, point final.

Alors oui, Google a fini par documenter une API NotebookLM Enterprise dans Google Cloud. Bravo. Elle est réservée aux entreprises, verrouillée derrière l'écosystème Google Cloud, et le standalone Podcast API est déprécié — même pas ouvert aux nouveaux clients. Traduction : si vous n'êtes pas une boîte du Fortune 500 avec un compte Google Cloud Enterprise, débrouillez-vous.

Trois ans. Pour un produit viral. Aucune API publique.

C'est là que Teng Lin entre en scène.

Un type, un navigateur headless, et 17 800 étoiles

Teng Lin. Un développeur. Pas de bureau chez Google. Pas de badge Mountain View. Pas de compte Google Cloud Enterprise. Juste un repo GitHub, un clavier, et une bonne dose d'agacement.

Son projet : notebooklm-py. Une bibliothèque Python non officielle qui donne un accès programmatique complet à NotebookLM. Le tout via les APIs internes — non documentées — que l'interface web utilise pour communiquer avec les serveurs Google.

Comment ? En interceptant les requêtes HTTP que le client web NotebookLM envoie aux serveurs de Google. Du reverse-engineering pur et dur. Le genre de travail que Google aurait pu éviter à tout le monde en publiant une API y a deux ans.

Le résultat est sidérant. En quelques mois : 17 800 étoiles GitHub, 2 400 forks, 1 823 commits, 41 branches. Le projet est vivant, maintenu quotidiennement, avec des commits signés par Teng Lin et... Claude. Oui, le développeur utilise Claude Code pour co-développer sa propre bibliothèque. La boucle est bouclée.

Trois modes d'utilisation :

1. API Python : asynchrone, complète, pour l'intégration dans des applis et des pipelines. 2. CLI : ligne de commande, pour les scripts shell et le CI/CD. 3. Intégration agent : Claude Code, OpenAI Codex, OpenClaw — vos agents IA pilotent NotebookLM directement.

Et aussi un serveur MCP (Model Context Protocol) en local ou accessible à distance via Cloudflare Tunnel, et un serveur REST pour l'automatisation sans CLI. Le package est complet.

Ce que l'API fait que l'interface web ne fait pas

Là où ça devient gênant pour Google, c'est la liste des fonctionnalités au-delà de l'interface web :

- Téléchargement par lot : tous les artefacts d'un type en une commande. L'UI web les donne un par un. - Quiz et flashcards exportables : JSON, Markdown, HTML. L'UI web les affiche en interactif, pas de données exploitables. - Mind map en JSON : extraction hiérarchique pour vos outils de visualisation. L'UI web : une image statique. - Data table en CSV : téléchargeable, structuré. - Slides en PPTX : PowerPoint éditable. L'UI web ne propose que du PDF. - Révision de slides : modifiez une slide individuelle par langage naturel. - Templates de rapport personnalisés : ajoutez des instructions aux formats intégrés. - Fulltext des sources : récupérez le texte indexé de n'importe quelle source. - Partage programmatique : gérez les permissions sans l'UI. - Multi-comptes : basculez entre profils Google sans réauthentification. - Import de cookies navigateur : réutilisez votre session existante plutôt que de lancer Playwright.

Le constat est limpide : l'API communautaire est plus riche que l'interface officielle. Un développeur solo a construit une meilleure porte d'entrée vers un produit Google que Google lui-même.

Retenez ce chiffre : 17 800 étoiles. C'est plus que beaucoup de projets open source officiels de Google.

L'agent IA rencontre le cerveau documentaire

L'aspect le plus fascinant de notebooklm-py n'est pas son exhaustivité technique. C'est l'intégration agent.

Imaginez : vous avez une base documentaire interne — RFCs, specs, architecture, FAQs, tickets résolus. Vous la balancez dans un notebook NotebookLM. Vous installez notebooklm-py comme skill Claude Code. Votre agent peut maintenant interroger cette base en temps réel, avec citations.

Ce n'est plus du RAG bricolé avec un vector store approximatif. C'est du RAG propulsé par Gemini, avec des citations précises, hébergé sur l'infrastructure Google. Zéro infra à maintenir. Zéro embedding pipeline à débugguer. Zéro hallucination non sourcée.

Les cas d'usage qui émergent de la communauté sont créatifs :

- Mémoire persistante inter-sessions : un « Master Brain » notebook où chaque session agent ajoute ses décisions et correctifs. La session suivante interroge ce cerveau avant de commencer. - Distillation de connaissance en skill : vous lancez une Deep Research sur un sujet, NotebookLM condense, et vous transformez le résultat en SKILL.md que votre agent charge au démarrage. Build once, reuse forever. - Skills auto-validés : NotebookLM génère un quiz à partir de vos sources, et ce quiz évalue votre skill agent. Première passe : 4/10. Une itération plus tard : 10/10. Validé par la machine, pas par votre biais. - Oracle de dépannage : un agent qui, face à une erreur, interroge immédiatement un notebook contenant toute la documentation d'un outil. Plus besoin de tenir 500 pages en contexte. - Briefings audio programmés : un cron job qui génère votre podcast quotidien à partir de vos sources fraîches.

Et le plus beau : zéro token dépensé côté agent pour la recherche lourde. C'est NotebookLM/Gemini qui bosse côté serveur. L'agent orchestre, reçoit le condensé, et peaufine. Le ratio tokens / valeur produite explose.

Le prix de la débrouille

Ne nous emballons pas. notebooklm-py reste un projet non officiel. Il utilise des APIs Google non documentées. Google peut les modifier sans préavis. Demain matin, une mise à jour de NotebookLM côté serveur peut casser la moitié des endpoints.

C'est écrit noir sur blanc dans le README : « This library uses undocumented Google APIs that can change without notice. » Le mainteneur a un processus de correction rapide, mais les utilisateurs doivent accepter l'incertitude.

Le setup n'est pas non plus un long fleuve tranquille. Il faut Playwright, Chromium (~170 Mo), et une authentification Google via navigateur. Pas de OAuth propre. Pas de service account. Du browser automation pour maintenir les cookies.

Et puis il y a les rate limits. Utilisation intensive = throttling. Le projet n'a aucun accord avec Google, aucune garantie de service, aucun SLA. C'est du bricolage de génie, mais du bricolage quand même.

Pour du prototypage, de la recherche, des projets personnels : parfait. Pour de la production critique : réfléchissez à deux fois.

Et Google dans tout ça ?

Google n'est pas resté totalement inerte. Une API NotebookLM Enterprise existe dans Google Cloud. Mais elle est pensée pour les grands comptes, pas pour les développeurs. Et le standalone Podcast API est documenté mais déprécié, fermé aux nouveaux clients.

Autrement dit, Google a trois ans de retard sur la demande du marché. Pendant ce temps, des alternatives comme AutoContent API comblent le vide avec des REST APIs publiques, des webhooks, et du pricing à la requête.

La leçon est cruelle pour Mountain View : quand vous ne donnez pas d'API à vos utilisateurs, ils la construisent eux-mêmes. Et souvent, ils la construisent mieux.