Notre plugin Chambres a été reconstruit : taxonomie, multilingue, et URLs anglaises propres

1. Pourquoi cette page-là, précisément, mérite l'attention

Sur un site hôtelier, il existe une page qui reçoit plus de trafic à forte intention que n'importe quelle autre : la fiche chambre, ou la fiche appartement. C'est là qu'atterrit un visiteur qui a déjà décidé qu'il séjournera peut-être dans cet établissement et qui compare maintenant les options concrètes — la vue, la surface, le type de lit, la présence d'un balcon ou d'une kitchenette. C'est aussi, presque systématiquement, la page qu'un système d'IA va chercher à citer quand un voyageur demande "quelle chambre avec vue mer coûte le moins cher à tel hôtel" ou "cet établissement propose-t-il un appartement avec deux chambres".

Et c'est, dans la plupart des sites que nous auditons, la catégorie de page la plus mal structurée techniquement. Pas parce qu'elle est négligée visuellement — les photos sont souvent excellentes — mais parce qu'il y en a beaucoup, qu'elles sont généralement générées en masse ou dupliquées à partir d'un modèle, et que personne ne revient corriger la structure de données une fois le contenu en place. Un hôtel de quarante chambres réparties en huit types, avec une déclinaison française et anglaise de chaque fiche, représente rapidement plus de soixante-dix pages individuelles à maintenir cohérentes. C'est exactement le genre de volume où les erreurs de structure passent inaperçues.

Notre plugin interne de gestion des chambres et appartements existe depuis plusieurs années et équipe déjà l'ensemble des sites hôteliers que nous construisons et gérons. Ces derniers mois, nous l'avons reconstruit en profondeur sur trois points précis, avec un lancement récent — l'hôtel Bârma Courchevel Hotel & Spa — qui nous a servi de terrain de validation grandeur nature. Voici ce qui a changé, et pourquoi chacun de ces changements compte plus qu'il n'y paraît.

2. Chambre et appartement ne sont pas la même chose — et notre plugin les traitait comme tels

Le premier changement est structurel et, avec le recul, il aurait dû venir plus tôt : nous avons introduit une taxonomie unit_type qui distingue explicitement une chambre d'un appartement, plutôt que de traiter l'appartement comme une simple variante ou un sous-type de chambre.

Cette distinction paraît presque triviale tant qu'on la voit du point de vue de l'affichage — les deux se présentent de la même façon dans une grille de résultats, avec une photo, un prix et un bouton de réservation. Elle cesse de l'être dès qu'on la regarde du point de vue du schema. Une chambre d'hôtel classique se décrit correctement avec un schema Room assez simple : un type de lit, une surface, une capacité d'accueil. Un appartement avec deux chambres et un salon séparé est un objet structurellement différent. Il a besoin de communiquer un nombre de chambres à coucher, potentiellement un nombre d'espaces de couchage distincts dans le salon (un canapé-lit, par exemple), et une organisation spatiale qu'un simple champ "type de lit" ne peut pas exprimer correctement.

Traiter les deux comme la même entité de données, avec les mêmes champs obligatoires et les mêmes champs optionnels, revient à forcer l'appartement dans un moule pensé pour la chambre — ou, à l'inverse, à alourdir chaque fiche chambre avec des champs qui ne la concernent jamais. Aucune des deux approches ne produit un schema propre. La taxonomie unit_type résout ce problème à la racine : chaque fiche sait dès sa création si elle est une chambre ou un appartement, et le plugin adapte en conséquence les champs qu'il expose et, en aval, la structure de schema qu'il génère.

3. Le bug WPML que la plupart des équipes ne trouvent jamais

Le deuxième chantier concerne les vocabulaires contrôlés associés à chaque fiche : équipements de la chambre, éléments de salle de bain, types de vue, types de lit. Nous les avons construits comme des taxonomies à part entière plutôt que comme de simples champs texte libre, précisément pour qu'ils soient traduisibles proprement via WPML plutôt que ressaisis, avec toutes les incohérences que cela implique, dans chaque langue.

C'est un chantier qui nous a fait tomber sur un bug WPML réel et suffisamment sournois pour mériter d'être documenté ici, parce qu'il illustre bien le genre de travail invisible qu'exige un site hôtelier réellement multilingue. WPML dispose d'un fichier de configuration, wpml-config.xml, qui fait autorité sur les réglages de traduction des types de contenu et des taxonomies personnalisées. Le problème : si ce fichier XML et l'interface d'administration WPML — ou la base de données elle-même — ne sont pas d'accord entre eux, c'est systématiquement le fichier XML qui gagne, silencieusement, sans avertissement affiché nulle part dans l'admin.

Concrètement, cela signifiait que basculer un réglage dans l'interface WPML — passer une taxonomie "type de vue" de "ne pas traduire" à "traduire" — ne suffisait pas. L'interface acceptait le changement, l'affichait comme actif, et WPML continuait pourtant à se comporter selon l'ancien réglage défini dans le fichier XML, parce que celui-ci restait, en coulisses, la source de vérité. Vider le cache ne changeait rien non plus — ce n'est pas un problème de cache, c'est un problème d'ordre de priorité entre deux sources de configuration qui, sur le papier, sont censées être synchronisées.

La correction en deux temps : réécrire directement le wpml-config.xml du plugin pour qu'il déclare correctement chaque taxonomie comme traduisible, puis désactiver et réactiver le plugin dans son intégralité — pas simplement vider un cache, pas simplement resauvegarder les permaliens. C'est ce cycle complet de désactivation/réactivation qui force WPML à relire le fichier de configuration et à réconcilier ses réglages internes avec ce qu'il déclare. Sans ce cycle, l'incohérence persiste indéfiniment, invisible dans l'admin, visible uniquement dans le comportement réel du site : des équipements qui restent affichés en français sur la version anglaise d'une fiche, par exemple.

