Un site qui fonctionne parfaitement dans le pays où il a été conçu peut être discrètement cassé dans douze autres. Un bouton de commande jamais traduit en Italie, des prix affichés en dollars aux visiteurs allemands, une bannière de consentement qui recouvre toute la page en France, une version linguistique que les moteurs de recherche ne trouvent jamais parce que son hreflang pointe vers la mauvaise URL. Rien de tout cela n’apparaît quand l’équipe teste depuis le bureau.
La raison est simple : la plupart de ce qui change entre les marchés est déterminé par l’endroit où se trouve le visiteur. Pour voir ce que voit un client local, il faut tester depuis ce marché. Ce guide couvre comment mener un contrôle qualité de la localisation sur plusieurs marchés à grande échelle : quoi vérifier, comment voir chaque marché comme le ferait un visiteur local, et un petit outil de vérification qui détecte automatiquement les bugs les plus courants.
Pourquoi les bugs de localisation passent inaperçus
Les sites localisés servent rarement une page fixe unique par langue. Ils décident de ce qu’ils affichent au moment de la requête, en fonction de signaux envoyés par le visiteur :
- La localisation, à partir de l’adresse IP : devise, prix, options de livraison, bannières légales, disponibilité des produits, et parfois la langue elle-même.
- Les préférences linguistiques, à partir du navigateur : quelle traduction afficher et comment formater les dates et les nombres.
- L’URL, comme
/de/oude.example.com: la version demandée au site, qui peut correspondre ou non aux deux autres signaux.
Les tests effectués depuis le siège couvrent généralement une seule combinaison : le propre pays du siège, un navigateur en anglais et l’URL par défaut. Les relectures de traduction vérifient les mots mais pas la page telle qu’elle est servie. Les bugs se cachent dans les combinaisons que personne n’a testées.
Ce qui casse dans un marché
| Bug | Exemple | Comment cela se produit généralement |
|---|---|---|
| Chaînes non traduites | « Add to cart » sur le site italien | De nouvelles fonctionnalités sont déployées avec des chaînes en anglais qui n’atteignent jamais le flux de traduction |
| Mauvaise devise ou format de prix | 49,99 $ affichés aux visiteurs allemands, ou 49.99 € au lieu de 49,99 € | La devise est choisie à partir de l’URL à un endroit et de l’IP à un autre |
| hreflang cassé | Une version linguistique pointe vers une erreur 404 ou vers une autre langue | Les URL ont changé après le lancement, les alternates n’ont pas été mis à jour |
Attribut lang manquant ou erroné | lang="en" sur la page allemande | Un modèle partagé avec un attribut codé en dur |
| Boucles de redirection ou redirections forcées | Un visiteur en Autriche est envoyé vers la boutique allemande et ne peut pas revenir en arrière | Des redirections géographiques qui ignorent un choix explicite |
| Couches légales et de consentement | Une bannière recouvrant le contenu dans un pays de l’UE | Une configuration de consentement spécifique au pays |
| Débordement de mise en page | Des libellés allemands qui cassent des boutons, un texte de droite à gauche qui casse une grille | Des designs testés uniquement avec des chaînes anglaises courtes |
Plusieurs de ces problèmes affectent directement le référencement. Une page avec un mauvais attribut lang ou des alternates cassés peut être indexée dans la mauvaise langue, voire pas du tout. Notre guide sur l’utilisation de hreflang pour trouver chaque version linguistique d’une page montre comment cartographier les alternates d’un site et repérer ceux qui ne mènent nulle part.
Étape 1 : voir chaque marché comme un visiteur local
L’exigence fondamentale est de demander chaque page depuis l’intérieur du marché, avec un navigateur configuré comme celui d’un visiteur local. En pratique, cela implique trois éléments qui doivent concorder :
- Une adresse IP dans le marché. Les proxies résidentiels avec ciblage par pays ou par ville vous donnent une adresse sur une connexion résidentielle locale, ce qui correspond à ce qu’attend la logique géographique du site. Nos proxies résidentiels couvrent plus de 195 pays, avec un ciblage par ville là où vous en avez besoin.
- La langue et les paramètres régionaux du marché. Réglez l’en-tête de langue et les paramètres régionaux du navigateur en conséquence.
- Le fuseau horaire du marché, si vous testez dans un vrai navigateur, car certains sites l’utilisent comme un autre signal de localisation.
Si ces éléments divergent, vous testez une combinaison qu’aucun vrai client n’a, et vous pouvez poursuivre des bugs qui n’existent pas. Notre guide sur la correspondance entre géolocalisation, fuseau horaire et paramètres régionaux du proxy explique comment dériver les trois éléments à partir d’un seul réglage.
Testez également avec une session nouvelle pour chaque marché. Les cookies d’une visite précédente peuvent figer le site sur le dernier pays testé, ce qui masque les bugs de logique géographique.
Étape 2 : vérifier chaque marché de la même manière
La relecture visuelle ne passe pas à l’échelle sur des dizaines de marchés et des milliers de pages, mais la plupart des bugs de localisation peuvent être détectés dans le HTML. La fonction ci-dessous vérifie une page localisée pour quatre des problèmes les plus courants : l’attribut lang, les chaînes anglaises restantes, les prix dans la mauvaise devise, et une entrée hreflang manquante pour le marché.
import re
from lxml import html as lxml_html
def market_problems(page_html, market):
"""Things that only break in one market, checked on one localized page.
market: {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]}
"""
doc = lxml_html.fromstring(page_html)
problems = []
lang = (doc.get("lang") or "").lower()
if not lang.startswith(market["lang"]):
problems.append(f"html lang is {lang or 'missing'}, expected {market['lang']}")
text = " ".join(" ".join(doc.itertext()).split())
for phrase in market["leftovers"]:
if phrase.lower() in text.lower():
problems.append(f"untranslated text: {phrase!r}")
prices = re.findall(r"[$€£¥₩R]\$?\s?\d[\d.,]*|\d[\d.,]*\s?[$€£¥₩]", text)
wrong = [p for p in prices if market["currency"] not in p]
if wrong:
problems.append(f"{len(wrong)} of {len(prices)} prices not in {market['currency']}, e.g. {wrong[0]!r}")
if not doc.xpath(f"//link[@rel='alternate'][starts-with(@hreflang, '{market['lang']}')]"):
problems.append(f"no hreflang entry for {market['lang']}")
return problemsEn l’exécutant sur deux pages (HTML illustratif, pas un site réel) :
from locqa import market_problems
markets = {
"de": {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
"fr": {"lang": "fr", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
}
pages = { # in practice: the same product page, fetched from inside each market
"de": '<html lang="de"><head><link rel="alternate" hreflang="de" href="/de/p/1"></head>'
'<body><h1>Wasserkocher</h1><p>49,99 €</p><p>Free shipping</p></body></html>',
"fr": '<html lang="fr"><head><link rel="alternate" hreflang="fr" href="/fr/p/1"></head>'
'<body><h1>Bouilloire</h1><p>$49.99</p><p>Ajouter au panier</p></body></html>',
}
for code, page in pages.items():
print(code, market_problems(page, markets[code]) or "ok")de ["untranslated text: 'Free shipping'"]
fr ["1 of 1 prices not in €, e.g. '$49.99'"]La page allemande comporte une expression anglaise restante ; la page française affiche un prix en dollars. Les deux passeraient une relecture de traduction, car les chaînes traduites elles-mêmes sont correctes.
Constituez la liste des expressions restantes à partir de votre propre interface : libellés de boutons, messages de livraison et de commande, messages d’erreur. Ce sont les chaînes les plus souvent ajoutées tardivement. Les formats de prix demandent une attention particulière au-delà du symbole monétaire, car le même symbole peut s’écrire de plusieurs façons ; notre guide sur la normalisation des prix, nombres et dates selon les paramètres régionaux explique comment les analyser de manière fiable.
Étape 3 : l’exécuter selon un calendrier
La localisation se casse après les lancements, pas seulement au lancement. Une nouvelle fonctionnalité, un changement de modèle ou une mise à jour de tarification peuvent casser un marché pendant que tous les autres semblent normaux. Un rythme pratique :
- À chaque publication : un petit ensemble de pages clés (accueil, une catégorie, un produit, panier, commande) sur chaque marché.
- Chaque semaine : un échantillon plus large de pages par marché, y compris celles récemment modifiées.
- Après tout changement à la logique géographique, à la tarification ou au consentement : un passage complet.
Présentez les résultats par marché et par vérification, afin que chaque équipe voie ses propres problèmes. Le marché avec le plus d’échecs est généralement celui qui bénéficie du moins de tests locaux.
Ce que l’automatisation ne détectera pas
Certains problèmes nécessitent toujours une personne qui connaît le marché : une traduction correcte mais qui sonne mal, une image ou une couleur avec une signification locale malheureuse, une exigence légale que le modèle ne couvre pas. Les vérifications automatisées libèrent du temps pour que les personnes consacrent leur relecture à ces aspects, plutôt qu’à chercher des symboles dollar.
Certains sites affichent aussi des couches de consentement et de confidentialité différentes selon le pays, ce qui change à la fois ce que voient les utilisateurs et ce qu’un test automatisé peut atteindre. Notre étude sur les murs de consentement par pays montre à quel point cela varie à travers l’UE.
FAQ
Qu’est-ce que le contrôle qualité de la localisation ?
Tester que chaque version linguistique et chaque marché d’un site fonctionne et se lit correctement pour les visiteurs locaux : traductions, formats de devise et de prix, mise en page, mentions légales, redirections et signaux utilisés par les moteurs de recherche pour trouver chaque version.
Pourquoi ne puis-je pas tester d’autres marchés avec un VPN ?
Vous le pouvez pour un aperçu rapide, mais de nombreux sites reconnaissent les adresses VPN et de centre de données et les traitent différemment des connexions domestiques, de sorte que vous pourriez ne pas voir ce que voit un vrai client local. Les IP résidentielles dans le marché se rapprochent davantage de l’expérience réelle.
Quelles pages dois-je tester sur chaque marché ?
Au minimum la page d’accueil, une page de catégorie, une page produit, le panier et la commande, ainsi que toute page comportant des prix ou du texte légal. Élargissez à un échantillon tournant de pages récemment modifiées.
Comment les bugs de localisation affectent-ils le SEO ?
Des attributs lang erronés, des alternates hreflang cassés et des redirections géographiques forcées peuvent faire en sorte que les moteurs de recherche indexent la mauvaise version linguistique, ou manquent entièrement une version, ce qui coûte de la visibilité sur ce marché.
En résumé
Les bugs de localisation se cachent dans les marchés que personne ne teste. Voyez chaque marché comme le ferait un visiteur local, avec une IP, une langue et un fuseau horaire qui concordent, et exécutez les mêmes vérifications automatisées sur chaque marché après chaque publication. Détectez les problèmes mécaniques (attributs de langue, chaînes restantes, devises, hreflang) par machine, et réservez la relecture humaine à ce que seul un lecteur local peut juger.