Le WordPress d'aujourd'hui, décodé pour les développeurs

Multilingue

Un multisite de 500 boutiques locales en douze langues : ce qui a tenu

Un réseau de franchises combine multisite et multilingue à très grande échelle sans transformer chaque déploiement en opération manuelle.

Par WordPress Développement • 28 juin 2022 • 4 min de lecture • Aucun commentaire
Un multisite de 500 boutiques locales en douze langues : ce qui a tenu

500 sites actifs, un par boutique locale, répartis dans douze pays et donc douze langues, sur une seule installation WordPress multisite : ce réseau de franchises n’a pas choisi cette échelle par confort technique, mais par nécessité commerciale — chaque franchisé doit pouvoir gérer les horaires, les promotions locales et les coordonnées de sa boutique, sans dépendre d’un service central pour la moindre modification.

Ce cas ne repose pas sur MultilingualPress, l’extension pensée spécifiquement pour lier des sites multisite entre eux comme traductions les uns des autres, déjà documentée séparément. Ici, l’architecture retenue est différente : chaque site du multisite correspond à une seule langue et un seul pays, sans lien de traduction croisé entre eux, parce que le contenu local d’une boutique ne se traduit pas d’un pays à l’autre, il diffère structurellement.

Un site modèle, cloné par script à chaque nouvelle boutique

La structure technique s’appuie sur un site modèle par langue (douze sites modèles au total, un par langue/pays), maintenu par l’équipe technique centrale, qui contient la structure de pages, le thème, les blocs réutilisables et les traductions génériques de l’interface. Chaque nouvelle boutique ne part jamais d’une installation vierge, mais d’un clonage automatisé du site modèle correspondant à sa langue :

arborescence (simplifiée) :
reseau-franchise.com/
├── modele-fr/          (site modèle français, jamais visible du public)
├── modele-de/          (site modèle allemand)
├── modele-it/          (site modèle italien)
├── ...
├── boutique-lyon/      (site réel, cloné depuis modele-fr)
├── boutique-marseille/ (site réel, cloné depuis modele-fr)
├── boutique-berlin/    (site réel, cloné depuis modele-de)
└── ... (500 sites au total)

Le clonage s’effectue via un script WP-CLI qui duplique la structure de base de données du site modèle vers un nouveau site du multisite, avant d’y injecter les données spécifiques à la nouvelle boutique (adresse, horaires, coordonnées de contact).

Le rôle central des mises à jour automatisées et non manuelles

L'essentiel à retenir : Un site modèle centralise la structure, chaque franchisé n'édite que son contenu local ; La langue est déterminée par le pays du site, pas par un réglage individuel ; L'automatisation du déploiement évite 500 configurations manuelles

Faire évoluer une fonctionnalité sur 500 sites individuellement serait impraticable pour l’équipe centrale. Toute modification de structure, de bloc réutilisable ou de gabarit passe systématiquement par le site modèle correspondant à sa langue, puis se propage aux sites existants via un script de synchronisation, exécuté sur une plage horaire creuse :

  • Les blocs réutilisables du site modèle sont identifiés par un slug fixe, retrouvé et remplacé sur chaque site cloné sans écraser le contenu local que le franchisé a pu personnaliser autour
  • Un système de verrouillage de blocs (attribut lock de l’éditeur de blocs) protège certaines zones de la modification par le franchisé, réservées à l’équipe centrale
  • Les traductions génériques de l’interface (libellés de formulaire, mentions obligatoires) sont mises à jour uniquement sur le site modèle, jamais boutique par boutique

La langue déterminée par le pays, pas par un choix individuel du franchisé

Contrairement à un site multilingue classique où un visiteur choisit sa langue, ici chaque site du réseau n’existe que dans une seule langue, celle du pays où se trouve la boutique physique. Ce choix architectural simplifie radicalement la gestion : pas de sélecteur de langue à maintenir, pas de traduction croisée entre boutiques, chaque franchisé travaille exclusivement dans sa propre langue sans jamais avoir à se soucier des onze autres.

Ce qui a posé problème malgré tout : les mentions légales par pays

Le point qui a demandé le plus d’ajustements après le lancement n’est pas la langue en elle-même, mais les mentions légales et fiscales qui diffèrent d’un pays à l’autre au-delà de la simple traduction : numéro de TVA intracommunautaire, mentions RGPD adaptées à la réglementation locale, conditions de rétractation propres à chaque législation nationale. Ces blocs ont dû être traités comme des variantes par pays du site modèle, pas comme une simple traduction du même texte source.

En résumé

Un multisite multilingue à très grande échelle tient dans la durée grâce à une séparation stricte entre ce que le site modèle centralise (structure, blocs génériques, mises à jour) et ce que chaque franchisé édite localement (contenu spécifique à sa boutique). La langue, ici, n’est pas un réglage individuel mais une propriété fixe de chaque site, déterminée une fois pour toutes à la création, ce qui élimine une bonne partie de la complexité qu’un multilingue classique devrait gérer.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

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

Voir tous ses articles

Dans la même veine

À lire aussi