# Diffuser les médias d’un site vitrine via Bunny.net plutôt qu’en local

> Avant de basculer la diffusion des images et vidéos vers un CDN externe, une dizaine de vérifications évitent les mauvaises surprises côté DNS, cache et facturation.

- Auteur : WordPress Développement
- Publié le : 2022-03-09
- Mis à jour le : 2022-03-09
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/diffuser-medias-site-vitrine-bunny-net/

## L’essentiel

- Vérifier le format des URL avant la bascule
- Séparer purge de cache et purge d'origine
- Chiffrer le budget mensuel avant de signer

68 % : c'est, sur un échantillon de sites vitrines que nous suivons, la part moyenne du poids total d'une page occupée par les images et les vidéos. Face à ce chiffre, la tentation est grande de sortir ces fichiers du serveur d'hébergement et de les confier à un réseau de diffusion de contenu comme Bunny.net, réputé pour sa simplicité de mise en place et ses tarifs lisibles au gigaoctet transféré.

Mais « diffuser les médias via un CDN » recouvre plusieurs architectures très différentes : réécriture d'URL à la volée, copie synchronisée des fichiers, ou stockage objet servant directement d'origine. Avant de brancher un plugin et de croiser les doigts, une liste de vérifications précises permet de savoir dans quoi on s'engage — et d'éviter de casser silencieusement des liens indexés depuis des années.

## Ce que cette bascule ne couvre pas

Le sujet ici est strictement la diffusion des fichiers médias : images, vidéos, documents PDF téléchargeables. La mise en cache des pages HTML complètes est un chantier distinct, avec ses propres règles de purge et ses propres risques de contenu obsolète affiché aux visiteurs ; il n'est pas traité dans cette liste, qui se concentre sur les assets statiques.

## La checklist avant bascule

> L'essentiel à retenir : Vérifier le format des URL avant la bascule ; Séparer purge de cache et purge d'origine ; Chiffrer le budget mensuel avant de signer

1. **Auditer les chemins d'URL existants.** Un plugin d'offload media réécrit généralement les balises `src` vers un sous-domaine dédié, du type `media.exemple.fr`. Il faut vérifier qu'aucun contenu n'utilise des chemins relatifs codés en dur dans le corps des articles, sans quoi la réécriture automatique les ignorera.
2. **Choisir entre Pull Zone et stockage objet.** En mode « pull », Bunny.net va chercher les fichiers directement sur le serveur d'origine à la première requête, puis les met en cache sur ses points de présence. En mode stockage, les fichiers sont copiés une fois pour toutes sur l'infrastructure du CDN, qui devient alors l'origine réelle. Le second mode protège le serveur d'origine des pics de trafic mais impose une synchronisation à chaque nouvel upload.
3. **Vérifier le comportement des en-têtes de cache.** Le serveur d'origine doit envoyer des en-têtes `Cache-Control` et `ETag` cohérents ; sans cela, le CDN risque de conserver une version périmée d'une image renommée à l'identique après retouche.
4. **Tester le remplacement d'un fichier existant.** Un cas fréquent : le client renvoie une nouvelle version d'un visuel avec le même nom de fichier. Sans purge explicite de la Pull Zone, l'ancienne version reste servie pendant toute la durée du TTL configuré, parfois plusieurs jours.
5. **Séparer purge CDN et purge du cache de pages.** Un plugin de cache classique et le CDN gèrent deux couches indépendantes ; purger l'un ne purge pas l'autre. Documenter clairement où se trouve chaque bouton de purge évite les échanges de tickets confus avec un client qui « ne voit toujours pas son image ».
6. **Contrôler les CORS pour les polices et le SVG.** Si des polices web ou des icônes SVG sont également servies par le sous-domaine du CDN, un en-tête `Access-Control-Allow-Origin` manquant bloque silencieusement leur chargement dans certains navigateurs.
7. **Mesurer l'impact sur le certificat TLS.** Le sous-domaine dédié aux médias a besoin de son propre certificat, généralement généré automatiquement par le CDN ; il faut vérifier qu'il couvre bien le nom exact utilisé dans les URL réécrites.
8. **Chiffrer le volume de transfert mensuel prévisible.** Bunny.net facture au gigaoctet sortant selon la zone géographique desservie ; un site à fort trafic vidéo en Amérique du Sud, zone plus coûteuse, peut réserver une surprise sur la première facture si la répartition géographique du public n'a pas été anticipée.
9. **Prévoir un plan de retour arrière.** Le plugin d'offload doit permettre de revenir aux URL d'origine sans réécrire manuellement la base de données, en cas d'incident chez le prestataire CDN ou de fin de contrat.
10. **Vérifier l'impact sur le référencement des images.** Google associe les images à un domaine ; un changement de domaine de diffusion peut temporairement faire disparaître des images déjà indexées dans Google Images, le temps que le nouveau domaine soit recrawlé.

## Un cas concret de mauvaise surprise

Sur un projet suivi récemment, la bascule avait été faite un vendredi après-midi, sans test préalable du remplacement de fichier. Le lundi suivant, un visuel de page d'accueil retouché en urgence continuait d'afficher l'ancienne version pendant près de trois jours, le temps que le TTL par défaut de la Pull Zone expire. La correction a consisté à activer la purge automatique via webhook à chaque mise à jour de média dans la médiathèque WordPress, plutôt que de compter sur l'expiration naturelle du cache.

### Le webhook de purge côté WordPress

```
add_action( 'wp_update_attachment_metadata', function ( $data, $attachment_id ) {
    $url = wp_get_attachment_url( $attachment_id );
    wp_remote_post( 'https://api.bunny.net/purge', array(
        'headers' => array( 'AccessKey' => BUNNY_API_KEY ),
        'body'    => array( 'url' => $url ),
    ) );
    return $data;
}, 10, 2 );
```

Ce déclencheur s'appuie sur le hook `wp_update_attachment_metadata`, exécuté chaque fois que WordPress régénère les métadonnées d'un fichier joint, y compris après un remplacement d'image dans la médiathèque. Il reste minimal volontairement : la logique de purge complète, avec gestion des erreurs et des tailles d'image multiples, doit être adaptée au cas par cas.

## Quand ne pas basculer

Tous les sites ne gagnent pas à externaliser leurs médias. Un site vitrine à trafic modeste, hébergé sur un serveur déjà rapide et proche géographiquement de son audience, peut ne tirer aucun bénéfice mesurable d'un CDN, tout en ajoutant un point de défaillance externe et une ligne de facturation supplémentaire. La bascule se justifie surtout à partir du moment où l'audience se disperse géographiquement, où les médias pèsent lourd, ou où le serveur d'origine montre des signes de saturation sur les requêtes de fichiers statiques.

> Une règle simple, éprouvée sur plusieurs migrations : ne jamais purger en pensant à moitié à ce qu'on purge. Toujours vérifier l'URL exacte renvoyée par l'API de purge avant de la considérer comme acquise.

## En résumé

Basculer la diffusion des médias vers Bunny.net apporte un vrai gain de rapidité pour une audience dispersée, à condition de traiter la question comme un projet d'infrastructure à part entière : test de purge, gestion des en-têtes, plan de retour arrière et estimation réaliste du volume transféré. Une checklist suivie point par point, avant toute bascule en production, évite l'essentiel des incidents rencontrés sur ce type de migration.