Elementor V4 – Comment construire un vrai design token ?

Pourquoi les simples réglages globaux ne suffisent plus ?

Pendant longtemps, beaucoup de sites Elementor ont été montés comme ça :

• une couleur principale ;
• une couleur secondaire ;
• deux polices ;
• et ensuite, des ajustements au fil des besoins.

Ça fonctionne. Jusqu’au moment où le site grossit.

• Tu ajoutes une page service.
• Puis une landing page.
• Puis une page tarifs.
• Puis un bloc témoignage sur une page qui n’en avait pas.
• Puis un nouveau CTA parce que “ce serait bien d’en tester un autre”.
• Et là, les écarts commencent.

Par exemple :

• le bouton principal fait 16 px sur une page, puis 15 px ailleurs ;
• l’espace entre deux sections fait 80 px ici, puis 72 px là-bas ;
• la couleur de fond d’une carte est #F7F8FA sur une page, et #F6F7F9 sur une autre, ce qui ne choque personne… sauf quand tout s’accumule ;
• le titre H2 a une taille cohérente dans les pages services, mais pas dans les pages construites plus tard.

Le souci n’est pas que ces choix soient “mauvais”. Le souci, c’est qu’ils s’additionnent.

Un design token, justement, sert à éviter ça. Ce n’est pas juste une valeur enregistrée quelque part. C’est une valeur nommée, qui décrit un usage clair.

Au lieu d’avoir :

• #1E3A8A
• 32px
• Inter 16px
• 12px radius

tu peux avoir :

• color-brand-primary
• space-section-m
• text-body-size
• radius-card

Tout de suite, c’est plus lisible. Et surtout, ça tient mieux quand le site bouge.

Si tu veux élargir ce sujet à l’échelle de tout le site, tu peux prolonger avec ce contenu sur le design system Elementor V4, qui montre comment garder une base plus cohérente quand Elementor commence à prendre de l’ampleur.

Ce qu’Elementor V4 change vraiment

L’intérêt d’Elementor V4, ce n’est pas juste un nouveau vernis sur l’éditeur. C’est que le style est pensé de manière plus centralisée.

En simplifiant :

• une variable stocke une valeur ;
• une classe applique un ensemble de styles ;
• un component permet de réutiliser un bloc complet.

Dit autrement :

• la variable répond à “quelle valeur j’utilise ?” ;
• la classe répond à “où et comment je l’applique ?” ;
• le component répond à “quel bloc je réutilise tel quel ?”.

Exemple très simple.

Tu peux créer une variable pour ta couleur principale :

color-brand-primary

Puis une autre pour le texte sur fond foncé :

color-text-on-dark

Ensuite, tu crées une classe de bouton principal qui utilise ces variables :

• fond = color-brand-primary
• texte = color-text-on-dark
• padding vertical = space-button-y
• padding horizontal = space-button-x
• rayon = radius-button

Et enfin, tu peux transformer ton bouton, son icône éventuelle et sa structure dans un component si tu l’utilises partout dans le site.

Là, tu ne règles plus un bouton “à la main” à chaque fois. Tu poses une base, puis tu la réutilises. Et franchement, quand tu dois reprendre le site trois mois plus tard, ton niveau de paix intérieure te remercie.

Ce qu’est un vrai design token, avec des exemples clairs

Un vrai design token, ce n’est pas un nom compliqué pour faire joli dans un audit. C’est juste une manière propre de nommer les éléments récurrents de ton design.

Le plus simple, c’est de les classer en trois familles.

1. Les tokens de fondation

Ici, tu poses les valeurs de base.

Exemples :

• color-brand-primary
• color-brand-accent
• color-text-default
• color-text-muted
• font-family-base
• font-family-heading
• text-size-body
• text-size-h2
• space-xs
• space-s
• space-m
• space-l

Ce sont les briques du site. Pas encore les usages précis. Juste les bases.

2. Les tokens sémantiques

Là, on arrête de parler “technique” pour parler “usage”.

Exemples :

• button-primary-bg
• button-primary-text
• card-bg
• card-title-color
• section-alt-bg
• faq-border-color
• hero-title-size

Ici, tu ne dis plus “j’utilise tel bleu”. Tu dis “voici la couleur de fond du bouton principal”. Et ça, c’est beaucoup plus utile quand la charte évolue.

3. Les tokens liés aux composants

C’est le niveau le plus concret.

Par exemple, pour une carte service, tu peux avoir :

• card-service-bg
• card-service-title-size
• card-service-radius
• card-service-padding
• card-service-shadow

Pour un bouton principal :

• button-primary-bg
• button-primary-text
• button-primary-border
• button-primary-padding-y
• button-primary-padding-x
• button-primary-radius

Pour une section témoignage :

• testimonial-bg
• testimonial-text-size
• testimonial-author-color
• testimonial-gap

Tout ça peut ensuite nourrir tes classes et tes components. C’est là que le système devient concret. Pas avant.

Comment les construire sans rendre l’éditeur incompréhensible ?

Le bon réflexe, c’est de partir de ce qui revient vraiment souvent.

Pas de ce que tu pourrais peut-être utiliser un jour, un mardi, dans une section cachée d’une landing page d’hiver.

Pour un site vitrine classique, tu peux commencer avec une base très simple.

Exemple de base saine pour un site pro

