Qu’est-ce qui rend un site réellement multilingue ?

Un site ne devient pas réellement multilingue parce qu’un sélecteur de langue apparaît dans son en-tête.

Le véritable test commence après le clic.

Le menu change-t-il ? Les horaires restent-ils compréhensibles ? Le formulaire de contact utilise-t-il la langue sélectionnée ? Que se passe-t-il lorsque le visiteur atteint l’outil de réservation, le checkout, l’e-mail de confirmation ou un PDF à télécharger ?

De nombreux sites traduisent la première couche visible et abandonnent le reste du parcours client.

La page d’accueil change de langue. Les pages de services ne changent pas.

La navigation est traduite. Les messages d’erreur du formulaire ne le sont pas.

La fiche produit est traduite. Les informations de livraison et le checkout reviennent à la langue d’origine.

Techniquement, le site propose plusieurs langues.

En pratique, le visiteur doit toujours contourner lui-même les lacunes.

Un site réellement multilingue ne doit pas nécessairement traduire immédiatement chaque page historique dans chaque langue. Il doit permettre au public visé d’accomplir le parcours important sans être régulièrement expulsé de la langue sélectionnée.

La traduction n’est pas la même chose qu’une expérience multilingue

La traduction concerne les mots.

Une expérience multilingue comprend tout le parcours autour de ces mots :

trouver la bonne page ;
reconnaître les options linguistiques disponibles ;
comprendre l’offre ;
vérifier les prix, les horaires ou les conditions de livraison ;
remplir un formulaire ;
réserver ou acheter ;
recevoir une confirmation ;
trouver de l’aide lorsqu’un problème survient.

Une entreprise peut disposer de traductions correctes et malgré tout proposer une mauvaise expérience multilingue.

Le contenu traduit peut être caché derrière un menu linguistique peu clair. Un outil de réservation peut s’ouvrir dans une autre langue. La langue choisie peut disparaître lorsque le visiteur suit un lien interne. Les moteurs de recherche peuvent envoyer les personnes vers la mauvaise version. Un e-mail de service client peut arriver dans la langue par défaut du site.

Les mots sont traduits.

Le parcours ne l’est pas.

La langue sélectionnée doit survivre à toute la tâche

Le test pratique le plus simple est le suivant :

Une personne peut-elle choisir une langue et accomplir l’action principale sans être forcée de revenir vers une autre langue ?

Pour un restaurant, cette action peut être :

comprendre le concept ;
consulter le menu ;
confirmer l’emplacement et les horaires ;
réserver une table ;
recevoir une confirmation utile.

Pour une entreprise locale de services :

comprendre le service ;
déterminer s’il correspond au besoin ;
consulter les prix ou conditions ;
envoyer une demande ;
comprendre ce qui se passe ensuite.

Pour une boutique en ligne :

trouver un produit ;
comprendre les détails ;
choisir une taille ou une variante ;
consulter les conditions de livraison et de retour ;
terminer le checkout ;
recevoir les informations de commande.

Lorsque la langue choisie disparaît à mi-parcours, le site n’a pas terminé son travail.

Le visiteur peut peut-être encore se débrouiller.

Cela ne rend pas l’expérience bonne.

Un sélecteur de langue est une promesse

Une option linguistique visible crée une attente.

Lorsqu’un site propose l’anglais, le néerlandais ou le français, le visiteur peut raisonnablement s’attendre à ce que les informations et actions pertinentes soient disponibles dans cette langue.

Cela n’exige pas la perfection.

Une petite entreprise n’a peut-être ni le temps ni le budget pour traduire immédiatement chaque ancien article, communiqué de presse ou page rarement visitée.

Mais le parcours client central doit être honnête.

Si seule une partie du site est traduite, l’entreprise doit décider consciemment quelle partie est complète et quelle partie ne l’est pas. Une option linguistique qui modifie la page d’accueil mais laisse le menu, le formulaire et le processus de réservation inchangés peut créer plus de frustration que l’offre claire d’un plus petit nombre de langues.

