Thèmes & WordPress

Thème blocs WordPress : comment fonctionne le Full Site Editing

Thèmes & WordPress · · Publié le 2026-10-27

Main qui dessine au crayon des maquettes fil de fer de pages web sur une feuille posée sur un bureau
Esquisse de maquettes de pages. Photographie de Green Chameleon, CC0 (Wikimedia Commons).

Depuis 2022, un site WordPress peut être entièrement dessiné avec des blocs, en-tête et pied de page compris, sans écrire une ligne de PHP. Ce changement repose sur un nouveau type de thème, le thème blocs, et sur un outil, l'éditeur de site. Voici comment ils fonctionnent, et ce qu'ils changent pour celles et ceux qui conçoivent ou entretiennent un site.

Thème classique, thème blocs : deux façons de construire

Pendant près de vingt ans, un thème WordPress a été un ensemble de fichiers PHP : header.php, single.php, footer.php et leurs cousins, appelés selon une hiérarchie de gabarits. Pour modifier la structure d'une page, il fallait ouvrir ces fichiers ou passer par le Customizer et des zones de widgets. La documentation officielle des développeurs décrit toujours ce modèle comme pris en charge : un thème classique utilise un « système de gabarits en PHP » et demande un minimum de connaissances en PHP, HTML et CSS.

Le thème blocs prend le problème à l'envers. La documentation le présente comme « la méthode moderne de construction des thèmes WordPress » : un thème « entièrement construit à partir de blocs », dont les gabarits sont des fichiers HTML contenant le balisage des blocs. Ces gabarits peuvent ensuite être modifiés dans l'éditeur de site, avec la même interface que celle qui sert à rédiger un article. Entre les deux, on parle parfois de thèmes « hybrides » : des thèmes classiques qui adoptent certaines fonctions des blocs, comme theme.json. La documentation précise que ce n'est pas une catégorie officielle.

Ce qu'il y a dans le dossier d'un thème blocs

Le minimum est étonnamment court. Selon la page « Theme Structure » du manuel des thèmes, seuls deux fichiers sont obligatoires :

Autour de ce noyau, le manuel décrit des dossiers « standard », chacun réservé à une fonction précise :

Dossier ou fichierContenu
templates/Les gabarits de page : single.html, page.html, archive.html, 404.html…
parts/Les parties de gabarit réutilisables : en-tête, pied de page, barre latérale.
patterns/Les compositions (patterns), des assemblages de blocs prêts à insérer.
styles/Les variations de style, des fichiers JSON qui proposent d'autres palettes ou typographies.
theme.jsonRéglages et styles globaux. Facultatif, mais central en pratique.
functions.php, assets/Facultatifs : code PHP d'appoint, polices, images, scripts.

Un gabarit de thème blocs n'est donc pas du PHP qui fabrique du HTML : c'est du HTML annoté de commentaires qui décrivent les blocs. Une partie de gabarit s'y appelle par un bloc dédié, et la boucle des articles devient un bloc « Query Loop ». Le résultat est plus lisible pour quelqu'un qui connaît l'éditeur, mais il déplace la logique : ce qui se faisait par des conditions PHP passe désormais par les réglages des blocs.

2022 : l'arrivée du Full Site Editing

Le basculement date de WordPress 5.9, baptisé « Joséphine » et publié le 25 janvier 2022. L'annonce officielle présente l'édition complète du site comme la grande nouveauté de cette version, qui « vous donne le contrôle de l'ensemble de votre site, directement dans l'administration ». Elle introduit aussi Twenty Twenty-Two, décrit comme « le premier thème par défaut en blocs de l'histoire de WordPress ». Avec un thème blocs, précise l'annonce, l'interface Styles de l'éditeur de site remplace le Customizer.

Les versions suivantes ont enrichi l'outil. WordPress 6.0, publié le 24 mai 2022, a permis aux thèmes blocs de proposer plusieurs variations de style et a ajouté de nouveaux gabarits modifiables (auteur, date, catégories, étiquettes, taxonomies). Le principe, lui, n'a pas changé depuis 2022 : tout ce que l'on voit à l'écran est un bloc, et tout bloc peut être modifié depuis l'administration.

Ce que l'éditeur de site change au quotidien

Pour la personne qui gère le site, le gain est réel : changer le logo dans l'en-tête, ajouter un lien dans le pied de page ou réorganiser la page d'accueil ne demande plus de développeur. Pour la personne qui conçoit le thème, trois conséquences méritent d'être connues avant de se lancer.

Les modifications vivent en base de données

Quand un gabarit est modifié dans l'éditeur de site, la version modifiée est enregistrée dans la base de données et prend le pas sur le fichier du thème. La documentation sur les thèmes enfants décrit cette superposition : réglages par défaut de WordPress, puis thème parent, puis thème enfant, puis personnalisations de l'utilisateur. Une mise à jour du thème qui corrige un gabarit n'aura donc aucun effet visible sur un gabarit déjà personnalisé, tant que la personnalisation n'est pas réinitialisée. C'est une source fréquente d'incompréhension lors de la mise à jour d'un site.

Le design passe par des réglages, pas par la feuille de style

Dans un thème blocs, les couleurs, tailles de police et espacements se déclarent dans theme.json. WordPress en tire des variables CSS et les propose dans l'interface. Écrire ses couleurs en dur dans style.css fonctionne toujours, mais elles échappent alors à l'interface Styles : la personne qui gère le site ne pourra pas les changer. Notre guide pratique de theme.json détaille cette mécanique.

Limiter ce qui peut être modifié

Un éditeur de site ouvert à tous les réglages permet aussi de casser une charte graphique en quelques clics. theme.json permet de désactiver les couleurs personnalisées, de restreindre les tailles de police à une échelle ou de bloquer certains réglages bloc par bloc. Sur un site d'entreprise, ces garde-fous valent souvent mieux qu'une liberté totale.

Faut-il passer au thème blocs ?

Il n'y a pas d'obligation : les thèmes classiques restent pris en charge, et un site qui fonctionne bien n'a pas besoin d'être refait pour suivre la mode. Les raisons de passer au thème blocs sont surtout pratiques : un thème plus léger à maintenir, une édition visuelle pour les personnes qui ne codent pas, et un alignement avec la direction prise par le projet WordPress. Les raisons d'attendre le sont aussi : une extension indispensable qui dépend encore des widgets ou du Customizer, un thème classique très personnalisé, ou une équipe qui n'a pas le temps de se former.

Dans tous les cas, un nouveau projet gagne à partir d'un thème blocs bien écrit plutôt que d'un thème « multi-usage » chargé d'options. Et quel que soit le choix, les mêmes exigences demeurent : un code sûr, un site accessible, des pages rapides. Le thème n'est qu'un moyen.

Sources