Thème bloc ou thème classique WordPress : la comparaison honnête

Ouvrez le dossier de votre thème. S’il contient un dossier templates avec un index.html dedans, plus un theme.json à la racine, vous avez un thème bloc. S’il contient index.php à côté de fichiers comme header.php et footer.php, et que votre barre latérale d’administration affiche Apparence puis Personnaliser, vous avez un thème classique.

Cette seule différence de structure décide de qui peut changer quoi sur votre site, de l’endroit où ces changements sont stockés, et de la moitié de l’écosystème d’extensions WordPress qui se comportera normalement.

L’identification en 30 secondes

Indice	Thème classique	Thème bloc
Fichier de template racine	index.php	templates/index.html
En-tête et pied de page	header.php, footer.php	parts/header.html, parts/footer.html
Configuration globale	functions.php	theme.json (plus un functions.php optionnel)
Menu d’administration	Apparence > Personnaliser	Apparence > Éditeur
Où les modifications sont enregistrées	Fichiers sur le disque	Base de données, en articles wp_template
Écran Widgets	Présent	Absent

WordPress tranche en cherchant templates/index.html. Un thème qui livre un theme.json mais conserve ses templates PHP reste traité comme classique — cet état intermédiaire est courant et il porte un nom, détaillé plus bas.

Si vous avez un accès shell, une seule commande règle la question :

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI est la vérification la plus rapide sur un site que vous n’avez pas construit, surtout quand un constructeur de pages a masqué les menus d’administration habituels.

Ce qui change pour la personne qui édite le site

Dans un thème classique, l’en-tête, le pied de page, la colonne latérale, les couleurs et le logo vivent derrière le Personnaliseur, et vous n’avez que les contrôles que l’auteur du thème a décidé de construire. Si le thème n’a pas prévu de contrôle pour le texte de copyright du pied de page, il n’y a pas de contrôle. Vous modifiez un fichier PHP ou vous faites avec.

Dans un thème bloc, l’éditeur de site expose la page entière. En-tête, pied de page, la boucle, la page 404, la mise en page des résultats de recherche — tout est en blocs, tout est modifiable par quelqu’un qui n’a jamais vu une ligne de PHP. C’est là le vrai argument phare, et il est réellement considérable.

Le revers, c’est que tout est modifiable par quelqu’un qui n’a jamais vu une ligne de PHP. Un client peut supprimer le titre du site dans l’en-tête à 2 heures du matin, et il n’y a aucun historique de versions sur le disque pour restaurer — seulement les révisions propres à l’éditeur de site. Verrouiller les choses est possible, avec le verrouillage de blocs et en restreignant l’accès à l’éditeur, mais c’est un travail volontaire qu’il faut penser à faire.

Deux pertes plus discrètes mais bien réelles : les thèmes bloc n’ont pas d’écran Widgets (les zones de widgets sont remplacées par les parties de template et les blocs), et les menus classiques sont remplacés par le bloc Navigation, qui stocke ses entrées dans un type de contenu à part plutôt que dans l’écran Menus habituel.

Ce qui change pour le développeur

Les thèmes classiques utilisent la hiérarchie de templates PHP. WordPress résout une requête en descendant une chaîne connue — single-{post-type}.php, puis single.php, puis singular.php, puis index.php — et votre fichier s’exécute, appelle get_header(), déroule la boucle et affiche un balisage que vous contrôlez caractère par caractère.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Les thèmes bloc reprennent les mêmes noms de hiérarchie avec l’extension .html, mais le fichier contient du balisage de blocs — du HTML avec des délimiteurs de blocs en commentaires — et il n’y a plus de balises de template :

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Trois conséquences que les développeurs rencontrent immédiatement :

get_header() et get_footer() ne s’exécutent jamais. Tout ce qui est accroché à ces actions, dans une extension ou un vieux thème enfant, ne fait silencieusement rien. wp_head et wp_footer se déclenchent toujours, donc la plupart des mises en file d’attente survivent, mais pas les hooks spécifiques à l’en-tête.

