J’ai passé assez de temps sur les threads Slack d’équipes d’ingénierie pour savoir comment cette question commence en général : quelqu’un partage un lien vers une liste des « meilleurs outils de web scraping », et trois ingénieurs répondent aussitôt : « aucun ne mentionne Colly ». Ce n’est pas un hasard. J’ai consulté les quatre articles actuellement bien positionnés sur « Thunderbit vs Colly », et chacun compare Thunderbit à d’autres outils no-code — Crawl4AI, Browse AI, rtrvr.ai, Chat4Data. Colly n’apparaît nulle part.
Ce qui est un peu fou, parce que Colly a une vraie communauté fidèle sur r/golang et dans les équipes Go qui ont besoin de crawler Web rapide, piloté par du code. Voici donc l’article qui répond vraiment à la question — pas une comparaison recyclée d’« outils IA » avec le nom de Colly ajouté au passage.
Réponse rapide
Voici l’essentiel si vous lisez entre deux réunions : Thunderbit est un extracteur Web agentique, géré pour vous, prêt à l’emploi — sans sélecteurs, sans code, avec exécution dans le navigateur ou dans le cloud, ainsi qu’une Web App, une Open API, un MCP Server et une CLI pour les développeurs qui veulent un accès programmatique. Colly est un framework Go open source — vous écrivez le crawler, vous maîtrisez la logique, vous réglez la concurrence.
En réalité, ces deux outils ne sont pas vraiment des concurrents au sens classique. L’un est un produit. L’autre est une bibliothèque. Les comparer directement n’a de sens que si vous êtes à un carrefour et que vous cherchez la voie la mieux adaptée à votre cas précis — et c’est exactement ce que je veux vous aider à déterminer.
En un coup d’œil
| Dimension | Thunderbit | Colly |
|---|---|---|
| Utilisateur principal | Utilisateurs métiers, équipes ops, développeurs qui veulent aller vite | Développeurs Go |
| Configuration | Cliquer sur Extraire en un clic sur une page | go get github.com/gocolly/colly + écrire du code Go |
| Délai avant premier résultat | Quelques secondes à quelques minutes, l’agent lance automatiquement | Selon votre vitesse à écrire les callbacks |
| Langage | Aucun requis pour l’usage dans le navigateur | Go |
| Modèle de crawl | Analyse agentique des pages, compatible avec pagination / sous-pages | Collector manuel + callbacks OnHTML / OnResponse |
| Rendu | Exécution gérée via navigateur/cloud | Principalement HTTP/HTML ; les sites très JavaScript nécessitent des outils supplémentaires |
| Règles d’extraction | L’agent propose les champs, l’utilisateur peut les ajuster | Le développeur écrit les sélecteurs CSS à la main |
| Concurrence | Gérée par la plateforme | Contrôle total manuel via goroutines |
| Stockage / exports | Export vers des tableurs, feuilles de calcul et autres destinations prises en charge | Construit par le développeur (fichiers, bases de données, Redis, etc.) |
| Déploiement | Extension navigateur, Web App, API, MCP, CLI | Binaire / script Go auto-hébergé |
| Maintenance | Logique d’extraction gérée ; dépend toutefois de la compatibilité du site | Le développeur corrige les sélecteurs quand les sites changent |
| Licence / coût | Plans à crédits (vérifiez les niveaux actuels sur la page tarifaire) | Apache-2.0, gratuit — mais pas l’infrastructure ni le temps de développement |
Qu’est-ce que Thunderbit ?
Le flux de travail par défaut de Thunderbit tient vraiment en un clic. Vous ouvrez une page à laquelle vous êtes autorisé à accéder, vous appuyez sur Extraire en un clic, et l’agent lit la page, repère ce qui mérite d’être récupéré et propose les champs. Il y a un bouton Exécuter maintenant, mais honnêtement il est surtout là pour rassurer — si vous ne touchez à rien, l’extraction démarre toute seule. Pas besoin d’écrire des sélecteurs, pas de schéma à configurer, sur les pages prises en charge par l’agent.
Ensuite, vous pouvez affiner les champs si l’agent n’a pas tout juste, et sur les sites compatibles il peut parcourir la pagination ou explorer des sous-pages pour enrichir les données — par exemple récupérer des détails supplémentaires sur chaque fiche produit d’une liste. Une fois les données prêtes, l’export se fait vers les destinations habituelles : Excel, Google Sheets et quelques autres cibles prises en charge.
Mais l’extension navigateur n’est que la porte d’entrée. Si vous êtes développeur, vous avez l’Open API pour déclencher l’extraction depuis votre propre code, le MCP Server pour intégrer l’extraction comme outil appelable dans Claude, Cursor ou Windsurf, et la CLI pour les workflows en terminal et avec des agents de codage. Je le précise parce que beaucoup d’arguments « no-code contre code » présentent encore Thunderbit comme un simple jouet pour utilisateurs métiers, ce qui n’est plus exact.
Qu’est-ce que Colly ?
Colly est une bibliothèque Go, point final. Pas de tableau de bord, pas de service hébergé, pas de couche IA qui décide quoi extraire. Vous écrivez en Go, vous créez un Collector, puis vous accrochez des callbacks comme OnHTML et OnResponse pour lui dire précisément quoi faire lorsqu’il atteint une page.
En gros, cela ressemble à ceci :
c := colly.NewCollector()
c.OnHTML("a[href]", func(e *colly.HTMLElement) {
link := e.Attr("href")
c.Visit(e.Request.AbsoluteURL(link))
})
c.OnResponse(func(r *colly.Response) {
fmt.Println("Visited", r.Request.URL)
})
c.Visit("https://example.com")
C’est tout le modèle mental : définir quoi chercher, définir quoi faire quand vous l’avez trouvé, puis laisser le collecteur crawler. Sous le capot, vous obtenez un crawl synchrone, asynchrone et parallèle, une limitation de débit par domaine, la gestion automatique des cookies et des sessions, la mise en cache des requêtes, le respect de robots.txt, la rotation des proxies et des backends de stockage interchangeables, dont Redis pour les déploiements distribués.
Un point important à dire clairement : Colly est avant tout un framework HTTP/HTML. Il n’exécute pas un navigateur complet comme Playwright. Si votre site cible repose fortement sur le rendu JavaScript, vous devrez soit retrouver l’API JSON sous-jacente qu’il appelle, soit associer Colly à un outil d’automatisation de navigateur séparé. Ce n’est pas un défaut de Colly — c’est simplement une philosophie de conception différente d’un produit pleinement agentique et conscient du navigateur.
Différence fondamentale : extraction agentique gérée vs framework Go
Temps avant le premier tableau
C’est là que l’écart est le plus net. Avec Thunderbit, le « temps avant premier résultat » se mesure au temps nécessaire pour cliquer sur un bouton et attendre que l’agent termine la lecture de la page — quelques secondes à quelques minutes selon la complexité. Avec Colly, ce délai inclut l’écriture du collecteur, la recherche des bons sélecteurs (ce qui implique souvent quelques essais dans les outils de développement), la gestion de la pagination par vous-même, puis l’exécution. Pour une tâche ponctuelle, c’est un coût de temps réel, même pour un développeur Go compétent.
Performance et contrôle
Colly gagne sans discussion sur le contrôle brut. Comme vous écrivez la logique, vous décidez précisément combien de goroutines tournent en parallèle, à quel point la limitation de débit est agressive, ce qui est mis en cache et comment les erreurs sont retentées. La documentation du projet mentionne plus de 1 000 requêtes par seconde sur un seul cœur pour des cibles statiques adaptées — il s’agit d’une affirmation de benchmark de Colly, pas d’une comparaison contrôlée avec Thunderbit, et je ne vais pas prétendre le contraire. Mais cela vous indique une chose réelle : pour des cibles compatibles HTTP, une concurrence Go réglée à la main sera difficile à battre.
Thunderbit échange ce contrôle granulaire contre une exécution gérée. Vous ne réglez pas des pools de goroutines — vous vous appuyez sur les chemins d’exécution navigateur/cloud de la plateforme, ainsi que sur l’extraction planifiée lorsque votre formule le permet. C’est le bon compromis si vous ne voulez pas gérer l’infrastructure, et le mauvais si votre travail consiste précisément à obtenir le débit maximal d’un crawler.
Déploiement et responsabilité de la maintenance
Voici la partie dont on parle trop peu. Colly est « gratuit » au sens où la licence Apache-2.0 ne coûte rien. Mais il faut toujours que quelqu’un l’écrive, l’héberge, le surveille et — le point essentiel — le corrige lorsque le site cible modifie son HTML. Les sélecteurs cassent silencieusement. Personne ne reçoit d’alerte disant « au fait, ce site a refondu sa page produit ». Un développeur doit remarquer que le pipeline est devenu muet ou renvoie des données inutilisables, puis le réparer.
Avec Thunderbit, la logique d’extraction est gérée par la plateforme, et son analyse agentique des pages est conçue pour s’adapter aux variations de mise en page sur les pages prises en charge et autorisées. Je veux toutefois être prudent ici : ce n’est pas une garantie absolue. Les pages fortement protégées contre les robots, les contenus soumis à connexion hors du périmètre autorisé, ou les sites que l’agent gère simplement mal sont de vraies limites. La formulation honnête est la suivante : avec Colly, la correction repose toujours sur vous. Avec Thunderbit, la charge est plus faible, mais « plus faible » ne veut pas dire « nulle » — le succès dépend encore du fait que la page cible soit bien prise en charge par Thunderbit.
Scénarios concrets
Extraction ponctuelle d’un annuaire ou d’un catalogue produit
Imaginez que vous deviez obtenir un tableau de 200 produits depuis la page catalogue d’un concurrent avant la fin de la journée, et que vous ne soyez pas développeur (ou que vous le soyez, mais que vous ayez mieux à faire). C’est le terrain de jeu naturel de Thunderbit — cliquez, laissez l’agent proposer les champs, ajustez si besoin, exportez vers Sheets. Écrire un script Colly pour une extraction unique est techniquement possible, mais cela ressemble à utiliser une tronçonneuse pour tailler un bonsaï.
Crawler Go personnalisé à haut débit
À l’inverse, vous construisez un pipeline de surveillance qui interroge des milliers d’URL par jour, vous avez déjà une stack Go, et vous avez besoin d’un contrôle précis sur la logique de retry, le stockage distribué via Redis et des limites par domaine réglées pour éviter d’être bloqué. Là, on est en plein territoire Colly. Vous ne payez pas d’abonnement, vous possédez chaque ligne de logique, et vous pouvez optimiser selon vos schémas de trafic spécifiques d’une manière qu’un produit géré n’est pas conçu pour exposer.
Cible très JavaScript
Si votre cible rend tout côté client avec beaucoup de JavaScript, Colly seul n’est probablement pas la bonne réponse — il faudrait soit exploiter les API JSON sous-jacentes, soit ajouter une couche d’automatisation de navigateur. Les chemins d’exécution navigateur/cloud gérés de Thunderbit sont pensés pour ce type de page, même si, là encore, il faut tester la compatibilité sur votre cible avant de supposer que tout fonctionnera du premier coup.
Intégration API ou agent IA
Vous construisez un outil interne où un agent IA (par exemple dans Claude ou Cursor) doit récupérer des données structurées dans le cadre d’un flux de travail plus large ? C’est là que le MCP Server de Thunderbit devient réellement utile — il expose l’extraction comme un outil appelable au sein des workflows d’agents, ce qui est un cas d’usage que Colly ne couvre tout simplement pas nativement, puisqu’il s’agit d’une bibliothèque autonome et non d’un outil qu’un agent IA peut appeler directement sans couche supplémentaire.
Fiabilité, passage à l’échelle et maintenance
Je veux distinguer deux choses souvent confondues : le débit brut et le taux de réussite réel sur des sites Web concrets. Colly peut aller très vite sur des pages statiques compatibles HTTP — c’est exactement son objectif. Mais « rapide » ne signifie pas automatiquement « encore fonctionnel dans trois mois » lorsque le site cible déploie une refonte. Chaque sélecteur que vous avez écrit est alors potentiellement obsolète, et personne ne vous prévient avant que votre pipeline ne commence silencieusement à renvoyer des valeurs nulles.
L’approche agentique de Thunderbit signifie que vous n’entretenez pas vous-même les sélecteurs — mais je nuancerais tout discours, y compris celui du marketing de Thunderbit, qui laisserait entendre une fiabilité universelle sur tous les sites, surtout ceux qui appliquent des mesures anti-bot agressives ou du contenu derrière authentification sans autorisation. Si vous évaluez l’un ou l’autre outil, la vraie question n’est pas seulement « quelle est sa vitesse au premier jour ? », mais « qui corrige quand ça casse, et combien de temps cela prend ? ».
Prix, licence et coût total
Colly est open source sous Apache 2.0 — la bibliothèque elle-même est gratuite. Mais le coût total de possession inclut les heures de développement pour écrire et déboguer le crawler, le calcul nécessaire à son exécution, les coûts de proxy si vous avez besoin de rotation d’IP, et le temps continu dès qu’un site cible change et casse vos sélecteurs. Pour une équipe déjà à l’aise avec Go, cela peut être réellement peu coûteux à grande échelle. Pour une équipe qui ne possède pas cette compétence en interne, le « gratuit » devient vite « coûteux de façon cachée ».
Thunderbit fonctionne sur des plans à crédits — consultez la page tarifaire actuelle, car les niveaux et les quotas de crédits sont le genre de chose qui évolue, et je préfère vous renvoyer à la source plutôt que de citer un chiffre déjà obsolète quand vous lirez ceci. Le compromis, c’est que vous payez pour moins de maintenance manuelle sur les pages prises en charge, pas pour zéro maintenance partout.
Si vous voulez un cadre de réflexion honnête, faites un petit tableau pour votre propre contexte : temps de configuration, coût d’infrastructure / proxy, temps de correction récurrent, et coût d’abonnement. Le côté qui gagne sur ce tableau, compte tenu des compétences et de la charge réelles de votre équipe, sera votre réponse — pas l’idée générale selon laquelle « l’open source est moins cher ».
Qui devrait choisir Thunderbit ?
Si vous êtes utilisateur métier, responsable ops ou membre d’une équipe growth et que vous avez besoin de données structurées immédiatement sans toucher au code, l’extension navigateur de Thunderbit est le choix évident. Si vous êtes développeur et que vous voulez intégrer l’extraction comme un composant de construction — via API, CLI, ou dans un workflow d’agent IA via MCP — Thunderbit convient aussi, mais par une autre porte que le simple clic.
Qui devrait choisir Colly ?
Si vous êtes développeur Go (ou si votre équipe est centrée sur Go) et que vous avez besoin d’un crawler sur mesure, à haut débit, où vous contrôlez chaque requête, chaque retry, chaque rotation de proxy — Colly a été conçu exactement pour cela. C’est aussi le bon choix si vous voulez absolument posséder le code sans dépendre d’un abonnement, et que vous avez la capacité d’ingénierie pour le maintenir.
Peut-on utiliser les deux dans une même équipe ?
Honnêtement, oui, et je ne pense pas que ce soit une réponse de facilité. Il est assez courant qu’une équipe d’ingénierie exploite un crawler Colly robuste et dimensionné pour une chaîne de données critique, tandis que d’autres équipes — ventes, ops, marketing — utilisent Thunderbit pour des extractions ponctuelles qui ne justifient pas l’écriture et la maintenance d’un script. Je ne vais pas inventer ici une fausse « intégration officielle » entre les deux — à ma connaissance, il n’en existe pas — mais, sur le plan architectural, rien n’empêche ces deux outils de coexister dans la même organisation pour résoudre des problèmes différents.
Verdict
Choisissez en fonction de la personne qui fait le travail et de ce qu’elle cherche à optimiser. Si vous maîtrisez Go, que vous avez besoin de logique personnalisée et que vous préférez assumer la maintenance en échange d’un contrôle total et d’aucun coût d’abonnement, Colly est le bon outil. Si vous voulez des données rapidement, sans écrire ni maintenir de code, et que vous êtes prêt à échanger une partie du contrôle bas niveau contre une expérience gérée — avec, en plus, la possibilité d’intégrer l’extraction à une API ou à un agent IA — Thunderbit est le meilleur choix. Aucun des deux n’est « meilleur » en absolu ; ils sont construits pour des personnes différentes qui résolvent des problèmes différents.
FAQ
Colly est-il gratuit ? Oui — Colly est open source sous licence Apache 2.0, donc la bibliothèque elle-même ne coûte rien. Vos coûts réels viennent du temps de développement, de l’hébergement, des proxies si nécessaire, et de la maintenance continue lorsque les sites cibles changent.
Colly rend-il JavaScript ? Pas nativement. Colly est avant tout un framework HTTP/HTML, donc les sites très JavaScript nécessitent généralement soit de retrouver l’API JSON sous-jacente appelée par la page, soit d’associer Colly à un outil d’automatisation de navigateur séparé.
Thunderbit prend-il en charge l’API et l’accès MCP pour les développeurs ? Oui. Thunderbit propose une Open API pour l’extraction programmatique et un MCP Server qui expose l’extraction comme un outil appelable dans des workflows d’agents IA compatibles comme Claude, Cursor ou Windsurf.
Lequel permet de démarrer le plus vite ? Thunderbit, par conception — le flux Extraire en un clic de l’extension navigateur vous donne un résultat en quelques secondes à quelques minutes, sans code. Colly exige d’écrire et de tester du code Go avant d’obtenir un premier résultat.
Lequel offre le plus de contrôle bas niveau sur le crawl lui-même ? Colly, sans hésiter. Vous contrôlez directement, dans le code, la concurrence via les goroutines, la limitation du débit des requêtes, la mise en cache, la rotation des proxies et les backends de stockage — un niveau de réglage qu’un produit géré comme Thunderbit n’expose pas par conception.
