Décider de nommer

La compétence la plus rare, et celle qu'aucune documentation n'enseigne : savoir ne pas créer une classe.

La règle de trois

Empruntée au refactoring logiciel, elle s'applique parfaitement au CSS :

L'arbre de décision complet

Avant de créer une classe, pose-toi ces questions dans cet ordre :

Le test du nouveau venu

Le meilleur juge de la qualité d'un nom : un développeur qui découvre le projet.

Peut-il, en lisant uniquement la liste des classes, sans ouvrir une seule page, deviner à quoi ressemble le site ? Si oui, ta nomenclature est bonne. Si les noms sont .box-2, .custom-thing, .section-new, il ne peut rien deviner — et toi non plus, dans six mois.

Conventions d'écriture

Les règles ennuyeuses. Ce sont exactement celles qui font diverger un projet quand on ne les fixe pas au départ.

1. La langue : anglais, toujours

Ton interface peut être en français. Tes noms de classes, non. C'est du code.

2. La casse : kebab-case, uniquement

3. Les séparateurs BEM

.c-card              ← le bloc
.c-card__title       ← un élément (double underscore)
.c-card--featured    ← une variation (double tiret)
.c-card__title--big  ← une variation d'élément

/* JAMAIS de chaînage d'éléments */
.c-card__body__title   ✗  ← le DOM peut changer, ce nom casse
.c-card__title         ✓  ← plat, robuste

4. Les abréviations autorisées

Une abréviation n'est acceptable que si elle est universellement comprise. Dans le doute, écris le mot en entier.

5. Singulier ou pluriel ?

Règle simple : l'objet est au singulier, la collection au pluriel.

.c-card       ← un objet carte
.l-cards      ← la grille qui contient plusieurs cartes
.c-nav-item   ← un item de navigation
.c-nav        ← la navigation entière

6. Ordre des mots : du général au spécifique

c- Composant

Un objet autonome, auto-contenu, qui fonctionne indépendamment de son environnement.

Le test du composant

Une classe mérite le préfixe c- si elle passe ce test : « puis-je découper cet élément, le coller ailleurs sur le site, et attendre qu'il fonctionne et reste beau ? »

Si oui → composant. Si non (il dépend de son parent pour sa largeur, son alignement, sa position) → ce n'est pas un composant, c'est du layout ou un élément enfant.

Exemples canoniques

Anatomie BEM d'un composant

<article class="c-card c-card--featured">
  <img class="c-card__img" src="...">
  <h3 class="c-card__title">Titre</h3>
  <p class="c-card__text">Description</p>
  <a class="c-btn c-btn--secondary">Lire plus</a>
</article>

Le composant ne se positionne pas lui-même

.c-card {
  margin-bottom: 2rem;
  width: 300px;
  float: left;
}

.c-card {
  padding: 1.5rem;
  border-radius: 8px;
  background: var(--color-surface);
}
/* le parent gère le reste */
.l-grid { gap: 2rem; }

l- Layout

La structure invisible qui organise l'espace. Elle ne se voit pas — elle se ressent.

Ce qu'un layout gère (et rien d'autre)

Exemples canoniques

Les trois layouts qui couvrent 90% des besoins

/* 1. STACK — empiler verticalement (le plus utilisé) */
.l-stack {
  display: flex;
  flex-direction: column;
  gap: var(--space-4);
}

/* 2. CLUSTER — aligner horizontalement, avec retour à la ligne */
.l-cluster {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-3);
  align-items: center;
}

/* 3. GRID — répartir en colonnes égales */
.l-grid {
  display: grid;
  gap: var(--space-6);
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
}

Le layout dans Elementor v4

Le Flexbox Container d'Elementor est ta classe layout. Il expose nativement direction, gap, alignement, padding — exactement le domaine du l-.

u- Utilitaire

Une classe, une propriété, une responsabilité. Puissant — et dangereux si mal dosé.

La définition stricte

Un utilitaire fait une seule chose, ne dépend de rien, et fonctionne partout. S'il fait deux choses, ce n'est plus un utilitaire, c'est un mini-composant mal nommé.

/* ✓ Utilitaires — une propriété chacun */
.u-text-center { text-align: center; }
.u-hidden      { display: none; }
.u-mb-4        { margin-bottom: var(--space-4); }

/* ✗ Ce n'est plus un utilitaire */
.u-fancy-box {
  padding: 1rem;
  border: 1px solid;
  border-radius: 8px;
  background: white;
}   ← ça, c'est un composant. Appelle-le .c-box.

Le grand danger : le style inline déguisé

<div class="u-p-4 u-mb-6 u-bg-white
  u-rounded u-shadow u-border
  u-flex u-flex-col u-gap-3">

<div class="c-card">