Ce n'est pas un détail exotique propre à notre plugin. C'est une classe de bug que toute équipe qui construit des taxonomies personnalisées sur un site WPML rencontrera tôt ou tard. Nous le documentons ici précisément parce qu'il est du genre à passer inaperçu pendant des mois — le site a l'air multilingue, la structure existe, mais une partie du vocabulaire reste bloquée dans une seule langue sans que personne ne comprenne pourquoi tant qu'on n'a pas ouvert le fichier XML en question.

4. Des URLs anglaises propres, sans rien casser

Le troisième chantier est le plus visible pour un visiteur, même s'il reste largement une question de plomberie interne : nous avons ajouté de nouvelles URLs anglaises pour les fiches chambre et appartement — /room/{slug}/ et /apartment/{slug}/ — aux côtés des URLs françaises existantes, /chambre/{slug}/ et /appartement/{slug}/.

Avant ce changement, les fiches en anglais héritaient des mêmes segments de chemin que la version française — une fiche anglaise se retrouvait par exemple sous /chambre/deluxe-sea-view/ plutôt que sous quelque chose de véritablement anglais. Ce n'était pas cassé au sens strict — WPML gérait correctement la langue du contenu affiché — mais ce n'était pas propre non plus. Un visiteur anglophone atterrissant sur une URL qui commence par un mot français reçoit un signal discordant. Un moteur de recherche ou un crawler IA qui tente de déterminer la langue canonique d'une page à partir de son URL, en complément du hreflang et de la balise html lang, reçoit lui aussi un signal plus ambigu qu'il ne devrait l'être.

Le plugin détecte désormais automatiquement la langue de chaque fiche et génère la base d'URL correspondante — anglaise pour le contenu anglais, française pour le contenu français — sans configuration manuelle par fiche. Et parce que nous ne voulions casser aucun lien existant — ni ceux partagés par des visiteurs, ni ceux déjà indexés par Google, ni ceux qu'un système d'IA a peut-être déjà mémorisés lors d'un crawl précédent — les anciennes URLs anglaises qui utilisaient les segments français redirigent désormais automatiquement, en 301, vers leur équivalent anglais canonique. Un lien externe pointant vers l'ancienne URL continue de fonctionner ; il atterrit simplement, après une redirection propre, sur la bonne adresse.

Ce détail de redirection compte davantage qu'il n'y paraît pour la visibilité IA spécifiquement. Un système d'IA qui rencontre deux URLs différentes pour ce qui semble être le même contenu, sans signal clair indiquant laquelle est canonique, peut soit citer l'une au hasard, soit hésiter à citer l'une ou l'autre. Une redirection 301 propre élimine cette ambiguïté : il n'existe plus qu'une seule adresse valide par langue, et c'est celle-là que tout système — humain ou machine — doit retenir.

5. Pourquoi la couche de données conditionne tout ce qui vient après

Rien de ce qui précède ne se voit dans l'interface d'administration au premier coup d'œil, et rien de tout cela ne change directement l'apparence d'une fiche chambre pour un visiteur. C'est précisément le point. Ce plugin ne produit pas de contenu visible ; il produit la couche de données structurées qui rend possible un schema propre, en aval, via notre autre plugin, récemment rebaptisé Mixit7 AI Ready, qui génère le schema Room et Offer à partir de ces mêmes données.

Or un schema Room ne peut être correct que si les données sous-jacentes le sont déjà. On ne peut pas générer un schema distinguant proprement une chambre d'un appartement si le modèle de données lui-même ne fait pas cette distinction. On ne peut pas produire un schema fiable dans les deux langues d'un site si les vocabulaires d'équipements, de vues et de types de lit ne sont pas traduits de façon fiable — s'ils basculent en silence vers l'anglais par défaut à cause d'un fichier de configuration WPML mal aligné. Et on ne peut pas donner à un moteur de recherche ou à un système d'IA un signal univoque sur la version canonique d'une page si deux URLs concurrentes existent pour le même contenu dans la même langue.

C'est la raison pour laquelle nous avons investi ce temps dans une couche que la plupart des visiteurs ne verront jamais directement. Les pages chambres et appartements sont à la fois les plus consultées et les plus fragiles techniquement, précisément parce qu'elles existent en grand nombre et qu'elles sont rarement révisées une par une après leur création. Corriger la structure une fois, à la source, dans le plugin lui-même, évite de devoir corriger la même erreur des dizaines de fois sur des dizaines de fiches individuelles.

6. Ce que cela change concrètement pour les sites que nous gérons

Ce plugin, avec ces trois changements, équipe désormais toutes les fiches chambre et appartement des sites hôteliers que nous construisons et gérons — pas seulement les nouveaux lancements comme Bârma Courchevel, mais aussi, progressivement, les sites existants où nous migrons les anciennes structures vers la nouvelle taxonomie. Ce n'est pas un plugin que nous commercialisons séparément ; c'est une pièce de notre infrastructure interne, au même titre que notre plugin FAQ ou notre plugin de données structurées Mixit7 AI Ready.

Mais les trois se rejoignent sur une même conviction, déjà exprimée à plusieurs reprises sur ce blog : la qualité de ce qu'un moteur de recherche ou un système d'IA peut dire, avec exactitude, sur un établissement hôtelier dépend presque entièrement d'une couche de données que le visiteur ne voit jamais. Un site peut afficher les plus belles photos de chambre du marché ; si la donnée sous-jacente confond une chambre et un appartement, ne traduit pas fiablement ses équipements, ou expose deux URLs concurrentes pour la même page, ni Google ni ChatGPT ne pourront décrire correctement ce que l'hôtel propose réellement.