Aller au contenu
Edouard Simon Le tech qui parle business.

Développement WordPress

Pourquoi les page builders sont l’erreur n°1 sur WordPress

Elementor, Divi, WPBakery : pourquoi ces outils détruisent votre site sur la durée, et l'approche custom qui résout vraiment le problème.

Edouard Simon · · 4 min de lecture
Pourquoi les page builders sont l'erreur n°1 sur WordPress

Elementor, Divi, WPBakery, Beaver Builder. 70% des sites WordPress en France tournent avec un de ces page builders. Et 70% de ces sites souffrent des mêmes problèmes : lenteur, instabilité, dépendance verrouillée, code illisible. Voilà pourquoi je n’en utilise jamais — et ce qu’on fait à la place.

Le problème de fond : confusion des rôles

Un page builder, c’est donner accès au front-end et au layout à des gens dont le rôle est juste d’éditer du contenu.

Marie, responsable marketing, doit publier un nouvel article. Avec un page builder, on lui demande de :

  • Choisir un template
  • Glisser-déposer des sections
  • Régler des marges, des paddings, des couleurs
  • Vérifier que c’est responsive
  • Ne pas casser le design global

Marie n’est pas designer. Marie n’est pas développeuse. Marie veut juste publier son article. Résultat : le site devient un patchwork de styles incohérents, chaque page diffère, le designer rage.

L’autre option ? On code en custom. Marie a un formulaire avec 5 champs ACF : titre, chapô, image, contenu, tags. Elle remplit, elle publie. Le layout est garanti par le développeur. Tout le monde fait son métier.

Les 6 dégâts concrets des page builders

1. Performance catastrophique

Elementor charge 1.2 Mo de JS et 800 Ko de CSS par défaut. Sur mobile 4G, c’est 4 secondes de chargement minimum. Lighthouse vous met 35/100 en performance. Google sait — et vous pénalise.

2. HTML inutilisable

Vingt couches de <div class="elementor-widget elementor-widget-text-editor"> imbriquées. Aucune sémantique. Accessibilité catastrophique. Cauchemar pour le SEO technique.

3. Verrouillage (lock-in)

Vos contenus sont stockés en JSON sérialisé dans des shortcodes propriétaires. Désinstaller Elementor = perdre tous vos articles. Migrer vers un autre builder = refaire le site.

4. Sécurité

Elementor et Divi ont eu plusieurs CVEs critiques (RCE, XSS) en 2023-2025. Plus le plugin a de surface, plus il a de vulnérabilités.

5. Coût caché

Licence annuelle : 100-200 €. Plugins addon nécessaires (Elementor Pro, Crocoblock JetEngine, etc.) : 200-500 €/an. Hébergement plus cher (le site mange plus de RAM). Total : ~600-1000 € de surcharge annuelle.

6. Évolutivité zéro

Refonte dans 3 ans ? Vous repartez de zéro. Tout votre contenu est prisonnier d’un format propriétaire.

L’approche custom : ACF + CPT + blocs sur mesure

Ce qu’on fait à la place :

  1. Custom Post Types pour le contenu structuré (réalisations, services, témoignages, articles).
  2. Champs ACF pour chaque type de contenu : un éditeur a un formulaire propre avec exactement les champs dont il a besoin.
  3. ACF Flexible Content pour les pages composables : un répertoire de « blocs » prédéfinis (hero, services, FAQ, CTA, etc.) que l’éditeur empile comme des briques. Chaque bloc est codé proprement par le dev.
  4. Tailwind + Vite pour un CSS optimisé et un build léger.

Résultat ?

  • CSS final : 50-80 KB (vs 800 KB Elementor)
  • JS : 2-10 KB (vs 1.2 MB)
  • Lighthouse : 95+
  • Code lisible : un autre dev reprend en 10 minutes
  • Aucun lock-in : votre contenu est en méta WordPress standard, portable ailleurs

« Mais le client veut éditer lui-même ! »

C’est l’objection classique. Réponse : il pourra éditer le contenu, pas le layout. Différence fondamentale. Avec ACF Flexible Content, le client compose ses pages en empilant des blocs (Hero, Services, FAQ, etc.) sans toucher au CSS, au HTML, ou au responsive. Il a la liberté éditoriale, pas la liberté de tout casser.

Et concrètement, dans 95% des cas, le client veut juste pouvoir changer un texte ou une image. Pas refaire son layout. Donnez-lui un champ texte. C’est tout.

TL;DR

  • Les page builders confondent édition de contenu et conception de layout
  • Performance, sécurité, accessibilité, SEO, coût : 6 axes où ils sont mauvais
  • L’approche custom (CPT + ACF + blocs codés) résout tout : code propre, perf max, contenu portable
  • Le client édite le contenu sans casser le design

Vous avez un site WordPress lourd, lent, ou que vous ne maîtrisez plus ? Discutons d’une refonte custom.

Un projet en réflexion ?

Si cet article a éclairé votre besoin, on peut en discuter de vive voix. 30 minutes, sans engagement.

Planifier un échange