Une situation transitoire, plus fréquente qu’on ne le pense sur des sites en migration progressive : une page dont le contenu principal est encore construit avec l’éditeur V4 d’Elementor, mais dont un bloc de contenu spécifique, ajouté récemment par un rédacteur pressé, utilise un bloc Gutenberg natif inséré directement dans la zone de contenu, faute de widget Elementor équivalent disponible sous la main à ce moment précis.
Cet article ne traite pas la question stratégique plus large de la cohabitation des deux systèmes à l’échelle d’un site entier, question de gouvernance déjà abordée ailleurs. Il se concentre uniquement sur ce qui se passe techniquement, au niveau du rendu, quand les deux coexistent sur une même page.
Comment WordPress gère cette cohabitation en interne
Techniquement, une page Elementor reste un contenu WordPress standard, stocké dans le champ de contenu de l’article ou de la page. Quand Elementor gère l’intégralité de la mise en page, il remplace entièrement le rendu de ce champ par sa propre structure, générée depuis ses données stockées séparément en métadonnées. Un bloc Gutenberg inséré au milieu de ce contenu se retrouve alors intégré dans le flux de rendu d’Elementor à l’endroit précis où il a été placé dans l’éditeur, sans que les deux systèmes n’entrent en collision structurelle directe, chacun générant son propre balisage HTML dans son périmètre respectif.
Le CSS des deux systèmes, chargé côte à côte
Les feuilles de style spécifiques à Elementor et celles générées par le cœur de blocs de WordPress se chargent simultanément sur la page concernée, sans exclusion mutuelle. Le risque réel de conflit se situe au niveau des noms de classe : si un thème ou une extension tierce définit une classe CSS portant le même nom qu’une classe utilisée par l’un des deux systèmes, un conflit de spécificité peut apparaître, avec un style qui l’emporte sur l’autre de façon parfois imprévisible selon l’ordre de chargement des feuilles de style.
Le point aveugle : les variables globales ne se partagent pas
C’est le point technique le plus souvent mal compris sur ce sujet : les variables et classes globales définies dans le kit de style de l’éditeur V4 d’Elementor ne sont pas automatiquement disponibles pour un bloc Gutenberg natif inséré sur la même page. Ce dernier reste piloté par son propre système, celui défini dans le fichier theme.json du thème actif, indépendant du kit de style Elementor sauf synchronisation manuelle explicite mise en place par le développeur du thème.
Concrètement, un bloc Gutenberg qui tente d’utiliser la couleur d’action primaire définie côté Elementor V4 n’y accède pas nativement : il faut soit dupliquer manuellement cette valeur dans les réglages de couleur du thème via theme.json, soit mettre en place un pont technique entre les deux systèmes, ce qui dépasse largement le cadre d’un simple ajout ponctuel de bloc par un rédacteur.
Un tableau de synthèse technique
| Aspect | Comportement observé |
|---|---|
| Balisage HTML | Chaque système génère le sien, sans collision structurelle directe |
| Chargement CSS | Les deux feuilles de style se chargent côte à côte |
| Variables globales | Non partagées automatiquement entre les deux systèmes |
| Risque principal | Collision de nom de classe CSS, rare mais possible |
Un test simple pour vérifier le comportement sur un site donné
- Créer une page de test avec un contenu Elementor V4 classique.
- Insérer un bloc Gutenberg natif (une simple citation ou un bloc de code) au milieu de ce contenu.
- Vérifier dans l’inspecteur du navigateur que les deux jeux de classes CSS coexistent sans collision visible sur cette page précise.
- Tenter d’appliquer une variable de couleur globale Elementor au bloc Gutenberg inséré, pour constater concrètement l’absence de partage automatique entre les deux systèmes.
Deux systèmes de rendu qui cohabitent sur une même page ne se disputent pas le terrain, ils l’ignorent poliment l’un l’autre. Le vrai risque n’est pas le conflit visible, c’est l’incohérence discrète d’un style qui ne se propage tout simplement pas là où on l’attendrait.
En résumé
Techniquement, l’éditeur V4 d’Elementor et les blocs Gutenberg natifs cohabitent sans casse structurelle sur une même page transitoire, chacun gérant son propre balisage et son propre CSS. Le point de vigilance réel se situe dans l’absence de partage automatique des variables globales entre les deux systèmes, une nuance technique à connaître avant de promettre à un client une cohérence visuelle parfaite entre un contenu Elementor et un bloc Gutenberg inséré au même endroit.
