Bricks Builder vs Elementor : comparatif en profondeur de deux philosophies du constructeur WordPress

Deux constructeurs, deux visions du métier

Quand vous installez Elementor sur un site WordPress, il s'ajoute à votre thème. Quand vous installez Bricks, il remplace le thème. Cette différence d'apparence anodine contient, en germe, tout ce qui distingue les deux constructeurs. Performances, maintenabilité, expérience de développement, gouvernance, tarification : une fois le choix fait, tout le reste en découle.

La plupart des articles qui comparent Bricks et Elementor se contentent d'un tableau côte à côte des fonctionnalités. Cette approche passe à côté de l'essentiel. Bricks et Elementor ne sont pas deux versions du même produit. Ce sont deux réponses différentes à la même question, "comment construire un site WordPress sur mesure sans coder chaque pixel à la main ?", assorties de deux paris opposés sur ce que veut vraiment l'utilisateur.

Elementor parie sur l'accessibilité et la démocratisation. Bricks parie sur la performance, le contrôle et la transparence. Les deux ont raison dans leur registre. Ce comparatif essaie de dire honnêtement ce qu'implique chaque choix, en évitant le faux équilibrage qui domine ce sujet dans la plupart des blogs WordPress. Nous utilisons principalement Bricks chez MtoM Création depuis plusieurs années, et nous le disons clairement dans la conclusion. Le reste du texte essaie de vous donner les éléments pour faire votre propre choix en toute connaissance de cause.

De 2016 à aujourd'hui : deux histoires qui éclairent les choix actuels

Elementor, du plugin freemium au leader du marché

Elementor naît en 2016 en Israël, cofondé par Yoni Luksenberg, Ariel Klikstein et Yakir Sitbon. L'ambition initiale est simple : permettre à n'importe qui de construire des pages WordPress complexes en glisser-déposer, sans toucher au code. Le modèle économique est freemium, avec une version gratuite généreuse distribuée sur WordPress.org, et une version Pro payante pour les fonctionnalités avancées (formulaires, pop-ups, Theme Builder, widgets WooCommerce avancés).

Le succès est massif et rapide. Elementor devient en quelques années le plugin WordPress le plus installé au monde. La société revendique aujourd'hui plus de dix millions d'installations actives, et l'outil est traduit dans plus de soixante langues. Elementor a bénéficié de l'effet de réseau : plus il y a d'utilisateurs, plus il y a d'addons tiers, plus il y a de tutoriels, plus il y a de freelances capables de prendre un site en cours de route. C'est encore aujourd'hui l'un des arguments les plus forts de l'outil, particulièrement pour les projets où l'autonomie du client final compte.

Plusieurs décisions ont marqué la trajectoire du produit. En 2022, la fin des licences lifetime oriente Elementor vers un modèle purement SaaS, avec des abonnements annuels entre 59 et 399 dollars selon le nombre de sites. En 2024 et 2025, le focus produit se déplace vers la performance. L'équipe d'Elementor travaille sur une refonte complète de son moteur de rendu, baptisée atomic editor. Cette refonte aboutit à la sortie d'Elementor v4 fin mars 2026, devenu depuis avril 2026 le mode par défaut pour tous les nouveaux sites créés avec l'outil.

Elementor v4 est une rupture assumée. Chaque élément atomique ne produit plus qu'un seul <div> wrapper, contre plusieurs niveaux de div imbriqués dans la version 3. Un nouveau système de Classes permet de créer des styles réutilisables à l'échelle du site, à la manière de ce que proposent depuis longtemps les frameworks CSS modernes. Les Components introduisent des sections synchronisées, éditables individuellement mais avec une source de vérité commune. Atomic Forms, Atomic Tabs, Pro Interactions, Entrance Interactions : la nouvelle architecture casse les widgets monolithiques d'hier en éléments plus petits et plus composables.

La v4 cohabite avec la v3 sur les sites existants. C'est à la fois une force (rétrocompatibilité) et une contrainte : l'équipe porte désormais deux architectures en parallèle, ce qui a un coût en rythme d'évolution.

Bricks, naissance en réaction et trajectoire d'indépendant

Bricks est lancé en mars 2021 par Thomas Ehrig, développeur et designer web allemand qui publie déjà depuis plusieurs années des produits WordPress en indépendant. Avant Bricks, Ehrig avait sorti en 2014 un thème premium sur CreativeMarket nommé Worx, puis en mars 2020 un plugin populaire de gestion de médias appelé HappyFiles. Son approche du produit est clairement différente de celle d'une société qui lève des fonds : développement incrémental, modèle économique transparent, relation directe avec les utilisateurs.

Bricks est conçu dès le départ en réaction à ce qu'Ehrig identifie comme les limites des constructeurs WordPress existants : code de sortie lourd, dépendance à des addons tiers pour les fonctionnalités essentielles, opacité du développement produit. Trois décisions fondatrices structurent le produit.

