Les proxys de traduction de sites web peuvent-ils supporter les tests A/B multilingues ?

Dernière mise à jour : 15 octobre 2026

Comment fonctionnent les trois méthodes d'exécution d'un test via un proxy de traduction ?

C’est l’architecture de test, et non le fournisseur de tests, qui détermine ce que le proxy doit faire. Chaque couche inférieure associe un type de test au mécanisme de traduction qui conserve ses variantes dans la langue.

• Tests côté serveur — votre serveur ou CMS choisit la variante et retourne son HTML, et le GDN traduit ce HTML en transit comme n’importe quelle autre page. Le GDN envoie un en-tête X-Language-Locale à chaque requête au site source, de sorte que la logique serveur peut également cibler ou exclure un test par langue (Smartling Help Center, « Smartling Headers »).
• Tests côté client — un script de test réécrit le texte dans le navigateur après le chargement de la page. DCS capture le texte écrit via des méthodes et propriétés DOM telles que innerHTML, textContent et appendChild, envoie de nouvelles chaînes de caractères au projet GDN, et insère les traductions publiées sur la page suivante (Smartling Help Center, « Dynamic Content Support (DCS) for the GDN »).
• Tests à URL divisée — les visiteurs sont redirigés vers une page variante avec sa propre URL. Le GDN réécrit les liens vers la version localisée de chaque URL et transmet les redirections de votre serveur au visiteur (Smartling Help Center, « A Technical Guide into How the Global Delivery Network Works » ; « Handling Redirections »).
• Les variantes spécifiques au marché — un test qui ne doit être exécuté que dans une seule langue ou afficher un texte différent selon le marché — peuvent utiliser Content Swaps pour les modifications en page ; à grande échelle, Smartling recommande de diffuser du contenu spécifique à la langue depuis le CMS à l’aide de l’en-tête X-Language-Locale (Centre d’aide Smartling, « Créer et traduire du contenu spécifique à la langue »).
• Une solution de repli pour la traduction en attendant la publication de la traduction automatique provisoire — Site-Wide MT fournit aux nouvelles chaînes une traduction automatique provisoire jusqu'à ce que la traduction révisée soit publiée, et elle fonctionne également sur le contenu capturé par DCS, de sorte que les visiteurs localisés voient une traduction automatique plutôt que le texte dans la langue source pendant que la révision se termine.

Test A/B multilingue via le GDN : les chiffres

Les chiffres de calendrier comptent plus qu’ils n’en ont l’air : ils déterminent à quelle avance une version de lancement test doit être traduite et publiée.

Comment réaliser un test A/B multilingue via un proxy de traduction ?

Cinq étapes permettent à chaque variante de rester dans la langue, du premier visiteur au dernier.

1. Cartographiez où chaque variante est assemblée — Vérifiez si l’outil de test construit des variantes sur le serveur, dans le navigateur ou sur des URL distinctes, car cela détermine si le proxy ou le DCS les traduit.
2. Capturez le texte des variantes avant le lancement — Chargez chaque variante sur un site de test acheminé via le GDN afin que ses chaînes de caractères soient capturées et puissent être traduites avant l'arrivée du trafic réel.
3. Traduire et publier avant la date de début — Acheminer les nouvelles chaînes vers un travail de traduction, puis autoriser la reconstruction du fichier de traduction DCS jusqu’à 20 minutes avant d’activer le test. Activez le mode MT à l’échelle du site comme filet de sécurité pour tout ce qui est manqué.
4. QA pour chaque variante dans chaque lieu — Consultez chaque variante sur chaque site localisé, vérifiez le texte dans la langue source, les mises en page cassées et le texte alternatif non traduit, et confirmez que DCS fonctionne depuis le message « Smartling DCS library » dans la console du navigateur.
5. Segmentez les résultats par langue et nettoyez -les : générez un rapport de résultats par langue, terminez le test dès qu’il dispose de suffisamment de données et supprimez les URL et scripts de variantes, comme le recommandent les instructions de test de Google.

Les tests via un proxy de traduction conviennent aux équipes qui...

• Ils traduisent déjà leur site web avec un proxy et veulent faire des tests de conversion sur tous les marchés, pas seulement dans la langue source.
• Utilisez un outil de test basé sur navigateur sur les pages d’atterrissage, où une copie variante est injectée après le chargement de la page.
• Lancer rapidement les tests et avoir besoin d'une traduction automatique provisoire pour couvrir les variantes en attendant la publication des traductions révisées.
• J'ai besoin de réaliser des tests sur un seul marché, ou avec un contenu spécifique à ce marché, sans créer de sites localisés distincts.

Quand un proxy de traduction n'est peut-être pas la solution idéale pour résoudre les tests multilingues

