Sites web

Site multilingue : bien penser l'architecture et éviter les pièges

Traduire un site ne suffit pas à le rendre multilingue. Sans architecture pensée en amont, sans processus de contenu clair et sans hreflang fiable, une version allemande ou italienne se transforme vite en copie à moitié traduite, mal indexée et pénible à maintenir. Voici comment construire une base qui tient dans le temps, pour une PME ou une ETI qui s'adresse à plusieurs régions suisses ou à plusieurs marchés à l'international.

Pourquoi l'architecture se décide avant la première ligne traduite

Un site multilingue n'est pas un site traduit après coup. La structure choisie au départ, URLs, arborescence, gestion des contenus, conditionne le référencement, l'expérience utilisateur et le coût de maintenance pour les années suivantes. Revenir dessus une fois le site en ligne veut souvent dire tout reconstruire.

Pour une PME ou une ETI suisse qui s'adresse au marché romand, au marché alémanique et parfois à une clientèle italophone, ou plus largement à l'international, ce choix touche aussi l'organisation interne : qui traduit, qui valide, à quelle fréquence, sur quel outil. Une architecture pensée dès le départ absorbe ces questions. Une architecture bricolée les fait remonter à chaque mise à jour.

Sous-dossiers, sous-domaines, domaines par pays : quelle structure choisir ?

Trois familles de structures dominent, chacune avec ses compromis. Le tableau ci-dessous résume les points qui comptent le plus au moment de choisir.

Pour la grande majorité des PME et ETI suisses qui visent la Suisse romande, la Suisse alémanique et la Suisse italienne depuis une seule structure, les sous-dossiers restent l'option la plus simple à maintenir : un seul certificat, un seul hébergement, un seul robot d'indexation à surveiller.

Comment gérer le contenu par langue sans perdre le fil ?

La vraie difficulté n'est pas de traduire une fois, mais de maintenir plusieurs versions synchronisées dans le temps, sans que l'une prenne du retard sur l'autre.

• Traduction humaine sur les pages qui vendent. Accueil, services, contact : la traduction automatique brute reste risquée sur les contenus qui engagent la marque.
• Une source unique de référence. Souvent la langue historique de l'entreprise, qui sert de point de départ à chaque mise à jour, pour éviter que les versions divergent avec le temps.
• Un statut visible par page. Traduit, en cours, à traduire : cela évite de publier une page vide ou un texte resté dans une autre langue par oubli.
• Un contenu non encore traduit assumé comme tel. Affiché clairement, plutôt que masqué ou remplacé par un texte générique qui trompe le visiteur.

Le bon réflexe organisationnel consiste à traiter chaque langue comme un contenu à part entière, avec son propre calendrier de mise à jour, plutôt que comme une simple copie à recaler après chaque changement sur la version principale.

Le sélecteur de langue : quelle expérience pour ne pas braquer le visiteur ?

Le sélecteur de langue est un détail d'interface qui a un impact disproportionné : mal placé ou mal pensé, il fait perdre des visiteurs avant même qu'ils lisent une ligne de contenu.

• Toujours visible et accessible depuis n'importe quelle page, pas seulement depuis l'accueil.
• Un choix explicite du visiteur, mémorisé pour ses visites suivantes, plutôt qu'imposé à chaque nouvelle session.
• Jamais de redirection automatique brutale basée sur l'adresse IP ou la géolocalisation : un visiteur romand qui navigue en anglais professionnel ne doit pas être forcé vers une version qu'il n'a pas choisie.
• Une bascule qui reste sur la même page, dans son équivalent traduit, et non un renvoi systématique vers l'accueil de l'autre langue.

Comment poser le hreflang correctement côté technique ?

Le hreflang indique aux moteurs de recherche quelle version linguistique proposer à quel public. Mal posé, il ne casse rien visuellement, mais il fait apparaître la mauvaise version dans les résultats, ou pire, aucune des deux.

• Auto-référencement systématique. Chaque page doit déclarer un lien hreflang vers elle-même, en plus des versions dans les autres langues : c'est l'une des causes d'erreur les plus fréquentes.
• Réciprocité des balises. Si la version française pointe vers la version allemande, la version allemande doit pointer en retour vers la française.
• Une valeur par défaut. Un repli x-default oriente les visiteurs dont la langue ne correspond à aucune version disponible.
• Des codes de langue standards. Langue seule, ou langue-région pour distinguer par exemple un français de Suisse d'un français de France.
• Une cohérence avec le plan du site. Le hreflang doit correspondre au sitemap et au contenu réellement présent sur chaque page : une déclaration qui ne correspond à rien de concret perd toute valeur.

Ces règles sont simples sur le papier, mais elles cassent facilement lors d'une refonte, d'un changement d'URL ou de l'ajout d'une nouvelle langue si personne ne les revérifie à chaque étape.

Performance et maintenance : comment un site multilingue tient dans la durée

Un site multilingue qui vieillit bien n'est pas celui qui a été le mieux construit au lancement, c'est celui dont la maintenance a été prévue et attribuée dès le départ.

Les pièges classiques qui coûtent cher

1. Traduire uniquement le texte visible. Métadonnées, URLs, formulaires et messages d'erreur restent souvent dans la langue d'origine, oubliés du périmètre de traduction.
2. Dupliquer toute la structure pour une langue marginale. Une version qui ne représente qu'une fraction du trafic alourdit la maintenance sans bénéfice proportionnel.
3. Laisser une version se figer. Faute de responsable désigné, une langue prend du retard jusqu'à ce que l'écart avec la version principale devienne visible des visiteurs.
4. Changer de structure d'URL sans plan de redirection complet. Cela casse les liens existants et fait perdre l'historique construit sur chaque version.
5. Considérer le hreflang comme réglé une fois pour toutes. Il doit être revérifié à chaque évolution du site, pas seulement au lancement.

FAQ