La première : Bricks est un thème, pas un plugin. Ce choix a des conséquences techniques profondes (que nous détaillons plus bas), mais il reflète aussi une opinion sur le métier. Un constructeur qui occupe tout l'espace front-end peut générer du code propre, cohérent, prévisible, sans avoir à composer avec la couche de thème sous-jacente.

La deuxième : Bricks se vend en licence lifetime. Un paiement unique d'environ 99 dollars pour la version starter, jusqu'à quelques centaines de dollars pour une licence illimitée agence. Pas d'abonnement annuel, pas de renouvellement obligatoire pour continuer d'utiliser le produit. Le pari sous-jacent est celui de la confiance long terme et de la stabilité, plutôt que du revenu récurrent maximisé.

La troisième : la roadmap est publique et votée. Un ideas board permet aux utilisateurs de soumettre des demandes de fonctionnalités, que les autres peuvent upvoter. Les demandes les plus populaires remontent automatiquement dans la roadmap officielle. Nous reviendrons sur ce point, mais c'est probablement la décision la plus structurante de Bricks à moyen terme, et celle qui différencie le plus radicalement le produit dans l'écosystème WordPress.

La trajectoire de Bricks depuis mars 2021 est dense. La série 1.9 consolide les fondamentaux (queries, variables globales CSS, formulaires, enregistrement natif des soumissions). La version 1.12 introduit les Composants en mode expérimental. La version 2.0, sortie en 2025 après environ quatre ans de développement depuis la 1.0, sort les Composants de l'expérimental et active par défaut les CSS Cascade Layers pour une gestion native de la spécificité. La version 2.2, sortie début 2026, ajoute les Slots (placeholders dans les composants), les Style Variants (variations de style par composant), les Property Bindings (liaisons dynamiques entre propriétés d'éléments) et un Style Manager unifié. La version 2.3, actuelle, ajoute le collage direct de HTML/CSS (converti automatiquement en éléments Bricks natifs), un moteur de filtres de requêtes enrichi (datepicker, range, select, radio, checkbox), et des animations natives (parallax, scale3d, perspective). La direction est claire : Bricks se rapproche désormais d'un vrai « framework WordPress », avec une grammaire moderne (composants, slots, variantes, bindings) inspirée des frameworks front-end comme Vue ou React.

Un plugin sur un thème, ou un thème qui fait tout : le choix d'architecture

Cette différence est la plus importante du comparatif. Tout ce qui suit en découle.

Elementor est un plugin. Pour l'utiliser, vous installez WordPress, vous choisissez un thème (souvent le thème Hello édité par Elementor, ou un thème tiers léger), puis vous installez le plugin Elementor par-dessus. Le thème fournit les templates par défaut, la structure HTML de base, les styles génériques. Elementor s'insère au niveau du rendu des pages ou articles individuels. Il prend le contrôle de la zone de contenu, y injecte son propre rendu, et laisse le thème gérer le reste (header, footer, templates d'archive, single post, 404). Avec Elementor Pro, le Theme Builder permet aussi de prendre le contrôle de ces templates globaux, mais l'architecture fondamentale reste celle d'un plugin qui se superpose à un thème sous-jacent.

Bricks est un thème. Pour l'utiliser, vous installez WordPress, puis vous installez le thème Bricks et vous l'activez comme thème actif du site. Il n'y a pas de thème tiers sous-jacent. Bricks occupe tout l'espace de rendu : header, footer, contenu, archives, single posts, 404, recherche. Le Theme Builder de Bricks est intégré dès le départ, dès la licence Starter, sans abonnement Pro additionnel à prévoir.

Les conséquences de cette différence sont nombreuses et concrètes.

Conflits et imbrication. Un site Elementor combine un thème et un plugin qui se disputent parfois les priorités sur certains éléments (styles globaux, chargement des polices, spécificité CSS, scripts front-end). Les conflits sont rares mais réels, surtout avec des thèmes lourds ou opinionnés, ou avec certains plugins qui se superposent à la couche de rendu. Un site Bricks n'est pas exempt de tout conflit (les conflits entre plugins restent possibles, comme sur n'importe quel site WordPress), mais il évite par construction la classe spécifique des conflits thème / plugin de rendu, parce qu'il n'y a qu'une seule source de vérité pour l'affichage du front.

