# Transients contre cache objet : où mémoriser un flux de disponibilité fournisseur dans WooCommerce

> Le flux XML d'un fournisseur change toutes les dix minutes. Transient ou cache objet : lequel choisir pour ne pas saturer wp_options ni servir du stock périmé ?

- Auteur : WordPress Développement
- Publié le : 2022-03-24
- Mis à jour le : 2022-03-24
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/transients-cache-objet-flux-disponibilite-fournisseur-woocommerce/

## L’essentiel

- set_transient() persiste sans dépendance externe
- Un cache objet dédié évite d'alourdir wp_options
- Le bon choix dépend surtout de la fréquence de rafraîchissement

`get_transient( 'flux_fournisseur_disponibilite' )` : cette ligne revient dans la moitié des connecteurs WooCommerce que j'ai audités ces derniers mois. Elle a l'air anodine, mais elle cache un vrai choix d'architecture dès qu'un fournisseur pousse un flux de disponibilité toutes les dix ou quinze minutes.

Le réflexe le plus courant consiste à stocker ce flux dans un transient, parce que la fonction est native, documentée et qu'elle fonctionne dès l'installation. Le problème apparaît quand le catalogue grossit ou que la fréquence de rafraîchissement augmente : la table `wp_options` commence à souffrir, et un objet mal sérialisé peut y rester bien plus longtemps que prévu.

## Ce que fait réellement un transient

Un transient WooCommerce n'est, à la base, qu'une paire d'entrées dans `wp_options` : la valeur elle-même, préfixée par `_transient_`, et sa date d'expiration, préfixée par `_transient_timeout_`. Sans cache objet persistant actif, chaque appel à `get_transient()` se traduit par une requête SQL contre cette table. Si l'entrée a expiré, WordPress la supprime et renvoie `false`, ce qui oblige le code appelant à régénérer la donnée à la volée.

Cette mécanique convient très bien à un flux qui change toutes les dix ou vingt minutes sur un catalogue de quelques centaines de références : la table reste petite, et la fréquence de lecture n'a rien d'excessif.

## Le vrai coût apparaît avec un cache objet absent

> L'essentiel à retenir : set_transient() persiste sans dépendance externe ; Un cache objet dédié évite d'alourdir wp_options ; Le bon choix dépend surtout de la fréquence de rafraîchissement

Sur un hébergement sans Redis ni Memcached, chaque page produit qui vérifie la disponibilité déclenche une requête sur `wp_options`. Multipliez cela par un catalogue de plusieurs milliers de références et par un trafic soutenu, et la table gonfle, se fragmente, et ralentit les requêtes voisines qui portent sur les réglages du site.

Voici comment je pose généralement le choix avec un client :

- Moins de 500 références et rafraîchissement toutes les heures : un transient classique suffit largement.
- Catalogue de plusieurs milliers de références avec un flux toutes les dix minutes : un cache objet devient nécessaire pour éviter la pression sur `wp_options`.
- Disponibilité vérifiée à chaque affichage de fiche produit à fort trafic : privilégier un cache objet avec une durée de vie courte plutôt qu'un transient rechargé en boucle.

## Un cache objet persistant change la donne

Avec un cache objet persistant (Redis ou Memcached configuré via un plugin de type object-cache.php), les fonctions `wp_cache_get()` et `wp_cache_set()` deviennent les bonnes candidates. Elles ne touchent jamais `wp_options` : la donnée vit en mémoire, avec une expiration gérée par le serveur de cache lui-même.

Fait important à connaître : sans cache objet persistant configuré, WordPress utilise un cache objet en mémoire non persistant, réinitialisé à chaque requête HTTP. Autrement dit, `wp_cache_set()` sans backend persistant ne sert à rien pour un flux qui doit survivre entre deux visites : il faut alors se rabattre sur un transient, ou installer un vrai backend de cache objet.

### Exemple de bascule conditionnelle

```
function get_disponibilite_fournisseur( $sku ) {
    if ( wp_using_ext_object_cache() ) {
        $valeur = wp_cache_get( 'dispo_' . $sku, 'flux_fournisseur' );
        if ( false === $valeur ) {
            $valeur = recuperer_disponibilite_distante( $sku );
            wp_cache_set( 'dispo_' . $sku, $valeur, 'flux_fournisseur', 10 * MINUTE_IN_SECONDS );
        }
        return $valeur;
    }

    $valeur = get_transient( 'dispo_' . $sku );
    if ( false === $valeur ) {
        $valeur = recuperer_disponibilite_distante( $sku );
        set_transient( 'dispo_' . $sku, $valeur, 10 * MINUTE_IN_SECONDS );
    }
    return $valeur;
}
```

La fonction `wp_using_ext_object_cache()` permet justement de détecter si un backend externe est actif, et donc d'adapter le comportement sans dupliquer la logique métier ailleurs dans le connecteur.

## Cas particulier : plusieurs milliers de SKU en une seule passe

Quand le flux fournisseur porte sur un catalogue entier plutôt que sur une référence isolée, mieux vaut éviter de multiplier les transients un par un. Je préfère alors sérialiser l'ensemble du flux dans une seule entrée, avec une clé de version dans le nom (par exemple `flux_fournisseur_v3`), ce qui permet d'invalider proprement sans dépendre de l'expiration naturelle.

| Critère | Transient | Cache objet externe |
| --- | --- | --- |
| Persistance sans configuration | Oui, via wp_options | Non, nécessite Redis ou Memcached |
| Impact sur wp_options | Direct, proportionnel au volume | Aucun |
| Vitesse de lecture | Correcte pour un petit volume | Nettement supérieure en mémoire |
| Simplicité de mise en œuvre | Aucune dépendance | Nécessite un backend installé |

> Sur un projet où l'hébergement ne garantit pas de cache objet persistant, je code toujours la bascule automatique décrite plus haut : le connecteur fonctionne partout, et profite du cache objet dès qu'il est disponible, sans ligne de configuration supplémentaire.

## Notre verdict

Le transient reste le choix par défaut le plus raisonnable pour un flux fournisseur modeste, parce qu'il ne demande aucune infrastructure supplémentaire. Dès que le catalogue dépasse quelques milliers de références ou que la fréquence de rafraîchissement descend sous le quart d'heure, le cache objet externe devient nécessaire pour préserver la table `wp_options` et la réactivité générale du site.

La bonne pratique consiste rarement à choisir l'un contre l'autre définitivement : coder une bascule conditionnelle, comme dans l'exemple ci-dessus, permet au même connecteur de fonctionner correctement sur un hébergement mutualisé comme sur une infrastructure équipée d'un cache objet persistant.