Traduire les textes et ajouter un sélecteur de langue suffit rarement. L’architecture d’un site multilingue doit définir des règles d’URL, relier les différentes versions linguistiques, structurer les données dans le CMS et prévoir un processus de mise à jour des traductions. Définir la stratégie de localisation dès le départ donne également au SEO multilingue une base technique stable et évite l’accumulation de pages dupliquées et de corrections manuelles.
Lorsque la localisation concerne le routage, la structure du CMS, les composants réutilisables et les intégrations, nos services de développement web couvrent la mise en œuvre technique nécessaire pour garder le site multilingue évolutif et facile à maintenir.
La traduction change la langue du texte. La localisation adapte le site au contexte de l’utilisateur : terminologie, formats habituels, devise, moyens de contact, obligations légales et usages de l’interface. Les images, les exemples, les témoignages et même la structure des pages peuvent également varier.
L’adaptation régionale répond à un autre besoin. Deux versions peuvent utiliser la même langue tout en ciblant des marchés différents. Les pages en anglais destinées au Royaume-Uni et aux États-Unis peuvent différer par leurs tarifs, leurs conditions de livraison, leur orthographe et leurs offres commerciales. À l’inverse, un même marché peut nécessiter plusieurs langues.
Une liste comme « anglais, allemand, français » ne suffit pas pour définir l’architecture. Avant le développement, il est utile de créer une matrice des langues et des régions. Pour chaque locale, l’équipe indique le marché, la langue, la devise, les pages légales requises et les sections disponibles. Cette matrice montre rapidement si le projet nécessite des versions régionales distinctes ou un site commun décliné en plusieurs langues.
Toutes les pages ne doivent pas nécessairement être publiées simultanément dans chaque locale. L’absence d’une version doit toutefois résulter d’une décision claire. Sans cette règle, un utilisateur peut suivre un lien et arriver sur une page dans une autre langue, une offre obsolète ou une page vide.
Chaque version linguistique indexable doit disposer de sa propre URL. Les utilisateurs peuvent ainsi l’ouvrir directement, partager son lien et suivre ses performances séparément. Les moteurs de recherche disposent également d’une adresse stable. Modifier dynamiquement la langue sur une URL unique selon un cookie ou les paramètres du navigateur complique l’indexation, car un robot peut ne voir qu’une seule version.
Pour la plupart des sites corporate et éditoriaux, les sous-répertoires comme « example.com/en/ » et « example.com/fr/ » fonctionnent bien. Toutes les versions restent sur un même domaine, ce qui simplifie la gestion des statistiques, des modèles et des réglages techniques.
Les sous-domaines comme « fr.example.com » donnent davantage d’autonomie à l’infrastructure et aux équipes locales. En contrepartie, il faut maintenir plusieurs configurations et surveiller la cohérence entre les différentes versions du site.
Les domaines nationaux comme « example.de » associent clairement un site à un pays. Ce modèle est pertinent lorsque les marchés présentent de fortes différences ou que les équipes locales travaillent de manière presque indépendante. Il demande davantage de maintenance et ne convient pas à une langue utilisée dans plusieurs pays.
La détection automatique de la langue peut servir de suggestion, mais elle ne doit pas limiter le choix de l’utilisateur. Le site peut recommander une version adaptée et mémoriser la préférence. L’utilisateur doit toujours pouvoir ouvrir une autre locale, tandis que les robots d’exploration doivent accéder à chaque version grâce à des liens standards.
Le modèle de locales décrit les versions disponibles et les relations qui les unissent. Le code « en » désigne un anglais générique, tandis que « en-GB » ou « pt-BR » précise une région. Il est utile d’ajouter une région uniquement lorsqu’elle modifie le contenu ou la logique métier. Créer des dizaines de locales nominalement différentes avec des pages identiques ne fait que compliquer la maintenance.
Le modèle définit la locale principale et associe les pages équivalentes. Depuis une page de service en anglais, le sélecteur de langue doit conduire à son équivalent allemand au lieu de renvoyer systématiquement à la page d’accueil. Le CMS ou la couche de routage doit donc savoir quelles entrées correspondent aux différentes versions d’un même contenu.
Le fallback doit également suivre une règle précise. Lorsqu’une traduction manque, le site peut masquer le lien indisponible, afficher la version source avec une indication claire ou proposer la page disponible la plus proche. Un mauvais fallback conserve « /fr/ » dans l’URL tout en affichant le contenu principal en anglais. L’utilisateur voit alors une interface bilingue et le moteur de recherche reçoit un signal ambigu sur la langue de la page.
Les composants doivent aussi accepter des textes plus longs. Le libellé court d’un bouton en anglais peut occuper deux lignes après traduction. L’arabe et l’hébreu nécessitent une lecture de droite à gauche, y compris pour l’ordre des éléments, les icônes et les contenus mêlant plusieurs écritures. Intégrer ces contraintes dès la conception d’un site RTL coûte moins cher que de les corriger page par page.
Des URL distinctes ne règlent qu’une partie du problème. Les moteurs de recherche doivent comprendre quelles pages représentent les différentes versions linguistiques ou régionales d’un même contenu. Le site communique ces relations grâce à « hreflang » dans le HTML, les en-têtes HTTP ou le sitemap XML. L’équipe choisit généralement une méthode qu’elle peut maintenir de manière cohérente.
Chaque page d’un groupe se référence elle-même ainsi que toutes les autres versions disponibles. Les relations doivent être réciproques : si la page anglaise pointe vers la page allemande, cette dernière doit également pointer vers la version anglaise. Dans « hreflang », la langue apparaît en premier, suivie de la région si nécessaire, comme dans « en-GB ». Un code pays utilisé seul n’est pas valide.
La valeur « x-default » peut pointer vers une page neutre de sélection ou vers une version destinée aux utilisateurs qui ne correspondent à aucune locale déclarée. Elle ne constitue pas un lien de fallback obligatoire pour tous les projets. Son utilisation dépend de l’architecture retenue.
La balise « canonical » indique l’URL privilégiée parmi des contenus dupliqués et ne remplace pas « hreflang ». Les pages entièrement traduites utilisent généralement une URL canonique autoréférencée. Lorsque plusieurs pages régionales dans la même langue sont presque identiques, la balise canonical doit être choisie avec soin au sein du même groupe linguistique ou vers la version linguistique la plus proche.
Les moteurs de recherche déterminent principalement la langue d’une page à partir de son contenu visible. L’attribut « lang » de l’élément « html » reste toutefois important pour les navigateurs et les technologies d’assistance. Les métadonnées et les requêtes de recherche doivent également être adaptées au marché. La traduction littérale d’une expression cible peut différer des termes réellement utilisés par les internautes pour rechercher le service.
Selon les marchés, les internautes peuvent employer des termes différents pour désigner le même service, même lorsque la traduction du texte source est correcte. La recherche de mots-clés localisés doit donc guider les titres de page, les intertitres, le contenu, les métadonnées et les slugs dès le début du travail.
Pour chaque locale, il est utile de consigner l’intention de recherche principale, le terme privilégié localement et les éventuelles formulations régionales qui influencent les pages commerciales. La page traduite reste ainsi naturelle pour les lecteurs, tandis que les décisions de SEO international disposent d’une référence documentée.
Il est utile de distinguer trois types de données dans le CMS. Les champs globaux restent identiques dans toutes les versions. Les champs traduisibles reçoivent une valeur pour chaque locale, tandis que les champs régionaux peuvent être remplacés pour un marché précis. La structure d’une carte peut, par exemple, rester commune, alors que son titre est traduit et que son prix et sa mention légale varient selon la région.
Copier l’ensemble du site pour chaque langue crée rapidement des incohérences. L’équipe corrige un composant dans une version, oublie la deuxième et, quelques mois plus tard, les sites ne suivent plus les mêmes règles. Des projets séparés se justifient lorsque les marchés proposent réellement des produits différents ou possèdent des équipes et des contraintes propres. Une simple différence de langue ne suffit généralement pas.
La gestion multilingue doit s’étendre aux slugs, aux catégories, aux filtres et à l’index de recherche. Le CMS doit également proposer des statuts de traduction, comme brouillon, en cours de révision, prêt à publier, publié ou obsolète. Lorsqu’un auteur modifie le contenu source, la traduction associée ne doit pas rester silencieusement marquée comme actuelle. Le système doit créer une tâche de mise à jour ou, au minimum, signaler l’écart.
Ce processus est particulièrement important pour les composants partagés et les textes récurrents. Si le même libellé est enregistré à cinq endroits, les traducteurs doivent le corriger cinq fois. Une source unique réduit la charge de travail et les incohérences terminologiques.
La traduction manuelle convient aux sites qui contiennent peu de textes et évoluent rarement. La traduction automatique ou assistée par IA permet de produire plus rapidement un premier jet sur un volume important, mais elle nécessite des règles terminologiques et une révision des pages prioritaires. La traduction humaine restitue mieux les nuances, avec un coût et un délai plus élevés. De nombreuses équipes adoptent une méthode hybride : le système prépare une première version, puis un spécialiste révise les contenus importants.
Une qualité cohérente repose sur un glossaire, une mémoire de traduction et un guide de style concis. L’équipe définit également les rôles de l’auteur, du traducteur, de l’éditeur local et de la personne chargée de la publication. Le niveau de révision peut varier, car une page juridique et un ancien article de blog ne présentent pas les mêmes risques.
Traduire le contenu principal ne termine pas le travail. L’équipe doit vérifier les menus, les boutons, les formulaires, les messages d’erreur, les e-mails, l’interface de gestion des cookies et les résultats de recherche. Les dates, les nombres, les devises, les unités de mesure, les adresses et les numéros de téléphone doivent également être localisés. Les textes alternatifs, les contenus Open Graph, les noms de fichiers et les widgets tiers demandent des contrôles spécifiques. Les widgets externes restent souvent dans la langue source alors que la page est déjà traduite.
Avant la publication, l’équipe vérifie quatre niveaux. La QA linguistique porte sur le sens, la terminologie et le ton. La QA fonctionnelle teste les liens, les formulaires, la recherche et les états interactifs. La QA technique SEO contrôle les codes de réponse, l’indexabilité, les balises canonical, « hreflang » et le sitemap. La QA d’accessibilité couvre l’attribut « lang », la navigation au clavier, l’ordre de lecture et les messages de l’interface.
En pratique, le site est prêt à être publié lorsque :
Lorsque la langue fait partie de l’architecture, l’équipe peut ajouter une nouvelle locale en suivant des règles établies. Celle-ci reçoit ses propres URL, des entrées CMS reliées, des statuts de traduction et un processus de QA. Il n’est plus nécessaire de copier le site avec toutes ses anciennes erreurs ni de réinventer le processus pour chaque nouveau marché.
Chaque version indexable doit disposer d’une URL stable, directement accessible aux utilisateurs et aux moteurs de recherche. Changer la langue sur une URL unique à l’aide de cookies ou des paramètres du navigateur peut empêcher les robots de découvrir toutes les versions disponibles.
Le site doit appliquer une règle de fallback explicite. Il peut masquer la locale indisponible, afficher la version source avec une indication claire ou proposer la page disponible la plus proche. Il ne doit pas conserver une URL localisée tout en affichant silencieusement un contenu dans une autre langue.
Le CMS doit relier les entrées équivalentes et suivre des statuts comme brouillon, en révision, publié et obsolète. Lorsque le contenu source change, les traductions associées doivent être signalées comme devant être révisées au lieu de rester marquées comme actuelles.
Notre équipe commence par établir une matrice des langues, des marchés, des devises, des obligations légales et des sections disponibles. Elle choisit ensuite entre des sous-répertoires, des sous-domaines ou des domaines nationaux en fonction des différences réelles de contenu, d’infrastructure et de responsabilité.
Nous contrôlons la qualité linguistique, les parcours utilisateurs localisés, les formulaires et les intégrations, l’accessibilité, l’indexabilité, les balises canonical, les relations hreflang et le sitemap. Le sélecteur de langue est également testé pour vérifier qu’il ouvre la page équivalente sans imposer un choix à l’utilisateur.
