Synthèse vocale pour les sites Polylang : ce qui fonctionne vraiment

La synthèse vocale avec Polylang, ça signifie un fichier audio par article traduit, dans la bonne langue et avec la bonne voix. Polylang stocke chaque traduction comme un article WordPress distinct avec son propre identifiant, ce qui rend la génération audio par article nativement compatible. Les vrais points de friction sont la sélection des voix, les redirections par cookie et la mise en cache des pages, pas l'audio lui-même.

Cet article est le quatrième de notre série sur la synthèse vocale multilingue. Nous avons déjà traité WPML, Weglot et la version GTranslate 3.3.0. Polylang se rapproche le plus de WPML en termes d'architecture, mais il a ses propres particularités. Voici ce que nous avons testé et ce qui fonctionne réellement sur des sites en production avec Synthèse vocale - TTSWP.

Pourquoi Polylang est important pour la synthèse vocale

Polylang fait tourner plus de sites WordPress multilingues que tout autre plugin gratuit. Il compte plus de 800 000 installations actives, ce qui en fait le plugin multilingue gratuit le plus utilisé. La première version est sortie en 2011 et le plugin est toujours activement maintenu. Le nombre de langues ajoutables est illimité, et les packs de langue WordPress se téléchargent automatiquement. La plupart des sites Polylang sont des blogs, des petits éditeurs et des agences soucieuses de leur budget qui l'ont choisi pour sa gratuité et son architecture propre.

Cette popularité est justement le problème pour les plugins de synthèse vocale. Beaucoup prétendent prendre en charge Polylang, mais ne testent que la langue par défaut. Ils attachent un seul fichier audio à un article, puis servent le même fichier sur toutes les traductions. La version espagnole lit de l'audio en anglais. La version allemande reste silencieuse. Les visiteurs quittent le site.

La solution est structurelle. Polylang n'ajoute ni table de base de données supplémentaire ni shortcode. Il s'appuie sur les taxonomies WordPress, la même fonctionnalité qui gère les catégories et les étiquettes. Chaque traduction vit comme un vrai article. La génération audio par article, qui est le fonctionnement de TTSWP, s'aligne donc parfaitement avec la manière dont Polylang stocke le contenu.

En quoi Polylang diffère de Weglot et GTranslate

Polylang duplique les articles. Weglot et GTranslate traduisent au moment du rendu. Cette seule différence conditionne tout ce qui touche à la synthèse vocale.

Sur un site Polylang, la traduction allemande de «À propos» est un article WordPress distinct avec l'identifiant 412, le slug de langue «de» et son propre contenu en base de données. WordPress le voit, l'API REST le voit, et tout plugin de synthèse vocale qui s'accroche à save_post ou wp_insert_post le voit aussi. La génération audio s'exécute une fois par traduction, dans la langue de cette traduction, et le fichier est mis en cache pour cet identifiant d'article.

Weglot et GTranslate fonctionnent différemment. Le texte traduit n'existe que lorsqu'un utilisateur demande la page. Il n'y a pas de second article auquel rattacher l'audio. Nous avons couvert les contournements pour Weglot et GTranslate dans des articles précédents. WPML utilise le même modèle de duplication que Polylang, c'est pourquoi notre guide WPML s'applique ici avec de légères adaptations.

Pour la synthèse vocale, c'est une bonne nouvelle. Polylang vous donne exactement ce dont vous avez besoin : un identifiant d'article stable par langue, un slug de langue connu et un permalien qui ne change pas au moment du rendu.

Les quatre structures d'URL de Polylang et ce qu'elles impliquent pour la synthèse vocale

Polylang propose quatre modes d'URL. Chacun change la façon dont les caches, les CDN et le code de détection de langue voient vos pages. Choisissez le mauvais mode et le bon fichier audio se retrouve derrière la mauvaise URL.