La base de données bat vos fichiers. Dès que quelqu’un enregistre un template dans l’éditeur de site, WordPress stocke cette version en article wp_template et la sert à la place de votre fichier. Vous pouvez modifier le fichier HTML tout l’après-midi et ne voir aucun changement côté visiteur. Effacer la personnalisation de ce template restaure la version du fichier. C’est le signalement « mon thème bloc est cassé » le plus fréquent, et ce n’est pas un bug.

Le style déménage dans theme.json. Couleurs, échelle d’espacement, typographie et valeurs par défaut par bloc sont déclarés comme des données plutôt que comme du CSS, et c’est WordPress qui génère le CSS. C’est plus propre et bien plus cohérent — jusqu’au jour où vous avez besoin de quelque chose que le schéma n’exprime pas, et là vous écrivez du CSS quand même en luttant contre la spécificité des règles générées.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Vérifiez la valeur de version par rapport à la version de WordPress sur laquelle vous êtes — le schéma a été révisé plus d’une fois, et recopier un numéro de version d’un vieux tutoriel produit des réglages discrètement ignorés.

Notez que functions.php ne disparaît pas. Les thèmes bloc s’en servent toujours pour les mises en file d’attente, l’enregistrement d’entrées add_image_size, les types de contenu personnalisés et tout ce qui relève du PHP. Vous y faites simplement beaucoup moins de templating.

Ce que vous gagnez vraiment, et ce que vous perdez vraiment

Passer au bloc vous fait gagner : le contrôle éditorial sur toute la page, une cohérence de design imposée par theme.json, moins de fichiers à maintenir, et des styles qui correspondent entre l’éditeur et le rendu public bien plus souvent que les thèmes classiques n’y sont jamais parvenus.

Passer au bloc vous fait perdre : le contrôle direct du balisage produit, la personnalisation simple par hooks, la compatibilité avec tout ce qui suppose des templates PHP, et la tranquillité de savoir que l’apparence du site vit dans le gestionnaire de versions.

Ce dernier point mérite d’être souligné. Dans un thème classique, git log vous dit ce qui a changé. Dans un thème bloc, une part significative de l’apparence du site vit en base de données, là où votre chaîne de déploiement ne regarde pas.

Quand un thème classique reste la bonne réponse

• Un constructeur de pages pilote le site. Elementor, Divi, Beaver Builder et leurs semblables prennent eux-mêmes en charge le templating. Glisser un thème bloc en dessous ajoute un second système de templating qui ne sert à rien.
• Le balisage doit être exact. Bibliothèques de composants sur mesure, balisage strictement accessible, exigences de données structurées inhabituelles — la sortie des blocs est contrainte par ce que les blocs produisent, et lutter contre coûte plus cher qu’écrire du PHP.
• Beaucoup de templating porté par des extensions. Adhésion, LMS, annuaires et anciennes extensions de commerce livrent fréquemment des surcharges de templates PHP. Beaucoup ont désormais un équivalent bloc ; beaucoup n’en ont pas.
• Le site est terminé et fonctionne. Un thème avec cinq ans de personnalisations accumulées n’a pas de chemin de mise à niveau vers le bloc, seulement une reconstruction. « C’est l’approche la plus récente » n’est pas un argument business.
• Personne d’autre que vous ne l’éditera. Le principal bénéfice de l’éditeur de site est de confier le contrôle à des non-développeurs. S’il n’y a pas de non-développeurs, vous payez le prix d’un avantage dont personne ne se sert.

Le terrain d’entente hybride

Un thème classique peut ajouter un theme.json et récupérer le système de styles globaux, les presets de couleurs et d’espacement, et un style d’éditeur cohérent — tout en conservant ses templates PHP et son Personnaliseur. WordPress n’appelle pas cela un thème bloc, et l’éditeur de site reste indisponible, mais vous récupérez l’essentiel du bénéfice « système de design » pour une fraction du travail.

Pour un site existant qui fonctionne globalement bien, c’est en général le bon premier geste. Ajoutez theme.json, définissez votre palette et vos espacements, supprimez le CSS qu’il remplace, et voyez si vous voulez encore le reste.