Roomi Fields

NotebookLM piloté — quand l’automatisation devient une API

Donner à un agent IA un assistant de recherche qui cite ses sources

Un service sans API n’est pas un service fermé. C’est un service dont l’interface est l’écran.

NotebookLM, en deux phrases

NotebookLM est un assistant de recherche de Google. Sa particularité : vous lui fournissez vos sources — des PDF, des pages web, des vidéos, du texte — et il ne répond qu’à partir de ces sources. Chaque affirmation de sa réponse est accompagnée d’une citation : un renvoi vers le passage précis d’où elle vient.

Cela paraît anodin. C’est en réalité la propriété la plus importante de l’outil, et il faut s’y arrêter.

Pourquoi « citer ses sources » n’est pas un détail

Le défaut le plus connu des modèles de langage, c’est l’hallucination : produire une affirmation fausse, mais formulée avec la même assurance qu’une affirmation vraie. Le modèle ne ment pas — il n’a tout simplement pas de mécanisme interne pour distinguer « ce dont je suis sûr » de « ce qui ressemble à une réponse plausible ».

La parade s’appelle la génération ancrée (grounded generation) : on contraint le modèle à fonder sa réponse sur un corpus fourni, et on lui demande de pointer le passage qui justifie chaque affirmation. C’est exactement ce que fait NotebookLM.

L’effet est double. D’abord, la contrainte réduit l’hallucination à la source : le modèle ne peut pas inventer, puisqu’il doit montrer d’où il tire chaque phrase. Ensuite — et c’est aussi important — la citation rend le contrôle possible. Une réponse non sourcée, il faut la croire ou tout revérifier. Une réponse sourcée, il suffit d’aller lire le passage cité. Pour un travail académique, juridique ou réglementaire, cette différence n’est pas un confort : c’est la condition pour utiliser l’outil du tout.

Le problème : un outil qu’on ne peut pas brancher

NotebookLM est donc précieux. Mais il a, pour qui veut l’intégrer dans un flux de travail, deux défauts rédhibitoires.

Le premier : il n’a pas d’API publique. Une API (Application Programming Interface) est la « prise » par laquelle un programme parle à un autre. Sans elle, NotebookLM ne se pilote qu’à la main, dans un navigateur, un humain devant l’écran. Impossible de l’appeler depuis un script, une chaîne de traitement, ou un agent IA.

Le second : un plafond de 50 questions par jour et par carnet. Pour une exploration ponctuelle, c’est large. Pour traiter un corpus de recherche systématiquement — poser cent questions à un ensemble d’articles scientifiques — c’est un mur.

L’idée : l’automatisation de navigateur est l’API

Voici le renversement central de ce projet. Un service sans API n’est pas un service infranchissable. Son interface existe — c’est simplement l’écran, le navigateur, les clics et la frappe au clavier. Et tout cela, un programme sait le faire.

L’automatisation de navigateur consiste à piloter un vrai navigateur Chrome par programme : ouvrir la page, taper la question dans le bon champ, attendre, lire la réponse affichée, en extraire les citations. Du point de vue de NotebookLM, c’est un utilisateur comme un autre. Du point de vue de votre script, c’est devenu une API — celle qui n’existait pas.

Le serveur notebooklm-mcp fait exactement cela. Il enveloppe l’interface visuelle de NotebookLM dans une couche programmable, et l’expose de deux façons :

  • comme serveur MCP — le standard qui permet à un agent (Claude Code, Cursor, Codex) de découvrir et d’appeler des outils externes, détaillé dans A1 — pour qu’il puisse poser des questions à NotebookLM au cours de son raisonnement ;
  • comme API REST, une trentaine de points d’entrée documentés pour les outils d’automatisation classiques (n8n, Zapier, Make) ou un simple curl.

Le même moteur sert aussi à déclencher les fonctions « Studio » de NotebookLM — générer un résumé audio façon podcast, une vidéo explicative, une infographie, un rapport — depuis un appel programmatique au lieu d’un clic.

Le prix de cette approche : la fragilité

Il faut être honnête sur le coût de la méthode. Piloter un service par son écran, c’est dépendre de la stabilité de cet écran. Le jour où Google redessine son interface, déplace un bouton, renomme un champ, le programme qui cliquait « au bon endroit » clique dans le vide.

