Comment rendre un site web multilingue en 2026

La première décision est de savoir quelles locales publier, et la réponse est rarement « toutes ». Chaque locale que vous ajoutez est un engagement : vous devrez maintenir son contenu, surveiller son SEO, réviser ses traductions et répondre à ses visiteurs. Ajouter 10 locales que vous ne pouvez pas maintenir est pire que d'en ajouter 2 que vous pouvez maintenir.

Commencez par les locales qui correspondent à votre audience réelle. Examinez votre trafic existant dans Google Analytics — quels pays et quelles langues vous visitent déjà ? Regardez vos clients — quelles langues parlent-ils ? Regardez vos concurrents — quelles locales servent-ils que vous ne servez pas ? L'intersection entre « où se trouve mon audience » et « où je peux offrir de la qualité » constitue votre liste restreinte de locales.

Pour la plupart des entreprises de services, la réponse est deux locales : votre langue commerciale principale plus une langue communautaire (par exemple, anglais + chinois pour un dentiste américain servant une communauté chinoise). Pour les entreprises transfrontalières, deux à quatre locales (par exemple, anglais + chinois + espagnol pour un consultant servant les États-Unis, la Chine et l'Amérique latine). Pour les sites logiciels et de contenu, quatre à dix locales peuvent se justifier une fois que l'économie unitaire justifie le coût de maintenance.

Trois structures d'URL viables pour les sites multilingues : (1) des sous-répertoires préfixés par la locale (example.com/zh-CN/, example.com/es/), (2) des sous-domaines préfixés par la locale (zh-cn.example.com, es.example.com), ou (3) des domaines distincts par locale (example.cn, example.es, example.com). Chacune présente des compromis.

Les sous-répertoires sont le choix le plus courant et généralement le meilleur. L'équité SEO se cumule entre les locales (les liens vers /zh-CN/ profitent à tout le domaine), la maintenance est simple (un seul CMS, une seule base de code) et le hreflang fonctionne proprement. La documentation de Google recommande explicitement les sous-répertoires lorsque c'est possible.

Les sous-domaines divisent l'équité SEO entre les locales (les liens vers zh-cn.example.com ne profitent pas à example.com autant que le ferait /zh-CN/). Ils se justifient lorsque chaque locale est exploitée par une équipe distincte disposant d'une infrastructure distincte, ou lorsque des exigences légales propres à une locale (résidence des données, licences de contenu) imposent une séparation physique. La plupart des sites n'en ont pas besoin.

Les domaines distincts se justifient pour des entreprises véritablement distinctes partageant une marque (par exemple, une chaîne de restauration rapide mondiale avec des menus et des tarifs propres à chaque pays). La complexité — SEO distinct, DNS distinct, hébergement distinct — en vaut rarement la peine pour les sites multilingues de petite ou moyenne taille.

Cogo Site utilise des sous-répertoires par défaut (/zh-CN/, /es/, etc.), ce qui est la bonne réponse pour 95 % des sites multilingues. Si vous avez besoin de sous-domaines ou de domaines distincts pour des raisons légales, il s'agit d'une configuration personnalisée ; sinon, restez avec les sous-répertoires.

La qualité de la traduction détermine si votre site multilingue se cumule ou se cannibalise. Trois approches, par ordre de coût et de qualité :

Approche A — Traduction entièrement humaine. Qualité maximale, la plus lente, la plus coûteuse. Idéale pour le contenu juridique, médical ou réglementé où les erreurs coûtent cher. Coût : 0,10 à 0,30 $ par mot pour une traduction professionnelle. Délai : de quelques semaines à plusieurs mois pour un site complet.

Approche B — Traduction par IA avec relecture par un locuteur natif. L'IA traduit, un locuteur natif révise la page d'accueil et les pages critiques pour la conversion. La qualité est proche de la traduction humaine pour 10 à 20 % du coût. Idéale pour la plupart des entreprises de services. Cogo Site utilise cette approche par défaut.

Approche C — Traduction entièrement par IA. La plus rapide, la moins chère, la moins qualitative. Acceptable pour les outils internes ou le contenu à faible enjeu ; risquée pour les sites destinés aux clients. Google peut détecter une traduction automatique de faible qualité et déclasser les deux locales.

L'approche hybride (B) est le juste équilibre pour la plupart des sites. La traduction par IA de Cogo Site produit des formulations adaptées à la locale (et non mot à mot), et un locuteur natif devrait toujours réviser la page d'accueil, les tarifs et les pages critiques pour la conversion. Le résultat atteint 90 % de la qualité humaine pour 10 % du coût.

Hreflang indique à Google quelle version de locale montrer à quel internaute. Sans cela, Google peut servir la mauvaise locale au mauvais internaute, provoquant des rebonds et une perte de classement. Chaque page multilingue a besoin de trois éléments : une balise hreflang autoréférente, des balises alternatives pour chaque autre locale, et une balise x-default pointant vers la locale destinée aux internautes non appariés.

Au-delà du hreflang, chaque locale dispose de son propre titre, méta-description et slug d'URL — le tout dans la langue de la locale. Une erreur courante consiste à traduire le corps du contenu mais à laisser les métadonnées SEO en anglais ; Google interprète cela comme une « traduction de faible effort » et classe en conséquence. Traduisez tout.

Sitemaps : chaque locale doit figurer dans votre sitemap XML. La plupart des CMS modernes (y compris Cogo Site) génèrent automatiquement des sitemaps multilingues avec les annotations hreflang correctes. Si vous gérez vos sitemaps manuellement, ajoutez des annotations hreflang à chaque entrée d'URL.

Données structurées : le JSON-LD de chaque page de locale doit être dans la langue de la locale lorsque cela s'applique (par exemple, les noms de Question de FAQ traduits, le titre d'Article traduit, le nom de Fil d'Ariane traduit). Consultez notre guide hreflang pour la spécification complète du hreflang.

La traduction représente la moitié du travail. L'autre moitié consiste en détails d'UX propres à chaque locale qui distinguent un véritable site multilingue d'un site simplement traduit.

Formats de date et d'heure : les États-Unis utilisent MM/JJ/AAAA, la majeure partie du monde utilise JJ/MM/AAAA, la norme ISO est AAAA-MM-JJ. Choisissez le format correspondant aux conventions de chaque locale ; n'utilisez pas un seul format à l'échelle mondiale.

Numéros de téléphone et adresses : format selon la convention postale de chaque locale. Les adresses américaines sont « 123 Main St, San Francisco, CA 94101 » ; les adresses chinoises sont en ordre inverse (pays, province, ville, district, rue, numéro). Le formatage sensible à la locale de Cogo Site gère cela automatiquement.

Devise et unités : prix en USD pour en-US, en CNY pour zh-CN, en MXN pour es-MX. Ne convertissez pas automatiquement — affichez la devise réelle de la locale.

Preuve sociale : affichez des témoignages WeChat / Weibo / QQ sur zh-CN, des témoignages Facebook / Twitter / Yelp sur en-US. N'affichez pas de preuve sociale en anglais sur les pages chinoises — cela signale un « opérateur étranger ».

Libellés de formulaire et validation : les règles de validation des numéros de téléphone diffèrent (10 chiffres aux États-Unis, 11 chiffres en Chine continentale), les codes postaux diffèrent (5 chiffres aux États-Unis, 6 chiffres en Chine), les champs de nom diffèrent (prénom/nom occidental vs nom de famille/prénom chinois dans cet ordre). Validez selon la locale.

Piles de polices : le chinois nécessite des polices compatibles CJK (Noto Sans CJK, PingFang, Microsoft YaHei) ; l'anglais nécessite des polices latines (Inter, system-ui). La typographie à scripts mixtes nécessite des piles de secours. Cogo Site gère cela par locale ; les sites construits à la main nécessitent un CSS soigné.

Après le lancement, surveillez trois choses : (1) le rapport Ciblage international de Google Search Console pour les erreurs hreflang, (2) le rapport Performances de Search Console par locale (requêtes, CTR, position), (3) les Analytics par locale (trafic, engagement, conversion).

Problèmes courants après le lancement : erreurs hreflang (à corriger immédiatement), pages d'une locale non indexées (vérifiez l'inspection d'URL), mauvaise locale classée dans la mauvaise région (vérifiez que le hreflang est correct), faible engagement sur une locale (révisez la qualité de la traduction et les détails d'UX).