Sortie HTML. Historiquement, Elementor produit un code plus verbeux que Bricks, avec de nombreux <div> imbriqués autour de chaque widget pour gérer les options de mise en page (sections, colonnes, containers, widget wraps). Elementor v4 adresse ce problème frontalement avec l'architecture atomique, où chaque élément ne produit plus qu'un seul wrapper. Bricks, depuis le premier jour, produit un code natif avec des balises sémantiques choisies par l'utilisateur : un bouton peut être un <button>, un <a>, ou toute autre balise contextuellement pertinente. Le contrôle de la balise HTML de sortie est offert pour la quasi-totalité des éléments, ce qui est particulièrement précieux pour l'accessibilité et le SEO sémantique. La différence de poids HTML sur des mises en page identiques reste significative en 2026. Les benchmarks récents montrent Bricks environ 40 % plus rapide et 60 % plus léger en DOM que Elementor v3 sur des pages équivalentes. Elementor v4 réduit fortement cet écart. La question ouverte est de savoir dans quelle proportion, sur des benchmarks indépendants et à grande échelle, une fois la v4 en production mature.

Maintenabilité et indépendance. Sur un site Elementor, si vous désactivez un jour le plugin (pour migrer vers Gutenberg, un autre builder, ou reprendre le contrôle du thème), vous récupérez un site sans contenu de page. Tout ce qui a été construit dans Elementor disparaît, remplacé par des shortcodes illisibles dans la base de données. C'est un verrouillage structurel inhérent au modèle "plugin sur thème". Sur un site Bricks, le problème existe aussi (les templates sont stockés dans un format spécifique à Bricks), mais la portée est différente : un site Bricks est "un site Bricks", pas un site WordPress avec du Bricks dedans. L'enjeu de migration se pose au niveau du site entier, pas d'une portion.

Theme Builder inclus ou séparé. Sur Elementor, construire les templates globaux (header, footer, archive, single post) nécessite Elementor Pro, l'abonnement payant. Sur Bricks, ces templates sont disponibles dès la licence Starter. Cette différence a un impact pratique énorme pour une agence : sur Elementor, un site complet nécessite presque systématiquement Pro, alors que Bricks permet des sites complets dès l'entrée de gamme.

Aucun des deux choix n'est intrinsèquement supérieur. Un site Elementor sur un thème léger bien choisi fonctionne très bien. Un site Bricks fonctionne bien par construction. La question de fond : préférez-vous la flexibilité de combiner un thème et un constructeur (Elementor), ou l'intégration totale d'un outil qui occupe toute la chaîne de rendu (Bricks) ?

Le code qui sort : ce que Google et les navigateurs voient

L'un des critères les plus objectifs pour comparer deux constructeurs, c'est le code HTML qu'ils produisent. À mise en page identique, le builder qui génère un HTML plus léger, plus sémantique et moins imbriqué aura de meilleures performances (Core Web Vitals), un meilleur SEO technique, et une meilleure accessibilité.

Reprenons un exemple simple. Imaginons un bouton primaire avec un texte centré horizontalement dans une section.

Avec Elementor v3, le moteur historique encore présent sur l'immense majorité des sites en ligne, la sortie HTML ressemble à une succession de wrappers :

<section class="elementor-section elementor-top-section">
  <div class="elementor-container">
    <div class="elementor-row">
      <div class="elementor-column elementor-col-100">
        <div class="elementor-widget-wrap">
          <div class="elementor-widget elementor-widget-button">
            <div class="elementor-widget-container">
              <a class="elementor-button" href="#">
                <span class="elementor-button-content-wrapper">
                  <span class="elementor-button-text">Cliquez ici</span>
                </span>
              </a>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</section>

Chaque couche a un rôle (responsive, background, padding, alignement), mais l'ensemble produit un DOM très profond pour un simple bouton. Sur une page complète avec plusieurs dizaines de widgets, l'empilement devient significatif.

Avec Elementor v4 (atomic editor), cette imbrication est radicalement réduite. Chaque élément atomique produit un seul wrapper, et le système de Classes permet de mutualiser les styles sans multiplier les conteneurs. La différence de poids DOM par rapport à la v3 est substantielle selon les premières mesures publiées par Elementor et par la communauté, et l'entreprise en fait un argument central de sa communication produit. Des benchmarks indépendants à grande échelle, sur des sites v4 en production mature, restent à consolider.

Avec Bricks, le même bouton produit directement un <a> (ou un <button>, au choix de l'utilisateur dans l'interface) avec les classes appliquées et les attributs voulus :

<section class="hero">
  <a class="btn btn-primary" href="#">Cliquez ici</a>
</section>

Pas de wrapper superflu, sauf si l'utilisateur choisit explicitement d'en ajouter. Les classes sont celles que l'utilisateur a définies (classes globales ou classes locales), pas des classes techniques imposées par le builder.

En résumé. Elementor v3 produit un code lourd. Elementor v4 produit un code beaucoup plus proche de celui de Bricks. Bricks produit, depuis le premier jour, un code aussi propre que ce qu'un développeur écrirait à la main.