L’historique des versions du projet est, à cet égard, très éloquent : c’est une longue suite de corrections de sélecteurs (les repères qui désignent un élément précis de la page), d’adaptations à une mise à jour de l’interface, de rustines défensives. Ce n’est pas un défaut du projet — c’est la nature même de l’automatisation de navigateur. Là où une vraie API change selon un calendrier annoncé, une interface visuelle change sans prévenir.

Deux conséquences pratiques, que le projet assume explicitement : utiliser un compte Google dédié à l’automatisation (Google peut détecter et signaler un usage automatisé), et toujours relire ce que l’agent produit. L’outil intègre des « humanisations » — vitesse de frappe réaliste, délais naturels — mais aucune ne garantit l’invisibilité. C’est un contournement assumé, pas un canal officiel.

Passer à l’échelle : mille questions dans la nuit

Une fois l’interface devenue programmable, le plafond de 50 questions par jour se traite comme un problème d’ingénierie, pas comme une fatalité.

Le projet le résout par la rotation multi-comptes : plusieurs comptes Google se relaient automatiquement, et quand une session expire, le système se ré-authentifie tout seul. De quoi enchaîner des lots de plus de mille questions au fil de la nuit, sans surveillance — un cas réellement testé.

C’est ici que le sujet rejoint le précédent.

Le motif de pipeline : NotebookLM en entrée, RTFM en cache

NotebookLM et RTFM (A1) ne se concurrencent pas — ils s’enchaînent.

NotebookLM est excellent comme source de réponses ancrées, mais c’est un service distant, plafonné, lent, en ligne. RTFM est excellent comme couche de récupération locale, instantanée, illimitée — mais il ne produit rien, il indexe.

Le motif consiste donc à faire de NotebookLM une étape d’ingestion unique. On lui pose, une fois, toutes les questions utiles sur un corpus ; il répond avec ses citations ; ses réponses sont écrites sur disque sous forme de fichiers Markdown accompagnés d’un volet de données structuré. RTFM indexe ces fichiers. À partir de là, on interroge le cache local : demander une fois, retrouver pour toujours — hors ligne, en quelques millisecondes, sans plafond.

Le plafond de 50 questions par jour ne disparaît pas. On le franchit une seule fois, à l’ingestion, et plus jamais ensuite.

Ce qu’il faut retenir

  1. NotebookLM répond en citant ses sources. C’est rare, et c’est ce qui le rend utilisable pour un travail sérieux.
  2. Citer ses sources combat l’hallucination de deux façons : la contrainte empêche d’inventer, et la citation rend le contrôle possible.
  3. Pas d’API publique, 50 questions par jour. Deux murs qui empêchent toute intégration sérieuse.
  4. Quand un service n’a pas d’API, son interface visuelle peut en tenir lieu. L’automatisation de navigateur transforme l’écran en prise programmable.
  5. Le prix de cette approche est la fragilité. Une interface change sans prévenir ; il faut un compte dédié et une relecture systématique.
  6. NotebookLM en entrée, RTFM en cache. Poser les questions une fois, indexer les réponses, interroger ensuite le cache local sans plafond.

Glossaire

  • NotebookLM : assistant de recherche de Google qui répond uniquement à partir des sources qu’on lui fournit, en citant ses passages.
  • Hallucination : affirmation fausse produite par un modèle de langage avec la même assurance qu’une affirmation vraie.
  • Génération ancrée (grounded generation) : technique forçant le modèle à fonder sa réponse sur un corpus fourni et à citer le passage justifiant chaque affirmation.
  • API (Application Programming Interface) : interface standardisée par laquelle un programme en pilote un autre.
  • Automatisation de navigateur : pilotage par programme d’un vrai navigateur (ouvrir une page, taper, cliquer, lire) — utilisé ici pour suppléer une API absente.
  • Sélecteur : repère technique qui désigne un élément précis d’une page web ; se casse quand la page est redessinée.
  • API REST : style d’API très répandu, interrogeable par de simples requêtes web — compatible avec les outils d’automatisation grand public.

Pour aller plus loin

Dans cette série

  1. A1 — RTFM : rendre la mémoire à votre agent IA
  2. NotebookLM piloté — quand l’automatisation devient une API ← vous êtes ici
  3. A3 — osc-bridge : un pont déclaratif vers 849 synthétiseurs

Prérequis : A1 conseillé (notion de MCP)
Temps de lecture : 11 min
Tags : #MCP #NotebookLM #RAG #automatisation-navigateur #hallucination

roomi-fields — vulgarisation à l’intersection des outils, des formalismes et de l’intelligence augmentée.

← Retour à l’index