Tests de localisation : guide étape par étape et liste de contrôle

Résumez ce post avec : 9 min de lecture

Les tests de localisation vérifient qu'un site Web ou une application traduite fonctionne et se lit correctement pour les personnes de chaque marché cible. Il couvre quatre choses : la langue (précis, naturel, cohérent), le mise en page (rien de coupé, de superposé ou de mal reflété), le fonctions (les formulaires, la recherche, le paiement et les e-mails fonctionnent toujours) et le conventions locales (dates, numéros, devises, adresses). Le meilleur processus commence avant la traduction par une pseudo-localisation, puis combine des vérifications automatisées avec une révision par des locuteurs natifs sur les pages réelles.

Ce manuel vous propose un processus étape par étape, une liste de contrôle que vous pouvez copier et les meilleures pratiques qui détectent le plus de bugs pour le moins d'effort.

Principaux points à retenir

Test dans le contexte, sur des pages et des appareils réels. La révision des chaînes dans une feuille de calcul ne résout pas la plupart des problèmes de mise en page et de signification.
Courir pseudo-localisation avant de traduire pour trouver du texte codé en dur et des mises en page qui ne peuvent pas s'étirer.
Budget pour extension de texte. Les étiquettes anglaises courtes peuvent plus que doubler de longueur dans d’autres langues.
Utiliser locuteurs natifs pour le passage linguistique, avec un glossaire et un guide de style afin que les retours soient cohérents.
Re-testez après chaque changement significatif de contenu ou de conception, pas seulement au lancement.

Ce que couvrent les tests de localisation

Zone	Ce que vous vérifiez	Bugs typiques
Linguistique	Précision, ton, terminologie, grammaire, adéquation culturelle	Traductions littérales, termes incohérents, formalité erronée, chaînes non traduites
Visuel / Interface utilisateur	Le texte s'adapte, les polices s'affichent, les miroirs RTL, les images conviennent au marché	Boutons tronqués, texte superposé, glyphes manquants (“tofu”), icônes non en miroir
Fonctionnel	Formulaires, recherche, filtres, paiement, connexion, e-mails, liens	La validation rejette les noms locaux ou les codes postaux, la recherche ignore les accents, les liens vont dans la mauvaise langue
Conventions locales	Dates, heures, numéros, devise, unités, adresses, numéros de téléphone	03/04 lu comme une mauvaise date, un mauvais séparateur décimal, des prix dans la mauvaise devise
SEO et technique	`lang` attribut, titres et descriptions traduits, hreflang, canoniques	Méta-titres anglais sur les pages françaises, hreflang manquant, canoniques pointant vers l'anglais

Tests de localisation vs tests d'internationalisation

Tests d'internationalisation (i18n) vérifie que le produit peut être localisé : le texte n'est pas codé en dur, les mises en page s'étirent, le code gère Unicode, les dates et les devises proviennent des paramètres régionaux. Cela se produit une fois par fonctionnalité, idéalement avant toute traduction.

Test de localisation (l10n) vérifie chacun spécifique version linguistique. Cela se répète pour chaque langue que vous ajoutez.

Les bugs de localisation les plus douloureux sont en réalité des bugs d’internationalisation découverts tardivement. C'est pourquoi la première étape ci-dessous a lieu avant la traduction.

Processus de test de localisation étape par étape

Étape 1 : Définir la portée et les priorités

Énumérez les langues, les marchés (l'espagnol pour l'Espagne et pour le Mexique sont des cibles de test différentes), les pages et les flux concernés, ainsi que les appareils et navigateurs utilisés par vos visiteurs. Le classement s'effectue en fonction de l'impact sur l'entreprise : l'inscription, le paiement et les prix sont placés avant la page carrières.

Étape 2 : Préparer le matériel de référence

Donnez aux testeurs le même matériel que celui utilisé par les traducteurs :

UNE glossaire des termes du produit et de la marque, avec des traductions approuvées et des termes qui doivent rester en anglais.
UNE guide de style par langue : adresse formelle ou informelle, ton, ponctuation, comment écrire des nombres et des unités.
Écrans ou URL pour chaque flux dans la portée et les comptes de test.

