Un même bloc « bandeau de témoignages clients » revient, à quelques détails près, sur cinq sites différents gérés par la même agence. Où ce pattern doit-il vivre : dans chaque thème individuellement, ou dans un emplacement partagé consultable depuis n’importe quel projet ? La réponse dépend moins d’une préférence technique que du nombre de sites réellement concernés et de leur degré de parenté visuelle.
Option 1 : le pattern vit dans le thème du projet
Un pattern déclaré directement dans le dossier patterns du thème, via un fichier PHP avec un en-tête de commentaire structuré (Title, Slug, Categories), reste la solution la plus simple pour un pattern spécifique à un seul site. Il hérite naturellement des styles globaux du thème, sans configuration supplémentaire, et sa maintenance suit celle du thème lui-même.
Cette approche devient limitante dès que le même pattern doit exister, presque à l’identique, sur plusieurs projets distincts : chaque copie du pattern évolue alors indépendamment, et une correction faite sur un site ne se propage jamais automatiquement vers les autres.
Option 2 : une extension dédiée aux patterns partagés
Une extension séparée, installée sur chaque site client qui en a besoin, peut enregistrer les mêmes patterns via register_block_pattern() côté PHP, indépendamment du thème actif. Ce découplage a un avantage direct : une mise à jour de l’extension propage la correction ou l’amélioration d’un pattern vers tous les sites qui l’utilisent, sans devoir toucher à chaque thème individuellement.
add_action( 'init', function () {
register_block_pattern(
'agence-patterns/bandeau-temoignages',
array(
'title' => __( 'Bandeau de témoignages', 'agence-patterns' ),
'categories' => array( 'temoignages' ),
'content' => file_get_contents( __DIR__ . '/patterns/bandeau-temoignages.html' ),
)
);
} );
La contrepartie de cette approche : le pattern ne peut plus s’appuyer implicitement sur les styles globaux d’un thème précis, puisqu’il doit fonctionner correctement sur plusieurs thèmes différents. Il faut donc l’écrire avec des blocs suffisamment sobres, qui héritent bien des variables de préréglages standards (couleurs et espacements nommés) plutôt que de valeurs figées pensées pour un seul thème.
Comparatif des deux approches
| Critère | Pattern dans le thème | Pattern dans une extension partagée |
|---|---|---|
| Propagation d’une correction | Manuelle, site par site | Automatique à la mise à jour de l’extension |
| Dépendance aux styles du thème | Forte, hérite naturellement | Faible, doit rester générique |
| Complexité de mise en place | Minimale | Nécessite une extension à maintenir |
| Adapté à | Un seul site, ou des sites très différents visuellement | Plusieurs sites proches, mise à jour groupée souhaitée |
Un entre-deux possible : catégories de patterns partagées
Sur un socle de sites qui partagent déjà une base commune (un thème parent décliné en plusieurs thèmes enfants, par exemple), les patterns peuvent rester déclarés dans le thème parent, hérité par chaque thème enfant du projet. Cette solution ne convient que si les sites concernés reposent effectivement sur cette architecture parent-enfant, ce qui n’est pas systématique dans une agence qui traite des projets aux origines variées.
Notre verdict
En dessous de deux ou trois sites partageant un même pattern, le dupliquer directement dans chaque thème reste plus simple à maintenir qu’une extension dédiée, dont la mise en place a elle-même un coût. Au-delà, et surtout si ces sites doivent recevoir des corrections groupées régulièrement, une extension séparée devient rentable : elle centralise la source de vérité du pattern et évite l’écart progressif entre des copies qui, sans ce garde-fou, finissent toujours par diverger.
La question qu’on se pose avant de choisir : si ce pattern doit changer demain, combien de sites faudra-t-il rouvrir un par un pour appliquer le changement ? La réponse tranche généralement le débat plus vite qu’un argument théorique.
Pour aller plus loin
Ce choix n’est pas figé définitivement : un pattern né dans un thème unique peut très bien être extrait plus tard vers une extension partagée, le jour où un second projet en a réellement besoin. Mieux vaut ce déplacement tardif qu’une architecture partagée mise en place par anticipation pour un seul site qui, finalement, restera seul.