Une traduction partielle n’est pas automatiquement inutile.

Une traduction partielle accidentelle constitue le problème.

Traduisez les pages qui aident quelqu’un à agir

La première priorité de traduction n’est pas nécessairement la page qui contient le plus de mots.

Elle doit être la page qui soutient la décision la plus importante.

Pour beaucoup de petites entreprises, l’ordre des priorités ressemble davantage à ceci :

1. L’offre

Que propose l’entreprise ? À qui s’adresse-t-elle ? Combien cela coûte-t-il, ou qu’est-ce qui influence le prix ?

2. Les informations pratiques

Où se trouve l’entreprise ? Quand est-elle ouverte ? Quel établissement, quelle région de livraison ou quelle zone de service s’applique ?

3. L’action suivante

Comment peut-on réserver, acheter, appeler, visiter ou demander des informations ?

4. Les conditions et la réassurance

Quelles sont les conditions de livraison, règles d’annulation, conditions de retour, méthodes de paiement ou limitations importantes ?

5. La confirmation et le suivi

Que se passe-t-il après l’envoi du formulaire, la commande ou la réservation ?

Une archive d’articles traduite peut soutenir la visibilité et la confiance.

Un e-mail de confirmation traduit peut éviter un problème client immédiat.

La priorité doit suivre le parcours client, pas la facilité du système de contenu.

Les parties cachées comptent surtout lorsqu’un problème survient

Les pages les plus faciles à traduire sont généralement celles que l’entreprise voit tous les jours.

Les parties oubliées apparaissent souvent seulement après une action ou une erreur :

messages de champs obligatoires ;
erreurs de paiement ;
horaires de réservation indisponibles ;
notifications de rupture de stock ;
réglages de cookies et de consentement ;
e-mails de réinitialisation de mot de passe ;
confirmations de commande ;
messages d’annulation ;
réponses automatiques du support ;
conditions juridiques ou de livraison.

Ces moments comptent parce que le visiteur essaie déjà de résoudre quelque chose.

Une belle page d’accueil traduite apporte peu de réconfort lorsque l’erreur de paiement est incompréhensible.

Une véritable revue multilingue doit donc tester les parcours réussis et les parcours d’échec.

Ne demandez pas seulement si le formulaire peut être envoyé.

Demandez si la personne comprend ce qu’elle doit corriger lorsqu’il ne peut pas l’être.

Les menus, PDF et outils externes comptent aussi

Les entreprises considèrent souvent les outils externes comme la responsabilité de quelqu’un d’autre.

Le visiteur ne le fait pas.

Le site d’un restaurant peut être traduit alors que le menu n’existe qu’en PDF français. Le site multilingue d’un hôtel peut envoyer le visiteur vers un moteur de réservation uniquement en anglais. Une boutique peut présenter ses produits en néerlandais et utiliser un portail de retour non traduit.

Du point de vue du visiteur, le parcours appartient à une seule entreprise.

Le fait qu’un autre fournisseur gère la dernière étape ne supprime pas la friction.

Les systèmes externes doivent être inclus dans la revue multilingue :

plateformes de réservation ;
outils de paiement et de checkout ;
suivi de livraison ;
centres d’aide ;
cartes et widgets intégrés ;
menus et brochures téléchargeables ;
portails de compte ;
e-mails et messages automatisés.

L’entreprise ne peut parfois pas contrôler entièrement le système externe.

Cette limitation doit tout de même être reconnue et, lorsque c’est possible, expliquée avant que le visiteur ne l’atteigne.

Le site doit mémoriser le choix du visiteur

Choisir plusieurs fois la même langue constitue un travail inutile.

Lorsqu’une personne sélectionne une langue, le site doit normalement conserver ce choix pendant qu’elle navigue. Les liens internes doivent conduire vers la version équivalente lorsqu’elle existe.

Les problèmes fréquents comprennent :

