Où en est le Full Site Editing dans WordPress

par | WordPress

Si votre client vous dit « je ne retrouve plus l’en-tête dans Apparence > Personnaliser », il ne parle pas d’un bug. Il tombe sur la réalité de WordPress 6.9.4 : le workflow “Full Site Editing” (FSE) n’est plus une option marginale, c’est une trajectoire par défaut pour une partie croissante des thèmes… et un point de friction récurrent quand on mélange thèmes blocs, thèmes classiques, page builders et plugins historiques.

Je vois souvent le même scénario en support : un site passe sur un thème bloc, l’équipe continue à chercher les réglages du Customizer, puis finit par ajouter un plugin de snippets pour « remettre le header ». Résultat : dette technique, incohérences d’édition, et parfois des templates qui ne se chargent plus comme prévu.

Ce qui change

Avec WordPress 6.9.x (6.9.4 étant la stable en avril 2026), le FSE n’est plus seulement “l’éditeur de site”. C’est un ensemble cohérent : thèmes blocs, templates HTML, styles globaux, patterns synchronisés, et une séparation plus nette entre ce qui relève du contenu (posts/pages) et ce qui relève de la structure (templates/parts).

Concrètement, ce qui change pour votre workflow :

  • La source de vérité du design se déplace vers theme.json et les Styles globaux, plutôt que vers le Customizer et des options de thème.
  • La structure (header/footer/single/archive) se gère via des templates et template parts, souvent en HTML avec des commentaires de blocs.
  • La personnalisation “client” (logo, couleurs, typo, layout) devient plus prévisible si vous embrassez les presets et les styles, et plus fragile si vous continuez à “patcher” au cas par cas.

Pour suivre les changements côté core, les sources à garder sous la main :

Note de terrain : depuis 6.7–6.9, j’ai vu moins de “gros” breaking changes visibles pour les blogueurs, mais beaucoup de micro-évolutions qui changent la façon d’industrialiser (patterns, styles, gestion des templates, APIs de blocs). Ce sont ces détails qui font gagner (ou perdre) des heures.

Résumé rapide

  • FSE = workflow, pas juste un écran : templates, template parts, styles globaux, patterns, navigation.
  • Le Customizer n’est plus central pour les thèmes blocs : la personnalisation passe par Styles/Éditeur de site et theme.json.
  • Les thèmes classiques continuent d’exister, mais l’écart de fonctionnalités avec les thèmes blocs s’est creusé (et vos plugins doivent composer avec les deux).
  • Les page builders (Divi 5, Elementor, Avada) cohabitent, mais le “qui contrôle quoi” doit être décidé explicitement (header/footer, templates, CSS global).
  • Le risque principal n’est pas “ça casse” mais “ça devient incohérent” : styles du builder vs styles globaux, templates du thème vs templates builder.
  • Migration réaliste : commencer par un hybride maîtrisé (templates critiques + styles), puis basculer le reste.

Avant / Après en code

Le meilleur marqueur d’un changement de workflow, c’est l’endroit où vous mettez votre logique. Avant, beaucoup de sites “thème classique” centralisaient la personnalisation via le Customizer. Avec FSE, vous poussez davantage vers theme.json et des variations de styles.

Avant (thème classique) : Customizer + CSS ad hoc

Exemple : ajouter une option de couleur de liens via le Customizer, puis injecter du CSS en front.

<?php
/**
 * Ancienne approche : thème classique + Customizer.
 * Problème fréquent : options dispersées, CSS injecté, difficile à versionner proprement.
 */

add_action( 'customize_register', function( $wp_customize ) {
	$wp_customize->add_setting( 'bpcab_link_color', array(
		'default'           => '#1e73be',
		'sanitize_callback' => 'sanitize_hex_color',
		'transport'         => 'refresh',
	) );

	$wp_customize->add_control( new WP_Customize_Color_Control(
		$wp_customize,
		'bpcab_link_color',
		array(
			'label'   => 'Couleur des liens',
			'section' => 'colors',
		)
	) );
} );

