Au moment de cadrer un nouveau site destiné à plusieurs marchés, la question de la structure d’URL revient systématiquement, et elle est souvent mal comprise par les clients qui la découvrent pour la première fois. Sous-dossier, sous-domaine, domaine national distinct : ces trois termes désignent des réalités techniques très différentes, avec des implications concrètes sur le référencement, le coût d’hébergement et la gestion quotidienne du site. Ce glossaire définit chacune de ces architectures sans en comparer les mérites sur des cas d’usage précis, déjà traité par ailleurs sous forme de retour d’expérience chiffré.
Sous-dossier de langue
Un sous-dossier de langue consiste à ajouter un segment de chemin dans l’URL pour distinguer chaque langue, tout en conservant un seul et même nom de domaine : exemple.com/fr/, exemple.com/en/, exemple.com/de/. Techniquement, c’est l’architecture la plus simple à mettre en œuvre : un seul certificat SSL, une seule configuration DNS, une seule installation WordPress (avec WPML ou Polylang gérant la distinction de langue au niveau applicatif plutôt qu’au niveau de l’hébergement).
Fonctionnement interne
D’un point de vue serveur, il n’existe qu’un seul virtual host à configurer. C’est WordPress, via le plugin multilingue, qui intercepte la requête entrante, détecte le segment de langue dans l’URL demandée et charge le contenu correspondant. Toute l’autorité de référencement acquise par le domaine (backlinks, ancienneté, confiance globale) est mécaniquement partagée entre toutes les langues, puisqu’il s’agit du même domaine aux yeux des moteurs de recherche.
Cas d’usage typique
Cette architecture convient particulièrement aux sites à fort volume de publication et à équipe éditoriale réduite, qui ont besoin de gérer toutes les langues depuis un seul back-office sans complexité d’hébergement supplémentaire.
Sous-domaine de langue
Un sous-domaine de langue place la distinction de langue avant le nom de domaine principal plutôt qu’après : fr.exemple.com, en.exemple.com, de.exemple.com. D’un point de vue technique, chaque sous-domaine peut, selon la configuration retenue, correspondre soit à une même installation WordPress (comme pour les sous-dossiers, WPML gérant la distinction), soit à un site distinct dans un réseau multisite WordPress, avec sa propre base de contenu partiellement indépendante.
Fonctionnement interne
Les moteurs de recherche traitent historiquement les sous-domaines avec un niveau d’autonomie intermédiaire entre le sous-dossier et le domaine complètement distinct : Google a par le passé traité certains sous-domaines comme des entités quasiment indépendantes, avant d’évoluer vers un traitement plus proche du sous-dossier pour la majorité des cas. Ce point a évolué au fil des années et mérite d’être vérifié au cas par cas plutôt que présumé de façon définitive.
Cas d’usage typique
Les sous-domaines sont souvent choisis lorsqu’une séparation technique plus nette est souhaitée entre les langues (hébergement distinct pour des raisons de conformité locale, équipes techniques séparées par marché) sans pour autant vouloir gérer l’achat et le renouvellement de plusieurs noms de domaine nationaux.
Domaine national distinct (ccTLD)
Un domaine national distinct, ou ccTLD (country code Top-Level Domain), utilise une extension de domaine propre à chaque pays cible : exemple.fr, exemple.de, exemple.es. C’est l’architecture qui offre la séparation la plus complète entre les langues, chaque domaine étant considéré par les moteurs de recherche comme une entité entièrement indépendante, sans aucun partage d’autorité SEO avec les autres domaines du groupe.
Fonctionnement interne
Chaque ccTLD nécessite généralement sa propre installation WordPress (ou son propre site dans un réseau multisite), son propre certificat SSL, et souvent son propre hébergement si des contraintes de résidence des données s’appliquent localement. La synchronisation de contenu entre ces domaines, si elle est souhaitée, doit être construite manuellement ou via des outils de synchronisation multisite, WPML ne proposant pas nativement de synchronisation transparente entre plusieurs installations totalement distinctes.
Cas d’usage typique
Cette architecture est privilégiée par les entreprises qui recherchent une implantation locale forte, perçue comme plus rassurante par une clientèle nationale (paiement en devise locale évident, service client perçu comme local), ou par des groupes ayant des obligations réglementaires distinctes selon les pays, nécessitant une isolation complète des données et du contenu.
Pièges fréquents au moment du choix
- Confondre sous-domaine et domaine distinct lors des devis d’hébergement, ce qui fausse l’estimation du coût de maintenance annoncé au client ;
- Sous-estimer le coût de gestion de plusieurs certificats SSL et configurations DNS pour une architecture en ccTLD, souvent perçu comme un détail technique mineur au moment du cadrage ;
- Choisir une architecture en fonction d’une préférence esthétique de l’URL plutôt qu’en fonction du volume éditorial réel et de la stratégie commerciale par marché ;
- Changer d’architecture en cours de vie du site sans anticiper l’ampleur du travail de migration technique et SEO que cela implique.
Le choix d’une architecture d’URL multilingue n’est jamais qu’une question technique : c’est avant tout une décision de stratégie commerciale par marché, que la technique vient ensuite traduire.
En résumé
Ces trois architectures répondent à des priorités différentes, et aucune n’est universellement supérieure aux deux autres. Le sous-dossier privilégie la simplicité et le partage d’autorité, le sous-domaine offre un compromis de séparation technique modérée, et le domaine national distinct privilégie l’implantation locale au prix d’une complexité de gestion nettement supérieure. Cadrer ce choix correctement dès le début d’un projet évite des migrations coûteuses une fois le site en production depuis plusieurs années.
