Accept-Language, devise et géo-cookie : nous réparons le parseur.

Le parser se lance, le code ne plante pas, les données arrivent — mais les prix sont en dollars au lieu de roubles, le texte est en anglais, et les produits diffèrent de ceux que voit un utilisateur vivant en Russie. C'est l'un des problèmes de parsing les plus fréquents et frustrants : techniquement, tout fonctionne, mais le contenu « n'est pas le bon ». Analysons pourquoi cela se produit et comment formuler une requête qui obtient exactement la version de la page dont vous avez besoin.

Symptômes : comment comprendre que le parser voit la mauvaise version

Avant de résoudre le problème, il est important de le diagnostiquer correctement. Il existe trois scénarios typiques pour lesquels le parser obtient des données différentes de celles qu'un utilisateur ordinaire du navigateur voit :

La langue du contenu ne correspond pas — vous attendez un texte en russe, mais vous recevez une version en anglais ou en ukrainien de la page.
La devise et les prix diffèrent — le site affiche le prix en USD ou EUR, alors que dans le navigateur depuis la Russie vous voyez des roubles, ou les chiffres sont tout simplement différents (tarification régionale).
Le catalogue de produits/contenus est différent — la disponibilité des produits, les promotions, la vitrine dans son ensemble dépendent de la région que le site a « vue » chez vous.

La raison est presque toujours l'une des trois (ou une combinaison) : l'en-tête Accept-Language, des cookies manquants ou incorrects, ou la géolocalisation de l'adresse IP à partir de laquelle la requête est envoyée. Analysons chacune d'elles dans l'ordre.

Accept-Language : comment le serveur choisit la langue de la réponse

Le navigateur envoie à chaque requête l'en-tête Accept-Language, dans lequel sont énumérées les langues préférées de l'utilisateur avec des poids (valeurs q). Voici un exemple de ce que Chrome envoie réellement avec la locale russe :

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

Les bibliothèques de parsing (requests, httpx, scrapy) n'envoient par défaut soit cet en-tête, soit envoient quelque chose comme */*. Dans ce cas, le serveur renvoie soit la langue par défaut (souvent l'anglais), soit détermine la langue par IP — et c'est ici que la partie géo entre en jeu, comme nous le verrons ci-dessous.

Un point important : de nombreux sites utilisent précisément la combinaison « Accept-Language + géolocalisation IP », et non quelque chose de séparé. Cela signifie que même si vous envoyez un en-tête de langue correct, si la requête provient d'une IP d'un autre pays, le site peut tout de même vous rediriger vers la version anglaise ou locale pour la région d'où la requête a réellement été envoyée.

Devise et locale : d'où le site obtient les prix

La devise n'est presque jamais déterminée directement par l'en-tête Accept-Language. Le plus souvent, l'un des trois mécanismes (ou une combinaison) est utilisé :

Base GeoIP — le serveur regarde d'où provient l'IP et insère automatiquement la devise et la locale appropriées lors de la première visite.
Cookie avec la région précédemment choisie — si l'utilisateur a un jour choisi manuellement un pays et une devise, le site le conserve dans un cookie et ne vérifie plus l'IP.
Paramètre dans l'URL ou sous-domaine — certains sites utilisent des marqueurs explicites comme ?country=ru ou ru.example.com.

En pratique, si vous parsez un site de commerce électronique et voyez des prix en dollars au lieu de roubles, dans 80 % des cas, le problème ne vient pas des en-têtes, mais bien de l'adresse IP de la requête. Le site a simplement « vu » une IP non russe et a inséré la vitrine internationale par défaut.

Après que le site a déterminé une fois votre région (par IP ou par choix manuel sur la bannière « Choisissez votre ville »), il conserve cette décision dans un cookie — généralement avec des noms comme region, geo_city, currency ou locale. Ensuite, toutes les requêtes avec ce cookie sont traitées selon la région enregistrée — même si l'IP change soudainement.

