Parsing Mercado Libre 2026 : le prix dépend de la zone de livraison

Vous avez extrait 40 000 fiches Mercado Libre, calculé le prix moyen en Argentine et remis un rapport. Le problème est que ce ne sont pas des prix pour l'Argentine. Ce sont des prix pour le code postal 1430 — la zone par défaut que la plateforme attribue à tous ceux qui n'ont pas précisé où livrer.

Mercado Libre opère dans 18 pays d'Amérique Latine, le chiffre d'affaires du groupe pour 2025 s'élevait à 28,9 milliards de dollars, et l'entreprise compte 123 670 employés. Pour l'analyse e-commerce, c'est la principale source de données dans la région et en même temps le piège le plus sous-estimé : la plateforme fournit des prix différents, des frais de livraison différents et un gagnant de la boîte d'achat différent selon d'où provient la demande et quelle zone de livraison la session voit. Analysons ce qui se casse et comment collecter correctement.

Ce qui a changé en 2026 : l'API est pratiquement fermée

Il y a encore quelques années, le « parsing de Mercado Libre » était résolu par une API publique : GET api.mercadolibre.com/sites/MLA/search?q=iphone renvoyait des résultats sans autorisation. Aujourd'hui, ce n'est plus le cas.

Vérification du 12 septembre 2026 depuis une IP serveur ordinaire, sans token :

/sites — HTTP 403, corps {"code":"PA_UNAUTHORIZED_RESULT_FROM_POLICIES","blocked_by":"PolicyAgent","message":"At least one policy returned UNAUTHORIZED."}
/sites/MLA/search?q=iphone&limit=1 — HTTP 403, {"message":"forbidden","error":"forbidden"}
/items/{id} — HTTP 403, même PolicyAgent

Et ce n'est pas seulement une question d'absence de token. Les vendeurs et intégrateurs dans des plaintes publiques décrivent le même tableau avec un token d'accès valide : /users/me et les commandes répondent normalement, tandis que les endpoints catalogues et de notation renvoient blocked_by: PolicyAgent. La politique d'accès à l'API se renforce de manière ciblée, par endpoints, et la documentation ne suit pas.

Parallèlement, la plateforme a deux délais techniques pour ceux qui vivent encore sur l'API officielle :

à partir du 30 août 2026, les applications doivent être séparées : une application distincte pour Mercado Libre, une autre pour Mercado Pago. Cela est vérifié via GET applications/$APP_ID — si dans les scopes il reste des droits de type urn:mp:..., l'application doit être refaite, sinon elle perd l'accès à l'API Mercado Libre ;
la transmission du token d'accès dans les paramètres de requête est considérée comme non sécurisée : la plateforme commencera à rejeter de telles requêtes avec une réponse 301. Le token doit être envoyé uniquement dans l'en-tête Authorization: Bearer.

La conclusion pratique est simple : l'API officielle en 2026 est un canal pour le vendeur travaillant avec son compte, et non un outil d'analyse de marché. Si la tâche est de surveiller les concurrents et les prix par région, vous travaillez avec la vitrine publique. Ce qu'il faut choisir pour une tâche spécifique, nous l'avons examiné dans le matériel API officielle, jeu de données prêt ou votre propre parser.

Sept vitrines au lieu d'un seul site

Mercado Libre n'est pas un seul catalogue avec un filtre par pays, mais un ensemble de plateformes indépendantes avec leurs propres domaines, devises et offres de produits. Dans l'API, elles sont appelées site_id :

MLA — Argentine (mercadolibre.com.ar, ARS)
MLB — Brésil (mercadolivre.com.br, BRL)
MLM — Mexique (mercadolibre.com.mx, MXN)
MLC — Chili, MCO — Colombie, MLU — Uruguay, MPE — Pérou, MLV — Venezuela

Le même article dans MLA et MLB représente deux fiches différentes, deux vendeurs différents, deux schémas logistiques différents. Les comparer « de front » n'a pas de sens : une normalisation par devise et par conditions de livraison est nécessaire. À propos de la devise — la plateforme fournit elle-même les règles de formatage en HTML : pour l'Argentine, c'est "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Les parsers qui coupent le prix avec une expression régulière par point se trompent mille fois sur les vitrines latino-américaines.

Principal : le prix et la livraison sont calculés à partir de la zone du destinataire

Voici un extrait qui est intégré directement dans le HTML de la page de résultats listado.mercadolibre.com.ar lors d'une demande sans adresse :

"location_info":{"zipcode":"1430","inferred_zipcode":false,"default_zipcode":true,"user_zone":"X19"}

On peut le lire comme suit : le code postal 1430, il n'est pas dérivé de votre IP (inferred_zipcode: false), il est par défaut (default_zipcode: true). En haut, il est indiqué « Enviar a Capital Federal » — c'est-à-dire que la plateforme a silencieusement décidé que vous êtes dans le district fédéral de Buenos Aires, et ensuite, elle calcule tout précisément pour lui.

