Comment créer un Design System avec Elementor V4 ?

Créer un site avec Elementor page par page peut sembler efficace au début. Pourtant, lorsque le projet prend de l’ampleur, les incohérences apparaissent rapidement : une couleur légèrement différente, plusieurs tailles de titres pour une même fonction, des espacements qui varient d’une section à l’autre ou encore plusieurs versions d’un même bouton.

Le problème n’est pas forcément Elementor. Il vient souvent de la manière dont le projet est construit.

Depuis l’arrivée d’Elementor V4, il est possible d’adopter une approche beaucoup plus structurée autour des Variables, Classes, Atomic Elements et Components. L’idée n’est plus seulement de construire chaque page individuellement, mais de définir d’abord les règles graphiques du site, puis de construire les pages à partir de ces règles.

C’est l’approche que j’utilise aujourd’hui sur mes nouveaux projets clients : je pars de la maquette Figma, j’identifie les règles graphiques, puis je construis le Design System dans Elementor avant de commencer réellement les pages.

L’objectif de cet article est de montrer concrètement comment je structure ce travail.

Pourquoi créer un Design System avec Elementor ?

Un Design System peut être vu comme la fondation graphique et fonctionnelle d’un site.

Il regroupe notamment :

• les couleurs
• les typographies
• les tailles de titres
• les styles de paragraphes
• les containers
• les espacements
• les boutons
• les cartes
• les formulaires
• les composants réutilisables
• les règles responsive

Sans cette base, chaque élément risque d’être stylisé au moment où il apparaît sur une page.

Avec un Design System, la logique est différente :

Variables → Classes → Components → Pages

Cette approche permet de centraliser davantage les styles et de réutiliser les mêmes règles sur l’ensemble du site.

Elementor V4 s’inscrit précisément dans cette logique avec son nouvel environnement Atomic, ses Classes, ses Variables et ses Components.

Si vous découvrez encore Elementor, je vous conseille de commencer par [Qu’est-ce qu’Elementor et comment fonctionne-t-il ?], puis de revenir ici pour aborder la partie plus structurée de son utilisation.

Première étape : analyser la maquette Figma

Je ne commence pas par Elementor.

Je commence par la maquette Figma.

L’objectif est de comprendre le langage visuel du projet avant de commencer son intégration.

Je vais notamment rechercher :

• les couleurs
• les typographies
• les tailles de titres
• les styles de paragraphes
• les labels
• les différentes tailles desktop
• les adaptations tablette
• les adaptations mobile
• les espacements
• le système de spacing
• les bordures
• les border-radius
• les ombres éventuelles
• les largeurs de contenu
• le comportement responsive

Cette analyse permet de transformer une maquette graphique en véritable système de règles.

La logique de spacing

Sur mes projets, j’utilise notamment une logique basée sur une unité de 8 px.

Cette logique est présente dans mes maquettes Figma puis reprise lors de l’intégration Elementor.

Cela ne signifie pas que chaque valeur doit obligatoirement être un multiple de 8.

L’objectif est plutôt de disposer d’une référence commune permettant de conserver une cohérence entre les différents espacements.

Par exemple, plutôt que de choisir indépendamment 22 px, 31 px, 47 px ou 53 px selon les sections, on peut construire une échelle cohérente autour de valeurs comme 8, 16, 24, 32, 40, 48 ou 64 px.

C’est un choix de workflow personnel, pas une règle universelle.

Créer une page Design System dédiée

Une fois l’analyse de la maquette terminée, je crée une page dédiée dans le projet :

Design System

Cette page reste volontairement hors du parcours public du site. Dans mon workflow, je la conserve en brouillon et hors indexation.

Elle devient la référence centrale du projet.

Je l’organise généralement en plusieurs catégories :

• Colors
• Typography
• Containers
• Spacing
• Buttons
• Cards
• Forms

L’objectif est de pouvoir retrouver rapidement les différents éléments du système et de vérifier leur rendu.

Cette page devient également une documentation vivante.

Si un autre intégrateur intervient sur le projet, il peut comprendre rapidement :

• quelles couleurs utiliser
• quelles typographies sont prévues
• quelles largeurs de contenu existent
• quels espacements sont disponibles
• quels boutons utiliser
• comment sont construites les cartes
• comment sont pensés les formulaires

Elle reste également utile après la mise en ligne.

Si le site doit évoluer dans six mois, je peux revenir à cette page pour vérifier le système existant avant de créer une nouvelle variante.

Commencer par les variables de couleurs

La première couche que je définis concerne généralement les couleurs.

À partir de la charte graphique et de Figma, je crée les variables nécessaires au projet.

