210 gigaoctets d’images en un an, sur un seul site e-commerce à catalogue produit fourni : c’est le volume qui a fini par remplir le disque d’un VPS pourtant dimensionné à 80 Go au départ. La bibliothèque de médias WordPress grossit vite quand chaque fiche produit embarque cinq à huit photos en haute résolution, sans compter les vignettes générées automatiquement pour chaque taille d’affichage.
Deux options s’offraient alors : agrandir le disque du serveur, solution rapide mais qui ne fait que repousser le problème, ou décharger les médias vers un stockage objet externe. Le choix s’est porté sur un test comparatif entre Backblaze B2 et un espace compatible S3, avec un an de recul aujourd’hui pour en tirer un bilan concret.
Pourquoi le disque local ne suffisait plus
Au-delà du simple espace disque, le vrai problème venait de la génération de vignettes : WordPress crée par défaut plusieurs tailles pour chaque image importée (miniature, moyenne, grande, plus les tailles définies par le thème via add_image_size()). Pour une image source de 4 Mo, cela peut représenter six à dix fichiers supplémentaires, multipliant d’autant l’espace occupé et le nombre d’opérations d’écriture disque lors d’un import en masse.
Les sauvegardes quotidiennes du serveur souffraient aussi de ce volume : chaque sauvegarde complète devait traiter des dizaines de gigaoctets de médias rarement modifiés, allongeant la fenêtre de sauvegarde et le temps de restauration en cas d’incident.
Backblaze B2 : le choix du coût au Go
Backblaze B2 s’est distingué immédiatement sur le prix : le stockage facturé est resté nettement inférieur à celui d’un espace S3 standard, pour un usage comparable en volume et en nombre de requêtes de lecture. La compatibilité avec l’API S3 proposée par Backblaze a permis d’utiliser les mêmes extensions WordPress d’offload que pour un vrai bucket S3, sans réécrire l’intégration.
La contrepartie s’est fait sentir sur la latence brute des requêtes, légèrement supérieure à celle observée sur un bucket S3 dans la même région que le serveur. Ce point est devenu secondaire une fois un CDN placé devant le stockage, ce qui a été fait dès le second mois de test.
Le comparatif après un an d’usage réel
| Critère | Backblaze B2 | Espace S3 standard |
|---|---|---|
| Coût au Go stocké | Nettement inférieur | Référence du marché |
| Coût de sortie (egress) vers un CDN tiers | Souvent réduit via accords partenaires | Facturé au tarif standard |
| Compatibilité extensions WordPress | Bonne, via API compatible S3 | Native, écosystème le plus large |
| Latence brute sans CDN | Légèrement plus élevée | Meilleure en général |
Impact réel sur la génération de vignettes
Un point technique a demandé un ajustement du flux d’import : générer toutes les tailles de vignettes localement avant l’envoi vers le stockage distant, plutôt que de tenter de les générer après coup sur des fichiers déjà déportés. Cela évite des allers-retours réseau coûteux en temps lors de chaque import produit, surtout en masse via un import CSV WooCommerce.
- Import et génération de toutes les tailles en local, sur le disque du serveur
- Envoi groupé vers le stockage distant une fois toutes les tailles prêtes
- Suppression des fichiers locaux après confirmation de l’envoi, pas avant
Le rôle décisif du CDN devant l’offload
Un stockage objet sans CDN devant reste plus lent qu’un disque local bien configuré ; c’est la combinaison offload plus CDN qui apporte le vrai gain, jamais l’offload seul.
Une fois le CDN mis en place devant le bucket, la différence de latence entre les deux fournisseurs de stockage est devenue quasiment imperceptible pour les visiteurs, le CDN servant la grande majorité des requêtes depuis son propre cache en périphérie, sans même solliciter le stockage d’origine.
Notre verdict après un an
Le choix de Backblaze B2 s’est révélé pertinent pour ce projet précis, porté principalement par l’écart de coût au Go stocké sur un volume qui continue de croître chaque mois. Un site avec un volume de médias plus modeste, ou déjà fortement intégré à l’écosystème Amazon pour d’autres services, tirerait sans doute davantage bénéfice d’un bucket S3 classique, ne serait-ce que pour la simplicité de gestion des accès. Dans les deux cas, la leçon la plus utile de cette année de recul reste la même : générer les vignettes avant l’offload, jamais après.
