Servir des assets statiques depuis Cloudflare R2 plutôt que S3 : bénéfices, règles et limites

Les assets statiques paraissent simples jusqu’au moment où ils deviennent une ligne importante et imprévisible de la facture. Images produit, PDFs, vidéos, polices, exports de documentation, rapports générés et builds téléchargeables commencent souvent dans le même bucket. Lorsque le trafic augmente, le sujet principal n’est plus le stockage. C’est la livraison.

Cloudflare R2 change l’équation : stockage objet compatible S3, pas de frais d’egress R2 vers Internet, et possibilité de placer le bucket derrière un domaine géré par Cloudflare. Mais R2 ne remplace pas tous les modèles d’hébergement statique. Le bon choix dépend de ce que vous servez : une application web ou des objets.

Le vrai problème n’est pas seulement le stockage

Un système public d’assets doit faire quatre choses :

1. Stocker les objets durablement.
2. Exposer des URLs sous un hostname contrôlé.
3. Mettre en cache les fichiers très demandés.
4. Invalider ou versionner les changements proprement.

S3 le fait souvent avec CloudFront devant. R2 le fait avec un domaine personnalisé Cloudflare, Cache Rules, WAF, Access et Workers lorsque de la logique est nécessaire. La différence n’est pas seulement l’API du bucket. Elle se situe dans la couche edge et dans le coût des octets servis aux utilisateurs.

Où R2 est le plus pertinent

R2 est particulièrement adapté aux fichiers publics, lus souvent et relativement stables :

• assets avec hash, par exemple app.4f3a1c.css ou vendor.91bc2.js
• images, vidéos, polices et médias Open Graph
• PDFs, livres blancs, rapports et téléchargements publics
• releases, datasets, fichiers de modèles et grandes archives
• répertoires statiques où l’URL doit correspondre à une clé objet

Le bénéfice est à la fois économique et opérationnel. R2 ne facture pas l’egress R2 vers Internet, fonctionne avec beaucoup d’outils compatibles S3 et place cache, sécurité et règles de livraison dans le même plan de contrôle Cloudflare.

SSG ou service direct depuis R2 ?

La première question est simple : servez-vous des pages ou des fichiers ?

Utilisez un hébergement SSG pour le HTML et les routes. Astro, Cloudflare Pages, Workers Static Assets, Netlify ou Vercel comprennent les routes comme /pricing, les fallbacks SPA, les redirections, les headers par route, les pages 404 et les déploiements atomiques. C’est le bon choix pour les sites marketing, la documentation, les blogs et les applications où SEO, canonical, structured data et status codes comptent.

Utilisez R2 directement lorsque le chemin identifie un fichier :

https://assets.example.com/brand/logo.svg
https://downloads.example.com/reports/audit-2026.pdf
https://releases.example.com/app/1.8.4/linux-amd64.tar.gz

R2 ne déduit pas automatiquement que /docs/ doit servir /docs/index.html ou que /app/settings doit revenir à /app/index.html. Vous pouvez ajouter un Worker devant R2 pour ce comportement, mais vous construisez alors un petit hébergeur statique. C’est parfois le bon choix, mais il doit être explicite.

Trois modèles qui tiennent en production

Le modèle recommandé consiste à garder le site sur une plateforme SSG et à déplacer les fichiers lourds vers R2 :

www.example.com       -> site ou application
assets.example.com    -> bucket R2 public
downloads.example.com -> bucket R2 public

Vous gardez les routes HTML, previews, redirects et signaux SEO dans la plateforme du site, pendant que les images, PDFs et releases sont servis depuis R2 avec le cache Cloudflare.

Pour des archives publiques versionnées, R2 peut servir directement une arborescence d’objets. Ne comptez pas sur le listing de bucket comme navigation. Publiez une page d’index depuis le site principal ou uploadez un index.html explicite si les utilisateurs doivent parcourir le contenu.

Si vous avez besoin d’authentification, de tokens, de normalisation de chemins ou de headers dynamiques, placez un Worker devant R2. Le Worker peut valider la requête, résoudre la clé objet, définir Cache-Control et retourner le fichier.

Domaine personnalisé, cache et sécurité

En production, utilisez un domaine personnalisé comme assets.example.com. L’URL r2.dev est pratique pour tester, mais ne doit pas être votre surface publique principale. Le domaine personnalisé permet d’appliquer Cache Rules, WAF, Access, règles anti-bot et Workers.

Les règles doivent rester simples :

• Assets hashés : Cache-Control: public, max-age=31536000, immutable.
• Fichiers mutables comme latest.zip, catalog.json ou index.html : TTL court et purge au déploiement.
• Téléchargements privés ou signés : bypass du cache ou cache key conçue correctement.
• Cache Everything : uniquement sur le hostname du bucket, jamais globalement sur l’application.

Le pipeline d’upload compte autant que le fournisseur. Chaque objet doit avoir le bon Content-Type et les bons metadata de cache. Un fichier JavaScript servi en application/octet-stream ou un SVG avec un mauvais type peut casser le navigateur, les previews ou les règles de sécurité.

R2 vs S3 : règle de décision

S3 reste pertinent pour une organisation très AWS-native, avec CloudFront, IAM, signed URLs, logging et gouvernance déjà en place. R2 devient intéressant lorsque l’egress pèse, que les fichiers sont publics ou semi-publics, et que Cloudflare est déjà la couche edge.

Règle pratique :

• Pages HTML et routes applicatives : SSG, Pages ou Workers Static Assets.
• Gros fichiers publics et assets immuables : R2 derrière un domaine personnalisé.
• Arborescences publiques simples : R2 direct.
• Arborescences avec auth ou routing : Worker devant R2.
• Workflows privés profondément intégrés à AWS : S3 peut rester le meilleur choix.

La bonne architecture n’est généralement pas “R2 partout”. Elle est plus précise : garder les pages dans l’outil conçu pour les pages, déplacer les octets publics à fort volume vers R2, et appliquer cache et sécurité au point d’entrée réel du trafic.