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.
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.
