Thème classique ou thème de blocs : comment choisir pour votre boutique WooCommerce

WordPress propose depuis plusieurs versions deux façons de construire l’habillage visuel d’une boutique WooCommerce : le thème classique, écrit en PHP, et le thème de blocs, construit entièrement avec l’éditeur de blocs et pilotable depuis le Site Editor. Pour un dirigeant de boutique, la question n’est pas technique par goût : elle détermine qui peut modifier une page produit, une page d’accueil ou une fiche catégorie, à quel coût, et avec quel niveau de dépendance à un développeur.

Cet article explique la différence entre les deux approches, ce qu’elle change concrètement pour une boutique, et propose une méthode simple pour trancher sans avoir à suivre les débats internes du projet WordPress.

Ce qu’est un thème de blocs, en langage de gestion

Un thème de blocs repose sur trois éléments documentés par WordPress : des gabarits HTML composés de blocs, un fichier theme.json qui centralise les couleurs, les polices et les espacements, et le Site Editor, l’interface qui permet de modifier ces gabarits sans toucher au code. Il est même possible d’exporter un thème directement depuis cet éditeur. À l’inverse, un thème classique reste un ensemble de fichiers PHP : toute modification structurelle (en-tête, pied de page, mise en page d’une fiche produit) passe par un développeur ou par un constructeur de pages tiers installé en complément.

Cette bascule n’est pas un détail cosmétique. Elle a été la pièce centrale de la deuxième phase du projet Gutenberg, celle qui a introduit l’édition complète du site à partir de WordPress 6.3. Pour 2026, WordPress annonce trois versions majeures dont WordPress 7.0, qui avance sur la collaboration (plusieurs personnes qui modifient le même contenu), la gestion des médias côté navigateur et des réglages de mise en page responsive plus fins. Autrement dit, l’écart fonctionnel entre thème de blocs et thème classique continue de se creuser en faveur du premier, run après run de développement du cœur WordPress.

Ce que ça change pour une boutique WooCommerce

WooCommerce documente aujourd’hui deux parcours distincts et parallèles : « Block themes » et « Classic themes », avec dans les deux cas des blocs Panier et Commande destinés à un tunnel d’achat optimisé pour la conversion. Une boutique qui tourne sur un thème de blocs peut modifier l’ordre des éléments du panier, la mise en page de la page de commande ou l’apparence d’une fiche produit directement dans le Site Editor, sans ouvrir un ticket de développement pour un changement qui reste visuel. Une boutique sur thème classique conserve ces mêmes blocs Panier et Commande, mais leur habillage et leur position dans la page dépendent du code du thème ou du constructeur de pages installé.

La différence se voit surtout à l’usage quotidien : ajouter un bandeau de réassurance au-dessus du bouton d’achat, tester une nouvelle disposition de la page d’accueil pour une opération commerciale, ou adapter une fiche catégorie à une nouvelle gamme. Sur un thème de blocs, ce sont des tâches d’une personne autonome sur l’éditeur. Sur un thème classique, ce sont des tâches qui remontent, presque systématiquement, vers un prestataire.

Le thème classique reste pertinent dans certains cas

Basculer vers un thème de blocs n’est pas la bonne décision pour toutes les boutiques. Un thème classique bien maintenu, compatible avec la version en cours de WooCommerce et de PHP, ne présente pas de risque en soi : le risque vient de l’abandon de maintenance, pas du choix technique d’origine. Une boutique qui dépend d’un constructeur de pages tiers profondément intégré, ou de fonctions métier développées sur mesure (grille tarifaire par profil client, configurateur de produit), a rarement intérêt à migrer dans l’urgence : la migration touche alors non seulement l’habillage visuel, mais aussi ces développements spécifiques, avec un risque de régression sur des fonctions qui génèrent du chiffre d’affaires.

La question à se poser n’est donc pas « faut-il un thème de blocs ? » de façon générale, mais « qui, aujourd’hui, modifie la mise en page de la boutique, à quelle fréquence, et à quel coût ? ».

Un critère souvent oublié : la performance

Le choix du thème n’est pas seulement une question d’ergonomie de gestion : il pèse aussi sur les Core Web Vitals, les métriques que Google utilise pour évaluer la qualité d’expérience d’une page. Depuis le retrait du FID, ce sont le LCP (temps d’affichage de l’élément principal), l’INP (réactivité aux interactions) et le CLS (stabilité visuelle) qui comptent, mesurés au 75e percentile des visites réelles sur 28 jours. Le seuil « bon » de l’INP, tel que défini par la documentation officielle, est de 200 millisecondes ou moins.

Un thème classique alourdi par plusieurs extensions de construction de page accumule souvent du code et des scripts qui dégradent l’INP sur les pages produit ou le panier. Un thème de blocs, plus proche du cœur de WordPress et plus léger par construction, part avec un avantage sur ce point, mais il ne le garantit pas automatiquement : un thème de blocs surchargé de blocs tiers peut tout autant dépasser 200 millisecondes. Le format du thème ne remplace pas une mesure régulière sur les pages qui comptent réellement pour la conversion : fiche produit, panier, page de commande.

Comment trancher, en pratique

1. Lister qui modifie la mise en page aujourd’hui. Si c’est systématiquement un prestataire externe pour des changements purement visuels, le thème de blocs réduit ce coût récurrent.
2. Vérifier la dépendance à des développements spécifiques. Grille tarifaire, configurateur, connecteur ERP : ces éléments doivent être testés avant toute bascule, indépendamment du thème.
3. Mesurer les Core Web Vitals actuels sur la fiche produit, le panier et la page de commande, avant de décider si la question est le thème ou les extensions installées autour.
4. Tester le thème de blocs sur un environnement de préproduction avec le catalogue réel, pas un jeu de démonstration, avant toute mise en production.
5. Planifier la bascule hors période de forte activité commerciale, avec un plan de retour arrière si le tunnel d’achat se dégrade.

Cette méthode rejoint celle déjà recommandée pour mettre à jour WooCommerce sans casser la boutique : une bascule de thème se traite avec la même prudence qu’une montée de version, parce qu’elle touche aux mêmes zones sensibles, le panier et la commande. Le sujet est également à rapprocher de celui du passage du tunnel de commande en blocs plutôt qu’en shortcode, qui a précédé et préparé cette évolution vers les thèmes de blocs.

Le thème de blocs n’est pas non plus l’unique voie vers plus d’autonomie éditoriale : une boutique qui a déjà tranché en faveur d’une architecture découplée, comme évoqué dans l’arbitrage entre approche headless et thème classique, se pose une question différente, où le Site Editor de WordPress n’entre pas en jeu.

Ce qu’il faut retenir

• Un thème de blocs (FSE) permet de modifier gabarits et mise en page depuis le Site Editor, sans passer systématiquement par un développeur ; un thème classique garde ces modifications dans le code.
• WooCommerce documente les deux approches en parallèle, avec les mêmes blocs Panier et Commande dans les deux cas.
• Le thème n’est ni un gage automatique de bonne performance ni un risque en soi : ce qui compte est la maintenance active et la mesure régulière des Core Web Vitals (INP sous 200 ms au 75e percentile).
• Une bascule de thème se planifie comme une montée de version majeure : test en préproduction avec le catalogue réel, hors période de forte activité, avec un plan de retour arrière.