Pourquoi je n’utilise plus de constructeur de pages WordPress

On m’a demandé 100 fois quel constructeur de pages choisir pour WordPress. Divi ? Elementor ? Beaver Builder ? Bricks ?

Ma réponse, depuis 3 ans maintenant : aucun.

En 2022, j’ai donné une conférence au WordCamp Lyon intitulée "Puis-je me passer d’Elementor grâce à Gutenberg ?". Il y avait un peu de monde dans la salle et des regards sceptiques. Trois ans plus tard, les faits m’ont donné raison. Et je vais vous montrer pourquoi, chiffres à l’appui.

Le verrouillage propriétaire : vous êtes prisonniers

Le verrouillage propriétaire (vendor lock-in), ça te parle ? C’est simple : tu construis ton site avec un outil, et le jour où tu veux en changer, tout s’effondre. Tu es prisonnier. Et la plupart du temps, tu ne le sais même pas.

Avec Divi 4 (celle que 90% des sites Divi utilisent encore), chaque section de ta page est stockée sous forme de shortcodes propriétaires. Désactive Divi, et voici ce qui reste de ta belle page d’accueil :

[et_pb_section][et_pb_row][et_pb_column]Votre texte ici[/et_pb_column][/et_pb_row][/et_pb_section]

Illisible. Inutilisable. Irrécupérable. Tout ton contenu est là, mais enfoui sous des couches de balisage propriétaire. Pagely l’a documenté déjà en 2018: ces builders laissent derrière eux des masses de shortcodes qui rendent la migration quasi impossible sans intervention manuelle.

Elementor, c’est différent mais pas mieux. Tout est stocké dans un champ _elementor_data en JSON dans la table wp_postmeta. Un JSON de 200 à 500 Ko par page. Désactive Elementor : ta page affiche un texte brut sans aucune mise en forme, ou pire, du HTML cassé. RTCamp, une agence WordPress de référence, l’explique en détail : l’approche Elementor (imbrication excessive de <div> et classes CSS propriétaires) crée un DOM surdimensionné qui ne survit pas à la désactivation du plugin.

Bref. Ces "outils" te capturent. Tu entres facilement, tu ne sors jamais ou du moins difficilement. C’est leur modèle économique : te rendre dépendant pour que tu renouvelles ta licence à 89, 199 ou 249 dollars chaque année. Et ça marche formidablement bien… pour eux.

Avec l’éditeur natif de WordPress, tes blocs sont du HTML standard. Désactive-le (si un jour tu en as l’idée) : ton contenu reste intact, lisible, exploitable. C’est du HTML. Point.

940 Ko par page, 54 requêtes HTTP : les chiffres qui font mal

Avez-vous déjà regardé le poids d’une page Elementor dans les DevTools ? Moi oui. Et ça fait mal. Pas un peu. Beaucoup.

Selon le benchmark WP-Rocket 2026, une page Elementor pèse en moyenne 940 Ko avec 15 requêtes HTTP, un LCP de 5,4 secondes et un score PageSpeed Mobile de 75/100. Divi fait à peine mieux : 874 Ko, mais avec 36 requêtes HTTP et un LCP de 5,8 secondes pour un score mobile de 64/100. Les deux en zone rouge.

WP Bullet a mesuré le même problème sur un autre angle : Elementor génère 512 Ko de poids de page et 54 requêtes HTTP là où un GenerateBlocks produit 331 Ko et 34 requêtes. C’est 35% de poids en moins et 37% de requêtes en moins, juste en virant le builder.

Et Divi ? Accelera a démontré que Divi injecte 115 Ko de CSS inline directement dans le HTML, ce qui empêche toute mise en cache navigateur. Résultat : le TTFB est presque le double de celui d’un site sur l’éditeur natif, et le Load Event 50% plus lent.

Et pourquoi c’est grave ? Parce que Google et Deloitte l’ont mesuré dans leur étude "Milliseconds Make Millions" : 0,1 seconde d’amélioration du temps de chargement mobile, c’est +8,4% de conversions dans le e-commerce et +9,2% de panier moyen. À l’inverse, SOASTA/Google montre que chaque seconde de délai coûte jusqu’à 20% de conversions perdues. Et 53% des visiteurs mobile quittent si la page met plus de 3 secondes à s’afficher (source).

