# Antipattern : un front headless recalcule des taxes déjà posées par WordPress

> Ce que l'on observe sur des projets e-commerce découplés d'artisans quand la duplication du calcul fiscal côté front crée des écarts avec WooCommerce.

- Auteur : Clément Hadrot
- Publié le : 2025-11-09
- Mis à jour le : 2025-11-09
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/antipattern-front-headless-recalcule-taxes-wordpress/

## L’essentiel

- Le calcul fiscal ne doit exister qu'à un seul endroit
- La Store API de WooCommerce reste la source unique de vérité
- Un affichage front qui recalcule finit toujours par diverger

Pourquoi deux totaux différents s'affichent-ils pour la même commande, à quelques centimes près, entre la page panier et l'e-mail de confirmation ? Ce symptôme, observé sur plusieurs boutiques d'artisans construites en headless au-dessus de WooCommerce, a toujours la même cause profonde : quelqu'un, quelque part dans le code du front, a recalculé une taxe déjà posée côté serveur.

Le réflexe part souvent d'une bonne intention. L'équipe front veut afficher le montant de la TVA en temps réel pendant que l'acheteur modifie les quantités dans son panier, sans attendre un aller-retour réseau complet. Elle réimplémente alors, en JavaScript, une version simplifiée des règles fiscales de WooCommerce. Ce raccourci fonctionne dans les cas simples, et diverge dès qu'un cas particulier apparaît.

## Ce qu'on observe concrètement sur ces projets

Sur les architectures auditées, la divergence apparaît systématiquement sur les mêmes points : un taux de TVA différent selon le pays de livraison, une exonération pour certaines catégories de produits, ou un arrondi appliqué différemment ligne par ligne plutôt que sur le total. Le front, codé une fois lors du lancement du projet, ne suit pas les évolutions ultérieures des règles fiscales configurées dans WooCommerce, ce qui crée un écart qui grandit avec le temps sans que personne ne le remarque immédiatement.

## Pourquoi ce recalcul est un problème, pas un détail d'affichage

> L'essentiel à retenir : Le calcul fiscal ne doit exister qu'à un seul endroit ; La Store API de WooCommerce reste la source unique de vérité ; Un affichage front qui recalcule finit toujours par diverger

Le risque ne se limite pas à un affichage inesthétique. Quand le total affiché au moment du paiement diffère, même légèrement, du total réellement facturé, l'acheteur peut légitimement contester la commande, et l'artisan se retrouve à justifier un écart qu'il n'a lui-même pas provoqué : la logique fiscale vit dans WooCommerce, configurée par son comptable ou son prestataire, pas dans le code front qu'il ne maîtrise pas.

## Ce qu'il faut faire à la place : la Store API comme source unique

WooCommerce expose une Store API pensée précisément pour les fronts découplés, capable de calculer un panier complet, taxes comprises, à chaque modification. Plutôt que de reproduire ces règles côté front, l'appel suivant renvoie un total déjà calculé selon la configuration fiscale réelle de la boutique :

```
fetch('/wp-json/wc/store/v1/cart', {
  method: 'GET',
  headers: { 'Content-Type': 'application/json' },
})
  .then((reponse) => reponse.json())
  .then((panier) => {
    // panier.totals.total_tax contient la taxe déjà calculée par WooCommerce
  });
```

Chaque modification de quantité déclenche un nouvel appel à cette API, ce qui retarde légèrement l'affichage par rapport à un calcul local instantané, mais garantit que le montant affiché correspond exactement à celui qui sera facturé.

## Le compromis pour garder une interface réactive

Pour limiter la sensation d'attente, certains projets affichent un total provisoire, clairement identifié comme tel (« total estimé, en cours de calcul »), pendant l'aller-retour vers la Store API, puis remplacent cet affichage par le total définitif dès la réponse reçue. Cette approche garde une interface réactive sans jamais afficher un montant fiscal calculé de façon autonome par le front.

- Ne jamais coder de taux de TVA en dur dans le front, même « temporairement ».
- Toujours afficher le total définitif à partir de la réponse de la Store API, jamais d'un calcul local.
- Prévoir un état de chargement explicite plutôt qu'un faux total instantané.

## Quoi faire si le recalcul existe déjà en production

Sur les projets déjà en production avec ce défaut, la correction consiste à remplacer progressivement chaque affichage recalculé par un appel à la Store API, en commençant par la page panier, la plus visible, avant de traiter les emails transactionnels et les pages de confirmation, souvent générées par un template séparé qui reproduit le même antipattern.

> Un total qui rassure l'acheteur en temps réel mais qui ment de quelques centimes reste un mensonge, même petit, même involontaire.

## Ce que ça ne couvre pas

Cette question ne concerne que le calcul fiscal lui-même ; la gestion des devises multiples, avec ses propres règles d'arrondi et de conversion, pose des problèmes différents qui méritent un traitement séparé.

### Le signal qui doit alerter une équipe technique

Un indice fiable de cet antipattern en cours d'installation : la présence, quelque part dans le code front, d'une constante nommée `TAUX_TVA` ou d'un tableau de taux par pays codé en dur. Dès qu'un tel élément apparaît dans une revue de code, la bonne réaction consiste à le remplacer par un appel à la Store API avant même de chercher à comprendre pourquoi il a été introduit : la justification, presque toujours liée à un besoin d'affichage instantané, ne compense jamais le risque de divergence qui en découle à moyen terme.