vendredi 25 septembre 2026

À propos

Contact

Multilingue

MultilingualPress : gérer un réseau multisite multilingue avec des sites vraiment indépendants

Pour des sites régionaux gérés séparément, MultilingualPress relie un multisite WordPress sans dupliquer les contenus dans les mêmes tables. Explications.

Par Clément Hadrot • 21 septembre 2021 • 6 min de lecture • Aucun commentaire
MultilingualPress : gérer un réseau multisite multilingue avec des sites vraiment indépendants

WPML et Polylang partagent une même philosophie : une seule installation WordPress, un seul jeu de tables de base de données, des posts dupliqués et reliés entre eux par langue. Cette approche convient à la majorité des sites multilingues. Mais certains projets ont des besoins différents : plusieurs équipes éditoriales autonomes, une par pays, chacune avec ses propres administrateurs, ses propres extensions actives, et une tolérance nulle à toute dépendance entre les contenus des différentes langues.

C’est précisément le terrain de MultilingualPress : une extension conçue pour relier plusieurs sites d’un réseau WordPress multisite, chacun correspondant à une langue ou une région, sans les faire cohabiter dans les mêmes tables de contenu.

Le principe : un site du réseau par langue

Sur un multisite WordPress classique, chaque site du réseau possède son propre jeu de tables (wp_2_posts, wp_3_posts, etc., le préfixe numérique correspondant à l’ID du site). MultilingualPress s’appuie directement sur cette architecture native : au lieu de dupliquer un post dans la même table comme le font WPML ou Polylang, chaque langue vit dans son propre site du réseau, avec ses propres tables complètement séparées.

La relation entre les contenus de deux sites différents est stockée dans une table de correspondance propre à l’extension, qui associe l’ID d’un post sur le site A à l’ID de son équivalent sur le site B. Cette relation permet d’afficher un sélecteur de langue cohérent et de proposer, lors de la création d’un contenu, un lien direct vers l’écran de création de sa traduction sur l’autre site du réseau.

Pourquoi cette architecture plutôt que WPML ou Polylang

Trois cas d’usage justifient concrètement ce choix :

  • Autonomie éditoriale forte : une filiale allemande peut gérer son propre site, ses propres utilisateurs, ses propres extensions actives (un plugin de paiement local, par exemple), sans dépendre des réglages du site français.
  • Isolation en cas de panne : une erreur fatale sur le site français (une extension mal mise à jour, une requête qui sature la base) n’affecte pas nécessairement le site allemand, puisque les tables sont séparées — même si le serveur physique reste partagé sur une installation multisite classique.
  • Contenu volontairement divergent : certains projets ne veulent pas qu’une page existe obligatoirement dans toutes les langues. Un site multisite avec MultilingualPress permet à chaque site de publier son propre contenu, sans lien de traduction si aucun n’est nécessaire, contrairement à WPML et Polylang qui présupposent une correspondance systématique entre contenus.
L'essentiel à retenir : Chaque langue est un site WordPress à part entière dans le réseau ; Les contenus sont reliés, pas dupliqués dans les mêmes tables ; Solution adaptée aux équipes éditoriales indépendantes par pays

Mise en place technique

Le prérequis absolu est un réseau WordPress multisite fonctionnel, activé via la constante WP_ALLOW_MULTISITE dans wp-config.php puis configuré depuis Réseau → Créer. Une fois le réseau en place, chaque site correspondant à une langue est créé normalement depuis Mes sites → Réseau → Sites → Ajouter, avec son propre domaine ou sous-domaine.

MultilingualPress s’installe ensuite au niveau du réseau (activation réseau, pas activation simple sur un seul site) et se configure depuis Réseau → Réglages → MultilingualPress, où l’on associe chaque site à une langue et où l’on définit les relations entre sites (quel site est la traduction de quel autre).

// wp-config.php - activer le support multisite avant configuration réseau
define( 'WP_ALLOW_MULTISITE', true );

Relier deux contenus existants

Sur l’écran d’édition d’un article, une métabox « MultilingualPress » liste les autres sites du réseau et permet, pour chacun, soit de créer une nouvelle traduction (ce qui ouvre l’écran de création sur le site cible avec le contenu source en référence), soit de relier un contenu déjà existant sur ce site si la traduction a été rédigée indépendamment.

Ce que MultilingualPress ne fait pas

Contrairement à WPML, MultilingualPress ne propose pas nativement de traduction automatique intégrée ni de tableau de bord centralisé listant l’avancement des traductions sur l’ensemble du réseau — chaque site garde sa propre file d’articles à traduire, sans vue transversale simple. Pour un client qui souhaite piloter finement l’avancement de ses traductions depuis un seul écran, WPML ou Polylang restent souvent plus adaptés.

De la même manière, la synchronisation de contenus partagés entre langues (un menu identique, une même image mise en avant) n’est pas automatique : chaque site du réseau reste par nature indépendant, ce qui signifie qu’un changement de logo doit être répété manuellement sur chaque site, sauf à mettre en place soi-même une synchronisation via les hooks réseau (switch_to_blog() dans une extension personnalisée, par exemple).

Nous ne recommandons MultilingualPress que lorsque le client exprime clairement un besoin d’autonomie entre ses équipes par pays. Pour un site géré par une seule équipe éditoriale avec un simple besoin de traduction, l’architecture single-site de WPML ou Polylang reste plus simple à maintenir au quotidien.

Coût d’hébergement et de maintenance

Un réseau multisite avec MultilingualPress implique par nature davantage de complexité d’hébergement : chaque site doit être surveillé, mis à jour (les extensions activées site par site, pas seulement au niveau réseau, doivent être maintenues individuellement), et sauvegardé. Sur un projet à trois langues, cela signifie concrètement trois configurations à auditer plutôt qu’une seule installation avec trois langues internes. C’est un coût réel à mettre en balance avec le bénéfice d’autonomie recherché.

En résumé

MultilingualPress répond à un besoin précis et minoritaire par rapport à WPML ou Polylang : celui d’équipes éditoriales véritablement indépendantes par langue ou par pays, au prix d’une architecture multisite plus lourde à administrer et d’une absence de vue centralisée sur l’avancement des traductions. Pour la majorité des sites bilingues ou trilingues gérés par une seule équipe, une extension multilingue single-site reste le choix le plus pragmatique ; MultilingualPress prend tout son sens à partir du moment où l’autonomie entre langues devient une exigence organisationnelle, pas seulement technique.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi