Douze tokens de couleur, trois marques, un seul thème parent : c’est la configuration qui revient dès qu’une agence gère plusieurs identités visuelles proches, nées de la même maison mère mais tenues à des chartes graphiques distinctes. Dupliquer le thème trois fois semble la solution la plus rapide sur le moment. Elle devient, en pratique, la source la plus fréquente de régressions silencieuses : un correctif appliqué sur une marque, oublié sur les deux autres, découvert des mois plus tard par un client qui compare deux sites côte à côte.
La question n’est pas de savoir si theme.json d’un thème bloc résoudrait le problème autrement : ce chantier concerne des thèmes classiques, où les couleurs de marque vivent dans le Customizer, dans des variables SCSS compilées, ou dans des constantes PHP. L’enjeu est de structurer ces trois sources pour qu’une seule reste responsable de chaque couleur.
Le principe : un thème parent neutre, des enfants qui ne portent que leurs tokens
Le thème parent contient toute la structure : gabarits, requêtes, mise en page, classes CSS génériques. Il ne déclare aucune couleur de marque en dur. Chaque thème enfant se limite à un fichier qui définit ses tokens propres, sous forme de variables CSS personnalisées injectées dans le <head> via wp_head, ou de variables SCSS compilées séparément pour chaque marque.
- Le thème parent référence toujours des noms de tokens (
--marque-primaire,--marque-accent), jamais de valeurs hexadécimales. - Chaque enfant fournit sa propre feuille de valeurs, sans toucher au reste du code.
- Un correctif de structure profite instantanément aux trois marques, sans recopie manuelle.
L’arborescence qui matérialise cette séparation
Concrètement, le dépôt du projet prend la forme suivante, avec un thème parent générique et trois enfants minces :
theme-parent/
├── style.css
├── functions.php
├── inc/
│ └── tokens-defaut.php (valeurs de secours si un enfant est incomplet)
└── templates/
theme-marque-alpha/
├── style.css (Template: theme-parent)
├── functions.php (déclare les 12 tokens de la marque Alpha)
└── assets/tokens-alpha.css
theme-marque-beta/
├── style.css (Template: theme-parent)
├── functions.php (déclare les 12 tokens de la marque Beta)
└── assets/tokens-beta.css
La déclaration des tokens côté enfant
Chaque thème enfant enregistre sa feuille de tokens via wp_enqueue_style, après la feuille du parent, pour que la cascade CSS s’applique naturellement sans surcharge complexe :
<?php
// theme-marque-alpha/functions.php
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_style(
'marque-alpha-tokens',
get_stylesheet_directory_uri() . '/assets/tokens-alpha.css',
array( 'theme-parent-style' ),
wp_get_theme()->get( 'Version' )
);
} );
Le fichier tokens-alpha.css ne contient que des déclarations de variables sur :root, jamais de règles de mise en page. Cette contrainte, tenue strictement, est ce qui garantit qu’aucune couleur ne se retrouve codée en dur dans un gabarit du parent.
Le garde-fou : des valeurs par défaut dans le thème parent
Un thème enfant incomplet, livré avant que toutes ses couleurs soient validées par le client, ne doit jamais produire un site sans couleur du tout. Le fichier inc/tokens-defaut.php du parent déclare donc des valeurs de secours neutres, chargées en premier, que chaque enfant vient simplement surcharger.
- Le parent définit des gris neutres comme filet de sécurité.
- Chaque enfant surcharge uniquement ce qui le concerne.
- Un token oublié par un enfant reste visible, sous une forme neutre, plutôt que de casser l’affichage.
Le jour où un enfant déclare une couleur qui n’existe pas dans la liste des douze tokens documentés, c’est le signe qu’une marque a besoin d’un token supplémentaire pour toutes les autres, pas d’une exception locale.
La documentation, seule garantie sur la durée
Sans document de référence listant les douze tokens, leur usage et un aperçu visuel par marque, l’architecture la plus propre finit par se dégrader dès qu’une nouvelle personne reprend le projet. Un tableau simple, tenu à jour dans le dépôt, associant chaque nom de token à sa fonction (fond, texte, accent, état de survol) évite que deux développeurs inventent chacun leur propre variable pour le même usage.
Ce qu’il faut retenir
Séparer structure et marque n’est pas un exercice de style : c’est ce qui permet de corriger un bug d’affichage une seule fois pour trois sites, et d’ajouter une quatrième marque sœur sans dupliquer un thème entier. Le signal qui doit alerter une agence est simple : dès qu’une couleur apparaît en valeur hexadécimale dans un gabarit partagé plutôt que sous forme de token, la séparation a déjà commencé à se fissurer.