Cela crée un piège pour le parser : si vous avez une fois reçu la « mauvaise » version et avez enregistré le cookie de session, toutes les requêtes suivantes reproduiront la même erreur, même si vous corrigez les en-têtes ou les proxies. C'est pourquoi lors du diagnostic, vérifiez toujours le parsing avec une session propre — sans cookies enregistrés des exécutions précédentes.

L'autre côté de la même mécanique est utile : si vous connaissez le nom du cookie nécessaire et sa valeur correcte pour la région cible (par exemple, vous l'avez vu dans DevTools du navigateur à l'emplacement souhaité), vous pouvez forcer cette valeur dans la requête sans changer l'IP. Cela fonctionne pour les sites où la région est déterminée uniquement par un cookie-flag, mais ne fonctionne pas si le serveur vérifie à chaque requête l'IP avec la base GeoIP.

Rôle de l'adresse IP et des proxies dans la détermination de la région

La détermination GeoIP est le moyen le plus fiable pour un site de comprendre d'où provient réellement la requête, car les en-têtes et les cookies peuvent être falsifiés, mais l'adresse IP ne peut pas être falsifiée (on peut seulement la remplacer par une autre réelle). C'est pourquoi pour obtenir de manière stable la « bonne » version régionale de la page, il ne suffit pas d'avoir des en-têtes HTTP — il faut une IP qui appartient réellement au pays souhaité.

Il existe une différence significative entre les types d'adresses IP :

IP de centres de données — les bases GeoIP les identifient souvent correctement par pays, mais de nombreux grands sites (en particulier les marketplaces et les services avec protection contre les bots) marquent les plages d'adresses de centres de données comme suspectes et peuvent afficher une version réduite ou par défaut du contenu, indépendamment de la géolocalisation.
IP résidentielles — appartiennent à de véritables fournisseurs et adresses physiques, donc GeoIP détermine la région plus précisément, et le site perçoit la requête comme celle d'un utilisateur ordinaire de ce pays/ville.
IP mobiles — sont liées aux opérateurs mobiles d'un pays spécifique, ce qui est particulièrement important pour les sites et applications qui traitent différemment le trafic mobile et de bureau.

Pour des tâches comme la surveillance des prix sur Wildberries, Ozon ou Avito depuis des villes spécifiques, les proxies résidentiels sont les plus adaptés — ils fournissent une IP liée à une région réelle, et les bases GeoIP des sites déterminent correctement le pays et la ville, sans substitution à la vitrine internationale par défaut.

Pratique : construisons la bonne requête en Python

Construisons une requête qui résout simultanément les trois problèmes : envoie un Accept-Language correct, utilise une session propre avec les cookies nécessaires et passe par l'IP de la région souhaitée.

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

session = requests.Session()
response = session.get(
    "https://example.com/catalog",
    headers=headers,
    cookies=cookies,
    proxies=proxies,
    timeout=15,
)

print(response.status_code)
print(response.text[:500])

Quelques points importants dans ce code :

Utilisation de requests.Session(), et non d'un simple requests.get(), afin que le serveur puisse, si nécessaire, établir des cookies supplémentaires qui seront conservés entre les requêtes d'une même session de parsing.
Les valeurs des cookies region et currency — sont conditionnelles, leurs noms et valeurs réels doivent être vérifiés dans DevTools du navigateur (onglet Application → Cookies) sur le site cible avec la localisation souhaitée.
Le proxy doit réellement se trouver dans le pays souhaité — sinon, même des en-têtes et des cookies corrects peuvent être écrasés par le serveur lors de la redétermination de la géolocalisation.

Sites JS : Playwright et gestion des en-têtes/cookies

Si le site rend le contenu via JavaScript (les prix sont chargés par une requête distincte après le chargement de la page), une simple requête requests n'est pas suffisante — un navigateur sans tête est nécessaire. Dans Playwright, la locale, la langue et le proxy sont définis au niveau du contexte du navigateur :

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

