# Elementor V4 pour multisite de 500 sites : partager composants et variables

> Arborescence type et méthode pour partager composants et variables globales de l'éditeur V4 entre cinq cents sites d'un même réseau multisite, sans duplication.

- Auteur : Clément Hadrot
- Publié le : 2026-09-07
- Mis à jour le : 2026-09-07
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/elementor-v4-multisite-500-sites-composants-variables/

## L’essentiel

- Un composant V4 défini sur un site ne se partage pas nativement avec les autres sites du réseau
- Une bibliothèque centrale exportée en JSON sert de source unique de vérité
- Un script de synchronisation programmé propage les mises à jour vers les sites abonnés

Comment garantir qu'un composant V4 modifié sur un site pilote se retrouve identique, sans divergence, sur les cinq cents sites d'un réseau multisite qui l'utilisent ? Cette question s'est posée dès la phase de cadrage d'un chantier de standardisation, une fois établi qu'Elementor ne propose, à ce stade, aucun mécanisme natif de partage de composants entre les différents sites d'une installation multisite WordPress.

Ce billet détaille l'arborescence et la méthode retenues pour résoudre ce problème, sans entrer dans la gestion des utilisateurs à l'échelle du réseau multisite ni dans les questions d'hébergement, deux sujets traités séparément par l'équipe infrastructure.

## Pourquoi Elementor ne résout pas ce problème nativement

Les composants et variables globales de l'éditeur V4 sont stockés dans la base de données propre à chaque site du réseau multisite, exactement comme n'importe quel autre réglage Elementor. Un réseau multisite WordPress partage certes une installation de fichiers commune, mais chaque site conserve ses propres tables de base de données : un composant créé sur le site pilote n'existe tout simplement pas dans la base des 499 autres sites, sans mécanisme de duplication explicite.

## L'arborescence de la bibliothèque centrale

> L'essentiel à retenir : Un composant V4 défini sur un site ne se partage pas nativement avec les autres sites du réseau ; Une bibliothèque centrale exportée en JSON sert de source unique de vérité ; Un script de synchronisation programmé propage les mises à jour vers les sites abonnés

La solution retenue s'appuie sur un site technique dédié au sein du réseau, jouant le rôle de bibliothèque centrale, dans lequel chaque composant validé est exporté sous forme de fichier JSON versionné :

```
bibliotheque-composants/
├── composants-v4/
│   ├── entete-standard.json
│   ├── carte-produit.json
│   └── footer-institutionnel.json
├── variables-globales/
│   ├── palette-couleurs.json
│   └── typographies.json
└── manifest.json
```

Le fichier `manifest.json` recense la version courante de chaque composant et variable, avec un numéro de version incrémenté à chaque modification validée. C'est ce manifeste que consulte le script de synchronisation pour déterminer si un site abonné doit recevoir une mise à jour.

## Le script de synchronisation

Un script WP-CLI personnalisé, exécuté périodiquement via une tâche planifiée sur chaque site abonné, compare la version locale de ses composants avec celle du manifeste central, puis importe les composants et variables mis à jour via l'API d'import native d'Elementor pour les Kits :

```
wp eval-file sync-composants-v4.php --url=site-abonne.reseau.fr
```

```
$manifest = wp_remote_get( 'https://bibliotheque.reseau.fr/manifest.json' );
$distant  = json_decode( wp_remote_retrieve_body( $manifest ), true );
$local    = get_option( 'wpmoderne_composants_version', [] );

foreach ( $distant['composants'] as $nom => $version ) {
    if ( ( $local[ $nom ] ?? 0 ) < $version ) {
        $json = wp_remote_get( "https://bibliotheque.reseau.fr/composants-v4/{$nom}.json" );
        \Elementor\Plugin::instance()->templates_manager
            ->import_template( [ 'fileData' => wp_remote_retrieve_body( $json ) ] );
        $local[ $nom ] = $version;
    }
}

update_option( 'wpmoderne_composants_version', $local );
```

## Ce que cette méthode impose comme discipline

Cette architecture fonctionne à une condition stricte : aucun site du réseau ne doit modifier localement un composant synchronisé depuis la bibliothèque centrale, sous peine de voir sa modification écrasée à la prochaine synchronisation, ou pire, de créer une divergence silencieuse si la synchronisation échoue partiellement. Une convention de nommage stricte distingue les composants partagés (préfixe `reseau-`) des composants propres à un site, qui restent en dehors du périmètre de synchronisation.

- Les composants partagés ne se modifient que sur le site bibliothèque centrale, jamais localement
- Chaque synchronisation est journalisée, avec la version appliquée et l'horodatage, pour faciliter le diagnostic en cas d'écart constaté
- Une alerte est envoyée à l'équipe centrale si un site échoue à synchroniser trois fois de suite

> Notre principe de conception sur ce type d'architecture : la synchronisation doit toujours pouvoir échouer proprement, site par site, sans jamais bloquer ni corrompre le fonctionnement des 499 autres sites du réseau.

## En résumé

Partager des composants et variables globales de l'éditeur V4 entre cinq cents sites d'un même réseau multisite demande de construire, en dehors d'Elementor lui-même, une bibliothèque centrale versionnée et un mécanisme de synchronisation tolérant aux pannes. La discipline la plus importante reste organisationnelle plutôt que technique : interdire toute modification locale d'un composant partagé, sous peine de rendre l'ensemble du système de synchronisation incohérent au fil du temps.