Revue de Colly : test de l’extracteur Go open source sur HTML, JSON et graphes de crawl

J’ai créé un site de test pour vérifier ce que la réputation en matière de nombre de pages ou de vitesse ne dit pas à propos de Colly : est-ce que ses callbacks extraient bien les enregistrements attendus, redirigent une erreur HTTP, parcourent un graphe borné et exposent des contenus servis en dehors du HTML rendu. Il s’agissait d’une revue centrée sur la justesse et les limites, pas d’un benchmark de débit.

Sur les jeux de données contrôlés, l’outil a extrait tous les enregistrements statiques attendus, a envoyé une réponse 500 vers OnError et a visité 17 URL dans le graphe limité par profondeur configurée. Il a renvoyé zéro élément cible sur deux pages dont les éléments n’apparaissaient qu’après exécution de JavaScript. Un point de terminaison JSON directement accessible restait utilisable sans navigateur, ce qui le distingue clairement du rendu de l’interface client.

Ce qu’est vraiment Colly

Colly se présente comme un « elegant scraper and crawler framework for Golang », et cette formule est plus riche qu’il n’y paraît. C’est une bibliothèque Go — environ 25 300 étoiles GitHub et 1 850 forks — sous licence Apache-2.0. Ce n’est pas un outil en ligne de commande qu’on télécharge pour lui donner une URL. Vous écrivez du Go, vous importez Colly, vous enregistrez quelques callbacks, puis vous compilez l’ensemble en un seul exécutable.

Le fonctionnement repose sur un modèle événementiel. On attache des gestionnaires à un Collector : OnHTML exécute la logique d’extraction pour les sélecteurs CSS correspondants, OnResponse fournit le corps brut de la réponse et OnError gère les échecs de requête. Les gestionnaires de liens appellent Visit() sur les URL découvertes, tandis que MaxDepth limite la traversée. Pour ces chemins HTTP uniquement, la machine cible n’a pas besoin d’un runtime Go ni d’un navigateur installés séparément ; le fait qu’un binaire soit totalement statique dépend des options de compilation et de l’usage de CGO, ce que ce test n’a pas relevé.

Fonctionnalités clés et fonctionnement interne

Le modèle de callbacks est l’élément essentiel à comprendre, car c’est ce qui donne à Colly une sensation différente d’un script de requête puis parsing. Trois callbacks ont porté tous mes tests.

OnHTML(selector, handler) est le cheval de bataille. En l’enregistrant sur .product ou article p, Colly appelle votre handler une fois par élément correspondant au moment où il parse le DOM. C’est là que vit l’extraction structurée, et la logique reste lisible — vous décrivez ce que vous voulez récupérer, vous n’écrivez pas une boucle de parsing.

OnResponse(handler) se situe un cran plus bas et vous donne les octets bruts. Quand une cible renvoie du JSON au lieu du HTML, vous ignorez complètement le DOM et désérialisez vous-même le corps. C’est ce callback unique qui a permis à Colly de traiter proprement une API JSON dans mes tests, sans aucun parsing HTML.

OnError(handler) gère les échecs de requête et peut exposer un statut HTTP au code appelant. Dans ce test, une réponse de fixture avec le statut 500 a bien atteint le callback enregistré. Les retries, les timeouts, les erreurs DNS, les resets de connexion, les panics dans les callbacks, la persistance et les alertes n’ont pas été testés.

Au-dessus de ces callbacks, on trouve deux fonctionnalités opérationnelles. MaxDepth borne la traversée des liens selon la sémantique de profondeur de Colly. Un exécutable Go compilé évite aussi d’avoir à installer un runtime de langage sur la machine cible. Ce test n’a pas enregistré les options de build ni l’état de CGO, il ne prétend donc pas que chaque binaire obtenu soit entièrement statique.

Installation : l’outillage Go requis

La dépendance est courte mais bien réelle, alors la voici avant toute installation. La machine de test n’avait pas Go installé, et Colly est une bibliothèque Go — la première étape a donc consisté à installer une toolchain Go sur la machine (j’ai installé Go 1.26.5 via Homebrew). Si votre équipe ne travaille pas déjà en Go, c’est là que se situe la friction : pas dans Colly lui-même, mais dans l’environnement de langage nécessaire avant même de compiler la moindre ligne.