le logo renvoie vers la page d’accueil dans la langue par défaut ;
un bouton d’action mène vers la page dans la langue d’origine ;
les liens d’articles basculent vers une autre langue ;
le sélecteur renvoie toujours vers la page d’accueil au lieu de la page équivalente ;
le checkout ignore la langue de la boutique ;
changer de langue efface l’action en cours.

Ce ne sont pas des erreurs de traduction.

Ce sont des erreurs de navigation et d’implémentation.

Elles rendent le site moins fiable parce que le visiteur ne peut pas prévoir ce que fera le prochain clic.

Les moteurs de recherche ont également besoin d’une structure claire

Les personnes ne sont pas les seules à devoir comprendre la structure linguistique.

Lorsque des URL distinctes existent pour différentes langues ou régions, Google recommande de relier ces versions avec des annotations hreflang, afin que Search puisse orienter les utilisateurs vers une version appropriée. Google recommande aussi des URL distinctes et claires par langue ou région plutôt qu’un contenu modifié uniquement selon la langue ou la localisation supposée du visiteur. (Google Search Central)

Une structure multilingue utile demande donc plus qu’un texte traduit.

Elle doit prendre en compte :

des URL stables pour chaque langue ;
des liens entre les pages équivalentes ;
des codes de langue et de région corrects ;
des titres et descriptions adaptés ;
ce qui se passe lorsqu’aucune traduction équivalente n’existe.

Le terme technique compte moins que le résultat :

Les bonnes personnes doivent pouvoir trouver la bonne version de la page.

La page doit déclarer correctement sa langue

Les pages web peuvent déclarer leur langue principale avec l’attribut HTML lang.

Les recommandations du W3C demandent de déclarer la langue par défaut de la page. MDN indique que cette information aide les technologies d’assistance, comme les lecteurs d’écran, à utiliser la bonne prononciation et le bon comportement linguistique. (W3C Internationalisation) (MDN)

Il s’agit d’un petit détail technique aux effets pratiques.

Une page peut sembler correctement traduite pour une personne voyante et être prononcée incorrectement par un lecteur d’écran parce que la langue sous-jacente n’a jamais été modifiée.

Un site multilingue doit donc contrôler le contenu visible et les informations linguistiques intégrées à la page.

La traduction doit ressembler à l’entreprise

Une traduction littérale peut conserver le sens et affaiblir malgré tout le message.

Une phrase naturelle en anglais peut sembler rigide en français. Une traduction directe en néerlandais peut employer des mots techniquement corrects mais commercialement inhabituels. Le niveau de formalité, la longueur des phrases, l’humour et les appels à l’action ne se déplacent pas parfaitement entre les langues.

C’est là que commence la localisation.

La localisation demande :

Comment ce public le dirait-il naturellement ?
La devise, les dates et unités sont-elles adaptées ?
Le ton correspond-il aux attentes locales ?
Les exemples et références sont-ils compréhensibles ?
L’appel à l’action semble-t-il naturel ?
Le même niveau de formalité est-il utilisé de manière cohérente ?

L’objectif n’est pas de rendre toutes les versions identiques.

L’objectif est de rendre chaque version aussi utile que les autres.

La traduction automatique peut aider, mais quelqu’un doit rester responsable

Les outils de traduction modernes peuvent rendre la publication multilingue beaucoup plus rapide.

Ils peuvent produire un excellent premier brouillon, particulièrement lorsque le texte source est clair.

Ils ne suppriment pas le besoin de décisions.

Quelqu’un doit toujours vérifier :

les noms et termes produits ;
le ton et le niveau de formalité ;
les prix et conditions ;
les informations juridiques ou sensibles ;
les liens ;
les titres et labels d’interface ;
les formulaires et messages ;
si le sens a survécu à la traduction.

Plus la page est importante pour un achat, une réservation ou un engagement juridique, plus la revue doit être délibérée.

L’automatisation peut réduire le travail.

