Comment planifier un site multilingue en Suisse

Partir des marchés et des besoins clients, pas du nombre de langues

La Suisse est multilingue, mais toutes les entreprises suisses n’ont pas besoin de proposer chacune de leurs pages en allemand, en français, en italien et en anglais. La question utile consiste à déterminer quels clients vous souhaitez servir, ce qu’ils doivent pouvoir accomplir et si votre équipe peut leur répondre dans la langue publiée.

Commencez par les données issues des échanges commerciaux, des demandes reçues, du service client, des requêtes de recherche et des projets d’expansion. Distinguez une langue qui contribue déjà au chiffre d’affaires d’une langue qui relève encore de l’expérimentation. Un parcours d’achat complet en allemand et en français inspire davantage confiance que quatre boutons de langue menant vers des contenus partiels ou obsolètes.

Définissez la tâche principale de chaque public. Un responsable des achats peut avoir besoin de caractéristiques techniques et d’un devis. Un client local peut rechercher une disponibilité et un numéro à appeler. Un partenaire international peut vouloir vérifier les références de l’entreprise. Ces besoins déterminent les pages, les preuves et les formulaires à localiser ensemble.

• Dressez la liste des marchés actuels et visés, des décideurs et de la couverture des services.
• Consignez la langue employée pour la vente, la prestation et le service après-vente.
• Repérez les pages qui influencent un achat, une demande, un contrat ou une sollicitation d’assistance.
• Ne promettez pas une prise en charge linguistique que l’entreprise ne peut pas assurer.

Choisir délibérément entre versions linguistiques et régionales

Un code linguistique indique une langue. Un code régional facultatif précise la région visée. L’allemand destiné aux lecteurs en général peut utiliser de. Un contenu allemand spécifiquement adapté à la Suisse peut utiliser de-CH. Le même raisonnement s’applique à fr et fr-CH, à it et it-CH ainsi qu’à en et en-CH.

Un code de pays seul ne désigne pas une langue. ch n’est donc pas une valeur linguistique hreflang valide. Ajouter une région à chaque URL augmente également le travail de maintenance. Réservez cette pratique aux cas où les prix, la terminologie, les informations juridiques, la disponibilité ou l’offre diffèrent réellement.

Conservez une URL canonique pour chaque version de page prévue. Ne créez pas de variantes suisse, allemande et autrichienne au texte identique dans le seul but d’occuper davantage de résultats de recherche. Lorsque le contenu est véritablement identique entre les régions, une version linguistique plus générale constitue souvent le choix le plus clair.

• Utilisez des versions définies uniquement par la langue pour les contenus largement partagés.
• Utilisez des versions associant langue et région lorsque le public ou l’offre présente une différence régionale significative.
• Alignez l’intention de l’URL, de l’URL canonique et de hreflang.
• Documentez la raison d’être de chaque variante régionale.

Construire une matrice des versions locales avant de concevoir les modèles

Une matrice des versions locales transforme un plan de traduction abstrait en inventaire. Attribuez une ligne à chaque objectif de page et indiquez le statut de chaque version locale. Consignez l’URL, l’URL canonique, le responsable, la version source, l’état de validation et les variantes correspondantes. Vous découvrirez ainsi les lacunes avant qu’elles ne deviennent des menus défaillants ou des annotations trompeuses.

Prenons l’exemple d’une société suisse de conseil fictive. Elle propose ses pages de conseil en quatre langues, mais un service réglementaire spécialisé n’existe qu’en allemand, car la prestation est actuellement assurée uniquement dans cette langue. Une matrice correcte n’invente pas trois équivalents vides. Elle publie la page allemande et l’exclut d’un groupe multilingue jusqu’à ce que des services réellement localisés soient disponibles.

Des identifiants stables aident les équipes à faire correspondre les pages équivalentes, même lorsque les termes des URL sont traduits. Le chemin visible peut être localisé tandis que le système éditorial conserve un identifiant de page commun.

Créer des groupes hreflang complets et réciproques

Hreflang établit la correspondance entre des versions localisées. Il ne traduit pas le contenu et ne détermine pas lui-même la langue. Google accepte les annotations dans l’en-tête HTML, les en-têtes HTTP ou un sitemap XML et précise que l’application simultanée des trois méthodes n’apporte aucun avantage dans la recherche. Choisissez la méthode que votre équipe peut générer et tester de façon constante.

Chaque membre d’un groupe doit se référencer lui-même et référencer tous les autres membres. Si la page A désigne la page B, mais que B ne renvoie pas la référence, Google peut ignorer cette association. Les URL doivent être absolues et mener à la page canonique prévue.

Une URL x-default peut servir de solution de repli aux utilisateurs qui ne correspondent à aucune version, par exemple un sélecteur de langue ou une version largement adaptée. Elle constitue une solution de repli, pas un substitut à un plan linguistique complet.

