Le web scraping change de nature dès qu'une charge de travail approche le milliard de requêtes par mois. À petite échelle, le problème d'ingénierie consiste à extraire des données d'un site web. À l'échelle de l'entreprise, le problème devient opérationnel : tenir les pipelines de rafraîchissement dans les délais, maintenir des taux de succès stables, absorber la pression anti-bot et faire en sorte que la couche de collecte ne devienne jamais le goulot d'étranglement de tout ce qui se trouve en aval.
Cette étude de cas retrace la façon dont une plateforme américaine de premier plan spécialisée dans l'intelligence de la location de vacances a intégré le Crawlbase Enterprise Crawler à une plateforme de données existante afin de prendre en charge environ un milliard de requêtes par mois sur Airbnb, Vrbo, Booking.com et les places de marché de voyage régionales.
La plateforme analytique de l'entreprise était déjà conçue pour ingérer, normaliser et analyser de gros volumes de données de places de marché. Plutôt que de repenser ce système, l'équipe d'ingénierie a remplacé uniquement la couche de collecte. Crawlbase a repris la charge d'acquérir les données web de manière fiable à grande échelle, ce qui a laissé le client libre de continuer à travailler sur ce qui différenciait réellement le produit : transformer des données brutes de places de marché en business intelligence.
5.52 milliards de requêtes réussies, soit une moyenne de 919 millions par mois et environ 30.6 millions par jour, pour un taux de succès moyen de 99.96%. Le volume mensuel a progressé de 51% entre novembre 2025 et un pic de 1.04 milliard en mars 2026, et le taux de succès mensuel n'est jamais descendu sous 99.78%.
La charge de travail
La plateforme analytique du client sert plus de 2,300 organisations d'hébergement professionnel dans 220+ pays et territoires, en combinant des données publiques de places de marché avec des données de réservation directes pour produire une intelligence de marché en temps réel destinée au secteur de la location courte durée.
Contrairement à une plateforme analytique bâtie sur une source unique, leur système fusionne en continu deux flux indépendants. Le premier provient de 65+ intégrations de systèmes de gestion immobilière (PMS), qui couvrent les données de réservation et d'exploitation d'environ 700,000 biens gérés. Le second provient de la collecte à grande échelle de données publiques de places de marché sur Airbnb, Vrbo, Booking.com et les plateformes régionales de location de vacances.
| Métrique | Valeur |
|---|---|
| Couverture géographique | 220+ pays et territoires |
| Intégrations PMS | 65+ |
| Biens gérés | 700,000+ |
| Annonces Airbnb surveillées | 6.15 millions |
| Annonces Vrbo surveillées | 1.85 million |
| Requêtes de crawl par jour à couverture complète | ~33 millions |
| Requêtes de crawl par mois | ~1 milliard |
Chaque crawl alimente un calcul : taux d'occupation, disponibilité, tarifs à la nuitée, délais de réservation, ADR, RevPAR et comparatifs concurrentiels sur des milliers de marchés locaux. Rafraîchir les annonces, les calendriers, les tarifs et les disponibilités sur des millions de biens est ce qui porte le chiffre quotidien à environ 33 millions de requêtes, et le chiffre mensuel vers le milliard.
À cette échelle, le défi d'ingénierie change de forme. Collecter une page d'annonce est simple. En collecter des millions en continu, terminer chaque cycle de rafraîchissement dans une fenêtre de SLA stricte et livrer les données assez vite pour que l'analytique en aval reste à jour est un tout autre problème.
La fiabilité compte alors davantage que le débit de pointe. Chaque crawl retardé, chaque timeout et chaque job incomplet finit par se traduire en intelligence de marché périmée, et cela se voit dans les tendances d'occupation, les référentiels de prix et les modèles de prévision dont dépendent des milliers d'équipes d'hébergement professionnel.
Quand la couche de collecte devient le goulot d'étranglement
Des charges de travail de cette taille révèlent des problèmes qui apparaissent rarement dans les systèmes de scraping plus modestes.
À mesure que le volume quotidien s'approchait de 33 millions de requêtes, l'infrastructure de collecte a commencé à souffrir. La latence de crawl augmentait pendant les charges soutenues, si bien que les gros jobs de rafraîchissement mettaient de plus en plus de temps à se terminer. Les timeouts de requêtes se faisaient plus fréquents, en particulier sur les pages d'annonces dynamiques et les calendriers de disponibilité d'Airbnb et de Vrbo. Les échecs isolés restaient gérables ; sur des millions de requêtes, ils s'accumulaient en lots incomplets et en cycles de rafraîchissement en retard.
Exploiter une infrastructure de proxy autogérée à cette échelle constituait un problème à part entière. Les performances de routage variaient d'une région à l'autre, des pannes réseau intermittentes introduisaient des délais imprévisibles, et maintenir les pools de proxy en bonne santé exigeait une attention constante. Pendant ce temps, Airbnb et Vrbo continuaient de renforcer leurs défenses anti-bot, réduisant le rendement effectif du crawl par blocage, fingerprinting et autres méthodes de détection.
Les conséquences dépassaient largement la couche de scraping. Chaque crawl retardé signifiait que l'analytique en aval travaillait sur des données de places de marché plus anciennes. Les calendriers de disponibilité dérivaient, les instantanés de prix prenaient du retard sur les conditions réelles du marché, et les comparatifs concurrentiels perdaient en fraîcheur dès qu'une fenêtre de rafraîchissement dépassait sa cible.
Le coût le plus élevé était le temps d'ingénierie. Au lieu de construire des capacités analytiques, l'équipe consacrait une part croissante de sa semaine à maintenir l'infrastructure de crawl, à ajuster les pools de proxy, à récupérer les jobs en échec et à traquer les problèmes de collecte. Rien de tout cela n'était un bug à corriger. C'était la conséquence naturelle de l'exploitation d'une couche de collecte à une échelle où la fiabilité prévisible compte plus que le débit brut.
Remplacer uniquement la couche de collecte
La plateforme analytique n'a jamais été le problème. L'ingestion, la normalisation, l'enrichissement et le reporting traitaient déjà confortablement de gros volumes de données de places de marché et de réservation. Ce qui ne suivait plus, c'était la couche chargée de récupérer ces informations sur le web public.
L'équipe a donc isolé le goulot d'étranglement et remplacé uniquement l'exécution des crawls. L'Enterprise Crawler a pris en charge tout ce qu'il faut pour récupérer des données web de manière fiable à grande échelle :
- Le routage des requêtes.
- L'infrastructure de proxy datacenter et résidentiels rotatifs.
- Le rendering JavaScript pour les pages dynamiques.
- Les retries automatiques et la reprise après échec.
- La résilience réseau.
- La gestion anti-bot sur les places de marché prises en charge.
Tout ce qui vient après la collecte est resté exactement en l'état. Une fois la page récupérée par Crawlbase, le pipeline existant du client la faisait passer par la validation, la normalisation, l'enrichissement et l'analytique, sans le moindre changement.
Séparer la collecte du traitement en aval a simplifié l'architecture. Crawlbase a absorbé la complexité opérationnelle de l'exécution des requêtes, de la rotation des proxies, des retries, du rendering et de la résilience anti-bot, tandis que l'infrastructure du client restait concentrée sur la transformation des données web brutes en intelligence de marché.
Cette séparation a aussi permis à chaque couche d'évoluer à son propre rythme. À mesure que le volume de crawl augmentait, améliorer la collecte n'imposait plus de modifier le parsing, le stockage ou l'analytique. Ce sont les principes que nous détaillons dans notre guide de l'architecture de web scraping à grande échelle, appliqués à une charge de production.
Monter en charge vers un milliard de requêtes par mois
Le meilleur test d'une infrastructure de crawl reste son comportement quand la charge augmente. Beaucoup de systèmes gèrent bien un trafic modéré, puis réclament une refonte architecturale dès que le volume grimpe.
Sur les six mois observés, le volume mensuel de requêtes réussies est passé d'environ 687 millions en novembre 2025 à un pic de 1.04 milliard en mars 2026, soit une hausse d'environ 51%. Avril s'est clôturé à 990.7 millions, encore 44% au-dessus du point de départ de la période. La tendance sur l'ensemble de la période équivaut à environ +52.6 millions de requêtes par mois.
| Mois | Requêtes réussies | Taux de succès |
|---|---|---|
| Nov. 2025 | 686.7M | 100.00% |
| Déc. 2025 | 889.8M | 100.00% |
| Janv. 2026 | 1,015.8M | 100.00% |
| Févr. 2026 | 894.8M | 99.98% |
| Mars 2026 | 1,037.5M | 99.78% |
| Avr. 2026 | 990.7M | 100.00% |
Sur l'ensemble de la fenêtre, cela représente 5.52 milliards de requêtes réussies, une moyenne de 919 millions par mois et environ 30.6 millions par jour. Notez la distinction entre les deux chiffres quotidiens : environ 33 millions de requêtes par jour correspondent au coût d'un cycle de rafraîchissement complet à couverture totale, tandis que 30.6 millions est la moyenne quotidienne mesurée sur six mois de trafic réel.
Ces chiffres ne parlent pas que de débit. Chaque crawl réussi alimente les systèmes de parsing, d'enrichissement et d'analytique qui produisent les tendances d'occupation, l'intelligence tarifaire, les calendriers de disponibilité, l'ADR, le RevPAR et les comparatifs concurrentiels sur des millions de biens surveillés. La tendance montre une couche de collecte qui absorbe une charge supplémentaire sans devenir le facteur limitant, et sans refonte du pipeline en aval.
Fiabilité sous charge soutenue
Monter en volume n'est que la moitié du problème. Une plateforme capable de traiter des milliards de requêtes n'est utile que si les résultats restent fiables pendant que la charge se déplace.
Sur ces mêmes six mois, le taux de succès est resté remarquablement stable malgré des variations importantes du trafic mensuel :
- 99.96% de taux de succès moyen des requêtes.
- Un taux de succès mensuel compris entre 99.78% et 100.00%, soit une amplitude de 0.22 point.
- Près d'un milliard de requêtes réussies par mois, à travers des profils de trafic changeants.
Le taux de succès se traduit directement en qualité analytique. Chaque requête aboutie est une donnée de place de marché supplémentaire qui peut être validée, parsée, enrichie et intégrée aux modèles d'occupation, aux référentiels de prix, aux calendriers de disponibilité et aux dashboards de prévision. Les échecs laissent des trous, et les trous réduisent à la fois la fraîcheur et l'exhaustivité.
L'observation la plus utile tient au peu de variation de la fiabilité alors que le débit progressait de plus de 50%. La couche de collecte n'a pas échangé de la stabilité contre du volume. Pour une plateforme analytique rafraîchie en continu, cette régularité vaut souvent plus qu'un pic plus élevé, car terminer chaque cycle de collecte dans les délais est ce qui permet aux systèmes en aval de traiter des données fraîches au lieu de compenser le bruit de l'infrastructure.
Impact opérationnel
Comme chaque système en aval dépendait de l'arrivée à l'heure des données de places de marché, les améliorations au stade de la collecte se sont propagées à tout le pipeline.
Des pipelines de données plus fiables
Le changement immédiat a été la régularité. Les jobs de crawl se terminaient de façon prévisible sur Airbnb, Vrbo, Booking.com et les places de marché régionales, si bien que les cycles de rafraîchissement tenaient dans leurs fenêtres de traitement, même avec un volume qui continuait de grimper.
En aval, l'ingestion, le parsing et la normalisation passaient moins de temps à compenser des lots retardés ou incomplets et plus de temps à traiter des données fraîches. Des rafraîchissements plus réguliers signifiaient des tendances d'occupation, des tarifs à la nuitée, un ADR, un RevPAR, des calendriers de disponibilité, des délais de réservation et des comparatifs concurrentiels plus à jour. Le résultat n'était pas simplement un scraping plus rapide ; c'était une business intelligence plus fiable.
Moins de charge opérationnelle
Déléguer la collecte a également réduit l'effort d'ingénierie nécessaire pour exploiter une infrastructure de scraping à grande échelle. Le temps consacré au diagnostic des échecs de crawl, à la gestion des proxies et à la reprise des jobs incomplets a été réinvesti dans l'élargissement de la couverture analytique et la prise en charge de nouveaux marchés.
À mesure que l'inventaire surveillé, l'adoption client et le volume de crawl augmentaient, la couche de collecte a continué de soutenir environ un milliard de requêtes mensuelles sans redevenir un problème d'ingénierie récurrent.
À retenir
Quatre principes issus de ce déploiement s'appliquent à toute organisation qui construit des systèmes de données web à grande échelle.
- Séparez la collecte du traitement en aval. La collecte, la transformation, le stockage et l'analytique n'ont pas les mêmes caractéristiques de montée en charge. Les découpler permet à chacun d'évoluer indépendamment et réduit la complexité opérationnelle.
- Optimisez pour une complétion prévisible, pas pour le débit de pointe. Pour une plateforme rafraîchie en continu, terminer chaque cycle de façon fiable vaut mieux que des pics de performance occasionnels.
- Traitez la résilience anti-bot comme une infrastructure mutualisée. À l'échelle de l'entreprise, le routage, la gestion des proxies, les retries et le rendering sont des capacités de plateforme, pas des fonctionnalités de scrapers individuels.
- Mesurez la santé opérationnelle, pas seulement le volume. Le débit seul dit peu de chose. Les taux de succès, la régularité de complétion, le comportement des retries et la latence de rafraîchissement montrent si un pipeline livre réellement.
À mesure que les charges de travail atteignent les centaines de millions ou les milliards de requêtes, le succès dépend moins des scrapers individuels que du fait de traiter la collecte de données comme une infrastructure de production. Une couche de collecte qui passe à l'échelle permet aux équipes d'ingénierie de consacrer leur temps aux produits et aux analyses qui créent de la valeur, plutôt qu'aux crawlers qui les sous-tendent.
La couche de collecte managée derrière ce déploiement : routage des requêtes, proxies datacenter et résidentiels rotatifs, rendering JavaScript, retries automatiques et gestion anti-bot, livrés de façon asynchrone vers votre webhook ou votre Cloud Storage. Des milliards de requêtes par mois sans flotte de crawlers à exploiter. Parlez-nous de vos volumes entreprise, ou démarrez sur l'offre gratuite.
Questions fréquentes
Que représente concrètement un milliard de requêtes de crawl par mois ?
Pour cette plateforme, cela équivaut à environ 33 millions de requêtes par jour à couverture complète, pour rafraîchir les annonces, les calendriers, les tarifs et les disponibilités sur 6.15 millions d'annonces Airbnb, 1.85 million d'annonces Vrbo et l'inventaire complémentaire de Booking.com et des places de marché régionales. Sur six mois mesurés, cela a représenté 5.52 milliards de requêtes réussies, soit une moyenne de 919 millions par mois.
Pourquoi remplacer uniquement la couche de collecte plutôt que tout le pipeline ?
Parce que le reste du pipeline n'était pas le goulot d'étranglement. L'ingestion, la normalisation, l'enrichissement et le reporting absorbaient déjà le volume. Isoler l'exécution des crawls permettait à l'équipe de corriger la couche défaillante sans toucher au parsing, au stockage ni à l'analytique, et chaque couche pouvait ensuite évoluer à son propre rythme.
La fiabilité baisse-t-elle quand le volume de crawl augmente ?
Pas ici. Le volume mensuel a progressé de plus de 50% sur la période tandis que le taux de succès restait entre 99.78% et 100.00%, soit une bande de 0.22 point, pour une moyenne de 99.96%. Pour une analytique rafraîchie en continu, cette régularité compte plus que le débit de pointe, car une fenêtre de rafraîchissement manquée se traduit par des données de marché périmées.
Comment la gestion anti-bot est-elle assurée à cette échelle ?
Comme une infrastructure mutualisée, plutôt que comme une logique propre à chaque scraper. Le routage des requêtes, la rotation des proxies entre pools datacenter et résidentiels, le rendering JavaScript pour les pages dynamiques et les retries automatiques sont tous intégrés à l'Enterprise Crawler, si bien que les jobs de collecte individuels n'embarquent pas leur propre code de contournement et n'ont pas besoin d'être mis à jour chaque fois qu'une place de marché modifie ses défenses.
Que doivent mesurer les équipes pour savoir si leur couche de collecte est en bonne santé ?
Le taux de succès, la régularité de complétion, le comportement des retries et la latence de rafraîchissement, pas le volume de requêtes seul. Le débit ne dit rien du respect des délais par les cycles de rafraîchissement. La bonne question est de savoir si chaque cycle se termine dans sa fenêtre avec un taux de succès stable.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.