Scrapy est souvent mis dans la case « incapable de gérer les sites modernes » parce qu’il n’exécute pas JavaScript. En réalité, ce reproche passe à côté de l’essentiel. Ne pas rendre la page fait partie du concept, et dès qu’on comprend cette logique, on arrête de voir ça comme une absence de fonctionnalité.
Je me l’ai prouvé en un seul test. J’ai monté un catalogue de test rendu en JavaScript, j’ai pointé Scrapy vers la page telle qu’un navigateur l’afficherait, et j’ai récupéré 0 carte produit. Puis j’ai envoyé le même spider vers le point de terminaison JSON appelé discrètement en arrière-plan par cette page, et j’ai obtenu 8/8 éléments, proprement. Même outil, même session, résultat opposé — et l’écart entre ces deux chiffres résume à lui seul tout l’intérêt de ce test.
Ce qu’est vraiment Scrapy — et ce qu’il n’est pas
Scrapy est un framework Python pensé pour explorer des sites et en extraire des données structurées. C’est ainsi que ses mainteneurs le présentent dans la documentation d’introduction, et après l’avoir utilisé, on peut dire que c’est exact — pas besoin de forcer un discours marketing trop beau pour être vrai. Le projet est assez ancien et suffisamment bien installé pour être la réponse spontanée quand un développeur Python demande avec quoi les gens sérieux font du scraping, et le dépôt confirme cette réputation : environ 62 981 étoiles GitHub au 2026-07-07 (scrapy/scrapy), avec 11 773 forks et 590 issues ouvertes à la même date. Licence BSD-3-Clause, Python 3.10 ou plus récent, et la version que j’ai testée était 2.17.0, publiée le matin même où j’ai lancé ces essais — donc pas d’astérisque lié à une version trop vieille.
C’est là qu’on trace la frontière avec les nouveaux outils de crawl dopés à l’IA : Scrapy est, par défaut, limité au HTTP. Pas de navigateur. Pas de moteur de rendu. Il récupère le HTML via le réseau, le passe à un parseur, puis vous laisse extraire les champs avec des sélecteurs CSS ou XPath. Appeler cela une limitation n’est vrai qu’à moitié, parce que ça rate totalement l’intention de conception. Le principe de Scrapy, c’est qu’ouvrir un Chrome headless pour une extraction de routine est souvent une mauvaise idée — l’approche plus maligne consiste à repérer la requête de données que la page fait déjà et à l’appeler directement.
Ce n’est pas une lecture personnelle de l’outil. La documentation officielle sur le contenu dynamique le dit très clairement : il faut d’abord repérer et reproduire la requête de données sous-jacente, puis n’utiliser un navigateur headless qu’en dernier recours si cette reproduction n’est pas réaliste. La plupart des extracteurs ouvrent le navigateur d’abord et ne pensent jamais à l’API. Scrapy, lui, inverse cette logique par défaut.
Fonctionnalités clés, et le choix de conception derrière chacune
Sous le capot, Scrapy assemble plusieurs briques, toutes pensées pour une chose : vous laisser du contrôle, pas vous imposer un assistant en un clic.
Spiders. Vous écrivez une classe, vous lui donnez des URL de départ, puis vous définissez un rappel parse qui émet des éléments ou suit d’autres liens. Ça demande plus de code qu’un extracteur sans programmation — les règles d’extraction sont à écrire soi-même — mais en contrepartie vous décidez précisément ce qui est capturé et jusqu’où le crawl continue.
Sélecteurs. Le parsing repose sur parsel, lui-même basé sur lxml. CSS et XPath sont tous les deux pris en charge nativement, pas ajoutés à la va-vite. C’est grâce à lxml que la sélection reste rapide et que le code d’extraction exprime l’intention plutôt qu’un empilement confus de découpes de chaînes.
Export des flux. Si vous ciblez un fichier, Scrapy sérialise vos éléments en JSON, JSON Lines, CSV ou XML sans plomberie en plus. Lors de mon test, un spider sur un catalogue statique a généré à la fois du JSON et du CSV sans que j’écrive une seule ligne dédiée à l’export — la promesse des feed exports est bien réelle.
AutoThrottle et contrôle du crawl. Les requêtes sont planifiées de façon asynchrone sur Twisted, avec des limites de concurrence, des délais de téléchargement, des restrictions de profondeur, AutoThrottle pour un rate limiting adaptatif, et le respect de robots.txt. Ce sont ces garde-fous qui évitent qu’un crawl large se transforme en bombardement de serveur.
HTTP-only, dit autrement comme avantage. Pas de navigateur signifie moins de mémoire, un meilleur débit, et pas de moteur de rendu à surveiller — à condition que les données recherchées soient accessibles en HTTP classique. Ce qui, plus souvent qu’on ne le croit dans les équipes « browser-first », est bel et bien le cas.
Installation : la pile de dépendances qu’on ne voit jamais en capture d’écran
L’installation n’a rien eu de spectaculaire, ce qui, pour un framework de cette taille, mérite d’être dit clairement. pip install Scrapy==2.17.0 s’est terminé sans incident dans un nouvel environnement virtuel sur macOS arm64, en récupérant des wheels binaires, sans compilation bloquante. Rien de dramatique à raconter — et c’est justement le but.
Mais regardez ce qui a été installé. scrapy version -v a indiqué Scrapy 2.17.0 avec lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 et cryptography 49.0.0, complétés par parsel, cssselect et tldextract. Ça représente un vrai socle — la pile d’un framework complet de crawling, pas un simple parseur HTML dans un seul fichier. Sur cette machine, tout existait en wheels et l’installation est restée simple. Sur d’autres environnements, la documentation officielle signale toujours des frictions possibles selon la plateforme, et historiquement ce sont surtout les briques cryptography et Twisted qui posent problème ; si tu es sur un système un peu atypique, prévois ce temps-là. Ici, l’installation a été fluide ; la taille de ce qui s’installe reste malgré tout utile à connaître avant de te lancer, parce que tu adoptes un framework avec le poids d’un framework.
Test pratique : ce qui a fonctionné
Une fois installé, le scénario statique s’est déroulé sans accroc. Rappel complet, aucune donnée perdue.
| Test | Résultat | Temps d'exécution |
|---|---|---|
| Catalogue statique local + pagination | 12/12 produits | 0.557s |
| Export CSV du catalogue statique | 12 lignes écrites | (même exécution) |
| Extraction d'article | titre + 3/3 paragraphes du corps | 0.416s |
| Graphe de crawl, DEPTH_LIMIT=2 | 11 pages sur les profondeurs 0/1/2 | 0.904s |
| Page locale 500 | statut 500 capturé, aucune panne | 0.424s |
| Books to Scrape (public) | 20 produits | 2.053s |
| Spider Quotes to Scrape (public) | 12 citations | 3.465s |
Le spider sur le catalogue statique a suivi la pagination de la première à la deuxième page et a capturé 12/12 enregistrements attendus, puis les a exportés en JSON et CSV dans la même passe. Le cas de l’article mérite qu’on s’y arrête. Scrapy n’a pas essayé de nettoyer automatiquement la page pour en faire un Markdown propre — à la place, j’ai pu cibler explicitement les champs article avec des sélecteurs précis, et isoler la navigation ainsi que le pied de page dans des champs séparés. J’ai donc obtenu 3/3 paragraphes du corps, tandis que les éléments de remplissage restaient à part, au lieu de se mélanger à la sortie. C’est le compromis : tu écris les sélecteurs, et tu obtiens exactement ce que tu as demandé, ni plus ni moins.
Le contrôle du crawl a aussi été solide à petite échelle. Avec DEPTH_LIMIT=2, un court délai de téléchargement, une concurrence limitée par domaine et robots.txt activé, le graphe de crawl a visité 11 pages sur les profondeurs 0, 1 et 2, et le comptage des niveaux s’est comporté comme prévu. La gestion des erreurs a été tout aussi simple. La page volontairement en erreur 500 est revenue sous forme d’élément structuré avec le statut 500 exposé via handle_httpstatus_list — pas d’exception, pas d’arrêt brutal. Scrapy traite un statut d’erreur comme quelque chose à gérer dans la logique du spider, pas comme une surprise qui fait tomber tout le crawl.
Test pratique : le mur JavaScript et la porte juste à côté
Voici maintenant le résultat sur lequel repose cette revue.
J’ai pointé le fetcher HTTP de Scrapy vers un catalogue de test rendu en JavaScript. Il a téléchargé le HTML source, trouvé 0 nœud .product-card, puis passé à la suite — parce qu’il n’a jamais exécuté le script qui aurait dessiné ces cartes. La page JavaScript publique Quotes to Scrape JS racontait la même chose : 0 nœud de citation rendu. Si on s’arrêtait là, on conclurait que Scrapy n’est bon pour rien de vraiment moderne.
Mais il ne faut pas s’arrêter là. Ce catalogue JS était alimenté en arrière-plan par une API JSON, comme dans la plupart des cas de ce genre. J’ai envoyé le même spider Scrapy vers ce point de terminaison et j’ai obtenu 8/8 produits en 0.416s — pas de navigateur, pas de rendu, juste une requête vers l’URL que la page appelait déjà et le parsing du JSON renvoyé.
Ce face-à-face résume à petite échelle la philosophie du « reproduire la requête ». La page rendue n’est qu’un écran de fumée ; les données étaient derrière une API depuis le début, et la conception de Scrapy vous pousse à aller directement à la source plutôt que de payer un navigateur headless pour regarder la page se construire. C’est plus rapide, plus léger, et ça casse moins souvent — un contrat d’API est bien plus stable qu’un amas de DOM côté client. La contrepartie, c’est le travail manuel. Il faut ouvrir l’onglet réseau, trouver la requête, et reproduire soi-même ses en-têtes et ses paramètres. Scrapy ne découvre pas l’API à ta place ; il rend simplement l’appel trivial une fois que tu l’as identifiée.
Deux limites, dites franchement. Lorsqu’il n’existe vraiment aucune requête sous-jacente à reproduire — par exemple lorsque les données sont injectées uniquement côté client sans API derrière — Scrapy a besoin d’une intégration de navigateur headless que tu branches toi-même, et je n’ai pas testé ce chemin dans cette session. Et tout ce qui précède a été exécuté sur de petits jeux de test et des pages de démonstration publiques. Je n’ai pas lancé un crawl de 100 à 1 000 pages, donc je ne fais aucune promesse sur la mémoire, le débit ou la gestion des retries à grande échelle — le cœur asynchrone et les contrôles de crawl sont de bons signaux, mais un signal n’est pas une mesure.
Avantages et inconvénients
Avantages :
- Conception HTTP-only rapide et légère — 12/12 sur le statique en environ une demi-seconde, 8/8 depuis une API JSON en 0.416s, sans surcoût de navigateur.
- L’approche « reproduire la requête » fonctionne vraiment : une page JavaScript qui renvoyait 0 a livré les 8 éléments via son API.
- Les sélecteurs CSS et XPath basés sur
lxmlgardent le code d’extraction lisible et rapide. - Export direct vers JSON/CSV/XML sans code supplémentaire.
- Gestion explicite des erreurs — un 500 est capturé comme statut, pas comme crash.
- Contrôles de crawl mûrs : concurrence, délais, profondeur, AutoThrottle, robots.txt.
- Licence BSD-3-Clause permissive ; installation propre sur une machine récente.
Inconvénients :
- Ne rend pas JavaScript par conception — 0 nœud sur une page rendue côté client tant que tu n’as pas trouvé l’API toi-même.
- La découverte de la requête sous-jacente est manuelle ; Scrapy ne t’indique pas l’endpoint.
- Pile de dépendances conséquente (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — fluide ici, mais historiquement source de friction sur certaines plateformes.
- Plus de code qu’un outil no-code ou d’extraction automatique ; les spiders sont à écrire et à maintenir soi-même.
- Mes tests se limitaient à de petits jeux de données et des sites de démonstration, pas à de gros crawls — la fiabilité à l’échelle n’est pas prouvée dans cette passe.
À qui il convient — et qui devrait passer son chemin
Scrapy s’adresse aux développeurs qui veulent garder la main au niveau du code et qui raisonnent en requêtes plutôt qu’en pages. Si ton premier réflexe face à un site JavaScript lent est « il y a sûrement une API quelque part », l’outil est pensé exactement pour cette intuition. Il récompense ceux qui sont à l’aise pour écrire des sélecteurs, lire un onglet réseau et assumer de bout en bout leur logique d’extraction. Pour les sites statiques, les catalogues paginés et tout ce qui repose sur un endpoint JSON détectable, il est rapide et précis.
Passe ton chemin — ou associe-le au moins à un autre outil — si écrire et maintenir du code de spider n’est pas la façon dont tu veux passer ton temps, ou si tes cibles rendent leurs données uniquement côté client sans requête reproductible et que tu préfères ne pas ajouter toi-même un navigateur headless. Et si ton rêve consistait à pointer un outil vers une URL et obtenir une sortie structurée propre sans écrire de règles d’extraction, ce n’a jamais été le rôle de Scrapy, et il n’a jamais prétendu le contraire.
Alternatives, et la place de Thunderbit
Essayez Thunderbit pour l’extraction de données web
Il faut partir de ce à quoi tu t’engages : un framework gratuit et open source que tu exécutes et maintiens toi-même. Tu possèdes les spiders, la pile de dépendances et le travail de découverte de la requête de chaque site. En échange, tu ne payes rien par requête, tu gardes tout en interne et tu obtiens un contrôle total. Pour beaucoup d’équipes, c’est le bon choix, et ce test n’a pas pour but d’en détourner qui que ce soit.
La contrepartie se situe dans le problème du rendu et des dérives de page, et la réponse de Scrapy consiste à dire : c’est à toi de le résoudre. Tu trouves l’API, tu reproduis la requête, et tu gères les cas sans API en branchant toi-même un navigateur. Une API de scraping IA gérée retire cette couche de tes épaules. C’est là que se place Thunderbit pour les lecteurs techniques — une API de scraping IA, un serveur MCP et une CLI, et non l’extension navigateur utilisée par les équipes commerciales et opérationnelles. POST /distill transforme une page en Markdown propre prêt pour les LLM ; POST /extract renvoie du JSON structuré à partir du schéma que tu définis ; et les deux prennent en charge le rendu JavaScript, l’anti-bot et le contenu dynamique côté serveur — y compris le cas rendu côté client où Scrapy t’invite à utiliser un navigateur. Il existe un serveur MCP pour les agents IA et les assistants de code (avec un thunderbit_suggest_fields gratuit pour cadrer une page avant de dépenser quoi que ce soit), ainsi qu’une CLI via npx @thunderbit/thunderbit-cli pour le terminal, la CI ou les tâches cron.
La différence n’est pas la qualité, mais la propriété du système. Scrapy est un framework d’ingénierie explicite : tu gères le spider, le pipeline et la stratégie JavaScript, et tu obtiens un contrôle total sans coût par appel. La stack de Thunderbit délègue la couche de rendu et d’extraction à un service géré, ce qui t’évite d’explorer l’onglet réseau et te fait payer à l’usage. Petit, orienté code, et tu aimes maîtriser chaque étape ? Le contrôle de Scrapy est plus adapté. Tu dois scaler sur une centaine de sites et tu ne veux pas reproduire manuellement une requête par site ? Le modèle géré supprime toute cette catégorie de travail.
Pour un aperçu plus large du paysage, ces tests de référence couvrent les voisins : la comparaison complète des extracteurs open source, le test de Colly, le crawler Go sans navigateur, et l’évaluation de Scrapling sur les sélecteurs adaptatifs.
Verdict
Faut-il utiliser Scrapy ? Oui — si tu es développeur, que tu veux garder la main, et que tu adhères à cette vision : ne pas rendre la page, trouver la requête derrière elle. Dans les tests, cette philosophie a produit exactement ce qu’elle promettait. Un catalogue JavaScript a donné 0 carte au fetcher HTTP ; l’API JSON qui l’alimentait a livré ses 8 éléments au même spider. L’extraction statique a atteint 12/12, les sélecteurs d’article ont conservé 3/3 paragraphes sans bruit, le graphe de crawl a respecté sa limite de profondeur sur 11 pages, et un 500 est revenu comme un statut géré au lieu d’un crash.
Il faut toutefois calibrer correctement ces affirmations. Scrapy ne rend pas JavaScript, et il ne découvrira pas l’API à ta place — ce réflexe, c’est à toi de le construire. La pile de dépendances est celle d’un vrai framework et peut poser problème sur des plateformes atypiques, même si tout s’est bien passé ici. Et j’ai testé des fixtures et des pages de démonstration, pas un crawl de mille pages, donc il faut considérer la promesse de passage à l’échelle comme encourageante mais non démontrée dans ce test. Dans ces limites, Scrapy est l’outil qui épouse le plus franchement une idée discrètement radicale : le chemin le plus rapide à travers une page web passe souvent… par le fait de ne pas passer par la page elle-même.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Scrapy peut-il extraire des pages rendues en JavaScript ? Pas avec son fetcher HTTP par défaut — il a renvoyé 0 nœud à la fois sur une fixture JS et sur la page publique Quotes JS, parce qu’il télécharge le HTML sans lancer de navigateur. La démarche prévue consiste à trouver la requête de données sous-jacente et à l’appeler directement ; dans mon test, l’API JSON derrière un catalogue JS a livré ses 8 éléments. Pour les pages sans requête reproductible, il faut brancher toi-même un navigateur headless.
Que signifie exactement « reproduire la requête » ? La plupart des pages dynamiques chargent leurs données depuis une API JSON en arrière-plan, puis les rendent côté client. Au lieu de lancer un navigateur pour observer ça, tu ouvres l’onglet réseau, trouves cet appel API et pointes Scrapy dessus directement. C’est plus rapide et plus stable que le rendu — un contrat d’API casse moins souvent qu’un DOM — mais ça demande un travail manuel, et Scrapy ne localise pas l’endpoint pour toi.
Scrapy est-il difficile à installer ?
Pour moi, non — pip install Scrapy==2.17.0 s’est terminé sans erreur de compilation dans un nouvel environnement virtuel sur macOS, avec des wheels binaires. Mais l’outil embarque une pile assez large (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), et la documentation officielle met toujours en garde contre des frictions liées à la plateforme sur certains systèmes ; prévois donc une marge si tu es sur un environnement inhabituel.
Quels formats de sortie Scrapy prend-il en charge ? Les feed exports gèrent nativement JSON, JSON Lines, CSV et XML — il suffit de pointer un spider vers un fichier pour sérialiser les éléments sans code supplémentaire. Lors de mon test, un spider a produit à la fois du JSON et du CSV en une seule passe. Note qu’il exporte les champs sélectionnés ; il ne nettoie pas automatiquement une page pour en faire du Markdown.
Scrapy est-il gratuit pour un usage commercial ? Oui, la licence BSD-3-Clause est permissive et compatible avec un usage commercial. Comme toujours, vérifie la licence actuelle sur le dépôt avant de t’appuyer dessus, et garde des choix responsables pour ton user-agent, tes proxys et tes limites de débit — la capacité technique n’est pas une permission.