/* et une seule fois : */
.c-card {
  padding: var(--space-4);
  /* ...etc */
}

Le seuil de bascule

Quand l'utilitaire est le bon choix

• Une exception ponctuelle — ce titre-là, et seulement lui, est centré.
• Un ajustement qui ne mérite pas un composant — masquer un élément sur mobile.
• Une composition rapide en phase de prototypage — tu explores, tu nommeras plus tard.

Dans tous les autres cas, demande-toi si le composant ne devrait pas porter ce style lui-même.

is- / has- États

La famille oubliée — et pourtant indispensable dès qu'il y a un menu, un accordéon ou un formulaire.

Variation ≠ état

C'est la distinction la plus mal comprise de tout BEM. Elle est pourtant simple :

La convention

/* is- : l'élément EST dans cet état */
.is-active     ← onglet sélectionné, lien de nav courant
.is-open       ← menu déplié, accordéon ouvert
.is-hidden     ← masqué dynamiquement
.is-loading    ← en attente d'une réponse
.is-disabled   ← non cliquable

/* has- : l'élément CONTIENT quelque chose */
.has-error     ← un champ dont la validation a échoué
.has-children  ← un item de menu avec un sous-menu
.has-icon      ← un bouton qui contient une icône

L'état est un modificateur global, pas un préfixe de bloc

En CSS

/* On scope l'état au composant, pour éviter les collisions */
.c-menu.is-open {
  max-height: 500px;
  opacity: 1;
}

.c-input.has-error {
  border-color: var(--color-danger);
}

.c-btn.is-loading {
  pointer-events: none;
  opacity: 0.6;
}

Gap, margin, padding

Le sujet qui gâche le plus de sites. Trois outils, une hiérarchie stricte.

1. Les trois outils

2. La hiérarchie de décision

3. Pourquoi le gap a gagné

.c-card { margin-bottom: 2rem; }
.c-card:last-child {
  margin-bottom: 0;  /* la rustine */
}

.l-grid {
  display: grid;
  gap: 2rem;
}

4. L'échelle d'espacement

Aucune valeur au hasard. Une échelle unique, et chaque espacement pointe vers un cran.

5. Et les classes u- d'espacement ?

Nomenclature, si tu en crées malgré tout :

.u-p-4    padding sur les 4 côtés
.u-pt-4   padding-top      .u-pb-4  padding-bottom
.u-px-4   padding horizontal (left + right)
.u-py-4   padding vertical (top + bottom)

.u-m-4    margin sur les 4 côtés
.u-mt-4   margin-top       .u-mb-4  margin-bottom
.u-mx-auto  centrage horizontal d'un bloc à largeur fixe

.u-gap-4    gap uniforme
.u-gap-x-4  column-gap     .u-gap-y-4  row-gap

Typographie

La même logique d'échelle, appliquée au texte — avec les raisons UX derrière chaque valeur.

1. Taille de texte

2. Graisse

3. Hauteur de ligne — la règle inversée

4. Espacement des lettres

5. La typographie fluide (clamp)

Pour les titres, oublie les tailles fixes par breakpoint. Un titre doit grandir continûment avec l'écran, pas par sauts brutaux.

/* Un H1 qui passe de 32px (mobile) à 56px (desktop),
   de façon fluide, sans une seule media query */
--font-size-h1: clamp(2rem, 1.2rem + 3.5vw, 3.5rem);

6. Hiérarchie de titres : pas des classes u-

Cascade & spécificité

« Pourquoi ma classe ne s'applique pas ?! » — la frustration n°1, et sa résolution définitive.

1. L'ordre de priorité (du plus faible au plus fort)

La lecture du « poids » : on compare de gauche à droite. Un seul ID bat n'importe quel nombre de classes. C'est pour ça qu'on évite les ID en CSS — ils sont impossibles à surcharger proprement.

2. À égalité, le dernier gagne

.c-btn { background: blue; }
.c-btn { background: green; }   ← c'est celle-ci qui s'applique

Deux règles de même spécificité ? Celle qui arrive plus bas dans la feuille de style l'emporte. D'où l'importance de l'ordre de chargement de tes fichiers CSS.

3. Le cas Elementor v4

C'est là que ça devient concret. Dans Elementor v4, plusieurs sources de style cohabitent sur un même élément :

4. !important : le symptôme, pas la solution

Quand tu écris !important, tu ne résous pas un problème de style. Tu résous un problème d'architecture — mal.

.c-btn {
  background: red !important;
}

5. Règle d'or : garde la spécificité basse et plate

Anti-patterns

Ce qui trahit un débutant. On apprend plus vite de ce qui casse que de ce qui marche.

Cas pratique commenté

Une section réelle, du brief au code — avec chaque décision expliquée à voix haute. Les taxonomies s'oublient ; un raisonnement se retient.

