24 raisons de ne pas utiliser Elementor et Divi

Ce guide est destiné aux professionnels, ceux dont la création de sites web est le métier (ou qui ont pour projet d’en faire leur métier), notamment les freelances et agences.

Cet article va piquer, mais il est nécessaire.

Quand on envisage de créer un site sous WordPress et qu’on cherche sur internet quel page builder utiliser, on tombe toujours sur les mêmes :

• Elementor
• Divi
• … et c’est tout.

Ce sont de loin les deux plus répandus, on n’entend jamais parler des autres, comme s’ils n’existaient pas.

Mais voilà le problème : si vous créez des sites pour vos clients, Elementor et Divi sont les pires choix possibles.

Oui, vous avez bien entendu.

Les deux page builders utilisés par 99% des agences web ne sont pas du tout adaptés pour la création de sites professionnels.

C’est une affirmation lourde, qui va à l’opposé de tout ce que vous pouvez lire et entendre sur internet, alors vous vous doutez bien qu’on n’avance pas ça sans raison.

Ceci n’est pas un article “putaclic” pour buzzer. Il est long, détaillé et argumenté. Si vous vous donnez la peine de le lire en entier, vous comprendrez que ça tombe sous le sens.

L’objectif d’un page builder

Premièrement, il faut rappeler quel est l’objectif d’un page builder, pourquoi on les a créés ?

On ne parle pas des fonctionnalités que doivent avoir les page builders, mais de leur raison d’être, leur objectif principal “philosophiquement” parlant.

Et le voici :

Un page builder doit aider les freelances et agences à créer des sites plus facilement et plus rapidement.

• Plus facilement, car s’il y a des aspects techniques que vous ne maitrisez pas, un page builder peut combler certaines de ces lacunes.
• Plus rapidement, car même pour un développeur qui maitrise la partie technique, c’est toujours plus rapide de faire un site via l’interface visuelle du builder.

Fondamentalement, on utilise donc un page builder pour augmenter sa rentabilité, car il nous permet de pouvoir prendre des missions qu’on ne saurait pas faire avec du code pur, et pouvoir livrer plus de projets dans un temps donné.

Gardons ça en tête, la raison d’être d’un page builder est donc de pouvoir créer des sites plus facilement et plus rapidement.

Ce qu’un Page Builder ne doit pas faire

Un page builder ne doit pas vous encourager à :

• Prendre des mauvaises décisions qui impacteront le site et l’entreprise de votre client
• Faire des choses qui vont à l’encontre des bonnes pratiques de web design

Maintenons qu’on a clarifié l’objectif d’un page builder, passons à l’objectif du site que vous construisez.

Quel est l’objectif du site que vous construisez ?

Faisons généraliste.

Pour une entreprise, la raison d’être de son site est de gagner en visibilité, d’attirer plus de clients et au final d’augmenter ses ventes (ne serait-ce pas le slogan sur notre page d’accueil ? 😉).

Et pour ça, le site que vous créez doit :

• Permettre à votre client d’atteindre son objectif (augmenter son CA, gagner en visibilité, augmenter son panier moyen, trouver plus de leads…)
• Permettre un contrôle total sur son contenu
• Nous laisser autant de liberté qu’un site codé à la main
• Être facile à maintenir
• Être facile à faire évoluer
• Être dynamique
• Ne jamais nous bloquer pour l’un des points ci-dessus

Le page builder qu’on va utiliser devra donc remplir toutes ces conditions. Maintenons, attardons-nous un peu sur la notion de professionnalisme en web design, on en aura besoin pour la suite.

Professionnalisme VS amateurisme

Pour rappel, ce guide est destiné aux professionnels, ceux dont la création de sites web est le métier (ou qui ont pour projet d’en faire leur métier), notamment les freelances et agences.

Vous n’êtes pas concerné par ce qui va suivre si vous créez des sites :

• pour vous-même
• pour dépanner un entrepreneur qui se lance
• pour dépanner quelqu’un de votre famille
• pour aider une association qui n’a pas de budget
• comme un passe-temps

Par contre, à partir du moment où il y a un enjeu commercial, vous rentrez dans la catégorie des professionnels, et en tant que professionnel, vous avez des comptes à rendre a votre client :

Vous devez créer la meilleure solution possible pour que votre client puisse atteindre ses objectifs avec son site (voir la liste ci-dessus).

Voilà la différence entre l’amateur (ce n’est pas condescendant) et le professionnel.

Cette différence se traduit notamment dans le choix des outils que vous allez utiliser. Il existe des page builders pour les amateurs et des page builders pour les professionnels.

Si ça ne vous semble pas encore clair, voici une comparaison qui vous aidera à bien comprendre la différence. 👇

Les photographes ne travaillent pas avec des iPhone

Comparons le monde des web designers avec le monde des photographes.

Il est tout à fait possible de prendre de très jolies photos avec un iPhone. L’iPhone est fait pour être facile à utiliser pour n’importe qui et est préconfiguré pour toujours sortir des photos de bonne qualité.

La seule chose qu’il y a à faire, c’est cadrer et appuyer sur le bouton pour prendre la photo.

Pour les utilisateurs qui le souhaitent, il est même possible de switcher parmi les différents objectifs intégrés au téléphone, zoomer, recadrer, appliquer un filtre, voir appliquer un preset sur photoshop…

… et pourtant, avez-vous déjà vu un photographe travailler avec un iPhone ? Évidemment que non. Mais pourquoi ?

Le problème de l’iPhone, c’est qu’il a des limitations techniques intrinsèques qui l’empêchent d’atteindre le niveau d’un appareil photo professionnel, même si c’est un photographe qui l’utilise.

Un appareil photo professionnel donne un contrôle total sur tous les aspects techniques :

• Ouverture
• Vitesse d’obturation
• ISO
• Balance des blancs
• Flash
• Profondeur de champ
• Choix de l’objectif
• Lumière dans le studio
• Format des fichiers
• et bien plus encore

Un photographe professionnel sera aussi capable de retoucher lui-même la photo en postproduction exactement comme il le souhaite, plutôt que de chercher un filtre ou un preset qui ne fera pas exactement ce qu’il veut.

C’est pour ça que le photographe investit dans un appareil photo à plusieurs milliers d’euros.

L’appareil photo qu’il choisira lui permettra d’atteindre tous les objectifs de ses clients, même les plus spécifiques, de sorte à avoir un contrôle total sur ces photos et livrer le travail le plus qualitatif possible a ses clients.

Avec un appareil photo professionnel, le photographe va pouvoir créer précisément la photo qu’il avait en tête, celle dont le client avait besoin.

Avec un iPhone, ce sera plus rapide et plus facile, mais c’est l’iPhone qui va choisir le rendu de la photo, pas le photographe, même s’il est expérimenté.

Même si le photographe pourra probablement prendre de plus jolies photos à l’iPhone qu’une personne lambda, il sera trop limité par l’outil qu’il utilise, comparé à un appareil photo professionnel.

C’est exactement pareil pour les page builders. Elementor et Divi ont (beaucoup) trop de limitations techniques qui vous empêchent d’avoir la main sur tout ce qu’il faudrait pour pouvoir faire un site “professionnel”.

Ça ne veut pas dire qu’ils ne doivent pas exister, tout le monde n’a pas les compétences pour utiliser un builder professionnel, de la même manière qu’on ne sait pas tous utiliser un appareil photo professionnel.

Par contre, quand c’est notre métier, c’est obligatoire.

Quels page builders sont adaptés aux professionnels ?

Pour savoir si votre page builder est légitime, regardez les 24 points qui vont suivre, ce sont pour nous les points INDISPENSABLES qu’un page builder doit respecter pour pouvoir être considéré comme professionnel.

Cette liste est objective, elle définit d’abord les critères d’un builder professionnel, puis elle s’intéresse ensuite aux builders qui remplissent ces critères. Il n’y a pas de lien affilié ou de conflits d’intérêts.

Chez Partenaire du Web, on a choisi notre page builder APRÈS avoir vérifié cette liste, et non l’inverse.

Si vous avez la flemme de lire, voici les résultats :

