Traduire un site web : méthode et pièges à éviter

Prenez un site traduit en allemand en quelques jours. Les pages sont là, le menu aussi. Puis un visiteur remplit le formulaire de contact et reçoit sa confirmation en français, tape une mauvaise adresse et tombe sur une page d’erreur qui ne parle pas sa langue ; dans les résultats de Google, le titre de la page est resté en français. Aucune de ces erreurs n’apparaît quand on relit les pages : traduire un site, c’est traduire tout ce que le visiteur lit, à des adresses propres à chaque langue.

Ce guide rassemble les décisions à prendre, de l’adresse à la relecture ; la rubrique traduction de site détaille chacune dans un article à part.

Une précision sur notre point de vue : nous opérons Palmora Property pour un client, un site d’annonces immobilières de plus de 3 000 adresses publié en six langues (anglais, français, thaï, russe, chinois et allemand). Nous publions aussi ce site-ci, en français et en anglais. Les erreurs citées plus bas ont été trouvées sur le premier.

Que décider avant de traduire le premier mot ?

Trois décisions se prennent avant d’ouvrir le moindre fichier de traduction, parce qu’elles coûtent cher à défaire ensuite.

Les langues, dans l’ordre. Une langue s’ouvre pour un marché où une demande existe, pas pour allonger la liste. Avant de traduire tout le site, testez la demande sur quelques pages : nous détaillons comment choisir ses marchés, et entre un domaine par pays, un sous-domaine ou un sous-répertoire.

La forme des adresses. Elle se décide avant que le catalogue grossisse : c’est l’objet de la section suivante.

Qui lit chaque langue. Une langue que personne ne lit en interne se publie relue, par quelqu’un de l’extérieur s’il le faut. Sinon, ses erreurs restent en ligne jusqu’à ce qu’un visiteur les signale.

Pourquoi donner une adresse à chaque langue ?

Parce que c’est ce que Google recommande, et ce qui permet à chaque version d’être trouvée :

La même page ajoute trois recommandations. Ne redirigez pas automatiquement un visiteur d’une version linguistique vers une autre. Tenez-vous à une langue par page, sans traduction côte à côte : Google déduit la langue d’une page de son contenu visible. Et proposez sur chaque page des liens vers ses autres versions, pour que chacun choisisse la sienne.

Deux balises décrivent ensuite chaque version. L’attribut lang d’abord : le W3C le demande sans détour, « Utilisez toujours un attribut de langue sur la balise html pour déclarer la langue du texte par défaut dans la page. » La langue déclarée sert à la synthèse vocale et au braille, au choix des polices et aux correcteurs d’orthographe, selon le W3C.

Les balises hreflang, ensuite, relient les versions entre elles : chaque version linguistique se référence elle-même et indique toutes les autres, dans le code de la page, dans les en-têtes HTTP ou dans le plan du site, trois méthodes équivalentes pour Google. La valeur x-default désigne la page à montrer quand aucune langue ne correspond. Nous les détaillons dans notre guide des balises hreflang et de leurs erreurs.

Reste la forme des adresses. La page de Google sur les sites multilingues accepte les termes localisés dans l’URL : /fr/a-vendre/ plutôt que /fr/for-sale/. Le choix se fait tôt. Sur Palmora Property, des articles en anglais ont gardé des adresses en français : les reprendre demanderait une redirection par page, et un contrôle de chacune, pour un gain qui ne le justifie pas.

Que faut-il traduire au-delà des pages ?

Tout ce que le visiteur lit, y compris ce qu’il ne voit pas en parcourant le site :

Les gabarits demandent la même attention que les pages. Un titre assemblé à partir de morceaux traduits un par un sort faux dans la langue d’arrivée : c’est ainsi qu’une page de liste de Palmora Property s’est intitulée « Villas Zu verkaufen » en allemand. Il faut un gabarit complet par langue, avec le singulier, le pluriel et l’accord avec le nombre, qui prend trois formes en russe.

Comment garder le même vocabulaire dans chaque langue ?

