Page builders WordPress en 2026 : Gutenberg est-il enfin prêt ?

Chaque année depuis 2018, la même question revient dans les groupes WordPress francophones : « Est-ce que Gutenberg est enfin utilisable pour un vrai projet ? » Pendant longtemps, ma réponse était non. Aujourd’hui, après avoir livré plus de 40 sites entre 2024 et 2026, je dois reconnaître que la situation a basculé. Pas complètement, pas pour tout le monde, mais suffisamment pour qu’on en parle sérieusement.

Je vais vous donner ici mon retour terrain, sans langue de bois, sur l’état réel des page builders WordPress et de Gutenberg en 2026. Pas un comparatif sponsorisé, pas un top 10 recyclé : juste ce que j’observe sur mes projets clients, avec les vrais chiffres de performance, les vrais coûts, et les vrais compromis.

État de Gutenberg en 2026 : ce qui a vraiment changé

Gutenberg n’est plus le même éditeur qu’en 2020. Le projet a franchi plusieurs étapes décisives que beaucoup de développeurs WordPress n’ont pas suivies de près.

Le Full Site Editing (FSE), stabilisé depuis WordPress 6.4, permet désormais de modifier le header, le footer, les templates d’archive et les pages 404 directement depuis l’éditeur. Plus besoin de toucher aux fichiers PHP du thème pour ce genre de personnalisation. Avec WordPress 6.7, sorti fin 2025, l’API Block Bindings permet de connecter n’importe quel bloc à un champ custom (ACF, Meta Box, ou champ natif) sans écrire une seule ligne de JavaScript. C’est un changement majeur pour les développeurs qui construisent des sites sur mesure.

Concrètement, voici ce que Gutenberg gère correctement en mai 2026 :

• Mise en page responsive avec les blocs Group, Columns, Row et Stack
• Typographie fluide et espacements configurables via theme.json
• Patterns réutilisables (ex-blocs réutilisables) avec synchronisation optionnelle
• Styles globaux pour uniformiser couleurs, polices et espacements sur tout le site
• Navigation avec menu responsive intégré (encore perfectible, mais fonctionnel)
• Requêtes de boucle (Query Loop) pour afficher des articles filtrés sans code

Ce qui manque encore ? Un vrai constructeur de formulaires natif (on dépend toujours d’extensions comme Contact Form 7 ou Fluent Forms), un système de popups, et certaines interactions avancées (onglets, accordéons animés) qui nécessitent encore des blocs tiers ou du code custom. Le handbook officiel de l’éditeur de blocs WordPress documente l’ensemble des API disponibles pour les développeurs.

Comparatif des page builders WordPress encore pertinents

Le marché s’est considérablement réduit. Divi perd du terrain, Beaver Builder survit dans sa niche agence, et de nouveaux acteurs comme Bricks et Breakdance ont redistribué les cartes. Voici mon comparatif basé sur une utilisation réelle en production.

Quelques remarques terrain. Elementor reste le choix par défaut de beaucoup de freelances, mais le passage à un modèle 100 % abonnement (plus de licence à vie depuis 2024) et l’alourdissement constant du code généré posent question. Sur mes audits de performance, un site Elementor charge en moyenne 1,2 à 1,8 seconde de plus qu’un équivalent Gutenberg à contenu identique.

Bricks Builder est devenu mon builder de prédilection quand Gutenberg ne suffit pas. Il génère un HTML propre, supporte les requêtes dynamiques avancées, et sa licence à vie évite la dépendance à un abonnement. Le compromis : la courbe d’apprentissage est raide pour un non-développeur.

Performance et vitesse : Gutenberg face aux builders tiers

La performance n’est pas un luxe en 2026. Google intègre les Core Web Vitals dans son classement depuis 2021, et je constate sur mes projets SEO que la vitesse fait une différence mesurable sur le positionnement, surtout en mobile.

J’ai mesuré les performances d’une même page (section hero, 3 colonnes de services, témoignages, CTA) construite avec différents outils sur un hébergement identique (VPS 2 Go RAM, LiteSpeed, PHP 8.3) :

Les chiffres parlent d’eux-mêmes. Gutenberg avec un thème bloc bien configuré (type developer-oriented comme Flavor theme ou un thème custom basé sur theme.json) produit un HTML 3 à 4 fois plus léger qu’Elementor ou Divi. Cet écart se traduit directement en score PageSpeed et en expérience utilisateur, surtout sur mobile avec une connexion 4G.

Attention cependant : ces résultats supposent qu’on utilise Gutenberg correctement. Si vous empilez 15 extensions de blocs tiers (Stackable, Spectra, GenerateBlocks, etc.), vous perdez une grande partie de l’avantage natif. Mon conseil : limitez-vous à une seule extension de blocs complémentaire si nécessaire, et privilégiez les patterns custom.

