Comment créer un site multilingue : structure, hreflang, localisation et budget

Un site multilingue est un site dont chaque langue vit sur sa propre URL, avec son contenu, ses balises et son référencement séparés. Un widget de traduction posé par-dessus une seule version ne produit pas un site multilingue : il produit une page unique que les moteurs continuent de lire dans une seule langue.

La différence a des conséquences immédiates. Une version par langue s'indexe, se positionne, se mesure et se vend. Une traduction affichée au vol ne fait rien de tout cela.

Ce guide couvre la décision, la structure d'URL, le hreflang, la localisation au-delà du texte, le choix du CMS, le référencement en plusieurs langues, le budget, les erreurs classiques et la maintenance. Une partie des exemples vient de notre propre site, publié en cinq langues, que vous pouvez vérifier vous-même en changeant le préfixe dans la barre d'adresse.

Trois signaux justifient une deuxième langue. Vous vendez déjà à l'étranger et votre support répond dans une autre langue. Une réglementation locale impose la langue du pays sur certains documents. Ou vos concurrents locaux occupent des requêtes que votre site anglais ne touchera jamais, parce que personne ne cherche en anglais dans ce marché. En dehors de ces trois cas, une langue bien travaillée bat souvent trois langues à moitié finies.

Le critère qui tranche n'est pas la taille de l'entreprise, c'est l'origine des demandes entrantes. Si votre formulaire reçoit déjà des messages rédigés en allemand ou en néerlandais, la demande existe et vous la servez mal. S'il n'en reçoit aucun, une version supplémentaire ne créera pas le marché toute seule.

Deux situations où une seule langue reste défendable. Les produits techniques vendus à des développeurs, dont l'audience travaille en anglais par défaut. Et les projets à budget serré, où le choix réel se pose entre un site correct en une langue et cinq versions bâclées.

Une réserve honnête : ajouter une langue multiplie la charge éditoriale, pas seulement la facture de départ. Chaque page de service, chaque article, chaque mention légale existe désormais en autant d'exemplaires. C'est cette charge récurrente, bien plus que le devis initial, qui fait abandonner des locales au bout d'un an.

Avant de trancher, posez l'arborescence de votre site en une seule langue. Une structure confuse en français ne deviendra pas limpide en cinq langues.

Trois structures d'URL existent et le choix se fait une fois pour toutes. Le sous-dossier range les langues sous un domaine unique. Le sous-domaine leur donne un préfixe. Le domaine national leur donne une extension par pays. Selon la documentation Google sur les sites multirégionaux, les trois sont acceptables, mais elles ne coûtent pas la même chose à installer ni à maintenir.

Le tableau ci-dessous reprend les avantages et les inconvénients listés par Google, avec le cas d'usage qui correspond.

Le hreflang est une annotation qui signale aux moteurs qu'une page existe en plusieurs langues et laquelle servir à qui. Selon la documentation Google sur les versions localisées, trois méthodes sont équivalentes : des balises link dans le head, un en-tête HTTP, ou une déclaration dans le sitemap XML. Utiliser les trois en même temps n'apporte aucun gain de visibilité, seulement trois implémentations à maintenir.

Quatre règles expliquent la quasi-totalité des hreflang cassés. Chaque version doit se lister elle-même en plus des autres. Les liens doivent être réciproques : si deux pages ne pointent pas l'une vers l'autre, Google ignore les annotations. Les URL doivent être absolues, avec le protocole. Et une valeur x-default, que Google conseille d'ajouter, couvre les visiteurs dont la langue ne figure dans aucune version.

Voici l'annotation réelle d'un de nos articles, publié dans nos cinq langues actives.

La traduction transpose des phrases. La localisation de site web adapte tout ce qui entoure ces phrases pour qu'un visiteur du marché visé n'ait rien à convertir mentalement. Un site traduit se comprend, un site localisé se lit sans friction. La différence se voit rarement dans le corps de texte et presque toujours dans les formulaires, les prix et les documents légaux, c'est-à-dire exactement là où se joue la conversion.

Ce qui change au-delà des mots : le format des dates, la devise et la mention de la TVA, les unités, les champs d'adresse et de code postal, le format de téléphone, les mentions légales et la politique de confidentialité, les moyens de paiement proposés, les captures d'écran de l'interface, les exemples cités, et le niveau de familiarité du ton.

