La promesse est partout : "Créez votre site sans coder, glissez-déposez vos blocs, modifiez tout en temps réel." Elle se tient, dans les mains du prestataire qui connaît l'outil. Elle se tient le temps de la démonstration. Elle s'effondre le jour où le client ouvre Elementor seul pour la première fois.
Ce n'est pas une question de niveau technique. C'est une question d'architecture cachée.
L'interface qui semble simple
Elementor s'ouvre sur une interface en deux parties : la prévisualisation de la page à droite, le panneau de contrôle à gauche. En apparence, c'est intuitif. En pratique, chaque clic sur un élément de la page charge un panneau différent, avec des options différentes, organisées différemment. Un titre a ses options. La colonne qui le contient en a d'autres. La section qui contient la colonne en a encore d'autres. Trois niveaux d'imbrication pour modifier la couleur d'arrière-plan au bon endroit.
Les clients qui arrivent après un site Elementor décrivent tous la même chose : ils cliquent sur ce qui semble être le bon endroit, tombent sur des options qui ne correspondent pas à ce qu'ils cherchent, cliquent ailleurs, perdent le fil. L'interface réagit, mais pas de la façon attendue. Modifier une couleur prend vingt minutes non pas parce que c'est compliqué, mais parce que personne n'a expliqué que cette couleur est peut-être définie au niveau du widget, ou au niveau du style global du thème, ou dans le kit de site Elementor, ou dans le thème WordPress lui-même. Quatre endroits possibles pour une seule valeur.
La logique en couches que personne n'explique
Elementor superpose plusieurs couches de styles : le thème WordPress de base, les styles globaux Elementor, les styles du kit de site, les styles au niveau de la section, de la colonne, du widget. Chaque couche peut écraser la précédente. Un changement fait au bon niveau se répercute partout. Un changement fait au mauvais niveau ne s'applique qu'à un seul élément et crée une incohérence visuelle que le client ne sait pas comment corriger.
Cette logique en couches existe dans tous les outils web. Dans FSE, elle est documentée, nommée, et correspond directement à la cascade CSS que WordPress gère nativement. Dans Elementor, elle est partiellement masquée par une interface qui donne l'impression que tout se passe au même niveau. Le client non-technique n'a pas les repères pour comprendre pourquoi modifier la couleur d'un bouton à un endroit ne modifie pas celle du bouton identique sur une autre page.
Les mises à jour : la fragilité structurelle
Elementor sort des mises à jour fréquentes. WordPress aussi. Les plugins tiers également. Ces trois cycles de mise à jour sont indépendants et ne sont pas toujours synchronisés.
Le scénario qui revient : une mise à jour Elementor modifie le rendu d'un composant. Une mise à jour WordPress introduit un changement de comportement qu'Elementor n'a pas anticipé. Un plugin tiers, formulaire ou slider, cesse de fonctionner correctement avec la nouvelle version d'Elementor. La mise en page qui fonctionnait parfaitement la veille affiche un décalage, un bloc qui déborde, un espacement qui a disparu.
Corriger ces régressions demande de comprendre quelle couche a changé et laquelle compense mal. Sans cette compréhension, la tentation est de corriger localement : ajouter du CSS personnalisé, modifier un widget en particulier, contourner plutôt que résoudre. Le site accumule des corrections qui créent de nouvelles fragilités.
FSE n'est pas immunisé contre les mises à jour. Mais les composants en jeu sont moins nombreux et mieux intégrés : WordPress core, le thème bloc, les blocs natifs. Pas de couche propriétaire entre l'éditeur et le rendu final.
La courbe d'apprentissage qu'on ne montre pas
Elementor est présenté comme l'alternative accessible à l'apprentissage du développement WordPress. Cette présentation est honnête sur un point : Elementor ne demande pas d'écrire du code. Elle est malhonnête sur un autre : Elementor demande d'apprendre Elementor. Ses conventions, sa logique de sections et de colonnes, ses kits, ses variables globales, ses widgets propriétaires. C'est un apprentissage réel, qui ne transfère pas vers d'autres outils.
Quelqu'un qui apprend FSE apprend WordPress. Les templates, les
patterns, le theme.json, les blocs natifs : tout
ça fait partie du cœur de WordPress, documenté par l'équipe core,
stable entre les versions. Ce qu'on apprend aujourd'hui est valable
dans trois ans.
Quelqu'un qui apprend Elementor apprend Elementor. Si le plugin change d'interface, augmente ses tarifs ou cesse d'être maintenu, cet apprentissage ne se transfère nulle part.
Ce qu'on retient
La facilité d'usage d'Elementor et Divi est réelle dans un contexte précis : entre les mains d'un prestataire qui connaît l'outil et construit le site. Elle disparaît dès que le client prend la main seul, dès qu'une mise à jour introduit une régression, dès qu'il faut comprendre pourquoi une modification ne se répercute pas où on l'attendait.
FSE demande un apprentissage initial plus explicite. Mais cet apprentissage est linéaire, documenté, et transfère directement vers WordPress. Le client qui comprend comment modifier un template FSE comprend comment WordPress fonctionne. C'est un investissement qui dure.