La question intéressante n'est pas "qui produit le meilleur code aujourd'hui", mais "qui a construit ses fondations sur la bonne hypothèse dès le départ". Bricks a fait ce choix dès 2021. Elementor a dû reconstruire en 2025-2026 pour rattraper le retard. Les deux peuvent désormais prétendre à un code propre, mais l'histoire des deux produits n'est pas la même, et les sites v3 en production (encore très majoritaires) portent toujours la dette de l'architecture historique.

Composants, slots, classes : la grammaire du travail moderne

Le web moderne s'est converti aux composants. React, Vue, Svelte, les web components natifs : toute la production front-end professionnelle des dix dernières années tourne autour de l'idée qu'un élément d'interface doit être défini une fois, testé une fois, utilisé partout, et modifié en un seul endroit pour se mettre à jour partout. Les constructeurs WordPress, longtemps en retard sur ce terrain, rattrapent aujourd'hui cette grammaire.

Composants : héritage synchronisé dans les deux camps

Bricks introduit les Composants dans sa version 1.12 en mode expérimental, puis les stabilise en production avec la version 2.0. Un composant Bricks est un groupe d'éléments que vous définissez une fois et que vous pouvez insérer plusieurs fois dans vos pages. Une modification au niveau du composant source se propage à toutes les instances. Les instances peuvent être légèrement personnalisées (textes différents, images différentes) via les Property Bindings introduits en 2.2, sans rompre la synchronisation structurelle.

Elementor introduit les Components dans la v4 (2026). La logique est comparable : une section réutilisable, avec synchronisation entre la source et ses instances, et personnalisation contrôlée par instance. Avant la v4, Elementor disposait de Templates (statiques, copie-coller à l'insertion) et de Global Widgets (synchronisés, mais réservés à Pro). La logique de composant propre, avec synchronisation complète et personnalisation contrôlée, est une vraie nouveauté de la v4.

Les deux approches convergent. La différence à ce stade (2026) tient surtout à la maturité de l'implémentation. Bricks a plusieurs années de retour d'expérience sur son système de composants. Elementor arrive avec sa v4 très récente. Sur le papier, les capacités sont similaires. En pratique, les usages avancés (composants imbriqués, bindings complexes, versionning de composants entre projets) sont plus stables chez Bricks aujourd'hui.

Slots : l'injection contextuelle de contenu

La version 2.2 de Bricks introduit les Slots, une évolution majeure du système de composants. Un slot est un emplacement réservé à l'intérieur d'un composant, dans lequel chaque instance peut injecter du contenu personnalisé. Concrètement, vous définissez un composant "Carte produit" avec un slot "contenu" au milieu, et chaque instance de la carte peut remplir ce slot avec les éléments de son choix (titre, description, bouton, badge), tout en conservant la structure, les styles et les marges définies au niveau du composant source.

La logique est directement inspirée des slots de Vue.js et des children de React. Pour un développeur habitué à ces frameworks, l'approche est immédiatement familière. Pour un utilisateur WordPress sans bagage front-end moderne, c'est une grammaire nouvelle mais qui s'apprend vite par l'usage, et qui débloque des patterns de conception impossibles avec des composants monolithiques.

Elementor v4 ne propose pas, à la date de cet article, un équivalent direct des slots. Les Components v4 synchronisent la structure et les styles entre instances, mais ne proposent pas, au même niveau de granularité, de zones d'injection libre comparables aux Slots de Bricks. Cet écart de design system pourrait être comblé dans les versions suivantes, mais la différence existe aujourd'hui.

Classes et variables : la base d'un vrai système de design

Une classe CSS réutilisable est la brique fondamentale de tout système de design moderne. Elle permet de définir un style une fois et de l'appliquer à autant d'éléments que nécessaire, avec une seule source de vérité pour les modifications ultérieures. Jusqu'à récemment, ni Elementor ni Bricks n'offraient cette notion de façon native : les styles se définissaient widget par widget, avec un bricolage de CSS custom pour mutualiser.

Bricks a introduit un gestionnaire de classes globales dans sa série 1.9, puis un Style Manager complet dans la 2.2, qui unifie les variables CSS, les classes globales et les styles de base dans une interface unique. Les variables CSS peuvent être définies au niveau global ou par breakpoint, et utilisées partout dans le builder via un picker contextuel. Combinées aux CSS Cascade Layers activés par défaut depuis la 2.0, elles offrent une gestion de la spécificité et de la mutualisation des styles qui n'a rien à envier aux frameworks CSS modernes.

Elementor v4 introduit un système de Classes similaire dans sa version atomique. La logique est la même (créer des collections de styles réutilisables), mais l'implémentation est plus récente et la documentation encore en construction au moment où nous écrivons. La promesse est là ; la maturité viendra avec les versions suivantes.

Sur ce terrain aussi, la convergence est réelle. Les deux constructeurs adoptent une grammaire proche de celle d'un développeur front-end moderne (composants, classes, variables, slots, bindings), avec plusieurs années d'avance pour Bricks et un rattrapage rapide mais récent pour Elementor v4.

L'expérience développeur : custom code, hooks, queries

Au-delà de l'utilisation standard du builder, la vraie différence entre les deux outils se révèle quand un développeur doit étendre le constructeur avec du code personnalisé : widgets sur mesure, interactions JavaScript avancées, requêtes de contenu dynamique.

Créer un widget ou un élément personnalisé

Créer un widget custom dans Elementor passe par l'extension de la classe \Elementor\Widget_Base. Le développeur doit implémenter une série de méthodes obligatoires : get_name(), get_title(), get_icon(), get_categories(), register_controls() (qui décrit l'interface de configuration dans le builder), et une méthode de rendu qui produit le HTML final. La documentation officielle sur developers.elementor.com est riche, avec des exemples simples et avancés. L'API est mature, stable, mais verbeuse. Un widget simple nécessite typiquement entre cent et deux cents lignes de PHP.

