Site multilingue : hreflang, adresses, pièges

Q: Quelle structure d'adresses pour un site multilingue ?

Des sous-répertoires comme /en/ pour presque toutes les entreprises : toutes les versions profitent de la force du même domaine et la gestion reste simple. Des domaines nationaux propres ne valent la peine qu'avec des présences de marché autonomes et une équipe dédiée ; les paramètres de langue dans l'adresse sont à éviter.

L'essentiel en bref

Les sous-répertoires (/en/) sont le bon choix pour la plupart des entreprises – plus simples que des domaines propres, plus efficaces que des paramètres.
hreflang doit être réciproque : chaque version renvoie à toutes les autres, à elle-même et à une version par défaut.
Les adresses doivent être traduites aussi. Un texte anglais sous une adresse française est une traduction à moitié faite.
La redirection automatique selon la langue du navigateur est l'erreur grave la plus fréquente – elle exclut robots et utilisateurs.

La partie technique d'un site multilingue est limitée quand on la met en place correctement une fois – et pénible quand on la corrige après coup. La demi-heure préalable en vaut donc la peine.

La structure d'adresses

Variante	Exemple	Convient à
Sous-répertoire	`exemple.ch/en/`	presque tous – un domaine, une force
Sous-domaine	`en.exemple.ch`	systèmes ou exploitants distincts
Domaine national propre	`exemple.fr`	présences de marché autonomes avec équipe dédiée
Paramètre	`exemple.ch/?lang=en`	rien – à éviter

Les sous-répertoires l'emportent presque toujours, parce que toutes les versions profitent de la force du même domaine. Les domaines nationaux exigent que chacun soit construit séparément – cela ne vaut la peine qu'avec une équipe par marché.

Poser hreflang correctement

Quatre règles qui doivent valoir ensemble. Si l'une est enfreinte, tout le groupe est souvent ignoré.

Réciproque. Si la version française renvoie à l'anglaise, l'anglaise doit aussi renvoyer à la française. Les indications à sens unique sont rejetées.
Auto-référence. Chaque page renvoie aussi à elle-même. Souvent oublié et non optionnel.
Indiquer une version par défaut. Un x-default pour toutes les langues non couvertes.
Adresses absolues. Complètes avec protocole et domaine, pas de chemins relatifs.

Conseil Le code de langue indique d'abord la langue, puis éventuellement la région : fr pour le français en général, fr-CH pour le français en Suisse. Qui n'a qu'une version française prend fr – pas fr-CH. Sinon, les visiteurs français et belges ne se voient pas attribuer la version.

Six erreurs qui rendent un site multilingue invisible

1. Redirection automatique selon la langue du navigateur

L'erreur la plus grave. Les robots arrivent le plus souvent avec un réglage de langue américain et ne voient alors jamais les autres versions. Les utilisateurs non plus n'arrivent plus là où ils voulaient aller.

Correct : afficher un message avec une suggestion, mais ne pas rediriger. Retenir le choix.

2. Adresses non traduites

/en/impressum/ au lieu de /en/legal-notice/. Cela paraît inachevé – et gaspille le mot-clé dans l'adresse.

Correct : traduire les segments d'adresse par langue, les fixer durablement et ne plus les changer.

3. Le canonical pointe vers la langue principale

Si la page anglaise indique la page française comme adresse canonique, vous dites : cette page est un doublon, prends l'autre. Elle disparaît de l'index.

Correct : chaque version linguistique est sa propre adresse canonique.

4. Attribut lang manquant

<html lang="fr"> manque ou est identique dans toutes les versions. Cela ne concerne pas que les moteurs de recherche mais aussi les lecteurs d'écran – où cela produit une prononciation incompréhensible.

Correct : le code adapté par version, posé automatiquement.

5. Un seul sitemap pour tout, sans indications de langue

Sans indications hreflang dans le sitemap, le lien entre les versions manque là où il serait le plus simple à reconnaître.

Correct : hreflang soit dans le sitemap, soit dans le <head> – de façon cohérente à un seul endroit.

6. Pages partiellement traduites

Titres traduits, corps du texte en français. Pour un moteur de recherche, c'est une page sans langue claire – et pour les visiteurs, un problème de confiance.

Correct : mieux vaut moins de pages complètes que toutes à moitié.

Le saviez-vous ?

Traduire ne suffit pas – quatre choses doivent être adaptées au pays et non seulement à la langue : les montants dans la monnaie locale, le cadre juridique applicable, des exemples d'usage local et les formats de date.