Par exemple :

• Primary
• Text
• Background
• Black-70
• Black-60
• Black-50
• Blue-100

La nomenclature dépend évidemment du projet.

L’important est surtout qu’elle reste compréhensible.

Elementor définit une Variable comme une valeur réutilisable, qui peut ensuite être utilisée dans différentes parties du système. Les Variables peuvent également être intégrées aux Classes.

Pourquoi utiliser des variables ?

Imaginons que la couleur principale du site soit utilisée sur :

• les boutons
• certains titres
• des liens
• des icônes
• des éléments de navigation

Si cette couleur est définie indépendamment à chaque endroit, une modification devient rapidement fastidieuse.

Avec une variable, l’information est centralisée.

Je peux modifier la valeur de la variable et répercuter cette modification sur les éléments qui l’utilisent.

La logique est donc simple :

Une valeur définie dans le Design System doit être réutilisée partout où cette valeur est nécessaire.

Construire le système typographique

Après les couleurs, je définis la typographie.

Pour les titres, je commence par les niveaux sémantiques :

• H1
• H2
• H3
• H4
• H5
• H6

Pour chaque niveau, je définis notamment :

• la taille
• le poids
• la hauteur de ligne
• éventuellement l’espacement entre les lettres
• le comportement responsive

Les valeurs peuvent donc être différentes entre desktop, tablette et mobile.

Les paragraphes

Je définis également plusieurs niveaux de texte.

Par exemple :

• Paragraph Small
• Paragraph Medium
• Paragraph Large

Puis les autres styles nécessaires au projet :

• Label
• Caption
• Eyebrow
• etc.

L’objectif est d’éviter de modifier manuellement la taille d’un texte à chaque utilisation.

Ne pas confondre sémantique et apparence

C’est un point particulièrement important.

Un H2 reste un H2 pour sa fonction sémantique, même si plusieurs traitements visuels peuvent être nécessaires selon le contexte.

Le Design System doit donc organiser l’apparence sans sacrifier la structure HTML du contenu.

Autrement dit, on ne doit pas choisir un niveau de titre uniquement parce que sa taille nous convient visuellement.

Définir le système de containers

Les largeurs de contenu doivent également être pensées avant de construire les pages.

Dans mon workflow, je définis plusieurs niveaux de containers.

Par exemple :

• Container Small
• Container Medium
• Container Large
• Container XL
• Container Max

Chaque niveau correspond à une largeur différente.

Un bloc contenant simplement un titre, un paragraphe et quelques informations peut utiliser un Container Large.

À l’inverse, une carte, une carte interactive ou un contenu nécessitant davantage d’espace peut utiliser un Container Max.

L’objectif est d’éviter de définir une nouvelle largeur manuellement à chaque section.

Cela permet également de conserver une structure beaucoup plus proche de la maquette Figma.

Gérer le responsive dans le Design System

Le responsive ne doit pas être une étape réalisée à la fin.

Il doit être intégré directement dans le Design System.

Par exemple, un Container Max peut avoir un comportement différent selon la largeur de l’écran.

Dans mon propre système, j’utilise notamment :

• 24 px de padding horizontal sur desktop ;
• 24 px sur tablette ;
• 20 px sur mobile.

De la même manière, chaque niveau de titre possède ses propres valeurs responsive.

Elementor V4 permet de travailler directement dans différents modes responsive et les valeurs peuvent être héritées des écrans plus larges vers les écrans plus petits lorsqu’elles ne sont pas redéfinies.

Cela permet de faire du Design System une véritable référence responsive du projet.

Encore une fois, mes valeurs sont des exemples issus de mon workflow, et non des valeurs universelles à reproduire sur tous les sites.

Définir le système de spacing

Le spacing doit lui aussi être standardisé.

Je peux par exemple créer :

• Section Small
• Section Medium
• Section Large

Ces niveaux permettent de gérer plus facilement les espacements entre les différentes sections.

Je peux également appliquer cette logique aux :

• paddings internes ;
• gaps ;
• espacements entre les éléments ;
• marges nécessaires à certains composants.

L’idée est surtout d’éviter de choisir les espacements au hasard pendant l’intégration.

Lorsque Figma et Elementor utilisent la même logique, il devient beaucoup plus simple de reproduire fidèlement la conception.

Créer les boutons

Les boutons constituent généralement l’un des premiers composants à standardiser.

Je peux par exemple définir :

• Button Primary
• Button Secondary
• Button Tertiary

Pour chaque bouton, je définis notamment :

