Un cabinet de conseil en recrutement international nous a confié la reprise de son site, jusque-là suivi par une agence qui a cessé son activité. Avant même de parler de nouvelles fonctionnalités, il a fallu comprendre l’état réel du multilingue existant. Ce que nous avons trouvé est révélateur d’un problème plus large : la plupart des erreurs structurelles ne viennent pas d’un mauvais choix de plugin, mais d’une accumulation de décisions prises au coup par coup, sans vision d’ensemble.
Cet article liste les antipatterns structurels que nous rencontrons systématiquement en reprise de projet, indépendamment de la question de la qualité des traductions elle-même ou des pièges classiques de la traduction automatique, déjà traités par ailleurs.
Antipattern n° 1 : les langues fantômes
Le premier constat, presque toujours le même : des langues activées dans WPML depuis des années, sans plus aucun contenu maintenu. Sur ce projet, six langues étaient techniquement actives (français, anglais, espagnol, allemand, italien, néerlandais), mais seules deux (français, anglais) recevaient encore des mises à jour de contenu. Les quatre autres affichaient des pages figées depuis 2021, avec des informations obsolètes sur les offres du cabinet.
Ces langues fantômes ne sont pas neutres : elles apparaissent dans le sitemap XML, sont indexées par les moteurs de recherche, et génèrent du trafic vers des pages qui donnent une image datée de l’entreprise. Pire, elles consomment du temps de maintenance à chaque mise à jour de plugin, puisque WPML continue de synchroniser leur structure même sans contenu actif.
Antipattern n° 2 : la duplication par copier-coller
Deuxième constat fréquent : sur plusieurs pages stratégiques, la version espagnole n’était pas une traduction liée via WPML, mais une page indépendante créée par copier-coller du contenu français, puis traduite à la main dans l’éditeur, sans jamais établir la relation de traduction entre les deux versions. Concrètement, dans la table icl_translations, ces pages n’apparaissaient dans aucun groupe de traduction (trid différent pour chaque version au lieu d’un trid partagé).
Conséquence directe : le sélecteur de langue affichait un lien cassé ou redirigeait vers l’accueil au lieu de la page équivalente, et toute mise à jour du contenu français devait être répercutée manuellement, sans aucun signal d’alerte dans l’interface de gestion des traductions.
Antipattern n° 3 : le mélange de granularités de traduction
Sur certains contenus, le mode de traduction choisi était « traduire indépendamment », sur d’autres « dupliquer », sans logique apparente. Un CPT « Offre d’emploi » était en mode dupliqué (bonne pratique pour un contenu à durée de vie courte, homogène), tandis qu’un CPT « Étude de cas » du même site était en mode traduction indépendante, mais sans qu’aucune étude de cas récente n’ait jamais été réellement traduite : toutes les versions non françaises affichaient donc le badge « traduction manquante », visible publiquement sur le front dans le thème utilisé.
Antipattern n° 4 : les redirections de langue absentes ou en boucle
Le site utilisait la détection automatique de langue du navigateur, combinée à des redirections 301 codées en dur dans le .htaccess, en plus de la détection native de WPML. Ce doublon créait des boucles de redirection pour les utilisateurs ayant une langue de navigateur non gérée par le site (un visiteur avec un navigateur en polonais, par exemple, se retrouvait bloqué dans une boucle entre la racine du domaine et /en/).
Antipattern n° 5 : l’absence de convention de nommage pour les slugs traduits
Enfin, les slugs traduits ne suivaient aucune convention : certains gardaient le slug français tel quel (/en/nos-offres/), d’autres étaient traduits à moitié (/en/our-offres/), d’autres encore traduits intégralement mais de façon incohérente d’une page à l’autre (usage inconsistant du tiret, de l’article défini). Ce désordre rendait impossible toute analyse SEO fiable par langue, chaque export d’URLs nécessitant un nettoyage manuel préalable.
Ce que nous avons recommandé
- Désactiver proprement les langues fantômes plutôt que de les laisser trainer, avec redirection 410 ou 301 argumentée selon le volume de contenu concerné ;
- Reconstruire les relations de traduction manquantes via un script de rapprochement par slug et par date de création, validé manuellement page par page ;
- Harmoniser le mode de traduction par type de contenu, documenté une bonne fois dans un tableau de référence partagé avec le client ;
- Supprimer les redirections concurrentes et laisser WPML seul gérer la détection de langue ;
- Adopter une convention de slug unique, documentée, appliquée rétroactivement lors de la reprise.
Un audit de site multilingue commence toujours par une cartographie de la structure avant de s’intéresser à la qualité des traductions : corriger un texte mal traduit sur une page qui n’est même pas correctement reliée à sa version source ne sert à rien.
En résumé
Ces cinq antipatterns n’ont rien d’exotique : ils apparaissent, sous une forme ou une autre, dans la majorité des sites multilingues repris sans documentation de la part du prestataire précédent. Le point commun à tous : ce sont des décisions prises isolément, sans que personne ne se pose la question de leur cohérence d’ensemble au moment où elles ont été prises. Un audit structurel systématique avant toute intervention corrective permet d’éviter de corriger des symptômes sans traiter la cause.