Et si vous voulez encore un tableau comparatif complet, PluginTheme.net a mesuré les 5 principaux builders en février 2026 : l’éditeur natif obtient un score Lighthouse de 90-96, contre 72-78 pour Elementor, 65-72 pour Divi, et 58-65 pour WPBakery. Le TTFB de l’éditeur natif (180 ms) est deux fois plus rapide que celui de Divi (380 ms). Les éléments DOM ? 400 en natif, 1 200 pour Elementor, 1 600 pour WPBakery.

Votre builder vous coûte de l’argent. Littéralement.

152 Mo dans votre base de données : le mal silencieux

On l’oublie trop souvent mais le problème ne s’arrête pas au frontend. Les constructeurs de pages pourrissent également votre base de données.

Bug report #19901 sur GitHub (rapporté par les utilisateurs eux-mêmes sur le dépôt officiel d’Elementor) : le plugin génère 150 à 200 enregistrements orphelins par page par jour dans wp_postmeta. Vous lisez bien : par page, par jour. Sur un site de 50 pages, ça fait potentiellement 10 000 lignes fantômes par semaine dans votre BDD.

Un utilisateur a documenté son cas : sa table wp_postmeta avait gonflé à 152 Mo (contre 2 Mo normalement), principalement à cause des données SVG inline stockées par Elementor. Et un topic du forum officiel WordPress.org confirme le problème : wp_posts à 300 Mo, wp_postmeta à 120 Mo, tout ça à cause des révisions excessives et des meta orphelines générées par Elementor.

Un site avec l’éditeur natif de WordPress ? Le contenu est dans post_content, en HTML. Propre, léger, indexable. Pas de table satellite, pas de JSON propriétaire, pas de bloat.

CVSS 9.8 : quand votre constructeur devient une porte ouverte

Vous savez ce que signifie un score CVSS de 9.8 sur 10 ? C’est le niveau "critique". Exécution de code à distance, sans authentification. Le genre de faille qui permet à n’importe qui de prendre le contrôle complet de votre site.

Et c’est exactement ce qui est arrivé à Elementor. CVE-2023-48777 (CVSS 8.8) : upload de fichiers arbitraires via l’import de templates, ce qui revient à donner les clés de votre serveur à n’importe quel contributeur. Toutes les versions d’Elementor jusqu’à 3.18.1 étaient touchées, soit 5 millions de sites.

Et le pire : les addons. Essential Addons for Elementor (CVE-2023-32243, CVSS 9.8) : reset de mot de passe administrateur sans authentification. Activement exploité. Bricks Builder ? RCE exploitée avant même le patch début 2024.

Plus vous ajoutez de couches entre vous et WordPress, plus vous augmentez la surface d’attaque. Le rapport Patchstack 2026 est sans appel : 11 334 vulnérabilités dans l’écosystème WordPress en 2025 (+42% vs 2024), dont 96% proviennent des plugins. Et le temps médian d’exploitation est de 5 heures après divulgation. Pas 5 jours. 5 heures.

Chaque plugin que vous ajoutez est un vecteur d’attaque potentiel. Un constructeur de pages, avec ses addons et ses dépendances, c’est un boulevard.

Il y a 3 semaines, un client m’a appelé

Son site e-commerce était une vraie tortue. Dix secondes pour changer de page, dix secondes pour passer d’un produit à un autre. Il vend du matériel, ses positions Google chutaient depuis des mois. Et cerise sur le gâteau : un piratage il y a un mois.

Je prends la main et là, je découvre le désastre : un thème "premium" dézippé trouvé sur ThemeForest, couplé avec Elementor Pro, et WooCommerce. Plus de 60 plugins installés, dont certains faisaient double emploi. Le tout pas mis à jour correctement. Le prestataire d’origine ne faisait que rajouter patch sur patch sur patch sans jamais traiter le problème de fond. Beaucoup de fonctionnalités ne marchaient tout simplement plus.

Et la goutte d’eau ? Une transition catastrophique de Polylang Pro vers WPML qui a fini de tout casser. C’est à ce moment que le client a décidé de prendre le taureau par les cornes et de corriger le tir.

Arghhhh. Et le pire, c’est que je vois ça tout le temps. C’est le scénario numéro 1 dans mes formations : un site WordPress transformé en usine à gaz par un empilement de couches (thème lourd ThemeForest + builder + 60 plugins + traduction) où plus personne ne sait ce qui fait quoi, et où chaque mise à jour est une roulette russe.

