Deux fichiers de vérité pour une seule couleur de marque : c’est le risque concret dès qu’un site mêle un thème bloc classique et l’éditeur atomique d’Elementor V4. Le premier définit ses couleurs et espacements dans theme.json ; le second, avec ses classes globales et ses variables introduites en 2025, propose son propre système de design tokens. Sans réconciliation, un changement de couleur de marque oblige à le répercuter à deux endroits — et l’oubli d’un des deux devient vite visible.
Ce billet explique comment faire pointer les variables d’Elementor V4 vers celles déjà générées par theme.json, pour ne conserver qu’une seule source de vérité. Il ne traite ni la migration complète d’Elementor vers un thème bloc, ni l’opération inverse : seulement la cohabitation des deux sur un même site.
Deux systèmes de tokens, une même intention
Depuis WordPress 5.8, theme.json génère des variables CSS de la forme --wp--preset--color--primaire à partir des presets déclarés dans le thème. Elementor V4, avec son éditeur atomic elements et ses classes globales annoncées en 2025, introduit son propre mécanisme : des variables stockées et gérées depuis l’interface Elementor, appliquées via des classes réutilisables sur les éléments.
Les deux systèmes visent le même objectif — centraliser les valeurs de design pour éviter les répétitions — mais ils l’implémentent indépendamment, sans connaissance l’un de l’autre par défaut. Sur un site qui mêle des pages construites en blocs natifs et d’autres en Elementor, cela crée deux listes de couleurs, deux échelles d’espacement, à maintenir en parallèle.
Pourquoi ne pas simplement choisir un seul outil
Dans l’idéal, un site n’utiliserait qu’un seul système de construction de page. En pratique, de nombreux sites existants ont des sections historiques construites avec Elementor et des sections plus récentes migrées vers l’éditeur de site natif, souvent parce qu’une refonte complète n’était pas budgétée. Cette cohabitation est une réalité de terrain, pas un choix architectural idéal.
Faire pointer les variables Elementor vers theme.json
La méthode retenue consiste à ne jamais saisir de valeur brute dans l’interface de variables globales d’Elementor V4, mais à y référencer directement les variables CSS déjà exposées par theme.json. Elementor V4 permet, pour chaque variable de couleur ou d’espacement définie dans son gestionnaire, de renvoyer vers une valeur CSS personnalisée plutôt qu’une valeur figée.
/* theme.json — déclaration côté thème bloc */
{
"settings": {
"color": {
"palette": [
{ "slug": "primaire", "color": "#1c4e80", "name": "Bleu principal" },
{ "slug": "accent", "color": "#e08e45", "name": "Orange accent" }
]
}
}
}Ce bloc génère automatiquement --wp--preset--color--primaire et --wp--preset--color--accent dans le CSS global du site. Côté Elementor V4, la variable globale « Couleur principale » se configure alors non pas avec un code hexadécimal en dur, mais avec var(--wp--preset--color--primaire) comme valeur.
Synchroniser les espacements de la même façon
Le même principe s’applique aux espacements. Si theme.json déclare une échelle d’espacement personnalisée, ces valeurs peuvent être référencées telles quelles dans les variables d’espacement d’Elementor V4, plutôt que d’y dupliquer une échelle parallèle en pixels ou en rem.
{
"settings": {
"spacing": {
"spacingSizes": [
{ "slug": "petit", "size": "1rem", "name": "Petit" },
{ "slug": "moyen", "size": "2rem", "name": "Moyen" },
{ "slug": "grand", "size": "4rem", "name": "Grand" }
]
}
}
}La variable d’espacement « moyen » côté Elementor devient alors var(--wp--preset--spacing--moyen), garantissant qu’un ajustement de l’échelle dans theme.json se répercute automatiquement sur les deux systèmes de construction de page, sans intervention manuelle supplémentaire.
Ce que cette réconciliation ne résout pas
Cette technique évite la duplication des valeurs, mais elle ne fusionne pas les deux interfaces d’édition. Un intégrateur travaillant sur une page Elementor devra toujours choisir la bonne variable référencée dans la liste globale de l’éditeur, avec le risque qu’il en crée une nouvelle par erreur plutôt que de réutiliser l’existante. La discipline d’équipe reste indispensable : une nouvelle couleur de marque se déclare d’abord dans theme.json, jamais directement dans l’interface Elementor.
Sur un site mixte, documentez clairement dans le guide de style interne : « toute nouvelle valeur de couleur ou d’espacement se déclare dans theme.json, jamais ailleurs ». Cette règle unique évite la majorité des divergences observées en pratique.
Vérifier la cohérence après un changement
Après toute modification de theme.json, il est recommandé de vérifier visuellement au moins une page construite en blocs natifs et une page construite avec Elementor V4, pour confirmer que le changement s’est bien propagé aux deux. Un script de test visuel automatisé, comparant des captures d’écran avant/après sur un échantillon de pages représentatif des deux systèmes, sécurise cette vérification sur un site à fort trafic où une régression visuelle serait coûteuse.
Notion à retenir
La cohabitation entre Elementor V4 et un thème bloc n’oblige pas à dupliquer les design tokens : en faisant référencer par Elementor les variables CSS déjà générées par theme.json, le site conserve une unique source de vérité pour ses couleurs et ses espacements, quel que soit l’outil utilisé pour construire chaque page. Cette discipline demande une règle d’équipe claire, mais elle épargne des heures de correction de divergences visuelles au fil des mois.