• la typographie
• la couleur
• le padding
• la bordure
• le border-radius
• la taille
• l’icône éventuelle
• les transitions
• les états interactifs

Il faut notamment prévoir :

• Default
• Hover
• Focus
• Active
• Disabled

L’intérêt d’Elementor V4 est de pouvoir gérer une grande partie de cette logique directement dans son système de styles, ce qui peut limiter le recours à du CSS personnalisé pour les besoins courants.

Cela ne signifie évidemment pas que le CSS personnalisé disparaît complètement.

Il reste utile pour certains besoins spécifiques.

Créer les Cards

Les cartes sont elles aussi des éléments particulièrement intéressants à standardiser.

Une carte peut par exemple être composée de :

• une image
• un label ou une catégorie
• un titre
• une description
• un bouton

Plutôt que de styliser chaque carte individuellement, je définis les styles réutilisables nécessaires.

Une simple classe peut suffire lorsque je souhaite principalement partager un style.

Lorsque la structure devient plus complexe et que le bloc doit être réutilisé dans plusieurs endroits du site, un Component peut devenir plus pertinent.

C’est une distinction importante dans Elementor V4.

Construire le système de formulaires

Les formulaires font également partie du Design System.

Je peux définir les styles des différents éléments :

• Input
• Textarea
• Select
• Checkbox
• Radio
• Button
• messages d’erreur
• messages de validation

Il faut également prévoir leurs différents états.

L’objectif est que les formulaires du site partagent les mêmes règles graphiques.

Cela peut sembler secondaire au début d’un projet, mais les formulaires sont justement le genre d’éléments qui peuvent rapidement devenir incohérents lorsqu’ils sont construits séparément sur plusieurs pages.

Variables, Classes et Components : quelle différence ?

C’est probablement l’une des parties les plus importantes à comprendre lorsqu’on découvre Elementor V4.

La logique peut être résumée simplement.

Une Variable

Une Variable correspond à une valeur réutilisable.

Par exemple :

Primary = #1E90FF

Cette valeur peut ensuite être utilisée dans différentes Classes et différents éléments.

Une Classe

Une Classe regroupe plusieurs règles de style.

Par exemple :

button-primary

Cette classe peut définir simultanément :

• la couleur
• la typographie
• le padding
• la bordure
• le border-radius
• etc

Les Classes constituent l’un des changements importants d’Elementor V4. Elles permettent de regrouper des styles et de les réutiliser sur plusieurs éléments. Elementor dispose également d’une gestion des priorités lorsque plusieurs Classes entrent en conflit.

Un Component

Un Component va plus loin.

Il permet de réutiliser une structure complète.

Par exemple, une carte composée de plusieurs éléments peut devenir un Component.

Les Components Elementor sont conçus pour rester synchronisés à travers le site tout en permettant d’exposer certaines propriétés pour personnaliser une instance.

Il ne faut donc pas considérer un Component comme une simple « classe améliorée ».

La différence est structurelle :

Classe → style réutilisable

Component → structure réutilisable

Comment utiliser les Atomic Elements ?

Elementor V4 introduit une nouvelle génération d’éléments appelés Atomic Elements.

Le principe est de construire les interfaces à partir d’éléments plus simples et de leur appliquer les règles du Design System.

Cela change progressivement la manière de travailler avec Elementor.

Dans l’ancien workflow, on pouvait facilement prendre un widget, modifier ses paramètres, puis recommencer sur le widget suivant.

Avec V4, l’approche devient davantage :

définir → réutiliser → composer

Les nouveaux éléments sont conçus pour fonctionner avec les Classes, les Variables et les Components. Elementor permet par ailleurs de combiner les nouveaux éléments V4 avec les éléments issus de la génération précédente.

C’est particulièrement intéressant pour les nouveaux projets, car on peut construire progressivement une véritable fondation graphique avant de multiplier les pages.

Privilégier une nomenclature simple pour les Classes

Un Design System peut rapidement devenir difficile à comprendre si les noms des Classes deviennent trop complexes.

Je privilégie donc des noms simples.

Par exemple :

• button-primary
• button-secondary
• container-large
• container-max
• section-large

L’objectif est qu’un autre intégrateur puisse comprendre immédiatement ce que fait une Classe.

Il faut également éviter de créer une Classe simplement pour chaque élément rencontré.

Un Design System ne signifie pas :

une Classe pour absolument tout.

Une Classe doit correspondre à un style qui a réellement vocation à être réutilisé.

Quand utiliser une Classe et quand utiliser un Component ?

La distinction peut être résumée ainsi.

Utiliser une Classe

Utilisez une Classe lorsque vous souhaitez principalement partager un style.

