La plupart des guides sur la construction d’un jeu de données par web scraping s’arrêtent à “écrire un scraper, sauvegarder les résultats.” C’est les 20% faciles. Les 80% difficiles, ceux qui déterminent si votre jeu de données est réellement utilisable, concernent tout ce qui entoure la récupération : s’assurer que vous avez collecté les bonnes lignes, qu’elles sont complètes, qu’elles sont à jour, et que les lacunes dans vos données sont aléatoires plutôt que systématiques.
Ce dernier point est celui qui ruine silencieusement les jeux de données, et c’est celui dont presque personne ne parle. Quand un scrape échoue sur 30% des pages, vous ne perdez pas 30% aléatoires de vos données. Vous perdez un certain 30%, la tranche la plus difficile à atteindre, la plus protégée, la plus soumise aux restrictions géographiques, et ce qui reste est un échantillon biaisé qui semble complet. Un modèle entraîné dessus, ou une décision prise à partir de lui, hérite de ce biais sans que personne ne s’en aperçoive.
Voici un guide pratique pour construire un jeu de données issu du web scraping qui tient la route : les étapes du pipeline, les dimensions de qualité qui comptent, et les cas où la couche proxy fait la différence entre un jeu de données représentatif et un jeu de données biaisé.
Ce que signifie réellement “un bon jeu de données”
Avant tout code, clarifiez ce que vous cherchez à optimiser. Un jeu de données construit à partir du scraping est évalué sur cinq critères :
Complétude. Avez-vous tout collecté dans le périmètre défini, ou seulement les parties qui n’ont pas résisté ? Les lignes manquantes sont mauvaises ; les lignes systématiquement manquantes sont pires.
Représentativité. L’échantillon correspond-il à la population réelle ? Si vous scrapez des prix de produits mais que votre scraper est bloqué sur les grands distributeurs à fort trafic et passe sans problème sur les petits, votre “prix moyen” est faux dans une direction que vous ne pouvez pas voir.
Fraîcheur. Les données web se dégradent. Un jeu de données de prix du mois dernier est un jeu de données différent de celui d’aujourd’hui. Vous devez savoir à quel point chaque ligne est obsolète, et avoir un plan pour la rafraîchir.
Cohérence. Chaque ligne doit suivre le même schéma, avec les mêmes unités, formats et encodages. Le scraping extrait des données depuis du HTML désordonné, donc la normalisation représente la moitié du travail.
Provenance. Pour chaque ligne : d’où elle vient (URL source), quand vous l’avez récupérée, et depuis où (géo). Sans provenance, vous ne pouvez pas déboguer, dédupliquer, rafraîchir ni défendre le jeu de données ultérieurement.
Gardez ces cinq critères à l’esprit, car chaque décision de pipeline ci-dessous est au service de l’un d’eux.
Le pipeline, étape par étape
Un pipeline scraping-vers-jeu-de-données comprend six étapes. Traitez-les comme des étapes distinctes avec leur propre validation, et non comme un seul grand script.
1. Découverte. Énumérez les URLs dans le périmètre, à partir d’un sitemap, d’un crawl de recherche ou de listing, d’un index API, ou d’une plage d’identifiants connue. Cette étape définit votre population cible. Notez-la explicitement ; c’est votre référence pour évaluer la complétude par la suite.
2. Récupération. Récupérez chaque URL. C’est là que se produisent les blocages, les redirections géographiques, les limitations de débit et les timeouts, et c’est là que naît le biais du jeu de données. Nous y reviendrons, car c’est l’étape qui compte le plus pour la qualité.
3. Extraction. Analysez la réponse pour en extraire des champs structurés. Soyez défensif : les mises en page changent, des champs disparaissent, et un sélecteur fragile se transforme silencieusement en valeurs nulles sur des milliers de lignes.
4. Normalisation. Convertissez les valeurs brutes extraites en types et unités cohérents : devises vers une seule dénomination, dates en ISO, espaces supprimés, encodages corrigés, catégories mappées vers un vocabulaire contrôlé.
5. Déduplication. La même entité apparaît souvent à plusieurs URLs (canonique + variantes, doublons paginés, éléments re-listés). Déduplication sur une clé stable, pas sur l’URL.
6. Stockage et rafraîchissement. Persistez avec une provenance complète, puis définissez une cadence de re-crawl pour que le jeu de données reste à jour plutôt que de se dégrader en un instantané unique.
L’étape qui détermine la qualité : la récupération
Voici l’argument central de tout cet article. La qualité de votre jeu de données est plafonnée à l’étape de récupération, car une requête bloquée ne perd pas seulement des données, elle perd des données non aléatoires.
Trois mécanismes transforment les échecs de récupération en biais du jeu de données :
Biais de blocage. Les systèmes anti-bot (Cloudflare, Akamai, DataDome) protègent les cibles à forte valeur et à fort trafic de manière la plus agressive. Si votre scraper tourne depuis une IP de datacenter et se fait bloquer sur celles-ci, votre jeu de données manque systématiquement des lignes les plus importantes tout en conservant les plus faciles. Le résultat penche vers des sources plus petites et moins protégées, et il semble complet parce que vous avez quand même obtenu des milliers de lignes. (Voir pourquoi les scrapers se font bloquer pour les mécanismes.)
Biais géographique. De nombreux sites servent des contenus, des prix ou des disponibilités différents selon la localisation du visiteur, et redirigent ou localisent silencieusement en fonction de l’IP. Si toutes vos requêtes proviennent d’une seule région, chaque champ géo-variable de votre jeu de données reflète ce seul point de vue, et non la réalité mondiale que vous pensez avoir capturée. Scrapez “la disponibilité mondiale des produits” depuis un seul pays et vous avez en réalité capturé la vision d’un seul pays, mal étiquetée comme mondiale.
Biais de limitation de débit. Quand une cible vous ralentit, la réaction naïve est de ralentir ou d’abandonner les pages à réponse lente, qui sont souvent les plus lourdes et les plus riches en données. Vous finissez par sur-échantillonner les pages rapides et légères.
La solution pour ces trois problèmes est la même : récupérer via un pool d’IPs qui ressemblent à de vrais utilisateurs, dans les bonnes localisations, afin que la couverture soit complète et uniforme plutôt que biaisée vers ce qui était facile à atteindre.
Pourquoi la couche proxy est une décision de qualité des données, pas seulement de la plomberie
C’est pourquoi un réseau de proxies résidentiels est important spécifiquement pour la construction de jeux de données, au-delà du simple fait de “ne pas se faire bloquer” :
Couverture complète. Les IPs résidentielles portent le profil de confiance de vraies connexions grand public, ce qui leur permet de passer sur les cibles protégées qu’une IP de datacenter ne peut pas atteindre. Cela comble le fossé du biais de blocage : vous collectez les lignes difficiles, pas seulement les faciles.
Couverture géographique intentionnelle. Avec un ciblage par pays, état et ville, vous pouvez délibérément échantillonner chaque marché et étiqueter chaque ligne avec le point de vue depuis lequel elle a été obtenue. Au lieu d’un seul point de vue accidentel, vous obtenez un jeu de données multi-géo contrôlé où la géo est une colonne, pas un facteur confondant caché. C’est la différence entre “j’ai scrapé des prix” et “j’ai scrapé des prix tels qu’ils apparaissent depuis 12 marchés spécifiques, enregistrés par ligne.”
Échantillonnage uniforme à grande échelle. La rotation à travers un grand pool répartit les requêtes de sorte qu’aucune IP unique ne déclenche de limitations de débit, ce qui vous évite de sur-échantillonner les pages rapides et de sous-échantillonner les pages lentes et riches en données.
En clair : la couche proxy est l’endroit où vous décidez si votre jeu de données est un échantillon représentatif ou un échantillon de commodité. Pour le travail sur les jeux de données, ce n’est pas un détail de plomberie, c’est un choix méthodologique. (Pour une vue plus large de l’infrastructure, voir infrastructure proxy pour le machine learning.)
Fraîcheur : un jeu de données est un verbe, pas un nom
Un scrape unique est un instantané, et les instantanés se dégradent. Décidez dès le départ si vous construisez un jeu de données statique (acceptable pour une étude ponctuelle) ou un jeu de données vivant (nécessaire pour les prix, les stocks, les annonces, tout ce qui change).
Pour les jeux de données vivants :
- Définissez une cadence de re-crawl adaptée à la vitesse de changement des données : toutes les heures pour les prix volatils, chaque semaine pour les métadonnées de catalogue, chaque mois pour les données de référence à évolution lente.
- Faites des rafraîchissements incrémentiels, pas des re-scrapes complets. Détectez ce qui a changé (ETags, last-modified, hachages de contenu, différences de listing) et ne re-récupérez que cela. Plus économique, plus rapide, et moins contraignant pour la cible.
- Horodatez chaque ligne avec un timestamp de récupération afin que les consommateurs en aval puissent filtrer par récence et que vous puissiez mesurer l’obsolescence.
La fraîcheur est aussi un problème de couverture : si votre crawl de rafraîchissement se fait bloquer sur les mêmes pages protégées à chaque fois, ces lignes deviennent obsolètes tandis que les faciles restent à jour, réintroduisant le biais au fil du temps. Même solution.
Déduplication et normalisation, là où les jeux de données se gagnent ou se perdent
Les données scrapées brutes sont désordonnées. Deux étapes les nettoient :
Normaliser vers un schéma. Définissez d’abord le schéma cible, puis mappez chaque source vers lui. Devises vers une seule dénomination, dates en ISO 8601, nombres extraits des chaînes “1 299 unités”, texte nettoyé et normalisé en unicode, catégories alignées sur un vocabulaire contrôlé. Une normalisation incohérente est la raison la plus courante pour laquelle un jeu de données scrapé est techniquement complet mais analytiquement inutilisable.
Dédupliquer sur une clé stable, pas sur l’URL. Le même produit, la même personne ou le même enregistrement se retrouve régulièrement à plusieurs URLs. Construisez une clé de déduplication à partir de l’identité stable (SKU, ISBN, nom normalisé + localisation, URL canonique) et fusionnez les doublons en conservant la version la plus récente ou la plus complète. Dédupliquer sur l’URL brute seule vous laissera avec des comptages gonflés et des lignes doublement pondérées qui fausseront silencieusement tout agrégat.
Stocker avec provenance
Pour chaque ligne, stockez au minimum :
- L’URL source dont elle provient
- Le timestamp de récupération (UTC)
- Le point de vue géographique utilisé pour la requête (pays/ville), si la géo est pertinente pour les données
- Un hachage de contenu ou une version, afin de détecter les changements lors du re-crawl
- Le payload brut (ou une référence à celui-ci), séparé des champs analysés, afin de pouvoir re-analyser sans re-scraper quand votre extracteur s’améliore
La provenance semble être une surcharge jusqu’à la première fois où quelqu’un demande “d’où vient ce chiffre” ou que votre extracteur a un bug et que vous devez re-analyser 500 000 lignes sans toucher au réseau. Stockez-la dès le premier jour.
Valider le jeu de données avant de lui faire confiance
Avant que quiconque construise sur le jeu de données, effectuez des vérifications de couverture et de qualité : c’est ainsi que vous détectez le biais que l’étape de récupération peut introduire :
- Audit de couverture. Comparez les lignes collectées avec la population cible de l’étape de découverte. Un taux de complétion de 92% est acceptable ; la question est de savoir si les 8% manquants sont aléatoires. Vérifiez les échecs par sondage : s’ils se concentrent sur une source, une géo ou un type de site, vous avez un biais systématique à corriger, pas seulement des données manquantes.
- Vérification du taux de valeurs nulles par champ. Un champ soudainement nul à 40% signifie généralement un sélecteur cassé, pas des données absentes.
- Vérifications de cohérence des distributions. La distribution des prix, la répartition des catégories ou la répartition géographique correspondent-elles à ce que vous attendriez ? Un biais révèle souvent un problème d’échantillonnage en amont.
- Vérification de la fraîcheur. Quelle est la distribution d’âge des lignes ? Si un groupe est toujours obsolète, votre crawl de rafraîchissement y est bloqué.
Ces vérifications sont peu coûteuses et font la différence entre livrer un jeu de données et livrer un jeu de données faussement fiable.
Une note sur la responsabilité
Construire des jeux de données à partir du web implique de vraies obligations. Collectez uniquement des données publiques, respectez le robots.txt là où il est contraignant, respectez les limitations de débit et ne dégradez pas les sites que vous exploitez, évitez les données personnelles sauf si vous avez une base légale, et respectez les conditions d’utilisation de chaque cible. Un proxy change l’IP depuis laquelle une requête est émise, pas si vous devriez la faire. Notre politique d’utilisation acceptable est la référence pour ce qui est autorisé sur Shifter, et la collecte éthique de données mérite d’être lue avant de passer à l’échelle.
FAQ
Quelle est la partie la plus difficile de la construction d’un jeu de données par web scraping ? Pas le scraping, la couverture. Obtenir un échantillon complet et non biaisé est bien plus difficile que de récupérer des pages, car les requêtes échouées suppriment des tranches non aléatoires de données et le jeu de données résultant semble quand même complet. La plupart des problèmes de qualité des jeux de données remontent à l’étape de récupération.
Comment les blocages biaisent-ils un jeu de données scrapé ? Les systèmes anti-bot protègent les cibles à forte valeur de manière la plus agressive, donc un scraper qui se fait bloquer perd les lignes importantes et bien protégées tout en conservant les faciles. Le jeu de données penche vers des sources moins protégées, ce qui corrompt tout agrégat ou modèle construit dessus.
Ai-je besoin de proxies résidentiels pour construire un jeu de données ? Seulement si vos cibles bloquent les IPs de datacenter ou varient le contenu selon la géographie, ce que font la plupart des cibles de valeur. Pour les sources non protégées et géo-neutres, les IPs de datacenter conviennent. Pour une couverture complète et représentative des sites protégés ou localisés, les proxies résidentiels comblent le fossé du biais.
Comment maintenir un jeu de données scrapé à jour ? Définissez une cadence de re-crawl adaptée à la vitesse de changement des données, faites des rafraîchissements incrémentiels (détectez les changements via ETags, hachages ou différences plutôt que des re-scrapes complets), et horodatez chaque ligne avec un timestamp de récupération afin de pouvoir mesurer et filtrer par obsolescence.
Comment devrais-je dédupliquer des données scrapées ? Sur une clé d’identité stable (SKU, ISBN, URL canonique, nom normalisé + localisation), jamais sur l’URL brute, car la même entité apparaît à de nombreuses URLs. Fusionnez les doublons vers la version la plus récente ou la plus complète.
Que devrais-je stocker en plus des champs extraits ? La provenance : URL source, timestamp de récupération, point de vue géographique, un hachage de contenu pour la détection des changements, et idéalement le payload brut afin de pouvoir re-analyser sans re-scraper quand votre extracteur s’améliore.
En résumé
Construire un jeu de données avec le web scraping est un problème de qualité des données déguisé en problème de scraping. N’importe qui peut récupérer des pages ; le travail consiste à s’assurer que vous avez récupéré les bonnes pages, complètement, à jour, et sans un trou systématique là où devraient se trouver les cibles difficiles. Le pipeline, découverte, récupération, extraction, normalisation, déduplication, stockage, rafraîchissement, est simple. L’étape qui plafonne silencieusement votre qualité est la récupération, car c’est là que les blocages et la géo transforment des données manquantes en données biaisées.
Faites bien la couche de récupération et le reste n’est que de l’ingénierie. Si vos sources sont protégées ou géo-variables, un réseau de proxies résidentiels est ce qui transforme un échantillon de commodité en échantillon représentatif : couverture complète des cibles difficiles, échantillonnage multi-géo délibéré, et rotation uniforme à grande échelle. Quand vous êtes prêt à le mettre en place, le guide Python montre le code de l’étape de récupération, et la page de tarification présente les plans au Go. Construisez d’abord la couverture, et le jeu de données se construit de lui-même.