Les fonctionnalités d’IA font désormais partie de la plupart des produits : un assistant conversationnel sur la page d’aide, une recherche par IA dans une boutique, des descriptions produits générées, un panneau de recommandations. Chacune peut répondre différemment selon l’endroit où se trouve l’utilisateur, et ces différences apparaissent rarement quand l’équipe teste depuis le bureau. Si votre produit s’adresse à plusieurs marchés, vérifier les réponses de l’IA pays par pays a sa place à côté de vos travaux d’IA et de machine learning et de vos tests de mise en production, pas après la plainte d’un marché.
Ce guide explique pourquoi les réponses de l’IA changent selon le pays, quoi vérifier, comment faire passer vos requêtes de test pour celles d’un utilisateur local, et comment comparer des réponses qui ne sont jamais identiques mot pour mot.
Pourquoi les réponses de l’IA changent selon le pays
La plupart des différences viennent du produit qui entoure le modèle, pas du modèle lui-même :
- La localisation comme contexte. De nombreux assistants ajoutent au prompt le pays ou la ville de l’utilisateur, déduits de l’IP. Une mauvaise géolocalisation donne une réponse assurée pour le mauvais marché.
- Le routage régional. Les requêtes peuvent être envoyées vers un modèle, une version ou un endpoint différent selon la région, souvent pour des raisons de résidence des données. Deux marchés peuvent tourner sur des versions de modèle différentes le même jour.
- Les feature flags. Les fonctionnalités d’IA sont souvent lancées pays par pays. Un bouton qui fonctionne sur un marché peut être absent ou cassé sur un autre.
- Les règles de politique et de conformité. Des règles locales sur la santé, la finance, les élections ou l’âge peuvent déclencher des refus ou des avertissements dans certains pays seulement.
- La recherche d’informations. Quand l’assistant interroge le web, un centre d’aide ou un catalogue produits, il le fait généralement avec la région de l’utilisateur, si bien que les faits et les produits cités changent.
Le premier et le dernier de ces points dépendent de l’IP d’où part la requête. C’est pourquoi un test depuis un seul endroit ne les voit pas.
Quoi vérifier sur chaque marché
Pour chaque marché que vous servez, vérifiez le même ensemble de propriétés :
| Vérification | Ce qui peut mal tourner |
|---|---|
| Langue | Des réponses en anglais pour un utilisateur au Japon, ou plusieurs langues mélangées dans une même réponse |
| Devise et unités | Des prix en dollars pour un utilisateur allemand, des miles au lieu de kilomètres |
| Informations locales | Délais de livraison, jours fériés, règles fiscales ou adresses de magasins erronés pour ce pays |
| Disponibilité des fonctionnalités | La fonctionnalité d’IA est masquée, renvoie une erreur ou affiche un message « non disponible dans votre région » |
| Comportement face aux règles | Des refus ou avertissements prévus pour un pays apparaissent partout, ou l’inverse |
| Produits et sources | Des recommandations ou citations d’articles non vendus ou sans intérêt sur ce marché |
| Mise en forme | Dates, nombres et adresses dans le mauvais format local |
Plusieurs de ces points recoupent les vérifications classiques des pages. Notre guide sur la QA de localisation à grande échelle couvre les textes, le hreflang et la mise en page ; cette liste couvre ce que la couche d’IA ajoute par-dessus.
Tester comme un utilisateur local
La localisation vient généralement de l’IP, donc la requête de test doit partir du marché visé. L’envoyer via des proxys résidentiels ciblés sur le pays amène le produit à appliquer la même détection de région, les mêmes flags et les mêmes règles qu’à un vrai utilisateur sur place. Les plages de data center sont souvent rattachées au mauvais pays par les bases de géolocalisation IP, ou soumises à des contrôles anti-bots, ce qui vous donne des résultats de test que personne sur ce marché ne verrait.
Alignez aussi le reste de la requête sur le marché : l’en-tête Accept-Language, le fuseau horaire et les paramètres régionaux du navigateur. Une IP japonaise avec un navigateur en anglais n’est pas le même utilisateur qu’une IP japonaise avec un navigateur en japonais, et les deux méritent d’être testés. Notre article sur l’alignement de la géolocalisation, du fuseau horaire et de la langue du proxy explique comment garder ces signaux cohérents.
Pour une conversation en plusieurs tours, gardez une seule IP pendant tout l’échange grâce à une session sticky, pour que le produit ne voie pas l’utilisateur changer de lieu entre deux messages :
customer-USERNAME-country-jp-sid-chat-ja-01-ttl-600:PASSWORDUn petit banc de test
Le script ci-dessous envoie les mêmes prompts à votre endpoint d’IA depuis plusieurs marchés et vérifie des propriétés plutôt qu’un texte exact. Remplacez l’endpoint et les vérifications par les vôtres.
import requests
GATEWAY = "p.shifter.io:443"
USER, PASS = "USERNAME", "PASSWORD"
ENDPOINT = "https://app.example.com/api/assistant"
MARKETS = {
"de": {"lang": "de-DE", "currency": "€"},
"jp": {"lang": "ja-JP", "currency": "¥"},
"br": {"lang": "pt-BR", "currency": "R$"},
"us": {"lang": "en-US", "currency": "$"},
}
PROMPTS = ["How much is shipping for a 2 kg parcel?", "Recommend a laptop under my budget."]
RUNS = 3
def ask(country, lang, prompt, run):
proxy = f"http://customer-{USER}-country-{country}-sid-ai-{country}-{run}-ttl-600:{PASS}@{GATEWAY}"
r = requests.post(ENDPOINT, json={"message": prompt},
headers={"Accept-Language": lang},
proxies={"http": proxy, "https": proxy}, timeout=60)
return r.status_code, r.json().get("answer", "") if r.ok else ""
for country, m in MARKETS.items():
for prompt in PROMPTS:
hits = 0
for run in range(RUNS):
status, answer = ask(country, m["lang"], prompt, run)
if status == 200 and m["currency"] in answer:
hits += 1
print(country, prompt[:30], f"currency ok in {hits}/{RUNS} runs")Ajoutez une vérification par ligne du tableau ci-dessus : un détecteur de langue pour la réponse, une liste des produits vendus sur chaque marché, un motif pour le message régional « non disponible ». Lancez chaque prompt plusieurs fois, car les réponses du modèle varient d’une exécution à l’autre ; une vérification qui réussit deux fois sur trois est un constat, pas du bruit.
L’intégrer aux tests de mise en production
- Lancez le banc de test après chaque changement de modèle, de prompt ou de flag, depuis tous les marchés, pas seulement depuis la région par défaut.
- Gardez un jeu de prompts fixe par marché, rédigé par des locuteurs natifs, avec les questions que les clients posent vraiment sur place.
- Enregistrez les réponses avec le pays, la version du modèle et l’heure, pour distinguer un changement de modèle d’un changement de routage.
- Passez en revue les refus par pays chaque semaine. Un taux de refus qui bondit sur un marché signale généralement une règle de politique ou un endpoint régional.
Si vos fonctionnalités d’IA apparaissent aussi dans la recherche, la même méthode par marché s’applique au suivi de la visibilité dans la recherche par IA, où la question est de savoir ce que les autres assistants disent de vous dans chaque pays.
En résumé
Les réponses de l’IA sont locales, car le produit qui entoure le modèle lit la localisation de l’utilisateur et agit en conséquence. Testez chaque marché depuis une IP résidentielle située sur ce marché, avec la langue et les paramètres régionaux correspondants, gardez les conversations en plusieurs tours sur une seule IP sticky, et vérifiez sur plusieurs exécutions des propriétés comme la langue, la devise, les informations locales, la disponibilité et les refus. Faites-le à chaque mise en production, et les bugs d’IA régionaux ne seront plus découverts en premier par vos clients.