Le principe, en un exemple

0. .cms-content :where(h1..h6) sémantique confirmée

Tout titre inséré via le WYSIWYG dans une page ou un bloc CMS (comme cette page-ci) hérite automatiquement d'une taille, d'un poids et d'une couleur cohérents — sans que tu aies besoin d'ajouter la moindre classe.

Exemple de <h1>

Exemple de <h2>

Exemple de <h3>

Ce mécanisme ne couvre que le contenu CMS — voir la section 5 ci-dessous pour ce qui se passe sur les autres pages du site (catégorie, produit, panier, compte).

1. .btn / .btn-primary / .btn-secondary sémantique confirmée

Ce sont les vraies classes du thème — le rendu ci-dessous est exactement celui du site aujourd'hui.

Changer les variables --btn-bg / --btn-hover-bg / --btn-active-bg dans .btn-primary changerait aussi : "Continuer vos achats", "Créer un compte", "Inscription", et tout autre bouton utilisant cette classe.

2. .pagebuilder-button-primary / -secondary sémantique confirmée

Boutons créés via l'éditeur visuel de contenu Magento (Page Builder — bannières, pages riches). Vérification faite en direct sur le site : ils affichent aujourd'hui exactement les mêmes couleurs que .btn-primary/.btn-secondary — mais via une règle CSS totalement séparée qui duplique ces valeurs. Concrètement : changer .btn-primary ne changera pas ces boutons-ci, même s'ils se ressemblent aujourd'hui — il faudra mettre à jour les deux règles séparément.

À transmettre à Matias en même temps que .btn-primary : comme les deux règles sont dupliquées plutôt que liées, l'orange devra être appliqué ici aussi, séparément — sinon les boutons créés via l'éditeur visuel resteront bleus après le changement des boutons classiques.

3. .message.success/.error/.info/.warning sémantique confirmée

Bandeaux de notification (ex. "produit ajouté au panier", erreur de formulaire). Rendu réel ci-dessous.

Ces couleurs (rouge/vert/bleu/ambre) suivent un code couleur universel — généralement on ne les remplace pas par les couleurs de marque, pour ne pas perdre leur sens immédiat pour le client.

4. .card-interactive sémantique confirmée (mineure)

Contrôle uniquement l'effet au survol des cartes cliquables (ex. cartes "avantages" sur la home). Survolez le bloc ci-dessous :

5. .page-title pas sémantique — malgré les apparences

Vérifié en direct sur le vrai site, page par page. .page-title est la classe du titre principal (<h1>) sur toutes les pages du thème — catégorie, produit, panier, compte. Pourtant son rendu change d'une page à l'autre. La raison : .page-title elle-même ne définit aucune couleur. Le bleu qu'on voit parfois vient d'une classe utilitaire text-cd_blue ajoutée à la main sur certains templates seulement (la fiche produit) — pas d'un mécanisme centralisé.

Conclusion : il n'existe aujourd'hui aucune classe qui gouverne "tous les titres du thème" — seulement une qui gouverne "tous les titres à l'intérieur d'un contenu CMS". Pour une vraie cohérence partout (catégorie, produit, panier, compte inclus), il faudrait que Matias fasse porter la couleur par .page-title elle-même (et par une classe de sous-titre commune), plutôt que de la répéter au cas par cas selon les templates comme c'est fait actuellement.

Classes qui n'existent pas encore comme sémantiques — mais qui pourraient l'être

Ces éléments existent visuellement sur le site, mais leur couleur est aujourd'hui répétée avec des classes utilitaires ponctuelles à chaque endroit du code, plutôt que centralisée. Les exemples ci-dessous sont des propositions — pas le code réel du site.

Prix barré / prix promo

Aujourd'hui, si le orange promo doit changer, il faut le retrouver dans chaque fichier .phtml qui affiche un prix. Une classe .price-special centralisée éviterait ça.

Badges de stock

Aucune classe centralisée trouvée pour ces indicateurs — à ce jour ce sont probablement des classes Tailwind ponctuelles dans le code des pages catégorie/produit.

Récapitulatif