Et elle calcule beaucoup de choses. Dans le même HTML se trouvent des étiquettes de livraison, liées à la zone : same_day_free_shipping avec le texte « Llega gratis hoy », icône vpp_full_icon — « Enviado por FULL » (produit depuis l'entrepôt de la plateforme). Sur une seule page de résultats pour la requête « iphone », il y avait 96 mentions de livraison gratuite. La zone détermine également le bloc buy_box avec « Otra opción de compra » : quel vendeur remportera la fiche est déterminé en partie par qui livrera moins cher et plus rapidement à un code postal spécifique.

En résumé : un parser qui n'a jamais défini la zone de livraison ne collecte pas « le marché argentin », mais un échantillon d'une seule ville. Pour un rapport sur le pays avec des villes de plus d'un million d'habitants à mille kilomètres de la capitale, c'est un défaut qui ne se manifeste d'aucune manière — les chiffres semblent plausibles, ils ne répondent simplement pas à la bonne question.

Barrière à l'entrée : /gz/account-verification

Une deuxième surprise attend au niveau du transport. Une demande à listado.mercadolibre.com.ar/iphone ne renvoie pas immédiatement des résultats : elle arrive HTTP 302 sur /gz/account-verification?go=...&tid=... — sa propre page de vérification de l'appareil. Ce n'est pas Cloudflare et ce n'est pas DataDome : dans le code de la barrière, il n'y a ni reCAPTCHA, ni Turnstile, ni marqueurs de bots anti-tierce, mais une dizaine d'appels à la mécanique des appareils. La page pèse environ 41 Ko, est construite sur JavaScript et sans lui, elle ne montre rien.

Le comportement lors de la vérification s'est avéré révélateur. La première demande depuis une IP serveur propre a été acceptée par la barrière : une véritable sortie est arrivée à 2 425 906 octets — 50 blocs ui-search-layout et 120 nœuds de prix andes-money-amount__fraction, tout rendu sur le serveur. Les demandes répétées depuis la même adresse se sont déjà heurtées à /gz/account-verification et n'ont pas passé. Les vitrines brésiliennes et mexicaines depuis la même IP n'ont pas été acceptées du tout.

C'est une mécanique « réputationnelle » typique : l'adresse reçoit un petit crédit de confiance, le dépense en quelques requêtes et se ferme. Aucun test unique ici ne prouve quoi que ce soit — il est important de noter qu'il n'y a pas d'accès durable depuis le pool de centres de données, et le comportement varie d'un pays à l'autre.

Un autre détail des en-têtes de réponse : la plateforme attribue _d2id (identifiant de l'appareil avec une durée d'un an, qui est également dupliqué dans x-request-device-id) et _mldataSessionId avec Max-Age=1800. Trente minutes — c'est la durée naturelle de la session, à laquelle il convient d'adapter la rétention de l'IP.

Que dit robots.txt

Avant de commencer la collecte, il vaut mieux lire les règles de la plateforme. Dans le robots.txt des deux vitrines (argentine et brésilienne), le bloc supérieur est identique et tout à fait clair :

interdiction totale (Disallow: /) pour les crawlers AI : Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User ;
autorisé pour les bots de prévisualisation des réseaux sociaux : FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot ;
pour Bingbot — Crawl-delay: 5 et une longue liste de sections fermées : /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ et d'autres.

De cela découlent deux choses pratiques. Premièrement : le panier, le checkout et les profils utilisateurs sont clairement fermés — il n'est pas nécessaire d'y accéder techniquement ou juridiquement. Deuxièmement : Crawl-delay: 5 pour le bot de recherche est un indicateur honnête du rythme que la plateforme attend de l'automatisation. Cinq secondes par requête depuis une adresse est un point de départ raisonnable, et non un chiffre sorti de nulle part.

Comment collecter correctement : ordre des actions

Fixez la matrice de collecte. Pas « Mercado Libre », mais une liste de paires « pays × zone de livraison ». Pour l'Argentine, cela pourrait être, par exemple, Capital Federal, Córdoba, Rosario, Mendoza ; pour le Brésil — São Paulo, Rio, Belo Horizonte, Recife. Le prix sans indication de zone n'a pas de sens, et cette décision est prise avant la première ligne de code.
Obtenez une IP résidentielle du pays souhaité. Les adresses serveur sur les vitrines brésiliennes et mexicaines n'ont pas passé la barrière du tout, sur l'argentine, elles se sont épuisées après la première demande. Une adresse locale résidentielle résout à la fois la question d'accès et de fiabilité : la plateforme vous montre à l'origine ce qu'elle montrerait à un acheteur local.
Maintenez l'IP pendant toute la session. Le cookie de session vit 30 minutes — la rotation à chaque demande réinitialise à la fois celui-ci et la zone sélectionnée, et vous obtenez à nouveau l'index par défaut. Une session collante de 10 à 30 minutes pour une zone, puis changement. Comment choisir la durée de la fenêtre, nous l'avons examiné dans le guide sur les sessions collantes.
Utilisez un moteur de navigateur, pas un client HTTP brut. La page /gz/account-verification est entièrement construite sur JavaScript : sans exécution de scripts, vous resterez éternellement bloqué. Playwright ou un équivalent avec conservation de l'état entre les étapes.
Définissez explicitement la zone de livraison. Le lien mène à /addresses/v3/navigation/hub ; après avoir défini l'adresse, l'état vit dans le cookie de session. Exécutez cette procédure une fois par session, pas pour chaque fiche.
Faites de location_info un contrôle de somme. Sur chaque page sauvegardée, vérifiez que zipcode correspond à l'objectif, et que default_zipcode est devenu false. Si le drapeau reste true — ne l'écrivez pas dans la vitrine de données, elle a été collectée pour la mauvaise zone. Cette seule vérification élimine la majorité des défauts silencieux.
Récupérez les prix depuis le HTML serveur. Le prix et les étiquettes de livraison sont déjà rendus sur le serveur — il n'est pas nécessaire de courir après les endpoints JSON internes. Conservez à côté du prix le zipcode, user_zone, currency_id et le timestamp : sans eux, le chiffre n'est pas vérifiable.
Maintenez le rythme. L'indicateur de la plateforme elle-même est de cinq secondes entre les requêtes depuis une adresse. Si vous avez besoin de vitesse — élargissez le pool d'adresses, pas la fréquence depuis une IP : c'est précisément l'afflux depuis une adresse qui ferme la barrière.

Les pièges dont on découvre les conséquences trop tard

Défaut silencieux de la zone par défaut. L'erreur la plus coûteuse ne se manifeste pas par une exception. Les données sont collectées, le rapport est construit, la décision sur la formation des prix est prise — et seulement après un trimestre, il s'avère que toute l'analyse du Brésil décrit un seul quartier de São Paulo.

Poids des pages. Une page de résultats — 2,4 Mo. Mille pages par jour sur quatre pays et quatre zones — cela représente des dizaines de gigaoctets de trafic par mois. Avec un tarif résidentiel payant par gigaoctet, c'est le principal poste de dépenses, donc il est judicieux de désactiver immédiatement le chargement des images et des polices dans le moteur de navigateur : les prix sont dans le HTML, les images pour le parser sont un pur gaspillage.

Comparaison des pays sans normalisation. ARS, BRL, MXN et différents séparateurs de milliers. Ramenez à une seule devise selon le taux à la date de collecte et conservez le prix d'origine et la devise séparément, sinon il ne sera plus possible de recalculer a posteriori.

Pari sur l'API officielle. Si l'intégration se fait toujours via l'API, gardez à l'esprit l'exigence d'applications séparées à partir du 30 août 2026 et le déplacement du token des paramètres de requête vers l'en-tête. La perte silencieuse d'accès à l'API ressemble exactement à un bug dans votre code.

Quels proxies sont nécessaires pour cette tâche

Résidentiels — une option efficace pour la collecte des prix et des livraisons. Une adresse du pays dont vous extrayez la vitrine est nécessaire, et de préférence la région dont vous vérifiez la zone de livraison : ainsi, les données sont à la fois collectées et restent fiables. Les proxies résidentiels avec maintien de session répondent à ces deux exigences simultanément.

Mobiles — là où la barrière est particulièrement tenace. L'Amérique Latine est une région avec une forte part de trafic mobile, et une adresse d'opérateur mobile semble pour la plateforme tout à fait ordinaire. Elles sont justifiées sur des segments étroits mais critiques, et non sur un déchargement massif.

Les datacenters — pour l'exploration et les tâches administratives : lire robots.txt, extraire la structure de la page, vérifier la disponibilité du domaine. Pour une collecte régulière de prix, comme l'a montré la vérification, la ressource n'est pas suffisante.

En résumé

Mercado Libre en 2026 ne fournit pas de données de manière anonymisée. L'API officielle a été fermée par les politiques PolicyAgent, la vitrine rencontre sa propre vérification d'appareil, et le chiffre principal — le prix avec livraison — est calculé à partir de la zone du destinataire, que la plateforme attribue par défaut si elle n'est pas spécifiée. Un parser correct ici se distingue d'un incorrect non par l'ingéniosité de contournement, mais par la discipline : pays, zone, devise et location_info à côté de chaque ligne. Tout le reste est une question de l'origine de vos requêtes.