« Une classe globale doit produire le même rendu visuel sur les douze boutiques, ou elle n’a pas sa place dans le socle partagé. » Cette règle, simple à énoncer, est difficile à tenir dès que plusieurs équipes interviennent sur des instances WordPress distinctes qui partagent pourtant la même identité de marque. C’est exactement le problème que pose la gouvernance d’un design system Elementor à l’échelle d’un réseau de boutiques WooCommerce.
L’éditeur Elementor introduit progressivement, à travers son nouvel éditeur atomique encore en évolution, un système de classes globales et de variables destiné à remplacer les styles dupliqués widget par widget. Sur une seule boutique, l’intérêt est déjà réel. Sur douze instances distinctes gérées par plusieurs prestataires, la question change de nature : il ne s’agit plus de style, mais de gouvernance.
Pourquoi la duplication de classes finit toujours par diverger
Sans processus commun, chaque boutique tend à recréer ses propres classes locales pour des besoins qui semblent, au départ, spécifiques : un bouton d’appel à l’action légèrement plus large sur une boutique à fort trafic mobile, une couleur de fond ajustée pour un marché où la charte tolère une variante. Trois mois plus tard, les douze boutiques affichent des boutons visuellement proches mais jamais identiques, et personne ne sait plus laquelle des variantes correspond à la charte de référence.
Ce phénomène n’est pas propre à Elementor : c’est le problème classique de tout design system distribué. Ce qui change avec les classes globales de l’éditeur atomique, encore en phase de stabilisation à cette date, c’est qu’elles sont exportables et partageables entre instances via des fichiers de définition, ce qui rend la gouvernance techniquement possible — à condition de l’organiser.
Une arborescence de référence pour le socle partagé
La première décision structurante consiste à désigner une instance WordPress « source de vérité », généralement un environnement de préproduction dédié, où vivent les définitions canoniques des classes globales et des variables. Aucune boutique de production ne modifie directement ce socle.
design-system/
├── source-de-verite/ (instance de référence, non publique)
│ ├── classes-globales.json
│ └── variables.json
├── boutiques/
│ ├── boutique-nord.example
│ ├── boutique-est.example
│ ├── boutique-ouest.example
│ └── ... (12 instances)
└── journal-des-versions.md
Chaque modification de classe globale sur la source de vérité passe par une revue avant export : un changement de rayon de bordure sur le bouton principal, par exemple, est d’abord testé visuellement sur trois gabarits de page représentatifs (fiche produit, panier, page de contenu) avant d’être considéré comme validé.
Le processus de validation en trois temps
- Proposition : toute demande de modification d’une classe globale est documentée avec le motif métier (accessibilité, conversion, cohérence de marque) et non comme une préférence esthétique isolée.
- Validation croisée : la modification est appliquée sur l’instance source, puis revue par une personne qui n’est pas à l’origine de la demande, pour éviter la validation d’une préférence personnelle non partagée.
- Propagation contrôlée : l’export des classes globales est déployé sur un lot restreint de boutiques pilotes avant généralisation aux douze instances, avec un point de contrôle visuel après déploiement.
Ce processus ralentit volontairement la propagation. C’est un choix assumé : sur un réseau de douze boutiques, la vitesse de diffusion d’une erreur de style est proportionnelle au nombre d’instances, et une classe globale mal calibrée touche instantanément l’ensemble du réseau plutôt qu’une seule boutique.
Distinguer variation locale légitime et dérive non maîtrisée
Toutes les différences entre boutiques ne sont pas des anomalies. Une boutique qui vend dans un marché où la réglementation impose un bandeau d’information produit supplémentaire a une raison légitime de s’écarter du gabarit commun. La gouvernance ne doit pas interdire ces variations, mais les rendre traçables : chaque classe locale créée en dehors du socle partagé est déclarée dans un registre, avec sa justification.
- Variation légitime : contrainte réglementaire locale, spécificité produit documentée
- Dérive non maîtrisée : classe locale créée par commodité, sans registre, qui duplique une classe globale existante
Un audit trimestriel du registre permet de repérer les classes locales qui, en réalité, devraient être remontées au socle partagé parce qu’elles répondent à un besoin commun à plusieurs boutiques.
Un design system qui n’autorise aucune exception finit contourné en silence. Un design system qui trace chaque exception reste gouvernable.
Ce que la gouvernance ne couvre pas
Ce processus concerne exclusivement les classes globales, variables et composants visuels partagés. Il ne traite pas des questions d’hébergement mutualisé de ces douze boutiques, ni des choix d’infrastructure serveur qui restent un sujet distinct, à traiter indépendamment de la cohérence visuelle du réseau.
Notre verdict
La gouvernance d’un design system multi-boutiques fonctionne quand elle repose sur trois piliers : une source de vérité unique et non modifiable en production, un processus de validation qui ralentit délibérément la propagation, et un registre des exceptions qui rend visible ce qui, sinon, deviendrait une dérive silencieuse. Sans ces trois éléments, les classes globales d’Elementor restent un bon outil technique appliqué sans discipline collective, ce qui, à l’échelle de douze boutiques, revient au même problème que l’absence d’outil.
