Notre propre site est bilingue FR/EN : ce que ça nous a appris sur le hreflang et les IA

1. Un site construit en double dès le départ

Nous parlons régulièrement, sur ce blog, du travail invisible qui conditionne la performance réelle d'un site hôtelier — hreflang, schema, robots.txt, structure canonique. Ce mois-ci, plutôt que de décrire ce travail chez un client, nous voulons le montrer chez nous. Ce site, hotel-website.com, est bilingue français/anglais depuis sa toute première version. Pas une traduction ajoutée après coup, pas un plugin de traduction automatique posé sur un site conçu en une seule langue : chaque page existe en deux exemplaires, l'un en français à la racine du domaine, l'autre en anglais sous /en/, et les deux sont explicitement reliés l'un à l'autre.

Cet article que vous lisez en français a un jumeau anglais exact, à l'adresse /en/blog/multilingual-hreflang-ai-case-study/. L'inverse est vrai aussi : la version anglaise pointe vers celle-ci. Ce lien réciproque n'est pas cosmétique. C'est le mécanisme technique précis — le hreflang — qui indique aux moteurs de recherche et, de plus en plus, aux systèmes d'IA, laquelle des deux pages servir à quel visiteur, et que les deux ne sont pas des pages concurrentes mais des variantes linguistiques d'un même contenu.

Nous avons décidé d'écrire cet article parce que nous appliquons cette discipline chez nos clients hôteliers depuis des années, et que la construire pour notre propre site nous a obligés à la formaliser proprement, sans raccourci. Voici exactement comment elle fonctionne, dans notre propre code, et ce que sa maintenance quotidienne nous a appris.

2. Le mécanisme exact, tel qu'il tourne sur ce site

Chaque page de ce site — page de service, article de blog, page légale — déclare deux informations en haut de son fichier : sa propre URL canonique, et l'URL de sa variante dans l'autre langue. Pour l'article que vous lisez, ces deux valeurs sont https://hotel-website.com/blog/multilingue-hreflang-ia-etude-de-cas/ pour la version française et https://hotel-website.com/en/blog/multilingual-hreflang-ai-case-study/ pour la version anglaise.

Ces deux valeurs remontent ensuite dans un gabarit d'en-tête partagé par toutes les pages du site. C'est ce gabarit — pas chaque page individuellement — qui génère automatiquement les balises que les moteurs de recherche et les crawlers IA vont lire : une balise rel="canonical" qui confirme l'adresse officielle de la page en cours, puis trois balises rel="alternate" — une avec hreflang="fr" pointant vers la version française, une avec hreflang="en" pointant vers la version anglaise, et une avec hreflang="x-default", qui indique quelle version servir à un visiteur dont la langue ne correspond à aucune des deux — chez nous, la version française, puisque c'est notre langue par défaut.

Le point important, techniquement modeste mais déterminant en pratique : parce que ces balises sont générées automatiquement par le gabarit à partir des deux URLs déclarées en haut de chaque page, nous n'avons jamais à écrire du hreflang à la main. Nous déclarons une paire d'URLs ; le site se charge de produire une sortie cohérente et correctement formée à chaque fois. C'est ce qui rend la discipline tenable sur la durée, sur des dizaines de pages, plutôt que dépendante de la vigilance de la personne qui édite le contenu ce jour-là.

3. Leçon n°1 : la paire doit être exacte et réciproque

La première leçon, et la plus fondamentale, est que le hreflang fonctionne par paires, et qu'une paire n'a de valeur que si elle est parfaitement réciproque. Si la page française déclare que sa variante anglaise se trouve à telle adresse, cette adresse anglaise doit, de son côté, déclarer que sa variante française se trouve exactement là où se trouve réellement la page française — pas à une ancienne URL, pas à une redirection, pas à une adresse approximative.

Une réciprocité cassée ne produit généralement pas d'erreur visible pour un visiteur humain. Le site continue de s'afficher normalement dans les deux langues. Ce qui se dégrade, silencieusement, c'est la confiance qu'un moteur de recherche ou un système d'IA accorde à la relation entre les deux pages. Une IA qui répond à une question posée en anglais sur un établissement doit pouvoir identifier avec certitude quelle page anglaise est la bonne source à citer. Si le signal hreflang est incohérent — une direction pointe vers une URL, l'autre vers une adresse différente ou obsolète — le système perd une partie de cette certitude, et le risque augmente qu'il cite la mauvaise version, ou qu'il traite les deux langues comme des pages dupliquées plutôt que complémentaires.

Sur notre propre site, cette réciprocité tient précisément parce qu'elle n'est jamais laissée à la mémoire de qui édite le contenu. Chaque page ne déclare qu'une seule information dépendante d'une autre page — l'URL de sa variante — et le reste (canonical, les trois balises alternate) est déduit automatiquement de cette déclaration. Moins il y a de valeurs saisies manuellement, moins il y a d'occasions de les désynchroniser.

