« Ai-je encore besoin d'Elementor, maintenant que WordPress est livré avec son propre éditeur ? » Cette question, on me la pose désormais presque chaque semaine — et à juste titre. Gutenberg, l'éditeur de blocs natif de WordPress, est passé en quelques années du statut de « remplaçant moqué de l'éditeur classique » à celui d'outil de création de site à prendre au sérieux. Avec le Full Site Editing (FSE), on peut désormais concevoir des thèmes entiers dans l'éditeur lui-même — sans la moindre extension supplémentaire. Dans le même temps, Elementor reste, avec bien plus de 10 millions d'installations actives, le constructeur de pages le plus utilisé au monde, et des outils comme Bricks Builder montrent que l'on continue de développer vigoureusement à l'autre bout de l'échelle. Comme j'ai bâti tout mon travail de formation sur Elementor pendant des années, je voulais répondre honnêtement à cette question plutôt que de l'écarter d'un revers de main. Voici où j'en suis en 2026.
La réponse courte
Tout dépend de qui s'occupe du site — et non de savoir quel outil est le plus « moderne ». Si vous êtes à l'aise techniquement, que vous travaillez avec un thème par blocs bien conçu et que vous gérez avant tout des contenus plutôt que des mises en page complexes, Gutenberg et le FSE sont en 2026 une excellente solution, gratuite et légère. Si, en tant qu'indépendant, PME ou agence sans ressource de développement, vous voulez arriver vite à un résultat personnalisé et visuellement exigeant — et c'est le cas de la grande majorité de mes clients et de mes stagiaires —, un constructeur de pages comme Elementor reste le choix le plus pragmatique. Il n'existe pas ici de « meilleur » universel, seulement un « meilleur pour votre situation ».
La réponse détaillée
Les deux approches résolvent le même problème de fond — mettre en forme des pages WordPress sans savoir coder — mais selon des philosophies fondamentalement différentes. Gutenberg raisonne en blocs à l'intérieur d'un thème : le thème définit via theme.json des règles de design (couleurs, espacements, tailles de police), et vous placez des blocs à l'intérieur de ce cadre. Les constructeurs de pages comme Elementor raisonnent indépendamment du thème : vous faites glisser des éléments sur la page, avec un contrôle visuel total sur pratiquement chaque pixel, quoi que prescrive le thème actif.
Cette différence de logique explique presque toutes les divergences qui suivent — de la courbe d'apprentissage aux performances.
Le comparatif en un coup d'œil
| Critère | Gutenberg / Full Site Editing | Constructeur de pages (Elementor, Bricks) |
|---|---|---|
| Courbe d'apprentissage | Moyenne à raide pour les mises en page complexes, très douce pour de simples articles | Douce — visuel, WYSIWYG, immédiatement compréhensible |
| Souplesse de design | Bonne, mais liée à la structure du thème | Très élevée, contrôle au pixel près, indépendant du thème |
| Surcoût de performance | Très faible — aucune extension supplémentaire nécessaire | Sensible — CSS/JS additionnels, charge accrue de la base de données |
| Bibliothèque de gabarits et de compositions | En croissance (plus de 2 500 thèmes par blocs en 2026), mais moins peaufinée | Immense, très aboutie, utilisable immédiatement |
| Pérennité et feuille de route | Cœur de WordPress, phase 3 (collaboration) en cours en 2026 | Dépend de l'éditeur de l'extension, mais les leaders du marché sont stables |
| Prix | 0 € (partie intégrante de WordPress) | Version gratuite disponible, licences Pro à partir d'environ 59–99 € par an |
Gutenberg et le FSE : les points forts
Les progrès depuis 2022 sont réels, et pas seulement marketing. Trois points ressortent.
Aucune extension supplémentaire, aucun poids supplémentaire. Gutenberg fait partie du cœur de WordPress. Il n'y a pas de framework CSS additionnel ni de bibliothèque JavaScript supplémentaire à charger. Pour les projets sensibles à la performance — blogs légers, sites portfolio, sites portés par le contenu —, c'est un avantage concret.
theme.json et les systèmes de design natifs. Depuis WordPress 5.9, theme.json permet de définir un système de design complet : palettes de couleurs, préréglages typographiques, trame d'espacements. Une fois cela proprement en place, la cohérence est garantie sur tout le site — sans qu'un rédacteur puisse choisir par mégarde une mauvaise taille de police.
L'édition native des gabarits. Avec le Full Site Editing, en-têtes, pieds de page, gabarits d'article et pages d'archives se modifient directement dans l'éditeur — sans toucher au moindre fichier de gabarit PHP. Plus de 2 500 thèmes par blocs figurent en 2026 au répertoire WordPress.org, contre environ 400 en 2023. Selon les analyses de marché récentes, l'usage du FSE progresse d'environ 145 % d'une année sur l'autre — de loin le taux de croissance le plus élevé de toutes les approches de construction sous WordPress.
En 2026, l'effort de développement (la « phase 3 » de Gutenberg) porte sur la collaboration en temps réel dans l'éditeur — plusieurs personnes travaillant simultanément sur le même article ou le même gabarit, à la manière de Google Docs, avec curseurs en direct et verrouillage au niveau du bloc. Pour les équipes éditoriales, c'est un progrès sensible.
Gutenberg et le FSE : les points faibles
Malgré tous ces progrès, des limites bien concrètes demeurent.
Une courbe d'apprentissage plus raide pour les mises en page complexes et sur mesure. Dès que l'on dépasse les simples combinaisons texte-image — éléments qui se chevauchent, grilles complexes, effets de survol personnalisés, affichage conditionnel —, l'utilisation devient rapidement plus technique. Sans une compréhension de base de l'imbrication des blocs et de la logique de theme.json, les utilisateurs non techniques atteignent vite leurs limites.
Des modèles prêts à l'emploi moins peaufinés. Les compositions et les thèmes par blocs ont beaucoup rattrapé leur retard, mais restent en moyenne moins raffinés que les meilleurs gabarits Elementor. Qui veut une page d'atterrissage à l'air fini en vingt minutes trouvera toujours chez Elementor un choix plus vaste de modèles immédiatement convaincants.
Pas d'éditeur visuel par glisser-déposer au sens classique. Gutenberg fonctionne par blocs, pas par positionnement libre. Qui vient d'outils de design comme Figma ou Canva et s'attend à la sensation exacte du « je place cet élément précisément là » devra changer de logique.
Les constructeurs de pages : les points forts
Un contrôle visuel immédiat. Ce que vous voyez dans l'éditeur est exactement le résultat final — et vous y arrivez en glissant, en cliquant, en essayant. Pour des personnes sans bagage technique, c'est le chemin le plus court entre l'idée et la page terminée. C'est précisément la raison pour laquelle toute la structure de mes cours repose sur Elementor : la barrière à l'entrée est minime.
D'immenses bibliothèques de gabarits abouties. Elementor à lui seul propose des milliers de blocs prêts à l'emploi et des kits complets, dont beaucoup sont sectoriels. Sur des projets réels, cela épargne des journées de travail de conception.
Des écosystèmes matures. Autour d'Elementor gravitent des modules complémentaires pour pratiquement tous les besoins — formulaires, popups, extensions WooCommerce, animations. Bricks Builder se positionne de plus en plus comme une alternative plus rapide et plus favorable aux développeurs, avec une logique visuelle comparable mais un code produit plus léger.
Les constructeurs de pages : les points faibles
Le poids supplémentaire de l'extension. Un constructeur de pages embarque son propre CSS et son propre JavaScript, chargés en plus de ceux du thème. Cela coûte en performance — typiquement davantage de requêtes en base de données et des fichiers frontend plus lourds qu'avec une solution reposant uniquement sur un thème par blocs.
L'enfermement propriétaire. Les contenus créés avec un constructeur de pages sont souvent profondément enfouis dans sa propre structure de données. Passer à un autre constructeur, ou revenir à Gutenberg, signifie en règle générale reconstruire les mises en page de zéro — et pas seulement les exporter.
Des coûts de licence récurrents pour disposer de toutes les fonctions. Les versions Pro des constructeurs sérieux coûtent de l'argent chaque année. Supportable pour un seul petit projet, cela s'accumule vite avec plusieurs sites clients.
La performance en pratique
Sur un site typique d'une trentaine de pages, testé en comparaison directe avec les deux approches, un schéma se dégage, qui n'a guère changé au fil des années :
- Thème par blocs pur avec Gutenberg/FSE : surcoût minimal, puisqu'aucune bibliothèque supplémentaire n'est chargée — le temps de chargement dépend presque exclusivement de l'hébergement, des images et de la qualité du thème.
- Elementor (gratuit ou Pro) : sensiblement plus de fichiers CSS/JS et d'entrées supplémentaires en base de données par page, d'où typiquement 50 à 150 ms de TTFB en plus par rapport à un thème par blocs léger, selon l'hébergement et la configuration du cache.
- Bricks Builder : un code produit plus léger que celui d'Elementor, mais tout de même mesurablement plus lourd qu'une solution Gutenberg/FSE pure.
Sur un bon hébergement infogéré avec cache, ces écarts disparaissent largement dans le bruit de fond. Sur un hébergement mutualisé bon marché, ils deviennent perceptibles. Si vous travaillez de toute façon vos temps de chargement, vous trouverez tous les leviers dans mon article pilier Vitesse WordPress 2026.
Migration et usage mixte : ce qui est réaliste
Passer après coup d'un monde à l'autre est possible, mais rarement anodin :
- Elementor → Gutenberg/FSE : il n'existe aucun convertisseur automatique traduisant proprement les mises en page Elementor en blocs natifs. En pratique, les pages sont largement reconstruites, pas migrées.
- Gutenberg/FSE → Elementor : plus simple, car Elementor peut reprendre les contenus existants comme point de départ puis les enrichir visuellement — mais là encore, des retouches de mise en page sont la règle.
- Fonctionnement mixte (certaines pages sous Gutenberg, d'autres sous Elementor) : cela fonctionne techniquement, mais augmente la charge de maintenance et le temps de formation des nouveaux rédacteurs. Pour de petites équipes, ce n'est généralement pas une bonne solution à long terme.
Règle empirique tirée de ma pratique de conseil : prenez la décision de principe le plus tôt possible dans le projet. Un changement ultérieur est faisable, mais planifiez-le comme un petit projet à part entière, avec sauvegarde, préproduction et une marge de temps suffisante — pas comme une tâche annexe.
Vous ne savez pas encore quelle approche convient à votre projet ? Dans mon cours en ligne, je vous montre les deux voies en pratique — et comment décider en fonction de votre type de projet et de vos connaissances techniques, plutôt que de vous laisser déstabiliser par des articles de tendance. → Voir le cours en ligne
À qui convient quoi ?
La développeuse avec son propre thème par blocs. Qui écrit du code de toute façon, développe des blocs sur mesure ou entretient lui-même un thème par blocs léger est parfaitement servi par Gutenberg et le FSE. Aucune extension supplémentaire, contrôle total du code, performance native.
Le blogueur de contenu sans exigences de mise en page complexes. Qui écrit avant tout des articles, se contente d'images, de citations et de titres, et a rarement besoin de pages d'atterrissage élaborées, profite de Gutenberg : rapide, léger, gratuit, sans courbe d'apprentissage pour les tâches quotidiennes.
L'indépendante avec des ambitions marketing. Qui veut exploiter un site au design personnalisé, avec plusieurs pages d'atterrissage, des sections d'appel à l'action visuelles et sans appui d'un développeur est nettement mieux servi par Elementor ou Bricks Builder. C'est le cas de figure ordinaire chez la plupart de mes clients et stagiaires — et la raison pour laquelle je ne feins ici aucune fausse neutralité.
Ma conclusion
Je le dis sans détour : en 2026, Gutenberg et le FSE ne sont plus un jouet — c'est le choix par défaut pertinent pour les développeurs et pour les sites légers, fondés sur un thème et centrés sur le contenu. Mais pour la grande majorité de mes clients et de mes stagiaires — des indépendants non techniques et des entreprises avec des pages marketing complexes, qui ont besoin de souplesse visuelle sans travail de développement —, un constructeur de pages comme Elementor ou Bricks Builder reste en 2026 le meilleur choix. C'est précisément pour cela que mon travail de formation continue de s'appuyer avant tout sur Elementor : cela correspond mieux au besoin réel de mon public que la solution native, plus « pure » mais plus exigeante.
Si vous hésitez sur la voie qui convient à votre projet concret, je vous accompagne dans mon cours en ligne à travers les deux approches — avec une recommandation adaptée à vos connaissances techniques et à votre projet réel, et non à une tendance générale. → Voir le cours en ligne
Questions fréquentes
Gutenberg rendra-t-il un jour Elementor superflu ?
Pas dans un avenir prévisible. Gutenberg rattrape fortement son retard technique, mais la force d'Elementor ne tient pas seulement à l'étendue de ses fonctions : elle tient à son accessibilité pour les utilisateurs non techniques et à son immense écosystème de gabarits abouti. Tant que ce public existe — et il est vaste —, il restera de la place pour les constructeurs de pages. Une coexistence durable avec des domaines d'emploi distincts est plus réaliste qu'un remplacement.
Puis-je utiliser ensemble des blocs Gutenberg et Elementor sur la même page ?
En partie oui, techniquement — Elementor peut intégrer certains blocs Gutenberg. Mais les configurations mixtes demandent beaucoup d'entretien et sont rarement une bonne idée pour tout un site. Choisissez une approche principale par projet.
Un passage ultérieur d'Elementor à Gutenberg/FSE est-il possible ?
Possible, mais coûteux. Les contenus Elementor résident dans la structure de données propre à Elementor, pas dans des blocs Gutenberg natifs. En pratique, changer signifie reconstruire largement les pages, pas les convertir. Cette décision devrait donc être prise le plus tôt possible dans le projet.
Faut-il un thème particulier pour le Full Site Editing ?
Oui — le FSE ne fonctionne qu'avec ce qu'on appelle les thèmes par blocs, qui embarquent un fichier theme.json (par exemple Twenty Twenty-Four ou Twenty Twenty-Five, ou de nombreux thèmes tiers modernes). Les thèmes PHP classiques dépourvus de cette structure ne prennent pas en charge le Full Site Editing.
Bricks Builder est-il une véritable alternative à Elementor ?
Pour des utilisateurs un peu plus aguerris techniquement, tout à fait. Bricks mise davantage sur un code produit propre et léger et sur une structure plus favorable aux développeurs, avec une logique d'utilisation visuelle proche de celle d'Elementor. Vous trouverez un comparatif détaillé dans mon article Bricks Builder contre Elementor contre Breakdance.
Et si j'ai déjà un site sous Elementor et que je doute maintenant ?
Restez-y si vous en êtes satisfait. Changer sans motif concret — problèmes de performance, coûts de licence, réorientation technique — coûte du temps sans bénéfice clair. Un article de tendance n'est pas une raison de refaire une configuration qui fonctionne.
Pour d'autres repères sur les constructeurs de pages et les thèmes, voyez ma vue d'ensemble Comparatifs d'outils WordPress 2026 ainsi que mon article Elementor – le meilleur constructeur de pages pour WordPress ?
Source des images (à la une et dans l'article) : illustrations réalisées par mes soins dans le design pletzenauer (aucune photo de banque d'images).
Elementor Pro : si vous optez pour un constructeur de pages et que votre choix se porte sur Elementor : le Theme Builder et les formulaires relèvent de la version Pro. Découvrir Elementor Pro
Tags