Un détail sous-estimé : les visuels. Une capture d'écran de tableau de bord en anglais dans une page française annule une bonne partie du travail de traduction, parce qu'elle dit au visiteur que le produit, lui, n'a pas été traduit.

La localisation touche aussi le code. Selon le W3C, la langue par défaut d'une page se déclare avec un attribut lang sur la balise html, et tout passage rédigé dans une autre langue doit porter son propre attribut. C'est ce qui permet aux lecteurs d'écran de prononcer correctement un nom de produit étranger au milieu d'un paragraphe français.

Une URL localisée reprend les mots du marché visé : /fr/tarifs plutôt que /fr/pricing. Google indique qu'il est tout à fait acceptable d'employer des mots localisés dans une URL, à condition de rester en encodage UTF-8. Le gain est double. Le visiteur lit l'adresse et sait où il arrive avant de cliquer. Et le mot-clé de la langue apparaît dans l'URL affichée en résultat de recherche.

Notre propre site applique cette règle partout. Il tourne sur cinq locales actives, l'anglais à la racine et les quatre autres derrière un préfixe. Aucun slug n'est partagé : le guide de structure s'appelle /fr/blog/arborescence-site-web en français et /de/blog/website-struktur-planen en allemand. Le hreflang les relie par un identifiant stable stocké dans les données, jamais par une comparaison d'adresses.

La contrepartie est réelle et il vaut mieux la connaître avant de commencer. Chaque renommage de slug crée une redirection permanente que vous porterez indéfiniment. Notre fichier de redirections en compte aujourd'hui plus de 320, accumulées au fil des localisations et des réécritures de titres. Ce n'est pas un problème, c'est un coût de gestion, et il grandit avec le nombre de locales.

Si vous partez d'un site existant, faites l'inventaire des URL avant de traduire quoi que ce soit. Notre guide de préparation à une refonte décrit la séquence, et elle vaut aussi pour un passage au multilingue.

Quatre questions suffisent à départager les outils. Le CMS gère-t-il les langues nativement ou par extension payante ? Peut-on traduire le slug, et pas seulement le contenu ? Le hreflang se génère-t-il tout seul ou faut-il le poser à la main ? Et que se passe-t-il quand une page existe en français mais pas encore en néerlandais ? Cette dernière question élimine plus de candidats que les trois autres réunies.

Un site multilingue WordPress passe presque toujours par une extension : WPML en version payante, Polylang en version gratuite et payante. Les deux fonctionnent, les deux ajoutent une couche à maintenir à chaque mise à jour du noyau WordPress et des thèmes. Webflow propose depuis 2023 une fonction de localisation intégrée, facturée par locale supplémentaire.

Du côté des stacks sur mesure, un CMS headless comme Storyblok, Contentful ou Sanity sépare le contenu de l'affichage et traite les langues comme des champs, ce qui simplifie les traductions partielles. Next.js gère nativement le routage par locale, ce que nous utilisons sur ce site. Le comparatif Next.js, WordPress et Webflow détaille les compromis de chaque option.

Un avis, à contre-courant du réflexe habituel : le nombre de langues compte moins que le rythme de publication. Deux locales alimentées chaque semaine demandent plus d'outillage que cinq locales figées après le lancement.

Le référencement d'un site multilingue soulève trois craintes, dont une seule est sans objet. La duplication n'en est pas une : Google considère que les versions localisées d'une page ne sont des doublons que si le contenu principal reste non traduit. Traduire réellement suffit donc à écarter le risque. La vraie difficulté vient de deux autres endroits, moins commentés.

La première est la cannibalisation entre variantes d'une même langue. Si exemple.fr et exemple.com/fr/ servent le même texte français, il faut désigner une version préférée avec une balise canonique et laisser le hreflang faire le reste. Deux versions concurrentes dans la même langue se volent des positions, alors que deux langues différentes ne se gênent jamais.

La seconde est la demande, et c'est celle qui coûte le plus cher quand on l'ignore. Le volume de recherche ne se traduit pas. Un mot-clé qui pèse lourd en anglais peut être marginal en français, et l'expression courte que les Français tapent réellement n'est presque jamais la traduction littérale de l'expression anglaise. Traduire une liste de mots-clés produit un site grammaticalement correct et commercialement muet.

La conséquence pratique : chaque locale demande sa propre recherche de mots-clés, donc parfois ses propres pages. Une page qui n'existe qu'en néerlandais parce que la demande n'existe que là-bas est une décision saine, pas une anomalie de structure. C'est le type d'arbitrage que traitent nos services SEO.

