Trois thèmes développés en interne affichent le même bouton d’appel à l’action et la même carte de mise en avant, mais chacun vit dans son propre dossier, avec son propre balisage HTML et sa propre feuille de style. Changer un rayon de bordure ou un espacement suppose alors d’ouvrir trois répertoires, de repérer trois fichiers presque identiques, et de croiser les doigts pour ne rien oublier au passage.
Cette situation n’est pas rare dès qu’une agence maintient plusieurs projets classiques nés de la même base de travail. La solution ne consiste pas à fusionner les thèmes entre eux, ce qui casserait leur indépendance, mais à extraire les composants réellement partagés dans un emplacement neutre, chargé par les trois thèmes de la même manière.
Pourquoi le copier-coller entre thèmes finit toujours par coûter cher
Un composant dupliqué trois fois n’est jamais identique bien longtemps. Un correctif appliqué sur un projet, oublié sur les deux autres, une variable de couleur codée en dur ici, une classe CSS renommée là : au bout de quelques mois, les trois « mêmes » boutons ont des comportements légèrement différents, et personne ne sait plus lequel fait référence. Le risque n’est pas seulement esthétique : un bug de sécurité corrigé dans un seul fichier PHP reste actif dans les deux autres, sans que rien ne le signale.
Construire une bibliothèque de gabarits hors de wp-content/themes
La première étape consiste à sortir les composants partagés du dossier d’un thème particulier. Un emplacement pratique est un répertoire dédié, par exemple wp-content/agence-components/, versionné indépendamment dans son propre dépôt Git et installé sur chaque site comme une dépendance. Ce dossier contient les fichiers de gabarit (bouton, carte, encart de témoignage) ainsi qu’une feuille de style compilée, sans dépendre d’aucun thème en particulier.
Charger les composants partagés avec une fonction d’inclusion dédiée
get_template_part() et la fonction qu’elle appelle en interne, locate_template(), ne cherchent que dans le dossier du thème actif et, le cas échéant, dans celui de son thème parent : il n’existe pas de mécanisme du cœur pour leur faire regarder un dossier situé ailleurs dans wp-content. Plutôt que de détourner ces fonctions, la solution la plus fiable consiste à écrire une petite fonction d’inclusion dédiée, déclarée une seule fois dans le mu-plugin partagé :
// wp-content/mu-plugins/agence-composants-loader.php
function agence_composant( string $slug, array $args = [] ): void {
$chemin = WP_CONTENT_DIR . '/agence-components/' . $slug . '.php';
if ( file_exists( $chemin ) ) {
include $chemin;
}
}
Chaque thème appelle ensuite agence_composant( 'carte', [ 'titre' => ..., 'url' => ... ] ) à la place de get_template_part(). Le tableau $args est disponible tel quel dans le fichier inclus, exactement comme avec l’argument ajouté à get_template_part() depuis WordPress 5.5, mais sans dépendre de la résolution de chemin propre au thème actif. Aucun des trois thèmes n’a besoin de copier le fichier carte.php : il est chargé une seule fois, depuis un seul emplacement.
Gérer les variantes sans multiplier les fichiers
Un bouton « plein » et un bouton « contour » ne justifient pas deux fichiers distincts. Le gabarit partagé accepte un argument variante, et applique la classe CSS correspondante :
<?php
$variante = $args['variante'] ?? 'plein';
?>
<a class="btn btn--<?php echo esc_attr( $variante ); ?>" href="<?php echo esc_url( $args['url'] ); ?>">
<?php echo esc_html( $args['label'] ); ?>
</a>
Cette approche limite la bibliothèque à un nombre restreint de fichiers, chacun couvrant plusieurs cas d’usage par ses arguments plutôt que par sa duplication.
Verrouiller le chargement avec un mu-plugin
Pour que la fonction agence_composant() soit disponible avant même l’exécution de functions.php d’un thème, il est préférable de la déclarer dans un must-use plugin, placé dans wp-content/mu-plugins/. Ce dossier est chargé automatiquement par WordPress, sans activation manuelle, et garantit que les trois thèmes bénéficient exactement du même comportement, sans risque d’oubli lors d’une nouvelle installation.
Une bibliothèque de composants qui dépend d’une activation manuelle finira, tôt ou tard, par ne pas être activée sur un site. Ce qui doit toujours être là appartient à un mu-plugin, pas à un thème.
Une arborescence type pour trois thèmes et une bibliothèque
Voici l’organisation qui en résulte sur le serveur, une fois la bibliothèque extraite :
wp-content/
├── mu-plugins/
│ └── agence-composants-loader.php
├── agence-components/
│ ├── carte.php
│ ├── bouton.php
│ └── style.css
└── themes/
├── theme-vitrine-a/
├── theme-vitrine-b/
└── theme-vitrine-c/
Chaque thème conserve son style.css, ses templates de page et ses spécificités, mais aucun ne possède sa propre copie du bouton ou de la carte.
En résumé
Mutualiser des composants entre plusieurs thèmes classiques ne demande ni migration vers l’éditeur de site, ni changement d’organisation profonde : un dossier partagé, une fonction d’inclusion déclarée depuis un mu-plugin, et des gabarits qui reçoivent un tableau d’arguments suffisent à faire disparaître le copier-coller. Le gain se mesure directement au moment du prochain correctif : une seule modification, appliquée aux trois projets à la fois.