1. Langue déterminée par le contenu uniquement (pas de code langue dans l'URL)

C'est le cas le plus délicat. L'URL example.com/about sert l'anglais à un visiteur et l'allemand à un autre, selon le cookie ou la détection du navigateur. Les caches voient une seule URL et stockent une seule variante. La langue que le cache a capturée en premier l'emporte.

Pour la synthèse vocale, le fichier audio lui-même ne pose pas de problème car il est lié à l'identifiant de l'article, pas à l'URL. Le problème vient de la page qui intègre le lecteur. Si la page anglaise mise en cache charge l'embed audio allemand, le lecteur joue quand même l'allemand, mais les visiteurs attendaient du texte anglais. Nous déconseillons ce mode d'URL sur tout site utilisant la mise en cache.

2. URLs en répertoire (/en/, /de/)

C'est la configuration par défaut et celle que nous recommandons. Chaque langue vit à son propre chemin. Les caches traitent /en/about et /de/about comme des clés distinctes. La bonne page se charge avec le bon lecteur et le bon fichier audio. Aucun cookie nécessaire.

Attention à l'option «Masquer le code de langue pour la langue par défaut». Lorsqu'elle est activée, la langue par défaut perd son préfixe. /about devient anglais et /de/about reste allemand. La détection de langue basée sur l'URL dans du code tiers échoue alors sur les chemins de la langue par défaut, car elle ne voit pas de slug. Si vous utilisez cette option, appuyez-vous sur pll_current_language() plutôt que sur l'analyse de l'URL.

3. Sous-domaine (en.example.com, de.example.com)

Les sous-domaines donnent à chaque langue son propre hôte et son propre espace de cache. Les lecteurs audio se chargent proprement par langue. La contrepartie est la gestion DNS, les certificats SSL par sous-domaine et une analyse légèrement plus complexe. Fonctionne bien à grande échelle.

4. Domaines séparés par langue

Séparation totale. example.com pour l'anglais, example.de pour l'allemand. La synthèse vocale continue à lier l'audio à l'identifiant de l'article dans chaque installation WordPress, et le lecteur fonctionne de la même façon. Ce mode est courant pour les marques qui possèdent déjà des ccTLDs.

Le problème des redirections par cookie

Polylang peut détecter la langue du navigateur d'un visiteur lors de sa première visite sur la page d'accueil. Il pose alors le cookie pll_language et redirige le visiteur vers la version correspondante. Combiné à la mise en cache des pages, c'est là qu'apparaît l'audio dans la mauvaise langue.

Voici la séquence d'échec que nous avons reproduite. Un visiteur francophone arrive sur la page d'accueil. Polylang détecte le français, pose le cookie pll_language et redirige vers /fr/. Le cache stocke cette réponse de redirection sous l'URL de la page d'accueil. Le visiteur suivant, anglophone, demande la page d'accueil et reçoit la redirection mise en cache vers /fr/. Il atterrit sur la page française, entend l'audio français et repart.

Avec les URLs en répertoire, le problème reste limité à la page d'accueil, car toutes les autres pages ont une clé de cache distincte par langue. Avec le mode «langue déterminée par le contenu», le même problème se répand sur toutes les URLs du site.

Trois solutions fonctionnent. La plus simple est de désactiver la détection automatique de la langue du navigateur sur tout site utilisant la mise en cache et de laisser les visiteurs choisir via le sélecteur de langue. La deuxième est de demander à votre plugin de cache de varier ou de contourner le cookie pll_language. La troisième est d'exclure la page d'accueil du cache afin que la redirection de détection s'exécute toujours en direct.

Si vous utilisez WP Rocket, W3 Total Cache ou LiteSpeed, consultez notre documentation sur l'intégration du cache pour la configuration des cookies. Polylang fonctionne avec ces plugins de cache, mais coexister n'est pas la même chose qu'être compatible avec la détection de langue. Vous devez configurer le cache vous-même.

Comportement AJAX en frontend

Polylang détecte automatiquement la langue active lors des requêtes AJAX frontend et charge les chaînes correspondantes. Vous pouvez aussi passer une variable lang explicite dans la requête pour forcer une langue précise. Pour la synthèse vocale, cela compte quand le lecteur audio ou le widget d'articles connexes déclenche un appel AJAX pour récupérer un autre article.

Dans nos tests, Polylang gère cela proprement. Nous n'avons pas observé les régressions AJAX-langue documentées dans l'article WPML. Si une intégration personnalisée doit récupérer un article dans une langue différente de la langue active, passez lang explicitement et vérifiez que function_exists('pll_current_language') avant de lire le résultat.

Configurer Synthèse vocale - TTSWP sur un site Polylang

Ces étapes supposent que Polylang est déjà installé et qu'au moins une traduction existe.

1. Installez Synthèse vocale - TTSWP depuis la page du plugin sur WordPress.org. Activez-le. Consultez la documentation d'installation si vous rencontrez une erreur de permission.
2. Connectez le plugin à TTSWP en suivant le guide de connexion. Le forfait gratuit inclut des crédits de bienvenue pour tester avant de choisir un abonnement payant.
3. Ouvrez l'article dans la langue d'origine et générez l'audio. Vérifiez que le lecteur s'affiche bien en frontend.
4. Passez à la version traduite depuis le sélecteur de langue Polylang dans l'éditeur d'articles. Générez l'audio à nouveau. Polylang a chargé un identifiant d'article différent, donc TTSWP traite cela comme une nouvelle génération et stocke un fichier séparé.
5. Choisissez la voix pour chaque traduction. La sélection de voix se fait au niveau de l'article. Consultez la documentation sur la sélection des voix pour le remplacement par article.
6. Vérifiez en frontend. Ouvrez /en/post-slug et /fr/post-slug dans des onglets différents. Écoutez chacun. Les voix et les langues doivent correspondre.

Pour l'instant, la correspondance de voix par langue dans TTSWP couvre WPML et Weglot en priorité. Sur Polylang, la sélection de voix se fait au niveau de l'article et la valeur par défaut par langue fonctionne via la récupération de la langue de l'article décrite ci-dessous. Pour la plupart des sites Polylang, c'est suffisant, car chaque traduction est un vrai article et la voix est définie une fois par article. Consultez la documentation sur l'intégration Polylang pour le comportement actuel.

Comment récupérer la langue de l'article pour la sélection de voix

La bonne API pour lire la langue d'un article dans Polylang est pll_get_post_language(). Vérifiez toujours que la fonction existe avant de l'appeler, comme le recommande la documentation officielle de Polylang. Le schéma est le suivant :

if ( function_exists( 'pll_get_post_language' ) ) {
    $lang = pll_get_post_language( $post_id, 'slug' );
    // $lang vaut maintenant 'en', 'de', 'fr', etc.
}

En contexte frontend, pll_current_language() retourne la langue de la requête en cours. Ces deux fonctions sont stables et font partie de l'API publique de Polylang depuis des années. La logique de correspondance des voix doit toujours lire la langue de l'article, jamais la langue par défaut du site, sinon les traductions héritent de la mauvaise voix.

Polylang gratuit ou Polylang Pro pour la synthèse vocale

Rien dans Polylang Pro n'est nécessaire pour l'audio. La version gratuite de Polylang donne à TTSWP tout ce dont il a besoin : duplication par article, slugs de langue et les fonctions API publiques ci-dessus.

Polylang Pro ajoute la traduction automatique DeepL, le support de l'API REST, les slugs d'URL traduits et l'export XLIFF pour la traduction externalisée. Aucune de ces fonctionnalités ne change la donne pour la synthèse vocale sur les articles et les pages. Polylang pour WooCommerce est une extension payante séparée qui gère les pages de la boutique, les catégories de produits, les attributs et les e-mails transactionnels. Pour ajouter de la narration aux descriptions de produits, consultez notre guide sur la synthèse vocale pour WooCommerce.

SEO et AEO avec un audio par langue

Polylang gère les balises hreflang automatiquement, ce qui représente l'essentiel du travail SEO pour les sites multilingues. Ajoutez un schéma AudioObject par version de langue, pointez chacun vers le fichier de cette traduction spécifique, et vous envoyez un signal clair aux moteurs de recherche.

Dans nos propres tests, les articles avec audio et schéma AudioObject sont cités plus souvent par les moteurs de recherche IA. Nous avons documenté la méthode et les résultats dans notre article sur l'AEO et l'audio. En résumé : un fichier audio par traduction, un schéma par traduction, et l'avantage AEO suit naturellement.

Problèmes courants et solutions

Accessibilité

Ajouter de la narration par langue est aussi un gain pour l'accessibilité. Les visiteurs qui lisent mieux dans leur langue maternelle mais préfèrent écouter ont désormais les deux options. Si votre site est soumis aux WCAG 2.2 ou à la directive européenne sur l'accessibilité, consultez notre guide de conformité audio WCAG pour les critères applicables. Pour un tour d'horizon complet de l'ajout de la synthèse vocale sur WordPress en 2026, le tutoriel principal couvre les fondamentaux.

Questions fréquentes

Polylang est-il compatible avec la synthèse vocale ?

Oui. Polylang stocke chaque traduction comme un article WordPress distinct avec son propre identifiant, ce qui correspond exactement à l'architecture utilisée par TTSWP pour la génération audio par article. Générez l'audio sur chaque traduction et vous obtenez un fichier par langue avec la voix choisie. La version gratuite de Polylang suffit. Aucune configuration spéciale n'est nécessaire au-delà de l'installation standard de TTSWP.

Ai-je besoin de Polylang Pro pour l'audio ?

Non. La version gratuite de Polylang expose tout ce dont TTSWP a besoin : duplication d'articles par langue, slugs de langue et les fonctions API publiques pll_get_post_language() et pll_current_language(). Polylang Pro ajoute la traduction automatique DeepL, le support de l'API REST et les slugs d'URL traduits. Aucune de ces fonctionnalités ne change le fonctionnement de la génération ou de la lecture audio.

Chaque langue peut-elle avoir sa propre voix ?

Oui. Chaque traduction étant un article distinct, la sélection de voix se fait au niveau de l'article. Choisissez une voix allemande sur la traduction allemande, une voix espagnole sur la traduction espagnole, et ainsi de suite. TTSWP enregistre le choix par article et l'utilise à chaque régénération. Consultez la documentation sur la correspondance langue et voix pour le comportement actuel.

Pourquoi mon audio se lit-il dans la mauvaise langue ?

La cause habituelle est la mise en cache des pages combinée à la détection automatique de langue du navigateur par Polylang. Le cache stocke la redirection de la page d'accueil ou une seule variante de langue et la sert à tout le monde. Le fichier audio lui-même est correct pour l'identifiant de l'article. La page qui le charge, non. Désactivez la détection du navigateur sur les sites avec cache, ou demandez à votre plugin de cache de varier sur le cookie pll_language. Les URLs en répertoire (/en/, /fr/) limitent le problème à la page d'accueil, car toutes les autres pages ont une clé de cache distincte.

En quoi Polylang diffère-t-il de WPML pour la synthèse vocale ?

Les deux dupliquent les articles par langue, donc la génération audio par article fonctionne de la même façon sur les deux. Les différences portent sur la gestion AJAX, le comportement des cookies et les noms des fonctions de l'API développeur. Polylang utilise des fonctions préfixées pll_ et est généralement plus léger. WPML offre plus de fonctionnalités WooCommerce natives mais représente un plugin plus lourd. Notre article sur WPML couvre ce volet.

Puis-je traduire les libellés du lecteur audio ?

Oui, avec une étape supplémentaire. Polylang expose un écran de traduction des chaînes pour les plugins qui enregistrent leurs chaînes d'interface avec pll_register_string(). Pour que le bouton de lecture, le minuteur ou tout autre texte du lecteur change avec la langue, enregistrez ces chaînes dans votre thème enfant ou dans un petit plugin spécifique au site. Elles apparaissent ensuite dans Langues, Traductions des chaînes.

Prochaine étape

Ouvrez l'un de vos articles traduits dans l'éditeur WordPress et regardez le panneau audio. S'il affiche la bonne langue par défaut, la configuration est terminée. Sinon, définissez la voix sur cette traduction, régénérez et vérifiez en frontend. Quand une traduction fonctionne, les autres suivent le même schéma.

Si vous n'avez pas encore installé Synthèse vocale - TTSWP, téléchargez-le depuis WordPress.org et connectez-le à votre compte TTSWP gratuit. Testez sur une traduction, écoutez et décidez si vous souhaitez déployer sur l'ensemble de vos contenus.