class My_Button_Widget extends \Elementor\Widget_Base {
    public function get_name() { return 'my-button'; }
    public function get_title() { return 'Mon bouton'; }
    public function get_icon() { return 'eicon-button'; }
    public function get_categories() { return ['general']; }

    protected function register_controls() {
        $this->start_controls_section('content', [
            'label' => 'Contenu',
        ]);
        $this->add_control('text', [
            'label' => 'Texte du bouton',
            'type' => \Elementor\Controls_Manager::TEXT,
            'default' => 'Cliquez ici',
        ]);
        $this->end_controls_section();
    }

    protected function render() {
        $settings = $this->get_settings_for_display();
        echo '<a href="#" class="my-button">' . esc_html($settings['text']) . '</a>';
    }
}

Créer un élément personnalisé dans Bricks passe par l'extension de la classe \Bricks\Element. Les méthodes à implémenter sont globalement équivalentes (get_label, set_controls, render), mais l'API est plus légère et le code plus dense, avec des helpers dédiés pour générer des attributs HTML propres.

class My_Button_Element extends \Bricks\Element {
    public $category = 'general';
    public $name = 'my-button';
    public $icon = 'ti-link';

    public function get_label() {
        return esc_html__('Mon bouton', 'bricks');
    }

    public function set_controls() {
        $this->controls['text'] = [
            'label' => esc_html__('Texte du bouton', 'bricks'),
            'type' => 'text',
            'default' => esc_html__('Cliquez ici', 'bricks'),
        ];
    }

    public function render() {
        $text = $this->settings['text'] ?? '';
        $this->set_attribute('_root', 'class', 'my-button');
        echo '<a ' . $this->render_attributes('_root') . ' href="#">' . esc_html($text) . '</a>';
    }
}

Les deux API sont parfaitement utilisables. Celle d'Elementor est plus documentée et plus canonique dans l'écosystème. Celle de Bricks est plus concise, et surtout elle produit un code de sortie plus directement contrôlable grâce à la méthode render_attributes qui facilite la génération d'attributs propres, d'attributs dynamiques et d'interactions natives. Pour une agence qui développe régulièrement des widgets custom, la différence se sent au quotidien dans la productivité.

Interactions et JavaScript

Sur le front-end, Elementor a historiquement reposé sur jQuery, ce qui pèse à la fois sur le poids JavaScript chargé et sur les performances d'interaction sur mobile bas de gamme. La v4 introduit les Pro Interactions (incluses dans l'abonnement Pro), qui offrent un nouveau moteur d'interactions natives (hover, click, scroll, entrée dans le viewport), mais l'ensemble reste dans une logique où beaucoup de comportements passent par du JavaScript spécifique Elementor, chargé globalement.

Bricks repose sur Vue.js côté builder et propose, côté front, un système d'interactions natif qui couvre la plupart des besoins (afficher/masquer, toggle de classe, lecture vidéo, lightbox, comportements au scroll) sans imposer de JavaScript personnalisé. Pour les interactions plus avancées, la structure propre du HTML généré par Bricks se prête bien à l'ajout d'Alpine.js, activable en un clic dans les réglages du thème ou chargeable manuellement selon les préférences. Cette combinaison offre une couche légère pour le conditionnel sans charger un framework lourd et sans sortir du builder.

La différence de poids JS est notable sur des pages riches en interactions. Bricks charge typiquement moins de JavaScript, mieux segmenté par page. Elementor v4 promet un rattrapage, à confirmer dans la durée sur des benchmarks indépendants.

Query Loops et données dynamiques

Afficher du contenu dynamique (derniers articles, produits WooCommerce, custom post types, relations entre entités) est une fonctionnalité clé pour tout site WordPress non trivial. Les deux constructeurs ont un moteur de requêtes, mais avec des niveaux de profondeur très différents.