add_action( 'wp_head', function() {
	$color = get_theme_mod( 'bpcab_link_color', '#1e73be' );
	$color = sanitize_hex_color( $color ) ?: '#1e73be';

	echo '<style>a{color:' . esc_html( $color ) . ';}</style>';
} );

Ça marche, mais j’ai souvent vu :

  • du CSS injecté en double (plugin de cache + minification + head injections),
  • des valeurs non synchronisées entre environnements (prod/staging) si on oublie d’exporter les mods,
  • un thème enfant qui surcharge functions.php et casse le Customizer avec une parenthèse manquante.

Après (thème bloc/FSE) : theme.json + presets + variations

Avec un thème bloc, vous décrivez la palette/typographie dans theme.json. L’utilisateur ajuste via Styles globaux, et vous gardez une base versionnée.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"settings": {
		"color": {
			"palette": [
				{ "slug": "primary", "color": "#1e73be", "name": "Primaire" },
				{ "slug": "text", "color": "#111111", "name": "Texte" }
			]
		},
		"typography": {
			"fontFamilies": [
				{
					"fontFamily": "-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Arial, sans-serif",
					"slug": "system",
					"name": "System"
				}
			]
		}
	},
	"styles": {
		"elements": {
			"link": {
				"color": {
					"text": "var(--wp--preset--color--primary)"
				}
			}
		}
	}
}

Différences clés :

  • Versionnable : le design de base vit dans Git, pas dans la base de données.
  • Prévisible : les presets génèrent des variables CSS standardisées (ex. --wp--preset--color--primary).
  • Moins de “glue code” : vous évitez wp_head pour du CSS dynamique.

Le pont (souvent nécessaire) : ajouter des styles globaux depuis un plugin

Dans la vraie vie, vous avez parfois besoin d’un plugin (ou mu-plugin) pour imposer une règle globale, sans dépendre du thème (agence multi-thèmes, réseau multisite, etc.). Pour WordPress 6.9.4, une approche robuste consiste à injecter un stylesheet global et à s’appuyer sur les variables de presets quand elles existent.

<?php
/**
 * Approche moderne : charger un CSS global, compatible thèmes blocs.
 * Fonctionne aussi avec thèmes classiques (les variables peuvent ne pas exister).
 */
