Quiconque a géré un site Elementor un peu ancien connaît ce moment agaçant : la charte graphique change légèrement, une teinte de bleu doit être ajustée, et il faut retrouver toutes les occurrences de cette couleur, parfois codée en dur dans des dizaines de widgets différents. Les Global Colors et Global Fonts de la V3 réglaient partiellement le problème pour la couleur de texte et la typographie, mais restaient limités : pas de gestion fine des espacements, pas de vraie logique de variables applicables à n’importe quelle propriété.
Avec l’éditeur V4, Elementor va nettement plus loin en introduisant des classes CSS globales réutilisables et des variables de couleurs, d’espacements et de typographies. Ensemble, ces deux briques rapprochent Elementor d’un véritable design system, dans l’esprit de ce que proposent des outils comme Figma côté maquette, mais appliqué directement à la construction du site. Voyons comment les utiliser concrètement pour structurer un projet.
Ce qui changeait déjà avec les Global Colors et Global Fonts de V3
Pour rappel, la V3 permettait de définir une palette de couleurs globales et un jeu de polices globales, accessibles ensuite dans les réglages de style de chaque widget via un sélecteur dédié. C’était une avancée utile, mais elle restait cantonnée à deux propriétés précises : la couleur et la police. Toute autre propriété répétée sur le site, un espacement de section, un rayon de bordure, une ombre portée, devait être redéfinie widget par widget, sans lien entre les occurrences.
Autre limite : ces réglages globaux s’appliquaient propriété par propriété, mais ne permettaient pas de regrouper plusieurs propriétés sous un même nom réutilisable, comme le ferait une classe CSS. Modifier le style complet d’un type de bouton présent sur vingt pages différentes impliquait souvent de repasser sur chaque occurrence.
Les classes globales de V4, une vraie logique de classes CSS
La V4 introduit des classes CSS globales que vous définissez une fois, avec un ensemble de propriétés (couleur, espacement, bordure, typographie, effets), puis que vous appliquez à n’importe quel élément du site. Il s’agit d’un changement de logique important : on ne règle plus un style directement sur un widget isolé, on construit un vocabulaire de classes réutilisables, à la façon dont un développeur front-end structurerait une feuille de styles avec des classes utilitaires ou sémantiques.
Concrètement, vous pouvez définir une classe bouton-principal avec sa couleur de fond, son padding, son rayon de bordure et sa typographie, puis l’appliquer à tous les boutons d’appel à l’action du site. Le jour où la charte évolue, une seule modification de la classe se répercute partout où elle est utilisée, sans repasser page par page.
Les variables : couleurs, espacements et typographies centralisés
En complément des classes, les variables permettent de centraliser des valeurs atomiques réutilisables à l’intérieur même de ces classes, ou directement dans les réglages de style d’un élément. On y retrouve trois grandes familles :
- Les variables de couleur, qui étendent la logique des Global Colors de V3 mais s’intègrent nativement dans le nouveau système de classes.
- Les variables d’espacement, pour standardiser les marges et paddings selon une échelle cohérente plutôt que des valeurs libres saisies au hasard d’un widget à l’autre.
- Les variables de typographie, qui regroupent taille de police, graisse, interlignage et police elle-même dans une entité nommée et réutilisable.
L’intérêt d’une variable par rapport à une valeur codée en dur est le même que celui qu’un développeur connaît bien avec les variables CSS natives ou les tokens de design : un seul endroit à modifier pour propager un changement partout où la variable est référencée. Pour un espacement, par exemple, définir une variable espace-section utilisée par toutes les sections du site garantit une cohérence verticale du design, sans que chaque intégrateur ne réinvente sa propre valeur.
Un exemple de structure de variables
Voici un exemple simplifié de la façon dont on peut organiser ses variables au démarrage d’un projet, présenté ici sous une forme proche de ce qu’on retrouverait dans un fichier de tokens de design :
{
"couleurs": {
"primaire": "#1a3c6e",
"secondaire": "#f2a900",
"texte": "#1f1f1f",
"fond-clair": "#f7f7f7"
},
"espacements": {
"xs": "8px",
"sm": "16px",
"md": "32px",
"lg": "64px"
},
"typographies": {
"titre": { "police": "Poppins", "graisse": 600, "taille": "32px" },
"corps": { "police": "Inter", "graisse": 400, "taille": "16px" }
}
}Ce n’est pas un format exporté tel quel par Elementor, mais il illustre bien la logique de pensée à adopter : définir un petit nombre de valeurs de référence avant de commencer à construire des pages, plutôt que de laisser chaque page définir ses propres choix.
Comparer l’ancien et le nouveau système
| Aspect | V3 (Global Colors/Fonts) | V4 (Classes globales et variables) |
|---|---|---|
| Couverture | Couleur et typographie uniquement | Couleur, espacement, typographie, bordures, effets |
| Réutilisation | Propriété par propriété | Groupes de propriétés via des classes nommées |
| Mise à jour globale | Partielle, selon la propriété | Une modification, propagée partout |
| Logique proche de | Un nuancier de couleurs | Un vrai design system CSS |
Structurer un design system de site étape par étape
Pour tirer parti de ces outils sur un nouveau projet, une approche méthodique paie toujours plus qu’une improvisation page après page. Voici l’ordre que nous recommandons :
- Définir d’abord les variables de couleur et de typographie à partir de la charte graphique, avant de construire la moindre page.
- Créer une échelle d’espacements cohérente, avec un nombre limité de valeurs, plutôt que des espacements libres au cas par cas.
- Construire les classes globales pour les composants récurrents : boutons, titres de section, cartes, citations.
- Appliquer ces classes systématiquement plutôt que de recréer des styles locaux, même quand cela semble plus rapide sur le moment.
- Documenter ce vocabulaire de classes et de variables pour que toute personne qui reprend le projet, y compris vous-même six mois plus tard, s’y retrouve immédiatement.
Résistez à la tentation de créer une classe globale pour chaque micro-variation de style que vous croisez. Un design system utile reste un vocabulaire restreint et cohérent ; s’il compte autant de classes que de widgets sur le site, il perd tout son intérêt.
En résumé
Les classes globales et les variables de l’éditeur V4 transforment la façon de construire un site Elementor : on passe d’un ensemble de réglages locaux, widget par widget, à un vrai vocabulaire de design partagé et centralisé. C’est un changement d’habitude autant qu’un changement d’outil, et il demande de la discipline dès le début du projet pour en tirer tout le bénéfice.
Le gain, une fois cette discipline installée, est considérable : une charte graphique qui évolue se répercute en quelques clics plutôt qu’en une chasse fastidieuse page par page, et la cohérence visuelle du site devient beaucoup plus facile à maintenir sur la durée, y compris pour une équipe qui grandit ou change au fil du temps.
