# Multisite de 500 sites en éditeur de site : synchroniser templates et styles

> 500 sites, un seul thème bloc partagé. Arborescence retenue et méthode de propagation contrôlée d'un template ou d'un style global, sans casser les personnalisations locales.

- Auteur : WordPress Développement
- Publié le : 2022-04-08
- Mis à jour le : 2022-04-08
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/multisite-500-sites-editeur-site-synchroniser-templates/

## L’essentiel

- Un thème bloc parent versionné dans un dépôt central
- Une propagation par lot plutôt qu'un déploiement global
- Des variations de style isolées par site

500 sites d'écoles rattachées à un même réseau, chacun avec son identité visuelle propre, mais partageant une structure de page identique : c'est le périmètre confié à l'agence pour ce réseau multisite construit entièrement en éditeur de site, alors que WordPress 5.9 venait de livrer nativement le Site Editor complet quelques mois plus tôt. La question centrale du projet n'était pas la conception d'un thème bloc, déjà maîtrisée sur des projets plus modestes, mais la propagation contrôlée de ses évolutions sur un parc aussi large sans provoquer d'incident en cascade.

Modifier un template sur 500 sites à la main est évidemment exclu. Mais un déploiement automatique et immédiat de chaque changement présente un risque symétrique : la moindre erreur dans un template se propage instantanément à l'ensemble du réseau, sans marge de retour arrière simple. L'architecture retenue tente de concilier ces deux contraintes.

## Arborescence retenue pour le thème bloc parent

```
theme-reseau-ecoles/
├── style.css
├── theme.json
├── functions.php
├── templates/
│   ├── index.html
│   ├── single.html
│   ├── archive.html
│   └── page-actualites.html
├── parts/
│   ├── header.html
│   ├── footer.html
│   └── menu-etablissement.html
└── patterns/
    ├── bloc-contact-etablissement.php
    └── grille-actualites.php
```

Chaque site du réseau active ce thème bloc unique, versionné dans un dépôt Git central. Les personnalisations propres à un établissement (logo, couleurs, coordonnées) sont isolées dans un fichier `theme.json` spécifique à chaque site, généré à partir d'un gabarit commun, jamais directement modifié dans le thème parent.

## Synchroniser sans écraser les personnalisations locales

La méthode retenue distingue deux couches strictement séparées : le thème parent, qui porte la structure et les templates communs, et une surcouche de styles globaux par site, injectée via l'API `wp_theme_json_data_theme`, qui permet de fusionner des réglages spécifiques sans dupliquer le fichier `theme.json` complet sur chacun des 500 sites.

> L'essentiel à retenir : Un thème bloc parent versionné dans un dépôt central ; Une propagation par lot plutôt qu'un déploiement global ; Des variations de style isolées par site

```
add_filter( 'wp_theme_json_data_theme', function ( $theme_json ) {
    $site_id = get_current_blog_id();
    $reglages_locaux = get_option( 'wpm_couleurs_etablissement_' . $site_id );
    if ( ! $reglages_locaux ) {
        return $theme_json;
    }
    return $theme_json->update_with( array(
        'version'  => 2,
        'settings' => array( 'color' => array( 'palette' => $reglages_locaux ) ),
    ) );
} );
```

## Propager un changement de template par lot

Le déploiement d'une modification de template ne se fait jamais sur l'ensemble des 500 sites en une seule opération. Un lot pilote d'une dizaine d'établissements volontaires reçoit chaque changement en premier, avec une période d'observation de deux jours ouvrés avant extension au reste du réseau, via un script WP-CLI exécutant la commande de mise à jour de thème site par site, en boucle contrôlée avec pause entre chaque lot.

1. Déployer le nouveau thème parent sur un lot pilote de dix sites.
2. Observer les retours et les journaux d'erreurs pendant deux jours ouvrés.
3. Étendre le déploiement par vagues de cinquante sites, avec vérification automatisée entre chaque vague.
4. Conserver la version précédente du thème disponible pour un retour arrière rapide en cas d'incident.

## Ce que cette architecture évite volontairement

Ce billet ne traite pas la gestion des comptes utilisateurs à l'échelle du multisite, ni les choix d'hébergement qui permettent de faire tenir 500 sites sur une infrastructure raisonnable : ces deux sujets, bien que liés, relèvent de décisions indépendantes de l'architecture des templates elle-même.

> Sur un multisite de cette taille, la vraie compétence recherchée n'est pas de savoir construire un thème bloc, mais de savoir le faire évoluer sans jamais avoir à tout tester manuellement sur 500 instances différentes.

## Ce qui reste fragile dans cette approche

La séparation entre thème parent et surcouche de styles locaux fonctionne bien pour les couleurs et la typographie, mais reste plus délicate pour des modifications structurelles profondes d'un template : un établissement ayant demandé une mise en page radicalement différente pour sa page d'actualités a nécessité la création d'une variante de template dédiée, gérée en dehors du cycle de propagation standard, ce qui complexifie légèrement la maintenance à long terme.

## En résumé

Gérer un thème bloc unique sur 500 sites suppose une architecture qui sépare clairement structure commune et personnalisation locale, ainsi qu'une méthode de déploiement par vagues plutôt qu'un basculement global immédiat. Cette rigueur, coûteuse à mettre en place au départ, évite qu'une simple erreur de template ne devienne un incident touchant l'ensemble du réseau en quelques secondes.