# WooCommerce Blocks : ce que changent les blocs Panier et Paiement stables

> Les blocs Panier et Paiement quittent le statut expérimental : voici concrètement ce qui change pour les thèmes classiques et les personnalisations existantes.

- Auteur : Clément Hadrot
- Publié le : 2023-11-23
- Mis à jour le : 2023-11-23
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/woocommerce-blocks-panier-paiement-stables/

## L’essentiel

- Deux shortcodes historiques marqués comme obsolètes
- Un rendu en React côté front, plus en PHP classique
- Les hooks de template ne s'appliquent plus de la même façon

Pendant longtemps, activer les blocs Panier et Paiement de WooCommerce Blocks relevait de l'expérimentation : une case à cocher dans les réglages, un avertissement, et la certitude que certaines extensions de paiement ne fonctionneraient pas correctement. Ce n'est plus le cas. Avec la stabilisation de ces deux blocs, WooCommerce referme un chapitre ouvert depuis plusieurs années et pousse tout l'écosystème vers un nouveau modèle de rendu.

Pour un développeur qui maintient des boutiques en production, la question n'est pas de savoir s'il faut migrer un jour, mais de comprendre ce qui casse concrètement si l'on bascule maintenant, et ce qui continue de fonctionner sans y toucher. C'est l'objet de cet article : un classement par impact, du plus visible au plus discret.

## Le changement le plus visible : la fin du rendu PHP classique côté front

Les shortcodes historiques `[woocommerce_cart]` et `[woocommerce_checkout]` continuent de fonctionner, mais WooCommerce les considère désormais comme l'ancienne génération. Les nouveaux blocs `woocommerce/cart` et `woocommerce/checkout` ne génèrent plus leur balisage via les templates PHP du dossier `templates/cart/` et `templates/checkout/` : ils s'appuient sur des composants React hydratés côté client, alimentés par les données de l'API Store.

Conséquence directe : toute personnalisation qui reposait sur une surcharge de template dans un thème enfant, par exemple `woocommerce/cart/cart-totals.php`, n'a plus aucun effet une fois les blocs actifs. Ce fichier n'est simplement plus appelé.

## Les hooks d'action classiques perdent leur portée

C'est le point qui surprend le plus les équipes en migration : des hooks comme `woocommerce_before_cart_table`, `woocommerce_checkout_before_customer_details` ou `woocommerce_review_order_before_payment` ne se déclenchent plus dans le contexte des blocs, puisqu'il n'y a plus de rendu PHP séquentiel à ce niveau. Les personnalisations construites sur ces hooks — un bandeau promotionnel inséré au-dessus du tableau du panier, une mention légale ajoutée avant le récapitulatif — disparaissent silencieusement, sans erreur ni avertissement.

> L'essentiel à retenir : Deux shortcodes historiques marqués comme obsolètes ; Un rendu en React côté front, plus en PHP classique ; Les hooks de template ne s'appliquent plus de la même façon

Le remplacement passe par les *slots* exposés par le bloc lui-même, un système d'emplacements nommés que les extensions peuvent peupler via l'API `@woocommerce/blocks-checkout`. Le mécanisme est plus rigide que les hooks WordPress classiques : chaque emplacement a un nom précis et un jeu de props défini, on ne peut plus injecter du contenu à un endroit arbitraire du DOM.

## Ce qui, à l'inverse, ne change presque rien

Les extensions de paiement basées sur l'API `WC_Payment_Gateway` classique restent compatibles, à condition d'avoir enregistré leur intégration au bloc Paiement via `IntegrationRegistry` et un script d'enregistrement côté client. Beaucoup de passerelles majeures avaient déjà fait ce travail pendant la longue phase expérimentale des blocs, justement en prévision de cette stabilisation.

- Les taxes, remises et calculs de frais de port restent gérés côté serveur, inchangés
- Les e-mails transactionnels (`WC_Email`) ne sont pas concernés
- Les webhooks et l'API REST classique continuent de fonctionner à l'identique

## Un audit avant bascule, pas une bascule à l'aveugle

Nous recommandons, avant toute activation en production, de lister systématiquement les hooks liés au panier et au paiement présents dans le thème et les extensions maison, puis de vérifier lesquels appartiennent au flux désormais géré par React. Un grep sur `woocommerce_before_checkout`, `woocommerce_after_cart` et leurs variantes donne un premier périmètre exploitable en une petite heure.

### Un test terrain simple

Sur l'environnement de préproduction d'un client vendant du mobilier, activer les blocs a fait disparaître un encart de réassurance affiché juste avant le bouton de paiement, sans aucune erreur PHP ni message dans les journaux. Seul un test visuel manuel a permis de le repérer, ce qui confirme qu'un audit de code ne suffit pas toujours : une recette visuelle complète du tunnel d'achat reste indispensable après la bascule.

> Une migration de template invisible dans les logs est la plus dangereuse de toutes : elle ne casse rien techniquement, elle efface juste un morceau de l'expérience client sans le signaler.

## Faut-il basculer dès maintenant ?

Pour une boutique neuve, oui, sans hésiter : partir directement sur les blocs stables évite d'accumuler une dette de migration. Pour une boutique existante fortement personnalisée sur le tunnel de commande, mieux vaut planifier la bascule comme un chantier à part entière, avec son propre plan de test, plutôt que de la traiter comme une simple mise à jour de routine.

## Notre verdict

La stabilisation des blocs Panier et Paiement est une bonne nouvelle pour l'écosystème à moyen terme : rendu plus rapide, expérience plus cohérente avec l'éditeur de site. Mais elle transforme silencieusement toute boutique fortement hookée en projet de migration à part entière. Le vrai risque n'est pas technique, il est humain : oublier de recetter le tunnel de commande dans son intégralité après le changement.