Étape 1 — Je résiste à l'envie de nommer

Premier réflexe du débutant : ouvrir le Class Manager et créer .services-section, .services-title, .services-grid, .service-card… Stop.

Question : cette section « Nos services » existe-t-elle ailleurs sur le site ? Non, elle est unique à la page d'accueil.

Décision : je ne crée aucune classe spécifique à « services ». Une classe utilisée une fois est un coût sans contrepartie. Je vais chercher les motifs génériques qui se cachent derrière.

Étape 2 — Je cherche les motifs réutilisables

Je regarde la maquette et je me demande : qu'est-ce que je reverrai ailleurs sur ce site ?

• Une bande horizontale avec du padding vertical → je la reverrai sur chaque section. C'est l-section.
• Une grille de cartes qui s'empile en mobile → je la reverrai (portfolio, témoignages, articles). C'est l-grid.
• Une carte avec icône, titre, texte, lien → oui, c'est le motif le plus réutilisable de tous. C'est c-card.
• Un lien stylé en bouton → partout. C'est c-btn.

Étape 3 — Le titre et le chapô : je ne nomme rien

Question : ai-je besoin d'une classe .c-section-title ?

Réponse : non. Un H2 est un H2. Sa taille, sa graisse et sa couleur sont déjà définies dans les Réglages du site → Typographie d'Elementor. Créer une classe pour ça, ce serait doubler une fonctionnalité native — l'anti-pattern n°8.

Le chapô, lui, est un paragraphe légèrement plus grand que le corps. Une exception ponctuelle → une classe utilitaire suffit : .u-text-lg. Pas de composant.

Étape 4 — L'espacement : je ne pose aucune marge

Le piège : mettre margin-bottom: 2rem sur le titre, puis sur le chapô, puis sur chaque carte.

Ce que je fais à la place : le container de la section est un l-stack avec un gap. Il espace automatiquement le titre, le chapô et la grille. La grille, elle, a son propre gap entre les cartes.

Résultat : zéro marge dans tout le bloc. Deux valeurs de gap, posées sur deux parents. Si le client trouve que « ça manque d'air », je change une valeur.

Étape 5 — La carte mise en avant : variation, pas nouveau composant

Question : est-ce que je crée .c-featured-card ?

Non. C'est la même carte, avec un fond différent. Ce n'est pas un autre objet, c'est une sorte de carte. Donc : une variation BEM → .c-card--featured.

Et si le client veut plus tard la mettre en avant dynamiquement au survol ? Là, ce serait un état → .is-highlighted. La distinction : la variation est décidée au design, l'état survient à l'exécution.

Le résultat

<section class="l-section">
  <div class="l-container l-stack">

    <h2>Nos services</h2>
    <p class="u-text-lg">Une phrase d'introduction.</p>

    <div class="l-grid">

      <article class="c-card">
        <div class="c-card__icon">...</div>
        <h3 class="c-card__title">Design</h3>
        <p class="c-card__text">Description.</p>
        <a class="c-btn c-btn--ghost">En savoir plus</a>
      </article>

      <article class="c-card c-card--featured">
        ... même structure ...
      </article>

      <article class="c-card">
        ... même structure ...
      </article>

    </div>
  </div>
</section>

Le bilan

Aucune classe ne mentionne « services ». J'ai construit une section unique avec un vocabulaire entièrement générique. C'est la marque d'un design system qui tient.

Fondements UX

Pourquoi les échelles ne sont pas des chiffres au hasard. Chaque valeur répond à une contrainte de perception humaine.

1. Longueur de ligne : 60 à 75 caractères

Au-delà de ~75 caractères par ligne, l'œil peine à retrouver le début de la ligne suivante. En dessous de ~45, le rythme de lecture est haché par les retours à la ligne trop fréquents.

/* La façon la plus simple de respecter ça */
.l-prose {
  max-width: 65ch;   /* 65 caractères, littéralement */
}

Conséquence sur ta nomenclature : un l-container à 1200px, c'est bien pour une grille de cartes. C'est beaucoup trop large pour un article. D'où l'intérêt d'un layout dédié au texte long.

2. Zone tactile : 44 × 44 px minimum

C'est la taille moyenne de la pulpe d'un doigt. En dessous, le taux d'erreur de tap grimpe en flèche. Un bouton de 30px de haut sur mobile est un bouton qu'on rate.

.c-btn-icon {
  width: 44px;
  height: 44px;      /* la zone tactile */
  display: flex;
  align-items: center;
  justify-content: center;
}
.c-btn-icon svg {
  width: 20px;       /* l'icône visible */
}

3. Contraste : 4.5:1 minimum

Conséquence sur tes tokens : le gris clair « élégant » à #aaa sur fond blanc donne un ratio de 2.3:1. Il est illisible pour une partie de tes utilisateurs. Un token --color-text-muted doit être testé, pas choisi à l'œil.

