WordPress est sécurisé. Ce qui le fragilise, c'est ce qu'on y ajoute.
WordPress alimente 43 % des sites web mondiaux. Cette omniprésence en fait une cible privilégiée pour les attaques automatisées. Mais le cœur du CMS, audité en permanence par une communauté de plusieurs milliers de développeurs, est rarement la source des failles.
Selon Sucuri, spécialiste de la sécurité WordPress, 97 % des infections proviennent de plugins ou de thèmes vulnérables, pas du cœur de WordPress. Un plugin abandonné par son auteur continue de fonctionner jusqu'au jour où une faille est découverte et n'est jamais corrigée. Un thème téléchargé depuis une source non officielle peut embarquer du code malveillant dès l'installation.
La règle est simple : chaque plugin installé est une dépendance à maintenir, une surface d'attaque supplémentaire et un risque de conflit avec les futures versions de WordPress. Un site avec cinq plugins bien choisis est plus sûr qu'un site avec vingt plugins « pratiques ».
Ce qu'un page builder coûte vraiment
Un page builder (Elementor, Divi, WPBakery) ajoute entre 300 Ko et 1,5 Mo de JavaScript et CSS sur chaque page, que le contenu en ait besoin ou non. Ces fichiers sont chargés avant que la page ne s'affiche : chaque kilooctet supplémentaire rallonge le temps de rendu.
Elementor dans sa configuration par défaut génère entre 40 et 80 requêtes HTTP sur une page simple. Un thème FSE minimal avec le même contenu en génère 6 à 12. Chaque requête est un aller-retour entre le navigateur du visiteur et le serveur : plus il y en a, plus la page prend du temps à s'afficher, surtout sur mobile avec une connexion dégradée.
Le problème n'est pas que ces outils existent. C'est qu'ils sont utilisés pour des sites qui n'ont pas besoin de leur complexité, et que leur empreinte technique reste longtemps après que le site a été livré.
FSE : construire avec les outils natifs de WordPress
Full Site Editing est la réponse de WordPress à ce problème. Introduit en version 5.9 (janvier 2022), FSE permet de concevoir l'intégralité d'un site (header, footer, templates, pages) dans l'éditeur natif de blocs, sans plugin supplémentaire.
Ce que ça change concrètement : le style global du site est défini dans un
fichier theme.json.
Les templates sont des fichiers HTML composés de blocs Gutenberg. Les
patterns sont des compositions de blocs réutilisables. Tout cela est
éditable visuellement dans le Site Editor de WordPress, sans toucher au
code.
Pour l'utilisateur final, c'est une interface unifiée. Pour le développeur, c'est une base standardisée, documentée, maintenue par l'équipe WordPress core. Pour les deux : moins de dépendances, moins de risques de régression lors des mises à jour.
Thème classique vs thème bloc : la différence en pratique
Un thème classique WordPress repose sur des fichiers PHP qui mélangent
logique et présentation. Modifier le header signifie éditer header.php.
Changer la mise en page d'un article demande de comprendre la hiérarchie
des templates PHP. Ajouter une zone de widgets implique de déclarer des register_sidebar()
dans functions.php.
Un thème bloc remplace tout cela par l'éditeur visuel. Le header est un
template part HTML éditable dans le Site Editor. La mise en page d'un
article est un template single.html
composé de blocs. Les zones de contenu dynamique sont gérées par des blocs
natifs ( wp:post-title, wp:post-content, wp:query).
Le résultat : un client peut modifier sa navigation, réorganiser ses templates ou créer une nouvelle mise en page sans intervention du développeur. C'est ce que « simple à administrer » veut dire concrètement.
Ce que FSE ne fait pas encore
FSE est mature pour la majorité des sites vitrines et des sites de contenu. Quelques cas d'usage restent plus complexes : les sites e-commerce avec WooCommerce ont un support FSE partiel, les formulaires avancés nécessitent encore un plugin, les sites multilingues avec WPML ou Polylang ont des contraintes spécifiques.
Pour un site institutionnel, un site d'artisan, un portfolio ou un site associatif, FSE couvre 95 % des besoins sans compromis. La question n'est pas « est-ce que FSE peut le faire ? » mais « est-ce que ce site a vraiment besoin de ce que FSE ne fait pas encore ? »
Ce qu'on retient
WordPress est sécurisé par défaut. Ce qui fragilise un site, c'est l'accumulation de plugins non maintenus et de thèmes surchargés. FSE offre une alternative native : moins de dépendances, une interface unifiée, un code standardisé. Pour la majorité des projets, c'est la meilleure base de départ.