1. Bricks et Oxygen se démarquent de loin des autres page builders, tous les points indispensables sont respectés.
2. Cwicly, Breakdance et Zion sont pertinents, mais il manque encore certaines fonctionnalités cruciales.
3. Tous les autres page builders ne sont pas adaptés aux professionnels (Elementor, Divi, Beaver Builder, WP bakery, Site Origin…)

Chez Partenaire du Web, nous avons commencé avec Oxygen en 2020, et nous avons switcher en 2024 chez Bricks.

On vous conseille quand même de lire les points qui vont suivre pour comprendre notre classement.

1 – Div vide

La div, c’est l’élément le plus basique qui existe en HTML, c’est simplement un conteneur dans lequel on va placer du texte, des images, etc. Par défaut, elle est censée être vide et n’avoir aucun style.

En web design, tout est basé sur le modèle des boîtes (flexbox, grid, …). On met des éléments dans des boîtes et on les positionne par rapport à d’autres boîtes. Une div est simplement une boîte.

C’est sur ce principe que fonctionnent également les outils pour créer des maquettes comme Figma.

Le problème c’est que la plupart des page builders ne proposent même pas ce simple élément, qui est pourtant le fondement du web design.

Dans le but de rendre la création de site plus accessible, ils vont proposer des “blocks”, des “box”, des “containers” ou autre élément qui n’existe pas dans le DOM, avec des styles indésirables déjà appliqués par défaut, mais pas de simple div vide.

Lorsque vous ajouterez un texte, une image, ou n’importe quel élément, il sera déjà wrappé dans plusieurs div toutes prêtes, sans que vous n’aillez la main dessus.

En faisant ça, on doit déjà faire des concessions sur :

• Le rendu du site
• Son architecture
• Le DOM
• On se retrouve avec plein de div automatiquement générées par le builder avec du CSS indésirable et non supprimable
• On perd une partie de son contrôle
• On compromet l’accessibilité, la clarté du DOM, donc le SEO
• etc.

Mais surtout, on rend sa maintenabilité et son évolutivité plus difficile. On aura l’occasion de reparler de ça tout le long de ce guide.

Divi et Beaver Builer par exemple, ne proposent pas de div vide. Pourtant, pour Divi, c’est dans son nom.

Ce n’est pas même pas une fonctionnalité “professionnelle”, c’est juste fondamental. La preuve : tous ces pages builders génèrent bien des div au final sur la page, alors pourquoi ne pas laisser la possibilité d’en créer soit même ?

Oxygen est et Bricks proposent la div vide. Dans Bricks, il est même possible de choisir entre soit une div vide, soit un block ou un container, qui sont simplement des div avec du CSS par défaut et configurable selon le besoin pour gagner du temps, mais rien n’est imposé.

C’est pourtant rien de sorcier ! 🧙

2 – Classes CSS, pseudo-classes et pseudo-éléments

Les classes

Les classes CSS, c’est littéralement la deuxième ou troisième leçon qu’on apprend dans n’importe quelle formation HTML / CSS, juste après les div. C’est la base de la base du web design, elles permettent de :

• créer un site scalable, facile à maintenir et à faire évoluer dans le temps
• développer plus rapidement
• organiser la structure de son site

Comme pour les div, Elementor et Divi génèrent des classes, mais sans vous y donner accès.

Divi, par exemple, fonctionne avec des classes, mais vous ne pouvez pas les créer, les modifier ou les supprimer. Ils ont leur propre système interne, qui au final, repose bien sur les classes, c’est donc bien qu’elles sont nécessaires.

Elementor quant à lui, permet bien d’ajouter des classes a un élément, dans un champ bien caché, mais ne vous permet pas d’ajouter des styles à cette classe, tous les styles ajoutés le seront à cet élément précis uniquement.

Le développement de manière générale n’est pas “orienté classes” et ne permet pas de profiter de leur flexibilité.

Question praticité, gain de temps et maintenabilité, on ne peut pas faire pire.

Vous aurez à gérer vos styles en dehors du builder, potentiellement dans un autre plugin, et cela vous obligera en plus à écrire du CSS, alors que le but d’un page builder est justement de -entre autres- pouvoir générer du CSS rapidement en cliquant sur des boutons, le tout centralisé au même endroit.

Un builder digne de ce nom devrait vous encourager a travailler avec des classes. C’est une bonne pratique, mais c’est surtout encore une fois le b-a-ba du web design, c’est ce qui permet d’avoir un contrôle global sur le site.

Votre client, il attend de la part d’un professionnel que son site lui fasse gagner en visibilité et lui rapporte des leads, et pour ça, il a besoin que son site soit scalable, dynamique, facile à maintenir et à faire évoluer dans le temps au fur et à mesure que son business se développe.

Il ne veut pas être bloqué un jour. Il ne sait pas le verbaliser, mais c’est bien de ça dont il a besoin. Et devinez quoi ? L’absence d’accès facile aux classes va toujours résulter en un site qui :

• ne sera pas scalable
• ne sera pas dynamique
• sera difficile à maintenir

Et qui va en pâtir ? Votre client, qui ne comprendra pas pourquoi vous lui facturez une demi-journée de travail pour une modification qui aurait pris 5 minutes si le site avait été conçu avec des classes.

Et on ne parle même pas des sites multilingues utilisant Polylang, pour lesquels l’absence de classes se fait encore plus ressentir.

Pseudo-classes et pseudo-éléments

On passe très rapidement sur les pseudo-classes et les pseudo-éléments. Excepté le :hover qui est en général pris en charge par tous les builders, du moins sur certains éléments, on n’aura jamais accès aux :

• :first-of-type
• :last-of-type
• :nth-child
• ::before
• ::after
• etc.

La seule façon de le faire sera de passer par du CSS, mais pour rappel, vu que vous ne pouvez pas facilement personnaliser vos classes, comment cibler facilement vos éléments quand ils sont générés dynamiquement ? Comment faire si le contenu sur la page évolue ?

Encore une fois, la maintenabilité du site est remise en question.

Dans Bricks et Oxygen, il est possible de choisir si l’on veut appliquer nos styles sur l’#ID de l’élément, ou sur l’une de ses classes. Il est également possible de manager les classes et les styles de plein de manières différentes grâce à un menu contextuel.

Il existe d’ailleurs des plugins pour Bricks comme “Advanced Themer” qui ont une option pour complètement désactiver le style des #ID pour forcer à travailler sur les classes.

Si on résume pour le moment, vos deux outils préférés ne vous permettent ni :

• d’utiliser une div vide
• d’utiliser les classes

… alors que les deux sont pourtant bien générés au final sur la page.

Rien qu’avec ces deux points, vous perdez déjà complètement le contrôle du site que vous créez. Ca devrait déjà être suffisant pour bannir ces outils de n’importe quelle agence web.

Comprenez bien que ce n’est pas du chipotage, les div et les classes sont le fondement du web design, c’est comme ça que fonctionnent tous les outils de webdesign professionnel, et si WordPress le permet, comme Webflow et tant d’autres, ce n’est pas pour rien, il faut les utiliser.

Et on est encore loin d’avoir fait le tour.

3 – Sections et inner section

Une section est simplement une div avec une balise HTML <section>. La plupart des builders proposent ce type de composant, mais très peu vous permettent d’accéder à facilement l’inner section.

L’inner section est le container directement enfant d’une section, dans lequel on va ajouter tout notre contenu. Les seuls styles censés être préappliqués sont un réglage de layout sur la section, ainsi qu’un max-width et un padding sur le container. Tout le reste doit être vide par défaut.

Cela permet d’ajouter immédiatement du contenu dans sa section en s’assurant que tout sera parfaitement aligné et responsive.

Hélas, dans un souci de “simplifier” le processus, bien souvent l’inner section est inaccessible, rendant compliqué la création de section avec un design spécifique.

De plus, il y a souvent de nombreux styles indésirables appliqués sur ces éléments, car le builder veut nous forcer à faire les choses dans une direction spécifique, comme utiliser des colonnes ou autre, alors qu’il ne faut pas.

Dans Bricks, un container faisant office d’inner section est directement ajouté comme enfant direct lorsqu’on ajoute une section, les deux sont bien distinct et personnalisables.

