WordPress 6.9, sorti début 2026, promettait une révolution : le Full Site Editing (FSE) enfin mature, un éditeur unifié pour tous les thèmes, et la fin progressive du PHP template classique. Six mois après le déploiement massif, le bilan réel est très différent de ce que les communicants annonçaient. Les développeurs WordPress ont découvert des changements profonds, certains bienvenus, d’autres sources de friction intense.

Ce qu’était censé être le Full Site Editing en 2026

La promesse du FSE (Full Site Editing) était simple : permettre à n’importe quel utilisateur de personnaliser chaque zone de son site, header, footer, templates d’articles, pages d’archive, sans toucher une ligne de code PHP. Avec WordPress 6.9, cette promesse semblait enfin tenue grâce à l’éditeur de site « unifié ».

Sur le papier, c’est révolutionnaire. En pratique, les développeurs ont découvert une réalité bien plus nuancée.

L’éditeur unifié : révolution ou usine à gaz ?

WordPress 6.9 introduit un éditeur de site global qui fusionne l’éditeur de blocs et l’éditeur de thème. Plus besoin de naviguer entre « Apparence > Personnaliser » et l’éditeur classique. Tout se passe dans une interface unique.

Mais voici ce que personne n’anticipait : la courbe d’apprentissage s’est inversée. Les utilisateurs novices, familiers de l’ancien Customizer, se retrouvent perdus face à l’interface de blocs. Les développeurs expérimentés, eux, doivent réapprendre à structurer leurs thèmes selon une nouvelle architecture basée sur theme.json version 3.

theme.json v3 : la vraie rupture technique

La version 3 de theme.json introduite avec WordPress 6.9 change profondément la manière de définir les styles globaux d’un thème. Les nouvelles propriétés permettent une granularité sans précédent, mais créent des incompatibilités avec les thèmes construits pour les versions WordPress 6.x antérieures.

{
  "version": 3,
  "settings": {
    "typography": {
      "fluid": true,
      "fontFamilies": [
        {
          "name": "Inter",
          "slug": "inter",
          "fontFamily": "Inter, sans-serif",
          "fontFace": [
            {
              "fontFamily": "Inter",
              "fontWeight": "400 700",
              "fontStyle": "normal",
              "src": ["file:./assets/fonts/inter-variable.woff2"]
            }
          ]
        }
      ]
    },
    "color": {
      "palette": [
        { "name": "Primaire", "slug": "primary", "color": "#1a73e8" },
        { "name": "Fond", "slug": "background", "color": "#ffffff" }
      ]
    }
  },
  "styles": {
    "typography": {
      "fontSize": "clamp(1rem, 1.5vw + 0.5rem, 1.125rem)",
      "lineHeight": "1.7"
    }
  }
}

La dépréciation des hooks historiques : la bombe à retardement

C’est le sujet le moins médiatisé mais potentiellement le plus destructeur pour les sites en production. WordPress 6.9 a marqué comme dépréciés plusieurs hooks PHP utilisés massivement depuis des années : wp_head, wp_footer, the_content dans certains contextes, et plusieurs filtres liés au menu de navigation classique.

Ces hooks ne sont pas supprimés, ils fonctionnent toujours, mais les développeurs qui maintiennent des plugins ou des thèmes custom doivent prévoir la migration. WordPress a annoncé leur suppression définitive dans la version 7.0.

Les thèmes bloc vs thèmes classiques : la guerre froide continue

En juin 2026, malgré la pression de l’équipe WordPress core, seulement 23 % des sites WordPress actifs utilisent un thème bloc (FSE). Les 77 % restants tournent toujours sur des thèmes classiques PHP, Divi, Avada, ou des thèmes custom développés avant 2023.

La raison est simple : migrer un thème classique complexe vers un thème bloc représente souvent plusieurs semaines de travail. Pour les agences qui gèrent des dizaines de sites clients, c’est un investissement difficile à justifier quand le site fonctionne parfaitement en production.

La gestion des médias refondée : enfin !

Un point positif largement salué : la refonte de la bibliothèque médias. WordPress 6.9 introduit une interface modernisée avec filtres par date, type de fichier, et taille. Les images WebP et AVIF sont désormais gérées nativement, sans plugin. La compression automatique à l’upload a été améliorée.

Pour les sites avec des milliers de médias, c’est une amélioration tangible du quotidien. La recherche est plus rapide, les dossiers virtuels permettent une organisation plus claire.

PHP 8.2+ : la mise à niveau forcée

WordPress 6.9 requiert officiellement PHP 8.1 minimum, avec une forte recommandation pour PHP 8.2. Cela semble raisonnable, sauf que des dizaines de plugins populaires ne sont pas encore pleinement compatibles PHP 8.2. Des erreurs de type « Deprecated: Required parameter follows optional parameter » surgissent sur des plugins pourtant toujours maintenus.

La recommandation pratique : avant toute mise à jour vers WordPress 6.9, auditez votre liste de plugins avec un outil de compatibilité PHP, ou testez sur un environnement de staging dédié.