add_action( 'wp_enqueue_scripts', function() {
	$css = '
		:root {
			/* Fallback si le thème ne définit pas le preset */
			--bpcab-primary: var(--wp--preset--color--primary, #1e73be);
		}
		a { color: var(--bpcab-primary); }
		a:hover { opacity: 0.85; }
	';

	wp_register_style( 'bpcab-global', false, array(), '1.0.0' );
	wp_enqueue_style( 'bpcab-global' );
	wp_add_inline_style( 'bpcab-global', $css );
}, 20 );

Piège courant : coller ce code dans le mauvais endroit (ex. un fichier de template, ou un snippet plugin qui l’exécute en admin). Gardez-le dans un plugin, un mu-plugin, ou functions.php d’un thème enfant, et testez avec WP_DEBUG activé.

Impact concret

Pour les blogueurs (intermédiaires)

  • Vous éditez la structure (header/footer) sans toucher au code, mais vous pouvez aussi la casser sans le vouloir (ex. supprimer un bloc “Titre du site”).
  • Vous gagnez en cohérence si vous utilisez les Styles globaux plutôt que d’ajouter du CSS par page.
  • Vous perdez des repères si vous veniez du Customizer : certains réglages “n’existent plus” parce qu’ils ont changé d’endroit (ou parce que le thème bloc ne les expose pas).

Pour les développeurs / agences

  • La responsabilité se déplace : vous ne livrez plus seulement un thème, vous livrez un système (templates + patterns + styles + guidelines d’édition).
  • La review devient différente : vous relisez du HTML de templates avec des commentaires de blocs, et du JSON (theme.json), plus que du PHP.
  • La maintenance est plus saine si vous évitez les options “maison” et vous alignez sur les presets et les APIs core.

Impact sur les plugins existants

Les plugins qui “injectent” des éléments structurels (bannières, bars de consentement, CTA globaux) doivent choisir leur point d’ancrage :

  • Sur un thème classique : hooks PHP (ex. wp_body_open, wp_footer).
  • Sur un thème bloc : idéalement, fournir un bloc ou un pattern que l’utilisateur place dans un template/part.

Dans mon expérience, le pire anti-pattern en 2026 reste : “je force un header via wp_head ou un output buffer”. Ça finit en conflits avec la navigation bloc, les caches et l’accessibilité.

Impact sur les thèmes (classiques vs blocs)

  • Thèmes classiques : toujours valables, surtout si vous dépendez d’un builder ou d’un framework historique. Mais vous aurez plus de “ponts” à maintenir (Customizer, options, widgets, etc.).
  • Thèmes blocs : plus alignés avec la direction core. Les personnalisations doivent passer par theme.json, patterns, styles, et éventuellement des variations.

Divi 5, Elementor, Avada : compatibilité réelle (pas théorique)

Sur des sites intermédiaires, la question n’est pas “est-ce compatible ?” mais “qui pilote la structure ?”. Décidez-le explicitement.

  • Divi 5 : si vous utilisez le Theme Builder Divi pour header/footer, évitez de laisser l’équipe éditer aussi les template parts FSE, sinon vous aurez deux sources de vérité. Gardez FSE pour styles globaux/presets, ou désactivez l’édition de certaines zones via rôles.
  • Elementor : même logique. Elementor gère souvent les templates (header/single). Un thème bloc en arrière-plan peut ajouter des styles globaux inattendus. Testez les variables CSS --wp--preset--* : elles peuvent influencer vos CSS si vous utilisez des sélecteurs trop génériques.
  • Avada (Fusion Builder) : Avada reste très “option panel”. Sur un site qui migre vers FSE, je recommande souvent une étape intermédiaire : conserver Avada mais commencer à adopter une discipline “presets” (couleurs/typos) et réduire les réglages dispersés.

Tableau de diagnostic (problèmes typiques FSE)

Symptôme Cause probable Vérification Solution
Le header a “disparu” Template part modifiée/supprimée dans l’éditeur de site Éditeur de site > Modèles > Parties de modèle Restaurer la partie, ou réinitialiser la personnalisation du template
Les couleurs changent selon les pages Styles globaux + CSS du builder + CSS custom par page Inspecteur navigateur, ordre des styles chargés Centraliser : presets/theme.json + réduire le CSS “page-level”
Un plugin ajoute une barre mais elle casse la mise en page Injection via hook non adapté, ou CSS trop global Voir si le markup est dans wp_footer / wp_body_open Transformer en bloc/pattern, ou restreindre le CSS (scoping)
Modifs non visibles malgré sauvegarde Cache (plugin/CDN) ou CSS minifié non purgé Tester en navigation privée + purger caches Purger cache, incrémenter version de style, vérifier CDN
Erreur fatale après ajout de snippet Point-virgule/parenthèse manquant(e), ou hook exécuté trop tôt Logs PHP, activer WP_DEBUG_LOG Corriger syntaxe, déplacer sur le bon hook, tester sur staging

Risques, compatibilités et points de vigilance

Ce qui est nouveau vs ce qui change vraiment

  • Nouveau (côté usage) : la maturité des workflows basés sur patterns/styles/templates. Beaucoup de sites peuvent enfin standardiser sans builder.
  • Change (côté équipe) : la frontière “contenu vs structure” devient éditable dans la même UI. Super pouvoir… et source d’erreurs.
  • Peut casser (côté écosystème) : plugins/thèmes qui supposent l’existence du Customizer, des widgets, ou d’un header/footer PHP classique.

Breaking changes : rarement front, souvent process

En 6.9.x, les “breaks” visibles viennent surtout :

  • de templates surchargés (un template modifié en base de données qui masque une mise à jour du thème),
  • de priorités de hooks (un plugin enfile du CSS trop tard/trop tôt),
  • de conflits de CSS (sélecteurs globaux type a {} dans un builder ou un vieux thème enfant).

Timeline de dépréciation (ce que je surveille en pratique)

Je ne vais pas vous promettre une date de suppression du Customizer : WordPress a historiquement gardé une compatibilité longue. En revanche, la tendance est claire : moins d’investissements dans les flux “Customizer-first”, plus d’énergie sur l’éditeur de site et Gutenberg.

Ce que je recommande de traiter comme “déjà déprécié” dans votre tête :

  • Ajouter de nouvelles options Customizer pour des thèmes que vous maintenez à long terme.
  • Multiplier les “options de thème” propriétaires au lieu de s’appuyer sur theme.json et les presets.

Sécurité : l’édition de site élargit la surface d’erreur

Quand vous donnez accès à l’éditeur de site, vous donnez accès à la structure. Sur des sites multi-auteurs, c’est parfois trop permissif.

  • Vérifiez les rôles/capacités : évitez de laisser un rôle “éditeur” modifier des templates si votre organisation n’est pas prête.
  • Surveillez les plugins qui ajoutent des blocs “dynamiques” : la sortie doit être échappée correctement côté PHP. Un bloc mal codé peut devenir un vecteur XSS.

Référence utile côté sécurité PHP : PHP Manual – Security

Comment migrer

La migration FSE réussie ressemble rarement à “on change de thème et tout le monde est content lundi”. Elle ressemble plutôt à une suite de bascules contrôlées, avec des garde-fous.

Étape 0 : vérifier l’environnement (PHP et staging)

  • PHP : visez 8.1+ (minimum recommandé). Beaucoup de vieux snippets cassent sur 8.x (types, fonctions dépréciées, warnings transformés en erreurs selon config).
  • Faites la migration sur staging, avec une copie de la base.
  • Activez les logs : WP_DEBUG, WP_DEBUG_LOG (sans afficher en front en prod).
<?php
// wp-config.php (staging uniquement)
// Attention : ne pas afficher les erreurs en production.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Étape 1 : décider “qui gère header/footer” (core vs builder)

C’est la décision qui évite 80% des incohérences.

  • Si vous gardez Divi/Elementor/Avada pour header/footer : verrouillez l’édition FSE des template parts (process interne + droits).
  • Si vous basculez vers FSE : recréez header/footer en template parts, puis désactivez les templates builder correspondants.

Étape 2 : extraire vos “réglages de design” vers theme.json

Commencez petit : palette + typo + espacements. Le but est de réduire le CSS custom et les options dispersées.

Piège que je vois souvent : copier un theme.json trouvé dans un vieux tutoriel (version 2, structure différente) et se retrouver avec des settings ignorés. En 6.9.4, utilisez le schéma actuel.

Schéma officiel : Theme.json reference

Étape 3 : transformer les sections répétitives en patterns (souvent synchronisés)

Si vous avez des blocs “CTA”, “Bio auteur”, “Encart newsletter” répétés, mettez-les en patterns. Sur des sites éditoriaux, c’est un gain énorme : une correction, propagée partout (si synchronisé).

Exemple : enregistrer un pattern depuis un plugin (pratique pour une agence). Il faut un fichier PHP, et un fichier pattern.

<?php
/**
 * Enregistrement d'une catégorie de patterns et d'un pattern.
 * À placer dans un plugin (ou mu-plugin) pour le versionner.
 */
add_action( 'init', function() {

	if ( function_exists( 'register_block_pattern_category' ) ) {
		register_block_pattern_category(
			'bpcab',
			array( 'label' => 'Patterns Agence (BPCAB)' )
		);
	}

	if ( function_exists( 'register_block_pattern' ) ) {
		register_block_pattern(
			'bpcab/cta-newsletter',
			array(
				'title'       => 'CTA Newsletter',
				'categories'  => array( 'bpcab' ),
				'description' => 'Un encart CTA simple, cohérent avec les presets du thème.',
				'content'     => '<!-- wp:group {"style":{"spacing":{"padding":{"top":"var:preset|spacing|40","bottom":"var:preset|spacing|40","left":"var:preset|spacing|40","right":"var:preset|spacing|40"}}},"backgroundColor":"primary","textColor":"base","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-base-color has-primary-background-color has-text-color has-background" style="padding-top:var(--wp--preset--spacing--40);padding-right:var(--wp--preset--spacing--40);padding-bottom:var(--wp--preset--spacing--40);padding-left:var(--wp--preset--spacing--40)">
	<!-- wp:heading {"level":3} -->
	<h3>Recevez les prochains articles</h3>
	<!-- /wp:heading -->

	<!-- wp:paragraph -->
	<p>Un email par semaine, zéro bruit.</p>
	<!-- /wp:paragraph -->

	<!-- wp:buttons -->
	<div class="wp-block-buttons">
		<!-- wp:button {"backgroundColor":"base","textColor":"primary"} -->
		<div class="wp-block-button"><a class="wp-block-button__link has-primary-color has-base-background-color has-text-color has-background wp-element-button" href="/newsletter/">Je m’inscris</a></div>
		<!-- /wp:button -->
	</div>
	<!-- /wp:buttons -->
</div>
<!-- /wp:group -->',
			)
		);
	}
} );

Erreurs réalistes :

  • Copier le contenu du pattern avec des guillemets non échappés et casser le PHP.
  • Enregistrer sur le hook plugins_loaded et se demander pourquoi le pattern n’apparaît pas (utilisez init).
  • Oublier de vider le cache d’objets / cache page après ajout (surtout sur hébergement managé).

Étape 4 : gérer les templates modifiés en base (le “piège silencieux”)

Quand vous éditez un template via l’éditeur de site, WordPress peut stocker une version en base. Ensuite, une mise à jour du thème ne se reflète pas, parce que la version “user” prend le dessus.

Check concret :

  • Après update de thème, si un correctif “n’apparaît pas”, comparez le template du thème et la version personnalisée.
  • Documentez une règle interne : “qui a le droit de modifier les templates”.

Étape 5 : compat plugin/builder (CSS et enqueues)

Si vous gardez un builder, soyez strict sur les enqueues. Un mauvais wp_enqueue_scripts est la cause n°1 des “styles cassés” après migration.

<?php
/**
 * Exemple : charger un CSS spécifique seulement sur le front,
 * et éviter de polluer l'éditeur (ou inversement).
 */
add_action( 'wp_enqueue_scripts', function() {
	wp_enqueue_style(
		'bpcab-front',
		get_stylesheet_directory_uri() . '/assets/css/front.css',
		array(),
		'1.0.0'
	);
} );

add_action( 'enqueue_block_editor_assets', function() {
	wp_enqueue_style(
		'bpcab-editor',
		get_stylesheet_directory_uri() . '/assets/css/editor.css',
		array(),
		'1.0.0'
	);
} );

Piège courant : charger le CSS front dans l’éditeur et croire que “FSE est cassé” parce que l’UI devient illisible. Séparez vos feuilles.

Faut-il agir maintenant ou attendre ?

Si vous gérez un blog actif (ou un réseau de sites) et que votre thème actuel est classique + Customizer, vous n’êtes pas obligé de migrer demain. Mais vous devriez agir maintenant sur deux points, même si vous “attendez” :

  • Réduire la dépendance aux options propriétaires (Customizer custom, panels de thème, CSS injecté), et rapprocher votre design d’un système (palette, typo, échelle d’espacement).
  • Décider une stratégie builder vs FSE : soit vous assumez le builder comme source de vérité, soit vous commencez à basculer la structure vers FSE.

Je recommande d’attendre (ou plutôt de ne pas basculer en one-shot) si :

  • Vous avez un site e-commerce critique avec beaucoup de templates builder et des tests insuffisants.
  • Votre équipe éditoriale n’a pas de process (qui touche aux templates ? comment on rollback ?).

Je recommande d’agir vite si :

  • Vous repartez sur une refonte, ou vous changez de thème de toute façon.
  • Vous maintenez plusieurs sites : un socle FSE + patterns versionnés vous fera gagner du temps dès le second site.

Conseils de maintenance

  • Versionnez : theme.json, patterns (plugin), CSS, et si possible exportez vos réglages de styles globaux quand vous standardisez un design.
  • Testez les mises à jour sur staging avec un jeu de pages représentatif : home, single, archive, pages builder, pages “pures blocs”.
  • Surveillez les templates personnalisés : c’est la source classique de “pourquoi la mise à jour du thème ne change rien”.
  • Cache : après migration, documentez une checklist “purge cache plugin + CDN + navigateur”. J’ai vu des équipes perdre une demi-journée sur un CSS qui était juste servi par Cloudflare.
  • Permissions : si plusieurs auteurs, évitez de donner l’accès à l’éditeur de site sans garde-fou. Un mauvais drag-and-drop dans un template peut impacter tout le site.
  • Compat PHP : refusez les snippets trouvés sur des articles 2019. Beaucoup utilisent des patterns de code qui génèrent des warnings/fatals en PHP 8.1+.

Ressources

FAQ

1) FSE remplace-t-il complètement les page builders ?