Une fois Go installé, go get github.com/gocolly/colly/v2 a résolu la version v2.3.0. Les chemins testés n’avaient besoin ni d’un navigateur ni de Chrome headless.

Un point de version peut prêter à confusion. Le module Go s’est résolu en v2.3.0 (publié en décembre 2025), alors que la version la plus récente visible dans l’interface GitHub Releases était v2.2.0 (mars 2025) au moment de la vérification. La distinction porte sur la version du module ou du dépôt, et non sur une différence entre module et tag Git. J’ai testé v2.3.0.

Test pratique : extraction et limites d’exploitation

J’ai exécuté Colly sur un serveur de fixtures autonome (httptest de Go) ainsi que sur deux sites de démonstration publics. Le répertoire de benchmark actuel et le fichier results/colly-test-summary.json exposent les artefacts, mais les deux liens pointent vers une branche mouvante. L’article ne fournit ni commit testé, ni commande exacte, ni options de build, ni graine de fixture ; ce n’est donc pas encore une recette de reproduction immuable.

Sur les fixtures statiques contrôlées, les sélecteurs configurés ont produit 12 enregistrements produit sur 12 attendus et les trois paragraphes d’article attendus. La réponse JSON directe n’a jamais touché un parseur HTML : OnResponse a fourni le corps et le harness a décodé les huit éléments attendus. La fixture 500 unique a atteint OnError avec son statut exposé et n’a pas fait tomber l’exécution ; cela ne prouve pas une fiabilité en production sans surveillance. Sur la page publique Books to Scrape, le sélecteur a renvoyé 20 produits pour un test rapide sur site public.

Pour la traversée, le collecteur a été configuré avec MaxDepth(2) selon la convention de profondeur de départ du harness, et a visité 17 URL dans le graphe de fixtures. Il s’agit d’une couverture de crawl, pas d’une mesure de vitesse. La trace observée — et non une affirmation générale sur des graphes arbitraires — se trouve dans results/local_crawl_graph.json.

Colly n’exécute pas JavaScript. La fixture rendue par JavaScript a produit 0 carte cible, et la page publique Quotes to Scrape JS a produit 0 citation cible. Si les éléments n’existent qu’après exécution dans le navigateur et qu’aucun endpoint de secours accessible ne les fournit, le chemin HTTP seul ne peut pas voir ces éléments comme du DOM rendu. Il faut alors le combiner avec un moteur de rendu, ou appeler directement l’endpoint de secours quand il existe, comme le montre la fixture JSON.

Je n’ai pas poussé le collecteur asynchrone, la limitation de débit ou la configuration de politesse, la rotation de proxy, les retries, ni les backends de queue et de stockage. Aucun temps d’exécution, débit, concurrence, CPU, mémoire, latence cible ni baseline de comparaison n’a été mesuré. Cet article ne formule donc aucune promesse de vitesse ou de fiabilité sans surveillance.

Comment interpréter les résultats des fixtures

Les trois chemins de contenu réussis testent des contrats différents. Les cas catalogue et article vérifient la sélection CSS sur du HTML renvoyé par le serveur. Leurs dénominateurs sont des attentes de fixture écrites avant l’extraction : douze enregistrements produit et trois paragraphes d’article. Les présenter comme des « enregistrements attendus extraits » est volontaire. L’exécution ne définit ni correspondance floue, ni gestion des doublons, ni tolérance aux champs partiels, ni métrique de rappel sur l’ensemble d’un corpus ; le résultat ne doit donc pas être transformé en précision d’extraction générale.

Le cas JSON contourne la sélection du DOM. Colly reçoit les octets de la réponse via OnResponse, et le harness effectue le décodage JSON. C’est pour cela que « Colly n’exécute pas JavaScript » ne signifie pas que tout site côté client est hors de portée. Si la source de données utilisée par le client est un endpoint appelable directement et que la requête est reproductible hors du navigateur, le crawler HTTP peut encore suffire. L’authentification, les signatures générées, l’état réservé au navigateur et les protections anti-bot peuvent changer la réponse ; rien de tout cela n’a été testé ici.

