La plupart des projets WordPress multilingues démarrent de la même façon : quelqu’un choisit WPML ou Polylang en se basant sur un article de blog qu’il a lu, le configure en une après-midi, le met en production, et six mois plus tard le site souffre de problèmes de performances, le workflow éditorial est un désordre, ou il existe un manque dans les traductions que personne ne sait expliquer.
Ce site fonctionne en quatre langues (EN/PT/ES/FR) avec une approche personnalisée, car aucun des plugins ne correspondait exactement à mes besoins. Cette décision n’était pas dogmatique — c’était la troisième option après avoir sérieusement envisagé les deux autres. Voici le cadre de décision que j’utilise réellement, basé sur des projets concrets.
Les trois vraies options
Oubliez un instant les pages marketing de chaque plugin. Sur le plan architectural, vous disposez de trois choix sérieux :
- WPML — premium, complet, lourd. Chaque traduction est un article distinct lié à l’original.
- Polylang — cœur gratuit / Pro payant, plus léger, même modèle d’articles séparés.
- Personnalisé — tout ce qui va d’un tableau i18n sérialisé dans le thème à une stratégie de méta de publication personnalisée, en passant par un sélecteur de langue basé sur une variable de requête.
Le multisite WordPress en multi-domaine ou sous-domaine est techniquement une quatrième option, mais c’est une tout autre affaire — vous faites tourner plusieurs installations WordPress. Je ne vais pas l’aborder ici ; si vous êtes à cette échelle, vous ne vous demandez pas « WPML ou Polylang », vous vous demandez « est-ce que je divise cela en sites séparés ».
WPML — quand il justifie son poids
WPML est la réponse par défaut des agences, car il couvre le plus large éventail de cas prêts à l’emploi : articles, pages, types de publications personnalisés, taxonomies, champs ACF, chaînes WooCommerce, chaînes de thème via le module String Translation, menus, widgets, bibliothèque de médias — tout est traduisible.
Où il fonctionne bien
- Les sites à forte charge éditoriale avec une équipe de traduction qui a besoin d’un tableau de bord de traduction, d’une intégration de traduction automatique et d’un workflow clair pour savoir « ce qui est nouveau dans la source, ce qui doit encore être traduit »
- Les boutiques WooCommerce vendant en plusieurs langues avec des noms de produits, descriptions, attributs et prix localisés dans différentes devises
- Les sites construits sur des plugins lourds (Elementor, Divi, configurations ACF complexes) — WPML dispose d’intégrations pour presque tout
Où il montre ses limites
- Performance. WPML ajoute environ 30 à 60 requêtes de base de données supplémentaires lors d’un chargement de page typique. Sur une page d’accueil qui exécute déjà 150+ requêtes en raison de la surcharge des plugins, WPML dépasse les 200. Cacheable, mais dès que vous avez des utilisateurs connectés ou un contenu basé sur des sessions, vous le ressentez.
- Taille de la base de données. Chaque traduction est une ligne dans
wp_posts, chaque méta traduite est une ligne danswp_postmeta. Un site en 4 langues avec 500 articles devient un site de 2 000 articles au niveau de la base de données. - Conflits avec les plugins récents. L’approche « Custom XML config » de WPML pour lui indiquer quelles chaînes traduire fonctionne, mais elle vieillit — chaque mise à jour de plugin peut nécessiter des ajustements de configuration.
Coût : 99 €/an pour Multilingual CMS, 199 €/an pour Multilingual Agency. Intéressant pour un site éditorial suffisamment complexe ; excessif pour une plaquette de 4 pages.
Polylang — plus léger, même principe
Polylang utilise le même modèle conceptuel que WPML — un article par langue, liés entre eux — mais l’implémentation est plus légère et la version gratuite est véritablement utilisable pour les sites sans WooCommerce.
Quand il convient
- Les thèmes personnalisés avec des types de contenus personnalisés où vous avez un contrôle total sur ce qui est traduit et n’avez pas besoin de la couverture exhaustive que propose WPML
- Les sites dont l’équipe éditoriale est réduite et peut se passer d’un tableau de bord de traduction dédié
- Les projets sensibles au budget pour lesquels 99 €/an pour WPML ne convient pas ; Polylang gratuit + Polylang Pro (99 € en paiement unique) est comparable
Quand il atteint ses limites
- WooCommerce. Polylang pour WooCommerce fonctionne mais est moins abouti que WooCommerce Multilingual de WPML. Si votre boutique est le moteur principal, cela a son importance.
- Les chaînes du thème. La traduction de chaînes de Polylang Pro est plus manuelle que celle de WPML. Vous devrez soit livrer votre thème avec des fichiers .mo complets via
load_theme_textdomain, soit vous appuyer sur l’interface plus lente de Polylang. - Les constructeurs de pages visuels. Les intégrations existent mais se cassent plus souvent que celles de WPML.
Personnalisé — quand aucun des deux ne convient
La voie personnalisée n’est pas une approche unique — c’est une catégorie d’approches. Les deux que je rencontre le plus souvent :
Approche A : tableaux i18n dans le thème
Pour les sites dont le contenu est très structuré et éditorialement stable — pages d’atterrissage, sites marketing avec un ensemble fixe de sections — définissez chaque chaîne traduisible comme une clé dans un tableau PHP par langue, accessible via un helper de style t(). L’URL prend un paramètre de requête ?lang=xx (ou un préfixe de chemin), et la langue active est déterminée une fois par requête.
Points forts : aucun impact sur les performances, pas de requêtes de base de données supplémentaires, traductions versionnées, déployées comme du code. Les rédacteurs traduisent en modifiant le tableau (ou via une interface d’administration personnalisée qui y écrit).
Points faibles : ne convient pas à un blog avec des articles fréquemment ajoutés, ni à un catalogue WooCommerce de 500 produits. Dès que les rédacteurs s’attendent à ce que l’administration WP soit la source de vérité pour les traductions, cette approche commence à sembler inadaptée.
Approche B : stratégie par métadonnées de publication
Chaque publication dispose d’un ensemble de champs méta par langue : title_pt, title_en, etc. Un petit filtre sélectionne le bon champ au moment du rendu en fonction de la locale active. Une seule publication, plusieurs traductions, une seule ligne dans wp_posts.
Points forts : deux fois moins de lignes en base de données par rapport à WPML/Polylang. Administration plus rapide (pas de jonglage entre les traductions de publications). Permaliens plus propres si vous utilisez des paramètres de requête ou une réécriture personnalisée.
Points faibles : le référencement nécessite une génération manuelle des balises hreflang (ce que vous feriez de toute façon sur un site sérieux). L’interface éditoriale requiert un développement personnalisé — par défaut, l’éditeur WP n’affiche qu’un seul jeu de champs, pas quatre. ACF ou des métaboxes personnalisées résolvent ce problème, mais ajoutent de la complexité.
Le cadre de décision
Mettez de côté les comparaisons de fonctionnalités et posez-vous quatre questions :
1. Qui effectue les traductions ?
Agence externe / service de traduction attendant un flux de travail familier → WPML. Équipe bilingue en interne → Polylang ou solution personnalisée. Vous seul → une solution personnalisée convient parfaitement.
2. Quel est le degré de structuration du contenu ?
Articles de blog et pages fréquemment modifiés avec de nombreuses variations → WPML ou Polylang. Site marketing très structuré avec des sections stables → une i18n personnalisée est plus rapide et plus légère.
3. Y a-t-il WooCommerce ?
Boutique multilingue avec plusieurs devises → WPML. Boutique multilingue avec une seule devise → Polylang pour WooCommerce est envisageable. Pas de boutique → l’un ou l’autre plugin, ou une solution personnalisée.
4. Quel est l’objectif de performance ?
LCP inférieur à 1,5 s au 75e percentile sur mobile → la solution personnalisée est la seule qui l’atteigne régulièrement sans cache edge agressif. WPML ou Polylang avec mise en cache de page complète en edge → 2 à 3 s à la première requête, moins d’1 s en cache.
Considérations SEO pour les trois approches
Le plugin ne vous dispense pas de bien configurer les balises hreflang. Chaque page traduite nécessite des balises hreflang réciproques pointant vers ses pages sœurs, ainsi qu’une balise x-default pour le repli linguistiquement neutre. WPML et Polylang les génèrent automatiquement, mais j’ai vu les deux produire des résultats subtilement incorrects (une langue manquante, un code de région erroné, des paramètres de requête dupliqués).
Vérifiez dans le HTML rendu, pas dans les paramètres du plugin. Utilisez le rapport « Ciblage international » de Google Search Console pour détecter les erreurs de groupe au fil du temps.
Les canoniques méritent la même attention : chaque page traduite doit être auto-canonique (elle est l’URL canonique pour cette version linguistique), et non pointer vers la version dans la langue d’origine. WPML et Polylang gèrent cela correctement par défaut ; les approches personnalisées nécessitent un travail explicite.
Ce que je fais concrètement
Sur les projets d’agence, le choix par défaut est WPML — les attentes en matière de flux de travail des clients d’agence et des services de traduction correspondent à la façon dont il se présente.
Sur les plateformes d’entreprise à architecture personnalisée, Polylang ou une solution sur mesure — selon que l’équipe éditoriale a besoin d’une interface de traduction par article.
Sur les sites marketing au contenu très structuré (comme celui-ci), une i18n personnalisée via un tableau PHP, servie via ?lang=xx. Zéro requête en base de données pour les traductions, versionnée, déployée comme du code. Contrepartie : la modification nécessite de toucher un fichier, pas l’administration WP.
Aucun de ces choix n’est définitif. Les chemins de migration entre eux sont bien balisés : WPML → Polylang est simple, Polylang → solution personnalisée est mécanique, et solution personnalisée → l’un ou l’autre plugin est la plus facile de toutes.
Ce que vous ne voulez pas, c’est la migration hors d’une configuration qui était incorrecte dès le départ parce que personne n’a posé les quatre questions ci-dessus.
