Thèmes multi-marques : un parent, plusieurs enfants et des variations

Un groupe possédant quatre enseignes de restauration nous a confié la refonte de leurs sites respectifs, avec une contrainte forte : une structure de page quasi identique d’une marque à l’autre, mais une identité visuelle propre à chacune, et la nécessité de faire évoluer la structure commune sans repasser sur les quatre sites un par un à chaque correctif.

Ce cas ne relève pas d’un multisite WordPress : chaque marque dispose de sa propre installation, sur des hébergements parfois différents. La question portait uniquement sur l’architecture des thèmes, pas sur l’infrastructure d’hébergement partagée.

Ce qui reste dans le thème parent

Le thème parent porte tout ce qui relève de la structure et de la logique, jamais de l’identité visuelle propre à une marque :

• Les templates de page (accueil, menu, contact, mentions légales), avec leur structure de blocs.
• Les types de contenus personnalisés partagés : plats, catégories de menu, établissements.
• Les blocs personnalisés (une carte plat, un sélecteur d’établissement) enregistrés en PHP.
• Le squelette de theme.json, avec les clés structurelles (customTemplates, templateParts) mais sans les valeurs de palette ou de typographie.

theme-parent-groupe/
  functions.php
  templates/
  parts/
  patterns/
  inc/
    post-types.php
    blocks.php
  theme.json

Ce qui revient à chaque thème enfant

Chaque marque dispose d’un thème enfant minimal, dont le rôle se limite à surcharger l’identité visuelle :

theme-enfant-marque-a/
  style.css
  theme.json
  styles/
    variation-saison.json
  assets/
    logo.svg
    polices/

Le theme.json de l’enfant ne redéclare que les clés de personnalisation : palette de couleurs, presets typographiques, éventuellement une police de marque spécifique. WordPress fusionne automatiquement les theme.json du parent et de l’enfant, l’enfant ayant priorité sur les clés qu’il redéfinit — un mécanisme natif au cœur de WordPress, sans code supplémentaire à écrire pour l’obtenir.

Gestion des variations saisonnières

Deux des quatre marques proposent des opérations saisonnières (menu de fêtes, campagne d’été) avec une variante de palette temporaire. Plutôt que de modifier le theme.json principal de l’enfant à chaque saison, chaque marque dispose d’un fichier de variation dans son propre dossier styles/, activable et désactivable depuis le panneau Styles de l’éditeur, sans intervention technique de notre part une fois la variation livrée.

Propagation d’une mise à jour du parent

Le cas d’usage qui a validé cette architecture : l’ajout d’un nouveau champ dans la carte plat (un badge « nouveauté »), demandé initialement par une seule marque puis étendu aux quatre. La modification du bloc personnalisé dans le thème parent, une fois testée sur l’environnement de la marque demandeuse, a été déployée sur les trois autres sites sans aucune adaptation côté thème enfant : ceux-ci héritent automatiquement du bloc mis à jour, puisqu’ils ne redéfinissent pas cette logique.

Modification	Portée
Nouveau champ dans un bloc du parent	Propagée automatiquement aux quatre enfants
Nouvelle couleur de palette	Reste isolée dans le theme.json de l’enfant concerné
Nouveau template de page	Propagé au parent, visible immédiatement sur les quatre sites

Le test le plus fiable pour valider une architecture parent-enfants multi-marques : demander à une marque un changement structurel après six mois de production, et vérifier combien de temps il faut pour le propager aux autres sans régression. Sur ce projet, la réponse est descendue à moins d’une demi-journée par marque, contre plusieurs jours avec quatre thèmes indépendants avant la refonte.

Limites de l’approche

Cette architecture suppose une vraie discipline : toute tentation d’ajouter une exception visuelle directement dans le thème parent, « juste pour cette marque, juste cette fois », fragilise l’ensemble du système à moyen terme. Sur ce projet, nous avons refusé deux demandes ponctuelles de ce type, en les redirigeant vers le thème enfant concerné plutôt que vers le parent commun.

En résumé

Une architecture parent-enfants pour un contexte multi-marques fonctionne à condition de tracer une frontière stricte entre structure (parent) et identité (enfant), sans jamais laisser une exception visuelle remonter dans le code commun. Le bénéfice se mesure directement au temps nécessaire pour propager une évolution structurelle à l’ensemble des marques.