En 2021, j'intégrais un client e-commerce allemand chez Seahawk. Sept langues, WooCommerce, Elementor, et une deadline déjà en retard. J'ai installé WPML, comme on le fait, j'ai configuré le sélecteur de langue, j'ai lancé la première synchronisation de traduction, et j'ai regardé le Time to First Byte grimper à 2,8 secondes sur un hébergement géré à 40 £/mois. Le client n'était pas ravi. Honnêtement, moi non plus.
C'est à ce moment-là que j'ai vraiment commencé à tester d'autres options au lieu de supposer que WPML était la solution. Quatre ans et quelques centaines de projets multilingues plus tard, j'ai des opinions. Des opinions bien arrêtées.
---
Pourquoi les gens regardent au-delà de WPML en 2026
WPML n'est pas mauvais. Je le dis clairement. Pour les sites éditoriaux complexes avec une équipe de contenu gérant les traductions dans un flux de travail, c'est toujours réellement capable. Mais il y a trois choses qui poussent constamment les clients (et moi) vers des alternatives.
La hausse des prix. Le plan Multilingual CMS, celui dont vous avez réellement besoin pour WooCommerce ou les types de contenu personnalisés, coûte maintenant 99 $/an. C'est par site. Les agences qui font du white-label pour les PME ne peuvent pas toujours répercuter ce coût sans avoir une conversation qu'elles préféreraient éviter.
La surcharge de performance. WPML ajoute un nombre non négligeable de requêtes de base de données par chargement de page. Sur un grand site avec des milliers de posts, cela s'accumule. J'ai vu ça ajouter 400-600ms au TTFB sur des sites qui n'avaient pas été spécifiquement accordés pour ça. Les recommandations de Google concernant les Core Web Vitals rendent ce genre de ralentissement de plus en plus coûteux à ignorer.
La complexité pour des besoins simples. Si un client a besoin de trois langues et vingt pages, la surface de configuration de WPML est intimidante. Vous naviguez entre String Translation, Translation Management, la configuration de WooCommerce Multilingual... c'est beaucoup. Parfois vous avez juste besoin de quelque chose qui fonctionne en un après-midi.
---
Polylang : La Bête de Somme que la Plupart des Agences Oublient
J'ai utilisé Polylang sur probablement plus de 200 sites jusqu'à présent. La version gratuite gère la traduction basique des posts/pages/taxonomies sans vous facturer un centime. La version Pro (£99/an pour des sites illimités, d'après mes dernières informations) est là où ça devient véritablement compétitif, parce que cette licence « sites illimités » est une proposition complètement différente pour les agences comparé au modèle par site de WPML.
Ce que Polylang Fait Bien
L'interface est claire. L'attribution de langue se fait directement dans la barre latérale de l'éditeur de posts, ça ne prend pas le contrôle de votre tableau de bord, et l'impact sur la performance est notablement plus léger que WPML, lors d'un test comparatif que j'ai lancé en mars 2025 sur un site de staging avec 500 posts, WPML contre Polylang Pro, Polylang a réduit d'environ 180ms le TTFB. Pas énorme, mais réel.
Ça s'intègre bien avec Elementor, Bricks, ACF et WooCommerce (via l'extension WooCommerce, qui coûte extra). Cette dernière partie est le hic : le support de WooCommerce nécessite l'extension, et une fois que vous l'ajoutez, la différence de coût avec WPML se réduit un peu.
Où Polylang faiblit, c'est la traduction automatique. Il n'y a pas d'intégration DeepL ou Google Translate intégrée dans le cœur. Vous avez besoin d'un pont tiers comme l'écosystème propre de WPML ou quelque chose comme Linguise, ce qui m'amène à...
---
TranslatePress : La meilleure option pour les projets axés sur la performance
TranslatePress a changé ma façon de penser la traduction multilingue sur WordPress. Au lieu du modèle de duplication de contenu (où vous avez des articles séparés par langue), il utilise un éditeur visuel front-end où vous traduisez le texte directement sur la page rendue. Vous voyez votre site, vous cliquez sur une chaîne, vous tapez la traduction. Terminé.
C'est important pour la performance. Il n'y a pas de duplication de contenu spécifique à chaque langue qui alourdit votre base de données. Les chaînes traduites vivent dans une table personnalisée, pas comme des articles séparés. Sur un projet qu'a exécuté Seahawk pour un client de la vente au détail français-belge fin 2024, nous sommes passés de WPML à TranslatePress en cours de projet (pas idéal, je sais, mais le client a changé le périmètre) et le nombre de requêtes de base de données par page a chuté d'environ 40 %.
L'intégration DeepL
TranslatePress Pro dispose d'une intégration API DeepL intégrée. Pour les clients qui veulent la traduction automatique comme point de départ et l'examen humain après coup, ce flux de travail est bien mieux que tout ce que j'ai pu bricoler manuellement. Vous la réglez sur la traduction automatique à la publication, votre éditeur révise et corrige, et vous avez terminé. Le délai d'exécution pour un site de 50 pages passe de plusieurs jours à un après-midi.
Le prix tourne autour de 89 $/an pour le plan Personnel, 179 $ pour Business (3 sites), 299 $ pour Developer (illimité). Pour les agences, c'est le plan Developer qu'il faut regarder.
Une limitation honnête : les très complexes boutiques WooCommerce avec beaucoup de contenu dynamique peuvent exposer des lacunes dans la détection de chaînes. TranslatePress capture la plupart des choses, mais si vous avez des flux de paiement très personnalisés ou des chaînes générées par des plugins à partir d'extensions obscures, vous pourriez en manquer certaines. Prévoyez quelques heures pour le nettoyage manuel des chaînes.
---
Weglot : Quand le client a un budget et veut zéro friction
Je vais être direct : Weglot est cher. 99 £/an vous donne une paire de langues et jusqu'à 10 000 mots. Un vrai site professionnel dépasse ça presque immédiatement, et la tarification augmente rapidement à partir de là. Pour un site de taille moyenne avec trois langues, vous pourriez payer 300-400 £/an.
Mais voilà. La mise en place prend environ 15 minutes. Vous installez le plugin, collez une clé API, choisissez vos langues, et ça fonctionne. Pas de pièges de configuration, pas de maux de tête de compatibilité avec votre page builder. Il gère le contenu rendu en JavaScript mieux que n'importe quelle autre option de cette liste, ce qui compte si vous utilisez une architecture lourde en React ou Elementor avec beaucoup de widgets dynamiques.
Je recommande Weglot spécifiquement quand : le client est une startup avec un vrai chiffre d'affaires, il a besoin d'aller vite, et le multilingue est vraiment secondaire pour son produit (pas l'élément principal). Pour une landing page SaaS passant de l'anglais à l'allemand et au français, c'est une évidence si le budget n'est pas l'objection.
---
MultilingualPress : Celui pour les configurations WordPress Multisite
Si vous utilisez WordPress Multisite, et en 2026, multisite connaît un léger renouveau pour les clients enterprise et franchise, MultilingualPress est le plugin que vous voulez. Aucune question.
Il crée un site séparé par langue au sein de votre réseau. C'est une approche architecturale fondamentalement différente comparée aux autres de cette liste. Chaque site de langue est indépendant : ses propres enregistrements de base de données, sa propre structure d'URL (vous pouvez faire des sous-domaines ou des domaines séparés), son propre admin. Ils sont connectés par des relations qui vous permettent de lier le contenu équivalent entre les sites.
Seahawk avait un client franchise en 2023 avec 14 sites régionaux, 6 langues, et un siège qui voulait le contrôle central du contenu avec la possibilité d'édition locale. MultilingualPress sur un réseau multisite était véritablement la bonne réponse. Rien d'autre ne s'en approchait. La documentation propre de MultilingualPress est en fait correcte si vous voulez voir comment fonctionnent les relations de contenu.
L'inconvénient est la complexité opérationnelle. Multisite est plus difficile à maintenir, plus difficile à confier à un client non technique, et les plugins qui ne supportent pas multisite (il en existe encore quelques-uns) deviennent votre problème. Allez-y les yeux ouverts.
---
Linguise : Le cheval noir pour les projets Headless et API-Driven
Linguise n'est pas un plugin WordPress au sens traditionnel. C'est une couche de traduction basée sur un proxy qui se situe devant votre site et gère la traduction à la périphérie. Cela la rend particulièrement intéressante pour les configurations WordPress headless où le frontend est construit en Next.js ou Nuxt.
Je l'ai testée sur un projet headless début 2025 où le client avait un CMS basé sur Gutenberg alimentant un frontend Next.js. WPML et TranslatePress n'étaient pas adaptés car la traduction devait se faire dans le résultat rendu, pas dans les champs de contenu WordPress. Linguise l'a géré de façon très efficace.
Ce n'est pas bon marché non plus, les plans commencent autour de 15€/mois, mais pour la bonne architecture, rien d'autre ne résout vraiment le problème de la même façon.
---
Comment vraiment choisir
Voici mon cadre de décision après avoir construit des sites multilingues à travers douze mille projets. Pas un algorithme rigide, mais un ensemble de questions qui le réduisent rapidement.
- Quelle est la stratégie d'URL ? Si le client a besoin de domaines séparés par langue (example.de,
example.fr), MultilingualPress ou WPML les gèrent le plus proprement. TranslatePress et Polylang peuvent le faire mais nécessitent plus de configuration. - WooCommerce est-il impliqué ? Si oui, présélectionnez WPML, Polylang Pro + l'add-on WooCommerce, ou TranslatePress Business. Testez chacun sur la taille spécifique de votre catalogue de produits.
- Le client veut-il une traduction automatique ? TranslatePress avec DeepL ou Weglot sont les plus efficaces. La gestion des traductions de WPML fonctionne aussi mais paraît plus destinée aux grandes entreprises.
- Combien de sites votre agence doit-elle gérer ? La licence illimitée de Polylang Pro offre un excellent rapport qualité-prix pour les agences à grande échelle.
- Le frontend est-il headless ou largement basé sur JavaScript ? Weglot ou Linguise. Ne vous battez pas avec les plugins de duplication de contenu sur un frontend Next.js.
- S'agit-il d'un réseau multisite ? MultilingualPress. C'est tout.
---
Et si on utilisait simplement les fonctionnalités multilingues natives de l'éditeur de blocs ?
WordPress core s'est progressivement orienté vers le support multilingue natif depuis des années. Matt Mullenweg l'a mentionné publiquement plus d'une fois, et il y a eu des discussions sur GitHub concernant Gutenberg qui remontent à 2020. Au début 2026, ce n'est toujours pas disponible sous une forme prête pour la production.
Je ne vous conseille pas d'attendre avant de décider pour un plugin. Construisez avec ce qui existe aujourd'hui. Si le support natif arrive, la migration sera un problème dont vous seriez heureux.
---
FAQ
WPML vaut-il encore le coup en 2026 ?
Pour les grands sites éditoriaux avec des équipes de traduction dédiées, absolument. Le module de gestion des traductions, l'export XLIFF, la compatibilité avec presque tout l'écosystème WordPress, c'est toujours l'option la plus complète. Où ça perd, c'est le prix à grande échelle, la performance sur les grandes bases de données, et la complexité pour les projets simples.
Puis-je passer de WPML à un autre plugin en cours de projet ?
Techniquement oui, pratiquement c'est galère. WPML stocke les métadonnées de langue dans ses propres tables et post meta. La plupart des autres plugins ne les lisent pas nativement. Il existe des outils de migration et des scripts qui traînent sur GitHub, mais attendez-vous à y passer du temps. J'ai fait trois migrations depuis WPML et chacune a demandé du travail SQL personnalisé. Prévoyez une demi-journée minimum sur un site de taille moyenne.
TranslatePress fonctionne-t-il avec Elementor et Bricks ?
Elementor : oui, très bien. Le traducteur front-end de TranslatePress affiche la sortie d'Elementor et capture les chaînes de manière fiable. Bricks est plus récent et la compatibilité s'est améliorée à travers 2024-2025, je ferais un test approfondi sur votre template spécifique avant de valider sur un site en production.
Quel plugin multilingue est le meilleur pour le SEO ?
Tous les principaux (WPML, Polylang, TranslatePress) implémentent correctement les balises hreflang quand ils sont configurés correctement. L'écart n'est pas dans l'implémentation hreflang, c'est dans la vitesse de rendu de chaque page. Le SEO en 2026 est fortement pondéré vers les Core Web Vitals, donc la différence de performance entre une installation WPML surchargée et une configuration TranslatePress épurée peut peser plus lourd que la configuration hreflang.
Quel est le moyen le moins cher de faire du WordPress multilingue ?
Polylang gratuit plus traduction manuelle pour chaque article. Zéro coût. Fonctionne bien pour les petits sites avec des éditeurs patients. À partir du moment où vous avez besoin de WooCommerce, de traduction automatique, ou de plus de 50 articles, vous allez vouloir payer pour quelque chose.
---
L'écosystème WordPress multilingue a vraiment mûri. WPML avait le domaine pour lui seul pendant trop longtemps, et la concurrence a amélioré les choses. Choisissez en fonction de votre architecture, du budget de votre client et de votre volonté de configurer les choses, pas en fonction de ce qui était la réponse par défaut en 2018.