La question revient à chaque nouveau projet d’agence : éditeur de site natif ou Elementor ? Trois ans après l’arrivée officielle du Full Site Editing dans WordPress 5.9, et alors qu’Elementor prépare la bascule vers son éditeur V4 basé sur des « atomic elements », la comparaison mérite d’être reposée avec des critères concrets plutôt qu’avec des arguments de principe.
Les deux outils ont énormément évolué depuis leurs débuts respectifs. L’éditeur de site s’est stabilisé, a gagné en performance et en outillage (Font Library, Zoom Out, patterns synchronisés). Elementor, de son côté, reste l’un des plugins les plus installés de l’écosystème WordPress et vient d’entamer une refonte en profondeur de son moteur de rendu. Voici un état des lieux honnête, critère par critère.
Performance : le poids réel des pages
C’est historiquement le point faible d’Elementor, et il reste réel même si la situation s’est nettement améliorée avec les versions récentes. Une page construite avec Elementor charge généralement plusieurs feuilles de style (le CSS du plugin lui‑même, le CSS généré par page, le CSS des widgets tiers), plus un ou plusieurs fichiers JavaScript nécessaires au rendu de certaines interactions, même quand ces interactions ne sont pas utilisées sur la page en question.
L’éditeur de site natif, lui, s’appuie sur theme.json pour générer un CSS minimal, propre à chaque page, sans dépendance à un moteur de rendu tiers. Les blocs natifs ne chargent leur JavaScript que lorsque le bloc l’exige réellement (un carrousel, une recherche instantanée), grâce au chargement conditionnel des scripts par WordPress.
Courbe d’apprentissage
Sur ce terrain, Elementor garde un net avantage pour un utilisateur qui découvre la construction de page. Son interface de type « ce que vous voyez est ce que vous obtenez », avec panneau de réglages à gauche et prévisualisation à droite, reste plus intuitive au premier contact que l’éditeur de site, où la distinction entre page, template, pattern et style global demande un temps d’adaptation réel.
À l’usage cependant, cette même distinction (page / template / pattern) devient un atout pour un client formé correctement : elle structure la réflexion et évite les pages « bricolées » où tout est mélangé. C’est une courbe d’apprentissage plus raide au départ, mais qui paie sur la durée pour un client qui maintient son site sur plusieurs années.
Portabilité du contenu
C’est sans doute le critère le plus sous-estimé, et celui où l’écart se creuse le plus nettement en faveur de l’éditeur natif. Le contenu créé avec les blocs WordPress reste stocké sous forme de HTML commenté, standard, lisible même sans le plugin ou le thème d’origine. Désactiver Elementor, en revanche, transforme généralement le contenu existant en un magma de shortcodes ou de balises illisibles, rendant toute migration extrêmement coûteuse.
Pour une agence qui reprend la maintenance d’un site existant, ou qui doit migrer un client vers un nouvel hébergeur ou un nouveau thème, cette différence pèse lourd dans la durée. Le contenu FSE survit à un changement de thème ; le contenu Elementor est, dans les faits, prisonnier du plugin.
Écosystème de patterns et de templates
Sur ce point, Elementor conserve une avance confortable. Sa marketplace de kits et de templates prêts à l’emploi reste bien plus fournie que ce que propose l’écosystème des thèmes-blocs, même si des répertoires de patterns communautaires se sont développés autour de WordPress. Pour un client pressé qui veut un site fonctionnel en quelques heures à partir d’un template existant, Elementor reste souvent plus rapide à mettre en œuvre.
L’éditeur natif progresse cependant vite sur ce terrain, porté par des thèmes-blocs de plus en plus complets et par des bibliothèques de patterns tierces. La bascule vers l’éditeur V4 d’Elementor, annoncée en 2025 et basée sur des « atomic elements » censés générer un CSS plus léger, montre d’ailleurs qu’Elementor cherche lui aussi à corriger son point faible historique sur la performance.
Tableau comparatif
| Critère | Éditeur de site natif (FSE) | Elementor |
|---|---|---|
| Poids CSS généré | Minimal, propre à chaque page via theme.json | Plus lourd en configuration classique ; allégé annoncé avec l’éditeur V4 |
| Courbe d’apprentissage | Plus raide au départ, structurante ensuite | Prise en main immédiate |
| Portabilité du contenu | HTML standard, survit à un changement de thème | Dépendant du plugin, migration coûteuse |
| Écosystème de templates | En croissance, encore inégal | Marketplace très fournie |
| Coût | Inclus dans WordPress core | Version gratuite limitée, Pro payante |
| Dépendance technique | Aucune, fonctionnalité du cœur WordPress | Plugin tiers à maintenir et mettre à jour |
Dans quels cas choisir l’un ou l’autre
Sur nos projets d’agence, le choix ne se fait plus de manière dogmatique mais selon le contexte réel du client :
- Site institutionnel destiné à vivre plusieurs années, avec un client formé à l’éditeur : éditeur de site natif, pour la pérennité et la performance.
- Site nécessitant une mise en ligne très rapide à partir d’un template existant, avec un client autonome dès le lendemain : Elementor reste pertinent.
- Projet avec des besoins d’interactions complexes non couvertes par les blocs natifs (formulaires avancés, animations poussées) : Elementor Pro ou un plugin de blocs complémentaire.
- Projet où la performance est un critère commercial explicite (e‑commerce, SEO local compétitif) : éditeur natif en priorité.
Le critère qui devrait primer sur tous les autres, à notre sens, c’est la durée de vie prévue du site. Plus un site est fait pour durer, plus la portabilité du contenu FSE devient déterminante face au confort immédiat d’Elementor.
Notre verdict
L’écart de performance entre les deux solutions s’est réduit ces dernières années, et il devrait continuer à se resserrer avec l’arrivée de l’éditeur V4 d’Elementor. Mais deux critères restent structurellement en faveur de l’éditeur de site natif : l’absence de dépendance à un plugin tiers, et la portabilité réelle du contenu produit. À l’inverse, Elementor garde une vraie avance sur la rapidité de prise en main et la richesse de son catalogue de templates. Le choix n’est donc pas définitivement tranché, mais il ne se fait plus par défaut en faveur du page builder, comme c’était encore largement le cas il y a quelques années.