Le constructeur de page n’est bien évidemment pas le seul responsable mais clairement, ça n’aide pas!

L’éditeur natif fait déjà tout ça

Rappelons un truc que les fans de builders oublient systématiquement : l’éditeur de blocs, c’est l’éditeur natif de WordPress. Pas un plugin tiers. Pas un produit d’une société privée. C’est WordPress lui-même. Intégré au core depuis WordPress 5.0, fin 2018. Maintenu par la communauté entière. Et il n’a pas attendu WordPress 7 pour être excellent.

Ce que vous avez déjà, aujourd’hui, sans aucun builder :

• Des dizaines de blocs natifs : paragraphes, images, galeries, colonnes, boutons, tableaux, vidéos, citations, groupes, covers… et ce n’est que le core. On peut en ajouter autant qu’on veut avec des extensions légères.
• Des compositions prêtes à l’emploi : des sections entières pré-designées (hero, témoignages, pricing, CTA, FAQ) que vous glissez-déposez en un clic. Twenty Twenty-Five en embarque plus de 70.
• Le Full Site Editing : header, footer, templates, le site entier se construit dans l’éditeur natif. Plus besoin d’un builder pour ça. C’est fini depuis un moment déjà.
• Un gain de vitesse incomparable : 35% de poids en moins et 37% de requêtes en moins rien qu’en passant d’Elementor à des blocs natifs. C’est mesurable, vérifiable, reproduisible.

Et si les blocs natifs ne suffisent pas, des extensions comme Spectra (Brainstorm Force), Stackable, GenerateBlocks ou Kadence Blocks ajoutent des dizaines de blocs supplémentaires : formulaires avancés, grilles, compteurs, onglets, accordions… 100% compatibles avec l’éditeur natif, sans ajouter 400 Ko de CSS propriétaire. L’écosystème est immense et il grossit chaque semaine.

Pour wpformation.com, j’ai poussé le concept à l’extrême : le site tourne en WordPress headless avec Next.js en frontend. Zéro builder, zéro CSS superflu. Résultat : PageSpeed Mobile 96/100. Mais le headless, c’est un choix de développeur. Ce n’est pas nécessaire pour obtenir d’excellentes performances : un thème FSE léger avec l’éditeur natif suffit largement.

Et avec WordPress 7.0, c’est encore mieux

Tout ce que je viens de décrire existait déjà avant. Mais avec l’arrivée de WordPress 7.0, l’éditeur natif prend une avance définitive :

• Collaboration temps réel : éditez à plusieurs simultanément, comme sur Google Docs. Les curseurs des collaborateurs sont visibles en direct. Essayez de faire ça avec Divi.
• AI Connectors natifs : intégration IA provider-agnostic (OpenAI, Google, Anthropic) directement dans le core. Pas besoin d’un addon payant ou d’un abonnement supplémentaire que vous allez encore devoir acheter auprès de votre constructeur de pages préféré
• DataViews : l’admin WordPress fait peau neuve avec une interface moderne qui remplace les vieilles listes.
• Command Palette (Cmd+K) : navigation instantanée dans l’admin.

Autant dire que l’argument "l’éditeur natif n’est pas prêt" ne tient plus. Et il ne tiendra plus jamais.

Ollie, GreenShift, Frost : des thèmes qui enterrent les builders

Ça paraît évident, mais… le choix du thème est aussi important que le choix de l’éditeur. Et en 2026, les thèmes FSE (Full Site Editing) nouvelle génération sont une claque.

Oubliez les thèmes ThemeForest à 200 options qui chargent 3 frameworks JavaScript. Voici ce qui existe aujourd’hui :

• Ollie : 50+ compositions personnalisées, PageSpeed 100/100 out of the box, temps de chargement sous 500 ms. Noté 5/5 sur WordPress.org (33 avis, tous 5 étoiles). Avec un assistant de configuration intégré pour les débutants.
• GreenShift : 2 Ko de CSS requis. Vous avez bien lu. Deux kilo-octets. Chargement conditionnel, zéro jQuery, zéro polices globales. Score 100 Core Web Vitals sans plugin de cache.
• Frost : créé par Brian Gardner (le père du framework Genesis/StudioPress), soutenu par WP Engine. Open source, 36 compositions pro, design épuré. L’expertise de 15 ans de Genesis appliquée au FSE.
• Twenty Twenty-Five : le thème officiel de WordPress. 70+ compositions, 100% gratuit, support à vie, PageSpeed 100/100. Pas excitant visuellement, mais solide comme un roc.