Le chemin 500 teste la distribution, pas la récupération. Il montre que le callback OnError enregistré a bien reçu cette réponse de fixture et son statut. Un crawler de production a toujours besoin d’une politique explicite pour les codes retryables, le backoff, les échecs terminaux, la persistance et les alertes. Le test ne fournit aucune preuve pour ces choix, et « le callback a été déclenché » ne doit pas être lu comme « le job peut être confié sans surveillance ».

Le graphe de 17 URL est tout aussi étroit. Il confirme l’ensemble des pages visitées produit par cette fixture, cette convention de départ et MaxDepth(2). Il n’établit ni pages par seconde, ni équité entre hôtes, ni croissance mémoire, ni comportement sur les cycles et les formes d’URL dupliquées. Tout cela demande des tests de charge et de file d’attente séparés.

Une checklist de sélection fondée sur ce test

Commencez par regarder la réponse que Colly reçoit réellement. Si les champs requis sont présents dans du HTML renvoyé par le serveur, utilisez OnHTML et validez les nombres de champs ou les clés obligatoires avant d’accepter un enregistrement. Si la réponse est du JSON, traitez le corps via OnResponse et validez son schéma. Si le HTML n’est qu’une coque applicative, vérifiez si une requête de secours accessible contient les données avant d’ajouter un navigateur.

Quand l’exécution du navigateur est nécessaire, traitez-la comme un composant à part entière plutôt que d’espérer qu’un simple flag Colly active le rendu. Le navigateur doit établir l’état de disponibilité, exposer le contenu rendu ou les réponses de secours, puis alimenter le reste du pipeline. Cette revue n’a pas testé une telle intégration.

Pour le déploiement, consignez la version de Go, la version du module, les options de build, l’état de CGO, la commande exacte, la graine de fixture et le commit du dépôt. Ces détails manquent dans les liens de publication actuels, et c’est ce qui sépare des artefacts inspectables d’une reproduction durable. En exploitation, ajoutez une matrice d’échecs et mesurez la charge qui vous importe réellement avant de qualifier le système de rapide ou fiable.

Avantages et inconvénients

Avantages :

• 12/12 produits de catalogue attendus et 3/3 paragraphes d’article attendus extraits via OnHTML.
• Gestion propre du JSON via OnResponse, sans parsing du DOM — 8/8 éléments API.
• La réponse 500 testée a bien atteint OnError avec le statut exposé.
• Le crawl limité en profondeur a atteint 17 pages à partir d’un seul collecteur.
• Compilation en exécutable Go ; la cible n’a pas besoin d’un runtime Go installé séparément pour les chemins testés.
• Licence Apache-2.0 permissive.

Inconvénients :

• Aucune exécution de JavaScript — le contenu rendu côté client renvoie 0, sans nuance.
• Nécessite une toolchain Go ; les équipes non-Go paient ce coût de mise en place avant d’écrire le moindre scraper.
• Le module testé (v2.3.0) est en avance sur la version GitHub Release la plus récente observée (v2.2.0).
• La sortie dépend de votre propre code — Colly fournit des callbacks, pas un exporteur de données / flux intégré comme Scrapy.
• Les backends async, rate limiting, proxy et queue existent mais n’ont pas été testés ici ; le débit et l’échelle restent non mesurés.

Pour qui c’est adapté — et qui devrait passer son chemin

Colly convient si vous écrivez déjà en Go et ciblez du HTML rendu côté serveur ou du JSON directement accessible. Le modèle de callbacks sépare les correspondances structurées, les payloads bruts et les échecs de requête. Un exécutable compilé évite aussi d’installer un environnement de langage séparé sur la machine cible, même si le lien entièrement statique n’a pas été vérifié ici.

Ajoutez un moteur de rendu quand les éléments ciblés n’apparaissent qu’après exécution dans le navigateur et qu’aucun endpoint de secours exploitable n’existe. Un endpoint JSON direct peut toujours être interrogé sans rendu. Colly est aussi moins adapté aux équipes qui ne veulent pas d’une toolchain Go ou qui préfèrent qu’un service d’extraction gère la forme du schéma et la maintenance des sélecteurs.

Alternatives, et où Thunderbit se situe