Exemple :

button-primary

Plusieurs boutons peuvent utiliser cette même Classe.

Utiliser un Component

Utilisez un Component lorsque vous souhaitez réutiliser une structure complète.

Exemple :

Une carte composée d’une image, d’un titre, d’un texte et d’un bouton.

L’intérêt du Component est notamment de pouvoir conserver une structure commune tout en exposant certaines propriétés modifiables par instance. Les modifications apportées au Component maître peuvent ensuite être répercutées sur ses instances.

Les Components sont cependant soumis à certaines conditions dans Elementor : ils reposent sur les Atomic Elements et leur création nécessite actuellement Elementor Pro ainsi que des permissions administrateur.

C’est donc un outil particulièrement intéressant, mais qu’il faut utiliser à bon escient.

Faire du Design System une documentation vivante

La page Design System créée au début du projet possède finalement plusieurs fonctions.

Une référence graphique

Elle permet de visualiser immédiatement les règles graphiques du projet.

Un outil de développement

Elle permet de tester une nouvelle Classe, une nouvelle variante ou un nouveau Component avant de l’utiliser sur le site.

Une documentation

Un autre intégrateur peut comprendre rapidement comment le projet est organisé.

Un outil de maintenance

Lorsque le site évolue, je peux revenir à cette page pour vérifier le système existant avant d’ajouter une nouvelle règle.

C’est pour cette raison que je la considère comme une documentation vivante, et non comme une simple page de démonstration.

Elementor V4 face à l’ancien workflow

Avant Elementor V4, je pouvais déjà structurer une partie du système avec :

• les réglages globaux
• les couleurs globales
• les polices globales
• le style du thème
• les typographies
• les boutons
• les images
• les formulaires
• les réglages de mise en page
• les espacements

Cette approche fonctionnait.

Il ne s’agit donc pas de dire que l’ancien Elementor était incapable de produire des sites cohérents.

La différence est plutôt dans la philosophie.

Elementor V4 apporte une organisation plus structurée autour des :

• Variables ;
• Classes ;
• Atomic Elements ;
• Components.

L’objectif est de se rapprocher davantage d’une logique de Design System moderne. Elementor présente d’ailleurs V4 comme une nouvelle fondation destinée à passer d’une construction davantage centrée sur les pages à une approche plus systémique.

Pour un projet existant, il n’est d’ailleurs pas nécessaire de tout reconstruire immédiatement. Elementor prévoit une coexistence entre les éléments V3 et les nouveaux éléments V4, ce qui permet une adoption progressive.

Quels sont les bénéfices d’un Design System Elementor ?

Gain de temps

La création initiale demande davantage de réflexion.

Mais une fois le système en place, les styles peuvent être réutilisés sur l’ensemble du site.

Le temps investi au départ est donc récupéré progressivement pendant l’intégration.

Cohérence graphique

Les mêmes règles sont utilisées sur les différentes pages.

Cela permet notamment de rester beaucoup plus proche des maquettes Figma.

Maintenance simplifiée

Modifier une Variable ou une Classe peut permettre de modifier plusieurs éléments simultanément.

Cela devient particulièrement intéressant lorsque le site contient beaucoup de pages.

Meilleure collaboration

La page Design System permet à un autre intégrateur de comprendre rapidement les règles du projet.

Il n’a pas besoin de découvrir la logique du site uniquement en parcourant ses pages.

Moins de CSS personnalisé

Certaines personnalisations qui nécessitaient auparavant du CSS peuvent désormais être gérées directement dans Elementor V4.

Il faut cependant rester prudent : un Design System ne supprime pas le besoin de CSS dans tous les projets.

Il peut toujours être nécessaire pour des besoins spécifiques.

Une structure potentiellement plus légère

Elementor met également en avant une architecture Atomic visant notamment à réduire les wrappers inutiles et à produire un rendu plus léger.

Mais il serait incorrect d’en déduire qu’Elementor V4 rend automatiquement tous les sites rapides.

La performance finale dépend toujours de nombreux facteurs :

• images
• plugins
• JavaScript
• CSS
• polices
• hébergement
• cache
• scripts tiers
• structure des pages

Le Design System contribue à une meilleure organisation, mais il ne remplace pas une véritable optimisation technique.

Quelles sont les limites et la courbe d’apprentissage ?

Le Design System demande une phase d’apprentissage.

Un utilisateur habitué à Elementor V3 peut être dérouté au départ par :

• les Atomic Elements
• les Variables
• les Classes
• la hiérarchie des Classes
• les Components
• la logique d’héritage
• le responsive

