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
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.
