Votre thème WordPress préféré, celui que vous utilisez depuis des années, est peut-être déjà condamné. Pas parce qu’il est laid. Pas parce qu’il est lent. Mais parce que le Full Site Editing (FSE) a fondamentalement changé la façon dont WordPress fonctionne, et les thèmes classiques PHP deviennent progressivement des citoyens de seconde zone dans l’écosystème WordPress.

Ce n’est pas une opinion. C’est une trajectoire visible dans les choix de l’équipe WordPress core depuis Gutenberg 12.x, confirmée par les versions TwentyTwenty-Five et TwentyTwenty-Six, et actée par les hébergeurs majeurs qui poussent le FSE dans leurs offres managées.

Qu’est-ce que le Full Site Editing exactement ?

Le Full Site Editing, c’est la promesse de contrôler l’intégralité d’un site WordPress depuis l’éditeur de blocs, sans jamais toucher à un fichier PHP. En thème classique, votre header et votre footer vivent dans des fichiers header.php et footer.php que vous modifiez via FTP ou l’éditeur de thème. Avec le FSE, ces zones deviennent des templates de blocs éditables visuellement, exactement comme n’importe quel contenu de page.

En 2026, le FSE n’est plus expérimental. Il est mature, adopté par les grands constructeurs de thèmes, et il intègre des fonctionnalités que les thèmes classiques ne peuvent tout simplement pas répliquer proprement : les style variations, les Block Patterns globaux, les Font Library, et le nouveau système de Layout.

La différence technique fondamentale

Un thème classique WordPress repose sur une hiérarchie de templates PHP (single.php, archive.php, page.php…) et des hooks (wp_head, wp_footer). Le style est géré via style.css et souvent des dizaines de fichiers CSS supplémentaires.

Un thème bloc (FSE) repose sur un fichier theme.json comme source de vérité pour tous les tokens de design (couleurs, typographies, espacements), et des templates HTML stockés dans /templates/ qui contiennent des blocs commentaires WordPress. Pas de PHP dans les templates eux-mêmes.

// Extrait de theme.json — définition des couleurs globales
{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "name": "Encre", "slug": "ink", "color": "#19170f" },
        { "name": "Papier", "slug": "paper", "color": "#f6f1e8" },
        { "name": "Argile", "slug": "clay", "color": "#b8442b" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "name": "Fraunces", "slug": "fraunces", "fontFamily": "Fraunces, serif" }
      ]
    }
  }
}

Ce que les thèmes classiques ne peuvent plus faire

En 2026, plusieurs fonctionnalités WordPress core sont réservées aux thèmes bloc ou fonctionnent de façon dégradée avec les thèmes classiques :

Style Variations : les utilisateurs peuvent switcher entre plusieurs palettes de couleurs et typographies d’un clic, sans plugin. Réservé au FSE.

Block Patterns synchronisés : un pattern global modifiable depuis un seul endroit et répercuté partout sur le site. En thème classique, il faut un plugin tiers ou du code custom.

Site Editor IA : WordPress.com et plusieurs hébergeurs proposent désormais un générateur de site assisté par IA qui produit directement des thèmes bloc. Les thèmes classiques sont hors de portée de ces outils.

Les thèmes FSE qui dominent en 2026

Kadence, Blocksy et GeneratePress ont tous lancé des versions FSE complètes. Astra travaille sur sa migration. Les pure-players FSE comme Ollie, Spectra One ou Frost ont gagné des millions d’installations. TwentyTwenty-Six, le thème officiel WordPress 2026, est un thème bloc pur avec des style variations saisonnières.

À noter : des thèmes hybrides existent, combinant PHP et FSE. Ils servent de pont pour les sites existants, mais ils ne bénéficient pas de toutes les fonctionnalités bloc natives et représentent une solution transitoire, pas une destination.

Faut-il migrer maintenant ?