Dernier point technique : produisez un sitemap qui couvre toutes les langues et déclarez les variantes, plutôt qu'un sitemap par version isolée.

Le budget d'une création de site web multilingue se décompose en deux blocs qu'il faut chiffrer séparément. Le socle, c'est le site lui-même : conception, design, développement, intégration. Sur notre page tarifs, une landing page démarre à €1 500, un site corporate à €5 000, un portail web à €9 000. Ces montants couvrent la première langue.

Le second bloc, propre au multilingue, dépend de facteurs que personne ne peut deviner sans voir le projet : le nombre de langues, le volume de mots réellement traduits, la présence ou non d'un glossaire, et la quantité d'éléments à refaire en dehors du texte. Une agence qui annonce un prix par langue avant d'avoir compté les pages annonce une moyenne, pas un devis.

Côté délais, la traduction n'est jamais le goulot d'étranglement. La relecture par un locuteur natif et la validation interne le sont presque toujours, parce qu'elles dépendent de la disponibilité de personnes qui ont un autre métier. Prévoyez cette étape dans le planning, pas en fin de projet.

Enfin, la maintenance grandit avec le nombre de locales. Nos forfaits démarrent à €500 par mois pour la formule Essentials, montent à €2 500 pour Growth et à €5 000 pour Scale. Le détail poste par poste d'un budget site web figure dans notre analyse des prix.

La plupart des sites multilingues butent sur les mêmes points, et aucun n'est difficile à corriger tant que le site est jeune. Les quatre premiers de la liste ci-dessous ont un trait commun : ils ne déclenchent aucune erreur visible. La page s'affiche, le menu fonctionne, rien ne signale que le signal envoyé aux moteurs a disparu en route. C'est ce qui les rend durables.

La redirection automatique selon la langue du navigateur. Google recommande de l'éviter : elle empêche les visiteurs et les robots d'accéder aux autres versions. Proposez un sélecteur de langue visible, pas un aiguillage forcé.

Le hreflang non réciproque. Une version qui pointe vers les autres sans être citée en retour voit ses annotations ignorées. C'est l'erreur la plus silencieuse de toutes : rien ne casse, rien ne s'affiche, le signal disparaît simplement.

La traduction automatique publiée sans relecture. Elle fait illusion en survol et rate systématiquement les termes métier, les noms de produits et les formules commerciales.

Le gabarit traduit, le contenu resté en anglais. Menu et pied de page en français, corps de texte en anglais : la page sera lue comme anglaise, et le visiteur repartira.

Les URL relatives dans le hreflang, alors que Google exige des adresses absolues. L'oubli de x-default, qui laisse les visiteurs des autres langues sans page de repli. Les formulaires non localisés, avec un champ d'état américain sur un site français. Et enfin la suppression d'une locale sans redirections, qui transforme des dizaines d'URL indexées en erreurs 404.

La maintenance d'un site multilingue tient à trois règles simples. Une seule langue fait autorité et sert de source pour toutes les autres. Chaque modification de la source ouvre une tâche par langue, sinon les versions divergent en silence. Et un glossaire fige la traduction des termes métier, pour que le même mot ne soit pas rendu de trois façons dans trois pages.

Ce qui aide vraiment, ce sont les contrôles automatiques. Vérifier que chaque page a bien ses annotations réciproques, qu'aucune locale n'a de page orpheline, que les redirections ne forment pas de chaîne. Une page publiée dans quatre langues sur cinq n'est pas visible à l'oeil nu, elle se détecte par script.

Notre propre installation donne un ordre de grandeur de ce que cela représente. Cinq locales actives, l'anglais à la racine et les autres préfixées. Des slugs traduits partout, donc un identifiant stable pour relier les versions. Des miroirs markdown par locale, destinés aux robots des assistants IA qui lisent mal le rendu JavaScript. Et plus de 320 redirections permanentes accumulées depuis la mise en place.

Un dernier conseil, valable quel que soit le nombre de langues. Publiez la deuxième langue en entier avant d'envisager la troisième. Un site complet en deux langues rapporte davantage qu'un site à moitié traduit en cinq, et il coûte nettement moins cher à tenir. Si vous hésitez sur le périmètre, commencez par cadrer le projet avec nos services, la question du nombre de locales se règle mieux une fois l'arborescence posée.