Playbook
Full Site Editing

Full Site Editing : une méthode de conception modulaire dans WordPress

Soyons clairs dès le départ : le Full Site Editing n’est qu’un outil.

Ce qui compte, c’est ta méthode.

Et si tu prends le temps de creuser, tu verras que le FSE n’est pas une révolution technique. C’est une révélation méthodologique.

Avec le FSE, WordPress te pousse à penser ton site comme un écosystème modulaire, cohérent, structuré.

Et franchement… tant mieux.

Avant, l’édition de contenu dans WordPress c’était un peu le far west :

TinyMCE, des shortcodes qui pètent au moindre copier-coller, des meta box dans tous les sens, et du PHP spaghetti pour assembler tout ça. Chaque thème était un mini framework perso — rarement documenté, jamais réutilisable. On bricolait. On improvisait.

Je vais pas refaire ici l’histoire de la phase 1 de Gutenberg, ni te redire comment les blocs sont venus soigner une bonne partie du problème.

Ce qui m’intéresse aujourd’hui, c’est la suite.

C’est comment le Full Site Editing te force à structurer ta manière de concevoir des sites WordPress. Et surtout, comment tu peux t’appuyer là-dessus pour faire du propre, du pérenne, et du scalable.

Alors on va prendre les choses dans l’ordre. On va partir du plus générique — le langage visuel — jusqu’à la partie visible de l'iceberg — les modèles de page. Et je vais te montrer comment tout ça s’imbrique.

De Gutenberg à la méthode : comment WordPress nous a poussé à évoluer

Commencer par la base : ton langage visuel

Avant de toucher au moindre bloc, tu peux te poser une question simple :

"C’est quoi le système visuel derrière mon site ?"

Couleurs, espacements, tailles de texte, rayons de bordure, tout ça doit être normalisé, centralisé et pensé comme un langage partagé.

C’est là que les design tokens entrent en scène

Un token, c’est une valeur nommée. Plutôt que de dire #1E40AF, tu dis color.primary. Et tu peux l’utiliser partout : dans tes blocs, dans tes styles, dans tes composants.

Mais les tokens, aussi, se structure.

Couche 1 : Tokens de fondation

Les valeurs brutes. Les couleurs, tailles, typos, espacements. Genre : color.blue.500, spacing.4, font.size.md

Couche 2 : Tokens sémantiques

Tu leur donnes un sens dans ton design. Exemple : color.background.primary, color.text.error

Couche 3 : Tokens de composant

Tu les rattaches à un usage précis dans l’interface. Genre : button.background, card.padding, input.label.color

C’est ce découpage qui te permet d’évoluer sans foutre le feu à tout ton code.

Le theme.json comme base déclarative

Tout ce système visuel, tu vas pouvoir l’implémenter directement dans WordPress via le theme.json. C’est ton fichier maître.

Tu y déclares :

  • les couleurs disponibles
  • les typos
  • les espacements
  • les largeurs de contenu
  • les styles par défaut des blocs
  • les variations
  • les presets exposés dans l’éditeur

Et WordPress se charge de générer les CSS Custom Properties (--wp--preset--...), d’afficher l’UI dans Gutenberg, et de t’éviter 80% de surcharges CSS.

Un design system déclaratif, réutilisable, documenté nativement.

Les block supports : pour ouvrir les bons réglages

Tu veux exposer certains réglages à l’utilisateur ? Les block supports sont là pour ça.

Tu peux activer :

  • le contrôle des couleurs
  • la typo
  • le layout
  • les marges/paddings
  • les bordures
  • les ombres

Et surtout : tout est lié à ton design system.

L’éditeur propose uniquement les options que tu as prévues. Tu gardes la main, l’utilisateur ne peut pas casser la charte.

Et ça, c’est exactement le genre de garde-fous qu’on devrait tous mettre en place.

Styliser les blocs natifs avant tout

Avant de partir bille en tête sur des blocs custom, commence par maîtriser les blocs natifs.

Pourquoi ? Parce qu’ils sont puissants, bien intégrés à l’écosystème WordPress, bien maintenus… et surtout largement suffisants dans 80% des cas.

Tu peux déjà :

  • définir leur style par défaut dans le theme.json
  • restreindre les options exposées à l’utilisateur
  • personnaliser leur rendu avec les presets CSS générés automatiquement
  • gérer les marges, la typo, les couleurs via les block supports

Bref, y’a de quoi faire avant d’écrire la moindre ligne de PHP ou de JS.

Tu veux un bloc Hero ? Un Group + une Image + un Heading + un Button bien stylisés, et t’es déjà à plus de 90% du besoin.

Étendre les styles graphiques avec register_block_style

Une fois que tes blocs natifs sont bien stylés, tu peux aller plus loin dans l’expérience éditoriale sans toucher au fonctionnel.

C’est là que les block styles entrent en jeu.

Avec register_block_style, tu ajoutes des variations visuelles à un bloc existant. Tu gardes 100% de la logique native, mais tu proposes plusieurs rendus graphiques.

