# Purger Bunny.net automatiquement après chaque déploiement d’une billetterie

> Une étape de pipeline qui purge automatiquement le CDN Bunny.net juste après la mise en production d'un site de billetterie de spectacle, particulièrement sensible au cache figé.

- Auteur : Clément Hadrot
- Publié le : 2026-01-07
- Mis à jour le : 2026-01-07
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/purger-bunny-net-apres-deploiement-billetterie/

## L’essentiel

- Appeler l'API de purge Bunny.net depuis le pipeline
- cibler les zones sensibles plutôt que tout purger
- vérifier la purge avant de considérer le déploiement terminé

30 secondes : c'est le délai de propagation moyen observé après un appel à l'API de purge de Bunny.net, une fois l'étape ajoutée au pipeline de déploiement. Sans cette purge automatique, un visuel d'affiche obsolète, un prix erroné, une date de représentation modifiée ou une jauge de places affichée en cache peuvent rester visibles bien après la correction et induire un client en erreur au moment de l'achat sur un site de billetterie.

Bunny.net, utilisé ici comme CDN devant un site WordPress de billetterie, met en cache les pages et les assets statiques selon une durée de vie configurée en amont. Sans purge explicite après déploiement, cette durée de vie peut largement dépasser le temps entre deux mises à jour de contenu critiques, ce qui impose d'automatiser la purge directement dans le pipeline de mise en production.

## Cibler les zones sensibles plutôt que tout purger

Purger l'intégralité du cache à chaque déploiement semble la solution la plus simple, mais elle a un coût : toutes les pages, y compris celles qui n'ont pas changé, redeviennent temporairement plus lentes à charger le temps de repeupler le cache, ce qui pénalise l'expérience de tous les visiteurs pour un changement qui ne concerne parfois qu'une seule page de spectacle.

Une purge ciblée, limitée aux URLs réellement modifiées lors du déploiement (fiches de spectacle mises à jour, page de tarifs, page d'accueil si elle affiche les prochaines dates), réduit cet impact tout en garantissant la fraîcheur là où elle compte réellement.

## Appeler l'API de purge depuis le pipeline

> L'essentiel à retenir : Appeler l'API de purge Bunny.net depuis le pipeline ; cibler les zones sensibles plutôt que tout purger ; vérifier la purge avant de considérer le déploiement terminé

Bunny.net expose une API REST de purge, utilisable directement depuis une étape de pipeline après la mise en production effective des fichiers :

```
#!/bin/bash
# Étape de purge ciblée, exécutée après le déploiement
URLS_A_PURGER=(
  "https://billetterie.exemple.fr/spectacles/soiree-jazz/"
  "https://billetterie.exemple.fr/tarifs/"
  "https://billetterie.exemple.fr/"
)

for URL in "${URLS_A_PURGER[@]}"; do
  curl -s -X POST "https://api.bunny.net/purge?url=${URL}" \
    -H "AccessKey: ${BUNNY_API_KEY}"
  echo "Purge demandée pour ${URL}"
done
```

La liste des URLs à purger peut être générée dynamiquement à partir des identifiants de contenu modifiés lors du déploiement, plutôt que codée en dur, pour rester exacte au fil de l'évolution du catalogue de spectacles.

## Vérifier la purge avant de clore le déploiement

Une purge demandée n'est pas instantanément terminée sur l'ensemble du réseau de points de présence de Bunny.net. Une étape de vérification, quelques secondes après l'appel de purge, confirme que la page renvoie bien le contenu attendu plutôt que de considérer le déploiement terminé sur la seule foi de la réponse de l'API :

```
sleep 30
curl -s https://billetterie.exemple.fr/tarifs/ | grep -q "nouveau-tarif" \
  && echo "Purge confirmée" \
  || echo "Attention : contenu encore en cache après 30 secondes"
```

## Ce qui reste hors périmètre de cette étape

- Le cache applicatif WordPress lui-même (objets, requêtes) suit un cycle de purge séparé, généralement déclenché par les hooks WordPress natifs comme `save_post`, indépendant de la purge du CDN.
- La configuration des règles de mise en cache de Bunny.net (durée de vie par type de contenu) se définit en amont, dans le tableau de bord du service, et ne fait pas partie de cette étape de pipeline.

### Un point de vigilance sur les clés d'API

La clé d'accès à l'API Bunny.net doit être stockée comme variable d'environnement du pipeline de déploiement, jamais en clair dans le script lui-même, avec des droits strictement limités à l'action de purge si le fournisseur le permet, plutôt qu'une clé disposant d'un accès complet au compte.

> Un CDN mal purgé ne ment pas différemment d'un site en panne : il montre simplement une vérité qui n'est plus la bonne.

## En résumé

Automatiser la purge de Bunny.net juste après chaque déploiement d'un site de billetterie évite qu'une information sensible au cache reste visible au-delà de sa durée de validité réelle. Cibler les URLs réellement modifiées plutôt que de tout purger conserve les bénéfices du CDN sur le reste du site, tout en garantissant l'exactitude des pages critiques pour l'achat de billets.