Un client gérant un site vitrine pour une chaîne d’hôtels indépendants en zone frontalière nous a demandé de choisir une solution multilingue capable de gérer six langues, avec des équipes éditoriales locales dans chaque pays qui souhaitaient un contrôle fin sur les traductions plutôt qu’une traduction purement automatique. Ce choix nous a poussés à comparer en profondeur les trois extensions multilingues les plus utilisées en 2025, avec un regard de développeur sur leur fonctionnement interne, pas seulement sur leur interface.
Trois modèles de stockage radicalement différents
WPML et Polylang partagent une philosophie proche : chaque traduction est un article WordPress distinct, lié à l’original par une table de correspondance. WPML stocke ces relations dans ses propres tables (icl_translations notamment), tandis que Polylang s’appuie sur la taxonomie native pour relier les articles entre eux, une astuce élégante qui évite de créer de nouvelles tables mais charge la taxonomie WordPress d’un rôle qui n’est pas le sien à l’origine.
TranslatePress fonctionne selon un principe très différent : il n’existe qu’un seul article en base, dans la langue d’origine. Les traductions sont stockées séparément (par défaut dans des tables dédiées, avec une option de stockage automatique via un moteur de traduction), et injectées à la volée au moment du rendu, en remplaçant les chaînes détectées dans le HTML final. C’est une architecture radicalement plus simple côté structure de contenu, mais qui déplace la complexité vers le rendu.
Implications pour un développeur qui étend le site
Avec WPML et Polylang, une extension personnalisée qui crée du contenu par programmation (un CPT, un article généré par import) doit explicitement gérer la duplication ou l’association entre langues, sous peine de voir son contenu n’exister que dans la langue par défaut. Polylang expose une fonction claire à cet effet :
// Associer un article existant à sa traduction dans une autre langue (Polylang)
pll_set_post_language( $id_article_fr, 'fr' );
pll_set_post_language( $id_article_en, 'en' );
pll_save_post_translations( array(
'fr' => $id_article_fr,
'en' => $id_article_en,
) );
WPML propose une API équivalente via sa classe SitePress et ses fonctions d’aide, plus riche mais aussi plus complexe à prendre en main pour un premier développement d’intégration. TranslatePress, à l’inverse, ne demande aucune gestion explicite côté création de contenu : un article créé par programmation existe automatiquement dans toutes les langues, puisqu’il n’existe qu’une seule version stockée. La contrepartie apparaît dès qu’on veut cibler du texte précis pour une traduction manuelle fine : cela passe par son éditeur visuel de traduction en façade, moins adapté à une automatisation par code que les API dédiées de WPML ou Polylang.
Compatibilité avec les blocs et l’éditeur de site
| Critère | WPML | Polylang | TranslatePress |
|---|---|---|---|
| Traduction des templates FSE | Prise en charge avancée, avec synchronisation de structure | Correcte, contrôle manuel plus fréquent | Traduction du rendu final, transparente mais moins fine sur la structure |
| Traduction de contenu de bloc dynamique | Bonne prise en charge native | Bonne prise en charge native | Dépend de la détection du texte au rendu |
| API pour développeur tiers | Très riche, documentation dense | Plus légère, bien documentée | Plus restreinte, orientée configuration |
| Poids en base pour un gros volume | Notable, tables dédiées nombreuses | Modéré, s’appuie sur la taxonomie | Faible côté contenu, dépend du volume de chaînes traduites |
Performance sur un site à fort volume
Sur le site hôtelier, avec environ 400 pages par langue une fois la duplication effectuée, WPML et Polylang affichent un coût de requête supplémentaire lié à la résolution de la langue courante sur chaque affichage, généralement bien absorbé par un cache de page correctement configuré. TranslatePress, en traduisant à la volée le HTML généré, ajoute un traitement de substitution de texte sur chaque rendu non mis en cache, ce qui rend un cache de page complet d’autant plus indispensable pour ce dernier — sans cache, le coût de traitement par requête est le plus sensible des trois solutions testées.
Le cas des équipes éditoriales locales
Le critère décisif pour ce client a été le contrôle éditorial : les équipes locales voulaient pouvoir réviser et modifier chaque traduction comme un contenu à part entière, avec son propre statut de publication et son propre flux de relecture. C’est un point où WPML et Polylang, avec leur modèle d’articles distincts par langue, offrent un contrôle plus naturel qu’une traduction injectée au rendu, plus adaptée à des sites qui privilégient la rapidité de mise en ligne sur le contrôle fin.
Notre repère simple pour trancher : si chaque langue a besoin d’un contenu qui peut diverger structurellement (pas seulement traduit mais réellement adapté), WPML ou Polylang s’imposent. Si l’objectif est de rendre un site existant accessible dans d’autres langues sans réorganiser le contenu, TranslatePress fait le travail plus vite.
Notre verdict
Polylang reste notre choix par défaut pour un projet où le budget compte et où l’architecture de contenu par langue distincte convient, grâce à sa légèreté et son API claire. WPML se justifie sur des projets à fort enjeu multilingue avec des besoins avancés (e-commerce multidevises, workflows de traduction professionnelle intégrés), au prix d’une licence et d’une complexité plus élevées. TranslatePress reste une option pertinente pour rendre rapidement un site existant multilingue sans réorganiser son contenu, en particulier sur des sites de taille modeste où sa simplicité de mise en œuvre l’emporte sur son besoin accru de cache. Sur le site hôtelier, avec ses équipes éditoriales locales exigeantes, Polylang a été retenu pour son équilibre entre contrôle et légèreté.