Faites attention au paramètre timezone_id — de nombreux sites vérifient également le fuseau horaire du navigateur par rapport à celui attendu pour la région, et un écart (par exemple, IP venant de Russie, mais fuseau horaire du navigateur — américain) peut à lui seul être un signal pour le système anti-bot que la requête est suspecte, même si la langue et la devise sont formellement correctes.

Erreurs typiques et checklist avant le lancement

Avant de lancer le parser en production, passez en revue une courte checklist — cela économise des heures de débogage :

✅ L'en-tête Accept-Language est défini et correspond à la région attendue.
✅ La session est propre — les cookies ne sont pas hérités d'une requête précédente infructueuse.
✅ L'IP du proxy se trouve physiquement dans le pays souhaité (vérifiez avec n'importe quel vérificateur geo-IP avant le parsing).
✅ User-Agent correspond à un véritable navigateur et ne contient pas de signes de mode headless.
✅ Le fuseau horaire et la locale du navigateur (pour Playwright/Selenium) correspondent au pays de l'IP.
✅ Si le site utilise un choix manuel de la région sur une bannière — les cookies de ce choix sont transmis manuellement.

Il convient de mentionner la rotation des proxies : si vous changez d'IP à chaque requête, mais que les cookies de session restent les mêmes, le site peut voir une incohérence « cookie de région A, mais IP de région B » et réinitialiser la session. Pour des tâches de surveillance des prix, il est préférable de fixer une IP pour toute la session de parsing d'une région spécifique, plutôt que de la faire tourner au milieu de la collecte de données.

Quel type de proxy choisir pour la tâche

Le choix du type de proxy influence directement la précision avec laquelle le site déterminera votre région et ne suspectera pas l'automatisation. Voici une comparaison pour des tâches typiques de parsing des versions régionales des sites :

Type de proxy	Précision de la géolocalisation	Quand utiliser
Proxies de centres de données	Moyenne, le pays est correct, mais l'IP peut être marquée comme « non résidentielle »	Parsing de sites sans protection anti-bot stricte, vitesse élevée et volume de requêtes
Proxies résidentiels	Élevée, jusqu'à la ville	Surveillance des prix sur les marketplaces, contenu régional, contournement des vérifications GeoIP
Proxies mobiles	Élevée, plus la marque de l'opérateur mobile	Sites et applications qui fonctionnent différemment avec le trafic mobile d'un pays spécifique

Si la tâche consiste à surveiller le catalogue et les prix sur les marketplaces depuis différentes villes, les proxies résidentiels donnent généralement le résultat le plus prévisible : les bases GeoIP voient une véritable adresse résidentielle, et non une plage de centres de données, que certains sites traitent avec une logique distincte.

Conclusion

Le problème « le parser voit la mauvaise version de la page » est presque toujours composé de trois facteurs : de l'en-tête Accept-Language, qui détermine la langue préférée de la réponse ; des cookies, qui se souviennent de la région et de la devise précédemment choisies ; et de la géolocalisation de l'adresse IP, par laquelle le serveur détermine le pays de la requête lors de la première visite. Pour obtenir exactement la version du site que voit un utilisateur vivant, il est nécessaire de synchroniser tous les trois paramètres en même temps, et non de les corriger séparément.

Si vous parsez régulièrement des versions régionales de sites, surveillez les prix des concurrents sur les marketplaces ou collectez des données depuis différents pays, il est judicieux de commencer par le choix de l'IP appropriée — les autres réglages (en-têtes, cookies, fuseau horaire) se construisent autour de cela. Pour un ciblage précis de la région souhaitée, nous vous recommandons d'essayer des proxies résidentiels, qui offrent une géolocalisation prévisible et minimisent le risque d'obtenir la version internationale par défaut du site au lieu de la version locale.