Reprendre la maintenance d’un site WordPress multilingue construit par une autre équipe est un exercice révélateur. Sur les projets utilisant WPML avec des types de contenu personnalisés, quatre erreurs de configuration reviennent avec une régularité frappante, indépendamment de l’agence d’origine ou de l’ancienneté du site. Cet article documente ces pièges tels que nous les rencontrons en audit, avec la correction associée pour chacun.
Nous ne parlons pas ici de bugs de l’extension elle-même — WPML est un produit mature et globalement fiable — mais d’erreurs de configuration humaines, souvent commises par manque de temps ou de connaissance des réglages avancés du module de traduction de contenu.
Erreur n°1 : un CPT laissé en mode « non traduisible »
Dans WPML → Réglages → Types de contenus personnalisés, chaque CPT détecté doit être classé dans l’une de trois catégories : traduisible, affiché mais non traduisible, ou uniquement dans la langue par défaut. Le réglage par défaut appliqué à un nouveau CPT n’est pas toujours celui qu’on imagine, et il arrive fréquemment qu’un développeur ajoute un CPT en cours de projet sans revenir vérifier ce réglage.
Conséquence concrète : le contenu du CPT reste visible uniquement dans la langue d’origine, sans qu’aucune erreur ne s’affiche. Le client ne s’en aperçoit souvent que des mois plus tard, en constatant que la version anglaise de son catalogue de « Témoignages clients » est vide, alors que la version française en contient une trentaine.
Erreur n°2 : des relations ACF cassées après traduction
Advanced Custom Fields est omniprésent dans les projets WordPress professionnels, et les champs de type relation ou post object posent un problème spécifique en contexte multilingue : par défaut, un champ de relation créé sur la version française d’un post continue de pointer vers l’ID du post français, même lorsque celui-ci est affiché sur la version anglaise du site.
WPML propose un module de compatibilité pour ACF (WPML for ACF) qui doit être activé explicitement et configuré champ par champ dans WPML → Réglages avancés → Champs personnalisés. Sans cette configuration, un champ de relation « Produits associés » affichera, sur la page anglaise d’un article, des liens vers des produits en français — un défaut qui n’apparaît qu’à l’usage, jamais lors d’un simple test de traduction du texte principal.
<?php
// Vérifier qu'un champ ACF de relation est bien traduit
// Sans configuration WPML, ce code retourne l'ID du post d'origine
$produits_associes = get_field( 'produits_associes' );
// Avec le module WPML for ACF correctement configuré en mode
// "Copier" ou "Traduire", l'ID retourné correspond à la traduction
// dans la langue courante, pas à l'ID brut enregistré en base.
Erreur n°3 : des taxonomies non synchronisées entre langues
Comme pour Polylang, WPML propose un mode de synchronisation des taxonomies personnalisées, accessible depuis WPML → Réglages → Types de contenus personnalisés, section taxonomies. Un réglage mal choisi ici entraîne des situations où un même article se retrouve classé dans une catégorie en français, mais dans une catégorie complètement différente (ou aucune) une fois affiché en anglais, parce que les termes de taxonomie n’ont jamais été correctement liés entre les deux langues.
La vérification recommandée avant toute mise en production : ouvrir un article dans chaque langue et comparer manuellement ses taxonomies assignées. Un tableau de bord de vérification improvisé, même une simple feuille de calcul listant CPT par CPT le nombre de contenus traduits et le nombre de termes de taxonomie associés dans chaque langue, permet de repérer rapidement les écarts anormaux.
Erreur n°4 : des slugs de CPT ou de taxonomie non traduits
WPML permet de traduire les slugs des URL (l’identifiant textuel dans l’adresse, par exemple realisations devenant projects en anglais) via WPML → Réglages → Slugs des types de contenus personnalisés. Ce réglage est souvent ignoré, ce qui laisse des URL anglaises contenant des mots français : exemple.fr/en/realisations/mon-projet/ au lieu de exemple.fr/en/projects/my-project/.
Ce n’est pas qu’un problème esthétique : un slug non traduit nuit à la pertinence perçue de la page par les moteurs de recherche anglophones, qui accordent un poids réel aux mots-clés présents dans l’URL. C’est un détail facile à corriger en configuration, mais qui doit être anticipé avant la mise en ligne, car changer un slug après indexation impose des redirections supplémentaires.
Une checklist avant mise en production
- Vérifier le statut de traduisibilité de chaque CPT dans les réglages WPML.
- Activer et configurer WPML for ACF si des champs de relation ou de type post object sont utilisés.
- Contrôler la synchronisation de chaque taxonomie personnalisée, terme par terme si le volume le permet.
- Traduire les slugs de CPT et de taxonomie avant toute indexation par les moteurs de recherche.
- Republier au moins un contenu de test dans chaque langue et comparer manuellement le rendu final.
Sur nos projets, nous imposons désormais une règle simple : aucun CPT n’entre en développement sans qu’une ligne dédiée dans le cahier de recette ne précise explicitement son statut de traduisibilité et le comportement attendu pour chaque champ ACF associé.
En résumé
La grande majorité des problèmes multilingues rencontrés sur des sites WPML avec des types de contenu personnalisés ne viennent pas de l’extension elle-même, mais d’oublis de configuration lors du développement initial. Traiter la traduisibilité comme une spécification à part entière, au même titre qu’un champ obligatoire ou une règle de validation, évite la grande majorité des correctifs coûteux constatés après mise en production.
