En 2020, un client du secteur de la formation professionnelle nous a confié la refonte de son site vitrine, alors limité à 400 pages en français. Cinq ans plus tard, ce même site compte près de 3 000 pages réparties sur quatre langues — français, anglais, espagnol et allemand — et nous en assurons toujours la maintenance mensuelle. Ce genre de longévité est rare dans notre métier, et elle donne un point de vue qu’aucun audit ponctuel ne peut offrir : celui de voir vieillir en accéléré les choix pris au tout début du projet.
Cet article n’est pas une méthodologie générale de maintenance WPML. Nous avons déjà couvert l’architecture des tables et de la String Translation à plusieurs reprises. Ici, nous racontons ce qui, sur ce projet précis, a bien vieilli et ce qui, au contraire, nous coûte du temps chaque mois — avec les chiffres à l’appui.
Ce qui a bien vieilli : la structure en sous-dossiers
Le choix initial d’une structure en sous-dossiers (/fr/, /en/, /es/, /de/) plutôt qu’en sous-domaines s’est révélé judicieux. Le référencement naturel du domaine principal a profité à toutes les langues sans dilution d’autorité, et la gestion des certificats SSL n’a jamais posé de problème puisqu’un seul domaine est concerné. Sur cinq ans, nous n’avons eu à toucher ni au DNS ni à la configuration serveur pour des raisons liées au multilingue.
Le second choix qui tient toujours est celui d’avoir limité la traduction automatique aux contenus à faible enjeu éditorial dès le départ : pages de mentions légales, fiches produits secondaires. Les pages stratégiques (formations phares, pages de conversion) ont toujours été traduites par des professionnels, et cette hiérarchisation a évité un nivellement par le bas de la qualité perçue par les visiteurs internationaux.
Ce qui coûte cher aujourd’hui : la dérive de la String Translation Table
Le vrai point noir, c’est la table icl_string_translations. Au lancement, elle contenait environ 900 chaînes à traduire (thème, plugins, quelques constructions ACF). Cinq ans et plusieurs mises à jour de thème plus tard, elle en contient plus de 7 200, dont une bonne moitié sont des chaînes orphelines : des libellés issus d’anciennes versions de plugins désinstallés, ou de blocs Gutenberg supprimés depuis longtemps du site mais dont la chaîne est restée enregistrée.
Cette dérive a un coût direct : chaque recherche dans l’interface WPML → Traduction de thèmes et plugins devient plus lente, et surtout, les traducteurs perdent du temps à trier le pertinent de l’obsolète quand on leur confie un nouveau lot. Nous avons fini par écrire un script de nettoyage exécuté deux fois par an, qui croise les chaînes enregistrées avec les plugins et thèmes réellement actifs :
global $wpdb;
$table = $wpdb->prefix . 'icl_strings';
$orphelines = $wpdb->get_results(
"SELECT id, name, context FROM {$table}
WHERE context NOT IN ('WPBakery', 'Twenty Twenty-Three', 'WooCommerce')"
);
foreach ( $orphelines as $ligne ) {
error_log( sprintf( 'Chaîne orpheline : #%d [%s] %s', $ligne->id, $ligne->context, $ligne->name ) );
}Ce script se contente de journaliser, la suppression reste manuelle après vérification — nous avons appris à nos dépens qu’une suppression automatique peut effacer une chaîne encore utilisée dans un contenu généré dynamiquement.
La décision qu’on ne reprendrait plus : les CPT à taxonomies croisées
En 2020, nous avions créé un CPT « Formation » avec trois taxonomies personnalisées croisées (métier, niveau, format) pour permettre un filtrage fin côté front. Cinq ans plus tard, la synchronisation de ces taxonomies via WPML représente à elle seule près de 40 % des tickets de support liés au multilingue. Le problème n’est pas WPML en tant que tel, mais la complexité que nous avons nous-mêmes introduite : chaque nouvelle valeur de taxonomie doit être créée puis liée manuellement dans les quatre langues avant qu’un formateur puisse publier une fiche complète.
Sur un projet destiné à durer plus de deux ans, mieux vaut sacrifier un peu de finesse de filtrage au lancement que de multiplier les taxonomies croisées traduites : la dette se paie à chaque nouvelle langue ajoutée, pas seulement au lancement.
Les incidents qui reviennent
Sur cinq ans, trois types d’incidents reviennent avec une régularité presque comique :
- Une mise à jour de thème qui réinitialise des chaînes déjà traduites, obligeant à relancer une synchronisation complète des chaînes ;
- Un plugin tiers mis à jour qui change légèrement un libellé (une majuscule, un point final en moins), ce qui crée une nouvelle chaîne au lieu de mettre à jour l’existante ;
- Un contributeur qui publie un contenu directement en anglais sans passer par le flux de traduction WPML, cassant la relation entre les versions linguistiques.
Pour ce dernier point, nous avons fini par restreindre les rôles de publication directe aux seuls administrateurs et par former les rédacteurs à toujours partir de la fiche en langue source, jamais de zéro dans une langue cible.
En résumé
Cinq ans de recul sur un même site multilingue de cette taille confirment une intuition que beaucoup d’agences partagent sans toujours la vérifier : les choix d’architecture d’URL vieillissent bien, les choix de granularité de contenu (taxonomies, chaînes) vieillissent mal si on ne prévoit pas leur nettoyage régulier. Le prochain projet de cette envergure intégrera dès le cahier des charges une routine de purge de la String Translation Table, plutôt que de la découvrir comme une dette cinq ans après.
