# Antipatterns d’URL bilingue : un identifiant traduit avec un slug incohérent > Ce qu'on observe régulièrement sur les sites de billetterie culturelle bilingues, pourquoi ça complique le suivi analytique, et quoi harmoniser avant que ça ne coûte cher. - Auteur : Clément Hadrot - Publié le : 2024-08-08 - Mis à jour le : 2024-08-08 - Catégorie : Multilingue - URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/antipatterns-url-bilingue-billetterie/ ## L’essentiel - Un identifiant numérique traduit casse la lisibilité et le suivi - Un slug traduit littéralement perd le sens commercial de l'URL - Harmoniser une convention avant la première mise en ligne, pas après « /fr/spectacle/id-4521-le-lac-des-cygnes/ » d'un côté, « /en/show/swan-lake-4521-id/ » de l'autre : sur le papier, les deux URL désignent la même représentation. Dans les tableaux de suivi analytique, elles apparaissent pourtant comme deux pages totalement distinctes, sans lien évident entre elles pour qui ne connaît pas la structure interne du site. Ce type d'incohérence se rencontre régulièrement sur les sites de billetterie culturelle traduits en plusieurs langues, où l'identifiant de la représentation, censé rester stable, finit par bouger de position ou de format d'une langue à l'autre au fil des évolutions du site. ## Ce qu'on observe Trois variantes de convention d'URL coexistent souvent sur un même site multilingue, généralement parce que des développeurs différents sont intervenus à des périodes différentes sans documenter de règle commune : - L'identifiant en préfixe dans une langue, en suffixe dans l'autre, comme dans l'exemple ci-dessus. - Le slug traduit littéralement dans une langue mais laissé en version courte non traduite dans l'autre, par exemple `/le-lac-des-cygnes/` contre `/lac-des-cygnes-en/` avec un suffixe de langue ajouté au lieu d'utiliser le préfixe de répertoire standard de Polylang. - Un identifiant purement numérique traduit involontairement lors d'un export/import de contenu, l'ID de représentation d'une langue ne correspondant plus à celui de l'autre après une migration. ## Pourquoi c'est un problème Au-delà de l'aspect esthétique, ces incohérences ont un coût concret sur le suivi analytique. Un outil comme Google Analytics ou Matomo, configuré pour regrouper les pages par contenu logique plutôt que par URL brute, doit s'appuyer sur une convention stable pour rapprocher les performances d'une représentation entre ses différentes langues. Sans convention fiable, l'équipe marketing compare des statistiques de trafic par URL isolée, sans vision consolidée par spectacle. > L'essentiel à retenir : Un identifiant numérique traduit casse la lisibilité et le suivi ; Un slug traduit littéralement perd le sens commercial de l'URL ; Harmoniser une convention avant la première mise en ligne, pas après Le second effet, plus insidieux, touche le référencement : des identifiants numériques qui changent de position dans l'URL selon la langue compliquent la mise en place propre des balises `hreflang`, qui doivent pointer vers des URL stables et prévisibles pour chaque variante linguistique d'une même page. ## Quoi harmoniser La convention retenue pour corriger ce site a fixé trois règles simples, documentées dans le guide de contribution interne de l'équipe : 1. L'identifiant numérique de représentation reste toujours en position finale de l'URL, jamais en préfixe, quelle que soit la langue. 2. Le slug littéral se traduit entièrement (titre du spectacle traduit), jamais partiellement ni laissé en langue source par défaut. 3. Le répertoire de langue de Polylang (`/fr/`, `/en/`) reste l'unique marqueur de langue dans l'URL, sans suffixe de langue additionnel dans le slug lui-même. ### Migrer sans casser le référencement acquis Harmoniser une convention d'URL sur un site déjà indexé exige une campagne de redirections 301, une par ancienne URL non conforme vers sa nouvelle version, plutôt qu'un renommage silencieux qui casserait les liens entrants déjà construits vers les anciennes adresses. ## Ce que cet article ne traite pas La mise en place technique détaillée des balises `hreflang` fait l'objet d'un traitement séparé et n'est pas reprise ici : l'objectif de cet article est uniquement de documenter le problème d'incohérence d'URL en amont, avant même de poser la question du référencement. > Une convention d'URL multilingue qui n'est pas écrite noir sur blanc dans un document de référence finit toujours par diverger, développeur après développeur. ## En résumé L'incohérence d'URL entre langues n'est presque jamais un choix technique délibéré, c'est le symptôme d'une convention jamais formalisée. La corriger tôt, avant la première mise en ligne d'un site de billetterie ou de tout autre site multilingue à forte volumétrie de pages, coûte infiniment moins cher qu'une campagne de redirections après coup.