Un site EmDash multilingue : les trois approches et ce qu'elles coûtent
Sous-dossier, sous-domaine ou domaine par langue : ce que chaque structure implique pour les URL, le référencement et la charge éditoriale réelle.
Publier dans plusieurs langues paraît être une question technique. C’en est une, marginalement. C’est d’abord une décision de structure, et elle est difficile à revenir en arrière une fois les URL en ligne.
Trois approches existent. Elles n’ont pas le même coût, ni la même conséquence.
Les trois structures
| Structure | Forme d’URL | Ce qu’elle implique |
|---|---|---|
| Sous-dossier | site.com/fr/, site.com/en/ | Un seul domaine, une seule installation |
| Sous-domaine | fr.site.com, en.site.com | Séparation nette, configuration DNS par langue |
| Domaine par langue | site.fr, site.com | Autonomie totale, coût multiplié |
Le sous-dossier est le choix par défaut, et le bon dans la grande majorité des cas. Une seule installation, un seul certificat, un seul domaine à gérer, et l’ensemble des signaux acquis reste concentré sur un même hôte.
Le sous-domaine se justifie quand les versions sont réellement autonomes — équipes distinctes, contenus qui divergent, infrastructures séparées. Il fragmente en revanche ce qui se serait cumulé sur un domaine unique.
Le domaine par langue ne se justifie que dans un cas : quand chaque marché a une identité propre, un nom différent, et une équipe locale. C’est le plus coûteux à tous points de vue — achat, renouvellement, certificats, administration — et le sujet rejoint les considérations de mise en production.
Le choix se fait avant la première publication. Changer de structure ensuite suppose un plan de redirections complet, avec tout ce que cela comporte de perte, comme le décrit la migration WordPress et les redirections.
Ce que le contenu structuré permet
L’architecture d’EmDash, décrite dans le guide de l’architecture, place le contenu dans des collections de fichiers typés. C’est un avantage réel pour le multilingue, pour une raison simple : la langue devient une donnée du contenu, pas une couche superposée.
Deux organisations se rencontrent.
Une collection par langue — content/fr/, content/en/. La séparation est nette, chaque langue vit sa vie, et rien n’oblige les deux arborescences à se ressembler.
Une clé de langue dans le frontmatter, avec un identifiant commun reliant les traductions d’un même contenu. C’est plus souple pour générer les liens entre versions, et cela demande une discipline de nommage.
La seconde approche est la plus confortable dès qu’on veut afficher un sélecteur de langue qui pointe vers la traduction de la page courante, et non vers l’accueil de l’autre langue — nuance qui paraît mineure et qui change complètement l’expérience.
Le point technique qui compte : déclarer les correspondances
C’est l’élément que les implémentations improvisées oublient, et il a un effet direct.
Chaque page doit déclarer ses équivalents dans les autres langues, et cette déclaration doit être réciproque : si la page française pointe vers l’anglaise, l’anglaise doit pointer vers la française. Une déclaration unilatérale est ignorée.
Trois règles pratiques :
- déclarer aussi la page elle-même dans son propre jeu de correspondances ;
- prévoir une entrée par défaut pour les visiteurs dont la langue ne correspond à aucune version ;
- ne déclarer que les correspondances qui existent réellement — pointer vers une traduction absente est pire que ne rien déclarer.
Chaque version doit par ailleurs porter sa propre canonique, vers elle-même. C’est un point vérifié dans la liste de contrôle du référencement d’un site EmDash.
La redirection automatique, à éviter
Détecter la langue du navigateur et rediriger d’office paraît attentionné. C’est une mauvaise idée, pour trois raisons.
Elle empêche l’accès volontaire à une autre version : un francophone qui veut lire la page anglaise se retrouve renvoyé.
Elle perturbe l’exploration : un robot qui se présente sans préférence de langue, ou avec une préférence unique, ne verra jamais qu’une version du site.
Elle se trompe souvent : la langue du navigateur ne dit rien du pays, ni de la préférence réelle.
La bonne pratique est de proposer sans imposer : un sélecteur visible, éventuellement une suggestion discrète, et le respect du choix une fois fait.
La charge réelle, qui n’est pas technique
C’est le point sur lequel les projets multilingues échouent, et il n’a rien à voir avec le code.
Chaque publication est multipliée. Un site en trois langues demande trois fois le travail éditorial, à chaque article, indéfiniment. Une équipe qui tient un rythme dans une langue ne le tiendra pas dans trois.
Les versions divergent. Au bout de six mois, la version secondaire a deux articles de retard, puis dix. Un site dont une langue est visiblement abandonnée fait moins bonne impression qu’un site monolingue assumé.
La traduction n’est pas de l’adaptation. Un contenu traduit mot à mot fonctionne rarement : les exemples, les références, les questions posées diffèrent d’un marché à l’autre.
D’où une recommandation qui paraît défaitiste et qui ne l’est pas : commencer par un sous-ensemble. Traduire les pages structurantes plutôt que l’intégralité, et n’étendre que si le trafic le justifie. Un site avec dix pages solides dans une seconde langue vaut mieux qu’un site avec cent pages dont soixante-dix sont périmées.
Ce qu’il reste à faire soi-même
EmDash fournit la structure de contenu et le routage. Trois choses restent à votre charge.
Le fil d’actualité et le plan du site par langue. Chaque version doit avoir les siens, et le plan général doit les référencer.
Les chaînes de l’interface — navigation, boutons, messages — qui ne vivent pas dans les collections de contenu et se gèrent séparément.
Les formats. Dates, nombres, devises et sens de lecture ne se traduisent pas : ils se localisent. C’est le détail qui distingue un site réellement multilingue d’un site traduit.
Enfin, si le multilingue s’accompagne d’une équipe élargie, la question des accès se pose immédiatement — elle est traitée dans rôles et permissions dans EmDash.
Le plan du site et le fil d’actualité
Deux fichiers générés qu’un site multilingue doit traiter explicitement, et qui sont souvent laissés en configuration mono-langue.
Le plan du site doit référencer les URL de toutes les langues. Deux organisations sont valides : un plan unique listant l’ensemble, ou un plan par langue rassemblé dans un index. La seconde est plus lisible dès que le volume grossit.
Vérifiez surtout qu’aucune langue n’est absente : c’est le défaut le plus fréquent, et il se voit en comptant les URL du plan et en les comparant au nombre de contenus publiés.
Le fil d’actualité se décline également par langue. Un flux unique mélangeant trois langues n’a d’intérêt pour personne, et il donne une impression de désordre aux agrégateurs qui le consomment.
Ces deux points figurent dans la liste de contrôle du référencement d’un site EmDash, et ils se vérifient en trente secondes une fois le site en ligne.
Une progression réaliste
Pour qui veut ouvrir une seconde langue sans se piéger, une séquence qui limite le risque.
1. Choisir la structure et la figer. Le sous-dossier dans le doute.
2. Traduire les pages structurantes uniquement — accueil, pages de fond, pages de service. Une dizaine de contenus.
3. Mettre en place les correspondances entre versions, et vérifier leur réciprocité.
4. Publier et mesurer pendant trois à six mois. Le trafic de la seconde langue justifie-t-il la charge ?
5. Étendre ou s’arrêter. S’arrêter est une décision valable : une seconde langue réduite mais tenue à jour vaut mieux qu’une version complète abandonnée.
L’erreur inverse — tout traduire d’emblée puis ne plus suivre — laisse un site dont une moitié périme visiblement. C’est ce qu’on veut éviter, et c’est ce qui arrive quand la décision se prend sur l’ambition plutôt que sur la capacité éditoriale réelle.