L'équipe traduit l'interface en une dizaine de langues, le développeur ouvre le site depuis son IP de travail et voit la bonne langue : tout fonctionne, donc. En réalité, un seul des cinq niveaux a été vérifié. La devise, la taxe affichée dans le prix, la disponibilité de la livraison et même la composition du catalogue ne dépendent pas de la langue du navigateur, mais de l'endroit d'où le site voit le visiteur. Sans sortie depuis une adresse réelle du pays concerné, la localisation se vérifie à l'aveugle.

Ce qui change réellement pour un visiteur local

La devise n'est pas toujours convertie automatiquement en fonction de la langue : le déclencheur est souvent la géolocalisation de l'IP, et une erreur de détection du pays affiche des dollars là où il devrait y avoir des euros ou des roubles. La taxe affichée dans le prix est une variable à part : certaines plateformes montrent le prix hors taxe de vente, d'autres taxe incluse, et cette décision est prise côté backend d'après l'adresse du visiteur, et non d'après la langue d'interface choisie.

La disponibilité de la livraison est un autre niveau, invisible quand on travaille depuis une IP domestique. La fiche produit peut afficher « en stock » pour un pays et « livraison indisponible » pour un autre, avec une mise en page strictement identique. Enfin, la composition du catalogue : certains articles sont masqués selon la région en raison de licences, de restrictions locales sur la catégorie de produit ou simplement de l'absence d'entrepôt, et on ne peut le constater qu'en se connectant depuis une adresse du pays concerné.

Pourquoi la traduction de l'interface n'est vérifiée qu'à moitié

Changer de langue dans le sélecteur relève du frontend. La devise, la taxe, la livraison et le catalogue relèvent de la logique backend, liée à la géolocalisation de l'IP et parfois à l'ASN : certains services de tarification distinguent une adresse résidentielle d'une adresse de datacenter et montrent au proxy de bureau une autre version de la page que celle d'un utilisateur ordinaire. Un contrôle du type « le texte est traduit, les boutons sont en place » répond à la question de la langue, mais pas à celle de ce que le client verra réellement dans le pays visé. La différence entre une adresse résidentielle et une adresse mobile compte aussi dans ce type de vérification, comme l'explique l'article proxys mobiles contre proxys résidentiels.

Checklist de vérification de la localisation

Premièrement, le pays et la ville d'après la géolocalisation, et non d'après une supposition : l'adresse doit se résoudre exactement là où se trouve physiquement l'utilisateur cible. Deuxièmement, la devise sur la page du catalogue et sur la page de validation de commande, qui divergent parfois. Troisièmement, la présence et le montant de la taxe dans le prix final. Quatrièmement, la disponibilité de la livraison et des moyens de paiement pour la région. Cinquièmement, la composition du catalogue : comparez la liste des produits depuis une adresse locale et depuis votre IP habituelle, l'écart révélera les restrictions régionales.

Sixièmement, la langue de l'interface et le format des dates, des nombres et des masques de saisie téléphonique : ils doivent correspondre à la locale, et pas seulement au sélecteur de langue. Ces points doivent être vérifiés de façon systématique et non au hasard : la méthode de vérification de la qualité des proxys décrit les métriques sur lesquelles s'appuyer pour que le résultat soit reproductible.

Bugs de localisation typiques, visibles seulement depuis une adresse locale

Le premier : le prix affiché est de 15 à 20 % inférieur ou supérieur au prix réel, parce que la taxe s'applique ou non selon le pays de l'IP, et non selon l'adresse de livraison saisie dans le formulaire. Le deuxième : le bouton de validation de commande est actif, mais une erreur apparaît à la dernière étape lors d'une livraison vers la région réelle ; personne ne parcourt ce chemin depuis une IP de travail. Le troisième : un produit est visible dans le catalogue depuis l'IP domestique du développeur, mais disparaît quand on se connecte depuis une adresse du pays cible, à cause d'un filtre régional dont personne n'avait connaissance. Le quatrième : la devise change selon la langue et non selon le pays, et un utilisateur francophone du Canada voit les prix en euros au lieu de dollars canadiens.

Ces bugs ne sont détectés ni par un QA manuel depuis une IP de bureau, ni par des tests automatisés sans usurpation de géolocalisation : il faut une vraie sortie depuis le pays cible, et de préférence depuis plusieurs types d'adresses, car certaines plateformes traitent une IP de datacenter autrement qu'une IP résidentielle. Pour comprendre quel type d'adresse choisir selon l'objectif de la vérification, l'analyse où l'économie sur les proxys est illusoire est utile.

Quel volume de trafic consomme la vérification de la localisation

Une page de catalogue complète avec images pèse de 2 à 5 Mo, une page de texte sans médias de 0,3 à 1 Mo. La vérification d'une centaine de fiches produit (prix, taxe, disponibilité de la livraison) tient dans environ 0,3 à 0,5 Go, et la surveillance quotidienne d'une centaine de pages dans plusieurs pays, dans 1,5 à 3 Go par mois. L'économie vient de la désactivation du chargement automatique des images et des polices lors d'une vérification automatisée, et non du choix du canal le moins cher : une session interrompue à cause d'une adresse instable coûte plus cher que les gigaoctets économisés.

Questions fréquentes

Une IP de datacenter suffit-elle pour vérifier la localisation ?

Pour vérifier la langue de l'interface et l'accessibilité de base du site, oui. Pour vérifier les prix, la taxe et le catalogue, pas toujours : certaines plateformes renvoient aux adresses de datacenter une version tronquée ou différente de la page, c'est pourquoi une adresse résidentielle ou mobile du pays concerné est plus fiable pour un contrôle précis des prix.

Faut-il une adresse de la ville même où vit l'utilisateur cible ?

Pour la taxe et la devise, une précision au niveau du pays suffit généralement, parfois au niveau de l'État ou de la région si la taxe est régionale. Pour la livraison par code postal et les promotions locales, la précision au niveau de la ville peut compter ; il convient de la vérifier séparément pour chaque plateforme.

À quelle fréquence faut-il revérifier la localisation si le site a déjà été contrôlé ?

La logique des prix, des taxes et du catalogue évolue indépendamment des versions de l'interface : le fournisseur a mis à jour son tarif, une règle fiscale a changé, un filtre régional a été ajouté. Une périodicité raisonnable est d'une fois toutes les 2 à 4 semaines, ou immédiatement après toute modification de la logique de prix ou de catalogue.

Vous pouvez vérifier la localisation de vos propres yeux avec un proxy du pays voulu : le catalogue des adresses et des types d'accès est disponible dans la rubrique proxys.