Si vous parsez Wildberries, Ozon ou tout autre site en téléchargeant des pages HTML complètes, vous payez pour le trafic de proxy 5 à 10 fois plus que nécessaire. Chaque page de produit représente 200 à 800 Ko de balisage, de scripts et de styles, dont vous n'avez littéralement besoin que de quelques champs : prix, disponibilité, note. Dans cet article, nous expliquons comment trouver l'API cachée d'un site et obtenir les mêmes données directement, au format JSON compact.
Pourquoi le parsing HTML consomme du trafic proxy
Lorsque le parser charge une page via une requête HTTP classique ou via un navigateur sans tête (Selenium, Puppeteer, Playwright), le serveur renvoie un document HTML complet : balisage, scripts en ligne, styles, parfois des images en base64 et des centaines de lignes de JSON avec des données pour des widgets publicitaires dont vous n'avez pas besoin. La fiche produit moyenne sur Wildberries pèse entre 300 et 600 Ko, sur Ozon jusqu'à 800 Ko, si l'on compte toutes les ressources associées (CSS, polices, trackers).
Si vous surveillez 10 000 produits par jour via 3 sessions proxy, cela peut facilement se traduire par des dizaines de gigaoctets de trafic par mois. Les proxies résidentiels et mobiles sont généralement vendus par trafic, donc chaque mégaoctet supplémentaire représente des coûts directs. En revanche, les données réelles dont vous avez besoin — prix, remise, stock, note — occupent dans la réponse JSON 1 à 5 Ko. La différence de volume est de 100 à 200 fois par produit, et en tenant compte des frais généraux de rendu du navigateur, l'économie de temps et de CPU est encore plus importante.
Un problème supplémentaire du parsing HTML est sa fragilité. Les sites de marketplaces changent régulièrement leur mise en page, les classes CSS, la structure DOM. Chaque changement casse le parser basé sur XPath ou des sélecteurs CSS. L'API interne change beaucoup moins souvent, car elle est essentielle au fonctionnement de l'application mobile et du frontend du site en même temps.
Qu'est-ce qu'une API cachée et d'où vient-elle
Presque chaque site moderne est une SPA (Single Page Application) ou une application hybride, où le navigateur charge d'abord le "squelette" de la page, puis effectue des requêtes supplémentaires via JavaScript à l'API interne pour obtenir des données réelles : prix, stocks, avis, recommandations. Ces requêtes sont appelées API cachées ou internes — elles ne sont pas documentées publiquement, mais sont complètement ouvertes dans le trafic du navigateur.
Techniquement, il s'agit généralement de points de terminaison REST ou GraphQL qui renvoient des données au format JSON. Par exemple, chez Wildberries, la fiche produit est chargée via des requêtes de type card.wb.ru et wbx-content-v2.wbstatic.net, tandis que les prix et les stocks sont obtenus via une requête distincte sur basket-01.wb.ru et des domaines similaires. Pour Ozon, la logique est similaire : le frontend interroge l'API interne de composition, qui agrège les données des microservices.
Il est important de comprendre : l'utilisation de cette API n'est formellement pas considérée comme un piratage — vous répétez simplement les mêmes requêtes qu'un navigateur classique. Mais les sites protègent ces points de terminaison par des systèmes anti-bot, donc il est nécessaire d'imiter soigneusement le comportement d'un client réel, y compris via des proxies de qualité.
Comment trouver une API cachée via DevTools
Trouver l'API interne peut se faire sans une seule ligne de code, en utilisant les outils intégrés du navigateur Chrome ou Firefox. Voici un algorithme étape par étape :
- Ouvrez la page produit souhaitée dans Chrome, appuyez sur F12 et allez dans l'onglet Network.
- Dans le filtre des requêtes, choisissez le type Fetch/XHR — cela vous permettra d'éliminer le chargement des images, des polices et des fichiers statiques.
- Rafraîchissez la page (F5) et regardez la liste des requêtes qui apparaissent après le chargement du squelette de la page.
- Trouvez la requête dont la réponse (onglet Response) montre le prix du produit, le nom ou d'autres champs nécessaires au format JSON.
- Cliquez sur cette requête et copiez-la comme cURL (clic droit → Copier → Copier en tant que cURL) — cela vous donnera l'ensemble complet des en-têtes, cookies et paramètres.
- Vérifiez quels paramètres dans l'URL sont obligatoires (référence du produit, région, version de l'API), et lesquels peuvent être supprimés sans perte de données.
Après cela, il suffit de répéter cette requête via une bibliothèque HTTP classique, en remplaçant la référence ou l'ID du produit au lieu de rendre toute la page. Cela fonctionne pour la plupart des marketplaces — Wildberries, Ozon, Avito, ainsi que pour de nombreuses plateformes étrangères comme Amazon et eBay.
Comparaison du trafic : HTML vs JSON API
La différence de volume de données est si grande qu'il vaut la peine de la montrer en chiffres. Ci-dessous, des mesures moyennes pour une fiche produit sur des marketplaces populaires.
| Méthode de parsing | Taille moyenne de la réponse | Temps de chargement | Rendu JS nécessaire |
|---|---|---|---|
| HTML complet via Selenium | 400-800 Ko | 1.5-4 sec | Oui |
| Requête HTTP simple (requests) | 150-300 Ko | 0.3-0.8 sec | Non |
| API JSON cachée | 3-15 Ko | 0.1-0.3 sec | Non |
Lors de la surveillance de 50 000 produits par jour, le passage d'un navigateur sans tête à des requêtes directes vers l'API réduit le trafic d'environ 30-40 Go à 300-700 Mo par mois. Cela représente non seulement des économies sur le trafic proxy, mais aussi une réduction de la charge sur l'infrastructure serveur du parser — moins de CPU pour le rendu, moins de mémoire, plus rapide pour la collecte des données.
Exemple pratique en Python
Considérons un exemple simplifié : obtenir le prix et le stock d'un produit via une requête directe à l'API interne au lieu de charger la page complète. C'est un modèle d'apprentissage — les points de terminaison et les paramètres exacts doivent être déterminés via DevTools pour un site spécifique, car la structure des requêtes peut varier en fonction de la région et de la version de l'API.
import requests
def get_product_data(product_id: str, proxies: dict = None) -> dict:
"""
Obtient les données du produit via l'API interne au lieu du HTML complet.
proxies — dictionnaire avec les proxies au format requests : {"http": "...", "https": "..."}
"""
url = f"https://card.example-marketplace.ru/v2/detail"
params = {
"nm": product_id,
"dest": "-1257786", # région, déterminée via DevTools
"spp": "0"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0 Safari/537.36",
"Accept": "application/json",
"Referer": f"https://www.example-marketplace.ru/catalog/{product_id}/detail.aspx"
}
response = requests.get(
url,
params=params,
headers=headers,
proxies=proxies,
timeout=10
)
response.raise_for_status()
data = response.json()
product = data["products"][0]
return {
"id": product["id"],
"name": product["name"],
"price": product["salePriceU"] / 100,
"stock": product.get("totalQuantity", 0),
"rating": product.get("reviewRating", None)
}
if __name__ == "__main__":
proxy = {
"http": "http://user:pass@proxy-host:port",
"https": "http://user:pass@proxy-host:port"
}
result = get_product_data("123456789", proxies=proxy)
print(result)
Notez trois points dans cet exemple. Premièrement, nous spécifions l'en-tête Referer, car de nombreuses API vérifient que la requête provient "d'un navigateur", et non directement par URL. Deuxièmement, nous utilisons un User-Agent réaliste, et non le défaut de la bibliothèque requests, qui est facilement détectable. Troisièmement, toute la requête s'effectue en un seul appel HTTP sans rendu — c'est ce qui permet un gain significatif en trafic et en vitesse.
Pour les points de terminaison GraphQL, la logique est similaire, mais au lieu de paramètres GET, vous envoyez une requête POST avec un corps de requête au format JSON, où vous énumérez explicitement les champs nécessaires — cela réduit encore le volume de la réponse, car le serveur ne renvoie que les données demandées.
Travail avec des proxies lors des requêtes API
Même en passant au format JSON compact, vous avez toujours besoin de proxies — les marketplaces limitent le nombre de requêtes d'une seule IP et bloquent en cas d'activité anormale. Le choix correct du type de proxy a un impact direct sur la stabilité du parser.
Pour le contournement massif des API des marketplaces comme Wildberries ou Ozon, les proxies de datacenter conviennent bien — ils offrent une grande vitesse et un faible coût de trafic, ce qui est critique lors de requêtes fréquentes vers des points de terminaison JSON légers. Mais si une API spécifique est protégée par un anti-bot plus strict et bloque complètement les sous-réseaux de datacenter, il est plus judicieux de passer à des proxies résidentiels — ils utilisent de vraies adresses IP d'utilisateurs domestiques et sont moins souvent bloqués par sous-réseau.
Pour les API liées aux applications mobiles (certaines versions des points de terminaison Avito ou des marketplaces ne renvoient des données que sur le trafic mobile), il peut être nécessaire de se connecter via des proxies mobiles — ils imitent le trafic des véritables opérateurs de téléphonie mobile et passent les vérifications qui bloquent les IP classiques.
Lors de la configuration des proxies dans le parser, il est également important de répartir les requêtes dans le temps et d'utiliser la rotation des IP — même une requête JSON compacte répétée 1000 fois par minute depuis une seule adresse suscitera des soupçons auprès du système de protection. Configurez un pool de plusieurs sessions proxy et répartissez la charge entre elles, en ajoutant des délais aléatoires de 1 à 3 secondes entre les requêtes.
Pièges : tokens, signatures, anti-bot
Les API cachées ne sont pas toujours totalement ouvertes. Certains sites protègent leurs points de terminaison par des mécanismes supplémentaires qu'il faut prendre en compte lors de la construction du parser.
- Tokens de session temporaires — certaines API nécessitent une requête préalable pour obtenir un token, qui est ensuite transmis dans l'en-tête des requêtes suivantes et a une durée de vie limitée (généralement 5 à 30 minutes).
- Signature de la requête — les paramètres de la requête sont hachés côté client avec une clé secrète provenant du code JS de la page. Cette signature doit être soit reproduite manuellement en décomposant l'algorithme, soit exécutée via un navigateur sans tête uniquement lors de l'obtention du token, et ensuite envoyer des requêtes légères directement.
- Limitation de fréquence par IP et par User-Agent — en cas de dépassement de la fréquence des requêtes, le site bloque temporairement l'accès. Cela se résout par la rotation des proxies et des délais raisonnables.
- Fingerprinting des en-têtes — certains systèmes vérifient l'ensemble complet des en-têtes (ordre, présence de Accept-Language, Sec-Fetch-*) et bloquent les requêtes avec un ensemble "incomplet", caractéristique des scripts plutôt que des navigateurs.
- Dépendance géographique des données — les prix et les stocks sur les marketplaces peuvent varier selon les régions, il est donc important de transmettre le bon paramètre de région/entrepôt dans la requête, sinon les données seront non pertinentes.
Si l'API est protégée par une signature de requête difficile à reproduire, une option de compromis consiste à utiliser un navigateur sans tête (Playwright, Puppeteer) uniquement pour intercepter les requêtes réseau et extraire la réponse JSON prête, sans parser le DOM. C'est plus lent qu'une requête HTTP directe, mais reste encore plus rapide et plus léger qu'un parsing complet de la mise en page de la page.
Checklist avant de lancer le parser sur l'API cachée
- Point de terminaison trouvé via DevTools, copié comme cURL et testé dans Postman ou via requests.
- Paramètres obligatoires de la requête (ID produit, région, version de l'API) définis et les paramètres superflus exclus.
- En-têtes User-Agent, Referer et Accept-Language configurés de manière réaliste.
- Vérifié si un token de session ou une signature de requête est nécessaire, et pensé à la manière de les obtenir.
- Rotation des proxies et délais aléatoires entre les requêtes configurés.
- Type de proxy approprié choisi en fonction de la protection spécifique du site — datacenter, résidentiels ou mobiles.
- Gestion des erreurs 429 et 403 ajoutée avec basculement automatique vers un autre proxy.
- Journalisation du volume de trafic configurée pour contrôler les économies réelles.
Conclusion
Passer du parsing du HTML complet à l'utilisation d'une API cachée n'est pas seulement une optimisation technique, mais une réduction directe des coûts de trafic proxy et d'infrastructure. Au lieu de charger des centaines de kilo-octets de balisage superflu, vous obtenez un JSON compact avec exactement les champs nécessaires pour surveiller les prix, les stocks ou les notes. Un bonus supplémentaire — la résistance du parser aux changements de mise en page du site, car les API internes changent moins souvent que le frontend.
Cependant, la méthode de recherche d'API ne supprime pas la nécessité d'avoir des proxies de qualité — les systèmes anti-bot des marketplaces surveillent de manière égale les requêtes HTML et les appels aux points de terminaison JSON. Si vous surveillez Wildberries ou Ozon en grande quantité, commencez par des proxies de datacenter rapides pour réduire les coûts, et dès les premiers signes de blocage, passez à des pools IP résidentiels ou mobiles pour un fonctionnement plus stable du parser.