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. The Multilingual CMS plan, the one you actually need for WooCommerce or custom post types, sits at $99/year now. That's per site. Agencies doing white-label work for SMEs can't always pass that on without a conversation they'd rather not have.
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. WPML adds a non-trivial number of database queries per page load. On a large site with thousands of posts, that compounds. I've seen it add 400-600ms to TTFB on sites that weren't tuned specifically around it. Google's Core Web Vitals guidance makes that kind of drag increasingly expensive to ignore.
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. If a client needs three languages and twenty pages, WPML's configuration surface is intimidating. You're clicking through String Translation, Translation Management, WooCommerce Multilingual setup... it's a lot. Sometimes you just need something that works in an afternoon.
---
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 à...WPML's own ecosystem or something like Linguise, which brings me to...
---
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.DeepL API integration built in. For clients who want machine translation as a starting point and human review after, this workflow is miles better than anything I've patched together manually. You set it to auto-translate on publish, your editor reviews and corrects, and you're done. The turnaround on a 50-page site goes from days to an afternoon.
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.MultilingualPress's own documentation is actually decent if you want to see how the content relationships work.
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. If the client needs separate domains per language (
example.de,example.fr), MultilingualPress or WPML handle this most cleanly. TranslatePress and Polylang can do it but need more config. - 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. If yes, shortlist WPML, Polylang Pro + WooCommerce add-on, or TranslatePress Business. Test each on your specific product catalogue size.
- 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. TranslatePress with DeepL or Weglot are the cleanest. WPML's translation management also works but feels more enterprise-y.
- 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. Polylang Pro's unlimited-sites licence is the standout value for agencies at volume.
- 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. Weglot or Linguise. Don't fight with post-duplication plugins on a Next.js frontend.
- S'agit-il d'un réseau multisite ? MultilingualPress. C'est tout. MultilingualPress. That's it.
---
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.Gutenberg GitHub discussions about it going back to 2020. As of early 2026, it still isn't here in any meaningful production-ready form.
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.hreflang tags correctly when configured properly. The gap isn't in hreflang implementation, it's in how fast each renders the page. SEO in 2026 is heavily weighted toward Core Web Vitals, so the performance difference between a bloated WPML install and a lean TranslatePress setup can matter more than the hreflang configuration.
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.