Couleurs

• color-brand-primary
• color-brand-secondary
• color-text-default
• color-text-light
• color-bg-page
• color-bg-card

Typographies

• font-family-base
• font-family-heading
• text-size-body
• text-size-small
• text-size-h1
• text-size-h2

Espacements

• space-xs
• space-s
• space-m
• space-l
• space-xl

Rayons

• radius-s
• radius-m
• radius-l

Ombres

• shadow-soft
• shadow-card

Avec ça, tu as déjà une vraie base exploitable.

Dès que tu poses des tailles d’espacement claires, tu améliores aussi la respiration générale du site. Et ça rejoint très bien ce point sur les espaces blancs dans WordPress, parce qu’un design cohérent ne tient pas seulement à la couleur ou à la typo, mais aussi à la façon dont le contenu respire.

Ensuite, tu crées seulement les classes dont tu as besoin.

Exemples de classes utiles

• btn-primary
• btn-secondary
• card-service
• card-testimonial
• section-alt
• title-section
• text-small

Et après, tu montes les composants qui reviennent souvent.

Exemples de components utiles

• un bloc CTA avec titre + texte + bouton ;
• une carte service avec icône + titre + texte ;
• un bloc témoignage ;
• une FAQ ;
• un encart de réassurance.

À partir de là, tu commences à gagner du temps pour de vrai. Et tu évites le grand classique du site qui a été “bien pensé” au départ, puis “vite adapté” ensuite, puis “un peu corrigé” plus tard… jusqu’à finir avec une cohérence qui boite légèrement.

Exemple concret sur un bouton

Prenons un bouton principal.

Sans système, tu peux te retrouver avec ça :

• page d’accueil : fond bleu #1E3A8A, texte blanc, padding 14/24, rayon 10 ;
• page service : fond bleu un peu différent, padding 16/26, rayon 12 ;
• landing page : même bleu que la page d’accueil, mais texte légèrement cassé, hover encore différent.

Personne ne va hurler devant son écran. Mais mis bout à bout, ça fatigue la perception du site.

Avec des design tokens, ton bouton principal peut reposer sur :

• button-primary-bg = color-brand-primary
• button-primary-text = color-text-light
• button-primary-padding-y = space-s
• button-primary-padding-x = space-m
• button-primary-radius = radius-m

Puis ta classe btn-primary utilise ces valeurs.

Résultat : si demain tu modifies radius-m, tous les boutons concernés suivent.

Si tu changes color-brand-primary, même chose.

Tu ne passes pas ton après-midi à chercher où tu avais mis “le bon bouton”.

Exemple concret sur une carte service

Même principe avec une carte service.

Sans système, on voit souvent ça :

• une carte avec un fond blanc pur ;
• une autre légèrement grise ;
• une troisième avec plus de padding ;
• un titre parfois en 24 px, parfois en 22 px ;
• un rayon pas toujours identique.

Avec un système propre, tu peux poser :

• card-service-bg = color-bg-card
• card-service-padding = space-m
• card-service-radius = radius-l
• card-service-title-size = text-size-h3
• card-service-shadow = shadow-card

Puis créer une classe card-service.

Et là, tout le site respire mieux. Sans effet waouh inutile. Juste parce que ça tient ensemble.

Les erreurs qui font dérailler tout ça

La première, c’est d’en faire trop.

Créer cinquante variables dès le départ n’aide pas. Ça donne surtout l’impression de monter un système très sérieux, jusqu’au moment où plus personne ne sait à quoi sert color-neutral-soft-alt-2. Là, on entre dans la poésie triste du back-office.

La deuxième, c’est de mal nommer les choses.

Des noms comme :

• blue-final
• blue-final-2
• cta-new
• padding-ok

… ce n’est pas un système. C’est un appel à l’aide.

Des noms comme :

• color-text-default
• button-primary-bg
• space-section-l

… vieillissent beaucoup mieux.

La troisième, c’est de vouloir créer des components alors que les fondations ne sont pas stables. Si tes couleurs, tes tailles et tes usages sont encore flous, tu vas juste emballer le désordre dans une jolie boîte.

La quatrième, c’est de mélanger ancien et nouveau sans méthode. Si tu reprends un site existant, fais le ménage progressivement. Tu peux t’aider d’un cadre plus large sur le design system Elementor V4 pour garder une vue d’ensemble, puis t’appuyer aussi sur une base propre de maintenance WordPress pour éviter que le site reparte en freestyle graphique à chaque évolution.

En conclusion

Avec Elementor V4, tu peux enfin construire autre chose qu’un simple empilement de styles “à peu près cohérents”. Les Variables, les Classes et les Components permettent de poser une vraie base de travail. À condition, bien sûr, de rester simple, clair et utile.

Le plus important n’est pas d’avoir le système le plus impressionnant. Le plus important, c’est d’avoir un site qui reste propre quand il évolue.

En clair :

• les variables stockent les valeurs ;
• les classes appliquent les styles ;
• les components réutilisent les blocs ;
• les design tokens relient tout ça proprement.

Et c’est souvent ce petit travail en amont qui évite, plus tard, les boutons qui improvisent, les cartes qui dérivent et les pages qui semblent sortir d’ailleurs. Toute ressemblance avec certains sites existants n’est évidemment pas fortuite.