Elle ne peut pas assumer les conséquences.

Un site multilingue a besoin d’une règle de maintenance

La première traduction n’est pas le problème le plus difficile à long terme.

Maintenir les versions alignées l’est.

Une entreprise modifie ses horaires, ajoute un service, change une condition de retour ou remplace un produit. La langue par défaut est corrigée immédiatement. Les autres versions restent inchangées pendant des mois.

Finalement, le site contient plusieurs versions de la vérité.

Un workflow multilingue pratique doit définir :

quelle langue constitue la version source ;
qui est responsable des nouvelles traductions ;
quelles modifications doivent être répercutées immédiatement ;
comment le contenu non traduit est signalé ;
si la publication attend toutes les langues ;
comment les anciennes traductions ou traductions manquantes sont revues ;
ce qui se passe lorsqu’une page est supprimée.

Cela ne doit pas être compliqué.

Un statut simple—draft, translated, reviewed, published—peut éviter beaucoup de confusion.

Un site n’est pas réellement multilingue uniquement le jour du lancement.

Il doit le rester après la prochaine mise à jour.

Toutes les entreprises n’ont pas besoin de toutes les langues

Davantage de langues n’est pas automatiquement mieux.

Chaque langue supplémentaire crée du travail : traduction, revue, support, maintenance, cohérence juridique et contrôle qualité.

Une entreprise doit choisir les langues selon le public qu’elle sert réellement ou souhaite servir.

Les questions utiles comprennent :

Quelles langues utilisent les clients actuels ?
Quels visiteurs abandonnent parce que l’information n’est pas disponible ?
Quels lieux ou marchés sont importants commercialement ?
L’entreprise peut-elle gérer les demandes dans cette langue ?
Quelle partie du parcours doit être disponible en premier ?
La version linguistique peut-elle être maintenue ?

Pour un restaurant bruxellois, le néerlandais et l’anglais peuvent être commercialement utiles même si la communication quotidienne se déroule principalement en français.

Pour une entreprise locale dans une zone étroite, une excellente version dans une seule langue peut être préférable à trois versions négligées.

L’objectif n’est pas d’accumuler des drapeaux dans l’en-tête.

Il consiste à réduire les obstacles inutiles pour le bon public.

Comment Vayluna peut aider

Un propriétaire ne devrait pas devoir devenir spécialiste des sites multilingues pour identifier les lacunes pratiques.

Vayluna peut examiner l’expérience du point de vue d’un visiteur :

quelles langues sont visiblement proposées ;
quelles pages importantes sont réellement disponibles ;
où la langue choisie disparaît ;
si les menus, formulaires et outils externes restent utilisables ;
si l’action suivante est compréhensible ;
quelles corrections semblent prioritaires.

Le résultat doit être une explication claire et hiérarchisée, pas une liste de termes techniques non expliqués.

Ce principe se trouve aussi derrière le Brussels Project en développement, où l’accès multilingue est considéré comme une partie du parcours client plutôt que comme un tableau de score politique.

L’offre plus large de services Vayluna continuera à grandir, mais le standard doit rester simple : identifier le vrai problème, l’expliquer clairement et recommander une étape proportionnée.

Un site réellement multilingue semble complet

Les meilleurs sites multilingues ne rappellent pas constamment au visiteur qu’un travail de traduction a eu lieu.

Ils lui permettent simplement de continuer.

La langue reste sélectionnée.

Les informations importantes sont présentes.

Les boutons mènent à l’endroit attendu.

Les erreurs peuvent être corrigées.

La confirmation peut être comprise.

Le client ne doit pas se demander quelles parties de l’entreprise sont disponibles dans sa langue et lesquelles ne le sont pas.

Voilà la véritable norme.

Pas une rangée d’options linguistiques.

Pas une page d’accueil traduite.

Pas un plugin installé puis oublié.

Un site réellement multilingue permet au visiteur visé d’accomplir le parcours avec confiance.