« L’export comptable ne correspond plus au total affiché sur la fiche commande, d’un centime, systématiquement. » Ce signalement, remonté après une montée de version PHP sur le serveur d’hébergement passée à PHP 8.3, sorti en novembre 2023, ne traite pas la configuration fiscale des taxes elle-même — le paramétrage des taux reste identique avant et après la montée de version. Le problème se situe ailleurs : dans la façon dont WooCommerce arrondit chaque ligne de commande avant d’en faire la somme.
Le mécanisme d’arrondi ligne par ligne
WooCommerce calcule la taxe de chaque ligne de commande séparément, l’arrondit au centime le plus proche, puis additionne les lignes arrondies pour obtenir le total final. Cette méthode, dite « arrondi par ligne », diffère de « l’arrondi au total », qui calcule d’abord la somme exacte avant d’arrondir une seule fois à la fin. Sur une commande à une seule ligne, les deux méthodes donnent presque toujours le même résultat. Sur une commande à plusieurs lignes avec des prix aux décimales peu rondes, un écart d’un centime peut apparaître entre les deux approches, un phénomène connu bien avant PHP 8.3 mais qui devient soudain visible après la montée de version.
Ce que change PHP 8.3
PHP 8.3 n’a pas modifié la formule mathématique de l’arrondi, mais a affiné la précision interne de certaines opérations en virgule flottante et le comportement de fonctions comme round() dans des cas limites où le nombre à arrondir se trouve exactement à la frontière entre deux centimes en représentation binaire. Un calcul qui produisait auparavant 12.345 représenté en interne comme 12.34499999999..., arrondi vers le bas à 12.34, peut désormais être représenté légèrement différemment et arrondir vers le haut à 12.35. Ce type de micro-différence, invisible sur une ligne isolée, se répercute et s’amplifie une fois sommée sur plusieurs lignes de commande.
// Comportement sensible à la précision flottante
$prix_ht = 12.345;
echo round( $prix_ht, 2 ); // le résultat peut varier selon la version PHP
Diagnostiquer un écart précis
Pour confirmer que le problème vient bien de ce mécanisme d’arrondi et non d’une configuration de taxe modifiée par erreur, il faut comparer le total recalculé manuellement ligne par ligne avec le total stocké en base pour une commande représentative :
wp eval '
$commande = wc_get_order( 12345 );
$total_recalcule = 0;
foreach ( $commande->get_items() as $item ) {
$total_recalcule += round( $item->get_total() + $item->get_total_tax(), 2 );
}
echo "Total recalculé : " . $total_recalcule . "\n";
echo "Total stocké : " . $commande->get_total() . "\n";
'
Corriger en fixant explicitement la précision
Le correctif le plus fiable ne consiste pas à espérer un comportement identique entre versions PHP, mais à forcer explicitement le mode d’arrondi utilisé par WooCommerce via l’option woocommerce_tax_round_at_subtotal, en la configurant de façon cohérente et documentée plutôt que de la laisser au comportement par défaut sensible aux micro-variations de précision flottante :
update_option( 'woocommerce_tax_round_at_subtotal', 'yes' );
Cette option force l’arrondi au niveau du sous-total global plutôt que ligne par ligne, ce qui élimine la sensibilité aux micro-écarts de précision flottante sur des commandes à lignes multiples, au prix d’un changement de méthode qu’il faut documenter auprès de la comptabilité avant de l’activer, car les totaux historiques ne seront pas recalculés rétroactivement.
Utiliser bcmath pour les calculs critiques
Pour un développement personnalisé qui manipule des totaux financiers, s’appuyer sur l’extension bcmath, qui effectue des calculs en précision arbitraire sans passer par la représentation flottante native de PHP, élimine complètement ce type d’écart, au prix d’un code légèrement plus verbeux :
echo bcadd( '12.345', '0.005', 2 ); // précision garantie, indépendante de la version PHP
- Vérifier la valeur de
woocommerce_tax_round_at_subtotalaprès toute montée de version PHP majeure. - Documenter la méthode d’arrondi choisie pour éviter toute confusion future avec la comptabilité.
- Envisager
bcmathpour tout calcul financier personnalisé sensible aux écarts de précision.
Un écart d’un centime qui apparaît après une montée de version technique, sans aucune modification de configuration métier, mérite toujours d’être documenté précisément avant d’être corrigé : la comptabilité doit savoir pourquoi les chiffres ont légèrement changé.
En résumé
L’écart d’un centime constaté après une montée vers PHP 8.3 n’est pas un bug de WooCommerce, mais la conséquence visible d’une sensibilité connue de longue date entre arrondi par ligne et arrondi au total, révélée par un changement subtil de précision flottante côté PHP. Fixer explicitement la méthode d’arrondi, plutôt que de subir le comportement par défaut, met fin durablement à ce type d’écart.