Ce que les développeurs recommandent vraiment

Après six mois de recul, les développeurs WordPress expérimentés convergent vers une recommandation pragmatique : ne migrez pas vers les thèmes bloc si votre site fonctionne et si vous n’avez pas de raison business claire de le faire.

Le FSE est l’avenir de WordPress, c’est indéniable. Mais l’avenir n’est pas encore aujourd’hui pour tous les projets. Pour les nouveaux sites, les thèmes bloc comme Kadence, Blocksy ou TwentyTwenty-Five offrent d’excellentes bases. Pour les sites existants, la priorité reste PHP 8.2, les performances, et la sécurité.

Sources :

Migrer un thème classique vers le FSE sans tout casser

La migration d’un thème PHP historique vers le Full Site Editing n’a pas à être un big bang. WordPress 6.9 conforte l’approche des thèmes hybrides : on convertit les gabarits un par un en gardant le reste du thème en PHP classique. Concrètement, on commence par déclarer un theme.json minimal pour reprendre la main sur les réglages globaux (couleurs, typographie, espacements), puis on bascule d’abord les zones les moins risquées, 404.html, archive.htmlavant de toucher la page d’accueil ou le single, qui concentrent le SEO et les conversions.

Le piège classique consiste à laisser cohabiter des styles définis dans style.css et dans theme.json : en cas de conflit, c’est la spécificité CSS qui tranche, pas l’ordre de déclaration, ce qui produit des régressions difficiles à diagnostiquer. La règle saine : tout ce qui relève du design system (palette, échelle typographique) passe par theme.json ; le CSS custom ne garde que ce qui n’est pas exprimable en presets.

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "color": {
      "palette": [
        { "slug": "ink",  "color": "#19170f", "name": "Encre" },
        { "slug": "clay", "color": "#b8442b", "name": "Argile" }
      ]
    },
    "layout": { "contentSize": "720px", "wideSize": "1100px" }
  }
}

Patterns synchronisés : la vraie fin des shortcodes maison

Avant le FSE, un bloc d’appel à l’action réutilisable se gérait avec un shortcode et une fonction dans functions.php. WordPress 6.9 généralise les patterns synchronisés (ex-reusable blocks) et la Block Bindings API : un même bloc édité une fois se répercute partout où il est inséré, sans code PHP ni dette technique. Pour un développeur, cela change la frontière entre ce qui doit être codé et ce qui doit être délégué à l’éditeur.

La Block Bindings API, stabilisée dans cette version, permet de lier l’attribut d’un bloc à une source dynamique, une meta de post, une option, une donnée tierce, sans créer de bloc custom complet. On réserve désormais le développement de blocs ACF/natifs aux cas réellement dynamiques, et on confie le reste aux patterns. Résultat : moins de code à maintenir, et un thème que l’équipe éditoriale peut faire évoluer seule.

Checklist de compatibilité avant de livrer un thème FSE 6.9

Avant de pousser un thème FSE en production, une revue systématique évite les régressions silencieuses. Les points qui cassent le plus souvent : les hooks dépréciés encore appelés par un plugin tiers, les template-parts référencés mais absents, et les réglages theme.json v2 non migrés vers le schéma v3.

Checklist minimale : (1) wp theme validate et le Theme Check passent sans erreur bloquante ; (2) chaque gabarit HTML a un fallback PHP ou une template-part équivalente ; (3) aucune fonction du thème n’appelle un hook marqué deprecated dans le changelog 6.9 ; (4) les Core Web Vitals du single restent verts après bascule (le FSE ajoute du CSS inline qu’il faut surveiller) ; (5) l’éditeur de site ne génère pas d’erreur console sur les patterns synchronisés. Cette passe de quinze minutes épargne des heures de support après mise en ligne.

Surveiller le CSS inline et la dette de performance du FSE

Le Full Site Editing déplace une part du style dans des feuilles générées à la volée et injectées en ligne dans le <head>. Pratique pour l’éditeur, mais c’est une source silencieuse de régression de performance : plus on multiplie les blocs et les presets theme.json, plus le poids du CSS critique enfle, ce qui dégrade le First Contentful Paint et le Largest Contentful Paint. Sur un thème FSE livré sans audit, il n’est pas rare de voir 40 à 60 Ko de CSS inline là où le thème classique en chargeait 12.

La parade tient en trois réflexes. D’abord, activer le chargement à la demande des styles de blocs (should_load_separate_core_block_assets) pour que WordPress n’émette que le CSS des blocs réellement présents sur la page. Ensuite, limiter le nombre de presets dans theme.json : chaque couleur, dégradé et taille génère des variables et des classes utilitaires, même inutilisées. Enfin, mesurer après chaque livraison avec Lighthouse ou WebPageTest plutôt qu’à l’œil, le FSE ne dégrade pas les Core Web Vitals brutalement, il les grignote, et seul un suivi chiffré rend la dérive visible avant qu’elle ne coûte des positions dans la SERP.

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon