# Concevoir une architecture de cache pour une boutique WooCommerce dans 50 pays

> Servir un catalogue localisé rapidement dans 50 pays impose de repenser la variation de cache par devise et par langue en périphérie de réseau.

- Auteur : Clément Hadrot
- Publié le : 2026-02-28
- Mis à jour le : 2026-02-28
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/architecture-cache-boutique-woocommerce-50-pays/

## L’essentiel

- La clé de cache doit inclure devise et langue, jamais l'adresse IP brute
- Le edge sert le HTML, l'API Store gère les prix personnalisés côté client
- Purger par segment plutôt que par page évite les tempêtes de cache

Comparez deux visiteurs qui ouvrent la même fiche produit à la même seconde : l'un depuis Osaka en yens, l'autre depuis Lisbonne en euros. Le HTML qu'ils reçoivent ne peut pas être identique, et pourtant les deux doivent arriver en moins de deux cents millisecondes si la boutique veut rester compétitive sur cinquante marchés à la fois. C'est précisément le problème que la mise en cache classique par URL ne sait pas résoudre.

Une boutique WooCommerce internationale ne sert pas un catalogue, elle sert des dizaines de variantes du même catalogue, et la périphérie de réseau doit savoir laquelle délivrer sans jamais interroger l'origine pour du contenu qui pourrait rester statique une heure de plus.

## Pourquoi la clé de cache par URL ne suffit plus

Un cache HTTP classique associe une réponse à une URL. Or la fiche produit à cinquante devises et une dizaine de langues ne correspond pas à cinquante URL distinctes dans la majorité des configurations WooCommerce multi-devise : le prix affiché dépend souvent d'un en-tête de devise, d'un cookie de préférence ou d'une géolocalisation IP résolue côté serveur. Servir du cache sur ce type de page suppose donc d'étendre la clé de cache au-delà de l'URL brute.

La périphérie doit varier sa clé sur des dimensions explicites : langue négociée, devise résolue et éventuellement zone de taxation, jamais sur l'adresse IP complète du visiteur, qui explose le nombre de variantes stockées sans bénéfice réel.

## Répartir le travail entre edge, cache applicatif et rendu dynamique

> L'essentiel à retenir : La clé de cache doit inclure devise et langue, jamais l'adresse IP brute ; Le edge sert le HTML, l'API Store gère les prix personnalisés côté client ; Purger par segment plutôt que par page évite les tempêtes de cache

L'architecture qui tient la charge sur cinquante pays répartit clairement les responsabilités :

```
Visiteur
   │
   ▼
Edge CDN ── clé = (url, langue, devise)
   │  hit ──────────────▶ HTML mis en cache (contenu, description, images)
   │  miss
   ▼
Origine WordPress ── rendu HTML localisé, prix de référence
   │
   ▼
API Store WooCommerce (JS) ── prix final, stock, promotions personnalisées
```

Le HTML statique — description produit, visuels, avis, structure de la page — reste parfaitement cachable en périphérie pour chaque combinaison langue/devise. Les éléments réellement dynamiques — prix exact avec remise personnalisée, disponibilité en temps réel, panier — sont récupérés après coup via l'API Store, en JavaScript, sans jamais invalider le HTML mis en cache.

## Éviter la combinatoire explosive des variantes

Cinquante pays multipliés par une dizaine de langues donnent, en théorie, plusieurs centaines de combinaisons pour une seule fiche produit. En pratique, il faut réduire la dimension avant qu'elle n'atteigne le cache : regrouper les pays qui partagent la même devise et la même langue de rendu dans un même segment de cache plutôt que de cacher pays par pays. Un visiteur belge francophone et un visiteur français partagent, la plupart du temps, exactement le même HTML localisé.

- Regrouper les zones par couple langue-devise réellement distinct, pas par pays administratif.
- Fixer un TTL plus long sur le contenu éditorial (48 heures) que sur les blocs promotionnels (5 minutes).
- Ne jamais varier le cache sur un paramètre d'URL de tracking marketing, qui multiplierait les variantes sans justification.

## Purger sans déclencher une tempête sur l'origine

Lorsqu'un prix change sur un produit vendu dans cinquante pays, purger toutes les variantes en même temps revient à envoyer, en quelques secondes, des centaines de requêtes simultanées vers l'origine WordPress au moment où le cache se reconstruit. La parade consiste à purger par vagues, segment de devise par segment de devise, avec un léger délai entre chaque groupe, ou à utiliser un mécanisme de revalidation en arrière-plan qui continue de servir l'ancienne version pendant que la nouvelle se régénère.

> Un cache qui protège l'origine pendant 99 % du trafic mais qui la met à genoux à chaque purge n'a résolu que la moitié du problème.

## Le cas particulier des taxes et de l'affichage légal

Certains marchés imposent un affichage de prix TTC, d'autres un affichage hors taxes avec mention séparée. Ce n'est pas un détail visuel : c'est une contrainte qui doit être tranchée avant la mise en cache, car elle change le HTML lui-même et non seulement une valeur affichée en JavaScript. Traiter ce choix comme une dimension de plus dans la clé de cache, au même titre que la langue, évite d'avoir à réécrire l'architecture une fois la boutique ouverte au premier marché avec obligation d'affichage TTC.

## Notre verdict

Une architecture de cache pour cinquante pays ne se pense pas comme une extension du cache habituel d'une boutique locale, elle se pense comme un système de segmentation à part entière : HTML localisé cachable agressivement en périphérie, données réellement dynamiques déportées vers l'API Store, purge par vagues, et taxation tranchée en amont plutôt qu'ajoutée après coup.