• Les pages de chaque marché sont rédigées en langue dans le CMS, donc les variantes doivent être construites et testées là-bas et exclues de la traduction proxy.
• Le test concerne des messages transcréés écrits séparément par marché, où la version variante est une nouvelle écriture plutôt qu’une traduction de la source.
• Le trafic localisé est trop faible pour obtenir un résultat fiable dans un délai raisonnable ; dans ce cas, tester sur le marché source et déployer la solution gagnante est la voie la plus rapide.

Liste de contrôle d'évaluation : questions à se poser avant de réaliser des tests A/B sur un site traduit

Le proxy traduit-il le texte qu’un script de test écrit dans la page après son chargement ?
Demandez comment les modifications effectuées dans le navigateur sont capturées. Smartling indique que DCS intercepte les écritures DOM telles que innerHTML et textContent et capture le contenu tiers ; confirmez sur un projet pilote que les variantes de votre outil de test sont bien détectées.

Combien de temps s’écoulent entre la publication d’une traduction et la lecture par les visiteurs ?
Obtenez ce chiffre en minutes, car il détermine votre délai de lancement. Pour le contenu capturé par DCS, la figure peut atteindre 20 minutes (Smartling Help Center, « Dynamic Content Support (DCS) for the GDN »).

Que voient les visiteurs localisés avant qu'une variante ne soit traduite ?
La réponse la plus sûre est une traduction automatique provisoire, et non le texte source. Demandez si cette solution de repli couvre également le contenu du navigateur.

Un test peut-il cibler, exclure ou varier selon la langue ?
Recherchez un signal linguistique que votre serveur ou CMS peut lire, comme l’en-tête X-Language-Locale, ainsi qu’un moyen de modifier la copie par localisation, comme les échanges de contenu.

Les variantes de chaînes seront-elles automatiquement routées pour la traduction ?
Demandez s'il est possible de filtrer les nouvelles chaînes de caractères dans les tâches par page ou par source de capture. Dans Smartling, les chaînes capturées par DCS comportent un préfixe /origin-pjs/ sur lequel les règles d'automatisation des tâches peuvent effectuer un filtrage.

Comment les chiffres de trafic proxy se rapportent-ils à mes analyses ?
Le nombre de requêtes proxy et les pages vues analytiques mesurent des choses différentes, donc attendez-vous à ce qu’ils diffèrent ; la réconciliation explique pourquoi les comptes de requêtes proxy de traduction ne correspondent pas à Google Analytics.

Mon serveur peut-il toujours voir qui est le visiteur ?
Le ciblage côté serveur nécessite la véritable adresse IP et le protocole du visiteur. Le GDN transmet les en-têtes X-Forwarded-For et X-Forwarded-Proto au site source précisément pour cette raison.

Comment Smartling conserve-t-il la traduction des variantes du test A/B ?

Le Global Delivery Network (GDN) de Smartling associe un proxy de traduction au Dynamic Content Support (DCS), et à eux deux, ils gèrent à la fois les variantes rendues sur votre serveur et celles rendues dans le navigateur. Les variantes que votre serveur rend sont traduites en transit par le proxy, qui ajoute en moyenne environ 40 millisecondes par requête localisée. Les variantes qu’un script de test écrit dans le navigateur sont capturées par DCS, qui surveille la page pour détecter des textes nouveaux ou modifiés, la compare à un fichier de traduction publiée, et envoie tout ce qui est nouveau à votre projet GDN ; DCS est activé par défaut pour les projets GDN créés après août 2023 (Smartling Help Center, « Dynamic Content Support (DCS) for the GDN »).

Autour de ces deux mécanismes se trouvent les contrôles dont un programme de test a besoin. L’en-tête X-Language-Locale indique à votre serveur à quelle langue chaque requête s’adresse, permettant ainsi de cibler les tests côté serveur par marché, et X-Forwarded-For préserve l’IP du visiteur pour le géociblage. Les échanges de contenu modifient le texte ou le HTML sur un seul endroit, les règles Ne pas traduire et l’attribut translate="no » empêchent les variantes en langue d’être traduites, et le TM à l’échelle du site affiche une traduction automatique provisoire pour toute chaîne de variantes encore en cours d’examen. Les chaînes capturées par DCS appartiennent au même projet GDN en tant que contenu proxy, donc la même mémoire de traduction, le même glossaire et les mêmes règles d’automatisation des emplois s’appliquent aux copies de test que pour le reste du site.

Questions connexes

• Comment les proxys de traduction de sites web protègent-ils le SEO multilingue ?
• Pourquoi le nombre de demandes de proxy de traduction de sites web ne correspond-il pas à Google Analytics ?
• Quels sont les SLA de disponibilité et les performances de vitesse de chargement des pages que vous pouvez attendre d'un proxy de traduction de site web ?
• Comment fonctionnent les widgets et les plugins de traduction de sites web ?