Site multilingue : bonnes pratiques UX et SEO pour une entreprise internationale

Traduire un site est la partie facile et celle que tout le monde budgète. L’architecture en dessous est celle qui décide si les autres langues parviendront un jour à concurrencer.

On identifie généralement un site multilingue rattrapé après coup en une quinzaine de secondes. Les versions non anglaises ont des URL anglaises, les métadonnées sont des mots-clés anglais traduits, la structure copie exactement l’anglais, et la validation des formulaires repasse en anglais dès qu’une erreur survient.

C’est lisible. Cela ne concurrence pas. Ce sont deux exigences différentes.

Décidez l’architecture des URL en premier

Il existe trois schémas viables et une erreur courante.

• Sous-répertoires (example.com/fr/) — généralement le bon choix par défaut. L’autorité reste consolidée sur un domaine et l’exploitation est la plus simple.
• Sous-domaines (fr.example.com) — raisonnable quand l’infrastructure ou les équipes sont réellement distinctes.
• Domaines nationaux (example.fr) — signal local le plus fort, coût le plus élevé, et chacun repart de zéro.
• L’erreur : servir des langues différentes à la même URL selon le navigateur ou l’IP. Les moteurs ne voient alors qu’une version, les utilisateurs sont devinés, et personne ne peut faire un lien vers une langue précise.

Localisez aussi les slugs

Si vos pages françaises vivent à /fr/services/website-development, vous avez traduit le contenu et laissé l’adresse en anglais.

Le slug doit être l’expression réellement employée sur le marché — /fr/services/creation-site-web. Il se lit correctement, il correspond aux recherches, et il signale que la page a été conçue pour cette audience plutôt qu’adaptée.

Pour une langue à écriture non latine, le choix entre slugs en écriture native et slugs latins stables est légitime. Ce qui compte est que la décision soit délibérée et cohérente.

hreflang, et l’erreur que presque tout le monde commet

hreflang indique aux moteurs quelle version d’une page montrer à quelle audience. Ce n’est pas difficile, et c’est fréquemment mal implémenté d’une manière précise.

• Chaque page doit pointer vers son équivalent réel, pas vers la page d’accueil de chaque langue. Renvoyer toutes les alternatives vers l’accueil est l’erreur la plus courante et annule tout l’intérêt.
• Les balises doivent être réciproques. Si l’anglais pointe vers le français, le français doit pointer vers l’anglais.
• Incluez une hreflang auto-référençante sur chaque page.
• Ajoutez x-default pour la version de repli.
• Utilisez les bons codes : fr pour le français, fr-CA seulement si vous avez réellement une version canadienne distincte.

Une bonne façon de rester honnête est de générer ces balises depuis une carte de routes unique plutôt que page par page, afin qu’une traduction manquante devienne une erreur de build plutôt qu’un mensonge silencieux.

Localisez plutôt que traduire

Une traduction littérale d’un texte marketing anglais produit un contenu grammaticalement correct et subtilement étranger. Il se lit comme importé, ce qui mine la crédibilité que le site doit construire.

Au-delà du ton, les différences de fond : comment les services se nomment sur ce marché, ce que les acheteurs s’attendent à voir, quelles preuves convainquent, à quoi ressemble un appel à l’action qui n’est pas un impératif traduit.

Le test est de savoir si quelqu’un peut arriver depuis son propre moteur de recherche, dans sa langue, sans jamais remarquer que l’anglais existe.

Faites la recherche de mots-clés par langue

Des mots-clés traduits sont la façon la plus fiable de construire un site qui ne se positionne sur rien.

On cherche différemment selon la langue : formulations différentes, degrés de formalité différents, usage d’emprunts anglais au sein d’une requête par ailleurs non anglaise. Étudiez chaque marché pour lui-même, puis rédigez les métadonnées à partir de cette recherche.

Le droite-à-gauche est structurel, pas cosmétique

Si vous prenez en charge l’hébreu ou l’arabe, le RTL est une décision d’architecture prise au départ, pas une feuille de style ajoutée à la fin.

• Utilisez les propriétés CSS logiques — margin-inline-start plutôt que margin-left. La direction devient alors une propriété du document plutôt qu’un second jeu de règles.
• Définissez dir="rtl" et le lang correct sur le document.
• Inversez ce qui porte une direction : flèches, progression, séparateurs de fil d’Ariane, précédent et suivant.
• N’inversez pas les logos, photographies, visuels produit ou cadres d’appareils. Un téléphone ne se retourne pas avec une langue.
• Vérifiez la typographie séparément. L’hébreu et l’arabe ont d’autres besoins de rythme vertical ; l’interlignage qui convient au latin paraît souvent serré.
• Testez spécifiquement les formulaires : alignement des champs, messages de validation, et la langue de ces messages.

Le sélecteur de langue

Petit composant, effet disproportionné sur l’usage réel des autres langues.

• Basculez vers la page équivalente, pas vers l’accueil. Renvoyer quelqu’un au début est le moyen le plus rapide de lui apprendre à ne plus s’en servir.
• Nommez les langues dans leur propre langue : Français, עברית, pas des drapeaux. Un drapeau désigne un pays, pas une langue, et se trompe pour l’essentiel du monde.
• Rendez-le trouvable sans le rendre envahissant.
• Mémorisez le choix, sans jamais écraser un choix explicite.

Ce qu’on oublie souvent

Prévoyez la maintenance, car c’est là que tout se dégrade

Les sites multilingues échouent lentement. L’anglais reçoit une nouvelle page ; les autres langues non. Six mois plus tard, l’anglais compte vingt pages que les autres n’ont pas, hreflang pointe vers des pages inexistantes, et le site français est discrètement un sous-ensemble.

Décidez dès le départ : chaque page existe-t-elle dans chaque langue, ou certaines sont-elles propres à une langue ? Les deux réponses sont valables. Ce qui ne l’est pas, c’est l’absence de réponse, car la dérive est la valeur par défaut.

En résumé

Le multilingue est surtout un problème d’architecture déguisé en problème de langue. Réglez la structure des URL, la génération du hreflang et les fondations RTL au départ, et la traduction devient la partie simple.

Réglez-les mal et aucune qualité de traduction ne compense. Nos pages création de sites web et référencement décrivent notre approche.