Comment les sites déterminent votre localisation

Pourquoi une IP allemande peut-elle ouvrir une boutique destinée à l’Inde ?

Imaginez un client en Inde qui ouvre une boutique en ligne via un proxy présenté comme allemand. Dans cet exemple, la boutique identifie aussi l’adresse IP comme allemande. Pourtant, le sélecteur de pays en haut de la page indique toujours l’Inde, et le catalogue est celui destiné aux clients en Inde.

Lors d’une visite précédente, le client a sélectionné l’Inde dans ce menu. La boutique a enregistré ce choix et le réutilise à son retour. Elle dispose de deux informations utiles : la requête actuelle provient d’une IP qu’elle associe à l’Allemagne, et le client a précédemment demandé à faire ses achats pour l’Inde. Conserver le marché sélectionné fait délibérément partie du fonctionnement de cette boutique.

Le pays de l’IP et la boutique sélectionnée répondent donc à des questions différentes. L’un concerne l’adresse depuis laquelle la requête est arrivée ; l’autre détermine l’expérience d’achat. La même distinction s’applique à une ville choisie sur un site météo ou à une destination saisie dans une recherche d’hôtel. Le site peut afficher des informations sur un lieu sans en déduire que le visiteur s’y trouve physiquement.

Quelles informations parviennent au site ?

Le serveur qui traite une requête de page voit l’adresse IP de la connexion. Pour une requête envoyée via un proxy, il s’agit de l’adresse utilisée par le proxy pour se connecter au service. Les données de géolocalisation IP associent cette adresse à un pays ou à une zone. Le site lui-même ou un service traitant les requêtes pour son compte peut effectuer cette recherche.

La requête peut aussi contenir les préférences linguistiques et les cookies précédemment enregistrés pour le site. Après le chargement de la page, son JavaScript peut lire d’autres paramètres du navigateur et demander la position de l’appareil via le système d’autorisations du navigateur. La connexion à un compte donne accès à d’autres informations : le site peut récupérer les données enregistrées dans ce compte.

Un site utilise les informations nécessaires à ses fonctions. Une page simple peut reposer uniquement sur l’adresse IP, tandis qu’une boutique avec des comptes, des catalogues régionaux et des options de livraison a des raisons d’utiliser plusieurs sources. Rien n’impose à tous les sites de recueillir tous les éléments du tableau.

Comment un site mémorise-t-il le pays choisi ?

Les cookies sont de petits éléments de données que le navigateur stocke et envoie avec les requêtes ultérieures au site concerné. Un cookie peut contenir directement une préférence de pays. Il peut aussi contenir un identifiant qui permet au serveur de retrouver une session enregistrée et ses paramètres. D’autres espaces de stockage du navigateur, comme localStorage, peuvent conserver des préférences que les scripts du site liront.

Changer de proxy modifie la connexion utilisée pour les requêtes suivantes. Cela ne supprime pas les valeurs stockées. Dans l’exemple d’achat, une requête depuis l’IP allemande peut transporter le même cookie de session qu’auparavant, ce qui permet à la boutique de retrouver la sélection de l’Inde.

Les paramètres du compte peuvent persister d’un navigateur ou d’un appareil à l’autre. Une adresse personnelle, une adresse de livraison ou une région préférée peuvent être conservées sur les serveurs du site. Après votre connexion, ces informations sont de nouveau disponibles. Effacer les données locales du site ne supprime pas les enregistrements du compte.

Le lien ouvert peut lui aussi sélectionner une région. Une boutique peut avoir un domaine ou un chemin d’URL distinct pour chaque marché. Suivre un lien vers sa boutique indienne peut ouvrir immédiatement cette version. Dans ce cas, l’URL choisie indique déjà à la boutique la version demandée.

L’activité antérieure peut aussi compter. Google, par exemple, indique utiliser les informations IP, la position de l’appareil, les adresses personnelle et professionnelle enregistrées et l’activité passée pour estimer une localisation pertinente pour la recherche. Cela décrit le service de Google ; cela ne signifie pas que n’importe quel site peut lire tout votre historique de navigation.

Comment le navigateur partage-t-il la position de l’appareil ?

La Geolocation API est une fonction du navigateur par laquelle une page peut demander une estimation de la position géographique de l’appareil. Sur les sites publics ordinaires, elle est disponible dans un contexte sécurisé, généralement HTTPS, et nécessite une autorisation de localisation. Le résultat comprend la latitude, la longitude, une estimation de la précision et l’heure à laquelle la position a été obtenue. Une requête autorisée peut utiliser une position en cache si la page l’accepte ; ouvrir une carte ne produit donc pas nécessairement une nouvelle mesure.

