# Un registre de blocs partagé sur un multisite de 500 sites, sans duplication

> Arborescence type et méthode pour opérer un registre de blocs commun sur un multisite de très grande taille, sans dupliquer le code entre les 500 sites du réseau.

- Auteur : Clément Hadrot
- Publié le : 2025-11-08
- Mis à jour le : 2025-11-08
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/registre-blocs-multisite-500-sites/

## L’essentiel

- Un seul plugin réseau active tous les blocs communs
- Chargement conditionnel par capacité de site, pas par duplication
- Manifeste de blocs partagé via wp_register_block_metadata_collection

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'
);
```

> L'essentiel à retenir : Un seul plugin réseau active tous les blocs communs ; Chargement conditionnel par capacité de site, pas par duplication ; Manifeste de blocs partagé via wp_register_block_metadata_collection

## 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.