Développement d'un site multilingue : structure, URL et circuit de travail
Ajouter des langues à un site est rarement une simple traduction. Cela change la structure des URL, ajoute un jeu de balises réciproques qui casse en silence, et introduit un circuit de contenu où une page devient douze pages qui peuvent diverger.
Ce guide couvre les décisions structurelles, les exigences techniques, et le circuit de travail qui empêche les traductions de se périmer.
Décidez d'abord le motif d'URL#
C'est la décision coûteuse à défaire, car elle touche chaque URL, chaque redirection et chaque balise hreflang du site.
| Motif | Exemple | Quand il convient |
|---|---|---|
| Sous-dossier | site.com/fr/guides | La plupart des sites : le plus simple, un domaine accumule l'autorité |
| Sous-domaine | fr.site.com/guides | Infrastructure distincte ou équipes distinctes |
| Domaine national | site.fr/guides | Engagement local fort, et un site distinct à gérer |
| Paramètre | site.com/guides?lang=fr | À éviter : signaux faibles, risque de doublons |
Décidez séparément si le segment d'URL est traduit. Des segments traduits aident la pertinence locale ; des segments identiques sont plus simples à maintenir. Les deux se défendent — changer d'avis ensuite non.
Les exigences techniques#
Chacune échoue en silence, et c'est pourquoi tant de sites multilingues n'ont aucun hreflang fonctionnel malgré la présence des balises.
- hreflang réciproque. Chaque page d'un ensemble linguistique liste toutes les autres, elle-même comprise. Une référence inverse manquante fait rejeter le groupe.
- Des codes cohérents. Le même code dans le HTML et dans le sitemap. Deux codes pour une page cassent l'ensemble.
- x-default pointant vers le sélecteur de langue ou la version par défaut.
- Des attributs lang et dir corrects sur l'élément html de chaque version.
- Une canonique auto-référencée par langue — ne canonicalisez jamais les traductions vers l'original.
- Aucune redirection automatique par IP ou langue du navigateur. Cela casse l'exploration et écrase un choix délibéré ; proposez plutôt une suggestion.
- Des métadonnées traduites. Titres et descriptions dans la langue cible, pas dans la langue source.
Un circuit de traduction qui tient#
Le mode d'échec n'est pas la première traduction, c'est la cinquième modification de la page française qui n'atteint jamais les onze autres.
- Modélisez les traductions comme des versions liées d'un même élément de contenu, pour que le système sache qu'elles vont ensemble.
- Suivez quelles traductions sont périmées par rapport à la source, et affichez-le dans l'interface d'édition.
- Décidez ce qui se passe quand une traduction manque : repli sur la langue par défaut, ou ne pas publier cette URL du tout.
- Ne publiez jamais une URL sans traduction : une page à moitié affichée dans une autre langue est pire que pas de page du tout.
- Tenez une date de revue par langue, pas par élément de contenu.
- Donnez du contexte aux personnes qui traduisent : une capture ou un aperçu vaut mieux qu'un tableur de chaînes.
- Décidez qui est responsable de chaque langue. Les langues sans responsable se périment en premier.
La traduction automatique comme point de départ, c'est acceptable ; la publier sans relecture non. Une sortie non relue se lit comme non relue, et c'est exactement le type de contenu de faible valeur sur lequel les moteurs sont de plus en plus explicites.
Au-delà du texte#
La traduction est la partie que tout le monde budgète. Voici les parties qu'on oublie et qui causent des erreurs visibles.
| Élément | Ce qui change |
|---|---|
| Dates et nombres | Le format et les séparateurs diffèrent selon la région |
| Devise | Symbole, position et conventions d'arrondi |
| Adresses et numéros de téléphone | Ordre des champs et règles de validation |
| Noms | L'ordre prénom / nom n'est pas universel |
| Longueur du texte | L'allemand et le finnois s'allongent ; les mises en page doivent céder |
| Sens de lecture | L'arabe et l'hébreu demandent des propriétés CSS logiques |
| Images contenant du texte | Une version par langue, ou pas de texte dans l'image |
| Pages légales | Les exigences diffèrent par juridiction, pas seulement par langue |
Questions fréquentes
Dois-je rediriger automatiquement les visiteurs vers leur langue ?
Non. La redirection automatique par IP ou langue du navigateur perturbe l'exploration — un robot venant d'un pays peut ne jamais voir les autres versions — et écrase des choix délibérés, ce qui est exaspérant pour qui lit dans une seconde langue. Affichez une suggestion que l'on peut fermer et laissez la personne décider.
La traduction automatique est-elle acceptable ?
Comme premier jet oui, et elle fait économiser de l'argent réel. Publiée sans relecture humaine, elle produit un contenu qui se lit comme généré par machine, ce qui touche à la fois les utilisateurs et l'évaluation de la qualité en recherche. L'approche pragmatique est traduction automatique plus relecture native, surtout pour les pages qui vendent ou expliquent quelque chose d'important.
Qu'est-ce qui casse le plus souvent hreflang ?
Des balises non réciproques : la page A liste la B, la B ne liste pas la A, et tout le groupe est ignoré. En deuxième, des codes discordants entre HTML et sitemap. On évite les deux en générant hreflang depuis une source unique faisant foi plutôt qu'en maintenant deux listes.
Dois-je traduire tout le site ?
Non, et une traduction partielle est normale. Traduisez ce qui a de la demande sur ce marché et laissez le reste n'exister que dans la langue source. Ce qu'il ne faut pas faire, c'est publier une URL vide ou à moitié traduite : soit la page existe correctement dans cette langue, soit elle n'existe pas du tout.
site web multilinguehreflangtraduction de site webseo internationalcms multilinguelocalisation