Sans cela, les évaluateurs discutent des préférences au lieu de signaler les erreurs.

Étape 3 : Exécuter la pseudo-localisation

Avant une traduction réelle, remplacez le texte source par une version étirée et accentuée, par exemple “Ajouter au panier” → “[Àdd ţö çàŕţ !!!!!]”. Cela montre rapidement:

Chaînes codées en dur (ils restent en anglais simple)
Des mises en page qui cassent quand le texte devient plus long
Personnages qui ne s'affichent pas dans vos polices
Chaînes concaténées (“Vous avez” + count + “éléments”) qui ne peuvent pas être traduits correctement

Corrigez-les maintenant dans le code ou les modèles. C'est bien moins cher que de les trouver en 12 langues plus tard.

Étape 4 : Traduisez, puis vérifiez le texte dans son contexte

Une fois les traductions terminées, les évaluateurs doivent les lire sur la page live ou de mise en scène, pas dans un fichier. Le contexte change de signification : “Livre” peut être un nom ou un verbe, “Gratuit” peut signifier gratuit ou disponible. Vérifier:

Chaque chaîne visible est traduite, y compris les boutons, les messages d'erreur, les info-bulles, le texte alternatif et les e-mails.
Les termes suivent le glossaire.
Le ton et la formalité correspondent au guide de style.
Rien n’est offensant, déroutant ou culturellement décalé dans les images, les couleurs, les exemples et les idiomes.

Étape 5 : Tests visuels et de mise en page

Testez chaque page intégrée aux tailles de bureau et mobile. Portez une attention particulière à :

Extension de texte. L'article du W3C sur taille du texte en traduction cite les directives IBM : les chaînes anglaises allant jusqu'à 10 caractères peuvent s'étendre de 200 à 300 % dans d'autres langues européennes, et les chaînes de plus de 70 caractères d'environ 130 %. Les menus, les boutons, les onglets et les en-têtes de tableau se cassent en premier.
Polices. Recherchez des cases vides ou un changement soudain de police, ce qui signifie que la police ne contient pas ces caractères. Notre liste de polices multilingues couvre les polices par script.
Langues de droite à gauche. L'arabe, l'hébreu et le persan ont besoin que toute la mise en page soit reflétée : navigation, icônes avec direction, barres de progression, champs de formulaire. Consultez notre guide pour Conception RTL.
Rupture de ligne. Des langues comme le japonais, le chinois et le thaï n'utilisent pas d'espaces entre les mots, alors vérifiez que le texte s'enroule judicieusement.

Étape 6 : Tests fonctionnels par lieu

Parcourez chaque flux clé dans chaque langue :

Formulaires accepter les noms locaux (accents, apostrophes, écritures non latines), les codes postaux locaux et les formats téléphoniques, et afficher les messages d'erreur dans la bonne langue.
Recherche et filtres trouvez les résultats avec et sans accents et triez par ordre alphabétique dans l'ordre local.
Check-out affiche la bonne devise, les taxes, les modes de paiement et les options d'expédition.
E-mails et notifications déclenchés par le flux arrivent dans la langue du visiteur.
Liens et redirections gardez le visiteur dans sa langue ; le sélecteur de langue atterrit sur la même page, pas sur la page d'accueil.

Étape 7 : Vérifiez les formats locaux

