Un réseau multisite WordPress de six sous-sites, chacun dédié à une filiale régionale d’un même groupe, devait devenir accessible en trois langues sans multiplier les installations de plugin ni les configurations à maintenir séparément. La demande initiale du client tenait en une phrase : « On ne veut pas configurer six fois la même chose. » TranslatePress Business, avec son mécanisme de traduction par proxy, a permis de répondre précisément à cette contrainte, au prix d’une complexité déplacée vers l’infrastructure plutôt que vers le contenu.
Ce fonctionnement diffère suffisamment de la traduction classique (dupliquer le contenu par langue en base de données) pour mériter d’être expliqué en détail avant d’être proposé à un client dans un contexte multisite.
Ce qu’est la traduction par proxy, concrètement
Contrairement à Polylang ou WPML, qui stockent chaque traduction comme un contenu WordPress distinct, TranslatePress traduit en mode « au vol » : la version originale du contenu reste unique en base de données, et la traduction est appliquée dynamiquement au moment de l’affichage, en interceptant les chaînes de texte détectées dans le HTML généré. La version Business ajoute une couche supplémentaire : ce traitement peut être délégué à un serveur proxy externe, géré par TranslatePress lui-même, plutôt qu’exécuté par le serveur WordPress à chaque requête.
Concrètement, une requête vers site.com/de/ ne déclenche pas un contenu WordPress différent : elle passe par le proxy, qui récupère la page originale, en traduit le texte détecté, puis renvoie le résultat au visiteur. WordPress lui-même ne « sait » pas qu’une version allemande existe en tant que contenu séparé.
Pourquoi ce mode change la donne en multisite
Sur un multisite classique, chaque sous-site possède ses propres tables de contenu, et une extension comme Polylang ou WPML doit être configurée indépendamment sur chacun, avec ses propres langues actives, ses propres réglages de structure d’URL, potentiellement ses propres crédits de traduction automatique à gérer séparément.
Avec le proxy de TranslatePress Business, la couche de traduction se situe en dehors de la logique multisite elle-même : une seule licence, une seule configuration de langues, appliquée uniformément à travers le proxy quel que soit le sous-site consulté. Le réglage des langues actives et des règles de traduction automatique se fait une fois, centralement, plutôt que six fois séparément.
Ce que cela implique concrètement pour l’équipe technique
- Le DNS de chaque sous-site doit être configuré pour router le trafic multilingue vers le proxy TranslatePress avant d’atteindre le serveur WordPress.
- La configuration de langues se gère depuis un tableau de bord centralisé propre à TranslatePress, distinct de l’administration WordPress classique de chaque sous-site.
- Les mises à jour de contenu sur chaque sous-site sont détectées automatiquement par le proxy, sans intervention manuelle pour resynchroniser les traductions existantes.
Les limites qu’il faut anticiper avec le client
Le mode proxy déplace une partie de la complexité vers l’infrastructure réseau, ce qui suppose un accès aux réglages DNS et parfois un budget d’hébergement supplémentaire pour la couche proxy elle-même, hébergée par TranslatePress. Sur un client peu à l’aise avec ces aspects techniques, cette dépendance supplémentaire doit être clairement expliquée avant la signature du projet, pour éviter toute surprise sur les délais de mise en ligne liés à la propagation DNS.
Autre limite à connaître : la traduction humaine reste possible directement dans l’éditeur visuel de TranslatePress, mais elle porte sur des chaînes détectées automatiquement dans le HTML plutôt que sur un contenu structuré comme le ferait Polylang. Pour un site avec beaucoup de contenu généré dynamiquement par des extensions tierces, certaines chaînes peuvent nécessiter un réglage manuel pour être correctement détectées et proposées à la traduction.
Le proxy résout un vrai problème de mutualisation en multisite, mais il ne dispense pas de tester chaque sous-site individuellement : une chaîne mal détectée sur l’un ne l’est pas forcément sur les autres, selon les extensions activées localement.
Le résultat sur ce projet
Une fois la configuration DNS en place et la période de propagation passée, les six sous-sites sont devenus accessibles en trois langues à travers une configuration unique, gérée depuis un seul tableau de bord. Le temps de configuration initial, plus long qu’anticipé à cause des réglages DNS, a été largement compensé par l’absence de configuration répétée sur chaque sous-site, un gain confirmé lors de l’ajout ultérieur d’un septième sous-site au réseau, intégré à la traduction existante en quelques minutes seulement.
Quand recommander cette approche plutôt qu’une extension classique
Cette approche se justifie surtout quand le nombre de sous-sites à traduire est important et que leur contenu partage une structure similaire. Sur un multisite de deux ou trois sous-sites seulement, la complexité d’infrastructure supplémentaire du proxy n’est généralement pas justifiée face à une configuration classique de Polylang répétée manuellement, plus simple à maintenir pour une petite équipe technique.
Notre verdict
TranslatePress Business en mode proxy tient sa promesse de mutualisation sur un réseau multisite de taille conséquente, mais au prix d’une dépendance réseau supplémentaire qui doit être assumée en amont, pas découverte en cours de projet. La bonne question à poser avant de la recommander n’est pas « combien de langues » mais « combien de sous-sites », et « qui gère le DNS » — la réponse à ces deux questions oriente directement le choix technique.
