J’ai commencé avec des constructeurs de page. Comme beaucoup. Divi d’abord, puis d’autres. L’argument était convaincant : concevoir visuellement, sans toucher au code, avec des centaines de templates prêts à l’emploi. Ça fonctionnait.
J’ai arrêté. Pas parce que ça ne fonctionnait plus, mais parce que j’ai compris ce que ça coûtait vraiment.
La promesse
Elementor, Divi, Beaver Builder et leurs équivalents promettent tous la même chose : prendre le contrôle de votre site sans développeur, avec une interface visuelle qui ressemble à ce que vous voyez à l’écran.
Cette promesse est tenue. Vous pouvez modifier la couleur d’un bouton, déplacer une section, choisir parmi des dizaines de mises en page prédéfinies. Pour quelqu’un qui ne code pas, c’est un gain d’autonomie réel.
Le problème n’est pas ce qu’ils font. C’est comment ils le font, et pour qui ils ont été conçus.
500 options pour un besoin simple
Un site vitrine de cinq pages a des besoins précis. Une page d’accueil qui dit ce que vous faites et à qui. Une page de services. Une page de présentation. Une page de contact. Parfois un blog.
Elementor propose plus de 80 widgets. Divi offre des centaines de modules, des dizaines de mises en page globales, des options de design au niveau de la section, de la colonne, et de l’élément. Beaver Builder empile des shortcodes dans le contenu de vos pages, visibles uniquement dans l’éditeur.
Tout ce choix n’est pas un avantage pour un site vitrine. C’est du bruit. Chaque option supplémentaire est une décision à prendre, une chose à comprendre, un réglage à maintenir. Pour quelqu’un qui veut juste mettre à jour son texte ou ajouter une photo, l’interface devient un obstacle.
J’ai vu des clients passer vingt minutes à retrouver où modifier un titre parce que l’option était enfouie dans trois niveaux de panneaux imbriqués. Ce n’est pas de l’autonomie. C’est de la complexité déguisée en liberté.
Il y a un angle que les constructeurs de page n’abordent jamais dans leur communication : avoir accès à des centaines de templates ne remplace pas la connaissance de la conception. Agencer les sections d’une page, hiérarchiser l’information, calibrer les espacements pour que la lecture soit fluide, choisir ce qu’on montre en premier et ce qu’on relègue en bas de page : ce sont des décisions de conception, pas des réglages techniques. Un constructeur de page donne les curseurs. Il ne dit pas dans quel sens les tourner.
Résultat : des sites où tout est possible et rien n’est vraiment décidé. Des mises en page surchargées parce que supprimer un élément demande autant d’effort qu’en ajouter un. Des pages qui ressemblent à un catalogue de fonctionnalités plutôt qu’à un outil au service d’un visiteur.
La dette technique qui s’accumule
Les constructeurs de page génèrent du code. Beaucoup de code. Pour afficher un texte centré sur fond coloré, Elementor ou Divi écrivent des dizaines de lignes CSS avec des classes propriétaires, des attributs de données, des styles inline. Ce code appartient au constructeur, pas à vous.
Tant que vous utilisez le même constructeur, ça fonctionne. Le jour où vous voulez changer de thème, migrer vers FSE, ou simplement faire intervenir un autre développeur : le contenu est prisonnier du format propriétaire. Changer devient une réécriture complète.
Les mises à jour ajoutent une autre couche. Un constructeur de page qui se met à jour peut casser une mise en page qui fonctionnait. Pas souvent, mais ça arrive. Et quand ça arrive sur un site avec cinquante pages conçues avec le constructeur, la correction prend du temps.
Ce n’est pas de la théorie. C’est ce que je vois sur les sites que des clients m’apportent en refonte.
Ce que WordPress FSE change
Le Full Site Editing est la réponse native de WordPress à ce problème. Pas un plugin supplémentaire : une architecture intégrée dans WordPress depuis 2022.
Avec un thème FSE, la mise en forme est définie dans le theme.json. Les couleurs, la typographie, les espacements : tout est centralisé dans un fichier structuré. Quand vous modifiez une couleur, elle change partout sur le site, cohéremment. Vous n’avez pas à retrouver les vingt endroits où cette couleur a été appliquée manuellement.
L’éditeur de blocs Gutenberg est plus sobre qu’un constructeur de page. Moins d’options, moins de widgets, moins de réglages. Pour concevoir un site vitrine, c’est suffisant. Pour le client qui gère son contenu au quotidien, c’est plus facile à prendre en main précisément parce que le périmètre est restreint.
Et le contenu reste dans WordPress. Pas dans un format propriétaire. Pas dans des shortcodes illisibles. Dans des blocs standards que n’importe quel développeur WordPress peut lire et modifier.
Quand un constructeur de page reste justifié
Il y a des cas où FSE n’est pas la bonne réponse. Un site e-commerce complexe avec des besoins spécifiques d’affichage. Un projet où le client a déjà une maîtrise poussée d’un constructeur particulier et ne veut pas repartir de zéro. Une contrainte de délai où le catalogue de templates d’un constructeur fait gagner du temps sur un périmètre très large.
Je ne dis pas que les constructeurs de page sont mauvais dans l’absolu. Je dis qu’ils sont surdimensionnés pour la plupart des sites vitrine. Et que surdimensionné, dans mon travail, n’est pas un compliment.
Un site sobre utilise ce dont il a besoin. Rien de plus.
Si votre site actuel repose sur un constructeur de page et que la maintenance vous prend plus de temps qu’elle ne devrait, contactez-moi : un audit permet souvent d’identifier rapidement ce qui peut être simplifié.