Itérez en fonction des données. Si zh-CN génère 10 fois le trafic de en-US, votre audience est chinoise — priorisez cette locale. Si es-MX a un trafic élevé mais une faible conversion, la traduction est peut-être maladroite ou les prix erronés — corrigez-le. Les sites multilingues sont des systèmes vivants ; le lancement est le début, pas la fin.

Réauditez le hreflang chaque trimestre. Les modifications de sitemap, les migrations de contenu et les mises à jour de CMS peuvent casser le hreflang silencieusement. Un crawl trimestriel avec Ahrefs ou Sitebulb détecte les problèmes avant qu'ils ne coûtent des classements.

Erreur 1 — Publier trop de locales à la fois. Chaque locale est un engagement de maintenance ; 10 locales que vous ne pouvez pas maintenir, c'est pire que 2 que vous pouvez maintenir. Commencez par vos locales à plus forte valeur, prouvez le modèle, développez plus tard.

Erreur 2 — Choisir des sous-domaines ou des domaines distincts sans raison réelle. Les sous-répertoires cumulent l'équité SEO ; les sous-domaines et les domaines distincts ne le font pas. Utilisez des sous-répertoires, sauf si des exigences légales ou opérationnelles imposent le contraire.

Erreur 3 — Traduire le corps du contenu mais pas les métadonnées SEO. Titre, description, URL, texte alternatif, données structurées — tout doit être traduit. Laisser des métadonnées en anglais signale un « faible effort » et fait chuter les classements.

Erreur 4 — Traduction automatique sans relecture par un natif. La traduction par IA est bonne mais pas parfaite. Faites toujours réviser la page d'accueil et les pages critiques pour la conversion par un locuteur natif. Le coût est faible ; le gain de qualité est important.

Erreur 5 — Détails d'UX identiques d'une locale à l'autre. Formats de date, formats de téléphone, devises, preuve sociale, validation de formulaire — tout nécessite un traitement propre à la locale. Une UX « taille unique » signale que « nous ne connaissons pas réellement votre locale ».

Erreur 6 — Oublier Baidu et Bing. Google est le moteur de recherche dominant en Occident, mais Baidu domine la Chine continentale et Bing compte encore dans certains segments d'entreprise/éducation. Assurez-vous que votre hreflang et votre sitemap fonctionnent pour les trois.