Ouvrir le dossier de Hello Elementor pour la première fois surprend toujours un peu : là où on s’attend à une structure fournie façon Twenty Twenty, on trouve une poignée de fichiers PHP, presque aucun style, et un thème qui semble volontairement inachevé. Ce n’est pourtant pas un oubli des équipes d’Elementor, mais un choix de conception assumé jusqu’au bout.
Dans cet audit, je démonte le thème fichier par fichier pour comprendre sa logique interne, avant de discuter honnêtement de ses limites dès qu’on sort du cadre pour lequel il a été pensé : construire des pages exclusivement avec le page builder Elementor.
La philosophie « canvas » : laisser toute la place au page builder
Hello Elementor part d’un constat simple : la plupart des thèmes classiques embarquent des styles, des animations et des choix visuels qui entrent en conflit avec ceux du page builder utilisé par-dessus. Header stylisé du thème contre header construit dans Elementor, marges par défaut qui s’ajoutent à celles du builder… le résultat est souvent un empilement de styles contradictoires qu’il faut ensuite neutraliser à coups de CSS personnalisé.
La réponse de Hello Elementor est radicale : ne fournir quasiment aucun style par défaut, et laisser le contenu généré par Elementor s’afficher sur une page vierge, sans interférence. On appelle cela un thème « canvas » ou « blank » : une toile blanche, littéralement, sur laquelle le page builder peint sans contrainte.
Ce que contient réellement le thème
La structure de fichiers tient sur une poignée de lignes. Voici l’essentiel de l’arborescence :
style.css: l’en-tête obligatoire du thème, avec un minimum de règles CSS de basefunctions.php: déclaration des supports de thème et enregistrement des stylesheader.phpetfooter.php: structure HTML minimale, ouverture et fermeture du documentindex.php: le gabarit générique, réduit à l’essentieltheme.json: présent dans les versions récentes pour préparer la compatibilité avec l’éditeur de blocs
Dans functions.php, on retrouve les déclarations attendues d’un thème respectueux des standards, mais réduites au strict nécessaire :
<?php
add_action( 'wp_enqueue_scripts', 'hello_elementor_scripts_styles' );
function hello_elementor_scripts_styles() {
wp_enqueue_style(
'hello-elementor',
get_template_directory_uri() . '/style.css',
array(),
HELLO_ELEMENTOR_VERSION
);
}
add_action( 'after_setup_theme', 'hello_elementor_setup' );
function hello_elementor_setup() {
add_theme_support( 'title-tag' );
add_theme_support( 'post-thumbnails' );
add_theme_support( 'automatic-feed-links' );
add_theme_support( 'html5', array( 'search-form', 'comment-form', 'comment-list', 'gallery', 'caption' ) );
}Rien de plus : pas de menu de navigation complexe préconfiguré, pas de widgets additionnels, pas de galerie de gabarits alternatifs. Le thème se contente d’exister, proprement, pour que le contenu prenne toute la place.
Un header et un footer réduits à l’essentiel
Même le header, élément généralement riche en styles dans un thème classique, se limite ici à une structure minimale : un logo optionnel, un titre de site, et parfois un menu de navigation basique, sans plus. Dans la pratique, la grande majorité des utilisateurs d’Elementor Pro remplacent entièrement ce header et ce footer par des gabarits construits dans le module « Theme Builder » du plugin, rendant les fichiers header.php et footer.php du thème quasiment invisibles au quotidien.
Cette approche a une conséquence directe sur les performances : moins de CSS chargé par défaut, moins de sélecteurs à recalculer, une base de départ plus légère qu’un thème complet comme Astra ou GeneratePress avant même la première personnalisation.
Pourquoi ce choix a du sens pour Elementor
Un page builder comme Elementor génère lui-même énormément de CSS inline et de classes utilitaires pour chaque section construite visuellement. Si le thème sous-jacent impose déjà ses propres marges, ses propres tailles de police ou ses propres couleurs de liens, l’utilisateur du page builder se retrouve à devoir « combattre » le thème pour obtenir le rendu voulu. En repartant d’une base quasi nue, Elementor s’assure que ce que l’utilisateur voit dans l’éditeur correspond fidèlement à ce qui s’affiche en production.
Sur les projets où le client construit lui-même ses pages avec Elementor après la livraison, je recommande systématiquement Hello Elementor plutôt qu’un thème complet : ça m’évite de passer une heure à annuler des styles qui ne serviront jamais.
Les limites hors page builder
C’est là que l’équation s’inverse. Dès qu’on désactive Elementor, ou qu’on affiche un contenu qui ne passe pas par lui (un article de blog classique rédigé dans l’éditeur natif, par exemple), Hello Elementor montre immédiatement ses limites :
| Contexte | Rendu avec Hello Elementor seul |
|---|---|
| Page construite avec Elementor | Excellent, sans conflit de style |
| Article de blog en éditeur natif | Très pauvre, quasiment sans mise en forme |
| Site sans Elementor installé | Expérience minimaliste à la limite du cassé |
Un article de blog classique, sans mise en page Elementor, s’affiche avec une typographie de base sans hiérarchie visuelle travaillée. Le thème n’a tout simplement pas vocation à gérer ce cas seul : c’est un choix de conception, pas un bug, mais il faut le savoir avant de l’utiliser sur un site à forte composante éditoriale.
Notre verdict
Hello Elementor n’est pas un thème au sens traditionnel du terme : c’est une fondation technique pensée pour disparaître derrière le page builder qu’elle accompagne. Utilisé dans ce cadre précis, c’est un choix pertinent et performant. Utilisé comme thème généraliste sur un site éditorial classique, il révèle vite ses manques. La règle est simple : si Elementor pilote l’intégralité de vos pages, ce thème est un allié discret et efficace ; sinon, mieux vaut se tourner vers un thème plus complet.