Le vocabulaire se fixe avant le premier passage, pas pendant la relecture :

Les mots-clés y entrent aussi, mais ils ne se traduisent pas : on les cherche dans chaque langue, parmi les termes que les gens du pays tapent vraiment, puis le terme choisi vaut pour toutes les pages, titres et descriptions compris.

Ensuite, une mémoire de traduction range chaque phrase validée, segment par segment : à chaque mise à jour, seul ce qui a changé repart en traduction. Sur Palmora Property, après le premier passage, 95 % des segments sont repris de la mémoire sans nouvel appel au modèle ; sur un site dont le texte change davantage, la part reprise est plus faible. Le fonctionnement et les réglages sont dans notre article sur la mémoire de traduction en entreprise.

Qui relit quoi ?

Relire demande quelqu’un qui lit la langue, et son temps est compté : il va d’abord là où une erreur coûte le plus. Les offres, les prix, les conditions et les pages qui vendent se relisent en entier, à chaque modification. Une fiche répétitive se valide sur son gabarit, relu en entier dans chaque langue, puis sur un échantillon de pages.

Ce partage a ses limites : Google juge essentiel de vérifier tout contenu généré par l’IA avant de le publier, métadonnées comprises. Un échantillon vaut pour des centaines de fiches qui se ressemblent, jamais pour une offre ou des conditions. Le détail, type de page par type de page, est dans notre comparatif entre traduction automatique et traduction relue.

Quels contrôles passer avant de publier une langue ?

Une langue s’ouvre quand elle passe six contrôles :

1. 01Chaque texte existe dans chaque langue.

   Un contrôle de parité vérifie qu’aucune clé ne manque, comme celui qui tourne avant chaque construction de Palmora Property.

2. 02La langue est déclarée dans chaque liste du code qui énumère les langues.

   Sur Palmora Property, l’allemand était servi sur toutes ses adresses, mais absent de plusieurs de ces listes : des pages s’affichaient vides tout en répondant 200, jusqu’à leur correction.

3. 03Les balises hreflang ne pointent que vers des pages qui existent.

   Une page en noindex n’en émet aucune.

4. 04Le plan du site liste chaque version.

   Seulement celles qui existent : une version annoncée et absente est une erreur.

5. 05Une mauvaise adresse répond dans la langue demandée.

   Sur Palmora Property, la page 404 s’affichait en anglais quelle que soit la langue de l’adresse, jusqu’à sa correction.

6. 06Les formulaires et les e-mails passent de bout en bout.

   Dans chaque langue, du clic à la confirmation reçue.

La liste de contrôle des balises elles-mêmes, en sept points, est dans le guide hreflang cité plus haut.

Que coûte un site maintenu en plusieurs langues ?

Le premier passage n’est qu’une partie de la facture. Une langue ouverte s’entretient aussi longtemps que le site vit :

Deux leviers font baisser la seconde colonne. La mémoire de traduction, vue plus haut. Et le choix du modèle, langue par langue : sur Palmora Property, le passage de DeepL à Gemini a divisé par 60 le coût de la traduction, un rapport propre à ce site et à ses six langues. Avant d’ouvrir une langue, comptez donc la seconde colonne autant que la première.

Par où commencer ?

Par une seule langue, et d’abord les pages qui vendent : l’accueil, les offres, le formulaire de contact et ses e-mails. Fixez les adresses et le glossaire, passez les six contrôles, puis ouvrez la langue. Les fiches et les articles suivent, une fois le gabarit tenu.

Pour savoir quelles pages traduire d’abord, et dans quelle langue, envoyez-nous l’adresse de votre site et les langues que vous visez : nous partons de ce qui vend déjà dans votre langue.

Questions fréquentes

Sources

1. Le W3C le demande sans détour (nouvel onglet)w3.org
2. Selon le W3C (nouvel onglet)w3.org
3. Chaque version linguistique se référence elle-même et indique toutes les autres (nouvel onglet)developers.google.com
4. Google juge essentiel (nouvel onglet)developers.google.com