Oxygen ne permet pas un accès direct au inner section, mais il est néanmoins facile d’y accéder grâce à son approche orientée classes, et aux styles par défaut que l’on peut définir sur les sections (de même pour Bricks).

4 – La création de templates

Un builder digne de ce nom doit vous laisser la possibilité de créer autant de templates que vous voulez et de les utiliser de manière conditionnelle en fonction du type de contenu à afficher.

On ne parle pas de faire du rendu conditionnel sur un template, mais bien d’en créer plusieurs et de pouvoir les utiliser sur le bon type de contenu de manière conditionnelle.

Voici les conditions qu’on doit pouvoir spécifier à un builder pour qu’il sélectionne le bon template :

• le fichier de template actuel (archive, single…)
• le type de publication
• la taxonomie
• la valeur d’un champ meta
• la combinaison des quatre
• n’importe quel autre contexte (utilisateur connecté, valeur d’un cookie …)

Le fait de pouvoir spécifier un ordre de priorité lorsque plusieurs templates correspondent à une condition est également un plus.

La plupart des builders proposent la création de templates, mais peu laissent autant de flexibilité dans la manière de les utiliser. Souvent, on doit se contenter de choisir le type de fichier template et le type de publication.

Bricks est probablement le plus permissif sur ce point, d’autant plus qu’on peut configurer nos propres fonctions PHP pour définir la condition d’affichage du template, on n’a donc aucune limite.

5 – Balises HTML custom

Étant donné qu’on a compris qu’il fallait éviter les éléments tout prêts et privilégier les div vides, il faut bien qu’on soit en mesure de choisir la balise HTML qu’on applique à nos div.

Votre builder doit vous laisser la possibilité de switcher entre une balise <div>, <section>, <article>, <ol>, <ul> etc.

La plupart des freelances qui utilisent Elementor et Divi ne savent même pas quel est l’intérêt d’utiliser une balise <article> dans une boucle WordPress, après tout “ça ne change rien au site“.

Même chose pour les textes, on doit pouvoir être capable de passer d’un <p> à un <li> sans friction, insérer des <span> à l’intérieur de nos textes sans devoir utiliser un élément de code block, utiliser des <figure> pour nos images…

Et il n’est pas question de simplement pouvoir choisir un tag HTML parmi une sélection dans une liste déroulante, on doit pouvoir utiliser nos propres balises custom si besoin.

Elementor et Divi sont trop limités. À titre de comparaison, dans Bricks, voici la liste des balises possibles en un clic pour un simple élément texte. Il est aussi possible d’ajouter une balise custom et la remplir avec une donnée dynamique.

De plus, il est possible d’insérer une span ou n’importe quelle autre balise inline comme <br>, <em> ou autre simplement en la mettant dans un champ texte, comme montré sur l’image.

Ne pas le faire, c’est complexifier la compréhension de votre page par le navigateur et par Google, donc ce qui pénalise le SEO de votre client. C’est donc un point crucial.

6 – HTML Attribut

De la même manière que les classes, votre builder doit vous laisser la possibilité d’ajouter n’importe quel type de data-attribut, choisir son libellé, sa valeur, et y insérer des données dynamiques, y compris dans une boucle WordPress.

• Elementor ne permet d’ajouter ces attributs que sur quelques éléments, et même pas de manière dynamique.
• Quant à Divi, ce n’est possible que via une extension tierce (Divi supreme) pas très flexible.

C’est pourtant d’autant plus important vu que ces builders ont tendance à ajouter du CSS parfois directement dans l’ID, laissant donc comme unique alternative d’écrire du CSS dans les data-attribut pour écraser leur priorité.

C’est aussi important afin de régler des problèmes de CLS (Cumulative Layout Shift) afin de passer les Core Web Vitals, ça a donc un intérêt en termes de SEO également…

… mais ça, ce sont des choses dont les amateurs ignorent complètement l’existence, c’est pour ça qu’ils ne voient pas de problème à utiliser Divi et Elementor.

Et on ne parle même pas de toutes les situations où on a besoin de spécifier des attributs aria, type aria-label, qui permettent d’améliorer l’accessibilité, et donc le SEO.

Et même d’un point de vue technique, chez Partenaire du Web on se sert souvent des attributs tout simplement parce qu’on en a besoin pour faire marcher certaines choses, si ça existe, c’est parce que c’est utile dans bien des situations.

D’ailleurs Divi et Elementor ne se privent pas d’en ajouter plein eux-mêmes dans le DOM, on comprend donc mal pourquoi ne pas laisser la possibilité d’en disposer comme on veut.

Oxygen et Bricks proposent cette fonctionnalité sur n’importe quel élément dans le builder, et il est possible d’utiliser des valeurs dynamiques ou des résultats de fonctions aussi bien pour la clé que pour la valeur, afin d’assurer une flexibilité maximale.

7 – Bloc de code

Même le meilleur page builder du monde ne peut pas couvrir tous les besoins imaginables, c’est pour ça qu’on a toujours besoin d’avoir un élément “code block” dans son panel d’éléments disponibles.

Cet élément permet d’insérer du code custom sur votre page. Ce sont les page builders incomplets comme Divi et Elementor qui en ont le plus besoin, car c’est parfois la seule façon de combler une lacune du builder sans passer par un plugin tier.

Certains builder permettent d’exécuter du code custom, mais en dehors du canva, ce qui perd de son intérêt, car encore une fois, le but d’un builder est de simplifier la tâche aux développeurs, donc de ne pas disperser les composants dont on a besoin lorsqu’on travaille sur une page.

Le minimum syndical est de pouvoir ajouter des code blocks contenant du :

• HTML & PHP
• CSS
• JavaScript

Mention spéciale si votre builder autorise le SASS et est capable d’interpréter les abréviations de code (style Emmet).

Oxygen le permet, à condition d’utiliser le plugin Recoda. Encore une fois sur ce point, c’est Bricks qui gagne, notamment car :

• Il respecte tous les points ci-dessus
• il possède un sélecteur CSS unique %root% rendant le CSS et le SASS bien plus faciles à maintenir
• il est possible d’intégrer les tags dynamiques dans n’importe quel bloc de code, même du Javascript.

Nous reparlerons des tags dynamiques plus tard.

8 – WP_Query facile et flexible (CPT, custom fields et taxonomies)

Pour ce point-là, on doit faire un rappel sur ce qu’est un CMS.

La raison d’être d’un CMS

On définit souvent WordPress comme étant un Content Management System, ou un CMS, mais qu’est-ce que c’est qu’un CMS ?

Un CMS est un outil qui permet de gérer et organiser les contenus de son site. Et grâce à WordPress, on peut facilement organiser ses contenus dans son back-end en utilisant des fonctionnalités telles que :

• les types de publication personnalisés (CPT)
• les champs personnalisés
• les taxonomies

C’est littéralement la raison d’être de WordPress. WordPress ne sert pas à “créer des sites facilement”, ça c’est la conséquence.

On organise notre base de données de manière propre grâce à ces fonctionnalités natives, c’est ce qui nous permet de ne pas avoir une base de données bordélique, impossible à maintenir, dans laquelle toutes les entrées ne sont que des “pages” et des “posts” indifférenciés.

C’est également ce qui permet de ne pas hardcoder en dur des éléments redondants dans ses pages et de pouvoir les modifier facilement de manière centralisée, donc encore une fois, de rendre le site plus maintenable, scalable, dynamique et évolutif.

La WP Query

En plus d’améliorer l’organisation de sa base de données et son back-end, cela permet aussi d’utiliser la WP_Query, fonction native de WordPress permettant de faire une requête à la base de données pour afficher des publications spécifiques dans une boucle, justement en fonction de leur type de publication, champs metas et taxonomies.

Ce sont les fameuses sections “Nos derniers articles” par exemple.

Alors vous n’utiliseriez jamais un builder qui ne vous encourage à ne pas de profiter des fonctionnalités natives du CMS qui sont la raison d’être de WordPress, pas vrai ? 😉

Un builder professionnel est censé proposer une interface UI directement intégrée pour pouvoir effectuer des WP query et les customiser en fonction :

• du type de publication
• des champs meta
• des taxonomies

