Créer un site WordPress multilingue : ce que les entreprises doivent absolument prendre en compte

Introduction

Développer un site web pour s'adresser à des publics parlant plusieurs langues semble simple en théorie. En pratique, cela implique une série de décisions techniques, stratégiques et liées au contenu qui prennent de nombreuses entreprises au dépourvu. Les erreurs ont tendance à suivre des schémas prévisibles, et la plupart d'entre elles sont plus faciles à éviter lors de la phase de planification qu'à corriger une fois le site créé et mis en ligne.

Wesley Cude, fondateur de la société de développement WordPress Cude Design, a créé des sites WordPress multilingues pour des clients au Royaume-Uni et à l’international. « L’aspect technique d’un site WordPress multilingue est bien pris en charge par les plugins disponibles », explique-t-il. « C’est au niveau des décisions prises avant même qu’une seule ligne de code ne soit écrite que les projets ont tendance à échouer. Quelles langues choisir, quelle structure d’URL adopter, qui est responsable des traductions, comment le site gère les devises et les différences régionales ? Prendre les bonnes décisions dès le départ permet d’éviter un travail de retouche considérable par la suite. »

Cet article aborde les décisions clés à prendre lors de la création d’un site WordPress multilingue, les approches techniques disponibles, ainsi que les considérations à long terme qui déterminent si un site multilingue répond réellement et efficacement aux besoins de son public cible.

Choisir la bonne structure d’URL

La première décision importante dans un projet WordPress multilingue concerne la manière de structurer les URL pour chaque version linguistique. Il existe trois approches principales, chacune ayant des implications en matière de référencement naturel (SEO), d’hébergement et de gestion au quotidien.

Les sous-répertoires utilisent une structure de dossiers pour séparer les versions linguistiques, la langue principale se trouvant à la racine et les autres langues dans des sous-répertoires. Une version en anglais britannique pourrait se trouver à l’adresse domain.com tandis qu’une version en français serait accessible à l’adresse domain.com/fr/. Cette approche permet de tout regrouper sur un seul domaine, ce qui signifie que toute l’autorité du domaine s’applique à toutes les versions linguistiques. C’est l’approche la plus courante pour les entreprises qui se développent dans d’autres langues sans avoir de raison particulière de traiter chaque marché comme une entité totalement distincte.

Les sous-domaines placent chaque version linguistique sur son propre sous-domaine, par exemple fr.domain.com pour le français. Les moteurs de recherche traitent les sous-domaines comme des entités distinctes dotées de leur propre autorité, ce qui signifie qu’un nouveau sous-domaine démarre sans aucune autorité accumulée, même si le domaine principal bénéficie d’un excellent classement. Cette approche est plus complexe à gérer sur le plan technique et n’a généralement de sens que lorsqu’il existe de solides raisons de traiter chaque langue comme véritablement distincte, par exemple en cas de stratégies de contenu significativement différentes pour chaque marché.

Les domaines de premier niveau nationaux (ccTLD) utilisent des enregistrements de domaine distincts pour chaque pays, comme domain.fr pour la France ou domain.de pour l’Allemagne. Cette solution envoie le signal géographique le plus fort aux moteurs de recherche et peut s’avérer efficace pour les entreprises disposant d’une présence importante sur chaque marché. Elle est également la plus coûteuse et la plus complexe, car chaque domaine nécessite en effet sa propre stratégie de référencement et son propre programme de création de liens.

Pour la plupart des entreprises qui créent un site WordPress multilingue pour la première fois, les sous-répertoires constituent le bon point de départ. Ils sont les plus simples à mettre en œuvre, permettent de conserver toute l’autorité sur un seul domaine et sont faciles à étendre à mesure que de nouvelles langues sont ajoutées.

Sélection et configuration des plugins

WordPress dispose de deux plugins multilingues dominants : WPML et Polylang. Tous deux sont capables de gérer des sites multilingues complexes, mais ils adoptent des approches différentes en matière de mise en œuvre et ont des implications différentes sur les performances du site et sa gestion au quotidien.

