# Boulangerie en réseau : préchauffer le cache à chaque mise à jour des horaires

> Un réseau de boulangeries met à jour ses horaires plusieurs fois par jour selon les fournées et les ruptures de stock. Comment préchauffer le cache de chaque boutique sans purger tout le site.

- Auteur : WordPress Développement
- Publié le : 2021-04-08
- Mis à jour le : 2021-04-08
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/boulangerie-reseau-prechauffer-cache-horaires/

## L’essentiel

- Chaque boutique dispose de sa propre page horaires, modifiée indépendamment
- Une purge globale à chaque mise à jour dégraderait le reste du site inutilement
- Un préchauffage ciblé par identifiant de boutique limite l'impact au strict nécessaire

Vingt-trois mises à jour d'horaires par jour, en moyenne, réparties sur l'ensemble d'un réseau de boulangeries artisanales : une rupture de pain aux céréales ici, une fermeture anticipée pour cause de four en maintenance là, une fournée supplémentaire annoncée ailleurs. Chaque boutique dispose de sa propre page horaires sur le site du réseau, modifiée indépendamment des autres par le gérant concerné, souvent depuis un téléphone entre deux services.

Le site utilisait un cache de page classique, avec une purge globale déclenchée à chaque modification de contenu. Résultat : chaque mise à jour d'horaires d'une seule boutique invalidait le cache de l'ensemble du site, y compris les pages des vingt-deux autres boutiques et les pages de recettes, pourtant totalement indépendantes du changement effectué.

## Le coût caché d'une purge trop large

Vingt-trois purges globales par jour signifiaient que la quasi-totalité du site repartait en permanence d'un cache froid, chaque visiteur risquant de tomber sur une page en cours de régénération plutôt que sur une version déjà en cache. Sur un site à trafic modéré mais constant tout au long de la journée, cette situation maintenait un taux de pages servies depuis le cache anormalement bas pour un site dont le contenu changeait, en réalité, assez peu dans l'absolu.

Le vrai problème n'était donc pas la fréquence des mises à jour, mais leur portée : chaque changement, localisé à une seule boutique, provoquait un effet global disproportionné.

## La stratégie : un préchauffage ciblé par boutique

La correction a consisté à remplacer la purge globale par une invalidation limitée aux pages réellement concernées par la mise à jour : la page horaires de la boutique modifiée, sa page fiche complète, et la page d'accueil listant les boutiques ouvertes à l'instant présent.

> L'essentiel à retenir : Chaque boutique dispose de sa propre page horaires, modifiée indépendamment ; Une purge globale à chaque mise à jour dégraderait le reste du site inutilement ; Un préchauffage ciblé par identifiant de boutique limite l'impact au strict nécessaire

```
function reseau_purger_et_prechauffer_boutique( $boutique_id ) {
    $urls = array(
        get_permalink( $boutique_id ),
        home_url( '/boutiques/' . get_post_field( 'post_name', $boutique_id ) . '/horaires/' ),
        home_url( '/' ), // liste des boutiques ouvertes
    );

    foreach ( $urls as $url ) {
        reseau_purger_cache_url( $url );
        wp_remote_get( $url ); // préchauffage immédiat
    }
}

add_action( 'reseau_horaires_mis_a_jour', 'reseau_purger_et_prechauffer_boutique' );
```

L'action personnalisée `reseau_horaires_mis_a_jour` se déclenche uniquement lors de l'enregistrement du champ horaires depuis l'interface d'administration de chaque boutique, ce qui garantit que seule la mise à jour effective déclenche ce traitement ciblé.

## Pourquoi préchauffer, et pas seulement purger

Purger une URL sans la recharger immédiatement laisse le premier visiteur suivant subir la génération complète de la page, potentiellement plus lente qu'une page déjà en cache. En ajoutant un appel de préchauffage juste après la purge, la boutique concernée retrouve une page en cache avant même qu'un visiteur ne la demande, ce qui évite tout ralentissement perceptible côté public.

- Purge ciblée : uniquement les URL réellement affectées par la modification.
- Préchauffage immédiat : rechargement de ces mêmes URL juste après la purge.
- Reste inchangé : le cache de toutes les autres boutiques et des pages de contenu éditorial.

## Ce que cette approche ne traite pas

La question du paiement en ligne pour les commandes anticipées de pièces montées ou de commandes spéciales reste hors sujet ici : elle dépend d'un système distinct, avec ses propres contraintes de cohérence, qui ne relève pas du cache de page.

> Purger large parce que c'est plus simple à coder finit toujours par coûter plus cher que localiser précisément ce qui a changé.

## En résumé

Face à un contenu qui change souvent mais toujours de façon localisée, une purge globale du cache est rarement la bonne réponse. Cibler exactement les pages concernées, puis les précharger aussitôt, permet à un réseau de boutiques de garder un cache globalement chaud toute la journée, malgré des dizaines de mises à jour quotidiennes réparties entre des boutiques indépendantes les unes des autres.