# Sites multilingues : les antipatterns que nous corrigeons le plus souvent en audit > Certaines mauvaises pratiques multilingues reviennent sur presque tous les sites que nous auditons. Voici les plus coûteuses, avec leur correctif. - Auteur : Clément Hadrot - Publié le : 2024-08-22 - Mis à jour le : 2024-08-22 - Catégorie : Multilingue - URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/antipatterns-sites-multilingues/ ## L’essentiel - La traduction automatique publiée sans relecture reste l'erreur la plus fréquente - Un contenu partiellement traduit nuit plus qu'un contenu monolingue assumé - Changer de plugin multilingue sans plan de migration casse les URL indexées Après plusieurs années d'audits de sites WordPress multilingues pour des clients qui nous sollicitent après un premier prestataire, une liste d'erreurs récurrentes se dessine clairement. Ces antipatterns ne sont pas des bugs techniques rares : ce sont des choix de conception ou d'organisation qui reviennent, indépendamment de l'extension multilingue utilisée. Cet article détaille les six plus fréquents, ce qu'on observe concrètement, pourquoi c'est un problème, et quoi faire à la place. ## 1. La langue « fantôme » activée mais jamais alimentée Ce qu'on voit : une langue est activée dans les réglages du plugin multilingue « pour plus tard », avec un sélecteur de langue visible sur le site, mais aucun contenu réel n'a été traduit. Le visiteur qui clique dessus tombe sur une page d'accueil traduite entourée de pages entièrement vides ou encore en français. Pourquoi c'est un problème : cela dégrade la confiance du visiteur international bien plus qu'une absence pure et simple de cette langue, et cela nuit au référencement en exposant des pages quasi vides ou dupliquées aux moteurs de recherche. Quoi faire : n'activer une langue publiquement qu'une fois un socle minimal de contenu réellement traduit (au minimum les pages principales et la navigation), ou masquer le sélecteur tant que ce socle n'est pas atteint. ## 2. La traduction automatique publiée sans aucune relecture Ce qu'on voit : un plugin de traduction automatique est activé, le contenu entier bascule instantanément dans une nouvelle langue, et personne ne relit avant mise en ligne. Les erreurs les plus visibles concernent les noms propres traduits littéralement (une marque déposée transformée en texte commun) ou des expressions idiomatiques rendues absurdes mot à mot. Pourquoi c'est un problème : au-delà de l'image dégradée, ce type d'erreur touche parfois des informations factuelles importantes — un tarif, une condition contractuelle mal rendue. Quoi faire : traiter systématiquement la traduction automatique comme une étape intermédiaire, jamais comme une livraison finale, avec un statut explicite de relecture dans le workflow éditorial. > L'essentiel à retenir : La traduction automatique publiée sans relecture reste l'erreur la plus fréquente ; Un contenu partiellement traduit nuit plus qu'un contenu monolingue assumé ; Changer de plugin multilingue sans plan de migration casse les URL indexées ## 3. Des URL de langue incohérentes après un changement de structure Ce qu'on voit : un site change de structure d'URL (passage d'un sous-dossier à un sous-domaine, ou changement de préfixe de langue) sans plan de redirection, laissant des centaines d'URL indexées renvoyer une erreur 404. Pourquoi c'est un problème : chaque URL cassée est une page qui perd son historique de référencement, parfois accumulé sur plusieurs années, sans aucune compensation automatique. Quoi faire : tout changement de structure d'URL multilingue doit s'accompagner d'un plan de redirections 301 complet, généré à partir d'un export exhaustif des anciennes URL avant bascule, jamais improvisé après coup une fois les premières pertes de trafic constatées. ## 4. Le changement de plugin multilingue sans migration planifiée Ce qu'on voit : un client change de plugin multilingue (par exemple de WPML vers Polylang, ou l'inverse) en désactivant simplement l'ancien et en activant le nouveau, en espérant que les traductions existantes soient reprises automatiquement. Pourquoi c'est un problème : les deux extensions utilisent des structures de données incompatibles (tables et métadonnées différentes pour lier les traductions entre elles). Sans migration explicite, les liens entre langues sont tout simplement perdus, et chaque contenu traduit redevient une page isolée sans lien connu vers ses équivalents linguistiques. Quoi faire : ce sujet mérite un article à lui seul (voir notre retour d'expérience dédié à la migration entre plugins multilingues) ; en résumé, il faut toujours passer par un export structuré des relations de traduction existantes avant toute désactivation de l'ancien plugin. ## 5. Un contenu partiellement traduit présenté comme complet Ce qu'on voit : une page « À propos » traduite, mais dont un paragraphe entier reste en langue source, copié-collé par erreur ou par manque de temps lors de la traduction initiale. Pourquoi c'est un problème : un mélange de langues au sein d'une même page est perçu comme un défaut de sérieux plus marqué qu'une page entièrement non traduite, car il suggère un travail bâclé plutôt qu'un simple choix de ne pas encore couvrir cette langue. Quoi faire : un contrôle qualité systématique après chaque traduction, éventuellement automatisé par un script qui détecte la présence de mots caractéristiques d'une autre langue au sein d'un contenu censé être entièrement traduit. ## 6. L'absence totale de suivi de l'avancement des traductions Ce qu'on voit : aucun tableau de bord, aucune liste, aucun suivi de ce qui reste à traduire sur le site. La traduction avance de façon ad hoc, au gré des demandes, sans vision d'ensemble. Pourquoi c'est un problème : sans suivi, il est impossible de savoir si le site est réellement « complet » dans chaque langue, ce qui rend le premier antipattern (la langue fantôme) presque inévitable à mesure que le site grandit. Quoi faire : WPML propose un tableau de bord de traduction natif listant l'avancement par contenu et par langue ; sur Polylang, un tableau équivalent peut être reconstitué via une requête WP-CLI personnalisée comparant le nombre de contenus publiés par langue : ``` wp post list --post_type=post --lang=fr --format=count wp post list --post_type=post --lang=en --format=count ``` > Sur nos audits, ces six antipatterns représentent à eux seuls la grande majorité des tickets de support liés au multilingue que nous traitons. Aucun n'exige de compétence technique avancée pour être corrigé : ce sont des questions de processus et de discipline éditoriale, pas de limitations des extensions elles-mêmes. ## En résumé Les problèmes les plus coûteux d'un site multilingue ne viennent presque jamais d'une limitation technique de WPML, Polylang ou TranslatePress, mais d'un manque de processus autour de leur utilisation : langues activées sans contenu réel, traductions publiées sans relecture, migrations improvisées, ou absence totale de suivi de l'avancement. Traiter le multilingue comme un processus éditorial continu, pas seulement comme une configuration technique ponctuelle, évite la quasi-totalité de ces antipatterns.