# Personnaliser les classes globales de couleur et typographie d’une page produit

> Une page produit qui respecte enfin la charte graphique du client, sans surcharge CSS bricolée : la démarche complète avec les classes globales de theme.json.

- Auteur : Clément Hadrot
- Publié le : 2026-08-18
- Mis à jour le : 2026-08-18
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/personnaliser-classes-globales-couleur-typographie-page-produit/

## L’essentiel

- Les classes globales évitent la surcharge CSS ad hoc sur chaque bloc
- Une variable de couleur mal nommée casse la cohérence entre thème et boutique
- Le bloc produit hérite des styles globaux, mais pas toujours comme on l'attend

Le client, une marque de cosmétiques vendant en ligne, avait une charte graphique précise — une palette de trois couleurs et deux typographies bien définies — mais sa page produit WooCommerce continuait d'afficher les couleurs par défaut du thème, en décalage complet avec le reste du site construit à partir de blocs. Plutôt que d'ajouter une surcharge CSS spécifique à chaque bloc du gabarit produit, ce qui aurait créé une dette de maintenance à chaque mise à jour de thème, la démarche retenue s'est appuyée entièrement sur les classes globales définies dans `theme.json`. Ce tutoriel ne couvre pas l'éditeur V4 d'Elementor, hors périmètre ici puisque le projet reposait sur un thème de blocs natif WordPress.

## Étape 1 : cartographier les couleurs existantes du thème

Avant de modifier quoi que ce soit, il faut identifier les palettes déjà déclarées par le thème actif dans son propre `theme.json`, généralement visibles dans la section `settings.color.palette`. Un thème de blocs bien construit expose ses couleurs sous forme de variables nommées (`--wp--preset--color--nom-couleur`), que l'éditeur de site propose ensuite dans son sélecteur de couleurs sous forme de pastilles nommées.

## Étape 2 : étendre la palette via un theme.json enfant

Plutôt que de modifier directement le thème parent, ce qui serait écrasé à la moindre mise à jour, la palette du client a été ajoutée dans le `theme.json` d'un thème enfant, en complément des couleurs existantes plutôt qu'en remplacement complet, pour ne pas casser d'éventuels blocs déjà configurés ailleurs sur le site avec les couleurs d'origine.

```
{
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        {
          "slug": "rose-signature",
          "color": "#c9435a",
          "name": "Rose signature"
        },
        {
          "slug": "vert-sauge",
          "color": "#7a8f6e",
          "name": "Vert sauge"
        }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "slug": "titre-marque",
          "fontFamily": "\"Fraunces\", serif",
          "name": "Titre de marque"
        }
      ]
    }
  }
}
```

> L'essentiel à retenir : Les classes globales évitent la surcharge CSS ad hoc sur chaque bloc ; Une variable de couleur mal nommée casse la cohérence entre thème et boutique ; Le bloc produit hérite des styles globaux, mais pas toujours comme on l'attend

## Étape 3 : créer les classes globales dérivées

Chaque couleur et typographie déclarée dans `theme.json` génère automatiquement des classes utilitaires exploitables directement dans le HTML des blocs, sans écrire une seule ligne de CSS personnalisée : `has-rose-signature-color`, `has-rose-signature-background-color`, `has-titre-marque-font-family`. C'est ce mécanisme, natif à WordPress depuis l'arrivée de theme.json, qui a permis d'appliquer la charte graphique directement depuis l'interface de l'éditeur de site, bloc par bloc, sans code additionnel.

## Étape 4 : appliquer les classes au gabarit de la page produit

Le gabarit de page produit WooCommerce, lorsqu'il est construit avec les blocs WooCommerce natifs (Titre du produit, Prix du produit, Galerie du produit), reste modifiable depuis l'éditeur de site comme n'importe quel autre gabarit de blocs. Chaque bloc de titre a reçu la classe de typographie de marque via le panneau de style de l'éditeur, chaque bouton d'ajout au panier a reçu la couleur de fond correspondant à la palette du client, directement depuis les contrôles visuels de l'éditeur, sans toucher au code du thème parent.

### Le piège des blocs WooCommerce qui n'héritent pas tout

Un point a surpris l'équipe en cours de projet : certains blocs WooCommerce, notamment ceux liés au prix barré en cas de promotion, appliquent leurs propres styles par défaut via une feuille de style embarquée par l'extension, qui peut entrer en conflit de spécificité CSS avec les classes globales issues de `theme.json`. Il a fallu, dans ce cas précis, ajouter une règle CSS ciblée dans les styles additionnels du thème, en s'appuyant toujours sur la variable de couleur globale plutôt que sur une valeur hexadécimale codée en dur, pour que la couleur reste centralisée même dans ce cas particulier.

```
.wc-block-components-product-price del {
    color: var(--wp--preset--color--vert-sauge);
}
```

## Ce que cette approche évite

- Une multiplication de règles CSS ad hoc dispersées dans un fichier de styles additionnels difficile à maintenir dans le temps.
- Une couleur codée en dur à plusieurs endroits différents, qui obligerait à modifier chaque occurrence manuellement le jour où la charte graphique évolue.
- Une incohérence visuelle entre les pages de contenu classique du site, déjà construites avec les classes globales, et la page produit qui serait restée à l'écart de ce système.

> Le jour où le client change une seule couleur de sa charte, la modification tient en une ligne dans `theme.json`. C'est ce test, plus que n'importe quelle démonstration visuelle, qui convainc qu'une architecture de style est bien pensée.

## En résumé

Personnaliser une page produit WooCommerce pour qu'elle respecte une charte graphique précise ne demande pas de surcharge CSS extensive dès lors que le thème s'appuie sur `theme.json` et ses classes globales : étendre la palette et la typographie dans un thème enfant, appliquer les classes via l'éditeur de site, et ne recourir à du CSS ciblé qu'en dernier recours pour les blocs qui n'héritent pas correctement du système global. Cette discipline garantit une charte graphique centralisée en un seul endroit, modifiable sans jamais toucher au gabarit lui-même.