Un site touristique en 5 langues sans plugins : les leçons

Mon site fonctionne en cinq langues — espagnol, anglais, français, catalan et italien — sans WordPress, sans plugins de traduction et sans abonnement mensuel : du HTML statique, une URL par langue et une poignée de règles apprises en chemin, certaines à la dure. Cet article n'est pas de la théorie : c'est la liste des décisions que je reprendrais et des erreurs que vous pouvez vous épargner si vous allez internationaliser le site d'un hôtel, d'une agence ou de tout acteur touristique.

Pourquoi le multilingue « à plugin » reste court

La voie habituelle — installer un plugin de traduction sur WordPress — règle le texte et ignore souvent ce qui positionne vraiment. Les manques typiques : des URL non traduites ou générées automatiquement, des balises hreflang incomplètes ou absentes, un sitemap sans les versions linguistiques, et de la traduction automatique publiée sans révision. Le résultat se voit chaque semaine sur les sites touristiques : la version française existe, mais Google montre l'espagnole aux Français — ou pire, traite les deux comme du contenu dupliqué.

Le multilingue n'est pas un problème de traduction. C'est un problème d'architecture avec une couche de traduction par-dessus.

Les quatre décisions qui comptent (dans l'ordre)

1. Une URL propre par langue, décidée avant de publier. Chaque langue vit dans son sous-répertoire (/en/, /fr/, /ca/, /it/) avec la langue principale à la racine. Pas de sélecteurs qui changent le texte sans changer l'URL : si deux langues partagent une URL, une seule existe pour un moteur. Et cette décision est du genre irréversible : changer la structure d'URL ensuite oblige à des redirections permanentes, que tous les hébergements ne permettent pas — le mien, par exemple, non ; chaque slug a donc été choisi en sachant que c'était pour toujours.

2. Des slugs traduits, pas seulement des textes traduits. La page de services en anglais ne devrait pas vivre sous /en/servicios/ mais sous sa forme anglaise. Le slug fait partie du contenu : les utilisateurs (et les machines) lisent l'URL. Cela oblige à tenir une carte d'équivalences entre langues — un petit coût d'ordre payé une fois.

3. hreflang réciproque et avec x-default. C'est la partie que le plus de sites ratent, et la plus mécanique : chaque page liste toutes ses versions linguistiques, y compris elle-même, plus une version par défaut (x-default) pour les utilisateurs qui ne rentrent dans aucune. La règle d'or est la réciprocité : si la page espagnole affirme qu'une version italienne existe, l'italienne doit affirmer que l'espagnole existe. Un hreflang à moitié fait confond plus qu'aucun. Et le sitemap doit raconter la même histoire : chaque URL avec son groupe complet d'alternatives.

4. Traduction avec révision humaine, en priorisant les pages d'argent. La traduction automatique moderne est une première passe excellente et bon marché. La publier sans révision sur les pages où l'argent se joue — tarifs, politiques d'annulation, conditions — est autre chose : une nuance mal traduite est une réclamation qui attend sa date. Mon ordre de révision : conditions et réservation d'abord, pages de vente ensuite, contenu éditorial à la fin.

Ce que l'approche sans plugins m'a épargné

En servant du HTML statique généré par mon propre script, les quatre règles ci-dessus ne dépendent pas du bon vouloir d'un plugin : elles vivent dans le code qui génère chaque page, toujours pareil, dans les cinq langues à la fois. Ajouter la cinquième langue (l'italien) a consisté à traduire les contenus et à régénérer ; le hreflang, le sitemap et les URL sont sortis tout seuls. Le coût de maintenance mensuel est nul ; le domaine et le serveur se paient à part, une fois par an. Et maintenir cinq langues coûte exactement la même chose qu'en maintenir une. Il y a en plus un effet collatéral qui n'était pas au programme : servir du HTML statique est justement ce que lisent le mieux les robots d'IA, qui n'exécutent pas JavaScript — je le passe en revue point par point dans la checklist en 7 points.

Je ne prétends pas que tout le monde doive abandonner WordPress — ce serait un mauvais conseil. Je défends le critère : quel que soit votre outil, exigez qu'il remplisse les quatre décisions ci-dessus, et vérifiez-le vous-même (les balises hreflang se voient dans le code source de n'importe quelle page ; regarder est gratuit).

L'erreur de fond

Reste l'erreur stratégique, qui n'est pas technique : ajouter des langues qu'on ne peut pas maintenir. Chaque langue est une promesse — que les tarifs seront à jour, que la politique d'annulation dira la même chose qu'en espagnol, que quelqu'un pourra traiter la demande qui arrivera dans cette langue. Une version allemande abandonnée avec des prix d'il y a deux saisons est pire que rien : elle génère des réservations erronées et des réclamations fondées.

La bonne question avant d'ajouter une langue n'est pas « m'apportera-t-elle du trafic ? » mais « puis-je tenir la promesse ? ». Dans mon cas, cinq langues sont tenables parce que le système régénère tout d'un coup et que le contenu change peu. Pour un hôtel aux tarifs et offres hebdomadaires, deux langues bien tenues valent plus que cinq à moitié. En multilingue, comme dans presque tout le numérique, l'ambition se mesure en années de maintenance, pas en drapeaux dans le menu.