Comparez ça avec un thème ThemeForest à 59 dollars qui charge jQuery, Font Awesome, trois librairies CSS, un slider Revolution et un constructeur de pages intégré. On n’est pas dans le même monde.

Et pour ceux qui veulent aller plus loin, notre guide complet sur l’éditeur de blocs couvre tout ce que vous devez savoir.

Les "comparatifs" ou "recommandations" WordPress

Et si vous vous demandez pourquoi tant de blogs WordPress continuent de recommander ces usines à gaz ?

La réponse tient en deux mots : commissions d’affiliation. Elementor Pro, Divi, Beaver Builder… ils ont tous des programmes d’affiliation très généreux. Écrivez un "comparatif" complaisant, glissez votre lien affilié, et vous touchez votre obole. En français comme en anglais, c’est la même mécanique. Le même cirque. Les mêmes "tests" rédigés avec le portefeuille en tête et pas l’intérêt du lecteur.

On m’a dit un jour : "Quand tu vends un produit, ne parle que des aspects positifs. Les autres se chargeront des aspects négatifs." C’est clairement vrai!

Ce n’est pas mon cas. Je ne touche pas un centime des outils que je recommande ou que je déconseille. Quand je dis que l’éditeur natif suffit, c’est parce que je le pense, pas parce que quelqu’un me paie pour le dire. C’est d’ailleurs pour ça que j’ai créé le Protocole Crash-Test : une déclaration d’intention sur la façon dont je teste et évalue les outils WordPress. Transparence totale, zéro affiliation.

Et un petit truc qui m’a horrifié : sur le Détecteur WordPress que j’ai créé (un outil gratuit qui analyse les sites WordPress), les Top 7 des thèmes et des plugins détectés affichent Divi et Elementor en tête. En première position. Partout. C’est devenu systémique. Et c’est un problème.

La prochaine fois que vous lisez un article intitulé "Divi vs Elementor : lequel choisir ?" ou "Elementor est juste est génial, achetez le", posez-vous une seule question : l’auteur touche-t-il une commission ?

L’agence ou le freelance qui ne sait pas faire sans

Un prestataire qui ne peut pas faire autrement qu’avec Divi ou Elementor, c’est un prestataire qui a un seul outil dans sa boîte. Et quand on n’a qu’un marteau, tout ressemble à un clou.

Je ne dis pas que c’est de la mauvaise foi. Beaucoup de freelances ont appris WordPress avec ces outils, ont construit leur workflow dessus, et n’ont jamais eu la curiosité ou le temps d’explorer l’éditeur natif. C’est compréhensible. Mais ça devient ton problème si tu leur confies ton site.

Ce que tu mérites, c’est une explication. Pourquoi un constructeur de pages sur ce projet précis ? Quels sont les avantages, quels sont les inconvénients ? Qu’est-ce qui se passe si tu veux changer de prestataire dans deux ans ? Si le développeur est capable de répondre clairement à ces trois questions, pas de te faire un cours magistral, juste d’être transparent, alors tu peux avancer en connaissance de cause. Vous faites un choix ensemble.

Mais si la réponse est "on travaille comme ça", ou "c’est la meilleure option, y a pas mieux", c’est que le choix n’a jamais vraiment été fait. Il s’est imposé par habitude. Et ton site en supportera les conséquences.

Les cas où je ferme les yeux (mais pas les deux)

Je suis honnête. Il y a des situations où un constructeur de pages a encore du sens :

Si votre client est une équipe marketing qui crée des landing pages à la chaîne sans développeur, un builder bien configuré peut faire gagner du temps. L’important, c’est que la décision soit consciente : vous acceptez le surcoût en performance, en sécurité et en maintenance pour gagner en autonomie de création.

Si vous avez déjà 200 pages construites sous Divi ou Elementor, migrer du jour au lendemain n’a pas de sens. Commencez par les nouvelles pages dans l’éditeur natif, migrez les anciennes progressivement.

Mais soyons clairs : ce sont des exceptions, pas la règle. Pour un nouveau projet WordPress en 2026, choisir un constructeur de pages quand l’éditeur natif fait le même boulot en plus léger, plus rapide, plus sûr et sans verrouillage… c’est un choix que je ne comprends plus. Et que je ne recommanderai plus.