Une version anglaise qui cite des francs suisses et la loi suisse révisée sur la protection des données n'est pas une version pour le marché britannique mais une traduction de la page suisse. Cela peut être voulu – mais ce doit être une décision et non un oubli.

L'entretien est le vrai problème

La mise en place est un effort ponctuel. L'entretien est durable – et c'est là que les sites multilingues échouent plus souvent que sur la technique.

Retour de pratique

Au bout d'un an, l'image typique est celle-ci : la langue principale a 40 pages, la deuxième 31, la troisième 22. Les modifications ont été faites dans la langue principale et oubliées dans les autres – et plus personne ne sait quelle version est à jour.

Une seule chose y remédie : une décision de construction. Une modification n'est terminée que lorsqu'elle a été reportée dans toutes les langues. Qui ne peut pas tenir cela devrait proposer moins de langues – trois langues entretenues valent nettement mieux que huit périmées.

Liste de contrôle avant le lancement

Chaque page renvoie par hreflang à toutes les versions, à elle-même et à x-default
Chaque version est sa propre adresse canonique
<html lang> est correctement posé par version
Les segments d'adresse sont traduits et fixés durablement
Aucune redirection automatique selon la langue du navigateur
Le sélecteur de langue est visible et fonctionne sans JavaScript
Montants, références juridiques et exemples sont adaptés, pas seulement traduits
Il existe un processus fixe qui reporte les modifications dans toutes les langues

Prompt

Examine la configuration multilingue de mon site.

Informations :
- Domaine : [adresse]
- Langues : [liste avec codes de langue]
- Structure d'adresses : [sous-répertoire / sous-domaine /
  domaine propre]
- Bloc hreflang d'une page d'exemple :
  [coller le bloc]
- Indication canonical de la même page : [coller]
- Attribut lang de la même page : [coller]
- Y a-t-il une redirection automatique selon la langue du
  navigateur ? [oui / non]
- Les segments d'adresse sont-ils traduits ? [exemple par langue]

Tâches :
1. Vérifie les quatre règles hreflang : réciprocité,
   auto-référence, présence de x-default, adresses absolues.
   Nomme chaque infraction séparément.
2. Vérifie si les codes de langue sont bien choisis – en
   particulier si une indication de région est trop restrictive.
3. Vérifie le canonical et l'attribut lang pour détecter toute
   contradiction avec la version linguistique.
4. Nomme les points de mes indications susceptibles de rendre une
   version invisible, classés par gravité.
5. Restitue le bloc hreflang corrigé en entier.

N'invente aucune adresse – marque ce qui manque par
[à compléter].

Conclusion

Techniquement, un site multilingue se joue à quatre endroits : structure d'adresses, hreflang réciproque, adresse canonique propre par version, absence de redirection automatique. Si ces quatre points sont justes, le reste fonctionne.

La vraie question est ensuite organisationnelle : parvenez-vous à reporter chaque modification dans toutes les langues ? Sinon, moins de langues est la meilleure décision.

Questions fréquentes

Quelle structure d'adresses pour un site multilingue ?

Des sous-répertoires comme /en/ pour presque toutes les entreprises : toutes les versions profitent de la force du même domaine et la gestion reste simple. Des domaines nationaux propres ne valent la peine qu'avec des présences de marché autonomes et une équipe dédiée ; les paramètres de langue dans l'adresse sont à éviter.

Que faut-il observer avec hreflang ?

Quatre règles simultanément : les indications doivent être réciproques, chaque page doit aussi renvoyer à elle-même, il faut un x-default pour les langues non couvertes, et toutes les adresses doivent être absolues. Si une règle est enfreinte, tout le groupe est souvent ignoré.

Faut-il rediriger automatiquement les visiteurs vers leur langue ?

Non. Les robots arrivent le plus souvent avec un réglage de langue américain et ne voient alors jamais les autres versions ; les utilisateurs n'atterrissent pas là où ils voulaient. La bonne solution est un message avec suggestion qui retient le choix fait – sans redirection automatique.

Faut-il traduire les adresses ?

Oui. Un texte anglais sous une adresse française paraît inachevé et gaspille le mot-clé dans l'adresse. Les segments d'adresse devraient être traduits par langue puis fixés durablement – des changements ultérieurs coûtent la visibilité acquise.

Combien de langues sont raisonnables ?

Autant qu'on peut en entretenir durablement. L'état le plus courant après un an, ce sont des versions inégalement complètes dont plus personne ne sait laquelle est à jour. Trois langues entretenues agissent nettement mieux que huit périmées – l'essentiel est un processus fixe qui reporte chaque modification dans toutes les versions.