Elementor propose les Loop Grid (réservés à Elementor Pro) et les Dynamic Tags pour insérer du contenu dynamique dans les widgets. Le moteur est fonctionnel mais moins flexible que celui de Bricks, et reste limité par le fait que certaines fonctionnalités clés (requêtes avancées, filtres AJAX, relations entre entités) ne sont accessibles qu'avec des addons tiers comme JetEngine de Crocoblock pour les cas d'usage complexes.

Bricks propose un Query Loop natif sur la quasi-totalité des éléments conteneurs, avec une interface de requête très riche (post types, taxonomies, méta-champs, relations ACF, filtres AJAX, ordre custom, pagination). La version 2.3 ajoute des contrôles de filtres de requêtes (datepicker, range, select, radio, checkbox) qui rendent le système quasiment équivalent à ce qu'offre un plugin spécialisé, sans dépendance externe. Pour un site éditorial, un annuaire, un catalogue produit ou tout site avec de la donnée à filtrer et afficher dynamiquement, la différence de productivité est tangible.

La roadmap et le modèle de gouvernance

Ce point est, d'après notre expérience, le différenciateur le plus sous-estimé entre les deux écosystèmes. Il ne concerne pas le produit d'aujourd'hui, mais la direction que prendra le produit dans les années à venir, et surtout l'influence que l'utilisateur aura sur cette direction.

Bricks publie une roadmap publique (accessible sur bricksbuilder.io/roadmap/) et un ideas board (sur bricksbuilder.io/ideas/) directement reliés. N'importe quel utilisateur peut soumettre une demande de fonctionnalité. Les autres utilisateurs votent et commentent. Les demandes qui rassemblent le plus d'upvotes remontent dans la roadmap officielle après revue par l'équipe. La philosophie revendiquée par Thomas Ehrig est que les décisions produit doivent être pilotées par les besoins exprimés de la communauté, avec des arbitrages explicites plutôt qu'une priorisation interne opaque.

En pratique, cela signifie que beaucoup des fonctionnalités livrées dans les dernières versions (parmi lesquelles les Slots de la 2.2, les contrôles de filtres de la 2.3, les Style Variants, le collage HTML/CSS) correspondent à des demandes communautaires qui avaient accumulé des votes significatifs sur l'ideas board. C'est vérifiable, public, traçable. Chaque utilisateur peut voir quelles idées sont acceptées, lesquelles sont en cours, lesquelles sont sorties, et combien d'autres utilisateurs partagent son besoin.

Elementor fonctionne sur un modèle de roadmap fermée. Les décisions produit sont prises en interne, avec des retours communautaires sollicités ponctuellement (beta programs, feedback sur les blog posts, écoute des communautés Facebook officielles), mais sans mécanisme structurel de priorisation par les utilisateurs. Les décisions sont cohérentes et souvent bonnes, mais ce sont les décisions d'une entreprise qui sert un marché de dix millions d'installations actives, avec toutes les contraintes business que cela implique : maintenance de l'existant, rétrocompatibilité, positionnement produit, partenariats, priorités commerciales.

Ce que ça change concrètement pour vous. Si vous êtes une agence qui construit sur WordPress pour les cinq ou dix prochaines années, la question n'est pas "quel outil est le meilleur aujourd'hui", mais "lequel évoluera dans la direction qui sert mon travail". Chez Bricks, vous avez un canal direct pour influencer les priorités. Si une fonctionnalité vous manque, vous pouvez la demander, rassembler des votes, et voir concrètement l'impact sur la roadmap. Chez Elementor, vous êtes un utilisateur parmi des millions d'un produit commercial, dont les priorités de développement reflètent celles d'une base beaucoup plus large et beaucoup plus grand public.

Aucune approche n'est meilleure dans l'absolu. Un produit piloté par sa communauté peut manquer de cohérence stratégique long terme ou dériver vers du feature creep. Un produit piloté en interne peut rater des besoins importants mais peu visibles depuis le siège. Mais pour un professionnel qui construit des sites à la chaîne et qui veut une prise sur l'outil avec lequel il travaille, la transparence de la gouvernance Bricks est, d'après notre expérience, un atout majeur rarement mis en avant dans les comparatifs.

Prix, modèles économiques, écosystème

Modèles économiques

Elementor fonctionne exclusivement sur abonnement annuel. La version gratuite reste distribuée sur WordPress.org, avec des fonctionnalités substantielles (glisser-déposer, widgets de base, mise en page responsive). Mais pour construire un site professionnel complet, Elementor Pro est pratiquement incontournable, parce qu'il contient le Theme Builder (templates globaux), les formulaires, les pop-ups, les Loop Grid et les widgets avancés.