4. La hiérarchie visuelle a besoin d'écarts francs

Un H2 à 20px et un corps à 18px : l'œil ne perçoit pas la différence. La hiérarchie n'existe pas.

5. La loi de proximité (Gestalt)

Deux éléments proches sont perçus comme liés. Deux éléments éloignés, comme séparés. C'est automatique et pré-conscient.

La conséquence, terriblement fréquente : un titre de section qui a autant d'espace au-dessus qu'en dessous. L'œil ne sait plus s'il appartient au bloc précédent ou au suivant.

Conséquence sur ta nomenclature : ton échelle d'espacement doit avoir assez de crans pour exprimer cette asymétrie. C'est aussi pourquoi le gap uniforme d'un l-stack ne suffit pas toujours — parfois, un titre a besoin de sa propre relation d'espacement avec ce qui suit.

6. La cohérence bat l'optimalité

C'est la justification profonde de tout ce document : la nomenclature et les échelles ne servent pas à trouver la valeur parfaite. Elles servent à garantir que tu réutilises la même valeur.

Cycle de vie

Un design system n'est pas figé. Sans règles d'entretien, il pourrit en 18 mois.

1. Le symptôme d'un système qui pourrit

• Des classes que personne n'ose supprimer « au cas où »
• Des noms qui ne veulent plus rien dire (.c-card-new, deux ans plus tard)
• Deux classes qui font la même chose avec des noms différents
• Des !important qui s'accumulent pour contourner l'existant
• Un nouveau venu qui préfère créer une classe plutôt que chercher si elle existe

2. Auditer : les classes orphelines

Le Class Manager d'Elementor v4 affiche le nombre d'utilisations de chaque classe — et où. Sers-t'en.

Rythme recommandé : un audit à chaque fin de projet, avant la livraison. C'est le seul moment où tu as encore tout le contexte en tête.

3. Renommer une classe utilisée 40 fois

Ça arrive : tu as nommé .c-btn-blue au début du projet, tu as compris ton erreur. Comment corriger sans tout casser ?

4. Déprécier plutôt que supprimer brutalement

Sur un projet livré à un client qui édite lui-même ses pages, une suppression brutale peut casser une page que tu n'as pas vue. Marque d'abord, supprime ensuite :

/* DÉPRÉCIÉ — remplacé par .c-btn--primary
   À supprimer après migration complète (audit prévu : mars) */
.c-btn-blue { ... }

5. La règle du « ajouter coûte plus cher que réutiliser »

6. Le kit qui voyage entre projets

C'est le cœur de la reproductibilité : ta nomenclature (c-btn, c-card, l-section, l'échelle d'espacement) reste identique d'un client à l'autre. Seules les valeurs changent — la couleur primaire, la police, éventuellement le rythme d'espacement.

Elementor v4 permet d'exporter et réimporter une collection complète de classes et variables. Concrètement, ton point de départ sur un nouveau projet n'est jamais une page blanche : c'est ton kit, dont tu échanges les valeurs de marque.

Dans Elementor v4

Où poser chaque brique, concrètement, dans l'interface.

Le bon outil pour chaque décision

La règle qui évite le chaos

Pourquoi le CSS-first change tout

En v4, le style d'un élément est porté par des classes globales réutilisables plutôt que par des réglages isolés sur chaque widget. Conséquences directes :

• Moins de styles inline → pages plus légères, meilleure performance
• Une modification se propage → tu changes la classe, tout le site suit
• Le Class Manager sait où chaque classe est utilisée → tu ne modifies plus à l'aveugle

Containers Flexbox : le socle

Les Containers génèrent un DOM nettement plus léger que l'ancien système Section → Column (2 niveaux au lieu de 4), et exposent nativement le gap. Pour tout nouveau projet : Containers, sans hésiter.

Checklist de démarrage projet

1. Importe ton kit de classes et variables du projet précédent
2. Change uniquement les valeurs de marque (couleurs, police) dans le Variables Manager
3. Définis la hiérarchie typographique dans les Réglages du site
4. Construis avec les Containers, en utilisant le gap natif
5. Ne crée une nouvelle classe que si un motif se répète 3 fois
6. Avant livraison : audite les orphelines dans le Class Manager

Et Figma dans tout ça ?

Une fois cette nomenclature stable côté Elementor, le passage à Figma est presque mécanique :

• Tes variables Figma portent les mêmes noms que tes variables Elementor
• Tes composants Figma portent les mêmes noms que tes classes c-
• Ton auto-layout Figma utilise les mêmes crans d'espacement

Glossaire

Tout le vocabulaire de ce document, en français simple.

Nomenclature

CSS

Elementor v4

UX