La réponse honnête : ça dépend. Si vous avez un site WordPress avec un thème classique fonctionnel, un enfant de thème bien configuré, et des personnalisations PHP significatives, la migration vers le FSE est un projet, pas une mise à jour. Comptez plusieurs heures à plusieurs jours selon la complexité.

Les cas où migrer maintenant s’impose :

  • Vous refaites un site de zéro : partez directement sur du FSE.
  • Vous subissez des problèmes de performance : les thèmes bloc sont structurellement plus légers.
  • Vous voulez utiliser la Font Library ou les Style Variations de WordPress core.
  • Votre hébergeur pousse vers une stack WordPress managée FSE-native.

Comment migrer proprement

La migration d’un thème classique vers le FSE ne se fait pas en un clic. Voici l’approche recommandée en 2026 :

1. Inventoriez vos templates PHP et identifiez leur équivalent en blocs. Créez les templates dans /templates/ avec l’éditeur de site.

2. Extrayez vos variables CSS (couleurs, fonts, espacements) et portez-les dans theme.json.

3. Recréez vos en-têtes et pieds de page comme des patterns ou templates de blocs.

4. Auditez vos shortcodes et functions.php : les hooks de template ne fonctionnent plus de la même façon. Certaines fonctionnalités devront devenir des blocs ou des plugins.

5. Testez avec Query Monitor pour identifier les requêtes orphelines et les hooks qui ne se déclenchent plus.

L’argument de performance

Les thèmes bloc génèrent généralement moins de CSS que les thèmes classiques chargés avec des constructeurs de pages. Le système de styles en ligne scopés de Gutenberg évite le chargement de feuilles de style monolithiques. Sur PageSpeed Insights, les thèmes FSE comme Blocksy ou Kadence Blocks affichent régulièrement des scores 99-100 sans optimisation manuelle poussée.

C’est un argument de poids en 2026, où les Core Web Vitals restent un signal de ranking Google.

Ce que l’avenir réserve aux thèmes classiques

WordPress ne va pas tuer les thèmes classiques du jour au lendemain. La compatibilité ascendante est une valeur cardinale du projet. Mais les investissements de l’équipe core vont vers le FSE. Les nouvelles fonctionnalités, les outils IA, les intégrations d’hébergeurs : tout cela cible les thèmes bloc. Les thèmes classiques sont maintenus, pas développés.

En 2026, continuer à construire des sites sur des thèmes classiques sans plan de migration, c’est s’exposer à un écart croissant avec l’état de l’art. Ce n’est pas urgent. Mais c’est inévitable.

Sources :

theme.json : le fichier qui pilote désormais tout le design

Le basculement vers le FSE se joue en grande partie dans un seul fichier : theme.json. Là où un thème classique éparpillait ses réglages entre functions.php, le Customizer et des centaines de lignes de CSS, le FSE centralise palette, typographie, espacements et réglages de blocs dans une déclaration unique et structurée. WordPress en génère ensuite automatiquement les variables CSS et les contrôles de l’éditeur. Maîtriser ce fichier, c’est reprendre le contrôle du design system sans écrire une ligne de CSS impérative.

L’erreur fréquente lors d’une migration est de continuer à empiler du CSS custom à côté de theme.json : en cas de conflit, c’est la spécificité CSS qui l’emporte, pas l’intention déclarée dans le JSON, ce qui produit des régressions difficiles à tracer. La discipline saine : tout ce qui relève du système (couleurs nommées, échelle typographique, largeurs de contenu) vit dans theme.json ; le CSS ne garde que l’exceptionnel et le non-exprimable en presets.

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "color": {
      "palette": [
        { "slug": "ink",  "color": "#19170f", "name": "Encre" },
        { "slug": "clay", "color": "#b8442b", "name": "Argile" }
      ]
    },
    "typography": {
      "fontSizes": [
        { "slug": "base", "size": "1.05rem", "name": "Base" },
        { "slug": "lead", "size": "1.35rem", "name": "Chapô" }
      ]
    },
    "layout": { "contentSize": "720px", "wideSize": "1100px" }
  }
}

