Le premier réflexe quand on configure un proxy est de choisir l’emplacement le plus proche de soi. On a l’impression que ce devrait être le plus rapide, et cela donne souvent les mauvaises données. Un site web ne sait pas où vous êtes assis. Il voit la sortie, donc avec un proxy résidentiel, le pays de sortie décide quelle version du site vous obtenez.
Ce guide explique comment choisir un pays de sortie en fonction de ce que vous cherchez à apprendre, comment vérifier si un site réagit ou non, et quand la sortie la plus proche est vraiment le bon choix.
La question à se poser en premier
Ne demandez pas où vous êtes. Demandez de quel point de vue vous avez besoin.
| Ce que vous faites | Choisissez une sortie dans |
|---|---|
| Surveiller les prix des concurrents | Le marché où vos clients achètent |
| Vérifier le classement dans les moteurs de recherche | L’endroit où se trouve le chercheur, jusqu’à la ville si nécessaire |
| Vérifier des publicités | Le pays ciblé par la campagne |
| Tester un site localisé | Chaque marché où vous vendez, un par un |
| Vérifier vos propres redirections géographiques | Chaque pays couvert par la règle, plus un qui ne l’est pas |
| Collecter du contenu qui ne varie pas | Près de la cible, avec un pool important |
Une équipe en Allemagne qui suit les prix aux États-Unis n’obtient rien d’utile avec une sortie allemande : elle verrait des euros et peut-être un catalogue différent, et les données auraient l’air parfaitement correctes.
Tester si le site réagit
Tous les sites ne changent pas selon l’IP. Avant de planifier autour d’un pays de sortie, mesurez-le. Le script ci-dessous demande une page depuis plusieurs pays, confirme où chaque requête est réellement sortie, et enregistre ce que la page affichait. Il fonctionne sous Python 3.9 et versions ultérieures avec requests. Les identifiants proviennent de variables d’environnement, donc gardez-les hors de votre code.
from __future__ import annotations
import os
import re
import requests
GATEWAY = "p.shifter.io:443"
USER, PASSWORD = os.environ["PROXY_USER"], os.environ["PROXY_PASS"]
def session_for(country):
proxy = f"http://{USER}-country-{country}:{PASSWORD}@{GATEWAY}"
s = requests.Session()
s.proxies = {"http": proxy, "https": proxy}
s.headers["User-Agent"] = ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/130.0 Safari/537.36")
return s
def signals(url, country):
"""What this page shows a visitor from one country, and where they really exited."""
s = session_for(country)
try:
exit_country = s.get("https://ip-info.com/json", timeout=30).json().get("country")
r = s.get(url, timeout=30)
except (requests.RequestException, ValueError) as exc:
return {"exit": country.upper(), "error": type(exc).__name__}
lang = re.search(r'<html[^>]*\blang=["\']?([\w-]+)', r.text, re.I)
currency = re.search(r'priceCurrency["\']?\s*(?:content=|:)\s*["\']([A-Z]{3})', r.text)
price = re.search(r'itemprop=["\']price["\']\s+content=["\']([\d.,]+)', r.text)
return {"exit": exit_country, "status": r.status_code, "final_url": r.url,
"lang": lang.group(1) if lang else None,
"currency": currency.group(1) if currency else None,
"price": price.group(1) if price else None}
if __name__ == "__main__":
for url in ("https://www.apple.com/shop/buy-iphone",
"https://store.steampowered.com/app/620/Portal_2/"):
print(url)
for country in ("us", "de", "gb", "br"):
s = signals(url, country)
print(f" exit {s['exit']} {s.get('status')} lang={s.get('lang')} "
f"{s.get('currency')} {s.get('price') or ''}".rstrip())Nous l’avons exécuté le 4 novembre 2026 avec un compte test Shifter. Voici les résultats, et les prix évolueront avec le temps :
https://www.apple.com/shop/buy-iphone
exit US 200 lang=en-US USD
exit DE 200 lang=en-US USD
exit GB 200 lang=en-US USD
exit BR 200 lang=en-US USD
https://store.steampowered.com/app/620/Portal_2/
exit US 200 lang=en USD 9.99
exit DE 200 lang=en EUR 9,69
exit GB 200 lang=en GBP 8.19
exit BR 200 lang=en BRL 33,99Ces deux sites illustrent les deux cas qu’il faut connaître.
Apple ne réagit pas à l’IP. Chaque sortie a obtenu la même page US en USD. Apple garde sa localisation dans l’URL : /de/shop/buy-iphone sert la boutique allemande. Votre pays de sortie n’a fait aucune différence sur cette page, donc choisir une sortie en fonction de la géographie n’aurait servi à rien.
Steam réagit, lui. L’URL et la langue sont restées les mêmes, mais la devise et le prix ont changé selon la sortie : USD 9.99, EUR 9,69, GBP 8.19 et BRL 33,99. Une vérification de prix depuis le mauvais pays vous donne un chiffre propre, crédible, et faux, sans aucune erreur pour vous alerter.
Vérifiez la sortie en plus de la page, comme le fait le script. Un mauvais emplacement est bien plus facile à repérer ici que plus tard dans vos données.
Quand la sortie la plus proche est la mauvaise
- Votre audience est ailleurs. C’est le cas le plus courant, et les exemples ci-dessus montrent pourquoi.
- Votre voisin est un marché différent. L’Allemagne et l’Autriche partagent une langue mais pas toujours des prix, et une devise commune ne signifie pas un catalogue commun. Traitez-les comme des marchés séparés.
- Le marché est régional. Certains résultats varient autant par ville ou par état que par pays. Notre guide sur quand le ciblage au niveau de la ville compte explique comment le savoir.
- Le reste de la requête ne correspond pas. Une sortie US avec une langue de navigateur allemande peut vous donner un étrange mélange des deux. La géolocalisation, le fuseau horaire et la langue doivent concorder, donc configurez-les ensemble.
Quand la sortie la plus proche est la bonne, et proche de quoi
Si un site sert le même contenu partout, comme le fait l’URL d’Apple, la géographie cesse d’être une question de précision et devient une question de performance. Même dans ce cas, la distance qui compte est rarement celle depuis votre bureau. Une requête proxifiée va de votre client à la passerelle, puis à la sortie, puis à la cible. Une sortie proche de la cible raccourcit le dernier tronçon, peu importe votre propre éloignement.
Donc si le contenu ne varie pas, choisissez une sortie proche de la cible avec un grand nombre d’IP disponibles, et mesurez-le. Les petits pays ont des pools plus restreints, donc un marché voisin populaire peut être plus fiable lorsque l’emplacement n’a vraiment aucune importance.
Erreurs courantes
- Tester un seul pays et supposer le reste. Un site qui ignore l’IP sur une page peut réagir sur une autre, comme le paiement ou la recherche. Testez la page qui vous intéresse.
- Faire confiance à une réponse propre. Une page dans la mauvaise devise renvoie quand même un 200. Ajoutez une vérification pour la devise ou la langue attendue.
- Supposer que chaque étape suit la sortie. Certains sites s’orientent par DNS ou par paramètres de compte, en plus de l’IP, et le DNS peut ne pas se résoudre dans le pays de sortie. Si c’est important, vérifiez la page que vous obtenez réellement.
- Confondre sortie et résidence. La sortie est l’endroit où une requête quitte le réseau. Elle ne dit rien sur l’endroit où vos données sont stockées.
- Traiter une sortie comme une autorisation. Montrer à un site la vue d’un autre pays pour des tests ou de la recherche est une chose. L’utiliser pour contourner des licences, des sanctions ou les conditions d’un site en est une autre. Vérifiez d’abord auprès de votre équipe juridique.
En résumé
Choisissez la sortie en fonction du point de vue dont vous avez besoin, pas de l’endroit où vous êtes. Testez si le site réagit du tout à l’IP, confirmez où chaque requête est réellement sortie, et ajoutez une vérification pour la devise ou la langue attendue. Ce n’est que lorsque le contenu est identique partout que la distance entre en jeu, et c’est alors la distance jusqu’à la cible qui compte.