Un client éditeur de contenu nous a confié un site avec une contrainte inhabituelle : les pages institutionnelles (accueil, à propos, services) devaient rester sur Elementor, déjà maîtrisé par l’équipe marketing, tandis que le blog, à fort volume de publication, devait passer sur l’éditeur de site natif de WordPress pour profiter de la rapidité de rédaction en blocs, sans passer par l’éditeur Elementor plus lourd pour du simple texte. Le thème actif restait un thème bloc compatible FSE.
Ce choix de cohabitation n’est pas une configuration officiellement documentée par Elementor, mais elle fonctionne, à condition d’anticiper les points de friction. Voici ce que ce projet nous a appris, sans comparer les deux outils entre eux — ce n’est pas l’objet ici, seulement leur coexistence concrète sur un même site.
Le header et le footer restent pilotés par Elementor
Premier point rassurant : un template Theme Builder Elementor (header, footer) s’affiche normalement sur toutes les pages du site, y compris les articles publiés en blocs natifs, tant que la condition d’affichage du template couvre bien tous les types de contenu concernés. Le visiteur ne voit donc aucune rupture de navigation entre une page Elementor et un article en blocs.
Les styles globaux ne se parlent pas
C’est le point de friction principal. Les couleurs et typographies définies dans Apparence > Éditeur > Styles (styles globaux du thème bloc, stockés dans theme.json et ses surcharges) sont totalement indépendantes des Global Colors et Global Fonts d’Elementor. Modifier une couleur de marque d’un côté ne se répercute jamais automatiquement de l’autre.
- Une mise à jour de la couleur principale dans Elementor Site Settings ne change rien dans les articles en blocs.
- Inversement, une modification des styles globaux du thème bloc n’affecte aucune page Elementor.
- La seule solution fiable trouvée : maintenir les deux jeux de valeurs manuellement synchronisés, avec une checklist à chaque changement de charte.
Les conflits de spécificité CSS observés
Sur ce projet, les conflits se sont concentrés à deux endroits précis : la typographie des titres et le style des boutons. Le thème bloc applique ses propres règles CSS issues de theme.json avec une spécificité qui, dans certains cas, entrait en collision avec les classes générées par Elementor sur les widgets présents dans les zones communes (header, footer).
/* Règle issue de theme.json du thème bloc */
.wp-block-button__link { border-radius: 4px; font-weight: 600; }
/* Règle générée par Elementor pour un bouton du header */
.elementor-element-abc123 .elementor-button { border-radius: 0; font-weight: 400; }
Dans ce cas précis, comme le header Elementor est injecté hors du contexte de l’éditeur de blocs, ses règles l’emportaient naturellement sans conflit réel. Les vrais problèmes sont apparus uniquement quand un widget Elementor Pro (le widget Posts, par exemple, affichant des articles) générait un balisage qui reprenait des classes wp-block-* issues du contenu des articles, créant des collisions de style inattendues.
La solution retenue : cloisonner les responsabilités
| Zone | Piloté par | Responsable de la cohérence |
|---|---|---|
| Header / Footer | Elementor Theme Builder | Équipe marketing (Elementor) |
| Pages institutionnelles | Elementor | Équipe marketing (Elementor) |
| Articles de blog | Éditeur de blocs natif | Équipe rédaction |
Ce cloisonnement clair a permis d’éviter la majorité des conflits : chaque équipe reste dans son outil, et seules les zones communes (header, footer) font l’objet d’une vérification croisée après chaque modification de charte graphique.
La leçon principale de ce projet : faire cohabiter Elementor et un thème bloc est tout à fait viable pour un usage segmenté par équipe, à condition d’accepter qu’aucun des deux systèmes ne pilotera jamais l’autre automatiquement. Toute synchronisation reste manuelle.
En résumé
Sur ce site mixte, Elementor et le thème bloc cohabitent sans casser l’expérience visiteur, grâce à un header et un footer communs pilotés par le Theme Builder. Le vrai coût de cette cohabitation se situe dans la synchronisation manuelle des styles globaux et dans une vigilance accrue sur les zones où les deux systèmes de classes CSS peuvent se croiser. Un cloisonnement clair des responsabilités par équipe reste, dans notre expérience, la meilleure façon de limiter ces frictions.
