Presque tous les classements du type « meilleur extracteur open source » ont le même petit défaut, presque invisible : aucun ne fait tourner les outils sur les mêmes pages. Scrapy est jugé sur un article de presse, Playwright sur une démo e-commerce, Colly sur ce que l’auteur avait sous la main — puis on les compare directement, comme si ces chiffres voulaient dire la même chose. Ce genre de classement vous apprend surtout des choses sur les pages testées, pas sur les outils.
J’ai donc fait le truc évident — et un peu barbant — que ces listes évitent presque toujours. J’ai monté un seul jeu de fixtures, puis j’ai fait passer neuf outils dessus : un catalogue statique, un catalogue rendu en JavaScript, un article caché derrière la navigation et le pied de page, une erreur serveur 500 volontaire, un petit graphe de liens internes, ainsi que deux sites publics d’entraînement. Même vérité de référence, mêmes mesures, à chaque run. Les scripts et les sorties brutes sont dispo dans un dépôt public de benchmark pour que vous puissiez tout relancer vous-même. Le résultat n’est pas le joli tableau de classement propre et net promis par les compilations — il n’y a pas de vainqueur unique. Il y a trois types de tâches, et les neuf outils s’y répartissent presque naturellement.
Essayez Thunderbit pour l’extraction de données web
Comment le banc d’essai a fonctionné, et la seule limite que je veux dire clairement
Chaque outil a été confronté aux mêmes types de fixtures : 12 produits statiques répartis sur deux pages, 8 produits injectés par JavaScript après un délai, un article entouré de contenu de navigation et de pied de page pour ne garder que trois vrais paragraphes, une erreur serveur 500 intentionnelle, et un graphe de liens internes. C’est cette conception qui aligne les résultats — « 8/8 produits dynamiques » veut exactement la même chose, que la sortie vienne de Puppeteer ou de Crawlee.
Voici la limite que la plupart des bilans passent sous silence. Le pack de chaque outil recrée ses propres copies de ces fixtures, donc les comptes absolus de caractères ne sont pas strictement comparables d’un outil à l’autre — il faut les lire comme des signaux internes à l’outil, jamais comme un score inter-outils. Les chiffres vraiment comparables sont le rappel (à lire comme un taux), la réussite/échec sur JavaScript, et le comportement structurel. Même précision à garder en tête : le test de Crawl4AI sur le catalogue statique ne couvrait que la première page, donc son 6/6 correspond à un rappel complet sur un périmètre plus restreint, alors que les autres outils ont parcouru les deux pages pour obtenir 12/12 — un champ d’action plus petit, pas une perte partielle. Le détail complet, fixture par fixture, est dans le document méthodologique.
Encore une réserve avant les chiffres. Chaque pack embarque aussi un score de recherche provisoire, mais je ne les affiche volontairement pas sous forme de tableau classé. Ce n’étaient que des aides internes pour vérifier chaque outil à partir de ses propres preuves, pas un classement officiel — et les publier comme tel recréerait exactement ce faux sentiment de précision que tout ce travail cherche à éviter. Ici, on parle d’une synthèse de ce que le banc d’essai a montré, pas d’un podium.
Tout le terrain, sur un seul banc d’essai
Lisez les deux colonnes « Rend JavaScript ? » et « File d’exploration intégrée » de ce tableau, et les trois tâches apparaissent presque toutes seules.
| Outil | Langage | Rend JavaScript ? | Rappel statique | Sortie structurée | File d’exploration intégrée | Poids d’installation | Licence |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Oui (navigateur) | 6/6 (page 1) | Schéma CSS | BFS/DFS intégré | Lourd (2 piles navigateur) | Apache-2.0 |
| Firecrawl | Auto-hébergé | Oui (playwright-service) | Markdown complet | Oui | /v1/crawl | Très lourd (6 conteneurs) | AGPL-3.0 |
| trafilatura | Python | Non | 3/3 article | Non (texte uniquement) | Non | Léger | Apache-2.0 |
| Crawlee | Node/TS | Moteur optionnel | 12/12 | Via extraction | Oui (RequestQueue) | Moyen (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Oui | 12/12 | Manuel | Non (BFS écrit à la main) | Moyen (navigateur) | Apache-2.0 |
| Puppeteer | Node | Oui (Chrome) | 12/12 | Manuel | Non (BFS écrit à la main) | Moyen (Chrome) | Apache-2.0 |
| Scrapy | Python | Non | 12/12 | Export de flux (JSON/CSV/XML) | Oui (intégrée) | Moyen (dépendances Twisted) | BSD-3 |
| Colly | Go | Non | 12/12 | Via callbacks | Contrôle de profondeur | Léger (1 binaire + Go) | Apache-2.0 |
| Scrapling | Python | Non (récupération HTTP) | 12/12 | Oui | Non | Moyen ([fetchers]) | BSD-3 |
Petite note sur les métadonnées de ce tableau et de tout ce qui suit : les nombres d’étoiles et les numéros de version ont été relevés début juillet 2026, et ça bouge vite. Vérifiez-les à nouveau sur GitHub et sur la page du package de chaque projet avant de les considérer comme actuels.
L’index des revues par outil
Chaque projet de ce comparatif a sa revue détaillée correspondante :
- Revue de Crawl4AI
- Revue de Firecrawl
- Revue de trafilatura
- Comparatif Playwright vs Puppeteer
- Revue de Crawlee
- Revue de Scrapy
- Revue de Colly
- Revue de Scrapling
Voici leurs couvertures — plus deux vraies captures d’écran du test de rendu JavaScript, pour montrer que le « 8/8 dynamique » n’est pas juste un chiffre posé sur une page.
Tâche 1 : transformer une page en texte prêt pour un LLM
Si vous cherchez du Markdown propre à injecter dans un pipeline RAG, trois outils se disputent la place — et leur façon de fonctionner n’a vraiment rien à voir.
Crawl4AI est, malgré le discours marketing, un générateur de Markdown branché sur un navigateur. Ça vaut le coup d’ignorer le récit du « sélecteur auto-apprenant à intelligence adaptative » qu’on lui colle souvent dans les résultats de recherche : il n’en a pas — en fait, ce coup-là vient d’une autre bibliothèque (j’y reviendrai quand on parlera de Scrapling). Mais ce qu’il fait, il le fait bien. Sur le site d’entraînement Books to Scrape, il a produit 13 476 caractères de Markdown, gère l’extraction via schéma CSS pour les récupérations structurées, et sa BFS intégrée a parcouru 5 pages sur le graphe de crawl tout en rendant une page JavaScript et en capturant une capture d’écran. Deux bémols, quand même. Son Markdown brut garde le bruit de la page tant qu’on n’active pas un filtre de contenu, et l’erreur 500 volontaire est revenue avec success=false — non pas parce que Crawl4AI a proprement intercepté l’erreur HTTP, mais parce que son heuristique de contenu a vu le tout petit corps d’erreur et l’a classé comme minimal_text ... blocked. Et l’installation ajoute deux piles navigateur sur votre disque. Version 0.9.0, Apache-2.0, environ 71k étoiles début juillet.
Firecrawl est le poids lourd, et l’auto-hébergement marche vraiment — j’insiste sur « vraiment » parce que la pile à six conteneurs (api, playwright-service, redis, rabbitmq, nuq-postgres et foundationdb) s’est bel et bien montée et a produit 9 222 caractères de Markdown prêt pour LLM à partir de la même page Books to Scrape. Il a rendu une page JavaScript via son playwright-service intégré, et la citation d’Einstein apparue après le script s’est retrouvée dans la sortie, preuve que le rendu était bien réel. Les deux accrocs rencontrés venaient de mon environnement, pas de Firecrawl, et je veux être précis pour éviter qu’on reprenne la mauvaise correction : une compilation depuis les sources a coincé à cause d’un bug ponctuel du snapshotter containerd sous colima (je suis donc passé aux images précompilées), et la plage DNS 198.18.x.x de colima a déclenché la protection SSRF de Firecrawl, que j’ai désactivée via ALLOW_LOCAL_WEBHOOKS=true — une rustine de dev local, pas un réglage à couper en prod. Le cœur auto-hébergé n’inclut pas non plus Fire-engine, la couche cloud anti-blocage, et je n’ai pas testé l’API cloud. Le point le plus important reste la licence : le cœur auto-hébergé de Firecrawl est sous AGPL-3.0, ce qui demande un vrai examen juridique avant tout usage commercial, pas juste une petite note en bas de page. Environ 148k étoiles début juillet.
trafilatura est le contre-exemple du groupe, et c’est précisément celui que les listes boostées à l’IA oublient sans arrêt. Pas de navigateur. Pas de lignes structurées. Juste du texte d’article rapide et propre en pur Python. Sur la fixture article, il a récupéré le titre ainsi que les 3 vrais paragraphes sur 3, en supprimant complètement le bruit du site — aucun « Login », « Subscribe » ou « Copyright » n’est passé — et il a aussi récupéré l’auteur et la date. Sur une page produit publique, il a renvoyé 1 324 caractères de texte propre. Sa limite est exactement celle qu’annonce sa conception : mettez-le sur un catalogue et il vous renverra 12 noms de produits en texte mais 0 ligne structurée — le texte est là, la structure non, et aucun JavaScript n’est rendu. Version 2.1.0 (la version actuelle), Apache-2.0, environ 6,2k étoiles. Pour l’extraction pure d’articles, c’est le premier outil que je prendrais.
Ces deux comptes de caractères Markdown — 13 476 pour Crawl4AI, 9 222 pour Firecrawl — viennent de la même page publique, mais il ne faut pas y voir une différence de qualité. Ils reflètent des stratégies Markdown différentes (plus ou moins de chrome de page conservé), pas un verdict sur le meilleur rendu. C’est bien la règle du signal interne à l’outil, évoquée plus haut, qui se voit ici clairement.
Tâche 2 : rendre JavaScript de manière fiable
Certaines données n’existent tout simplement pas dans le HTML tant que les scripts n’ont pas tourné, et à ce moment-là, un vrai navigateur n’est plus optionnel. Trois outils couvrent cette tâche — et deux d’entre eux se sont révélés être presque le même outil.
Playwright et Puppeteer ont fait égalité sur tous les tests que je leur ai lancés. Tous les deux ont rendu 8/8 produits dynamiques sur la fixture locale et 10 sur le site public Quotes JS, tous les deux ont atteint 12/12 de rappel statique, et tous les deux ont géré correctement l’erreur 500 (Puppeteer renvoie un objet réponse au lieu de lever une exception). Aucun des deux n’embarque de file de crawl, donc il a fallu écrire une BFS à la main pour parcourir le graphe de 12 pages. La seule vraie différence concerne la portée : Playwright pilote Chromium, Firefox et WebKit et parle Python et .NET, tandis que Puppeteer est d’abord centré sur Chrome et uniquement Node. Deux précisions, parce que les versions changent vite ici : j’ai testé Playwright 1.56.0 face à une version actuelle 1.61.1 et seulement avec Chromium, et Puppeteer 24.16.0 face à une version actuelle 25.3.0 — à revalider ou à relativiser en conséquence. Tous deux sont sous Apache-2.0 ; environ 92k et 95k étoiles respectivement.
Crawlee est celui qui règle le problème de file que les deux autres laissent ouvert. Il met un moteur Cheerio (HTTP) et un moteur Playwright (navigateur) derrière une seule API, et le contraste sur une page résume bien l’intérêt : le moteur Cheerio n’a vu 0 élément injecté par JavaScript, le moteur Playwright a tout vu, 8/8 en local (et 10 sur le site public), et passer de l’un à l’autre demande juste une ligne. Il fournit aussi une vraie RequestQueue, ce qui lui vaut sa place dans cette catégorie plutôt que dans la troisième. Le piège que personne ne met dans le titre : le moteur navigateur demande un npx playwright install séparé, soit environ 80 MiB que npm install crawlee ne télécharge pas pour vous. Version 3.17.0, TypeScript, Apache-2.0, autour de 24,6k étoiles.
Tâche 3 : crawler vite sans navigateur
Quand une page n’a pas de JavaScript, un navigateur devient un luxe coûteux. Trois outils HTTP-first s’affrontent ici, chacun avec sa logique de langage, et ils se distinguent de façon intéressante.
Scrapy est le framework le plus « industriel » du lot — spiders, exports de flux en JSON/CSV/XML, AutoThrottle, tout l’attirail. Il a atteint 12/12 de rappel statique, récupéré les 3/3 paragraphes de l’article, parcouru 11 pages en profondeur 0 à 2 sur le graphe de crawl, et intercepté la 500 via handle_httpstatus_list. Sa vision du monde est la partie la plus intéressante : il ne rend pas, il rejoue la requête. Face à la page JavaScript, il a obtenu 0 nœud — puis l’API JSON derrière cette même page lui a donné 8/8. C’est la philosophie Scrapy en une seule donnée : trouver la requête réellement utilisée par la page et la rejouer, sans piloter de navigateur. Le coût, c’est une pile de dépendances assez lourde (Twisted, lxml, parsel), et je ne l’ai testé que sur de petites fixtures. Version 2.17.0, BSD-3-Clause, environ 63k étoiles.
Colly est l’équivalent Go, et il est d’une franchise rafraîchissante sur ce qu’il est : un binaire statique, piloté par callbacks via OnHTML, OnResponse et OnError, avec contrôle de profondeur. Il a réussi 12/12 de rappel statique, extrait 8/8 depuis l’API JSON via OnResponse, intercepté la 500 via OnError, et atteint 17 pages lors d’un crawl en profondeur 2 — et je le formule exactement comme ça, parce que ce nombre de pages vient du compteur du banc d’essai, pas d’une garantie de complétude que Colly annoncerait lui-même. En revanche, il ne gère pas JavaScript : la fixture dynamique et le site public Quotes JS sont tous les deux revenus à 0, par conception. Il faut une toolchain Go pour le compiler, et la version du module (v2.3.0) est actuellement en avance sur la release taguée (v2.2.0). Apache-2.0, environ 25k étoiles.
Scrapling est l’outil spécialisé, et il mérite bien ce mot. Ses sélecteurs adaptatifs sont faits pour retrouver un élément quand le balisage change — par exemple, quand j’ai renommé la classe HTML d’une cible de product-name en product-title, un sélecteur classique a renvoyé 0, alors que la re-concordance adaptative a retrouvé l’élément suivi. En extraction HTTP pure, il a atteint 12/12 sur le statique et 8/8 sur l’API JSON. La partie que sa doc ne cache pas : dans un test synthétique à plusieurs éléments, il n’en a récupéré qu’1 sur 3 — on parle d’un suivi d’élément résilient, pas d’une récupération totale, donc évitez de le sur-vendre dans votre tête. Son installation de base pip install scrapling exige aussi l’extra [fetchers] pour fonctionner, et son StealthyFetcher est un point de vigilance conformité, pas une fonctionnalité que je mettrais en avant sur une slide. Version 0.4.10 (la version actuelle), BSD-3-Clause, environ 68,7k étoiles.
Le schéma qui se cache derrière les trois tâches
Alignez les neuf outils et un motif saute aux yeux. Un rappel statique complet — un simple 12/12 — est le minimum attendu pour tout outil HTTP-first ; aucun n’a trébuché sur le cas facile, donc ce n’est pas un critère différenciant. Les outils navigateur ne justifient leur poids supplémentaire que lorsqu’il y a vraiment du JavaScript dans l’équation, et ils le paient tous au niveau de l’installation : une pile navigateur, un install en plus, ou une flotte complète de conteneurs. Et la colonne « file d’exploration intégrée » trace en réalité la frontière entre un framework et un moteur — Scrapy et Crawlee apportent l’orchestration, alors que Playwright et Puppeteer vous laissent écrire la BFS vous-même. Voilà la forme du marché. Personne ne gagne au global parce que personne ne joue exactement au même jeu.
Alors, lequel devriez-vous vraiment choisir ?
Le banc d’essai refuse de sacrer un gagnant, parce que la vraie réponse n’est pas un outil mais une question — quelle tâche êtes-vous en train de faire ?
- Besoin de Markdown prêt pour un LLM ? Prenez trafilatura si vous voulez du texte d’article propre, Crawl4AI si vous voulez aussi l’extraction CSS et le rendu JavaScript dans une seule bibliothèque, et Firecrawl si vous cherchez vraiment un service auto-hébergé et que vous pouvez gérer à la fois la licence AGPL-3.0 et le poids de six conteneurs.
- Besoin de JavaScript rendu ? Playwright ou Puppeteer pour le rendu brut — choisissez selon le moteur et le langage, puisqu’à part ça ils sont à égalité — et Crawlee si vous voulez en plus qu’on vous fournisse l’orchestration du crawl au lieu de l’écrire à la main.
- Crawler des pages statiques ou des API reproductibles à grande échelle ? Scrapy pour un framework Python complet, Colly pour la vitesse brute de Go dans un seul binaire, et Scrapling quand survivre aux changements de balisage est votre douleur précise et récurrente.
Associez l’outil à la tâche, et chacun de ces choix se défend très bien. Prenez la mauvaise catégorie — un outil navigateur pour des pages statiques, ou un parseur HTTP pour une application JavaScript — et même la bibliothèque la mieux notée du web vous lâchera.
Où se place plutôt une API IA managée
Tous les outils ci-dessus sont gratuits, open source, et à exécuter vous-même. C’est aussi le compromis commun que le banc d’essai met sans cesse en lumière : vous êtes responsable de l’environnement navigateur, du code de crawl, de la course contre l’anti-bot, et de toute la maintenance. Pour beaucoup d’équipes, ce niveau de contrôle est justement l’intérêt, et la carte des licences compte quand on s’y engage — la majeure partie du terrain est permissive (Apache-2.0 pour Crawl4AI, Crawlee, Playwright, Puppeteer et Colly ; BSD-3 pour Scrapy et Scrapling), avec le cœur auto-hébergé de Firecrawl sous AGPL-3.0 comme seul cas qui mérite un vrai examen avant un usage commercial.
Mais regardez aussi ce que le banc a montré : ce que ces outils ne font pas. Rendre, crawler, structurer et contourner les blocages — rarement tout à la fois, et jamais sans votre maintenance. Une API d’extraction IA managée condense toute cette pile en un seul appel. Notre propre surface développeur chez Thunderbit est une option dans ce domaine, et pour un public technique, ce sont surtout l’API, le serveur MCP et la CLI qui comptent, pas l’extension navigateur. POST /distill renvoie du Markdown propre et POST /extract renvoie du JSON défini par schéma, avec le rendu JavaScript et la résistance anti-bot gérés côté serveur plutôt que sur votre machine. Il existe un serveur MCP officiel pour les agents et les assistants de code — thunderbit_suggest_fields est gratuit pour planifier une extraction, puis thunderbit_distill (1 crédit) et thunderbit_extract (20 crédits) exécutent le travail — ainsi qu’une CLI que vous pouvez installer avec npx @thunderbit/thunderbit-cli pour les tâches de terminal et de cron. Pour les non-développeurs de votre équipe, il y a aussi une extension Chrome sans code, et la tarification couvre les deux cas.
Le compromis reste le même que celui que ce banc d’essai met en évidence du début à la fin : faire tourner et maintenir vous-même jusqu’à neuf bibliothèques pour un coût nul à l’appel, ou déléguer l’infrastructure et payer à la requête. Aucun des deux choix n’est mauvais. Tout dépend de la part de la pile que vous voulez vraiment posséder. Si vous voulez voir à quoi ressemble l’extraction en pratique, la chaîne YouTube Thunderbit vous montre le fonctionnement.
{{INTERNAL_BLOG_LINKS}}
Verdict
Il n’existe pas d’extracteur open source « meilleur » au sens absolu, et toute liste qui vous en désigne un masque discrètement la vraie question : quelle tâche faites-vous ? Transformer une page en texte, rendre JavaScript, ou crawler vite sans navigateur — le secteur se découpe proprement selon ces trois axes, et à l’intérieur de chacun, le choix dépend du langage et du poids d’installation, pas d’un champion universel.
Si vous ne retenez qu’une habitude de tout ça, retenez celle-ci : testez sur vos propres pages avant de vous lancer. Chaque chiffre ici est reproductible dans le dépôt du benchmark précisément pour cette raison — parce que l’outil qui domine un classement générique et celui qui tient sur vos vrais sites ne sont pas toujours le même.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Quel est le meilleur extracteur web open source ? Il n’y en a pas un seul — tout dépend de la tâche. Pour du texte prêt pour un LLM, trafilatura ou Crawl4AI ; pour le rendu JavaScript, Playwright, Puppeteer ou Crawlee ; pour un crawl HTTP rapide, Scrapy ou Colly. Sur un banc d’essai partagé, chaque outil était le plus fort dans sa propre catégorie et nettement moins performant hors de celle-ci, ce qui explique pourquoi les classements universels sont trompeurs.
Quels extracteurs open source rendent JavaScript ? Crawl4AI, Firecrawl, Playwright, Puppeteer, ainsi que le moteur Playwright de Crawlee rendent JavaScript. Scrapy, Colly, trafilatura et le récupérateur HTTP par défaut de Scrapling ne le font pas — ils ont soit besoin d’une API reproductible derrière la page (l’approche de Scrapy, qui a obtenu 8/8 depuis le point de terminaison JSON), soit d’un mode navigateur séparé.
Ai-je besoin d’un navigateur headless pour scraper un site ? Seulement si les données apparaissent après l’exécution de JavaScript. Si une simple requête HTTP plus un parseur peuvent atteindre le contenu, un navigateur est un surcoût inutile — Scrapy, Colly ou Scrapling seront bien plus légers et plus rapides dans ce cas.
Lequel a la licence la plus favorable pour un usage commercial ? La plupart sont permissives : Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) ou BSD-3-Clause (Scrapy, Scrapling). L’exception est le cœur auto-hébergé de Firecrawl, sous AGPL-3.0, qui mérite un vrai examen de licence avant d’en faire la base d’un produit commercial.
Ces chiffres de benchmark sont-ils reproductibles ? Oui. Chaque exécuteur, chaque fixture et chaque résultat brut se trouvent dans un dépôt public sous licence MIT. La seule réserve à garder en tête : les résultats de rappel et de structure sont comparables entre outils, mais les comptes absolus de caractères ne sont valables qu’à l’intérieur d’un outil, parce que chaque pack recrée les fixtures au lieu de partager une copie canonique unique — comparez donc les taux et les réussites/échecs, pas les totaux bruts de caractères.