WPML est l’option la plus complète. Il gère la gestion des traductions, la traduction des chaînes de caractères pour les textes des thèmes et des plugins, la compatibilité avec WooCommerce, ainsi que les configurations multilingues complexes, y compris les langues s’écrivant de droite à gauche. Il s’intègre à des services de traduction pour des traductions professionnelles et offre un contrôle détaillé sur le contenu à traduire et la manière de le traduire. En contrepartie, c’est l’un des plugins les plus lourds en termes de requêtes de base de données et il peut affecter les performances du site s’il n’est pas configuré avec soin sur les sites de grande envergure.

Polylang est une alternative plus légère qui gère les fonctionnalités multilingues de base avec moins de surcoût. Pour les sites qui n’ont pas besoin de l’ensemble des fonctionnalités de WPML, il assure la gestion des traductions avec un impact moindre sur les performances. Il dispose d’une version gratuite dotée de fonctionnalités utiles, ce qui en fait un point de départ raisonnable pour des projets multilingues plus simples.

Le choix entre ces deux solutions dépend de la complexité du site, des exigences d’intégration avec WooCommerce et du workflow de traduction que le client prévoit d’utiliser. Un site comportant un petit nombre de pages statiques en deux langues n’a pas les mêmes exigences qu’une boutique WooCommerce vendant des produits sur cinq marchés européens, avec des prix, des taux de TVA et des exigences en matière de passerelles de paiement différents pour chacun d’entre eux.

Mise en œuvre de l’attribut hreflang

Hreflang est l’attribut HTML qui indique aux moteurs de recherche quelle langue et quelle version régionale d’une page proposer à quels utilisateurs. Une mise en œuvre correcte de hreflang est essentielle pour le référencement multilingue et constitue l’un des domaines où les sites multilingues présentent le plus souvent des erreurs.

Chaque page d’un site multilingue doit inclure des balises hreflang pointant vers toutes les autres versions linguistiques de cette page, y compris elle-même. Une page disponible en anglais, en français et en allemand doit comporter des balises hreflang pour ces trois versions sur chaque variante de la page. Des balises hreflang manquantes ou mal formatées peuvent amener les moteurs de recherche à proposer la mauvaise version linguistique aux utilisateurs ou à considérer les différentes versions linguistiques comme du contenu dupliqué.

WPML et Polylang gèrent tous deux automatiquement la génération des balises hreflang lorsqu’ils sont correctement configurés, mais il convient de vérifier cette implémentation automatique plutôt que de la considérer comme acquise. Parmi les erreurs courantes, on trouve l’absence de balises x-default, des balises hreflang pointant vers des URL redirigées plutôt que vers des URL canoniques, et des implémentations hreflang qui ne correspondent pas à la structure d’URL utilisée.

Rank Math et Yoast SEO offrent tous deux des fonctionnalités supplémentaires de gestion des balises hreflang lorsqu’ils sont utilisés avec des plugins multilingues. L’important est de s’assurer que le plugin de référencement et le plugin multilingue sont configurés pour fonctionner correctement ensemble, plutôt que de générer des balises contradictoires.

Stratégie de contenu et qualité de la traduction

La mise en œuvre technique d’un site WordPress multilingue est la partie la plus simple du projet. C’est au niveau de la stratégie de contenu que de nombreux sites multilingues échouent à atteindre leur objectif.

La traduction automatique s’est considérablement améliorée et, pour certains types de contenu, elle produit des résultats acceptables. Pour le contenu commercial, en particulier les descriptions de services, les textes de présentation des produits et les pages axées sur la conversion qui sont les plus importantes pour l’entreprise, la traduction automatique est rarement suffisante sans révision et correction humaines. Un texte qui se lit mal ou qui contient des formulations culturellement inappropriées sape la crédibilité que le site multilingue est censé instaurer.

Le flux de travail de traduction continu est un aspect souvent sous-estimé lors de la phase de planification. L’ajout d’un nouvel article de blog ou d’une nouvelle page produit sur un site multilingue implique la production de versions traduites de ce contenu, ce qui prend du temps et engendre des coûts. Les sites qui sont lancés avec un contenu entièrement traduit mais qui ne parviennent pas à maintenir ces traductions se retrouvent avec des versions linguistiques obsolètes par rapport à la version dans la langue principale. Cela crée une expérience pire que l’absence totale de traduction.