Le navigateur et les services de localisation de l’appareil déterminent comment obtenir cette estimation. Les sources disponibles peuvent inclure le GPS, les réseaux Wi-Fi à proximité, les informations du réseau mobile et les informations IP. Un ordinateur portable sans GPS peut donc lui aussi fournir une position. L’API n’impose pas de source particulière et n’indique pas la source à la page. Les coordonnées renvoyées par le navigateur ne doivent pas être automatiquement qualifiées de coordonnées GPS ou de position physique exacte.

Supposons que le client en Inde autorise la boutique à obtenir la position de l’appareil et que le navigateur renvoie des coordonnées en Inde. La page peut transmettre ces coordonnées à la boutique via le proxy allemand. La requête transporte alors deux faits différents : elle arrive d’une IP allemande et son contenu comprend une position en Inde. Le proxy transporte cette information ; il ne transforme pas les coordonnées fournies en coordonnées allemandes.

Une nouvelle demande d’autorisation n’apparaît pas forcément à chaque visite. Le navigateur peut toujours disposer d’une autorisation valide accordée auparavant. Vous pouvez examiner l’autorisation de localisation de ce site dans les paramètres du navigateur ; l’accès peut aussi dépendre des autorisations accordées au navigateur par le système d’exploitation.

Refuser cette autorisation empêche le site d’obtenir une nouvelle position par cette API tant que l’accès reste refusé. Les estimations fondées sur l’IP et les informations déjà enregistrées par le site demeurent des sources distinctes. Cela explique pourquoi un site peut encore afficher une localisation même si vous ne l’avez pas autorisé à demander la position de l’appareil.

Que révèlent la langue et le fuseau horaire au site ?

Un navigateur peut envoyer les langues préférées dans l’en-tête de requête Accept-Language. Les scripts de la page peuvent aussi lire les préférences linguistiques. Ces paramètres aident le site à choisir une langue comprise par le visiteur. Ils n’exigent pas l’autorisation utilisée pour la géolocalisation de l’appareil.

Un navigateur en anglais peut rester en anglais pendant que son propriétaire voyage entre plusieurs pays ou utilise un proxy allemand. Si une boutique allemande prend en charge l’anglais, elle peut afficher du texte anglais tout en considérant la connexion comme allemande. Même une préférence comme en-US identifie une variante linguistique, pas une position vérifiée aux États-Unis.

JavaScript peut aussi lire le fuseau horaire exposé par le navigateur, par exemple via Intl.DateTimeFormat().resolvedOptions().timeZone. Un site peut l’utiliser pour afficher un rendez-vous à l’heure locale du visiteur. La valeur reflète normalement l’environnement du navigateur, qui peut utiliser un fuseau horaire automatique ou configuré manuellement.

Un nom de fuseau horaire et un décalage UTC sont deux valeurs différentes. Un décalage exprime la différence par rapport à UTC à un instant donné, et plusieurs pays peuvent le partager. Aucune de ces valeurs n’établit à elle seule où l’appareil se trouve physiquement. Un site peut comparer la langue et le fuseau horaire à d’autres informations, mais une différence avec le pays du proxy ne montre pas, à elle seule, qu’une autre adresse IP a été divulguée.

Le site peut-il découvrir une autre adresse IP ?

Un paramètre de proxy s’applique au trafic que le navigateur envoie par ce proxy ; il ne garantit pas que toutes les connexions du navigateur ou de l’appareil empruntent ce trajet. WebRTC, la technologie du navigateur utilisée pour les échanges audio, vidéo et de données en temps réel, peut découvrir des adresses lors de la préparation des connexions. Lorsque les règles du navigateur et la configuration réseau permettent des vérifications directes, celles-ci peuvent divulguer une autre IP publique, comme l’adresse de la connexion Internet du client.

Le résultat dépend des règles de confidentialité du navigateur et de la configuration réseau. WebRTC ne permet pas à tous les sites de récupérer systématiquement l’IP publique du client. Une adresse locale privée telle que 192.168.1.10 constitue aussi un constat différent : la même adresse peut exister dans de nombreux réseaux locaux sans rapport entre eux et ne peut donc pas identifier un pays à elle seule.

