Réponse à David (Bright Data) — tests Web Unlocker Cardmarket

brightdata-reply-david.md

Re: Web Unlocker — premiers tests sur Cardmarket

Bonjour David,

Ravi d'échanger avec toi, et merci pour la mise en relation avec l'équipe commerciale (en copie).

Pour répondre à tes questions et faire un point sur les premiers tests :

Notre stack / notre besoin

On gère tout le parsing en interne. Ce qu'on cherche chez vous, c'est uniquement un moyen fiable de franchir Cloudflare et de récupérer le HTML brut. Cible pour démarrer : ~5 à 7M requêtes/mois sur Cardmarket, avec d'autres marketplaces ensuite.

Ce que j'ai testé (Web Unlocker API, flag country=de comme convenu)

✅ Le déblocage Cloudflare fonctionne très bien. Statut 200, routage via l'edge Cloudflare de Munich confirmé, la première page (les 50 offres les moins chères) revient proprement et complète. Sur ce point, rien à redire.

❌ En revanche, je n'arrive pas à faire fonctionner le « load more » (pagination) avec le Web Unlocker. C'est le point important, et il rejoint directement la question qu'on avait soulevée sur le comptage des « load more ».

Le détail technique, au cas où ça aide votre équipe support :

• La pagination de Cardmarket passe par un endpoint AJAX (Product_LoadMoreArticles) qui exige une continuité de session : le token CSRF (__cmtkn) est lié au PHPSESSID et à l'IP qui a chargé la page 1.
• Or l'API /request est sans état : elle ne renvoie pas le Set-Cookie (je ne récupère donc jamais le PHPSESSID), et l'IP de sortie change à chaque appel.
• J'ai bien vu que le paramètre session est accepté par l'API, mais en le testant, le cookie jar n'est pas conservé d'un appel à l'autre (cookie posé à l'appel 1 → absent à l'appel 2). Le paramètre épingle éventuellement l'IP, mais sans les cookies ça ne suffit pas.
• Résultat : chaque POST vers l'endpoint de pagination renvoie une 502 côté Cardmarket, car le token est « orphelin » (pas de session correspondante).

Si j'ai raté une option (mode proxy avec session + cookies persistants, une config de zone particulière, etc.), je suis évidemment preneur — n'hésite pas à faire relayer à l'équipe technique.

Ce que ça implique côté volume et coût

Avec le Web Unlocker seul, on est donc limité à la page 1 (les 50 offres les moins chères). Pour Cardmarket, la page 1 contient déjà le prix le plus bas (tri par prix croissant), donc pour une partie du catalogue c'est suffisant.

Mais pour reconstituer la matrice complète (langue × état) sur les produits qui ont plus de 50 offres — d'après nos mesures, ~60% du catalogue, ~2,7 pages en moyenne — il faut la pagination, ce qui nous orienterait vers la Browser API (facturée au Go, et non à la requête). C'est un modèle de coût très différent, et c'est exactement là que le comptage devient décisif pour nous.

Pour être transparent : chez certains fournisseurs qu'on évalue en parallèle, la pagination complète est incluse dans une seule requête facturée. Donc au-delà du prix unitaire, c'est vraiment la façon dont la pagination est comptée qui va départager les solutions à notre volume.

Les questions clés pour avancer

1. Existe-t-il un moyen de faire paginer le Web Unlocker (session + cookies persistants) que j'aurais manqué, ou la Browser API est-elle la seule voie pour le « load more » ?
2. Quels sont les tarifs des deux options à notre volume, pour qu'on puisse comparer le coût réel :
   • Web Unlocker — page 1 uniquement, ~5-7M requêtes/mois
   • Browser API — pagination complète, facturation au Go (une estimation du Go/produit serait très utile)
3. Quel taux de succès (SLA) vous garantissez, et le modèle de facturation en cas d'échec (on facture les requêtes bloquées ?).

Avec grand plaisir pour caler un appel avec l'équipe commerciale sur les volumes, la tarification et les SLA. Dispo cette semaine si ça vous convient.

Bien à toi,

Tristan