Quand Gutenberg suffit : les cas d’usage concrets

Voici les types de projets que je livre désormais 100 % en Gutenberg natif, sans aucun page builder tiers :

• Site vitrine de TPE/PME (5 à 15 pages) : accueil, services, à propos, contact, mentions légales. Le combo Gutenberg + un thème bloc + ACF pour les champs custom couvre tous les besoins.
• Blog professionnel ou magazine : l’éditeur de contenu de Gutenberg est son terrain de jeu naturel. Les patterns permettent de créer des mises en page éditoriales variées sans effort.
• Portfolio créatif : avec les blocs Galerie, Image et le bloc Cover, on obtient des résultats visuellement propres. Le tout sans dépendance externe.
• Landing page simple : une page d’atterrissage avec hero, arguments, témoignages et formulaire se construit en 2 heures avec des patterns réutilisables.
• Site institutionnel : les organisations qui veulent un site sobre, rapide et maintenable à long terme trouvent dans Gutenberg un allié fiable. C’est d’ailleurs la méthodologie de projet la plus simple à documenter pour une passation.

Le point commun de ces projets : des mises en page relativement standardisées, peu d’interactions JavaScript complexes, et un client qui n’a pas besoin de modifier la structure des pages lui-même (juste le contenu texte et image).

Quand un page builder reste indispensable

Gutenberg a ses limites, et les ignorer serait malhonnête. Voici les situations où je recommande encore un builder tiers :

Sites e-commerce complexes avec WooCommerce. Les pages produit personnalisées, les pages de catégorie avec filtres avancés, les tunnels de vente sur mesure : Gutenberg ne gère pas tout cela nativement. Bricks Builder avec ses éléments WooCommerce intégrés reste bien plus efficace.

Portails avec des dizaines de templates différents. Quand un site a 8 types de contenu custom, chacun avec son propre layout, la gestion via le FSE de Gutenberg devient fastidieuse. Un builder avec son système de templates dynamiques (Bricks, Oxygen) offre un workflow plus productif.

Clients qui veulent modifier la structure eux-mêmes. Malgré ses progrès, Gutenberg reste moins intuitif qu’Elementor pour un client non-technique qui souhaite réagencer des sections. Si l’autonomie du client est un critère prioritaire, Elementor ou Breakdance gardent l’avantage.

Maquettes design très spécifiques. Certains designs nécessitent un contrôle pixel-perfect sur chaque breakpoint. Gutenberg propose du responsive, mais pas avec la granularité d’un Bricks ou d’un Oxygen qui permettent de cibler mobile, tablette et desktop séparément pour chaque propriété CSS.

Pour la gestion d’un projet informatique impliquant WordPress, le choix du builder doit se faire dès le cadrage, pas en cours de développement.

Coût, licence et maintenance à long terme

Le coût d’un page builder ne se limite pas au prix de la licence. Il faut intégrer la dette technique, le coût de maintenance, et le risque de dépendance.

Le piège de l’abonnement. Elementor Pro à 59 $/an, Divi à 89 $/an, Breakdance à 149 $/an : ces coûts s’accumulent. Sur 5 ans, un site Elementor Pro aura coûté 295 $ rien qu’en licence builder. Gutenberg : 0 €. Bricks avec sa licence à vie : 79 $ une fois. Pour un freelance qui gère 20 sites clients, la différence est considérable.

Le lock-in (verrouillage). C’est le vrai danger. Si vous construisez un site avec Elementor et que vous décidez de ne plus renouveler la licence, votre site continue de fonctionner mais vous ne recevez plus les mises à jour de sécurité ni les correctifs de compatibilité. Pire : si vous voulez migrer vers un autre outil, vous devez reconstruire chaque page manuellement. Gutenberg, étant intégré au cœur de WordPress, n’a pas ce problème. Vos contenus restent en blocs HTML standard, lisibles même si vous changez de thème.

La part de marché de WordPress selon W3Techs confirme que le CMS propulse encore plus de 43 % du web en 2026 ; choisir un éditeur pérenne est donc un enjeu stratégique.

La compatibilité dans le temps. WordPress sort 3 à 4 mises à jour majeures par an. Chaque mise à jour peut casser un builder tiers. J’ai vu des sites Divi inaccessibles pendant 48 heures après une mise à jour WordPress parce que l’extension n’avait pas encore publié son correctif. Avec Gutenberg, la compatibilité est garantie puisque l’éditeur fait partie du cœur.

Pour les freelances qui facturent la maintenance, j’en parle aussi dans mon guide sur la facturation avec Henri : anticipez ces coûts récurrents dans vos devis.

Migrer d’un page builder vers Gutenberg : méthode et pièges

Si vous avez un site existant sous Elementor, Divi ou un autre builder et que vous envisagez de passer à Gutenberg, voici ma méthode éprouvée sur une dizaine de migrations.