Les plans Elementor Pro débutent à 59 dollars par an pour un site, montent à 99 dollars pour 3 sites, 199 dollars pour 25 sites, et jusqu'à 399 dollars par an pour 1000 sites. Les licences lifetime historiques ont été supprimées en 2022. Pour une agence qui gère une cinquantaine de sites clients, le coût annuel récurrent se situe autour de 200 à 400 dollars par an selon le plan choisi, et il faut continuer de payer pour recevoir les mises à jour et le support. Un site existant continue de fonctionner si l'abonnement expire, mais sans nouvelles mises à jour ni accès aux templates Pro.

Bricks fonctionne exclusivement sur licence lifetime. Un paiement unique, pas d'abonnement récurrent obligatoire. Les tarifs débutent autour de 99 dollars pour la licence Starter (un site), montent à environ 249 dollars pour la licence Unlimited (sites illimités), et à quelques centaines de dollars pour la licence Agency (sites illimités avec support prioritaire et accès early adopter). Une fois la licence achetée, vous continuez de recevoir les mises à jour pendant la durée d'abonnement aux mises à jour (typiquement un an inclus, puis prolongation optionnelle). Le site fonctionne à vie, même sans renouveler.

Sur la durée, la différence de coût est significative pour une agence. Cinq ans de licence Elementor Pro pour 25 sites représentent environ 1000 dollars cumulés. Cinq ans de Bricks Unlimited représentent environ 249 dollars initiaux, plus d'éventuelles prolongations optionnelles des mises à jour. Pour un freelance ou une petite agence, le rapport est encore plus favorable à Bricks. Pour une grande agence avec beaucoup de sites et des exigences de support élevées, la différence se resserre.

Écosystèmes d'addons

Le choix d'un constructeur WordPress, c'est aussi le choix d'un écosystème de produits tiers qui étendent ses capacités. Sur ce terrain, les deux outils ne jouent pas dans la même cour.

Elementor dispose de l'écosystème le plus riche du marché WordPress page builder, de très loin. Happy Addons, Essential Addons, PowerPack, Ultimate Addons : plusieurs dizaines d'addons gratuits ou payants ajoutent des widgets, des templates, des fonctionnalités spécialisées. Crocoblock, avec sa suite JetEngine, JetSmartFilters, JetBooking, JetFormBuilder, JetAppointments, est probablement l'addon le plus complet pour les sites complexes (e-commerce sur mesure, catalogues filtrables, réseaux sociaux internes, réservations, annuaires). Cet écosystème est l'un des arguments les plus forts d'Elementor pour les projets qui sortent du standard et nécessitent des fonctionnalités pointues rapidement déployables.

Bricks a un écosystème plus restreint mais de grande qualité. Bricksforge (interactions avancées, animations, formulaires, intégrations), Advanced Themer (productivité du builder, gestion des classes et variables, pipettes, outils designer), BricksExtras (widgets custom, breakpoints avancés), Automatic.css (framework CSS intégré au builder), Frames (bibliothèque de sections pré-conçues), Max Addons et quelques autres. Chacun de ces produits est développé par des équipes réduites, maintenu sérieusement, et se vend généralement en lifetime comme Bricks lui-même. L'ensemble forme un écosystème cohérent et en croissance, mais moins dense et moins généraliste que celui d'Elementor.

Le choix d'écosystème doit être aligné avec votre profil. Si vous construisez régulièrement des sites complexes qui nécessitent des fonctionnalités spécialisées (réservations avancées, filtres dynamiques très riches, interactions sophistiquées entre custom post types, produits numériques avec logique de licence), l'écosystème Elementor + Crocoblock vous donnera plus de billes plus vite. Si vous préférez un écosystème cohérent où chaque addon s'intègre proprement avec les autres, sans surcharge et sans conflits d'interface, Bricks vous servira mieux.

Pour qui, quand, pourquoi

Plutôt qu'un verdict qui voudrait trancher une fois pour toutes, voici une grille de lecture par profil et par contexte.

Vous êtes une TPE ou une PME pour qui la continuité du support compte plus que la performance brute. Elementor a un avantage net sur ce terrain, non pas parce que son interface est intrinsèquement plus facile que celle de Bricks (les deux sont visuelles et utilisables par un non-développeur après formation), mais parce que son écosystème externe est beaucoup plus large. Tutoriels en français par milliers, formations en ligne, communauté Facebook très active, pool massif de freelances capables de reprendre le site si votre prestataire devient indisponible. Si vous voulez pouvoir faire appel à n'importe qui pour intervenir dans deux ans, Elementor vous donne mécaniquement plus d'options. Bricks a une communauté dynamique et croissante, mais la probabilité de trouver un freelance disponible à Lille ou à Trois-Rivières reste plus faible qu'avec Elementor.