Non. FSE couvre désormais beaucoup de besoins (structure + styles + patterns), mais les builders gardent des avantages (workflows marketing, bibliothèques, widgets avancés). Le point clé est d’éviter deux systèmes qui pilotent la même zone (ex. deux headers).

2) Pourquoi je n’ai pas “Éditeur (Site)” dans l’admin ?

Parce que vous utilisez probablement un thème classique. L’éditeur de site complet est lié aux thèmes blocs. Vérifiez dans Apparence : si vous voyez “Éditeur” au lieu de “Personnaliser”, vous êtes côté FSE.

3) Est-ce que je vais perdre mon contenu en changeant pour un thème bloc ?

Votre contenu (posts/pages) reste. Ce qui change, c’est la structure et la présentation. Le risque réel est la mise en page (shortcodes, widgets, templates builder) qui peut devenir incohérente.

4) Pourquoi mes modifications de thème ne s’appliquent pas après une mise à jour ?

Souvent parce qu’un template a été modifié via l’éditeur de site et stocké en base. Cette version personnalisée masque la version du thème. Vérifiez les modèles/parties de modèle dans l’éditeur.

5) Puis-je continuer à utiliser le Customizer ?

Oui si votre thème est classique (ou si un plugin l’expose). Mais pour un thème bloc, baser de nouvelles fonctionnalités sur le Customizer vous enferme dans un workflow qui n’est plus central.