Le DNS convertit les noms de domaine en adresses réseau. Un test DNS dédié peut identifier le résolveur qui traite ses recherches. Le pays du résolveur décrit ce serveur, qui peut être éloigné du client comme du proxy. Certains résolveurs envoient aussi une partie de l’adresse IP du client ayant effectué la requête DNS, par la fonction facultative EDNS Client Subnet. Voir un résolveur dans un autre pays et exposer des informations sur le réseau du client sont donc deux résultats différents.

Ces mécanismes concernent les informations réseau accessibles au-delà de la requête de page ordinaire. Ils doivent être examinés lorsqu’un test révèle une adresse publique inattendue ou d’autres données réseau. Une page affichée dans la mauvaise langue ne suffit pas à établir qu’une telle connexion a eu lieu.

À quelles informations le site donne-t-il la priorité ?

La réponse dépend de la décision à prendre. La fonction « à proximité » d’une carte peut utiliser une position de l’appareil obtenue avec autorisation. Une boutique peut conserver le pays choisi par un client qui revient. Un calcul de livraison a besoin de la destination du colis. Ces fonctions peuvent intervenir au cours d’une même visite et utiliser des informations différentes.

Il n’existe pas de règle universelle selon laquelle le GPS prime toujours sur l’IP, ou le pays d’un compte sur les deux. Le site décide des sources disponibles et pertinentes pour chaque fonction. Il peut en utiliser une, se replier sur une autre ou en comparer plusieurs.

Le passage en caisse rend cette distinction particulièrement visible. Un client peut parcourir un catalogue allemand, puis saisir une adresse de livraison en Inde. La boutique peut recalculer la livraison, modifier les produits disponibles ou appliquer ses règles pour cette destination. Par exemple, Shopify indique que l’adresse de livraison détermine l’expérience de marché finale du client au paiement. Il s’agit d’une règle du système de commerce, pas d’une nouvelle mesure de l’IP du proxy.

L’accès est une autre décision. Un service peut identifier correctement le pays et néanmoins refuser une action en raison de ses règles de compte, de réseau ou de disponibilité. Un refus général ne révèle pas l’information qui l’a provoqué. L’élément pertinent est l’explication précise fournie par le service, plutôt que la seule apparition d’un refus.

Comment savoir ce qui a influencé le résultat ?

Partez de la fonction exacte à vérifier : le pays attribué à la connexion, un catalogue régional, des résultats de recherche à proximité, la langue ou la possibilité de livrer. Chacune peut dépendre d’informations différentes. Pour une comparaison utile, conservez la même IP de proxy et la même adresse de page en ne modifiant qu’une condition pertinente. Notez l’adresse utilisée dans chaque test au lieu de vous fier uniquement à des paramètres de proxy inchangés ; sinon, la rotation peut changer l’IP en même temps que le paramètre que vous vouliez tester.

1. Examinez les paramètres du site. Vérifiez son sélecteur de pays, sa zone de recherche, la destination de livraison et la version régionale dans l’URL. Une sélection visible peut déjà expliquer le résultat.
2. Comparez une visite de retour à une nouvelle session sans connexion au compte. Un profil de test distinct sans données enregistrées pour le site aide à examiner l’effet de l’état conservé. Confirmez d’abord que ce profil utilise la même IP de proxy. Une nouvelle session privée utilise des données de site séparées de la navigation ordinaire, mais ne change pas automatiquement la connexion ou tous les paramètres du navigateur.
3. Vérifiez ce qui change après la connexion au compte. Si la région précédente revient avec le compte, examinez ses paramètres de région et d’adresse. Ce comportement oriente vers les informations liées au compte, sans révéler l’ensemble du processus de décision du site.
4. Examinez la localisation de l’appareil lorsque la fonction a besoin d’une position actuelle. Vérifiez l’autorisation de localisation du site et les explications qu’il donne sur la source de son estimation. Des résultats à proximité et un pays de livraison enregistré nécessitent des vérifications différentes.

Dans l’exemple d’achat, sélectionner l’Allemagne dans le menu de pays de la boutique permet de modifier la préférence de boutique enregistrée. Si la tâche consiste à organiser une livraison en Inde, la destination indienne reste pertinente. Si le site attribue explicitement le mauvais pays à l’IP du proxy, la question porte alors sur ses données de géolocalisation pour cette adresse. Identifier le résultat nécessaire permet de définir précisément l’action suivante.