4. Leçon n°2 : les deux langues naissent ensemble, pas l'une après l'autre

La deuxième leçon découle directement de la première : un nouveau contenu doit exister dans ses deux langues au moment de sa publication, pas la version française aujourd'hui et la version anglaise "quand on aura le temps". Une page qui n'existe que dans une langue n'est pas simplement incomplète — elle rend impossible la paire réciproque décrite plus haut. On ne peut pas déclarer une variante anglaise qui n'existe pas encore, et une page publiée sans sa déclaration hreflang correcte laisse un signal ambigu aux crawlers pendant toute la période où elle reste orpheline.

C'est une discipline de production de contenu autant qu'une discipline technique. Chaque article que nous publions sur ce blog est écrit en français et en anglais avant sa mise en ligne, précisément pour que la paire hreflang soit correcte dès la première visite d'un crawler. Nous avons vu, chez des clients, des pages traduites "plus tard" rester des mois en attente de leur pendant dans l'autre langue — et pendant tout ce temps, la page existante pointe vers une URL qui n'existe pas, ou pire, personne ne l'a jamais fait pointer vers quoi que ce soit, laissant le moteur de recherche deviner seul s'il existe une alternative linguistique.

5. Leçon n°3 : traduire l'URL elle-même, pas seulement le contenu

La troisième leçon est plus discrète mais s'observe directement dans la structure d'URL de ce site. L'article que vous lisez vit à /blog/multilingue-hreflang-ia-etude-de-cas/. Sa version anglaise vit à /en/blog/multilingual-hreflang-ai-case-study/. Ce n'est pas le même segment de chemin préfixé par une indication de langue — c'est un slug véritablement traduit, dans les deux sens.

Nous aurions pu nous contenter d'ajouter /en/ devant le slug français partout sur le site et appeler cela suffisant — WPML et la plupart des systèmes multilingues permettent cette approche, et elle n'est pas techniquement fausse. Mais elle laisse un signal plus pauvre sur la table, pour deux publics différents. Pour un lecteur humain anglophone, une URL qui contient encore des mots français crée une friction de lisibilité mineure mais réelle. Pour un système d'IA qui pondère le contenu sémantique d'une URL comme un signal parmi d'autres pour comprendre de quoi parle une page, un slug traduit porte davantage d'information qu'un slug simplement préfixé. Ce n'est pas le signal le plus important de la page — le contenu et le schema comptent bien plus — mais c'est un signal gratuit dès lors qu'on a déjà traduit le contenu, et nous préférons ne pas le laisser filer.

6. Ce que cette discipline vaut ailleurs sur le site — et chez nos clients

Nous avons décrit, dans l'article sur l'iceberg du site hôtelier, la structure d'URL canonique et le hreflang comme faisant partie de la couche invisible qui détermine la performance réelle d'un site — juste sous la ligne de flottaison, avec le sitemap, les méta-descriptions et la structure de titres. C'est exactement la couche que la plupart des sites hôteliers que nous auditons gèrent mal : des balises hreflang absentes, des paires non réciproques, ou des versions linguistiques traitées par Google et par les IA comme des pages concurrentes sur les mêmes requêtes plutôt que comme des compléments l'une de l'autre.

Nous avons rencontré une variante concrète de ce même problème récemment, en reconstruisant notre plugin interne de gestion des chambres et appartements. Là, le défi n'était pas le hreflang au sens strict mais un problème adjacent et tout aussi révélateur : un fichier de configuration WPML, wpml-config.xml, qui faisait silencieusement autorité sur les réglages de traduction des taxonomies d'équipements — au point qu'un changement fait dans l'interface d'administration WPML était accepté et affiché comme actif, sans jamais réellement s'appliquer, parce que le fichier XML restait la source de vérité en coulisses. La correction a exigé de réécrire directement ce fichier XML puis de désactiver et réactiver le plugin dans son intégralité pour forcer WPML à réconcilier ses réglages. Rien de tout cela n'était visible dans l'admin tant qu'on n'avait pas ouvert le bon fichier — exactement le genre de bug qui explique pourquoi tant de sites multilingues affichent des incohérences de langue qu'aucune personne dans l'équipe ne sait expliquer.

Le fil qui relie ces deux cas — le hreflang de ce site et le bug WPML du plugin Chambres — est le même que celui qui traverse tout ce blog : une IA qui répond à un voyageur francophone et une IA qui répond à un voyageur anglophone, à propos du même hôtel, doivent toutes les deux atterrir sur la version linguistiquement correcte et canonique de ce contenu. Ce n'est pas un détail de confort pour webmaster méticuleux. C'est la condition pour qu'un système de recherche ou de réponse générative traite vos deux langues comme des atouts complémentaires plutôt que comme des pages qui se cannibalisent silencieusement l'une l'autre.