Mais également de les trier selon X conditions, d’exclure des résultats, ou d’en inclure au contraire, et d’utiliser du PHP pour customiser les requêtes les plus complexes.

L’objectif est de toujours pouvoir afficher le bon contenu au bon endroit et d’utiliser WordPress de manière DYNAMIQUE et non pas avec des pages statiques.

Pourquoi c’est essentiel ?

Mettons que vous ayez créé un type de publication “service”, que vous l’affichez sous forme de cartes dans une section “Nos services” en définissant un style pour la carte et un template.

Le jour ou votre client vous dit qu’il propose un nouveau service, vous n’avez qu’à l’ajouter dans le backend, et il s’ajoute partout sur votre site, de la bonne manière, avec une URL dédiée, etc.

Alors oui, ça prend plus de temps au début que de simplement créer la page sans se poser de question, mais sur le long terme (et encore plus pour les gros sites), ne pas utiliser ces fonctionnalités, c’est se tirer une balle dans le pied. Encore plus pour les sites multilingues.

Encore une fois, Elementor et Divi ne sont pas à la hauteur.

Chez Elementor, ils utilisent Loop Grid qui permet à faire quelques requêtes simples, mais c’est bien moins permissif que ce que permet la WP_Query native de WordPress.

Pour Divi, c’est encore pire. Ils ne proposent tout simplement pas ces fonctionnalités dans le builder. Pour Divi, les deux seules solutions sont soit :

Première solution : module blog

Utiliser le module “Blog” de Divi pour intégrer automatiquement une query qui affiche les derniers articles.

Mais cela nous contraint à créer tous nos types de publications dans le CPT “article”.

• De un, ça crée un bordel pas possible dans le backend et rend la maintenabilité affreuse, d’autant plus qu’on pourra difficilement attribuer des templates différents en fonction des publications.

• De deux, cela va tout simplement à l’encontre des fonctionnalités de base de WordPress que sont d’organiser ses contenus en fonction de CPT, champs metas et taxonomies. Le principe d’un CMS.

En gros, Divi nous force à ne pas utiliser WordPress de la bonne manière, celle qui permet d’avoir un site facile à faire évoluer.

Deuxième solution : code custom

L’autre solution, c’est de passer par du code PHP pour créer une simple boucle, ce qui veut dire qu’on doit créer également tout le CSS de notre boucle et de son contenu à la main. Où est donc l’intérêt d’utiliser un builder, puisque tout se fait à la main ?

Divi vous force à travailler de manière bordélique et difficilement maintenable, alors que le but de WordPress c’est justement l’inverse.

La bonne façon de faire

La plupart des freelances / agences travaillant avec Elementor et Divi ne savent même pas ce qu’est un CPT ou une wp_query, ils savent juste qu’on peut afficher les derniers posts de type “article”, et donc ils créent tout sous forme d’article.

Super pour lorsqu’on aura besoin d’utiliser un template particulier pour un type de contenu spécifique, ou de différencier les types de publications dans une query loop. 🙃

Voilà pourquoi les autres agences affirment qu’Elementor et Divi font très bien l’affaire : ils ne comprennent même pas comment fonctionne WordPress. Encore une fois, si c’est pour travailler de cette manière, il n’y a aucune raison de ne pas utiliser Wix.

Parmi les builders professionnels, on a Oxygen qui permet de le faire grâce à son Repeater et ses Advanced Query très permissives. Pour Bricks, c’est encore plus puissant et permissif grâce aux Query loops.

Les deux nous laissent autant de liberté que si on utilisait la WP_Query à la main, mais avec tous les avantages et la flexibilité que permet le builder par-dessus.

De cette manière, on a :

• Un site propre
• Un site bien organisé
• Une base de données bien structurée
• Les publications s’affichent partout de manière dynamique
• la maintenabilité est maximale

Si demain votre client vous demande de rajouter un service ou une réalisation sur son site, ça vous prend 5 minutes et ça fonctionne parfaitement.

Pour information, sur Partenaire du Web, notre site est entièrement dynamique grâce à ce fonctionnement. Services, avis, localisation, projet, membre de l’équipe, outils, tout est un type de publication à part entière.

Les services sont différenciés grâce des taxonomies (type de service, ville …) et les templates sont crées via des champs metas. Tout fonctionne parfaitement et cela nous offre une flexibilité optimale.

9 – Données dynamiques

Depuis le début de cet article, on parle de données dynamiques telles que les :

• custom post type
• champs personnalisés
• taxonomies
• catégories

Toutes ces données dynamiques existent dans WordPress pour pouvoir être utilisées, donc votre builder doit vous encourager à les utiliser et les intégrer facilement dans votre workflow.

De la même manière qu’on parlait du fait que les div sont fondamentales au HTML et que les classes sont fondamentales au CSS, les données dynamiques sont fondamentales à un CMS, c’est littéralement la base de la base.

Si votre builder ne vous donne pas la possibilité de rentrer des valeurs dynamiques dans les champs de ses composants recevant une valeur textuelle, il vous encourage à travailler de la mauvaise manière.

Encore une fois, c’est la raison d’être d’un CMS, si on n’utilise pas ces données dynamiques et le templating, à quoi bon utiliser WordPress ? Autant partir sur Wix.

Attention, quand on parle d’entrer des valeurs dynamiques dans des champs textuels, on ne parle pas que des champs “texte”.

Cela inclut également la possibilité d’ajouter des valeurs dynamiques en tant que :

• classes
• #ID
• data-attribut
• URL
• affichage conditionnel
• PHP, CSS, JS
• et n’importe quel champ d’un composant pouvant recevoir une valeur quelconque.

Exemple dans Bricks, chaque éclair permet d’ouvrir une liste pour insérer n’importe quelle donnée dynamique.

Un simple lien cliquable peut recevoir des paramètres de requête dynamiques (clé comme valeur), et tous les attributs de lien peuvent également être dynamiques. La balise HTML également. En termes d’accessibilité, SEO, flexibilité, c’est juste le top.

Et ce n’est qu’un lien. Il existe des centaines de composants, possédants eux-mêmes de nombreux champs spécifiques pouvant recevoir des valeurs dynamiques.

Pour couronner le tout, on peut aussi retourner le résultat d’une fonction custom comme donnée dynamique, inclure un argument dans notre tag dynamique comme paramètre de fonction, et même crée ses propres tags dynamiques.

👉 C’est ce qu’on a fait lorsqu’on a développé notre plugin WordPress.

Oxygen offre aussi de nombreuses possibilités, mais Bricks est le seul à aller aussi loin et ne laisser aucune limite.

Dans Divi et Elementor, seuls quelques champs peuvent recevoir des données dynamiques, tel que le post_title, post_content et autres données courantes. Si on a besoin de choses plus complexes, ça devra se faire via du PHP, encore une fois, où est l’intérêt du page builder ?

Ce n’est pas anecdotique

Nous voyons trop de “professionnels” passer sur ces fondamentaux:

• les fondamentaux du HTML (ils n’utilisent pas de div)
• les fondamentaux du CSS (ils n’utilisent pas de classes)
• et même les fondamentaux d’un CMS (ils n’utilisent pas les données dynamiques)

Et ils se prétendent pourtant “agence web”, “expert WordPress”. Si vous leur expliquez ces choses-là, ils vous répondront que “ça dépend du besoin”, “que ça suffit pour les petits projets simples”…

Ah bon, les petits projets simples n’ont pas besoin d’être faciles à maintenir ? Ils n’ont pas besoin d’être évolutifs selon les besoins futurs du client ? Ils n’ont pas besoin d’être optimisés SEO et bien référencés ? Ils n’ont pas besoin d’être bien construits et bien organisés ?

Imaginez que vous confiez la construction de votre maison à une boîte de TP et qu’elle travaille n’importe comment, laisse plein de défaut et de vices à votre maison sous prétexte que “ce n’est qu’une petite maison”. C’est pareil pour un petit site.

10 – Rendu conditionnel

Pouvez-vous afficher ou cacher des éléments en fonction de certaines conditions ?

• Afficher ou cacher un numéro de téléphone en fonction de l’heure ou du jour de la semaine
• Afficher ou cacher un bouton on fonction du rôle de l’utilisateur
• Afficher ou cacher une section en fonction de la valeur d’un champ ACF
• Afficher ou cacher quelque chose en fonction de la valeur de n’importe quelle fonction custom ou donnée dynamique

