Contexte technique
Je me suis intéressé à ce cas non pas pour la synthèse vocale elle-même, mais pour son architecture : lorsqu'un TTS local atteint une limite de VRAM, l'agent délègue simplement le texte à NotebookLM via la CLI et récupère l'audio. Pour l'automatisation par IA, c'est une approche très pragmatique. Ce n'est pas élégant d'un point de vue académique, mais ça fonctionne.
En réalité, NotebookLM ne devient pas ici une véritable API TTS. J'ai examiné les descriptions disponibles de la CLI et de son wrapper MCP : la logique semble être que le service peut créer des artefacts audio dans son propre flux de travail, plutôt que d'être un moteur de synthèse vocale universel avec un contrôle précis sur la voix, les pauses et les émotions.
C'est là que la différence se fait vraiment sentir. Qwen3-TTS et les modèles locaux similaires sont excellents tant que la tâche est compatible avec le matériel. Mais dès que l'on souhaite une voix plus agréable, plus d'expressivité et une qualité non téléphonique, les chiffres de VRAM deviennent rapidement décourageants. La discussion a mentionné un seuil de 16 Go et plus, ce qui semble très réaliste.
NotebookLM propose un compromis différent : il ne consomme presque aucune ressource locale car le travail intensif est délocalisé dans le cloud de Google. Mais on paie pour cela par la latence, un faible contrôle du format et le fait que ce n'est pas un outil pour des répliques rapides dans un dialogue en direct. Je ne qualifierais pas cela de TTS, mais de génération de contenu audio basée sur le cloud qu'un agent peut déclencher comme une étape externe.
Un autre point sur la qualité. D'après les avis et les démos, l'anglais sonne tout à fait correct pour son poids, mais pour l'ukrainien, l'accentuation est inégale. Cela signifie que pour une intégration d'intelligence artificielle multilingue dans des produits clients, je prévoirais immédiatement des vérifications spécifiques à chaque langue plutôt que de me fier à l'effet « waouh » initial.
Impact sur l'entreprise et l'automatisation
Les gagnants ici sont ceux qui développent des agents vocaux sans GPU puissants. On peut garder le « cerveau » de l'agent en local et externaliser la synthèse vocale vers une solution de repli dans le cloud. C'est moins cher que de surdimensionner le matériel pour une seule fonction.
Les perdants sont les scénarios où une faible latence et un contrôle total de l'intonation sont critiques. Pour un assistant en temps réel, c'est un pis-aller. Pour des résumés audio, des explications, des assistants internes et des réponses asynchrones, c'est tout à fait adapté.
Je concevrais cela comme un pipeline à plusieurs étapes : un TTS local si les ressources le permettent ; la CLI NotebookLM comme voie de secours ; et une réponse textuelle comme dernier recours. Chez Nahornyi AI Lab, nous construisons exactement ce type de parcours à embranchements pour les clients qui ont besoin de développement de solutions IA sans coûts d'infrastructure excessifs. Si votre agent sait déjà penser mais échoue à parler, examinons l'ensemble du flux et construisons une automatisation IA qui sonne bien sans nécessiter une nouvelle carte graphique pour chaque cas d'utilisation.