UX multilingue : adapter les interfaces aux utilisateurs
Une interface multilingue doit permettre d’accomplir la même tâche dans chaque langue : trouver une offre, comprendre un prix, remplir un formulaire ou suivre une commande. Traduire les paragraphes ne suffit pas si les boutons, erreurs et confirmations restent dans une autre langue ou si le changement de langue fait perdre le parcours.
Pour un site suisse en français et en anglais, préparez les deux parcours et testez-les sur de vrais écrans. Ce guide fournit des exemples FR/EN et une grille de validation. Les exemples sont fictifs et ne décrivent pas des résultats clients.
Distinguer traduction, localisation et préparation technique
La traduction adapte les textes. La localisation adapte aussi les formats et les informations utiles au public visé. L’internationalisation prépare le produit à accueillir ces variantes sans reconstruire son fonctionnement pour chaque langue. Définitions du W3C.
Pour votre projet, posez des questions concrètes : qui lit la version anglaise, dans quels pays, avec quelles devises et quels moyens de contact ? Une langue ne désigne pas un pays. Un visiteur anglophone peut habiter Genève et un visiteur francophone peut commander depuis l’étranger.
Ne déduisez pas les préférences de navigation de stéréotypes nationaux. Examinez les questions reçues, les parcours observés et les résultats de tests avec les personnes concernées. Notez ce qui relève d’une hypothèse à vérifier.
Donner un choix de langue compréhensible
Affichez les noms des langues dans leur propre langue, par exemple « Français » et « English ». Un drapeau représente un pays et laisse ambiguë la langue proposée. Gardez le sélecteur accessible sur mobile, au clavier et avec les technologies d’assistance.
Quand une version équivalente existe, le changement de langue doit conduire à cette page. Une personne lisant une prestation ne devrait pas devoir la retrouver depuis l’accueil. Si la traduction manque, annoncez-le et proposez un chemin explicite plutôt que de donner l’impression qu’elle existe.
Pour les formulaires, décidez ce qui peut être conservé lors du changement de langue. Évitez de perdre sans avertissement des informations déjà saisies. Cette conservation exige des choix techniques et de protection des données ; elle ne doit pas être promise avant d’être testée.
Tester les textes dans la mise en page
Un libellé traduit peut être plus long, plus court ou nécessiter une autre coupure. Une réserve uniforme de 30 % ne remplace pas le test des textes réels. Le W3C explique pourquoi les variations dépendent notamment de la longueur du texte et des langues. Taille des textes traduits.
Vérifiez les boutons, menus, onglets, cartes, filtres, tableaux et fenêtres de confirmation. Le texte doit pouvoir revenir à la ligne sans masquer une action ou changer son sens. Testez aussi les nombres longs, noms composés et messages d’erreur.
Exemple fictif : un bouton de demande
Une maquette affiche « Get a quote » dans un bouton étroit. Sa version « Demander un devis » déborde. Agrandir la zone disponible, autoriser une coupure adaptée ou revoir le composant est préférable à supprimer une partie du message uniquement pour faire tenir le texte.
Le couple « Envoyer » / « Send » convient à un formulaire si le contexte explique ce qui sera envoyé. Une confirmation comme « Votre demande a été envoyée » / « Your enquiry has been sent » indique ensuite ce qui s’est passé. N’ajoutez une promesse de délai de réponse que si l’équipe peut la tenir.
Traduire tout le parcours, y compris les erreurs
Inventoriez les libellés, aides, messages de validation, états vides, confirmations, emails et documents liés. Les textes générés par des outils externes doivent aussi être examinés : réservation, paiement, recherche ou CRM peuvent avoir leurs propres réglages de langue.
Un champ ne doit pas demander un format sans le préciser. « Date souhaitée » / « Preferred date » peut être accompagné d’un exemple explicite ; testez ce que le composant accepte et la façon dont il reformule la date. Pour un numéro de téléphone international, évitez de refuser un numéro valide uniquement parce qu’il n’a pas un format suisse.
Les erreurs doivent expliquer le problème et la correction dans la langue active. « Saisissez une adresse e-mail valide » / « Enter a valid email address » aide davantage qu’un code d’erreur isolé. Placez l’information près du champ et vérifiez qu’elle est accessible.
Rendre les formats explicites
La date « 03/10/2026 » peut être comprise différemment selon les habitudes. Dans un document destiné à être lu, « 3 octobre 2026 » / « 3 October 2026 » rend l’exemple clair. Pour une interface de saisie, choisissez un format explicite et vérifiez sa restitution dans les deux langues.
Affichez la devise avec le prix, par exemple CHF, et précisez les conditions qui changent la décision : TVA, livraison, périodicité ou renouvellement, selon l’offre. Ne modifiez pas ces conditions en traduisant. Un prix mensuel et un prix annuel ne deviennent pas équivalents parce que leurs libellés sont courts.
Pour une réservation, indiquez le fuseau horaire lorsque le public peut se trouver ailleurs. Testez les noms et adresses avec accents, apostrophes et caractères utilisés par vos clients. Confiez la gestion des formats aux composants appropriés et vérifiez leurs sorties réelles.
Déclarer la langue pour les outils de lecture
L’attribut HTML lang indique la langue du contenu et aide notamment les outils de lecture à choisir une prononciation adaptée. Déclarez la langue de la page et les changements de langue pertinents dans son contenu. WCAG 3.1.2 prévoit des exceptions, notamment pour les noms propres, les termes techniques et certains mots empruntés intégrés au langage courant. Déclarations de langue du W3C.
Cette déclaration remplit une fonction différente des annotations hreflang, qui relient les versions pour les moteurs de recherche. Elle ne remplace ni la traduction des messages ni leur vérification avec un lecteur d’écran. Notre guide sur les hreflang et canonical traite les annotations SEO ; notre guide d’accessibilité web traite les autres contrôles du parcours.
Utiliser une grille de validation FR/EN
Cette grille est un outil de projet proposé par EWM, pas une certification. Pour chaque contrôle, conservez le résultat, une capture si utile et la personne qui vérifiera la correction.
Navigation
Critère à vérifier dans les deux langues — Les intitulés sont compréhensibles et les liens conduisent au bon contenu.
Changement de langue
Critère à vérifier dans les deux langues — La page équivalente est ouverte ; toute traduction manquante est annoncée.
Mise en page
Critère à vérifier dans les deux langues — Textes, boutons et erreurs restent lisibles sur mobile et avec agrandissement.
Formulaire
Critère à vérifier dans les deux langues — Libellés, formats, validation et confirmation sont cohérents et accessibles.
Conditions
Critère à vérifier dans les deux langues — Prix, devise, délais et périmètre de l’offre ont le même sens.
Outils externes
Critère à vérifier dans les deux langues — Paiement, réservation et messages associés suivent la langue prévue.
Lecture assistée
Critère à vérifier dans les deux langues — La langue déclarée et les annonces permettent de comprendre la tâche.
Faites ensuite tester une tâche concrète : trouver une prestation, comparer une condition et envoyer une demande, par exemple. Observez où la personne hésite ou revient en arrière. Demandez-lui ce qu’elle pense avoir envoyé et ce qu’elle attend ensuite. Ces réponses révèlent des ambiguïtés qu’une simple relecture peut manquer.
Maintenir les deux versions après le lancement
Attribuez un responsable aux textes et à la validation métier. Quand une prestation, un tarif ou une condition change, suivez aussi les boutons, formulaires et documents associés. Publier une version sans mettre à jour l’autre peut créer une différence dans l’offre comprise par les visiteurs.
Conservez les termes approuvés et le contexte des messages pour les traducteurs. Évitez de composer des phrases à partir de fragments qui imposent le même ordre des mots partout. Testez les variantes et les pluriels avec les valeurs réellement affichées.
Pour votre projet de design UI/UX, rassemblez vos langues, parcours prioritaires et textes existants. Nous pouvons vous aider à concevoir les composants et les contrôles nécessaires pour que les visiteurs accomplissent leur tâche dans chaque version.