👉 Bonne nouvelle, Elementor gère l’affichage conditionnel correctement pour des besoins basiques, et nécessitera un peu de code custom pour les besoins complexes.

Pour Divi, c’est l’hécatombe, il faudra quasiment toujours utiliser du PHP ou du JS pour créer des conditions custom, même pour des besoins simples.

Encore une fois, on perd du temps, on complexifie inutilement le processus de développement, le client paie plus cher, bref, on perd l’intérêt du page builder.

On suit toujours le même pattern : Bricks et Oxygen se démarquent de très très loin, avec un léger avantage pour Bricks grâce l’UX de l’écran des conditions.

11 – DOM propre

Vous ajoutez un élément aussi simple qu’un bloc de texte sur votre page ? Si votre builder génère autre chose qu’une balise <p> dans votre DOM, il y a un gros problème.

Et c’est exactement ce qui se passe avec :

• Elementor
• Divi
• Beaver Builder, WP Bakery, Site Origin, et tous ces builders non professionnels.

À chaque fois que vous ajoutez un élément, le page builder va générer 5 ou 6 div inutilement, avec plein de classes et d’ID non désirés, des styles déjà préappliqués pour vous forcer à faire les choses dans une certaine direction (la mauvaise) etc.

Alors sur une page complète avec beaucoup de sections et beaucoup de contenu, vous vous retrouvez avec un DOM surchargé et 90% des balises ne servent à rien, elles ne sont présentes que parce que le builder est mal foutu.

Quand on dit qu’il est mal foutu, ce n’est pas une façon de parler. Ces page builders ont besoin de plein de pansements pour que tout fonctionne correctement, et les 5 div ajoutés font office de pansements.

Ce n’est pas juste un problème de bonnes pratiques. L’un des objectifs de votre client avec son site, c’est d’être bien référencé et avoir un bon SEO, mais toutes ces div indésirables et cette structure de DOM vont affecter ses Core Web Vitals, donc son SEO.

Test de performance d’un site Elementor

Faites le test avec un site fait avec Elementor et essayer de passer une de ses pages sur Google PageSpeed Insight et regardez le score des Core Web Vitals.

Pour l’exemple, on va prendre directement la page d’accueil du site https://elementor.com lui-même, car ils utilisent leur propre outil pour leur site.

En tant que professionnels de leur page builder, on peut s’attendre à ce qu’ils le maitrisent à la perfection et que leur page soit construite de la manière la plus optimisée qu’il soit possible de le faire avec Elementor.

👉 Et pourtant, eux-mêmes ne passent pas leur propre site aux Core Web Vitals. Alors imaginez les autres sites !

Et comme par hasard, si on s’attarde sur les messages d’erreurs et avertissements, on voit bien une note “Excessive DOM Size”, ce qui signifie qu’il y a trop d’éléments à charger dans le DOM.

Mais si vous prenez deux pages identiques, l’une faite avec Bricks ou Oxygen, et l’autre faite avec Divi / Elementor, la première n’aura aucune alerte relative à la taille de son DOM, la deuxième, si.

D’un côté, votre builder génère du code propre, de l’autre, il génère du code dégueulasse. Quel est l’intérêt d’utiliser un builder si en sortie son code ne passe pas les standards de Google ?

À titre de comparaison, voilà ce que ça donne pour notre site Partenaire du Web, développé avec Bricks :

Bien sûr, en regardant la page en tant que visiteur, on ne s’en rend pas compte, et comme les personnes qui utilisent Elementor, Divi et compagnie sont des amateurs, ils ne se rendent pas compte eux-mêmes du problème.

Il n’y a juste aucune raison qui nécessite de le faire, la preuve, Oxygen ne le fait pas (d’où leur nom) et ça fonctionne très bien. C’est donc bien que tous ces wrappers ne sont que des cache-misères pour faire fonctionner le site.

Et ce n’est pas qu’un problème de SEO (ce qui est déjà critique) mais également un problème de maintenabilité. On ne va pas rentrer dans les détails techniques, mais ce genre de comportement :

• complexifie l’utilisation de sélecteurs CSS avancés,
• complexifie l’utilisation de pseudo-classes et pseudo-éléments
• complexifie plein de points lors du développement
• crée des bugs,
• etc. bref c’est une tannée.

Les “professionnels” qui travaillent avec ce genre d’outils ne sont pas sérieux. Et oui, il existe des plugins d’optimisation de performances, mais aucun ne va modifier le DOM et “dewrapper” vos div. 👇

Elementor et Divi ne corrigeront jamais ce problème

Aucun page builder ne peut être parfait le jour de sa sortie, c’est pour ça qu’on paie un abonnement et qu’il y a des mises à jour au fur et à mesure pour enrichir le builder et l’améliorer avec le temps.

Certains page builders comme Bricks et Breakdance on même une roadmap publique pour que leurs utilisateurs soient au courant des nouvelles fonctionnalités des prochaines mises à jour.

Elementor a par exemple beaucoup progressé depuis sa sortie, il faut le reconnaître. Ils ont bien amélioré leur système de loop grid et leur affichage conditionnel par exemple.

Par contre, il y a des mauvaises décisions qui ont été prises dès le début et qui handicaperont À VIE le page builder, sans jamais aucun moyen de revenir en arrière, comme ce problème de DOM. La raison est simple : 👇

Une mise à jour qui modifie à ce point le DOM généré viendrait casser les 18 millions de sites existant qui ont déjà été créés avec tous ces cache-misères.

En effet, il y a du code exécuté en dehors d’Elementor et Divi, notamment par tous les plugins et thèmes qui s’y greffent autour, qui ont été conçus pour fonctionner en prenant en compte toutes ces div inutiles.

Les agences et freelances eux-mêmes ont également créé du CSS, des hooks, des scripts et autres qui dépendent de cette mauvaise configuration initiale.

Donc même si Elementor et Divi voulaient régler ce problème, ils ne pourraient pas, car cela casserait littéralement des millions de sites qui dépendent de ce mauvais DOM.

C’est donc un problème qui ne sera jamais réglé, et pourtant, chaque jour, des “professionnels” continuent à utiliser ces outils pour de nouveaux projets alors qu’on sait qu’ils ne seront jamais viables, même dans 50 mises à jour.

De mauvaises décisions ont aussi été prises chez d’autres builders. Oxygen a par exemple souffert d’avoir été développé avec la première version d’Angular, ce qui limitait son potentiel d’évolution. C’est pour ça qu’ils ont dû réécrire une toute nouvelle version d’Oxygen depuis zéro. Et pour ne pas casser les sites déjà conçus avec l’ancienne version, ils laissent les deux versions coexister, sauf que la première n’est plus vraiment mise à jour. Elementor ne fera jamais un tel choix pour plein de raisons.

12 – Flexbox

En CSS, les flexbox sont (avec les grid) le moyen plus pratique de positionner des éléments dans un container. Si vous n’êtes pas d’accord avec cette affirmation, il suffit de regarder comment fonctionne Figma.

Figma est l’outil de web design de référence pour les professionnels, c’est l’étape de prototypage qui intervient avant le développement d’un site.

Dans Figma, tout fonctionne sur le modèle de frames et d’auto layout :

• Les frames sont des “boites” qui servent à contenir d’autres éléments
• L’auto layout est la façon dont les éléments se positionneront à l’intérieur de cette boîte. (centrée, équitablement éloigné, espacée au maximum, positionnée au début ou à la fin du container, avec ou sans wrap etc).

Et bien devinez quoi ? Une frame, ce n’est ni plus ni moins qu’une div, ça a exactement la même utilité, et l’auto layout, c’est simplement le nom qu’ils utilisent pour parler de flexbox.

👉 On utilise l’autolayout selon exactement les mêmes propriétés et possibilités qu’un flexbox, pas plus, pas moins.

Étant donné qu’en web design, on travaille avec des div vide qu’on empile les unes dans les autres, chaque div est un container potentiel, les sections en tout premier lieu. On est donc censé utiliser les flexbox littéralement partout.

