J’ai utilisé Elementor, Divi, Visual Composer, Beaver Builder, Bricks, Oxygen. Tous. Sur des dizaines de projets. Et plus le temps passe, plus je m’en éloigne, sauf cas très précis.
Voilà pourquoi.
Le poids du builder est ce qu’il est
Tous les page builders ajoutent du poids à votre site. Du JavaScript, du CSS, des dépendances. Même les meilleurs, comme Bricks ou Breakdance, restent plus lourds qu’un thème codé proprement.
Sur un site Elementor classique en 2025, j’ai vu plus de 250 ko de JavaScript chargé sur la page d’accueil avant même que le contenu n’apparaisse. Sur un thème custom équivalent, on est sous les 50 ko.
250 ko en plus, sur 4G en zone moyenne, c’est facilement une seconde de plus au LCP. Une seconde, c’est 10 % de visiteurs en moins. Sur un site qui fait 10 000 visites par mois, c’est 1 000 visites évaporées. Si votre activité dépend de ces visites, le builder vous coûte.
La maintenance devient lourde
Les builders évoluent vite. Mises à jour majeures qui cassent des modules. Plugins compagnons qui ne suivent pas. Templates qui doivent être ré-éditées à chaque grosse version.
Sur un site Divi vieux de quatre ans que j’ai repris, mettre à jour Divi vers la version courante a cassé sept pages d’un coup. J’ai passé deux jours à tout refaire. Avec un thème codé proprement, les mises à jour WordPress passent sans rien casser depuis dix ans.
Le rendu est rarement net
Un page builder, c’est de la flexibilité. Trop de flexibilité, en fait. Vous pouvez positionner n’importe quoi n’importe où. Avec un client non-designer, ça finit toujours pareil : le site grossit, perd sa cohérence, mélange les polices, multiplie les couleurs.
Avec un thème codé sur la base d’un design system validé, ces dérives ne sont pas possibles. Les boutons sont les boutons. Les titres sont les titres. La cohérence visuelle se maintient pendant des années.
L’enfermement progressif
Un site Elementor n’est pas un site. C’est un site Elementor. Si vous voulez en sortir, vous devez tout refaire. Le contenu est mélangé avec la mise en page d’une manière qui ne s’exporte pas proprement.
Idem pour Divi, idem pour Bricks (un peu moins, mais quand même), idem pour les autres. Une fois engagé sur un builder, vous y restez.
Quand j’utilise quand même un builder
Je ne suis pas dogmatique. J’utilise des builders dans deux cas précis.
Premier cas : le client doit lui-même éditer beaucoup de pages très visuelles, avec différentes mises en page selon les pages. Un site de mariée, un site de coach, un site événementiel. Le client ne veut pas appeler un dev pour chaque modification. Là, un builder léger comme Bricks fait sens.
Deuxième cas : projet à très petit budget où le client accepte les compromis. Site personnel, side-project, association. Construire from scratch n’est pas justifié économiquement. Un Elementor avec un thème léger fait le job en une journée.
Mon approche par défaut
Pour un projet sérieux, je code un thème enfant à partir d’un thème léger comme GeneratePress, Astra, ou un thème de blocks natifs. Les pages sont construites avec Gutenberg, l’éditeur natif WordPress, qui est devenu très puissant depuis 2023.
Gutenberg en 2026 est largement suffisant pour 80 % des cas. Il est rapide, il est natif, il ne casse rien aux mises à jour, et le client peut éditer ses pages avec une interface simple. C’est le compromis que j’ai trouvé.
Le vrai sujet n’est pas le builder
En vérité, le vrai sujet n’est pas Elementor ou Bricks ou rien. C’est : qui décide à quoi ressemble une page, et avec quelles contraintes ?
Sur les bons projets, c’est un designer qui pose les règles. Polices, couleurs, espacements, hiérarchies. Le développeur intègre ces règles dans le code. Le client édite le contenu sans pouvoir casser la cohérence.
Sur les mauvais projets, le client a accès à un builder, peut tout faire, et finit par produire des pages qui se ressemblent toutes ou qui dérivent dans tous les sens.
Donnez-moi un page builder bien encadré, ça peut marcher. Donnez-moi un page builder en accès libre à un client sans direction artistique, ça finit en catastrophe esthétique. Le builder n’est pas l’ennemi. L’absence de cadre, oui.
Mon conseil pratique
Si vous démarrez un projet avec un prestataire et qu’il vous propose Elementor par défaut, posez-lui deux questions.
Pourquoi Elementor plutôt que Gutenberg ? S’il vous répond « c’est plus simple », demandez-lui pour qui. Pour vous ? Pour lui ? Pour votre site dans deux ans ?
Comment vous sortir du builder si vous voulez changer ? S’il n’a pas de réponse claire, vous savez ce qui vous attend.
Le bon outil n’est pas le plus puissant. C’est celui que vous arriverez à maîtriser et à transmettre.