Vous êtes une agence web qui cherche la meilleure combinaison performance, contrôle du code et tarification long terme. Bricks est, depuis quelques années, le choix qui s'impose progressivement dans les agences orientées qualité technique. Le code propre dès le départ, le Theme Builder intégré sans upsell, la licence lifetime, la gouvernance transparente et l'écosystème d'addons bien conçus forment un ensemble difficile à battre pour un studio qui construit à la chaîne et qui reste propriétaire de ses sites plusieurs années.

Vous êtes développeur ou développeuse WordPress. Bricks offre une expérience plus fluide pour les tâches custom : widgets PHP propres, interactions natives bien pensées, Query Loop flexible, sortie HTML contrôlée, intégration naturelle avec Alpine.js. Elementor v4 comble une partie de l'écart sur l'architecture, mais l'écosystème développeur de Bricks reste plus aligné avec les pratiques front-end modernes.

Vous construisez un e-commerce standard avec WooCommerce. Les deux outils conviennent, avec un léger avantage à Bricks sur les performances et la propreté du code. Catalogue, variations, panier, paiement, filtres simples : Bricks couvre tout nativement et produit un code plus propre. Pas de raison particulière de choisir Elementor dans ce scénario.

Vous construisez un e-commerce non standard. Relations complexes entre entités (marketplace, catalogue multi-dimensions, configurateur, annuaire produits-marques-artistes), filtres facettés très riches avec comptages dynamiques, réservations et créneaux horaires intégrés, workflows spécifiques liés à des Custom Post Types : l'écosystème Elementor + Crocoblock (JetEngine pour les CPT et relations, JetSmartFilters pour les filtres AJAX avancés, JetBooking pour les réservations, JetWooBuilder pour les templates produit poussés) offre des briques prêtes à l'emploi qui raccourcissent significativement le temps de développement. Sur Bricks, ces mêmes besoins sont faisables mais demandent plus d'assemblage de plugins externes ou de code custom. C'est le seul scénario où nous recommandons régulièrement Elementor sur Bricks.

Vous bâtissez un projet à horizon long (cinq ans ou plus). Le choix de modèle économique pèse. La licence lifetime de Bricks vous protège contre l'inflation des abonnements annuels. La roadmap votée vous donne de la prise sur la direction future du produit. Les licences Elementor Pro vous engagent sur des renouvellements annuels qui se cumulent dans le temps. L'écart financier sur dix ans est substantiel pour une agence.

Vous démarrez aujourd'hui un nouveau projet et vous hésitez. Installez les deux en local, une demi-journée chacun. Construisez la même page de démonstration dans chaque outil, codez un petit widget custom sur chaque plateforme, générez le HTML de sortie avec la console navigateur, consultez les roadmaps publiques de chaque produit. Le choix qui vous apparaîtra naturel après cette mise en main dépendra moins des arguments théoriques que de votre propre manière de travailler et de votre sensibilité au rapport entre contrôle et accessibilité.

Deux routes, pas un duel

Bricks et Elementor ne sont pas deux versions concurrentes du même produit. Ce sont deux manières de penser la construction WordPress visuelle, avec deux histoires, deux philosophies, deux modèles économiques, deux écosystèmes. Les opposer frontalement comme le font la plupart des comparatifs en ligne passe à côté de ce qui compte vraiment : comprendre ce que chaque outil a choisi d'optimiser, et confronter ces choix à votre propre manière de travailler.

Chez MtoM Création, nous travaillons principalement avec Bricks pour la création de sites web. Le code propre dès la première ligne, la grammaire moderne (composants, slots, variables, classes, bindings), la transparence de la roadmap votée par la communauté et le modèle lifetime s'alignent avec ce que nous attendons d'un outil structurant pour une agence. Nous n'avons pas trouvé, à ce jour, d'argument suffisant pour revenir en arrière. Mais nous reconnaissons sans réserve qu'Elementor reste un excellent choix dans deux contextes précis. D'abord pour les clients qui souhaitent une autonomie maximale post-livraison, grâce à la taille de sa base de tutoriels et au nombre de freelances capables de reprendre un site en cours de route. Ensuite pour les projets e-commerce non standards qui tirent parti de l'écosystème Crocoblock (relations entre entités, filtres facettés avancés, réservations intégrées, configurateurs), où les briques prêtes à l'emploi de JetEngine, JetSmartFilters et JetBooking raccourcissent significativement le temps de développement par rapport à un assemblage équivalent sur Bricks.

Si cet article vous a aidé à comprendre ce qui distingue vraiment les deux outils au-delà des tableaux interchangeables qui dominent le web, il a fait son travail. Le bon choix n'est pas le plus populaire ni celui qui apparaît le plus souvent dans les comparatifs. C'est celui qui correspond à votre métier, votre rythme, votre rapport au code, et votre horizon de travail. Si vous hésitez encore après lecture, nous sommes joignables pour une discussion concrète sur votre contexte. Nous partageons ce que nous savons, sans vendre ce qui ne vous servira pas.