Et pourtant, jusqu’à récemment… Divi ne le proposait pas !!!!!!! Et Elementor non plus !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 😲

It sounds crazy, but Divi has not yet integrated the CSS properties of Flexbox into its builder, or at least not in the form of options that can actually be activated for the user. 

astucesdivi.com, How to use the Flexbox CSS in Divi ?

Réellement, cette fonctionnalité a été ajoutée très récemment dans Divi (version 4.2), il faut aller l’activer dans les réglages avancés, alors que ça devrait être le réglage par défaut.

Entre 2013 et 2022, soit pendant 9 ans, il était impossible d’utiliser nativement le flexbox dans Divi !!! Et même chose pour Elementor, lancé en 2016 et introduit en 2022.

Avant ça, ils fonctionnaient avec un système de row et de colonnes en display Block et float.

Pour info, les row et les colonnes n’ont aucune existence en web design (en dehors des grid), puisque tout fonctionne sur le principe des div vide. Une colonne Elementor n’a aucune équivalence en HTML, c’est simplement une div avec une largeur en pourcentage par rapport à son container parent.

En bref, c’est du bricolage, et c’est à cause de ce genre de bricolage que, dans Elementor et Divi, le moindre élément que vous ajoutez sur la page va généré 5 ou 6 div, pour “essayer de faire fonctionner miraculeusement le tout”.

Tous les outils de web designs professionnels fonctionnent sur le principe de flexbox, alors comment respecter une maquette Figma (qui a été conçue d’une manière spécifique pour répondre à un objectif de spécifique) si on ne peut pas utiliser les mêmes réglages de positionnement ?

Les sites codés à la main utilisent tous flexbox également, il y a donc bien une raison : c’est par ce que c’est la bonne façon de faire, la plus flexible et évolutive.

C’est un énorme problème, encore une fois ces outils nous force à travailler de la mauvaise manière et de rendre la maintenabilité et l’évolutivité compliquée.

Même si aujourd’hui Flexbox est pris en charge, une grosse partie des fonctionnalités de Divi et Elementor fonctionne encore l’ancienne manière.

Pourquoi c’était si compliqué ?

Le display Block, inline, le float, tout ça c’est du bricolage et ça n’offre pas autant de flexibilité que les flexbox (d’où leur nom). L’une des révolutions du CSS 3 par rapport au CSS 2, c’est justement le modèle de flexbox, qui n’existait pas jusqu’alors.

👉 En nous forçant à travailler sans flexbox, ces outils nous ramènent à l’époque du CSS 2, c’est-à-dire 1998 à 2012 !!! C’est aberrant.

Alors oui, les flexbox étaient bien générés sur le front au final grâce au système de colonnes, entre autres, mais encore une fois ces colonnes n’ont aucune existence concrète sur la page lorsqu’elle est chargée dans le navigateur.

C’est comme pour comme les div et et les classes, ils les utilisent au final, car c’est indispensable, mais nous on n’y a pas accès. Pourquoi ne pas laissé le contrôle total dès le départ ?

Pourquoi parler de “colonnes” et de concepts qui n’existent pas, alors que les flexbox offrent tous les contrôles dont on a besoin ?

Pour une raison simple :

Pour un utilisateur non professionnel, c’est plus facile de comprendre ce qu’il se passe quand on clique sur “ajouter une colonne” que quand on doit ajouter une div puis lui mettre les propriétés de flexbox, bien que ce soit plus efficace et que ce soit la bonne manière de faire.

C’est donc bien la preuve que ce genre d’outil ne s’adresse pas aux professionnels, sinon, comment expliquez-vous ce choix ?

Désolé d’insister autant, mais on parle quand même de la base du positionnement en CSS, encore une fois, les flexbox c’est quelque chose qu’on apprend très tôt dans une formation CSS, ça n’a rien d’avancé.

Dans Bricks, même un élément <p> peut être mis en display: flex.

13 – CSS Grid

Comme pour les flexbox, si votre builder ne supporte pas nativement le positionnement en CSS grid, vous allez forcément être limité au moment d’intégrer une maquette.

L’utilisation de grid est critique pour certaines dispositions comme :

• une galerie
• un caroussel
• une liste de cartes
• ou même simplement pour positionner vos containers parents dans une section.

Il ne suffit pas de proposer un élément “Galerie” ou “Caroussel” tout prêt, on doit pouvoir être capable d’appliquer du CSS Grid à n’importe quel div !

Votre builder doit vous laisser suffisamment de flexibilité dans la configuration de la grille et la répartition des espaces :

• auto-fit, auto-fill
• template row, column, areas
• repeat, minmax
• prise en charge de subgrid
• répartition des colonnes flexibles (type Bootstrap)

C’est le cas des builders comme Oxygen, Breakdance et Bricks, et cela est rendu encore plus simple grâce à des frameworks CSS comme Automatic CSS.

Pour Elementor, le support natif de grid a été ajouté récemment, il n’est pas aussi permissif que les autres, mais il a au moins le mérite d’exister.

Pour Divi, c’est simple, ce n’est tout simplement pas pris en charge nativement à ce jour, on est obligé de passer par du CSS custom ou de se prendre la tête avec un module tiers. Dans tous les cas, on perd du temps et de la flexibilité.

Chez Bricks :

On a même un Grid Builder intégré avec Advanced Themer !

14 – Menu Builder

Dans WordPress, les menus de navigation sont créés dans l’onglet “Apparence” de WordPress, et c’est ensuite à vous d’intégrer ce menu dans votre builder, typiquement dans votre template de header.

Cela signifie que votre builder affichera votre menu à partir d’un shortcode, donc les éléments qui le composent ne seront pas sélectionnables individuellement (lien, sous-menu, liste, icône…)

Vous ne pouvez par exemple pas sélectionner un onglet ou un dropdown en particulier et lui appliquer des classes, des styles, etc.

Selon nous c’est l’un des gros défauts de WordPress, et c’est ce qui nous pousse parfois à créer manuellement un menu avec des CPT, pour avoir plus de libertés dans la création de menus complexes.

Toujours est-il que pour respecter les bonnes pratiques de WordPress, on doit faire avec, et votre builder doit s’adapter.

Votre builder vous laisse-t-il :

• choisir parmi plusieurs menus ?
• assez de flexibilité dans la création de votre menu ?
• assez de liberté pour customiser indépendamment chaque item et sous item de votre menu ?
• appliquer du style en fonction de l’item :active, :hover, .. ?
• gérer le fonctionnement du menu sur différentes largeurs d’écran ?
• gérer un off-canva ? un toggle ? un hamburger ? un mega menu ?

15 – Composants

Les composants sont INDISPENSABLES si vous réutilisez des éléments similaires à plusieurs endroits de votre site.

Par exemple, si vous créez un block, disons un bandeau CTA, vous allez le créer une première fois et le configurer d’une certaine manière :

• que ce soit son contenu (texte, offre, prix)
• ou son design (couleur, bordures, padding…).

Une fois qu’il est prêt, vous allez sans doute vouloir le réutiliser à d’autres endroit du site, sur différentes pages, sur différents templates, peut être en faire un block gutenberg, bref l’éparpiller un peu de partout.

👉 Mais devinez quoi ? Les offres changent avec le temps. Un jour votre client va peut être vouloir modifier son offre, changer le prix, ou même simplement changer le lien de la landing page sur lequel le CTA renvoi.

Comment vous faites si vous devez le changer sur 100 pages différentes ? Et ce, chaque semaine ?

Un composant vous permet justement de synchroniser les modifications entre chaque instance de votre block. Un builder flexible vous laissera la possibilité de :

• Modifier d’un coup toute vos instances de composant via un composant “mère” qui impactera tous les autres
• Modifier au cas par cas certains composants filles quand ils ont besoin d’être personnalisés, sans que ça impacte les autres

C’est important encore une fois pour la maintenabilité du site, son évolutivité, son côté dynamique, son organisation, sa capacité à scaler.

C’est bénéfique pour tout le monde :

• Pour vous, la gestion du site est plus simple, vous y passez moins de temps et vous êtes donc plus rentable
• Pour le client, car il sait qu’il peut continuer à avancer avec vous sans être limité et devoir payer une somme pharaonique, car la moindre modification de texte va prendre des heures.

