Les prix sur un marché bougent constamment, et une seule consultation de page ne vous dit que ce que quelque chose coûte en ce moment. La veille tarifaire est la discipline qui transforme cette cible mouvante en données structurées que vous pouvez suivre : extraire les prix des concurrents et des marchés depuis les pages de produits publiques, les normaliser en lignes propres, les stocker dans le temps, et lire la tendance. Ce guide vous montre comment utiliser le web scraping pour la veille tarifaire de bout en bout, avec du Python exécutable que vous pouvez pointer sur de vraies annonces dès aujourd'hui.
Pour rester honnête, tout le tutoriel porte sur des données de produits publiques : noms, prix, devises et URLs d'annonces que tout le monde peut voir sans se connecter. Il ne touche pas aux comptes utilisateurs, aux pages protégées par connexion, aux actions de paiement ni aux données personnelles. Une courte note sur les CGU vers la fin n'est pas du remplissage, alors lisez-la avant d'exécuter ceci à grande échelle.
Ce que la veille tarifaire nécessite réellement
Il est tentant de réduire cela à "scraper un prix". En pratique, un système de veille tarifaire utile a quatre tâches, et le scraping n'est que la première.
- Collecter les prix depuis les pages publiques qui vous intéressent, de façon suffisamment fiable pour s'exécuter selon un calendrier.
- Normaliser les valeurs brutes désordonnées (symboles monétaires, séparateurs de milliers, prix "à partir de") en nombres propres.
- Stocker chaque observation avec un horodatage pour avoir un historique, pas seulement un instantané.
- Analyser l'historique : comparer entre sources, calculer des moyennes, et signaler les mouvements à surveiller.
C'est la même forme de problème que tout travail de scraping e-commerce. La différence avec la veille tarifaire est que la valeur réside dans la série temporelle, donc la collecte doit être reproductible et les données doivent atterrir quelque part où vous pouvez les interroger ensuite.
Pourquoi la collecte est la partie difficile
Si vous pointez un client HTTP brut sur la page de recherche d'un grand marché, vous obtenez généralement l'un de deux résultats décevants : une réponse 200 avec presque aucune donnée de produit dans le corps, ou un blocage. Deux choses jouent contre vous. De nombreux marchés rendent leurs annonces dans le navigateur avec JavaScript, donc le HTML initial est une coquille qui ne se remplit qu'après l'exécution des scripts. Et ils signalent rapidement le trafic automatisé : les IPs de datacenter et les patterns de requêtes qui ne ressemblent pas à un vrai navigateur sont mis au défi avant même d'avoir vu le contenu rendu.
Une collecte fiable nécessite donc deux choses dans une seule requête : un moteur de rendu pour les pages côté client, et une IP que la plateforme interprète comme un vrai visiteur. Vous pouvez assembler cela vous-même avec un navigateur headless plus un pool de proxys résidentiels, mais maintenir cette flotte en bonne santé représente la majorité du travail. La Crawling API intègre les deux dans un seul appel. Pour les grands marchés, elle livre également des parseurs prêts à l'emploi, donc vous pouvez vous passer d'écrire des sélecteurs entièrement.
La Crawling API retourne le HTML rendu brut pour toute URL, que vous analysez ensuite vous-même. La Crawling API et les scrapers intégrés à la Crawling API vont un cran plus loin : pour les sites pris en charge comme Amazon et eBay, ils retournent du JSON propre, donc il n'y a aucun parsing HTML à maintenir. Ce guide utilise les scrapers intégrés pour la collecte et revient au HTML brut quand une cible n'est pas prise en charge.
Configurer le projet
Vous avez besoin de Python 3 installé. Créez un répertoire, puis installez les quatre bibliothèques utilisées dans ce tutoriel : requests pour HTTP, price_parser pour normaliser les chaînes monétaires, et pandas pour l'étape d'analyse.
mkdir price-intelligence && cd price-intelligence python -m venv .venv && source .venv/bin/activate pip install requests price_parser pandas
Vous avez aussi besoin d'un compte Crawlbase et d'un token API, que vous obtenez depuis le tableau de bord après inscription. Les nouveaux comptes bénéficient de requêtes gratuites, vous pouvez donc tout tester ci-dessous avant de vous engager à quoi que ce soit. Mettez le token partout où vous voyez YOUR_CRAWLBASE_TOKEN.
Collecter les prix d'un marché
Commencez par les pages de recherche que vous souhaitez suivre. Pour un produit comme un téléphone, une recherche Amazon et une eBay pour la même requête vous donnent deux sources concurrentes à comparer. Comme les deux sont prises en charge par les scrapers intégrés à la Crawling API, vous passez un paramètre scraper et obtenez du JSON de produits structurés en retour plutôt que du HTML.
import requests import urllib.parse API_TOKEN = "YOUR_CRAWLBASE_TOKEN" API_ENDPOINT = "https://api.crawlbase.com/" def collect(url, scraper, country="US"): params = { "token": API_TOKEN, "url": url, "scraper": scraper, "country": country, } resp = requests.get(API_ENDPOINT, params=params, timeout=90) resp.raise_for_status() return resp.json()["body"]["products"] def search_url(host, path, query): q = urllib.parse.quote_plus(query) return f"https://www.{host}/{path}{q}"
Le paramètre scraper fait le gros du travail : amazon-serp et ebay-serp indiquent à l'API de retourner des listes de produits analysées plutôt que du balisage brut. Le paramètre country achemine la requête via une IP dans cette région, ce qui compte car les prix et la disponibilité sont localisés. Un seul wrapper pilote désormais les deux sources.
def collect_amazon(query, country="US"): url = search_url("amazon.com", "s?k=", query) return collect(url, "amazon-serp", country) def collect_ebay(query, country="US"): url = search_url("ebay.com", "sch/i.html?_nkw=", query) return collect(url, "ebay-serp", country)
Chaque appel retourne une liste de dictionnaires de produits. La forme diffère selon la source (Amazon vous donne name et une chaîne price plate ; eBay imbrique le prix actuel sous price.current.to), ce qui est exactement la raison d'être de l'étape suivante.
Normaliser en une seule forme propre
Les données de prix brutes ne sont jamais prêtes pour l'analyse. Vous obtenez des symboles monétaires, des séparateurs de milliers, des plages "à partir de", et une disposition de champs différente par source. Normalisez à la capture pour que tout ce qui suit voie les mêmes colonnes : une source, un nom de produit, un prix numérique, une devise et l'URL de l'annonce. Normaliser une fois ici est ce qui garde le code de stockage et d'analyse simple.
from price_parser import Price def to_row(source, name, raw_price, url): parsed = Price.fromstring(raw_price or "") if parsed.amount is None: return None return { "source": source, "product": name.strip(), "price": float(parsed.amount), "currency": parsed.currency or "", "url": url, } def normalize(query, country="US"): rows = [] for item in collect_amazon(query, country): row = to_row("Amazon", item["name"], item.get("price"), item["url"]) if row: rows.append(row) for item in collect_ebay(query, country): raw = item["price"]["current"]["to"] row = to_row("eBay", item["title"], raw, item["url"]) if row: rows.append(row) return rows
price_parser gère l'analyse monétaire pour vous : il lit "£1 138,00" ou "$709.00" et retourne un montant propre et un code de devise, pour qu'un travail de comparaison de prix n'ait jamais à se soucier du symbole qu'une source a utilisé. Après cette étape, chaque observation se présente de la même façon quelle que soit sa provenance.
[ { "source": "Amazon", "product": "Apple iPhone 15 Pro Max 256GB", "price": 1138.0, "currency": "USD", "url": "https://www.amazon.com/dp/B0DGTJ6Y1S" }, { "source": "eBay", "product": "Apple iPhone 15 Pro Max 256GB Blue Titanium", "price": 709.0, "currency": "USD", "url": "https://www.ebay.com/itm/236096139018" } ]
La veille tarifaire repose ou s'effondre sur la fiabilité de la collecte. La Crawling API rend les pages côté client derrière des IPs résidentielles tournantes en un seul appel, et pour les grands marchés ses scrapers intégrés retournent du JSON de produits propre, vous évitant à la fois une flotte headless et la plupart de votre code de parsing. Pointez-la sur une page de recherche publique sur le niveau gratuit en premier.
Stocker chaque exécution avec un horodatage
Une liste normalisée unique est un instantané. La veille tarifaire porte sur la tendance, donc chaque exécution doit atterrir dans le stockage avec un horodatage attaché. Un CSV plat avec une colonne captured_at ajoutée est suffisant pour commencer, et il se charge directement dans pandas ou un tableur ensuite.
import csv, os from datetime import datetime, timezone FIELDS = ["captured_at", "source", "product", "price", "currency", "url"] def store(rows, path="price_history.csv"): stamp = datetime.now(timezone.utc).isoformat() new_file = not os.path.exists(path) with open(path, "a", newline="") as f: writer = csv.DictWriter(f, fieldnames=FIELDS) if new_file: writer.writeheader() for row in rows: writer.writerow({"captured_at": stamp, **row}) if __name__ == "__main__": rows = normalize("Apple iPhone 15 Pro Max 256GB", country="US") store(rows) print(f"stored {len(rows)} rows")
Exécutez cela selon un calendrier (une tâche cron toutes les quelques heures, ou horaire si votre niveau le permet) et price_history.csv se transforme en vraie série temporelle. Quand vous dépassez un fichier plat, écrivez les mêmes lignes dans une table de base de données à la place ; la forme normalisée signifie que rien d'autre ne change. Si vous collectez sur de nombreux produits et régions, le Crawler asynchrone vous permet de pousser de grands lots d'URLs et de recevoir les résultats via webhook plutôt que de bloquer sur chaque requête.
Analyser : comparer les sources et repérer les mouvements
Avec l'historique sur disque, l'analyse est courte. Chargez le CSV dans pandas, regroupez par source, et comparez. Voici la question classique de veille tarifaire : pour un produit donné, où est-il moins cher en ce moment, et de combien ?
import pandas as pd df = pd.read_csv("price_history.csv", parse_dates=["captured_at"]) # Latest run only, for a head-to-head comparison latest = df[df["captured_at"] == df["captured_at"].max()] by_source = latest.groupby("source")["price"].agg(["mean", "min", "count"]).round(2) print(by_source) # Day-over-day move per source, from the stored history daily = df.set_index("captured_at").groupby("source")["price"] trend = daily.resample("D").mean().round(2) print(trend.pct_change().round(3))
Le premier bloc vous dit qui est moins cher aujourd'hui ; le second transforme votre historique stocké en tendance quotidienne et en variation en pourcentage, ce qui est le signal sur lequel vous agissez réellement. Une baisse sous un seuil peut déclencher une alerte ; une hausse régulière vous indique que le marché bouge et que votre propre tarification mérite peut-être un examen. Tout ici est du pandas ordinaire car le travail difficile a eu lieu en amont dans la collecte et la normalisation.
En option : ajouter de l'IA par-dessus
Vous n'avez pas besoin de machine learning pour faire de la veille tarifaire, mais deux problèmes deviennent plus simples avec lui une fois que vous collectez à grande échelle.
Le premier est la correspondance de produits. Le même article est titré différemment sur chaque site ("iPhone 15 Pro Max 256GB" vs "Apple iPhone 15 Pro Max (256 Go) Titane Bleu"), donc comparer les mêmes choses signifie regrouper les annonces qui font référence au même produit. Intégrer les titres et regrouper par similarité fait cela bien mieux que la correspondance de chaînes, et c'est la différence entre une vraie comparaison et du bruit.
Le second est la détection d'anomalies. Sur un historique suffisamment long, la plupart des mouvements de prix sont des variations saisonnières normales. Une statistique glissante simple (signaler toute observation à plus de quelques écarts-types de la moyenne glissante d'un produit) détecte les véritables événements, une baisse soudaine ou une erreur de tarification, sans que vous regardiez un tableau de bord. Commencez par cette règle ; recourez à un modèle seulement quand la version simple cesse d'être suffisante.
Rester non bloqué à grande échelle
Même avec le rendu et les IPs gérés par l'API, quelques habitudes maintiennent une tâche de collecte récurrente en bonne santé, et elles s'appliquent à toute cible commerciale difficile.
- Espacez vos requêtes. Le débit par défaut de la Crawling API est généreux pour l'e-commerce, mais envoyer en rafale la même recherche dans une boucle serrée attire quand même la limitation. Étalez les exécutions et variez vos requêtes. Si vous commencez à voir des 429, c'est le signal de limitation.
- Appuyez-vous sur la rotation. Un pool de proxys résidentiels répartit les requêtes sur de nombreuses IPs d'utilisateurs réels pour qu'aucune adresse ne déclenche une limite. L'API fait cela pour vous ; si vous construisez votre propre stack, c'est la partie sur laquelle investir. Le Smart AI Proxy expose la même rotation comme un endpoint de proxy standard si vous préférez cette intégration.
- Lisez les codes d'état. Les requêtes échouées ne vous sont pas facturées, donc un crawl raté est peu coûteux à réessayer. Une exécution qui commence à retourner des défis vous signale que le niveau actuel n'est plus suffisant.
Pour le guide complet, consultez how to scrape websites without getting blocked. Si votre collecte dépasse quelques produits pour atteindre des milliers de références dans plusieurs régions, large-scale e-commerce scraping couvre l'architecture pour ce volume.
La partie honnête : CGU et données publiques
Scraper un grand marché commercial se situe dans une zone grise légale, et la permission dépend des conditions d'utilisation de la plateforme, de votre juridiction et de ce que vous faites des données. La plupart des conditions des marchés restreignent l'accès automatisé, donc la collecte peut aller à l'encontre de ces conditions peu importe la prudence de vos outils. Aucun code ici ne change cela ; il fait simplement fonctionner la partie technique.
Quelques lignes à respecter. Collectez uniquement des données publiques : noms de produits, prix, devises et URLs d'annonces que tout le monde peut voir sans compte. Respectez le fichier robots.txt de chaque site et ses attentes en matière de débit, et gardez votre volume assez bas pour ne pas surcharger les serveurs de quiconque. Ne collectez jamais de données personnelles, y compris tout ce qui est lié aux comptes de vendeurs ou d'acheteurs individuels. Et si vous prévoyez de réutiliser les données commercialement, obtenez une permission ou un accord officiel de données plutôt de supposer que le silence vaut consentement. Ce guide est limité aux données d'annonces publiques exprès, car c'est la limite qui rend le travail défendable.
Points clés
- La veille tarifaire est quatre tâches, pas une. Collecter, normaliser, stocker avec un horodatage, puis analyser. Le scraping n'est que la première étape.
- Une collecte fiable nécessite un rendu et une IP de confiance. La Crawling API fait les deux en un seul appel, et ses scrapers intégrés retournent du JSON propre pour les marchés pris en charge, donc il n'y a aucun parsing HTML à maintenir.
- Normalisez à la capture. Analysez les chaînes monétaires en nombres une seule fois, dans une seule forme, et chaque étape de stockage et d'analyse reste simple.
-
La valeur est la série temporelle. Ajoutez chaque exécution avec un horodatage
captured_atpour pouvoir lire les tendances et les mouvements jour après jour, pas seulement un instantané. - L'IA est une finition optionnelle. Les embeddings aident à faire correspondre le même produit entre sites ; une règle statistique glissante signale les vraies anomalies de prix. Recourez à eux seulement quand la version simple cesse de passer à l'échelle.
- Restez sur les données publiques. Respectez les CGU et robots.txt ; pas de comptes, pas de données personnelles.
Foire aux questions
Qu'est-ce que le web scraping pour la veille tarifaire ?
C'est la pratique de collecter automatiquement les prix depuis les pages de produits publiques, de les normaliser en nombres propres et de les suivre dans le temps pour comparer les concurrents et repérer les mouvements du marché. Le scraping collecte les observations brutes ; l'intelligence vient du stockage d'une série temporelle et de l'analyse de la tendance plutôt que de la lecture d'un seul instantané.
Dois-je analyser le HTML pour collecter les prix ?
Pas pour les grands marchés. Les scrapers intégrés à la Crawling API (et la Scraper API) retournent du JSON de produits analysé pour les sites pris en charge comme Amazon et eBay, vous évitant entièrement les sélecteurs. Vous ne retombez sur l'analyse du HTML brut que quand un site cible n'est pas couvert, auquel cas l'API vous remet quand même la page rendue sur laquelle travailler.
À quelle fréquence dois-je collecter les prix ?
Cela dépend de la vitesse d'évolution de votre marché et de votre budget de requêtes. Toutes les heures est largement suffisant pour la plupart des catalogues ; les catégories à évolution rapide peuvent vouloir plus, les plus lentes moins. Quelle que soit la cadence, ajoutez chaque exécution avec un horodatage pour construire un vrai historique. Espacez les requêtes et variez les requêtes pour qu'une tâche récurrente ne ressemble pas à une attaque en rafale.
Comment comparer le même produit entre différents sites ?
Les titres diffèrent sur chaque marché, donc la correspondance exacte de chaînes échoue. Normalisez chaque annonce dans les mêmes champs à la capture, puis faites correspondre les produits par similarité plutôt que par texte identique. Pour quelques références, un mappage manuel fonctionne ; à grande échelle, intégrer les titres et regrouper par similarité est l'approche fiable.
Vais-je me faire bloquer en collectant des prix à grande échelle ?
C'est possible, si vous envoyez du trafic de type scraper depuis une seule IP. Gardez le débit par IP faible, variez vos paramètres de recherche, et acheminez via des IPs résidentielles tournantes pour qu'aucune adresse ne déclenche une limite. La Crawling API et Smart AI Proxy gèrent la rotation et un pool d'IPs de confiance pour vous ; si vous construisez votre propre stack, c'est la partie dans laquelle investir. Les requêtes échouées ne vous sont pas facturées, donc réessayer un crawl bloqué est peu coûteux.
Est-il légal de scraper les prix pour la veille tarifaire ?
Cela dépend des conditions d'utilisation de la cible, de votre juridiction et de votre objectif, et la plupart des conditions des marchés restreignent l'accès automatisé. Restez strictement aux données d'annonces publiques (noms, prix, devises, URLs), respectez robots.txt et les attentes en matière de débit, et ne touchez jamais aux comptes ni aux données personnelles. Pour une réutilisation commerciale, obtenez une permission ou un accord officiel plutôt de vous fier à un scraper.
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.