500 sites, un seul réseau, une question simple qui devient vite complexe à grande échelle : où vit le code des blocs communs, et comment éviter que chaque site finisse avec sa propre copie légèrement différente du même bloc de mise en avant produit ? Cette architecture décrit la structure retenue pour un multisite WordPress de grande taille opéré par une agence, sans dupliquer une seule ligne de code entre les sites.
Elle ne couvre pas la gestion des utilisateurs et des rôles à l’échelle du multisite, ni l’hébergement de l’infrastructure sous-jacente (base de données, cache objet partagé), qui relèvent de décisions distinctes déjà arbitrées sur ce projet.
L’arborescence retenue
Un plugin unique, activé au niveau réseau (« network activate »), porte l’intégralité du registre de blocs communs. Aucun bloc n’est copié dans les thèmes ou plugins individuels des sites : le plugin réseau est la seule source de vérité.
wp-content/plugins/agence-blocs-reseau/
├── agence-blocs-reseau.php
├── blocs/
│ ├── mise-en-avant-produit/
│ │ ├── block.json
│ │ ├── render.php
│ │ └── build/
│ ├── temoignage-client/
│ │ ├── block.json
│ │ └── build/
│ └── bandeau-alerte/
│ ├── block.json
│ └── build/
├── manifeste-blocs.php
└── includes/
└── class-registre-conditionnel.php
Le manifeste de métadonnées partagé
Avec 500 sites potentiellement actifs simultanément, appeler register_block_type() individuellement pour chacun des blocs, à chaque requête, sur chaque site, représente un coût cumulé mesurable. La fonction wp_register_block_metadata_collection(), introduite en 2024, permet de déclarer l’ensemble des métadonnées de blocs via un unique fichier manifeste PHP, lu une seule fois, plutôt que de parcourir chaque block.json individuellement au chargement.
wp_register_block_metadata_collection(
__DIR__ . '/blocs',
__DIR__ . '/manifeste-blocs.php'
);
Le chargement conditionnel par capacité de site
Tous les sites du réseau n’ont pas vocation à utiliser tous les blocs : un site vitrine institutionnel n’a pas besoin du bloc « bandeau alerte promotionnelle », conçu pour les sites e-commerce du réseau. Plutôt que de dupliquer le plugin en plusieurs variantes, une option réseau par site (stockée via update_blog_option()) détermine quels groupes de blocs sont réellement enregistrés :
- Un tableau de capacités par site, stocké en option réseau, listant les groupes de blocs autorisés.
- Le registre filtre l’enregistrement des blocs au moment du chargement, site par site, sans dupliquer le code source.
- Un site qui change de capacité (montée en gamme e-commerce, par exemple) obtient l’accès sans déploiement de code.
Le point de friction principal
Le vrai risque de cette architecture centralisée n’est pas technique mais organisationnel : une modification d’un bloc commun impacte instantanément les 500 sites du réseau, sans étape de validation individuelle par site. Une régression sur le bloc « mise en avant produit » se propage immédiatement partout où il est utilisé, ce qui impose une discipline de test bien supérieure à celle d’un site isolé.
| Approche | Duplication de code | Risque de propagation d’un bug |
|---|---|---|
| Un plugin par site | Élevée, 500 copies à maintenir | Faible, isolé par site |
| Un plugin réseau centralisé | Nulle | Élevé, propagation immédiate |
La discipline de recette imposée
Pour compenser ce risque, chaque modification du registre de blocs commun passe par un environnement de recette répliquant un échantillon de dix sites représentatifs des différentes capacités du réseau, avant tout déploiement en production réseau. Un déploiement direct en production, sans cet échantillon de vérification, est explicitement interdit dans la procédure interne de l’agence.
Centraliser un registre de blocs sur un réseau de cette taille est un choix d’efficacité, pas un choix de confort : il exige en retour une rigueur de test proportionnelle au nombre de sites impactés par chaque changement.
En résumé
Un plugin réseau unique, un manifeste de métadonnées partagé via wp_register_block_metadata_collection(), et un chargement conditionnel par capacité de site : cette combinaison évite toute duplication de code sur un multisite de 500 sites, au prix d’une discipline de recette renforcée avant chaque déploiement, condition non négociable de cette architecture.