6) Quel est le meilleur point d’injection pour un bandeau global (cookie/CTA) en FSE ?

Si c’est structurel et réutilisable : créez un bloc ou un pattern et placez-le dans une template part (footer, par exemple). Si vous devez absolument injecter via PHP, préférez des hooks comme wp_body_open ou wp_footer selon le besoin, et scoper votre CSS.

7) Pourquoi le CSS de mon thème enfant “ne marche plus” ?

Très souvent : mauvais enqueue, ordre de chargement, ou cache. Vérifiez que votre CSS est bien enqueued sur wp_enqueue_scripts, et purge cache plugin/CDN. Vérifiez aussi si les styles globaux (theme.json) écrasent vos règles.

8) Est-ce que theme.json est obligatoire ?

Non, mais sans theme.json, vous perdez une grosse partie de la cohérence FSE (presets, variables, styles globaux). Sur un thème bloc maintenu sérieusement, il devient rapidement incontournable.

9) Comment éviter qu’un éditeur casse le header/footer ?

Process + permissions. Limitez l’accès à l’éditeur de site, documentez les zones éditables, et travaillez avec des patterns synchronisés plutôt que des blocs “libres” partout.

10) Je peux migrer progressivement, page par page ?

Oui, et c’est souvent la meilleure approche. Gardez certaines pages dans votre builder, basculez les templates critiques (header/footer/blog), puis standardisez le design via presets. Le piège est de ne pas décider clairement qui contrôle la structure à un instant donné.

Articles connexes

Envoyer Un Commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.