WooCommerce 11.2.1 corrige deux régressions du passage en caisse

WooCommerce 11.2.1 est disponible depuis le 9 octobre 2026. Cette version de maintenance touche une étape que les clients doivent pouvoir terminer sans hésitation : le passage en caisse. Les notes officielles identifient deux régressions de 11.2.0, concernant des adresses personnalisées dans le paiement classique et certains codes postaux dans le paiement à blocs. L’éditeur ne la présente ni comme une mise à jour de sécurité ni comme une mise à jour de la base de données.

Le passage en caisse est la page où le client fournit les informations nécessaires et confirme son achat. WooCommerce en propose notamment une forme classique et une forme composée de blocs. Les deux correctifs ne concernent pas exactement les mêmes parcours : savoir quelle forme utilise votre boutique aide à demander la bonne vérification. Une personnalisation visuelle de la page ne suffit pas à identifier son fonctionnement ; le prestataire peut le confirmer dans l’installation.

Reconnaître le parcours concerné

Situation	Correction annoncée
Paiement classique avec certains champs d’adresse retirés	Retour au comportement 11.1 pour la transmission des adresses lors de l’actualisation du récapitulatif.
Paiement à blocs et certains formats postaux internationaux	Acceptation rétablie pour les formats concernés, dont les codes argentins à quatre chiffres sans lettre de province.

Sur le paiement classique, une boutique qui retire des champs d’adresse pouvait voir apparaître une demande d’adresse bloquante, une taxe non appliquée ou la disparition de modes de livraison. WooCommerce précise le périmètre du correctif. Cela ne signifie pas que tous les abandons de panier venaient de ce défaut. La version installée et les personnalisations de l’adresse sont les premiers éléments à rapprocher du symptôme observé.

Le second correctif concerne des formats du Salvador, de Saint-Vincent-et-les-Grenadines et des îles Vierges britanniques, en plus de l’Argentine. Une boutique française qui ne dessert pas ces destinations peut être peu concernée par cette partie. Si elle les accepte, un code rejeté n’est pas seulement une gêne de saisie : il peut empêcher le client d’aller au bout du parcours. Il faut vérifier les formats réellement utiles aux zones de vente, sans désactiver globalement la validation.

Tester ce qui se passe après la saisie

Faites préparer une copie de test avec les mêmes réglages de taxes, de livraison et de personnalisation que la boutique, en évitant d’y exposer des données clients. Demandez une sauvegarde et un retour arrière adaptés avant l’intervention. Commencez par reproduire le parcours concerné, puis refaites-le avec le correctif : remplir le formulaire ne suffit pas, car le récapitulatif peut encore changer après le choix du pays ou du mode de livraison.

Pour un exemple hypothétique de vente de service sans expédition, contrôlez que le formulaire simplifié laisse terminer la commande et que les informations nécessaires à la facturation restent présentes. Pour une vente de produits physiques, changez une adresse de test puis vérifiez les modes proposés, les frais et les taxes attendues. Comparez ensuite le total affiché à celui enregistré dans la commande de test. Utilisez un moyen de paiement en mode test et neutralisez les envois réels : une recette ne doit pas produire d’achat ou de message client involontaire.

Conservez un relevé court : version, type de paiement, cas essayé, résultat attendu et résultat observé. Ajoutez un parcours habituel sans personnalisation pour repérer un éventuel effet de bord. L’absence de migration de base annoncée ne dispense pas de cette vérification des extensions de paiement et de livraison : le correctif central et leur compatibilité sont deux points différents.