Le panier est rempli. Le client indique son adresse, puis modifie une information de facturation. Le récapitulatif se recharge… et les modes de livraison disparaissent. Sur une boutique, ce scénario peut ressembler à une panne du transporteur. Depuis WooCommerce 11.2.0, il peut aussi correspondre à une régression bien précise : un checkout classique dont certains champs d’adresse ont été supprimés par une personnalisation.
Cette scène est illustrative, pas le résultat d’un audit client. Elle décrit néanmoins l’un des symptômes documentés par WooCommerce. La version 11.2.1, publiée le 9 octobre 2026, corrige ce cas ainsi qu’un problème distinct de validation de codes postaux dans le bloc de commande. La note officielle indique qu’il ne s’agit pas d’une mise à jour de sécurité et qu’elle ne comporte pas de mise à jour de base de données. [Source 1]
Pour une boutique française, l’enjeu est donc de qualifier le parcours réellement utilisé avant de choisir le test. Une page de commande qui paraît normale au premier affichage peut encore perdre ses informations au recalcul. À l’inverse, un incident de livraison n’est pas automatiquement imputable à cette version.
Commencez par ces trois informations, pas par le transporteur
Demandez au mainteneur la version de WooCommerce effectivement installée, le type de checkout et la liste des personnalisations d’adresse. Ce sont les trois coordonnées du diagnostic.
Le checkout classique et le bloc de commande ne sont pas deux noms pour la même implémentation. Le premier peut être présent via le shortcode de commande ; le second utilise les blocs WooCommerce. Un thème au design récent ne permet pas de trancher. Il faut vérifier la page utilisée et les éventuelles extensions qui la remplacent. La documentation officielle prévient d’ailleurs qu’une partie des filtres de personnalisation du checkout classique ne s’applique pas au bloc. [Source 2]
La version doit être relevée sur la bonne installation : production ou copie de test, avec la date du constat. Un message ancien annonçant une mise à jour ne remplace pas ce relevé. Si votre boutique n’est pas en 11.2.0, ne cherchez pas à la ramener artificiellement à cette version pour reproduire l’incident. Comparez le comportement actuel au périmètre documenté et préparez le prochain changement avec le mainteneur.
Enfin, « nous avons simplifié le formulaire » ne suffit pas à décrire la personnalisation. Un champ peut être masqué visuellement, rendu facultatif ou retiré des données définies par le serveur. Ces situations ne sont pas équivalentes. Faites identifier le thème enfant, le module ou le code sur mesure qui intervient, ainsi que le champ concerné et la raison de son retrait. Il ne s’agit pas de supprimer toutes les adaptations : il s’agit de savoir laquelle est à tester.
Ce que 11.2.1 répare — et ce que l’annonce ne dit pas
Le récapitulatif du checkout classique perd des données utiles
La note de version cite deux filtres : woocommerce_billing_fields et woocommerce_default_address_fields. Avec WooCommerce 11.2.0, les boutiques qui les utilisent pour retirer des champs d’adresse peuvent rencontrer le message « Please enter an address to continue. », une taxe non appliquée ou des options de livraison qui disparaissent. Le correctif rétablit le comportement de la version 11.1 concernant l’envoi des données d’adresse lorsque le récapitulatif de commande se rafraîchit. [Source 1]
Le moment du rafraîchissement est essentiel. Contrôler seulement que le formulaire s’affiche, que les champs sont remplissables ou que le premier tarif apparaît ne couvre pas le défaut décrit. Le test doit faire évoluer l’adresse ou un élément pertinent du panier, attendre le recalcul et vérifier ce qui reste disponible ensuite.
Cela ne signifie pas que tous les utilisateurs de WooCommerce 11.2.0 sont touchés, ni que toute extension de champs est incompatible. Cela ne prouve pas non plus qu’une taxe absente provient de ce bug : la configuration fiscale, le produit et la destination restent à examiner. La note fournit une piste ciblée, pas un diagnostic à distance de votre boutique.
Le bloc de commande rejette certains formats postaux
Le second correctif concerne notamment les codes postaux argentins sans lettre de province, comme 1213, ainsi que des formats du Salvador, de Saint-Vincent-et-les-Grenadines et des îles Vierges britanniques que la version 11.2.0 rejetait. [Source 1]
La France n’est pas citée parmi les pays de ce correctif. Il serait donc trompeur de présenter 11.2.1 comme la réparation d’un défaut général des codes postaux français. Une boutique lyonnaise qui vend uniquement en France n’a pas à ajouter un scénario argentin artificiel à sa recette. Si elle vend effectivement vers l’un des pays concernés, ce parcours devient en revanche pertinent, avec une adresse de test cohérente et un mode de livraison réellement proposé sur ce marché.
Les deux corrections se vérifient ainsi différemment : des données d’adresse lors du recalcul pour le checkout classique ; l’acceptation de formats postaux déterminés pour le bloc. Les confondre produit une recette rassurante sur le papier, mais mal ciblée.
Une recette courte, construite autour de vos vraies ventes
La méthode suivante est notre proposition de contrôle, pas un protocole imposé par WooCommerce. Elle se réalise sur une copie de test maîtrisée, avec les paiements en mode test et sans déclencher d’expédition, de facture commerciale ou d’envoi à un client réel. Les connecteurs vers l’ERP, le transporteur et les e-mails doivent être isolés ou configurés pour cet usage. Une copie de production non isolée peut encore produire des effets réels.
Avant le changement, relevez les versions du cœur, du thème et des extensions qui modifient la commande. Conservez la sauvegarde et la procédure de retour convenues avec le mainteneur. « Pas de mise à jour de base de données » décrit cette livraison WooCommerce ; cela ne dispense pas de ces précautions et ne garantit pas qu’une autre extension, mise à jour en même temps, ne modifiera rien.
Choisissez ensuite quelques paniers représentatifs. Le bon volume de test dépend des règles commerciales, pas du nombre de produits dans le catalogue. Pour une boutique vendant des objets physiques en France, le premier panier doit utiliser une destination française desservie et une règle de livraison connue. Si vous proposez aussi un produit virtuel, testez-le séparément : l’absence de livraison peut y être normale et ne doit pas être classée comme panne.
| Cas à retenir si pertinent | Manipulation à reproduire | Résultat à comparer avant et après |
|---|---|---|
| Produit physique, checkout classique personnalisé | Saisir une adresse française desservie, puis modifier un élément qui déclenche le recalcul | Livraison disponible selon les règles prévues, taxes et total attendus, commande de test possible |
| Facturation et livraison distinctes | Activer l’adresse de livraison différente, la compléter puis la modifier | Bonne destination utilisée, aucun blocage d’adresse injustifié, frais cohérents |
| Produit virtuel vendu par la boutique | Refaire le parcours avec les champs réellement conservés | Absence de livraison attendue, traitement fiscal prévu et commande de test cohérente |
| Client connecté avec adresse enregistrée | Charger l’adresse, la modifier et attendre le recalcul | Aucun résultat différent inexpliqué par rapport au parcours invité |
| Bloc de commande vers un pays cité par le correctif | Saisir un format postal concerné sur un marché réellement desservi | Format accepté, puis contrôles habituels de livraison, taxe et total |
Pour chaque ligne retenue, notez la version, le type de checkout, les champs retirés, le panier, la destination, l’action déclenchant le recalcul et le résultat. Gardez une capture avant/après expurgée, avec une référence de commande de test lorsque le parcours aboutit. Ajoutez « non testé » lorsqu’un cas n’a pas été exécuté : une case vide ne doit pas devenir un succès implicite.
Le point le plus utile est souvent la comparaison entre le résultat attendu et le résultat constaté. Une taxe égale à zéro n’est pas toujours une erreur ; elle peut être cohérente avec la configuration applicable au cas testé. Une livraison gratuite peut également être prévue. Faites fixer les montants attendus par la personne responsable des règles de la boutique, et non déduire une règle fiscale du seul affichage du checkout. Si nécessaire, faites valider le traitement fiscal séparément.
Cette précision relève aussi de la conception d’une boutique e-commerce : retrait sur place, produits virtuels, livraison à une autre adresse et ventes internationales ne suivent pas nécessairement le même parcours. Un formulaire plus court n’est utile que s’il conserve les données nécessaires aux opérations réellement proposées.
Ne vous arrêtez pas au message qui a disparu
Après application du correctif sur la copie, reprenez les mêmes scénarios, avec les mêmes produits et les mêmes règles. Si vous changez simultanément le thème, les extensions de livraison et les paramètres fiscaux, il devient difficile d’attribuer l’amélioration à un changement précis. Limitez les changements simultanés lorsque c’est possible ; documentez les autres lorsqu’ils sont nécessaires.
Le parcours n’est pas validé uniquement parce que « Please enter an address to continue. » n’apparaît plus. Vérifiez que la commande de test contient la bonne adresse, la bonne ligne de livraison et les montants attendus. Comparez le récapitulatif visible au moment de valider avec la commande enregistrée. Un écran réparé et une commande incorrecte restent un échec commercial.
Une passe mobile est utile si elle correspond à vos usages : formulaire lisible, choix de livraison conservé après modification, total compréhensible avant validation. Ce contrôle complète le test fonctionnel ; il ne démontre pas à lui seul que la régression est corrigée dans tous les parcours. De même, un paiement réussi dans un environnement de test ne certifie pas le fonctionnement de tous les moyens de paiement en production.
Si le défaut persiste, conservez le cas minimal qui échoue et sa configuration. Ne supprimez pas aveuglément les validations d’adresse ou de taxe pour faire passer la commande. Le mainteneur pourra distinguer le défaut documenté d’une autre personnalisation, d’une règle de zone ou d’un problème de connecteur. Une maintenance technique suivie doit permettre cette remontée précise, plutôt qu’une succession de mises à jour sans comparaison.
Le passage en production reste une opération distincte : fenêtre adaptée à l’activité, sauvegarde vérifiée, retour possible et contrôle après intervention. Un retour arrière doit tenir compte des commandes créées depuis le changement ; restaurer une ancienne base sans les réconcilier n’est pas un simple bouton d’annulation.
Les questions qui reviennent sur ce correctif
Faut-il réintroduire tous les champs d’adresse ?
Pas sur la seule base de cette annonce. Le correctif vise justement un comportement rencontré avec des champs retirés. Commencez par identifier les informations nécessaires à votre facturation, à vos taxes et à votre livraison, puis testez la personnalisation existante. Rendre tous les champs obligatoires peut masquer le symptôme tout en dégradant inutilement le parcours.
Une boutique déjà en 11.2.1 doit-elle refaire la mise à jour ?
Non, pas pour produire une preuve. Relevez sa version actuelle et exécutez les scénarios pertinents dans un cadre de test. Si le problème demeure, recherchez sa cause avec ces observations. Cet article porte sur le correctif publié le 9 octobre ; il ne recommande pas de revenir à cette version si une version ultérieure adaptée est déjà installée.
L’absence de migration de base rend-elle le correctif sans risque ?
Non. La note décrit l’absence de mise à jour de base de données pour cette version, pas une garantie de compatibilité avec votre thème, vos modules et votre code. Le checkout touche à la vente, à l’adresse et aux montants : une recette proportionnée reste justifiée.
Peut-on en déduire combien de commandes ont été perdues ?
Non. La présence de WooCommerce 11.2.0 ou d’une personnalisation ne mesure pas une perte de ventes. Il faudrait des observations datées du parcours et des données exploitables, en distinguant les abandons habituels d’un blocage technique. Aucun chiffre de conversion ou de chiffre d’affaires n’est déduit ici du correctif.
Faire vérifier le parcours qui compte pour votre boutique
Si votre checkout a été simplifié et que vous avez observé une livraison disparue, un message d’adresse ou un montant inhabituel, contactez 1Design pour cadrer un diagnostic ciblé. Transmettez l’URL publique, la version relevée, le type de parcours s’il est connu et une description expurgée du symptôme — sans identifiants ni données clients.
Le périmètre proposé porte sur un checkout et jusqu’à cinq scénarios convenus, avec inventaire des personnalisations pertinentes et matrice de résultats. L’objectif est de distinguer une régression reproduite, un parcours conforme et un cas encore non vérifié. Le devis, les accès nécessaires et l’environnement de test sont cadrés avant intervention ; corrections, déploiement et investigation de connecteurs sont définis séparément. Ce diagnostic n’est ni une garantie de conversion ni un audit fiscal.
Sources et périmètre de vérification
- WooCommerce 11.2.1 : note de version officielle, 9 octobre 2026. Deux corrections, versions concernées, absence de correctif de sécurité et de mise à jour de base de données. Relue le 16 octobre 2026.
- WooCommerce : personnaliser les champs de commande avec actions et filtres. Documentation technique sur les filtres et leur périmètre ; elle distingue notamment checkout classique et bloc. Consultée le 16 octobre 2026 via la redirection de la documentation historique.
Les scénarios de recette et le périmètre de diagnostic sont des recommandations éditoriales de 1Design. Aucune boutique cliente n’a été testée pour cet article.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?