Block patterns et template parts : industrialiser le design

Le FSE ne se résume pas à éditer des pages à la souris ; sa vraie puissance pour un site éditorial est la réutilisation. Les template parts (en-tête, pied de page, sidebar) sont définis une fois et partagés par tous les gabarits : modifier le pied de page se fait à un seul endroit, comme un include PHP, mais éditable visuellement. Les block patterns, eux, sont des compositions de blocs prêtes à insérer, un bloc d’auteur, un encart d’appel à l’action, une mise en avant d’article, qui garantissent la cohérence visuelle sans copier-coller fragile.

Pour un blog qui publie en volume, enregistrer ses propres patterns transforme la production : un rédacteur insère un pattern « comparatif » ou « sources » normalisé au lieu de reconstruire la structure à chaque article. On industrialise ainsi la qualité éditoriale, ce qui est exactement l’objectif d’un site qui vise le référencement à grande échelle.

Construire avec FSE : les composants blocks fondamentaux

Le Full Site Editing repose sur une vingtaine de blocks dit ‘globaux’ qui forment la colonne vertébrale de votre site. Le block Query Loop est le plus puissant : il remplace l’ancien template loop PHP et vous permet d’afficher n’importe quelle liste de posts, pages ou types de contenu personnalisés avec des filtres avancés (catégorie, tag, auteur, date) sans écrire une seule ligne de code. Combinez-le avec le block Post Template pour définir comment chaque item s’affiche.

Les Patterns (modèles de blocks) sont la vraie révolution du FSE. Un Pattern est une combinaison de blocks sauvegardée et réutilisable, une section hero, un bloc témoignage, un header de page. Depuis WordPress 6.5, les Patterns peuvent être synchronisés : modifiez le Pattern original, toutes les instances se mettent à jour automatiquement. C’est l’équivalent des ‘components’ React ou des ‘includes’ PHP, mais en no-code pur.

L’éditeur de styles globaux (Styles) dans le Customizer du thème FSE est une interface centralisée pour contrôler les couleurs, typographies, espacements et apparences de tous les blocks en une seule fois. Changez la couleur primaire une fois, elle se propage à tous les boutons, liens et en-têtes. Définissez vos custom properties CSS dans le fichier `theme.json` et elles deviennent disponibles comme variables dans tout l’éditeur. Pour les agences qui gèrent plusieurs marques sur un même thème parent, cette architecture est un gain de temps considérable.

// theme.json — définir les styles globaux
{
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1a73e8", "name": "Primary" },
        { "slug": "secondary", "color": "#34a853", "name": "Secondary" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "slug": "sans", "fontFamily": "Inter, sans-serif", "name": "Sans" }
      ]
    }
  }
}

Les pièges SEO d’une migration vers le FSE

Migrer un thème n’est jamais neutre pour le référencement, et le FSE comporte des chausse-trappes spécifiques. Le premier est la gestion du <title> et des balises méta : si l’ancien thème les générait en PHP et que le nouveau gabarit FSE ne reprend pas la même logique, on peut perdre des titres optimisés du jour au lendemain. Il faut vérifier que le plugin SEO (Rank Math, Yoast) garde bien la main sur ces balises après bascule, et auditer un échantillon d’URL en live juste après le déploiement.

Le second piège est la hiérarchie des titres : l’éditeur de blocs laisse facilement insérer plusieurs H1 ou casser l’ordre H2/H3, ce qui brouille la sémantique pour Google. Enfin, surveiller le poids des pages : un thème FSE mal configuré peut charger des feuilles de styles de blocs inutiles. La règle d’or de toute migration reste la même : mesurer avant, mesurer après, et ne généraliser qu’une fois les gabarits critiques (accueil, single, archive) validés en conditions réelles.

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