Le premier projet peut donc demander davantage de réflexion.

C’est normal.

On passe d’une logique :

Je construis la page et je personnalise chaque élément.

à une logique :

Je construis d’abord le système qui va me permettre de construire la page.

Cette différence demande un changement de méthode.

En revanche, plus le projet comporte de pages ou doit évoluer pendant plusieurs années, plus cette organisation devient intéressante.

Le minimum viable Design System

Je n’applique pas nécessairement un Design System gigantesque à tous les projets.

Si je dois construire rapidement une base Elementor, je commence par quatre éléments.

1. Les couleurs

Elles permettent d’établir immédiatement la base visuelle du projet.

2. Les typographies

Elles garantissent la cohérence des titres et des contenus.

3. Les containers

Ils permettent de contrôler les largeurs et la structure générale des pages.

4. Les boutons

Ils standardisent immédiatement les principaux éléments interactifs.

Les cartes et les formulaires peuvent ensuite être ajoutés lorsque le projet le nécessite.

Ce sont mes quatre priorités dans ce workflow. Ce n’est évidemment pas une règle absolue pour tous les projets.

Mon workflow complet

Si je devais résumer toute la méthode, je procéderais ainsi.

Étape 1 — Analyser Figma

Identifier les couleurs, typographies, tailles responsive, espacements, bordures, containers et autres règles graphiques.

Étape 2 — Créer la page Design System

La conserver en brouillon et hors indexation.

Étape 3 — Créer les Variables

Commencer notamment par les couleurs et les autres valeurs réellement nécessaires.

Étape 4 — Définir la typographie

Créer les styles H1 à H6, paragraphes, labels et autres styles nécessaires.

Étape 5 — Définir les Containers

Créer les différents niveaux de largeur nécessaires au projet.

Étape 6 — Définir le Spacing

Construire une logique cohérente, notamment autour de la grille de 8 px utilisée dans la conception.

Étape 7 — Créer les boutons

Définir les variantes Primary, Secondary, Tertiary et leurs différents états.

Étape 8 — Créer les Cards et Forms

Définir leurs styles et utiliser des Components lorsque cela apporte une réelle valeur.

Étape 9 — Construire les pages

Les pages sont maintenant assemblées à partir du système plutôt que stylisées élément par élément.

Étape 10 — Faire évoluer le Design System

Le système continue d’évoluer avec le projet.

Une nouvelle variante réellement nécessaire peut être ajoutée.

Une règle devenue inutile peut être supprimée.

Le Design System n’est donc pas figé.

Elementor V4 permet aussi de réutiliser son Design System

C’est un point intéressant pour les freelances et les agences.

Elementor permet actuellement d’importer et d’exporter des Design Systems comprenant notamment les Variables et les Classes. Le système peut être transféré sous forme de fichier ZIP entre plusieurs sites.

Cela ouvre une possibilité intéressante : construire progressivement sa propre base de travail.

Je peux par exemple avoir une structure de départ contenant :

• une base typographique
• une nomenclature de Classes
• une organisation de couleurs
• certains patterns de boutons
• des règles de spacing

Puis adapter cette base au projet du client.

Il ne s’agit évidemment pas de copier le même Design System sur tous les sites.

Chaque projet possède son identité.

L’intérêt est plutôt de ne pas repartir de zéro pour les principes d’organisation.

Conclusion

Elementor V4 change surtout une chose importante : la manière de penser la construction d’un site.

On peut passer d’une logique :

« Je construis chaque page et je règle chaque élément. »

à une logique :

« Je définis d’abord les règles du site, puis je construis les pages avec ces règles. »

C’est cette approche qui me paraît particulièrement intéressante.

Le Design System permet de mieux relier Figma, Elementor et le développement du site.

Il permet également de gagner en cohérence, de faciliter la maintenance et de rendre le projet plus compréhensible lorsqu’il doit être repris par une autre personne.

C’est aussi ce qui rapproche davantage Elementor des méthodes que l’on peut retrouver dans des outils comme Webflow ou Framer.

Pour moi, le Design System n’est donc pas une étape supplémentaire destinée à ralentir le projet.

C’est une fondation qui demande un peu plus de réflexion au départ, mais qui peut faire gagner beaucoup de temps sur l’ensemble du projet.

Si vous souhaitez comprendre plus largement comment je structure un projet WordPress, vous pouvez également consulter mon Guide Elementor ainsi que mon article Comment créer un site WordPress professionnel ?.

Et si votre projet doit être conçu à partir d’une maquette Figma puis intégré dans WordPress, vous pouvez également découvrir ma [méthode de conception web].

FAQ