youtube-transcript-api bloqué par YouTube ? 4 correctifs qui fonctionnent

L'erreur : ça marche en local, c'est bloqué en production

La bibliothèque Python youtube-transcript-api est le moyen le plus répandu de récupérer des transcriptions YouTube par programmation. Sur votre machine, elle fonctionne en général sans accroc. Mais dès que le code tourne sur un serveur cloud, les requêtes échouent avec des exceptions du type IpBlocked, RequestBlocked ou TooManyRequests — souvent accompagnées d'un message indiquant que YouTube bloque votre IP.

Le même sort attend toutes les approches fondées sur le scraping : les paquets de transcription Node.js, l'extraction de sous-titres avec yt-dlp et les scrapers maison se heurtent exactement au même mur. Le déclencheur n'est pas votre code, c'est l'endroit d'où partent vos requêtes.

Si votre charge de travail tourne sur AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io ou un VPS quelconque, YouTube voit une adresse IP de datacenter. Ces plages d'IP sont publiques, massivement abusées par les bots, et bloquées en bloc. Les connexions résidentielles (votre Wi-Fi domestique, par exemple) sont rarement bloquées — ce qui fait que le fameux « chez moi ça marche » est ici littéralement vrai.

Pourquoi YouTube bloque ces requêtes

Les transcriptions YouTube sont servies par un endpoint interne, non authentifié, qui n'a jamais été conçu pour un usage tiers. Il n'existe aucune API publique officielle pour récupérer la transcription d'une vidéo quelconque : l'endpoint captions de l'API Data officielle exige une autorisation OAuth du propriétaire de la vidéo, il ne fonctionne donc que pour vos propres vidéos.

Comme cet endpoint interne est gratuit et non authentifié, il est matraqué par les entreprises d'IA, les outils SEO et les scrapers. YouTube réagit de la seule façon possible : limitation de débit agressive, blocage en masse des plages d'IP de datacenter, et modifications ponctuelles de l'endpoint qui cassent les bibliothèques de scraping du jour au lendemain.

Autrement dit, toute solution auto-hébergée est engagée dans une partie de chat et de souris permanente. Les quatre correctifs ci-dessous vont du plus artisanal au plus géré.

Correctif 1 : passer par des proxys résidentiels

Le correctif maison classique consiste à faire transiter vos requêtes par des proxys résidentiels rotatifs, pour que YouTube voie des IP de particuliers plutôt que votre serveur. Les versions récentes de youtube-transcript-api le prennent en charge nativement : passez une configuration de proxy à la construction du client (la bibliothèque fournit l'aide WebshareProxyConfig, ou utilisez GenericProxyConfig avec n'importe quel proxy HTTP/SOCKS).

Cela fonctionne, mais l'addition est réelle. La bande passante des proxys résidentiels coûte cher (quelques dollars par Go, en général), la qualité varie énormément d'un fournisseur à l'autre, et vous héritez d'un nouveau mode de défaillance : quand une IP de proxy se fait bloquer en pleine requête, il vous faut une logique de réessai, des health checks et un basculement entre fournisseurs. À faible volume, c'est aussi l'option la plus lente, chaque requête faisant un détour par le réseau de proxys.

Choisissez cette voie si vous voulez le contrôle total, que vous avez du temps d'ingénierie à y consacrer et que votre volume justifie la mise en place.

Correctif 2 : exécuter le récupérateur sur une connexion résidentielle

Une variante plus simple : faites tourner la partie « récupération des transcriptions » de votre pipeline sur une machine dotée d'une IP résidentielle — un Raspberry Pi à la maison, un poste au bureau, un mini-PC bon marché — et faites-lui pousser les résultats vers votre infrastructure cloud via une file d'attente ou un webhook.

Vous évitez ainsi tout coût de proxy, et cela fonctionne étonnamment bien pour de petits usages personnels (transcrire des vidéos pour vos notes ou une newsletter confidentielle). Les inconvénients sautent aux yeux : c'est un point de défaillance unique et physique, cela ne passe pas à l'échelle, et c'est une architecture bancale pour un produit en production.

Correctif 3 : mettre en cache et temporiser en cas d'erreur

Quelle que soit la méthode de récupération, deux pratiques réduisent nettement le taux de blocage. D'abord, mettez en cache chaque transcription récupérée : une transcription ne change pratiquement jamais, il n'y a donc aucune raison de récupérer deux fois la même vidéo. Une simple table indexée par identifiant de vidéo élimine l'essentiel du trafic répété.

Ensuite, traitez un blocage comme un signal, pas comme une erreur à réessayer immédiatement. Un backoff exponentiel avec jitter (attendre 1 s, puis 2 s, 4 s, 8 s…) vous garde sous les radars. Marteler l'endpoint après un blocage est le plus court chemin pour faire bannir toute votre plage d'IP.

Attention : il s'agit d'une mitigation, pas d'un correctif — sur une IP de datacenter, même votre toute première requête peut être bloquée. Combinez-la avec l'un des trois autres correctifs.

Correctif 4 : utiliser une API de transcription hébergée

L'option gérée : laissez un service qui a déjà résolu le problème d'IP récupérer les transcriptions à votre place. ParseJet expose un seul endpoint — POST /v1/parse/youtube avec l'URL d'une vidéo — et renvoie la transcription complète en JSON, avec le titre, la chaîne et la durée. Blocages, gestion des proxys et changements d'endpoint sont absorbés côté serveur : votre code fait trois lignes, et reste à trois lignes.

Migrer depuis youtube-transcript-api prend quelques minutes : remplacez l'appel à la bibliothèque par un POST HTTP (depuis Python, Node.js ou tout ce qui parle HTTP — y compris les fonctions serverless, précisément là où l'approche par bibliothèque se fait bloquer). Le paramètre language permet de demander une piste de sous-titres précise.

L'offre gratuite inclut 300 crédits par mois (une transcription YouTube coûte 5 crédits, soit 60 vidéos) et les forfaits payants démarrent à 19 $/mois. Pour la plupart des produits, cela revient moins cher que la bande passante des proxys résidentiels plus le temps d'ingénierie passé à les surveiller.

Quel correctif choisir ?

Projet personnel, faible volume, un peu d'aisance technique : le correctif 2 (machine résidentielle) est gratuit et suffisamment fiable.

Gros volume avec une équipe infra dédiée : le correctif 1 (proxys résidentiels rotatifs) offre le plus de contrôle — prévoyez le budget des proxys et la maintenance continue.

Application en production, agent ou pipeline RAG où les transcriptions sont une fonctionnalité et non votre cœur de métier : le correctif 4 (API hébergée) — un appel HTTP, et fin de la partie de chat et de souris. Dans tous les cas, ajoutez le correctif 3 (cache et backoff) par-dessus.