Encore une fois, Oxygen s’en sorte haut la main grâce à son système de Reusable Part.

Pour Bricks, c’est encore mieux car on peut utiliser un système permettant de personnaliser les composants filles de manière automatique avec des propriétés dynamiques (un peu comme les propsavec React).

Les deux nous laissent même la possibilité de les importer / exporter en JSON pour les réutiliser entre différents sites.

Pour Elementor, les Global Widget font l’affaire dans la plupart des situations, même s’ils sont moins modulaires que Bricks et Oxygen.

Pour Divi, encore une fois, on est hors catégorie, il n’y a pas de relation mère / fille, si on veut modifier une instance fille, il faut transformer le composant en élément standard, ce qui rompt définitivement la liaison avec les autres instances.

16 – Images SRCSET

Lorsque vous importez une image dans votre bibliothèque WordPress, il n’est pas rare que votre thème duplique cette image en différentes tailles, ainsi vous pouvez vous retrouvez avec 7 variantes d’une même image :

• Une version miniature (150x150px)
• Une version un peu plus grande
• Une version encore plus grande
• etc… jusqu’à la taille originale, qui peut être par exemple en 1920x1080px

L’intérêt en tant que développeur, c’est que ça nous permet de ne pas avoir à nous préoccuper des résolutions AVANT l’importation. C’est un gros gain de temps, mais ce n’est même pas ça le plus cool.

Le plus intéressant, c’est que grâce au support natif de srcset, vous pouvez spécifier au navigateur quelle variante de l’image il doit charger, en fonction du contexte mais aussi de la taille d’écran.

👉 Par exemple, une image de mise en avant d’un article qui apparait en bannière sur la page devra probablement être affichée dans sa version originale, mais peut être que sur tablette, la version miniature en 660x660px suffira, car l’image se trouvera elle-même dans un container de 600px.

Peut être même que sur une autre page, cette même image sera affichée en tout petit, par exemple dans une carte “nos derniers articles” et que là, la version en 300x300px suffira.

Et le tout se fait tout seul, vous avez juste a spécifier la bonne version d’image à utiliser dans le builder lorsque vous créez votre page ou votre template, et c’est tout.

Un page builder qui ne propose pas cette fonctionnalité nativement vous force à faire des concessions sur :

• la vitesse de chargement de la page
• l’expérience utilisateur des prospects
• le SEO de votre client.

Un builder qui vous force à de telles contraintes peut-il être qualifié de builder pour professionnel ?

17 – Unités custom

L’unité de mesure par défaut de tous les builders est le pixel. C’est très bien par défaut, mais le pixel n’est pas toujours le meilleur choix. Il y a des situations où on veut pouvoir utiliser des :

• em
• rem
• %
• vh
• vw
• ch

Alors ce sera toujours possible de le faire via du CSS personnalisé, mais encore une fois, le CSS personnalisé est censé servir pour des cas très spécifiques, tandis qu’utiliser des ch pour définir la taille des textes, par exemple, c’est très courant.

Or, on ne peut pas se permettre de perdre du temps à faire du CSS custom à chaque fois qu’on doit définir la longueur d’un texte, ou utiliser des rem.

Sinon, encore une fois, quel est l’intérêt du builder ?

Pour rappel, les em, rem, %, vh et vw sont des unités dynamiques, elles sont donc très pratiques lorsqu’il est question de gagner du temps, notamment pour ne pas avoir à se retaper tout le CSS en responsive pour adapter les tailles et perdre un temps fou, temps qui est facturé au client.

Au passage, ça aide aussi à avoir un beau design, et on rappelle que beau design = haut taux de conversion, donc un site qui performe et qui rapporte des clients.

Ici, Bricks et Oxygen sont les plus complets : par défaut, l’unité sera toujours en px, mais il est possible de spécifier n’importe quelle unité simplement en l’écrivant dans le même champ que le nombre. C’est ultra rapide, pratique, smooth, sans friction.

La feuille de style sera générée avec cette unité spécifiée. Donc même les unités les plus exotiques seront prises en charge, telles qu’ex, vwmin, vhmin, etc. Tant que l’unité existe en CSS, le navigateur saura l’interpréter.

Pour Elementor et Divi, ça se fait uniquement via une liste de choix déroulant, donc on doit se limiter aux choix disponibles, sinon ça se fait en CSS custom.

18 – Structure Panel digne de ce nom

Faisons rapide pour ce point.

• Peut-on drag and drop facilement des éléments dans le structure Panel ?
• Peut-on voir entièrement la structure de la page qu’on est en train de construire ?
• Peut-on renommer les éléments dans le structure Panel ?
• Peut-on utiliser le structure panel de manière ergonomique pour dupliquer ou supprimer des éléments en clic ?
• Y a t-il un clic droit contextuel permettant d’étendre encore plus les possibilités et travailler dans des conditions ergonomiques et polyvalentes ?

Bricks : parfait, on peut élargir le structure panel, réduire ou étendre tous les éléments d’un coup, on a un clic droit menu contextuel avec plus d’options qu’il n’en faut (copier les styles, wrapper l’élément, le convertir en composant…)

Chez Oxygen, ça fonctionne presque aussi bien, excepté le drag and drop qui est un peu compliqué (résolu dans Oxygen v6).

C’est à ça que sert le Structure Panel, gagner en ergonomie et en vitesse grâce à un accès rapide à tous les éléments sur la page.

Chez Elementor et Divi encore une fois ça pêche, le structure panel et le menu contextuel sont très basique, on manque d’ergonomie et on perd l’intérêt dus structure panel.

19 – Compatibilité avec un framework CSS professionnel

Les frameworks CSS permettent de gagner énormément de temps lorsqu’il est question de développer un site sous WordPress.

👉 Il est toujours possible d’utiliser des frameworks habituels, comme Bootstrap ou Tailwind, mais étant donné qu’on est dans l’écosystème WordPress, autant en utiliser un qui s’intègre complètement dans le back et le front.

On ne parle pas d’un simple plugin qui propose des classes CSS préconfiguré (comme Oxyninja ou Advanced Themer), mais bien d’un framework CSS complet et entièrement personnalisable.

Pour ce point, on va partir dans le sens inverse et d’abord se demander “quels sont les frameworks CSS professionnels”, et ensuite on ira voir avec quels builders ils sont compatibles.

Selon nous, il n’existe que deux plugins de framework CSS pour WordPress qui respectent tous les points d’un framework CSS professionnel

On ne va pas détailler maintenant ce qu’est un framework CSS professionnel comparé a un framework d’amateur, c’est déjà assez long d’expliquer la différence pour les builders ! Donc il va falloir nous faire confiance :

• Automatic CSS (ACSS)
• Core Framework (CF)

La différence entre les 2 est surtout philosophique et sur la façon dont un framework doit diriger l’UI d’un site.

Automatic CSS c’est un peu l’équivalent de Bootstrap : « Donne-moi des utilitaires parfaitement optimisés et prêts à l’emploi » alors que UI Core c’est plutôt « Construis ton design à partir de zéro ».

Chez Partenaire du Web, on travaille aujourd’hui avec Automatic CSS, mais Core Framework devient de plus en plus intéressant.

Bref, tout ça pour dire que ces 2 framework CSS sont les meilleurs frameworks CSS pour WordPress, maintenant, regardons les compatibilités :

• Automatic CSS est compatible avec Bricks, Oxygen, Cwicly et Breakdance
• Core Framework est compatible avec Bricks et Oxygen.

Aucun des 2 seuls frameworks CSS professionnels pour WordPress ne sont disponibles sur Divi ou Elementor, donc à partir de là, Divi et Elementor sont automatiquement éliminés des page builders adaptés pour un usage professionnel.

Travailler sans framework CSS digne de ce nom, c’est perdre du temps et compliquer la gestion d’un site.

Ce ne sont pas les frameworks qui se refusent à Elementor et Divi, mais bien l’inverse :

Divi et Elementor ont une architecture fermée, et ne permettent presque pas d’utiliser de variable CSS dans l’UI, d’où le point suivant.

C’est donc une limitation technique d’Elementor et Divi qui impose de se priver de ces outils qui sont pourtant primordiaux dans un projet web sérieux.