Dates (03/04/2026 signifie 3 avril dans une grande partie de l'Europe et 4 mars aux États-Unis), heures (12 ou 24 heures), chiffres (1,234.56 contre. 1.234,56 contre. 1 234,56), les devises et leur position, les unités de mesure, l'ordre des adresses et le premier jour de la semaine dans les calendriers.

Étape 8 : Exécutez les contrôles SEO et techniques

Le <html lang> l'attribut correspond à la langue affichée.
Les titres et les méta descriptions sont traduits.
Chaque langue a sa propre URL, avec hreflang reliant toutes les versions et un canonique auto-référencé. Notre article sur balises hreflang auto-référencées montre comment vérifier cela en quelques minutes.
Le contenu principal est effectivement traduit. Google conseils de site multilingues dit-il “utilise le contenu visible de votre page pour déterminer sa langue”, et non des attributs au niveau du code.

Étape 9 : Enregistrer, corriger et tester à nouveau

Enregistrez chaque problème avec la langue, l'URL, la capture d'écran, le texte actuel, le correctif suggéré et une gravité :

Critique: bloque un flux ou change de sens (prix erroné, paiement cassé, texte offensant).
Majeur: clairement erroné ou déroutant, mais la tâche peut être accomplie.
Mineur: style, espacement ou petites incohérences.

Corrigez, puis retestez les pages concernées dans chaque langue, car un seul correctif de modèle les affecte souvent toutes.

Étape 10 : Continuez les tests après le lancement

La localisation n'est pas terminée au lancement. De nouvelles pages, de nouveaux produits et des changements de conception créent de nouvelles chaînes. Ajoutez des contrôles de localisation à votre liste de contrôle de publication et planifiez une révision des pages principales par langue tous les quelques mois.

Liste de contrôle des tests de localisation

Meilleures pratiques

Testez toujours dans votre contexte. Les problèmes les plus graves n’apparaissent que sur la vraie page.

Utilisez des locuteurs natifs qui connaissent le produit. Un locuteur courant qui n’a jamais utilisé votre produit manquera les erreurs terminologiques.

Automatisez ce qui est mécanique. Des comparaisons de captures d'écran, des robots d'exploration qui signalent du texte non traduit ou un hreflang manquant et des tests de formulaire peuvent s'exécuter sur chaque version.

Gardez une source de vérité unique pour les termes. Mettez à jour le glossaire lorsque les évaluateurs sont d’accord sur un changement, afin que le correctif s’étende à chaque page.

Corrigez la cause profonde. Si un bouton se casse en allemand, la solution consiste généralement en une mise en page flexible et non en un mot allemand plus court.

Comment ConveyThis prend en charge les tests de localisation

ConveyThis est construit autour de la révision des traductions dans leur contexte. Le éditeur visuel affiche la page traduite telle que les visiteurs la voient, afin que vous puissiez corriger la formulation et repérer les problèmes de mise en page en même temps. Le glossaire maintient les termes cohérents sur l'ensemble du site, rôles d'équipe vous permet d'inviter des traducteurs et des réviseurs natifs par langue, et la mémoire de traduction réutilise les traductions approuvées. Les pages traduites obtiennent leurs propres URL avec hreflang, et les titres et descriptions sont également traduits, ce qui couvre une grande partie de l'étape 8.

Découvrez comment fonctionne le flux de travail d'examen sur le qualité de la traduction page, ce qui est inclus dans Caractéristiques, et prévoir des limites sur le page de tarification. Pour un processus plus large au-delà des tests, lisez à propos de Localisation de site web.

FAQ

Qu'est-ce que les tests de localisation ? Vérifier que chaque version linguistique d'un site Web ou d'une application est précise, correspond à la mise en page, fonctionne fonctionnellement et suit les conventions locales.

Qu'est-ce que la pseudo-localisation ? Remplacer le texte source par un espace réservé étiré et accentué avant la traduction, pour trouver des chaînes et des mises en page codées en dur qui ne peuvent pas gérer un texte plus long.

Qui devrait faire des tests de localisation ? Testeurs d'assurance qualité pour les contrôles fonctionnels et visuels, locuteurs natifs qui connaissent le produit pour l'examen linguistique et idéalement quelqu'un du marché cible pour l'adéquation culturelle.

À quelle fréquence dois-je effectuer des tests de localisation ? Au lancement, à chaque version qui modifie le texte ou les mises en page, et lors d'un examen périodique des pages les plus importantes par langue.

Vous souhaitez consulter chaque traduction sur la vraie page avant que les visiteurs ne la voient ? Créer un compte ConveyThis et ouvrez votre site dans l'éditeur visuel.