Le signalement venait d’un client abonné à une box mensuelle de thé en vrac : sa facture de renouvellement affichait un sous-total légèrement différent de celui du mois précédent, alors qu’il n’avait rien changé à son abonnement. L’écart, quelques centimes seulement, aurait pu passer inaperçu s’il n’avait pas concerné plusieurs dizaines d’abonnés simultanément, tous depuis la même date : celle d’une mise à jour de WooCommerce Subscriptions appliquée le week-end précédent.
Ce cas illustre un type de bug particulièrement inconfortable à traiter : le montant réellement prélevé restait exact, seul le sous-total affiché sur la facture divergeait, ce qui a d’abord fait pencher l’équipe support vers un simple problème d’affichage sans gravité, avant qu’un examen plus attentif ne révèle une cause plus structurelle.
Symptôme : un écart systématique, mais minime
En comparant plusieurs factures de renouvellement avant et après la mise à jour, un motif est apparu : l’écart touchait uniquement les abonnements bénéficiant d’une remise fixe appliquée au moment de la souscription initiale, pas ceux souscrits au tarif plein. L’écart moyen constaté, 0,86 euro, correspondait presque exactement à la différence de TVA calculée sur le montant remisé par rapport au montant plein.
Diagnostic : l’ordre des hooks au renouvellement
WooCommerce Subscriptions recalcule certains éléments de la commande de renouvellement au moment de sa création, via le hook woocommerce_subscription_before_renewal_create, puis relance un calcul complet de taxe sur la nouvelle commande via calculate_taxes(). La mise à jour appliquée avait changé l’ordre relatif d’exécution entre le report de la remise fixe de l’abonnement d’origine et ce recalcul de taxe, sans que cela figure de façon très visible dans le journal des modifications de la version.
// Avant la mise à jour : la remise était reportée avant le calcul de taxe
add_action( 'woocommerce_subscription_before_renewal_create', 'reporter_remise_fixe', 5 );
add_action( 'woocommerce_subscription_before_renewal_create', 'recalculer_taxes', 20 );
// Après la mise à jour : l'ordre s'est inversé pour certains cas de figure
// woocommerce_subscription_before_renewal_create dispatchait recalculer_taxes en priorité 10
// avant que le hook personnalisé du client, en priorité 20, n'ait reporté la remise
La remise fixe du client était appliquée par un hook personnalisé, développé plusieurs années auparavant, qui supposait implicitement un ordre d’exécution jamais garanti explicitement par la documentation de WooCommerce Subscriptions. Ce hook s’exécutait toujours après le recalcul de taxe natif, avec une priorité par défaut de 10, ce qui fonctionnait par coïncidence sur les anciennes versions mais s’est retrouvé en concurrence différente après la mise à jour.
Le correctif
La correction n’a pas consisté à modifier le comportement de WooCommerce Subscriptions, mais à fiabiliser le hook personnalisé du client en explicitant sa priorité d’exécution, pour garantir qu’il s’applique systématiquement avant tout recalcul de taxe, quel que soit l’ordre interne du cœur à l’avenir :
add_action( 'woocommerce_subscription_before_renewal_create', 'reporter_remise_fixe', 1 );
add_action( 'woocommerce_subscription_before_renewal_create', function( $abonnement ) {
$abonnement->calculate_taxes();
$abonnement->calculate_totals();
}, 30 );Prévention pour la suite
- Ne jamais laisser une priorité de hook à sa valeur par défaut quand un ordre d’exécution précis est requis pour la cohérence des montants
- Documenter explicitement, dans un commentaire de code, la dépendance d’ordre entre deux hooks liés au même calcul
- Ajouter un test automatisé comparant le sous-total attendu d’un renouvellement remisé après chaque mise à jour majeure de WooCommerce Subscriptions
Ce que le journal de modification de la version ne disait pas
Le correctif de la version en cause portait officiellement sur un tout autre sujet, une amélioration de la précision des arrondis sur les renouvellements multi-devises. L’effet de bord sur l’ordre d’exécution des hooks n’était mentionné nulle part, ce qui rappelle qu’un correctif interne, même documenté pour un objectif précis, peut modifier des comportements adjacents non couverts par sa description officielle.
Une priorité de hook laissée par défaut n’est jamais une garantie d’ordre, c’est un pari implicite sur le comportement actuel du cœur, qui peut changer sans préavis à la prochaine mise à jour.
En résumé
Un écart de quelques centimes sur un sous-total d’abonnement peut sembler négligeable, mais il révèle souvent une dépendance implicite fragile entre des hooks dont l’ordre d’exécution n’a jamais été garanti explicitement. Fiabiliser cet ordre par une priorité explicite est un correctif discret, mais qui évite de revivre le même incident à chaque montée de version future.