• Utilisez des codes ISO valides pour la langue et, le cas échéant, la région.
• Incluez des autoréférences et des références réciproques.
• Faites pointer les variantes vers les URL canoniques finales et indexables.
• Ne mélangez pas les domaines de préproduction et de production.

Traduire les décisions, pas seulement les phrases

Une traduction littérale peut respecter la grammaire tout en perdant le sens commercial. Les noms de produits, les preuves, les objections et les appels à l’action doivent être revus par une personne qui comprend le public et l’offre. Une navigation traduite autour d’un contenu principal en anglais ne constitue pas une expérience localisée utile.

Donnez aux traducteurs le contexte nécessaire : le lectorat, l’objectif de la page, la prochaine étape souhaitée, la terminologie approuvée et les contraintes de longueur. Confiez à une personne connaissant le marché la vérification des affirmations, des exemples et du ton. Lorsqu’un concept source ne possède pas d’équivalent naturel, reformulez-le pour le rendre clair au lieu de reproduire la structure de la phrase.

Veillez à l’exactitude des preuves dans toutes les langues. Si une étude de cas ne concerne qu’un marché, indiquez-le au lieu de la présenter comme une preuve locale. Si la disponibilité du service diffère, adaptez l’offre et l’acheminement du formulaire, et pas seulement les mots.

• Tenez un registre commun de la terminologie et des affirmations.
• Traduisez les métadonnées, les textes alternatifs des images, les erreurs et les confirmations.
• Vérifiez les liens, les téléchargements et les données structurées dans chaque langue.
• Consignez les différences intentionnelles afin que les futurs éditeurs ne les effacent pas.

Concevoir un processus fiable pour les demandes multilingues

Une page localisée échoue commercialement si l’étape suivante revient à une autre langue ou mène à une équipe incapable de répondre. Suivez le parcours depuis la page de service jusqu’à la réponse humaine, en passant par les erreurs de validation, la confirmation de réussite et la notification par e-mail.

Gardez les formulaires assez courts pour être remplis, tout en recueillant le contexte nécessaire à l’acheminement de la demande. La langue peut être déduite du chemin de la page plutôt que faire l’objet d’une question supplémentaire. Confirmez la suite du processus dans la même langue et ne promettez pas un délai de réponse auquel l’équipe ne s’est pas engagée.

Dans une société d’ingénierie fictive, les demandes en français pourraient être acheminées vers une file commerciale francophone placée sous la responsabilité d’une personne identifiée, tandis que les pièces jointes techniques iraient à une équipe de projet commune. Il s’agit d’une organisation opérationnelle, pas simplement d’un formulaire traduit.

Attribuer un responsable à chaque page et à chaque langue

La qualité multilingue se dégrade lorsque personne n’est responsable des changements après le lancement. Désignez un éditeur pour la langue source, une personne chargée de la revue dans chaque marché et un décideur pour les affirmations. Fixez un délai de traitement pour les mises à jour importantes, notamment les prix, les disponibilités, les collaborateurs, les politiques et les coordonnées.

Un processus efficace distingue les changements structurels des modifications mineures. Une nouvelle section consacrée à un service peut nécessiter une mise à jour simultanée de toutes les versions locales. Un événement régional peut ne concerner qu’une seule version. La matrice doit montrer quelles différences sont intentionnelles.

Planifiez des revues périodiques en fonction du risque commercial, pas d’un calendrier de publication arbitraire. Les pages à forte conversion et les contenus réglementés méritent une attention plus soutenue qu’une ancienne actualité.

• Désignez un responsable et une personne chargée de la revue pour chaque version locale.
• Définissez les changements qui bloquent la publication jusqu’à ce que toutes les versions soient prêtes.
• Conservez les dates de révision et les documents sources dans la fiche de contenu.
• Retirez proprement les pages linguistiques qui ne sont plus prises en charge.

Tester le groupe comme un système avant le lancement

Ne vous limitez pas au sélecteur de langue. Explorez chaque version locale, comparez les annotations canoniques et les variantes, suivez les redirections, examinez les pages mobiles et envoyez de véritables demandes de test. L’absence d’un lien réciproque sur une seule page peut affaiblir le groupe prévu.

Google recommande de conserver sur mobile le contenu principal équivalent, les titres, les métadonnées et les données structurées. Cette règle compte lorsque les modèles mobiles localisés ou les couches de consentement diffèrent de la version pour ordinateur.

Terminez par une liste d’exceptions validée. Une traduction décorative manquante peut rejoindre une liste de tâches ultérieures. Une mauvaise URL canonique, un formulaire défaillant ou la promesse d’une langue indisponible doit bloquer le lancement.

• Vérifiez le statut, l’indexabilité, l’URL canonique et hreflang pour chaque ligne de la matrice.
• Vérifiez que le changement de langue conserve la page équivalente.
• Examinez le contenu mobile et l’intégralité du parcours de demande.
• Testez de nouveau chaque groupe corrigé avant de le valider.