Colly est un logiciel open source que vous exécutez vous-même. Il n’a pas de frais d’utilisation éditeur, mais le calcul, la bande passante, les proxies, le stockage, l’observabilité et l’ingénierie restent à votre charge. Vous maîtrisez le comportement des requêtes, les callbacks de parsing, la logique de crawl et l’intégration navigateur si une cible exige du rendu.

Un service d’extraction managé transfère une partie de ces responsabilités à un fournisseur. Nous développons Thunderbit, mais nous ne l’avons pas testé sur ces fixtures ; cet article ne propose donc aucune comparaison de rendu, d’anti-bot, de qualité, de latence ou de coût. La distinction à retenir est la responsabilité : Colly vous expose les réponses HTTP et les callbacks dans votre processus Go ; un service managé peut prendre en charge l’acquisition et la transformation du schéma moyennant un coût par appel.

Lectures de benchmark liées : la comparaison complète des scrapers open source, la revue du crawler Python Scrapy et la revue du sélecteur adaptatif Scrapling.

Essayez Thunderbit pour l’extraction de données web

Verdict

Colly est un excellent candidat pour les équipes Go qui ciblent du HTML rendu côté serveur ou du JSON direct et acceptent de gérer leur propre code d’extraction. Les fixtures valident l’extraction des enregistrements attendus, une trace de crawl bornée et un callback 500 observé — pas la vitesse, ni l’échelle, ni la fiabilité sans surveillance. Le DOM rendu par le navigateur nécessite un autre chemin, sauf si l’endpoint de données sous-jacent peut être appelé directement.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

Cette revue a-t-elle mesuré la vitesse de Colly ? Non. Elle a mesuré l’extraction des enregistrements attendus, la gestion directe du JSON, un callback d’erreur et la couverture d’un graphe de crawl de fixture. Elle n’a pas mesuré le temps écoulé, le débit, la concurrence, le CPU, la mémoire ou une baseline de comparaison.

Colly peut-il scraper des pages rendues en JavaScript ? Colly n’exécute pas le JavaScript de la page. Le chemin HTTP testé n’a donc trouvé aucun élément cible apparu uniquement dans le DOM rendu. Il peut toutefois interroger directement un endpoint JSON de secours accessible, comme le montre la fixture JSON. Utilisez un moteur de rendu quand l’exécution est nécessaire et qu’aucune requête de secours reproductible ne fournit les données.

Dois-je connaître Go pour utiliser Colly ? Oui. Colly est une bibliothèque Go, pas un outil autonome en ligne de commande — vous l’importez, vous enregistrez des callbacks (OnHTML, OnResponse, OnError) et vous compilez. La machine de test n’avait pas Go ; la mise en place a donc commencé par l’installation d’une toolchain Go (1.26.5). Si votre équipe ne travaille pas déjà en Go, cet environnement constitue le vrai coût d’installation.

Pourquoi la version que j’installe ne correspond-elle pas à la dernière release GitHub de Colly ? Le module Go s’est résolu en v2.3.0 (décembre 2025), tandis que l’entrée GitHub Release la plus récente observée était v2.2.0 (mars 2025). J’ai testé v2.3.0 ; il s’agit d’une différence entre surfaces de version, pas d’un signe d’installation cassée.

Colly est-il gratuit pour un usage commercial ? Oui, sa licence Apache-2.0 est permissive et adaptée au commercial. Comme toujours, vérifiez la licence actuelle sur le dépôt avant de vous appuyer dessus.

Avant une adoption en production, ajoutez des tests qui correspondent au risque opérationnel plutôt que d’extrapoler les résultats des fixtures par analogie. Mesurez les crawls répétés sur des cibles représentatives, relevez le CPU et la mémoire de pointe, testez les échecs retryables et terminaux, et vérifiez la politesse sous concurrence. Si la persistance compte, interrompez puis reprenez un crawl en inspectant la gestion des doublons et l’état de la queue. Si la simplicité de déploiement compte, consignez la configuration exacte du compilateur et de l’éditeur de liens, puis inspectez les dépendances runtime de l’exécutable produit. Aucune de ces vérifications ne change ce que la fixture actuelle a établi ; elles déterminent si cette même configuration de bibliothèque convient à une tâche de production donnée.