requests de Python renvoie souvent une page presque vide : il récupère le HTML brut, mais n’exécute jamais le JavaScript qui le remplirait avec les données recherchées.
Trois approches permettent de résoudre ce problème ; la bonne dépend de la conception du site. La moins coûteuse est préférable lorsqu’elle s’applique : testez-les donc dans l’ordre.
Approche 1 : afficher la page dans un véritable navigateur
La solution universelle consiste à exécuter un véritable moteur de navigateur qui interprète JavaScript exactement comme le navigateur d’un utilisateur. La page se charge, les scripts s’exécutent, les appels d’API se déclenchent et le contenu s’affiche ; ce n’est qu’ensuite que l’outil extrait les données du DOM complet. Cette méthode fonctionne avec tous les sites affichés par JavaScript, mais elle est plus coûteuse : chaque page nécessite une instance de navigateur qui consomme réellement de la mémoire et du processeur. Le choix du moteur est une décision à part entière : bibliothèques différentes (Puppeteer, Playwright, Selenium), API cloud différentes et compromis distincts entre modes avec et sans interface graphique. Retrouvez toutes les possibilités dans Panorama des environnements d’exécution de navigateur, et le choix essentiel entre les deux modes dans Navigateurs avec ou sans interface graphique. À grande échelle, la surcharge de l’environnement compte : un moteur spécialisé coûte nettement moins cher par page qu’un navigateur standard.Approche 2 : intercepter l’API sous-jacente
Les pages affichées par JavaScript ne créent pas leur contenu à partir de rien : elles le récupèrent auprès d’API backend via des requêtes XHR oufetch. Si vous identifiez ces endpoints, vous pouvez les appeler directement et obtenir un JSON propre et structuré sans afficher le moindre navigateur. Cette méthode est plus rapide, légère et fiable : nul besoin d’attendre le DOM, aucun sélecteur ne casse lors d’une modification de mise en page et les données arrivent déjà analysées.
Ces API peuvent toutefois être non documentées, exiger une authentification, limiter le débit ou changer sans préavis. La procédure consiste donc à ouvrir la page dans un véritable navigateur avec l’onglet Network des DevTools, à observer les requêtes pendant le chargement du contenu, puis à chercher les appels XHR / fetch dont la réponse contient les données voulues. Une fois trouvés, vous pouvez souvent les reproduire entièrement hors du navigateur, parfois avec une seule commande curl.
Octoparse intègre cette fonction directement à son éditeur visuel. Son Navigateur intégré présente le même onglet réseau que les DevTools, mais vous permet de sélectionner une réponse d’API sous-jacente comme un élément du DOM : un simple pointer-cliquer suffit pour que la tâche utilise cet endpoint au lieu d’afficher la page. La boucle habituelle « ouvrir les DevTools, trouver l’appel, copier les en-têtes, reconstruire la requête » devient ainsi une seule étape visuelle.
Lorsqu’elle est disponible, cette approche est la meilleure réponse aux pages affichées par JavaScript — et elle l’est plus souvent qu’on ne le pense. Vérifiez-la avant de recourir à un navigateur.
Approche 3 : détecter l’affichage côté serveur
Certains sites reposant sur des frameworks côté client mettent aussi en œuvre l’affichage côté serveur (SSR) ou la génération de sites statiques pour améliorer leurs performances et leur référencement. Dans ce cas, la réponse HTML initiale contient réellement tout le contenu : une requête HTTP légère peut donc suffire. Affichez le code source de la page (Cmd+U / Ctrl+U, et non « Inspecter », qui montre le DOM actif) ; si les données figurent déjà dans le HTML brut, vous pouvez vous passer entièrement de la surcharge d’un navigateur. Certains sites vont plus loin et fournissent un contenu différent selon le User-Agent, par exemple une version préaffichée aux crawlers des moteurs de recherche. Définir le User-Agent de la requête sur celui d’un robot de recherche connu permet parfois d’accéder à la version affichée côté serveur d’une page qui exigerait autrement JavaScript. Utilisez cette possibilité lorsqu’elle fonctionne, tout en respectant les conditions du site.Quelques conseils pratiques lorsqu’un véritable navigateur est nécessaire
Lorsque vous devez afficher la page dans un navigateur, les causes d’échec sont prévisibles :- Attendez le bon élément, pas l’événement « load ». L’événement de chargement du navigateur se déclenche une fois le HTML et les ressources reçus, mais le contenu affiché côté client peut être encore en cours de récupération. Attendez l’apparition du sélecteur ou du texte précis dont vous avez besoin, et non que la page soit « terminée ».
- Surveillez le chargement différé. Le contenu affiché uniquement après son entrée dans la zone visible n’existe pas tant que l’outil n’a pas fait défiler la page. La plupart des bibliothèques d’Automatisation du navigateur simulent le défilement ; encore faut-il savoir qu’il est nécessaire.
- Le routage côté client piège les outils traditionnels. Dans une SPA, passer de
/productsà/products/42peut modifier l’URL sans lancer de nouvelle requête HTTP. Une logique surveillant les événementspageloadmanque entièrement cette transition ; attendez plutôt une modification du contenu. - Le défilement infini et les boutons « Charger plus » exigent une interaction, et non une simple observation. Pour approfondir ces modèles, consultez Gérer la pagination.
Commencez par l’approche la moins coûteuse
Une stratégie fiable consiste à vérifier les points suivants dans cet ordre :- Afficher le code source. Si le contenu figure dans le HTML brut, une seule requête HTTP suffit.
- Inspecter les appels réseau. Si la page récupère son contenu auprès d’une API, appelez directement cette API : c’est plus rapide, léger et fiable.
- Afficher la page dans un véritable navigateur. Lorsque les deux premières options ne s’appliquent pas, exécutez la page. Choisissez l’environnement adapté à votre profil d’opérateur et aux défenses du site cible.