Si vous utilisez déjà un builder et qu’il vous convient, pas de panique. Consultez notre guide Divi ou notre tutoriel Elementor pour en tirer le meilleur. Mon propos n’est pas de vous conseiller de migrer demain. C’est simplement de vous ouvrir les yeux sur ce qui existe à côté.

Le meilleur outil, c’est celui que tu peux quitter

Quand j’ai commencé à former sur WordPress il y a plus de 14 ans, les constructeurs de pages n’existaient pas. On faisait des sites avec du HTML, du CSS, et un bon thème. Et ça marchait.

Puis les builders sont arrivés, avec une promesse séduisante : "construisez n’importe quoi sans coder". Et c’est vrai, ils ont démocratisé la création de sites. Je leur reconnais ça.

Mais en 2026, l’éditeur natif de WordPress fait la même chose. En plus léger (35% de poids en moins). En plus rapide. En plus sûr. Sans vous enfermer. Et avec la communauté entière qui pousse dans la même direction.

Le vrai test d’un bon outil, c’est de pouvoir le quitter sans tout perdre. C’est le cas de l’éditeur natif. Ce n’est pas le cas des constructeurs de pages. Et ça, c’est rédhibitoire.

De facto, si vous démarrez un nouveau projet WordPress aujourd’hui, faites-le sans builder. Votre site sera plus rapide, votre base de données plus propre, votre surface d’attaque réduite, et vous n’aurez plus jamais à vous demander si votre constructeur de pages va survivre à la prochaine mise à jour.

Pour aller plus loin, consultez notre guide complet sur l’éditeur de blocs ou notre article sur les nouveautés de WordPress 7.

Peut-on vraiment tout faire avec l’éditeur natif sans constructeur de pages ?

En 2026, l’éditeur de blocs natif de WordPress avec le Full Site Editing couvre 90% des besoins : header, footer, templates, blocs de contenu, compositions prêtes à l’emploi. Pour les 10% restants, des extensions comme Spectra, Stackable ou GenerateBlocks ajoutent des blocs avancés sans le poids d’un constructeur complet. Sur wpformation.com (WordPress headless + Next.js), on obtient un PageSpeed Mobile de 96/100 sans aucun builder.

Quel impact les constructeurs de pages ont-ils sur le PageSpeed ?

Selon le benchmark WP-Rocket 2026, une page Elementor pèse 940 Ko (score PageSpeed Mobile 75/100) et une page Divi 874 Ko (score 64/100). En comparaison, un site sur l’éditeur natif avec un thème FSE léger comme GreenShift charge à peine 2 Ko de CSS. L’étude Google/Deloitte "Milliseconds Make Millions" démontre que 0,1 seconde d’amélioration génère +8,4% de conversions e-commerce.

Divi 5 a-t-il résolu le problème du verrouillage propriétaire ?

Divi 5, sorti en février 2026, a fait des progrès : fin des shortcodes, architecture React, performances améliorées. Mais le stockage reste propriétaire. Désactivez Divi 5 et votre mise en page disparaît. Le verrouillage propriétaire (vendor lock-in) demeure. Un site sur l’éditeur natif avec un thème FSE reste plus performant et surtout : libéré de toute dépendance.

Quels thèmes FSE choisir pour remplacer un constructeur de pages ?

En 2026, les thèmes FSE recommandés sont Ollie (50+ compositions, PageSpeed 100/100, noté 5/5), GreenShift (2 Ko de CSS, chargement conditionnel), Frost (héritage Genesis, open source), et Twenty Twenty-Five (thème officiel, 70+ compositions, gratuit). Tous sont compatibles Full Site Editing et fonctionnent nativement avec l’éditeur de blocs.

Les constructeurs de pages représentent-ils un risque de sécurité ?

Oui. Elementor Pro a subi une vulnérabilité critique CVSS 9.8 (CVE-2024-28847) permettant l’exécution de code à distance. Essential Addons for Elementor a été activement exploité via la CVE-2023-32243 (CVSS 9.8, reset mot de passe admin). Bricks Builder a subi une RCE exploitée avant le patch en 2024. Le rapport Patchstack 2026 recense 11 334 vulnérabilités dans l’écosystème WordPress, avec un temps médian d’exploitation de 5 heures après divulgation.