Un prix affiché comme disponible alors que le bien vient d’être vendu la veille : c’est le symptôme qui a conduit à revoir entièrement la stratégie de mise en cache d’une agence immobilière traitant environ quarante mises à jour de prix ou de statut par jour sur un catalogue de six cents biens actifs.
La mise en cache de page complète, initialement en place pour accélérer le temps de chargement, resservait pendant plusieurs heures une version figée de chaque fiche, y compris aux robots d’exploration, ce qui posait un problème de fraîcheur bien plus grave pour un moteur de recherche que pour un visiteur humain habitué à actualiser la page en cas de doute.
Distinguer les données stables des données volatiles
Une fiche de bien immobilier mélange en réalité deux catégories de données très différentes dans leur rythme de mise à jour. D’un côté, des données stables : description du bien, surface, nombre de pièces, photographies, qui changent rarement une fois le bien mis en ligne. De l’autre, des données volatiles : prix, statut de disponibilité, date de dernière visite programmée, qui peuvent changer plusieurs fois par semaine, voire par jour lors d’une négociation active.
Mettre en cache l’ensemble de la page au même rythme revient à traiter ces deux catégories de la même façon, alors qu’elles n’ont rien de comparable en termes de criticité de fraîcheur.
Construire un cache par fragment plutôt qu’un cache de page entière
La solution retenue découpe la fiche de bien en deux zones de cache indépendantes, via les transients natifs de WordPress. La description longue et les photographies, coûteuses à générer mais rarement modifiées, restent en cache pendant vingt-quatre heures. Le bloc de prix et de disponibilité, lui, n’est jamais mis en cache et se recalcule à chaque affichage :
function bien_description_cachee( $bien_id ) {
$cle = 'description_bien_' . $bien_id;
$html = get_transient( $cle );
if ( false === $html ) {
$html = bien_generer_description_html( $bien_id );
set_transient( $cle, $html, DAY_IN_SECONDS );
}
return $html;
}
function bien_prix_disponibilite( $bien_id ) {
// jamais mis en cache : lecture directe à chaque affichage
$prix = get_post_meta( $bien_id, 'prix', true );
$statut = get_post_meta( $bien_id, 'statut', true );
return bien_generer_bloc_prix_html( $prix, $statut );
}Ce découpage garantit qu’un robot explorant la fiche à n’importe quel moment obtient toujours un prix et un statut à jour, quelle que soit l’ancienneté du cache appliqué à la description.
Purger le cache de façon ciblée plutôt que globale
Un correctif partiel restait insuffisant : lorsqu’une description était modifiée manuellement par un conseiller, il fallait invalider précisément le transient concerné, sans vider l’ensemble du cache du site, ce qui aurait provoqué un pic de charge serveur inutile en régénérant en masse des milliers de fragments non concernés :
function bien_purger_cache_description( $bien_id ) {
delete_transient( 'description_bien_' . $bien_id );
}
add_action( 'save_post_bien', 'bien_purger_cache_description' );Ce hook, déclenché uniquement à l’enregistrement du bien concerné, cible exactement le fragment devenu obsolète, laissant intact le cache de tous les autres biens du catalogue.
Effet sur le comportement des robots d’exploration
Après le déploiement de ce cache par fragment, l’analyse des journaux serveur a montré que Googlebot recevait systématiquement un bloc de prix et de disponibilité correspondant à l’état réel du bien au moment de l’exploration, y compris lorsque cette exploration survenait quelques minutes après une modification. Le taux de fiches signalées par les visiteurs pour un prix erroné a nettement diminué dans les semaines suivantes.
Limites de cette approche
Ce découpage suppose que le gabarit de fiche sépare clairement les deux zones dans son code, ce qui demande un effort de refactorisation sur un thème plus ancien où description et prix seraient historiquement générés par une seule fonction monolithique. L’effort initial de séparation reste toutefois limité comparé au gain obtenu en fiabilité de l’information affichée.
- Zone stable : description, photographies, caractéristiques du bien
- Zone volatile : prix, statut, disponibilité de visite
- Purge ciblée par identifiant de bien, jamais de purge globale automatique
Le cache n’est jamais un problème en soi. Le problème apparaît quand une seule politique de cache s’applique à des données dont le rythme de vie réel n’a rien de commun.
En résumé
Sur un catalogue immobilier actif, la mise en cache de page entière expose au risque réel de resservir une information de prix ou de disponibilité obsolète aux robots comme aux visiteurs. Séparer les fragments stables des fragments volatils, avec une purge ciblée par bien, permet de conserver les gains de performance du cache sans jamais sacrifier la fraîcheur des informations les plus sensibles de la fiche.