20 – Variables CSS

Pour pouvoir fonctionner avec un framework CSS, mais aussi dans bien d’autres situations, utiliser des variables CSS permet de gagner un temps précieux et de gagner en flexibilité, centraliser les modifications de styles concernant les couleurs, les typo, les espaces, les bordures, etc.

Ca permet de rendre le responsive plus fluide, d’harmoniser toute votre UI, bref c’est obligatoire dès qu’un site possède plus d’une page.

Bricks et Oxygen sont capable d’interpréter n’importe quelle variable CSS directement dans les champs du builder, même si ces variables sont déclarées ailleurs par un plugin tiers, le tout sans avoir à passer par du CSS custom.

Sur Elementor et Divi, il faut déclarer les variables manuellement dans du CSS custom, et on ne peut pas ou presque pas les utiliser directement dans les champs du page builder.

C’est en grande partie la raison qui explique pourquoi les frameworks CSS Automatic CSS et Core Framework ne sont pas disponible sur ces builders.

👉 Divi et Elementor vous forcent encore une fois à travailler de la mauvaise façon.

La seule alternative que vous avez, ce sont les Global settings, global colors, et autres styles globaux dont on parlera plus bas. Mais ces fonctionnalités ne remplissent même pas 1% de ce que permet de faire un framework CSS.

21 – Éxecution de shortcodes

Lorsqu’un page builder pèche dans un domaine ou manque de fonctionnalité, on peut utiliser un plugin pour combler ses lacunes. Les plugins qui permettent de générer un élément qui s’affiche sur le front (comme un formulaire) fonctionnent généralement avec des shortcode.

👉 Vous configurez votre plugin, il vous génère un shortcode, et le shortcode s’affiche sur la page.

Un builder professionnel doit offrir un élément dédié pour insérer des shortcodes, et exécuter les shortcodes en direct dans le builder pour prévisualisation.

Heureusement, même Elementor et Divi sont capables d’exécuter des shortcodes, bien que la prévisualisation ne fonctionne pas toujours correctement.

22 – Breakpoints customisable

• Pouvez-vous changer les breakpoint de votre site ?
• Pouvez-vous ajouter des tailles intermédiaires ?
• La taille de base (desktop) peut elle aussi être modifiée ?

Ca peut être crucial dans certains cas pour avoir un affichage optimal de tous les éléments. Par exemple, prenons une grille CSS, dedans il y a des images :

• La grille fait 3 colonnes sur le format PC –> les images rendent bien. ✅
• La grille fait 2 colonnes sur le format tablette –> les images rendent bien dans la fourchette haute du breakpoint (992px), mais pas dans la fourchette basse (768px). ❌
• La grille fait une colonne sur le format mobile –> les images rendent bien. ✅

Si votre builder ne permet pas de modifier les breakpoints par défaut, vous serez obligé de gérer cette situation via du CSS custom, voir du JS, ce qui fait encore une fois perdre l’intérêt du page builder.

De plus, vous devrez créer des média queries statiques à plein d’endroits du site, ce qui est le meilleur de laisser des bugs d’affichage sur certaines tailles d’écran.

Un page builder professionnel doit vous laisser la possibilité de changer les breakpoints de manière centralisée de votre site, ajouter autant de tailles intermédiaires que nécessaire, et modifier la taille de base sur desktop.

👉 Anecdote qui nous est arrivée à l’agence :

On a eu le cas où il y avait un pixel d’écart entre la configuration de notre framework CSS pour mobile (strictement inférieur à 479px) et le breakpoint mobile de Bricks (inférieur OU ÉGAL à 479px).

Cela signifie que, pour les utilisateurs dont l’appareil fait exactement 479px, l’affichage était buggé.

Ici, c’est du détail, mais c’est ce qui différencie un travail professionnel et un travail d’amateur. Il était aussi possible de modifier les breakpoints sur notre framework CSS, mais le plus simple était de le modifier sur le builder.

23 – Utiliser des global styles

On va faire court : un builder professionnel doit vous permettre d’utiliser des global styles qui s’appliqueront sur tous les éléments de votre site.

Pourtant, encore une fois, les global styles d’Elementor et Divi sont bien trop basiques, alors qu’ils devraient au contraire permettre d’appliquer n’importe quelle règle sur n’importe quel type d’élément par défaut, vu qu’ils ne proposent ni framework CSS professionnel, ni classes.

Des global styles basiques entrainent :

• plus de temps perdu
• des galères de maintenance
• des problèmes d’évolutivité

👉 Bricks et Oxygen sont de loin les page builders offrant le plus de flexibilité sur ce point. On peut créer plusieurs global styles et les appliquer selon XXX condition.

24 – Hooks pour customiser les fonctionnalités du builder

Enfin, un page builder taillé pour les professionnels doit être capable de s’adapter à vos besoins spécifiques. C’est le builder qui doit d’adapter à vous, pas l’inverse. On doit donc pouvoir être capable de modifier son comportement grâce à des hooks et une documentation claire.

Ca peut paraitre complètement irréel pour des amateurs, mais c’est pourtant la vérité : le builder est votre outil principal pour créer un site, il ne doit donc jamais vous limiter.

👉 Par exemple, pour un projet d’application mobile développé avec Bricks (oui, on peut le faire) on a eu besoin d’appliquer plusieurs sous-templates à des templates de publications principales.

Le fonctionnement par défaut de Bricks ne le permettait pas, mais il existait des hooks pour pouvoir ajuster le comportement de Bricks.

C’est juste un exemple comme il pourrait en avoir des centaines d’autres, mais encore une fois, si on avait dû passer par Elementor ou Divi, on aurait tout simplement été bloqué par le builder.

On aurait dû trouver une solution de bricolage qui marche à moitié, et le client n’y aurait pas trouvé son compte.

Bricks possède une documentation claire sur les éléments de son fonctionnement qu’on peut modifier en tant que développeur. Oxygen a aussi quelques possibilités sympas.

Mais Divi et Elementor sont tellement fermés que les seuls hooks qu’ils mettent à disposition servent simplement à compenser des lacunes et des fonctionnalités qui devraient être présentes directement dans l’UI du builder.

Conclusion

Si vous avez lu cette démonstration en entier, félicitations ! 🎉 Vous faites partie des heureux élus.

Cela prouve que vous prenez ce sujet au sérieux et que vous n’êtes pas fait pour utiliser Divi ou Elementor. Sinon, vous n’auriez jamais perdu autant de temps à lire tous ces arguments.

Vous l’avez compris, il n’existe pas 15 bons page builders : aujourd’hui, seuls Bricks et Oxygen sont adaptés à un usage professionnel. Ce n’est pas une opinion, mais une conclusion logique basée sur tous ces critères.

Nous ne sommes pas mariés à eux, ils ne nous ont pas payés. Objectivement, Bricks semble un meilleur choix, mais les deux restent largement supérieurs à Elementor et Divi.

Le but de cet article n’est pas de critiquer gratuitement, mais de dire la vérité. En France, tout le monde utilise Elementor et Divi sans réflechir, mais aux États-Unis, c’est une toute autre histoire.

D’autres professionnels du web design en sont arrivés à ce constant bien avant nous, on n’a rien inventé !

Ça ne veut pas dire qu’il faut tout jeter ! Elementor et Divi sont très bien pour créer un site facilement sans enjeu commercial – pour un particulier, une association ou un entrepreneur qui se lance. Le problème, c’est que ces outils ne tiennent pas la route dès qu’il y a un enjeu business.

Ce n’est pas un avis, mais un constat objectif. Nous avons détaillé 24 points. Si vous pensez qu’on se trompe, démontrez-le. 😉

Si vous êtes un freelance ou une agence et que vous travaillez avec ces outils, ce n’est pas “OK”… mais il n’est jamais trop tard pour changer. Bricks et Oxygen ne sont pas sorciers, ils demandent juste un changement de workflow et un petit effort d’apprentissage.

C’est aussi dans votre intérêt : un bon builder vous permet de travailler mieux, plus vite, et de signer des projets plus ambitieux et plus rentables.

Vous avez des questions sur l’écosystème Bricks / Oxygen ?

Contactez-nous !