Le groupe hôtelier qui a commandé ce projet possédait quatre enseignes bien distinctes : une chaîne d’hôtels d’affaires, une marque de resorts familiaux, une offre de séjours d’affaires courte durée, et une marque récemment rachetée orientée bien-être. Chaque marque avait son identité visuelle propre, son équipe marketing propre, et surtout son propre calendrier de mise en ligne. Le siège technique du groupe, en revanche, ne voulait gérer qu’une seule infrastructure back-office.
La contrainte n’était donc pas de faire cohabiter plusieurs designs sur un même site, ce qui est un problème résolu depuis longtemps avec un thème multi-marques classique. Elle était de faire cohabiter quatre équipes de développement front totalement indépendantes, chacune avec son propre rythme de déploiement, sur une seule source de contenu.
Le choix du multisite WordPress comme back-office pivot
Le réseau WordPress multisite a été retenu plutôt qu’un WordPress unique avec un champ « marque » sur chaque contenu. Ce choix a été guidé par une exigence de sécurité et de gouvernance : l’équipe marketing d’une marque ne devait avoir accès qu’aux contenus de sa propre marque, sans risque de fuite croisée ni de permission mal configurée sur un champ personnalisé. Le multisite WordPress offre cette isolation nativement, chaque site du réseau ayant ses propres utilisateurs, ses propres rôles et ses propres tables de contenu, tout en partageant la même installation de plugins et le même réseau d’hébergement.
Chacun des quatre sites du réseau expose son API REST à sa propre adresse (affaires.cms.groupe.exemple/wp-json, resorts.cms.groupe.exemple/wp-json, etc.), gérée via l’option de domaines de sous-site du multisite plutôt que par des chemins imbriqués, pour simplifier la configuration CORS de chaque front.
Quatre fronts, un seul contrat d’API
La vraie difficulté de gouvernance n’était pas technique mais organisationnelle : sans coordination, chaque équipe front aurait fini par consommer l’API REST WordPress à sa manière, avec ses propres conventions de nommage de champs personnalisés, rendant toute évolution commune du back-office risquée pour au moins une des quatre marques.
La solution a été de définir un contrat d’API commun aux quatre sites, appliqué via un plugin mu-plugin partagé sur l’ensemble du réseau, qui enregistre les mêmes champs personnalisés de la même façon sur chaque site :
add_action('rest_api_init', function () {
register_rest_field('page', 'design_marque', [
'get_callback' => function () {
return [
'code' => get_option('code_marque_groupe', 'inconnu'),
'palette_active' => get_theme_mod('palette_active', 'defaut'),
];
},
]);
});Ce mu-plugin, versionné dans un dépôt Git partagé et déployé identiquement sur l’ensemble du réseau multisite, garantit que les quatre fronts reçoivent toujours la même structure de champ, quelle que soit la marque interrogée. Toute évolution du contrat passe par une revue de code centralisée avant déploiement, plutôt que par une décision isolée d’une seule équipe.
L’authentification, un point de friction résolu une seule fois
Les quatre fronts avaient besoin d’écrire dans WordPress pour certaines fonctionnalités (formulaire de réservation, avis clients modérés). Plutôt que de laisser chaque équipe implémenter sa propre gestion des mots de passe d’application, un module d’authentification partagé, publié en paquet npm interne, a été développé une seule fois et réutilisé par les quatre dépôts Next.js. Ce module gère le rafraîchissement des jetons et le traitement des erreurs 401 de façon identique partout, ce qui évite quatre implémentations légèrement différentes du même problème.
Ce que le découplage a permis concrètement
- La marque bien-être, récemment rachetée, a pu lancer son nouveau site en huit semaines avec une stack technique différente des trois autres (Astro plutôt que Next.js), sans que cela n’impacte le reste du groupe, uniquement parce que le contrat d’API restait identique.
- Une migration de version majeure de WordPress sur le réseau multisite ne nécessite qu’un seul cycle de tests de non-régression, appliqué aux quatre fronts via une suite de tests d’intégration partagée sur les principaux endpoints.
- Le coût d’hébergement du back-office est resté celui d’une seule installation WordPress, avec une seule facture de maintenance de sécurité, malgré quatre marques et quatre équipes front.
Les limites de cette architecture
Le multisite WordPress impose des contraintes réelles : impossible de faire évoluer un plugin sur un seul site du réseau sans affecter potentiellement les trois autres, ce qui a nécessité une discipline stricte de tests avant toute mise à jour de plugin. Par ailleurs, une marque qui souhaiterait un jour un modèle de contenu radicalement différent (un type de contenu personnalisé propre, absent des trois autres) doit composer avec un schéma de base de données partagé, ce qui demande davantage de coordination qu’un WordPress totalement indépendant.
Un WordPress unique pour plusieurs marques n’est un bon choix que si la gouvernance des contenus et des permissions est pensée en amont ; sinon, c’est la garantie d’un incident de sécurité entre marques tôt ou tard.
Notre verdict
Deux ans après la mise en ligne des quatre sites, l’architecture a tenu ses promesses principales : un seul back-office à maintenir, quatre fronts totalement autonomes dans leur rythme de déploiement. Le facteur décisif n’a pas été un choix technique isolé, mais la définition précoce d’un contrat d’API partagé et versionné, qui a évité que les quatre équipes ne s’éloignent progressivement les unes des autres dans leur façon de consommer le même back-office.
