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 :

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.