Récupérer des données de sites web avec des agents

Le problème des SPA en JS

Beaucoup de sites web modernes sont des single-page apps : la première requête HTTP ne renvoie qu'un squelette HTML presque vide, et le contenu réel est chargé ensuite via JavaScript dans le navigateur. Un simple appel curl ou un outil de fetch basique ne voit alors que la coquille vide – pas le texte qu'un humain voit dans son navigateur.

Outils de fetch et rendu

Un outil de fetch comme WebFetch récupère la réponse brute d'un serveur et la convertit en Markdown pour du HTML – ce qui suffit pour les pages classiques rendues côté serveur. Pour les pages riches en JS, il faut à la place un service de rendu ou un vrai navigateur (headless) qui exécute d'abord la page, puis livre le contenu final déjà rendu.

Le côté légal, en bref

Un fichier robots.txt à la racine d'un site définit quelles zones les requêtes automatisées ont le droit de crawler – le respecter est un consensus de base sur le web, même si ça n'est pas techniquement imposé. S'y ajoutent les conditions d'utilisation (CGU) de chaque site, qui restreignent parfois explicitement le scraping.

Respecter les limites de débit

Face à trop de requêtes en peu de temps, les serveurs répondent souvent avec le statut 429 (« Too Many Requests »). Un agent qui ignore ça et continue à envoyer des requêtes peut surcharger un site ou se faire bloquer – des pauses et un rythme de requêtes modéré font partie d'un scraping propre.