Cinq hôtels indépendants, réunis sous une même charte de marque commune mais gérés au quotidien par des équipes locales distinctes, chacune avec ses propres tarifs saisonniers, ses propres périodes de forte affluence, et surtout ses propres priorités de mise à jour. Fallait-il centraliser ces cinq sites sous un unique réseau multisite WordPress, solution qui paraît de prime abord la plus économique à administrer, ou maintenir cinq installations totalement indépendantes ? Ce choix architectural, tranché avant même la première ligne de code, mérite d’être détaillé, car l’intuition de la centralisation n’est pas toujours la bonne.
Cet article ne traite pas du moteur de réservation lui-même, intégré séparément sur chaque site via un service tiers spécialisé, mais uniquement de l’architecture d’hébergement qui porte ces cinq installations WordPress.
Pourquoi le multisite a été écarté
Un réseau multisite WordPress partage une base de données unique et un cœur applicatif commun entre tous les sites du réseau. Cette mutualisation, séduisante sur le papier pour réduire les coûts de maintenance, introduit un couplage fort entre les établissements : une mise à jour du cœur ou d’une extension réseau s’applique à tous les sites simultanément, un incident de base de données affecte l’ensemble du réseau d’un coup, et une extension spécifique aux besoins d’un seul établissement (un module de gestion d’événements privés pour l’un des hôtels, absent chez les autres) complique l’administration du réseau entier.
Le rythme de mise à jour, argument décisif
L’hôtel historique du groupe, ouvert depuis des décennies, fonctionne avec une équipe prudente qui préfère des mises à jour espacées et testées. L’établissement le plus récent, plus digitalisé, veut au contraire suivre chaque nouveauté du cœur WordPress dès sa sortie. Un réseau multisite impose le même rythme à tous, ce qui aurait nécessairement mécontenté l’un des deux profils.
L’architecture retenue : cinq serveurs, un thème partagé versionné
Chaque établissement dispose de sa propre instance WordPress, sur son propre serveur, avec sa propre base de données et son propre rythme de mise à jour. Ce qui unifie visuellement les cinq sites, ce n’est pas une base de code partagée en temps réel, mais un thème commun versionné dans un dépôt central, installé indépendamment sur chaque serveur et mis à jour établissement par établissement, au moment choisi par chacun.
chaine-hotels-theme/
├── style.css
├── functions.php
├── template-parts/
│ ├── chambre-details.php
│ └── galerie-etablissement.php
└── CHANGELOG.md
Ce dépôt central publie une nouvelle version taguée à chaque évolution notable. Chaque établissement peut alors choisir de monter de version quand il le souhaite, en testant d’abord sur son propre environnement de recette, sans dépendance envers le calendrier des quatre autres.
Ce que cette architecture demande en contrepartie
L’isolation complète a un coût : cinq serveurs à surveiller plutôt qu’un seul, cinq jeux de sauvegardes à vérifier, et une discipline de publication du thème plus rigoureuse pour éviter que les cinq installations ne divergent au point de devenir difficiles à maintenir collectivement. Pour limiter ce risque, une convention simple a été retenue : aucune modification directe du thème sur un serveur de production, toute personnalisation locale passe par un thème enfant propre à l’établissement concerné.
- Le thème principal reste strictement identique sur les cinq installations, à la version près.
- Les particularités de chaque établissement (un encart pour un restaurant gastronomique attenant, une page dédiée aux séminaires) vivent dans le thème enfant local.
- Toute évolution jugée utile à l’ensemble de la chaîne remonte dans le thème principal, jamais l’inverse.
Comparatif avec l’option multisite écartée
| Critère | Multisite centralisé | Cinq serveurs isolés |
|---|---|---|
| Rythme de mise à jour | Identique pour tous les établissements | Propre à chaque établissement |
| Impact d’un incident serveur | Affecte potentiellement toute la chaîne | Limité à un seul établissement |
| Coût d’hébergement mensuel | Plus faible à court terme | Plus élevé, mais réparti |
| Extension propre à un établissement | Complique la gestion réseau | Installée localement sans impact ailleurs |
La question qui a tranché le débat en interne : si le serveur de l’hôtel historique tombe un samedi soir en pleine saison, les quatre autres établissements doivent-ils en subir la moindre conséquence ? La réponse, non, a suffi à écarter le multisite.
En résumé
Pour une chaîne d’hôtels indépendants dont les rythmes d’exploitation et de mise à jour diffèrent réellement d’un établissement à l’autre, l’infrastructure isolée par site protège mieux contre la propagation d’incidents qu’un réseau multisite mutualisé. La cohérence visuelle et fonctionnelle de la marque se maintient alors par la discipline d’un thème partagé versionné, pas par un couplage technique entre les serveurs eux-mêmes.
