Si vous avez l’habitude de travailler avec des Page builders (ou constructeurs de pages), il se peut que vous hésitiez à passer à l’Éditeur de site natif de WordPress. On a cette idée préconçue qu’on va avoir du mal à y passer. En fait, ce qui est difficile, c’est de quitter une habitude, de quitter sa routine dans laquelle on est bien installé, on a peur de sortir de sa zone de confort.
Le FSE (ou Full Site Editing) c’est l’évolution naturelle du projet Gutenberg : d’ailleurs, « FSE » n’est plus le terme mis en avant, on parle officiellement de Site Editor depuis 2022.
Cet article ne se veut pas exhaustif. Mais il pourra peut-être donner un coup de pouce aux personnes qui hésitent à se lancer.
Qu’est ce que le projet Gutenberg ?
Gutenberg est le projet pluri-annuel qui a transformé WordPress autour des blocs. L’idée n’était pas seulement de moderniser l’éditeur d’articles d’origine, le fameux TinyMCE, mais de faire des blocs le langage commun de tout l’écosystème, du contenu à la mise en page des sites. Le projet a démarré publiquement en 2017, en tant qu’extension, puis le nouvel éditeur par blocs a été fusionné dans WordPress 5.0 (le 6 décembre 2018), marquant la bascule pour des centaines de milliers de sites.
Gutenberg avance par phases. La phase 1 a livré l’éditeur de blocs pour les contenus (ce qu’on utilise dans les articles et pages). La phase 2 a étendu cette logique à tout le site, avec l’Éditeur du site et les thèmes de blocs : ainsi on peut créer les en-têtes, pieds de page, modèles, styles globaux, le tout piloté depuis l’interface et un fichier theme.json. Les phases suivantes devraient apporter la collaboration et la co-édition, et aussi le le multilingue natif.
FSE ou Éditeur de site, qu’est-ce que c’est ?
Ainsi l’Éditeur de site permet de composer tout le site en blocs : en-têtes, pieds de pages, modèles d’articles et de pages, archives, page de recherche, page 404.
On part sur un thème WordPress qui repose sur des blocs et dont le design est défini dans le theme.json. Effectivement, on y définit des palettes de couleurs, les typos utilisées, les styles par défaut. On peut concevoir des modèles et des parties de modèle, on peut créer des blocs ou modèles réutilisables (reusable blocks), très utiles quand on veut reproduire une partie du site qu’on est en train de faire.
La version 6.8 de WordPress (sortie en avril 2025) a affiné l’expérience : le guide de style est plus clair, plus structuré, on accède directement au panneau styles, l’éditeur est amélioré et les vues de données sont facilement visualisables, la création de contenu est simplifiée, la performance est largement améliorée et plus de 100 correctifs ont amélioré l’accessibilité.
Pourquoi franchir le pas ?
Voici quelques arguments qui vous convaincront peut-être.
On garde le contrôle sur son design grâce au theme.json. Il permet de centraliser la charte, mais rien n’empêche d’écrire du CSS d’appoint quand c’est nécessaire, votre CSS ne va pas rentrer en conflit avec un builder propriétaire.
Un autre argument, non négligeable, concerne la performance. WordPress 6.8 introduit le chargement spéculatif (speculative loading) pour une expérience plus fluide lorsque l’internaute s’apprête à cliquer. On part donc avec un socle rapide par défaut, mais rien ne nous empêche d’encore l’optimiser avec nos propres bonnes pratiques.
On peut définir une charte graphique globale uniforme, la création est encadrée, configurée par défaut et l’évolution du site est simplifiée. On parle de gouvernance qui permet de garder la main sur l’interface et de maintenabilité qui permet de simplifier les évolutions.
Quant aux motifs synchronisés, ceux-ci permettent d’effectuer un changement qui s’applique partout en un seul enregistrement.
En combinant ces trois aspects, c’est-à-dire une charte explicite dans theme.json, des modèles verrouillés pour l’ossature, et des motifs synchronisés pour les éléments transverses, vous obtenez un site gouverné par des règles claires et facile à faire évoluer. Les demandes qui, hier, réclamaient des retouches dispersées deviennent des changements uniques, traçables et réversibles, appliqués au bon endroit.
Quelques exemples concrets
Par exemple, si vous voulez refaire l’en-tête d’un site. Vous pouvez utiliser le bloc Navigation, le logo du site, la recherche et deux menus contextuels. Vous pouvez ensuite verrouiller le bloc pour empêcher toute modification, suppression ou modification de mise en page de manière accidentelle.
En verrouillant les blocs, vous permettez ainsi de maintenir la structure globale du site. Vous laissez à l’équipe éditoriale la liberté sur le contenu, mais pas sur la structure.
Le theme.json permet de gérer et de respecter par défaut la charte générale du site web.
Mon avis de développeuse front (qui n’engage que moi).
C’est vrai, j’étais sceptique jusqu’à aujourd’hui. Ce qui me freinait, c’était l’impression d’un chantier permanent : des options qui bougent, des API qui évoluent, cela me semblait difficile à suivre en plus de mes projets clients. Ce qui m’a convaincue, c’est que l’Éditeur du site est désormais mature. Le cœur du système reposant sur theme.json permet de créer un guide des styles lisible, le bloc Navigation qui remplace proprement les vieux menus, le verrouillage des blocs pour encadrer la structure, et les motifs synchronisés qui transforment une mise à jour globale en un geste unique. Surtout, d’après ce que j’ai compris, je peux versionner mes modèles, mes motifs et ma charte, garder un CSS d’appoint minimal, et laisser l’éditeur appliquer la cohérence à ma place. Autrement dit, je fixe mes règles dans le thème. Enfin, en termes de performance, j’ai constaté, sur les quelques sites que j’ai réalisés avec une base en FSE, qu’il il n’y a pas photo.
Je tiens aussi à dire, que l’utilisation des constructeurs de pages, m’a facilité la compréhension et la prise en main du FSE.
La technique évolue et c’est peut-être le bon moment pour proposer à vos clients, une refonte de leurs sites. Et pour vous lancer, n’oubliez pas que vous trouverez sur le web pléthore de tutoriels et de formations.
