Quand on tape « Colly », le premier mot qui revient est toujours le même : rapide. Un crawler Go rapide, rapide parce qu’il se compile, rapide parce qu’il n’a pas de navigateur à gérer. Mais presque personne ne met de chiffres derrière.
Alors j’ai arrêté de prendre ce mot pour argent comptant. J’ai monté un petit site de test, compilé Colly dessus et observé ce que la bibliothèque faisait vraiment — le taux de récupération sur de vraies pages, la façon dont elle gérait une requête en échec, jusqu’où un crawl limité en profondeur pouvait aller. La version courte, avant les chiffres : l’extraction statique a atteint un rappel complet, une erreur 500 a été envoyée exactement là où il fallait, et un crawl borné par la profondeur a atteint 17 pages à partir d’un unique binaire statique, sans navigateur. La bibliothèque a aussi renvoyé un zéro net sur tout ce qui était rendu en JavaScript — ce que les discours sur la « vitesse » ont tendance à passer sous silence.
Ce qu’est vraiment Colly — et ce qu’il n’est pas
Colly se présente comme un « framework élégant de scraping et de crawl pour Golang », et cette simple phrase en dit plus qu’on ne le croit. C’est une bibliothèque Go — environ 25,4 k étoiles au 2026-07-09 sur gocolly/colly, sous licence Apache-2.0. Ce n’est pas un outil en ligne de commande qu’on télécharge pour le lancer sur une URL. Tu écris du Go, tu importes le package, tu branches quelques callbacks, puis tu compiles le tout en un exécutable unique.
Le modèle mental est piloté par les événements, et ça déstabilise souvent celles et ceux qui ont l’habitude d’une logique requête puis parsing. On ne parcourt pas une réponse pour en extraire les champs ligne par ligne. On accroche des gestionnaires à un Collector, puis la bibliothèque les déclenche au fil de sa navigation. OnHTML lance ton code d’extraction à chaque fois qu’un sélecteur CSS correspondant apparaît. OnResponse te renvoie le corps brut de la réponse, ce qui est essentiel quand le contenu est du JSON plutôt que du HTML. OnError intercepte les requêtes qui échouent. Le crawl fonctionne de la même manière : dans un handler de liens, tu appelles Visit() sur les URL trouvées, Colly les met en file d’attente, et MaxDepth détermine jusqu’où la navigation peut s’étendre. Des callbacks, une file de visites, une limite de profondeur, un binaire statique compilé. Pas d’interpréteur, pas de runtime, pas de Chrome headless en mémoire.
Le modèle de callbacks, et pourquoi il change la sensation d’extraction
Les callbacks, c’est vraiment la personnalité de l’outil, donc ça mérite qu’on s’y arrête. Trois d’entre eux ont porté tous les tests que j’ai exécutés.
OnHTML(selector, handler) est celui que tu utiliseras le plus souvent. Enregistre-le sur .product ou article p, et Colly appelle ton handler une fois par élément correspondant pendant l’analyse du DOM. C’est là que vit l’extraction structurée, et la lecture est agréable — tu décris ce que tu veux, pas la boucle qui va le chercher.
OnResponse(handler) se situe un niveau plus bas et te donne les octets bruts du réseau. Quand une cible renvoie du JSON au lieu de balises HTML, tu ne touches jamais au DOM — tu désérialises toi-même le corps. Ce seul callback explique pourquoi Colly a géré une API JSON dans mon test sans analyser un seul morceau de HTML.
OnError(handler) est le callback que tout le monde oublie jusqu’au moment où un scraper plante à 3 h du matin. Il se déclenche lorsqu’une requête échoue et te transmet la réponse, pour que tu puisses lire le code de statut et décider de la suite. Un crawler qui avale les échecs en silence est pire qu’un crawler qui échoue bruyamment ; Colly ne fait ni l’un ni l’autre, et c’est plus important que ça en a l’air quand un job tourne sans surveillance.
Deux autres fonctionnalités s’ajoutent à ces callbacks et comptent sur le plan opérationnel. MaxDepth limite le crawl, afin qu’un collecteur qui suit les liens s’arrête après deux niveaux au lieu d’explorer tout le web. Et le résultat de compilation est un seul binaire Go statique — on compile une fois, on obtient un fichier sans dépendances au runtime, qu’on déploie sur un serveur ou dans un job CI. Si tu as déjà perdu une après-midi à cause d’un virtualenv Python sur une machine fraîchement provisionnée, ce profil de déploiement ressemble davantage à un vrai avantage qu’à une simple note de bas de page.
Installation — la chaîne d’outils Go dont personne ne parle
L’histoire des dépendances est courte, mais il y a un vrai point d’attention, alors autant le dire avant d’installer quoi que ce soit. La machine que j’ai testée n’avait pas Go du tout, et Colly est une bibliothèque Go ; l’étape zéro consistait donc à installer la chaîne d’outils sur la machine — j’ai installé Go 1.26.5 via Homebrew. Si ton équipe ne vit pas déjà dans Go, c’est là la vraie friction. Pas la bibliothèque. L’environnement de langage dont elle a besoin avant même qu’une ligne puisse compiler.
Une fois Go en place, récupérer Colly s’est fait sans accrocs. go get github.com/gocolly/colly/v2 a résolu vers la version v2.3.0 sans difficulté — pas de navigateur, rien de headless, rien d’autre que le binaire compilé à la fin. Compare ça à des scrapers Python qui installent un parseur puis se cassent au premier fetch à cause d’une chaîne de dépendances optionnelles manquantes, et l’expérience était presque ennuyeuse. Ici, « ennuyeux » est un compliment.
Un point de précision, dit clairement, parce qu’il va absolument te perturber si tu vas fouiller. Le dernier module sur le proxy Go est v2.3.0, publié en décembre 2025. La dernière release taguée sur GitHub est v2.2.0, datant de mars 2025. Donc le code que j’ai testé — v2.3.0 — est en avance sur ce que la page Releases du dépôt affiche. C’est une particularité du décalage entre modules Go et tags GitHub au fil du temps, pas le signe d’un problème. Ne sois simplement pas surpris quand go get et la page Releases annoncent des versions différentes.
Test pratique — les chiffres derrière « rapide »
J’ai exécuté Colly sur un serveur de test autonome construit avec httptest de Go, plus deux sites de démonstration publics, afin que le comportement soit reproductible plutôt qu’anecdotique. Voici ce que j’ai obtenu.
| Test | Cible | Résultat |
|---|---|---|
| Catalogue statique + pagination | fixture locale | 12/12 produits, rappel 1.0 |
| Extraction d’article | fixture locale | titre + 3/3 paragraphes |
| API JSON dynamique | fixture locale | 8/8 éléments via OnResponse, rappel 1.0 |
| Gestion d’un HTTP 500 | fixture locale | routé vers OnError, statut 500 |
Graphe de crawl (MaxDepth 2) | fixture locale | 17 pages |
| Books to Scrape | démo publique | 20 produits |
| Page dynamique (sans JS) | fixture locale | 0 carte (attendu) |
| Quotes JS (sans rendu) | démo publique | 0 (attendu) |
Lis ça de haut en bas, et le tableau d’ensemble tient parfaitement. L’extraction statique était propre — 12 produits sur 12 extraits du catalogue, les trois paragraphes complets sur l’article, le tout piloté par des sélecteurs OnHTML. Le test d’API JSON n’a jamais ouvert un parseur HTML : OnResponse a transmis le corps, je l’ai désérialisé, 8 éléments sur 8 sont revenus. Le test 500 est celui sur lequel je m’appuie le plus, parce que c’est la frontière entre un crawler qu’on peut laisser tourner toute la nuit et un autre qu’on ne peut pas : Colly a envoyé l’échec vers OnError et a exposé le statut proprement, sans crash ni disparition silencieuse. Sur la démo publique Books to Scrape, il a récupéré 20 produits sans traitement particulier.
Le résultat du crawl est l’information principale, et je veux le formuler avec précision. Un collecteur MaxDepth(2), en suivant les liens et en les résolvant en URL absolues, a atteint 17 pages sur mon graphe de test. C’est enfin un chiffre concret derrière la formule « crawler Go rapide », au lieu d’une impression. Mais attention au libellé : 17 pages dans le cadre d’un crawl limité à la profondeur 2. Le nombre de profondeur correspond ici au compteur de mon harness de test, qui décrit la configuration de l’exécution ; je ne prétends pas que Colly garantit en interne « exactement profondeur 2, pas un lien de plus » comme contrat. L’énoncé honnête et vérifiable est le suivant : avec une profondeur plafonnée à 2, le crawl a traversé le graphe et atteint 17 pages.
Vient maintenant la limite, là où les articles sur la « vitesse » deviennent généralement silencieux. Colly n’exécute pas JavaScript. Je l’ai envoyé vers une fixture rendue en JavaScript et j’ai obtenu 0 carte ; je l’ai ensuite envoyé sur la page publique Quotes to Scrape JS et j’ai encore obtenu 0. Ce n’est ni un bug, ni un reproche. Colly est un crawler HTTP — il télécharge et analyse du HTML, mais il ne lance jamais de navigateur pour exécuter des scripts côté client. Comme Scrapy et les autres crawlers HTTP-first, si le contenu que tu cherches n’existe qu’après l’exécution de JavaScript, Colly te renvoie systématiquement un résultat vide, et aucune vitesse brute ne change ça. Il faut soit l’associer à un moteur de rendu, soit choisir un outil qui en intègre un.
Je serai tout aussi transparent sur ce que je n’ai pas testé, pour que personne n’étire mes résultats au-delà des preuves. Je n’ai pas poussé le collector asynchrone, la configuration de limitation de débit et de politesse, la rotation de proxies, ni les backends de file d’attente et de stockage. Ces fonctionnalités existent dans Colly. J’ai testé le cœur extraction+crawl, pas l’infrastructure de montée en charge. Le README annonce un débit supérieur à un millier de requêtes par seconde sur un seul cœur, mais il s’agit du chiffre du projet lui-même — j’ai mesuré des pages et du rappel, pas du débit ; donc quand je parle de « rapide », je parle du chemin d’extraction Go compilé que j’ai réellement chronométré, et non d’un benchmark contre Scrapy que je n’ai pas exécuté.
Avantages et inconvénients
Avantages :
- Rappel complet sur l’extraction statique — 12/12 produits du catalogue et 3/3 paragraphes de l’article via
OnHTML. - Gestion propre du JSON via
OnResponse, sans parsing du DOM — 8/8 éléments d’API. - Routage correct des échecs — un 500 a atterri dans
OnErroravec le statut exposé, sans crash. - Un crawl limité en profondeur a atteint 17 pages depuis un seul collecteur.
- Un binaire Go statique, zéro dépendance au runtime — un excellent profil de déploiement et d’exploitation.
- Licence Apache-2.0 permissive.
Inconvénients :
- Pas d’exécution JavaScript — le contenu rendu côté client revient à 0, sans exception.
- Nécessite une chaîne d’outils Go ; les équipes qui ne travaillent pas déjà avec Go paient ce coût d’installation avant même d’écrire un scraper.
- Le dernier module (
v2.3.0) est en avance sur la dernière release taguée (v2.2.0), ce qui va dérouter toute personne qui se fie à la page Releases. - La sortie dépend de ton propre code — Colly fournit des callbacks, pas un dataset prêt à l’emploi ni un exportateur de flux intégré comme Scrapy.
- Les backends async, rate limiting, proxy et queue existent mais n’ont pas été testés ici ; le mot « rapide » désigne le chemin d’extraction que j’ai mesuré, pas un chiffre de débit en face-à-face.
Pour qui Colly est-il fait — et qui devrait passer son tour
Colly convient si tu écris déjà du Go et que tu explores des sites fondés sur HTML ou JSON à grande vitesse. Si ton idée d’un déploiement propre consiste à copier un binaire sur une machine puis à le lancer — sans interpréteur, sans virtualenv, sans loterie des dépendances — l’outil a été conçu exactement pour cette manière de faire. Le modèle à callbacks prend tout son sens dès que l’extraction cesse d’être triviale : OnHTML pour la structure, OnResponse pour la charge brute, OnError pour les échecs que tu ne verrais autrement jamais. Pour une cible statique ou alimentée par API, que tu lances selon un planning depuis CI, c’est un choix solide et sans drama.
Passe ton chemin, ou ajoute au minimum un second outil, quand tes cibles reposent sur JavaScript. Colly a renvoyé 0 sur chaque page rendue côté client que je lui ai soumise, et c’est voulu, pas un réglage à activer. Passe ton chemin aussi si ton équipe ne touche pas au Go et que tu ne veux pas mettre en place une chaîne d’outils juste pour extraire quelques sites — l’engagement vis-à-vis du langage est réel et il faudra l’assumer. Et si tu veux recevoir des données structurées au lieu de les parser toi-même dans ton code, les callbacks de Colly te laissent ce travail entièrement à charge.
Alternatives — où se situe une API de scraping IA gérée
Colly est une bibliothèque open source gratuite que tu compiles et exécutes toi-même. Tu possèdes le code Go, les callbacks, la logique de crawl et la machine sur laquelle tout tourne — et, en échange, tu ne paies rien par requête et tu gardes l’ensemble en interne. Pour une équipe Go, c’est une réponse parfaitement défendable, et le déploiement en un seul binaire est franchement agréable.
Les deux limites qui comptent sont aussi celles qui valent la peine d’être comparées à autre chose. Premièrement, JavaScript — Colly ne le rend pas, donc tout ce qui est côté client reste hors de portée sans ajouter un navigateur. Deuxièmement, la structure — Colly fournit des callbacks et laisse le soin de produire un résultat propre à ton propre code. Une API de scraping IA gérée répond différemment à ces deux points. La stack développeur de Thunderbit gère le rendu JavaScript et renvoie des données structurées côté serveur. POST /distill transforme une page en Markdown propre, prêt pour un LLM, avec le contenu dynamique et la protection anti-bot pris en charge pour toi. POST /extract renvoie du JSON structuré à partir du JSON Schema que tu définis, avec un renderMode que tu peux pousser jusqu’au rendu navigateur complet lorsqu’une page en a besoin. Thunderbit propose aussi un serveur MCP pour les agents IA et les assistants de code — thunderbit_suggest_fields est gratuit, ce qui permet d’explorer ce qu’une page expose avant de t’engager — ainsi qu’une CLI lançable avec npx @thunderbit/thunderbit-cli pour le terminal, CI et cron.
Essayez Thunderbit pour l’extraction de données web
Le compromis n’est pas meilleur contre moins bon. C’est plutôt l’endroit où le travail se situe. Avec Colly, tu gardes le rendu (aucun), l’analyse et la maintenance dans ton propre binaire compilé, sans coût par appel, et tu dois le surveiller lorsqu’un site change de forme. Avec une API gérée, tu délègues le rendu JavaScript, l’anti-bot et la sortie structurée, et tu paies à l’usage pour ce privilège. Des cibles petites, natives Go, HTML ou JSON, que tu es prêt à posséder et à maintenir ? Le contrôle et la vitesse de Colly l’emportent sans discussion. Des pages très dépendantes de JavaScript, ou simplement l’envie de recevoir du JSON calqué sur un schéma plutôt que d’écrire encore un callback ? Voilà le cas d’usage d’une solution gérée. Si tu veux une vue d’ensemble plus large, les sélections des meilleurs outils de web scraping et des meilleurs projets GitHub de web scraping montrent où se place une bibliothèque comme Colly face aux options orientées navigateur et aux services gérés.
Verdict
Faut-il utiliser Colly ? Oui — si tu écris du Go et que tu explores du HTML ou du JSON à grande vitesse, il fait bien ce que promet sa réputation de « crawler rapide », et il y a désormais des chiffres pour l’étayer. Rappel complet sur l’extraction statique. JSON propre via OnResponse. Un 500 correctement orienté vers OnError. Un crawl à profondeur 2 qui a atteint 17 pages. Le tout compilé en un seul binaire statique, sans dépendances au runtime, ce qui correspond sans doute au scénario de déploiement le plus simple de toute cette catégorie.
Mais il faut aussi mesurer les affirmations avec honnêteté. Il ne rend aucun JavaScript — chaque page côté client dans mon test est revenue à 0, et c’est définitif, pas un paramètre oublié. Il nécessite une chaîne d’outils Go, donc les équipes non-Go paient un coût d’installation dès le départ. Le module que tu installes (v2.3.0) est en avance sur la dernière release taguée (v2.2.0), donc inutile de paniquer quand les pages ne racontent pas la même chose. Et ici, « rapide » désigne le chemin d’extraction que j’ai mesuré, pas un benchmark de débit que je n’ai pas exécuté. Dans ce cadre, Colly est un crawler Go rapide, fiable et réellement déployable — et il mérite sa réputation dès l’instant où tu cesses de lui demander d’exécuter JavaScript.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Colly est-il vraiment rapide, et y a-t-il un chiffre derrière ? Oui, rapide au sens utile pour le chemin principal que j’ai mesuré : Go compilé, rappel complet sur l’extraction statique (12/12 produits du catalogue), gestion propre du JSON, et un crawl à profondeur 2 qui a atteint 17 pages — le tout dans un seul binaire statique. Ce que je n’ai pas exécuté, en revanche, c’est un benchmark de débit contre Scrapy ; considère donc « rapide » comme le comportement d’extraction mesuré, et non comme un score de vitesse en confrontation directe.
Colly peut-il extraire des pages rendues en JavaScript ? Non. Colly est un crawler HTTP — il télécharge et analyse du HTML, mais ne lance jamais de navigateur. Une fixture rendue en JavaScript a renvoyé 0 carte, et la page publique Quotes JS a renvoyé 0 elle aussi. Pour du contenu côté client, il faut soit combiner Colly avec un moteur de rendu, soit utiliser un outil qui intègre le rendu navigateur.
Faut-il connaître Go pour utiliser Colly ?
Oui. Colly est une bibliothèque Go, pas un CLI autonome — tu l’importes, tu enregistres des callbacks (OnHTML, OnResponse, OnError) et tu compiles. La machine que j’ai testée n’avait pas Go, donc l’installation a commencé par la mise en place de la chaîne d’outils (1.26.5). Si ton é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 ?
Parce que le module Go et le tag de release GitHub se sont éloignés l’un de l’autre. Le dernier module sur le proxy Go est v2.3.0 (décembre 2025), tandis que la dernière release taguée sur GitHub est v2.2.0 (mars 2025). J’ai testé v2.3.0. C’est un décalage entre modules et tags, pas une installation cassée.
Colly est-il gratuit pour un usage commercial ? Oui, il est sous licence Apache-2.0, donc permissive et favorable à un usage commercial. Comme toujours, vérifie la licence actuelle sur le repo avant de bâtir dessus.