Une stratégie de contenu réaliste pour un site multilingue doit inclure une attribution claire des responsabilités dans le processus de traduction, un flux de travail défini pour les nouveaux contenus et des décisions lucides quant aux contenus qui doivent réellement être traduits. Toutes les pages d’un site n’ont pas nécessairement besoin d’une version traduite. Il est plus efficace de donner la priorité aux pages les plus importantes pour les utilisateurs internationaux et d’assurer correctement la mise à jour de ces traductions que de tenter une traduction exhaustive sans parvenir à la maintenir à jour.

WooCommerce et le e-commerce multilingue

Les sites WooCommerce multilingues présentent une complexité supplémentaire qui va au-delà des considérations habituelles liées au multilinguisme sous WordPress. Les prix, les règles d’expédition, les passerelles de paiement et les configurations fiscales peuvent varier d’un marché à l’autre. L’affichage des devises doit correspondre aux attentes des utilisateurs dans chaque région. La disponibilité des produits peut varier d’un marché à l’autre. Les communications avec les clients, notamment les confirmations de commande et les notifications d’expédition, doivent être envoyées dans la langue du client.

WPML propose une prise en charge multilingue dédiée à WooCommerce qui gère la traduction des produits, le changement de devise et la localisation du processus de paiement. La configuration est plus complexe que celle d’un site multilingue standard et doit être considérée comme un projet distinct plutôt que comme une extension d’une installation WooCommerce standard.

La disponibilité des passerelles de paiement varie considérablement d’un pays à l’autre. Stripe et PayPal sont disponibles sur la plupart des marchés, mais les moyens de paiement locaux revêtent une importance particulière dans certaines régions. iDEAL domine aux Pays-Bas, Sofort en Allemagne et la Carte Bancaire en France. Une boutique WooCommerce ciblant les marchés européens qui ne propose que des options de paiement par carte internationale sera moins performante que ses concurrents locaux qui prennent en charge les moyens de paiement préférés de leur marché spécifique.

Considérations relatives aux performances

Les sites multilingues sont par nature plus volumineux que leurs équivalents monolingues. Un plus grand nombre de pages, d’enregistrements dans la base de données et de surcoûts liés aux plugins contribuent tous à une charge serveur accrue et à des problèmes de performances potentiels. Il convient d’anticiper ces aspects plutôt que d’y remédier de manière réactive après le lancement.

La configuration de la mise en cache doit tenir compte de la détection de la langue afin d’éviter de servir aux utilisateurs des pages mises en cache dans une langue incorrecte. La détection de la langue côté serveur, qui s’effectue avant que le cache ne soit servi, est généralement plus fiable que la détection côté client, mais l’approche spécifique dépend de l’environnement d’hébergement et du plugin de mise en cache utilisé.

Pour les sites destinés à plusieurs pays, un réseau de diffusion de contenu (CDN) qui met en cache le contenu dans des points de présence géographiquement proches de chaque marché cible réduit la latence pour les utilisateurs internationaux. Cela est particulièrement pertinent pour les sites ciblant des marchés géographiquement éloignés du lieu d’hébergement principal.

L’optimisation de la base de données revêt une importance accrue sur les sites multilingues, car les tables de traduction utilisées par des plugins tels que WPML alourdissent considérablement la charge de la base de données à mesure que le volume de contenu augmente. Une maintenance régulière de la base de données et une indexation appropriée sont plus cruciales sur un grand site multilingue que sur un site monolingue comparable.

Tests avant le lancement

Les sites multilingues nécessitent des tests plus approfondis que les sites monolingues, car il y a davantage de combinaisons de langues, d’URL et de contenus à vérifier. Une approche structurée des tests doit couvrir la fonctionnalité de changement de langue sur toutes les pages, la mise en œuvre correcte de l’attribut hreflang vérifiée avec Google Search Console après le lancement, l’exhaustivité des traductions pour toutes les pages commerciales, l’affichage correct de la devise et le processus de paiement pour chaque marché dans les implémentations WooCommerce, ainsi que les performances mobiles pour chaque version linguistique.

L’investissement dans des tests approfondis avant le lancement se justifie par le coût et la complexité de la résolution des problèmes sur un site multilingue en production, où les modifications apportées à la structure des URL ou à la mise en œuvre de l’attribut hreflang peuvent affecter simultanément les classements dans les résultats de recherche sur plusieurs marchés.