Exemple :

register_block_style('core/image', [
  'name'  => 'rounded-shadow',
  'label' => 'Image arrondie avec ombre'
]);

C’est super utile pour :

  • différencier un bloc dans un contexte donné
  • guider les éditeurs vers un style adapté
  • éviter de tout redévelopper pour une simple variation visuelle

Et surtout, tu restes dans les rails du système.

Étendre le fonctionnel d’un bloc sans le recréer

Bon, t’as bien bossé le style, tu veux aller plus loin côté fonctionnel ? Tu peux encore éviter de recréer un bloc de zéro.

Deux options super puissantes s’offrent à toi :

A. Les block variations

Une variation, c’est une version préconfigurée d’un bloc existant. Tu changes sa structure, ses attributs par défaut, son label… mais tu gardes le cœur du bloc.

Exemple :

registerBlockVariation('core/quote', {
  name: 'highlighted',
  title: 'Citation mise en avant',
  attributes: {
    className: 'is-style-highlighted'
  },
  isDefault: false
});

Tu peux en faire pour les paragraphes, les groupes, les boutons, les listes…

B. Les block bindings

Les bindings permettent d’injecter du contenu dynamique dans un bloc :

  • champs ACF
  • métadonnées de post
  • valeurs custom depuis un contexte

C’est parfait pour transformer un bloc “statique” en bloc intelligent. Et ça fonctionne même avec les blocs natifs.

Résultat : tu crées une interface hyper flexible sans dupliquer de code, et sans t’inventer un bloc perso qui fera doublon dans l’éditeur.

Composer avec les block patterns

Maintenant que t’as des blocs stylisés et potentiellement enrichis de variations ou de bindings, tu peux commencer à composer.

Les block patterns, c’est un peu le niveau “design system” de Gutenberg. Tu définis une composition de blocs qui va servir de modèle réutilisable.

Un bloc pattern, c’est :

  • une structure de blocs + des attributs + du contenu par défaut
  • accessible depuis l’éditeur en un clic
  • éditable une fois inséré
  • réutilisable partout

Tu peux t’en servir pour :

  • créer des headers de section
  • poser des call-to-action récurrents
  • proposer des mises en page pré-définies (grilles, colonnes…)

Tu construis ainsi ta bibliothèque de composants éditoriaux, 100% plug and play.

Et maintenant, les Overrides de blocs dans les patterns

Avec l’évolution de Gutenberg, une fonctionnalité super utile a fait son apparition : les “Overrides” de blocs dans les block patterns.

Concrètement ? Tu peux rendre certains champs éditables, tout en verrouillant les réglages du bloc. C’est un excellent moyen de :

  • proposer des blocs avec une structure graphique stricte,
  • tout en laissant aux éditeurs la liberté de changer le contenu (texte, image, lien, etc.),
  • sans casser la mise en page ou les styles définis.

C’est un équilibre parfait entre structure + liberté.

Tu peux dire :

"Ce bloc d’intro, tu peux modifier le texte et l’image, mais pas la typo, la taille, la couleur, ni la mise en page."

Résultat : tu guides la création de contenu sans frustrer, sans fliquer, mais en gardant le cap côté design.

Terminer par les templates

C’est souvent par là qu’on commence… et pourtant c’est là qu’on devrait finir.

Les templates, c’est la couche la plus visible, mais la plus simple quand tout le reste est bien pensé.

Tu n’as plus qu’à :

  • assembler tes blocs réutilisables
  • insérer tes patterns
  • gérer les cas spécifiques en fonction des types de contenu (single.html, archive.html, etc.)

Tu ne fais presque plus de logique dans tes templates. Tu fais du design déclaratif, avec un système qui tient debout.

Conclusion : FSE n’est pas une fin en soit, mais plus un point de départ

Si t’as tout lu jusque-là, t'as été patient déjà… et je pense que t'as aussi compris l’idée : le Full Site Editing, c’est pas un nouveau jouet. C’est un cadre. Un levier. Un changement de posture.

Il t'invite à penser ton site comme un écosystème, pas comme une succession de pages à la main. Il t’invite à organiser ton projet comme tu organiserais un bon repo de code : modulaire, factorisé, documenté, réutilisable.

Et entre nous, c’est une bonne chose, non ?

Parce que pendant trop longtemps, WordPress a laissé faire “comme on veut”. Et si ça t’a permis de shipper des sites vite, ça t’a peut-être aussi laissé des dettes techniques bien planquées.

Avec Gutenberg et le FSE, t’as enfin les outils pour bosser proprement :

  • Tu structures ton design avec des tokens
  • Tu appliques une logique modulaire dès le style
  • Tu composes ton interface avec des blocs natifs enrichis
  • Tu ajoutes des variations quand c’est utile
  • Tu guides l’édition avec des patterns intelligents
  • Et tu livres un produit qui tient debout, même quand t’as la tête tournée

Ce n’est pas une nouvelle stack. C’est une nouvelle rigueur. Et elle est déjà là, dans ton éditeur.