Étape 1 : audit du contenu existant. Listez toutes les pages, identifiez les éléments dynamiques (formulaires, sliders, onglets, accordéons), et évaluez le volume de travail. Sur un site de 20 pages, comptez 3 à 5 jours de migration effective.

Étape 2 : création du thème bloc. Configurez un thème basé sur theme.json avec vos couleurs, polices, et espacements. Créez vos patterns réutilisables pour les sections communes (header, footer, CTA, témoignages). C’est l’investissement initial qui fera gagner du temps sur chaque page.

Étape 3 : migration page par page en staging. Ne migrez jamais en production. Utilisez un environnement de staging, reconstruisez chaque page avec les blocs natifs, et validez avec le client avant de basculer. Suivez les étapes classiques de gestion de projet pour structurer cette transition.

Étape 4 : désactivation progressive. Une fois toutes les pages migrées, désactivez l’ancien builder (ne le supprimez pas immédiatement) et vérifiez que tout fonctionne pendant une semaine. Puis supprimez-le et nettoyez la base de données des shortcodes résiduels.

Les pièges courants :

• Les shortcodes Elementor qui restent en clair dans le contenu après désactivation : utilisez un plugin de nettoyage comme Better Search Replace
• Les CSS custom ajoutés dans le builder qui disparaissent : exportez-les avant la migration
• Les redirections et ancres internes qui changent d’URL : vérifiez chaque lien interne avec Screaming Frog ou un crawler similaire
• Les champs ACF liés au builder : vérifiez que Block Bindings ou vos templates PHP reprennent bien les données

Mon workflow freelance en 2026 : comment je choisis

Après 11 ans de freelance à Paris et des centaines de sites livrés, j’ai fini par établir un arbre de décision simple que j’applique à chaque nouveau projet.

Question 1 : le client doit-il modifier la structure des pages ? Si oui et qu’il n’est pas technique, je pars sur Breakdance ou Elementor. Si non (il modifie juste texte et images), Gutenberg suffit.

Question 2 : y a-t-il du e-commerce ou des templates dynamiques complexes ? Si oui, Bricks Builder. Sinon, Gutenberg.

Question 3 : quel est le budget ? Pour les petits budgets (moins de 2 000 € HT), Gutenberg est la seule option raisonnable. Chaque euro compte, et payer une licence builder sur un projet serré n’a pas de sens quand l’éditeur natif fait le travail.

Question 4 : quelle est la durée de vie prévue du site ? Pour un site qui doit durer 5 ans et plus sans refonte majeure, je privilégie Gutenberg pour sa pérennité. Pour un site événementiel ou temporaire, le builder le plus rapide à déployer l’emporte. C’est une logique que j’applique aussi quand je choisis entre cloud et on-premises pour l’hébergement.

En pratique, sur mes 10 derniers projets : 6 en Gutenberg pur, 3 en Bricks, 1 en Elementor (demande explicite du client qui connaissait déjà l’outil). La tendance est nette.

Pour suivre la performance de mes sites après livraison, Google Analytics reste incontournable comme outil de mesure.

L’avenir de l’éditeur WordPress après 2026

La roadmap de WordPress indique clairement la direction : Gutenberg doit devenir l’outil unique de construction de sites. La phase 3 (collaboration en temps réel) est en cours de développement, et la phase 4 (multilingue natif) est planifiée. Si ces deux phases aboutissent, deux des dernières raisons majeures d’utiliser un builder tiers ou des extensions lourdes disparaîtront.

L’intelligence artificielle entre aussi dans l’équation. WordPress.com intègre déjà un assistant IA pour la rédaction, et plusieurs extensions de blocs expérimentent la génération de layouts par prompt. On peut imaginer qu’en 2027, on décrira une page en langage naturel et que Gutenberg générera la structure de blocs correspondante.

Côté builders tiers, la consolidation se poursuit. Breakdance (créé par l’équipe d’Oxygen) tente de combiner la puissance d’Oxygen avec la simplicité d’Elementor. Bricks continue d’innover avec un écosystème d’extensions grandissant. Mais tous doivent composer avec un Gutenberg de plus en plus capable qui grignote leur proposition de valeur.

Mon pronostic : d’ici 2028, les page builders tiers ne disparaîtront pas, mais ils se repositionneront sur des niches spécifiques (e-commerce avancé, sites d’applications, portails complexes) plutôt que sur le marché généraliste du site vitrine, que Gutenberg aura largement conquis. La montée en puissance du cloud et des solutions headless pourrait aussi redistribuer les cartes pour les projets les plus ambitieux.

Le blog officiel Make WordPress Core publie chaque semaine l’avancement des développements du cœur et de Gutenberg ; c’est la source la plus fiable pour suivre ces évolutions.