Depuis qu’AWS a fixé les règles du stockage objet avec S3, la facture d’egress a fait fuir plus d’une équipe technique vers des alternatives moins gourmandes. Cloudflare R2 s’est imposé comme la réponse la plus crédible : une API compatible S3, zéro frais de sortie et, depuis août 2026, un choix explicite de juridiction des données qui parle directement aux équipes conformité RGPD. Ce tutoriel vous montre comment activer R2, choisir la bonne juridiction pour vos données européennes, brancher le SDK AWS existant sans réécrire votre code, et construire un pipeline de traitement avec Cloudflare Pipelines, la nouvelle brique en bêta. On couvre 13 étapes concrètes, du premier bucket jusqu’à la migration d’un stock S3 existant, avec du code testable à chaque étape.

Ce guide s’adresse aux développeurs backend, aux ingénieurs plateforme et aux CTO de PME ou de scale-up qui gèrent déjà un bucket S3 et se demandent si le passage à R2 vaut le coût de migration. Vous n’avez pas besoin d’être expert Cloudflare pour suivre ce tutoriel : chaque commande est donnée telle quelle, et chaque étape indique ce qui se passe si vous la sautez. Comptez environ 75 minutes pour tout dérouler sur un compte de test, et prévoyez une session séparée pour la migration d’un environnement de production existant, qui mérite sa propre fenêtre de maintenance.

Pourquoi Cloudflare R2 s’impose face à S3 en Europe en 2026

L’argument commercial de Cloudflare R2 tient en une ligne depuis son lancement : pas de frais de sortie (egress). Sur un projet qui sert des vidéos, des images ou des exports de données à des utilisateurs finaux, cette seule ligne peut représenter des milliers d’euros économisés chaque mois face à la grille tarifaire d’Amazon S3. Mais en 2026, l’argument qui pèse le plus pour les équipes françaises et européennes n’est plus seulement financier, il est réglementaire.

En août 2026, Cloudflare a ajouté une juridiction us explicite pour R2, garantissant que les données d’un bucket restent stockées et traitées exclusivement aux États-Unis via un endpoint dédié de type ACCOUNT_ID.us.r2.cloudflarestorage.com. Couplée à la juridiction eu déjà existante, cette option permet à une entreprise française de prouver, techniquement et contractuellement, où vivent ses données. C’est exactement le type de garantie que réclament les délégués à la protection des données (DPO) depuis l’entrée en vigueur du RGPD, et que peu de fournisseurs cloud américains offrent avec autant de granularité au niveau du bucket.

Le service n’est pas exempt d’incidents. Le 14 juillet 2026, Cloudflare a signalé un taux d’erreurs élevé sur R2 dans la région UE, résolu après plusieurs heures de surveillance renforcée. Cet épisode rappelle une règle de base du cloud : aucune juridiction, aussi rassurante soit-elle sur le papier, ne dispense d’une stratégie de sauvegarde et de monitoring. On y reviendra aux étapes 10 et 11 de ce guide.

Enfin, Cloudflare a ouvert en bêta, toujours en août 2026, un service nommé Cloudflare Pipelines, disponible pour tous les comptes disposant d’un plan Workers payant. Il permet d’orchestrer des transformations de données directement sur les objets stockés dans R2, sans passer par un service tiers d’ETL. C’est la partie la plus récente et la moins documentée de cet écosystème, et ce tutoriel lui consacre une étape dédiée avec un avertissement clair sur ses limites actuelles.

Reste la question du support Kubernetes autour de cet écosystème, pour les équipes qui font tourner leurs workloads sur GKE ou AKS et veulent y archiver leurs sauvegardes vers R2. Google a rendu Kubernetes 1.31 disponible dans le canal Rapid de GKE en août 2026, avec un support de correctifs prévu jusqu’à la version 1.31.14 selon le calendrier officiel des releases. Microsoft, de son côté, a annoncé en juin 2026 la disponibilité générale des Fleet Namespaces managés, avec un plafond porté à 1 000 clusters par flotte contre 200 auparavant, et un Fleet Manager pour les clusters Arc-enabled également passé en disponibilité générale. Ces deux annonces ne concernent pas directement R2, mais elles dessinent le même mouvement de fond : une gestion centralisée des politiques réseau, des quotas et des accès sur des environnements hybrides, dont R2 devient naturellement une brique de stockage commune.

Prérequis : comptes, outils et versions nécessaires

Avant de commencer, réunissez les éléments suivants. Rien d’exotique, mais un prérequis manquant casse systématiquement l’étape 4 ou l’étape 6 plus loin dans ce guide.

  • Un compte Cloudflare actif (le plan gratuit suffit pour suivre ce tutoriel, un plan Workers payant est nécessaire uniquement pour l’étape Pipelines)
  • Node.js 20 LTS ou une version plus récente, avec npm
  • Wrangler, l’outil en ligne de commande de Cloudflare, installé via npm (dernière version, alignée sur le runtime workerd 1.20260508.1 et miniflare 4.20260508.0 publiés en juillet 2026)
  • Le SDK AWS pour JavaScript, package @aws-sdk/client-s3, ou l’AWS CLI si vous préférez la ligne de commande pure
  • Un accès terminal (macOS, Linux, ou WSL2 sous Windows)
  • Environ 75 minutes pour suivre l’intégralité des 13 étapes, plus le projet complet en fin d’article

Un point de vigilance dès maintenant : les dépendances miniflare et wrangler ont été mises à jour en juillet 2026 avec un nouveau runtime workerd. Si vous travaillez sur un projet existant avec des versions plus anciennes, mettez-les à jour avant de suivre ce tutoriel, sinon certaines commandes de l’étape 9 (Pipelines) échoueront silencieusement.

Vérifiez aussi vos droits d’administration sur le compte Cloudflare avant de commencer. La création d’un bucket R2 et la génération de tokens API scoped exigent un rôle admin ou super-admin sur le compte, pas un simple accès membre. Si vous travaillez dans une organisation qui centralise la gestion des comptes cloud, demandez l’accès à l’avance : c’est souvent le blocage le plus bête et le plus long à débloquer, surtout un vendredi après-midi.

Étape 1 : Activer R2 et choisir la juridiction des données

Connectez-vous à votre tableau de bord Cloudflare et ouvrez la section R2 Object Storage dans le menu latéral. La première activation vous demande d’accepter les conditions du service, puis vous propose immédiatement de choisir une juridiction par défaut pour les futurs buckets. C’est ici que la décision de conformité se prend, et elle ne se change pas après coup sur un bucket déjà créé.

Trois options s’offrent à vous : auto (Cloudflare choisit dynamiquement l’emplacement le plus performant, sans garantie géographique), eu (données stockées et traitées exclusivement dans l’Union européenne) et, depuis août 2026, us (données cantonnées aux États-Unis). Pour une entreprise française qui traite des données personnelles au sens du RGPD, la juridiction eu est le choix par défaut recommandé, sauf contrat client explicite exigeant autre chose.

JuridictionEmplacement garantiEndpoint S3Cas d’usage typique
autoAucune garantie géographiqueACCOUNT_ID.r2.cloudflarestorage.comCache, contenu public non sensible
euUnion européenne uniquementACCOUNT_ID.eu.r2.cloudflarestorage.comDonnées personnelles RGPD, contrats DPA stricts
usÉtats-Unis uniquementACCOUNT_ID.us.r2.cloudflarestorage.comClients américains avec exigence de résidence locale

Un point souvent négligé : le choix de juridiction s’applique au contenu des objets, mais certaines métadonnées techniques (nom du bucket, taille des fichiers, horodatage) peuvent transiter par l’infrastructure globale de Cloudflare pour le routage et la facturation. Si votre analyse de risque RGPD exige une étanchéité totale, y compris sur les métadonnées, consultez la documentation officielle sur la localisation des données avant de valider votre architecture avec votre DPO. C’est une nuance qui distingue R2 d’un hébergement 100 % on-premise, sans pour autant remettre en cause sa pertinence pour la grande majorité des cas d’usage SaaS.

Étape 2 : Créer votre premier bucket S3-compatible

Une fois la juridiction validée, créez un bucket. Le nom doit être unique au sein de votre compte, en minuscules, sans espace ni caractère spécial. Depuis le tableau de bord, cliquez sur “Créer un bucket”, donnez-lui un nom explicite (par exemple mon-app-eu-prod) et sélectionnez la juridiction eu définie à l’étape précédente.

Vous pouvez aussi tout faire en ligne de commande avec Wrangler, ce qui est reproductible et versionnable dans un pipeline CI/CD :

npm install -g wrangler
wrangler login
wrangler r2 bucket create mon-app-eu-prod --jurisdiction eu

Depuis avril 2026, le tableau de bord permet aussi de vider un bucket ou de supprimer des dossiers entiers directement, sans écrire de script de purge ni configurer une règle de cycle de vie temporaire. Pratique pour nettoyer un bucket de test entre deux passages sur ce tutoriel.

Réfléchissez à votre convention de nommage avant de créer une dizaine de buckets à la volée. Un préfixe par projet, suivi de l’environnement puis de la juridiction (projet-prod-eu, projet-staging-eu) rend la lecture du tableau de bord instantanée, même six mois plus tard quand vous aurez oublié le contexte exact de chaque bucket. Cette discipline de nommage paie particulièrement au moment de configurer les permissions de tokens à l’étape suivante, où un nom clair évite d’accorder un accès au mauvais environnement par erreur de frappe.

Étape 3 : Générer des tokens d’API à portée restreinte

C’est l’étape où la majorité des équipes prennent un raccourci dangereux : créer un token “Admin Read & Write” valable sur l’ensemble du compte, puis l’oublier dans une variable d’environnement partagée. Ne faites pas ça. Dans le tableau de bord R2, section “Gérer les tokens API”, créez un token scoped à un seul bucket, avec les permissions minimales nécessaires (lecture seule pour un service de diffusion, lecture-écriture pour un service d’ingestion).

Le token généré vous donne trois valeurs à conserver dans un gestionnaire de secrets, jamais dans un fichier commité : l’Access Key ID, la Secret Access Key, et l’endpoint S3 spécifique à votre compte et à la juridiction choisie.

Si plusieurs services doivent accéder au même bucket avec des besoins différents, créez un token par service plutôt qu’un token partagé. Un service d’ingestion qui reçoit des uploads utilisateurs n’a besoin que de la permission d’écriture sur un préfixe précis, tandis qu’un service de reporting n’a besoin que de la lecture. Cette granularité limite mécaniquement l’impact d’une compromission : si le token du service de reporting fuite, un attaquant ne peut ni écrire ni supprimer vos données, seulement les lire.

# Exemple de configuration locale (à ne jamais committer)
export R2_ACCOUNT_ID="votre_account_id"
export R2_ACCESS_KEY_ID="votre_access_key"
export R2_SECRET_ACCESS_KEY="votre_secret_key"
export R2_ENDPOINT="https://${R2_ACCOUNT_ID}.eu.r2.cloudflarestorage.com"

Étape 4 : Installer et connecter le SDK AWS à R2

C’est l’argument technique le plus fort en faveur de R2 : la compatibilité S3 signifie que vous pouvez réutiliser le SDK AWS officiel sans changer une seule dépendance. Il suffit de pointer le client vers l’endpoint R2 et de renseigner les identifiants générés à l’étape précédente.

npm install @aws-sdk/client-s3

// client-r2.js
import { S3Client } from "@aws-sdk/client-s3";

export const r2Client = new S3Client({
  region: "auto",
  endpoint: process.env.R2_ENDPOINT,
  credentials: {
    accessKeyId: process.env.R2_ACCESS_KEY_ID,
    secretAccessKey: process.env.R2_SECRET_ACCESS_KEY,
  },
});

Testez immédiatement la connexion avec une commande de listing, avant d’écrire la moindre logique métier. Si cette commande échoue, tout le reste du tutoriel échouera aussi, autant le savoir tout de suite.

Si votre stack est en Python plutôt qu’en Node.js, le principe reste identique avec boto3, le SDK AWS officiel pour Python. La seule différence porte sur le paramètre endpoint_url à passer au client, qui pointe vers votre endpoint R2 au lieu de l’endpoint AWS par défaut. Cette portabilité, quel que soit le langage, est précisément ce qui rend R2 attractif pour une équipe qui ne veut pas maintenir deux jeux de bibliothèques différents selon le fournisseur de stockage.

Étape 5 : Uploader, lister et supprimer des objets en ligne de commande

Avec le client configuré, les opérations de base reprennent exactement la syntaxe S3 standard. Voici un script minimal qui envoie un fichier, liste le contenu du bucket, puis supprime l’objet de test.

import { PutObjectCommand, ListObjectsV2Command, DeleteObjectCommand } from "@aws-sdk/client-s3";
import { r2Client } from "./client-r2.js";
import fs from "fs";

const bucket = "mon-app-eu-prod";

// Upload
await r2Client.send(new PutObjectCommand({
  Bucket: bucket,
  Key: "test/rapport.pdf",
  Body: fs.readFileSync("./rapport.pdf"),
  ContentType: "application/pdf",
}));

// Liste
const liste = await r2Client.send(new ListObjectsV2Command({ Bucket: bucket }));
console.log(liste.Contents?.map(o => o.Key));

// Suppression
await r2Client.send(new DeleteObjectCommand({ Bucket: bucket, Key: "test/rapport.pdf" }));

Pour des fichiers volumineux (au-delà de 100 Mo), passez au multipart upload plutôt qu’un PutObjectCommand unique. C’est la cause numéro un des time-out d’upload évoqués dans la section dépannage plus bas.

Notez que l’objet ContentType mérite d’être renseigné systématiquement, même si R2 accepte l’upload sans lui. Un fichier PDF sans ce champ correctement défini sera servi par défaut en application/octet-stream par le navigateur, forçant un téléchargement au lieu d’un affichage inline, ce qui casse silencieusement l’expérience utilisateur sur une prévisualisation de document. Prenez cinq minutes pour établir une table de correspondance extension-vers-ContentType dans votre code d’upload plutôt que de la laisser au hasard du client qui envoie le fichier.

Étape 6 : Configurer CORS pour une application web

Si votre application front-end doit uploader ou télécharger des fichiers directement depuis le navigateur, vous devez déclarer une politique CORS sur le bucket avant le premier test. Sans cette étape, le navigateur bloque silencieusement les requêtes et l’erreur n’apparaît que dans la console développeur, jamais côté serveur.

wrangler r2 bucket cors put mon-app-eu-prod --rules '[
  {
    "AllowedOrigins": ["https://monapp.fr"],
    "AllowedMethods": ["GET", "PUT", "POST"],
    "AllowedHeaders": ["*"],
    "MaxAgeSeconds": 3600
  }
]'

Évitez "AllowedOrigins": ["*"] en production sur un bucket contenant des données personnelles. C’est une facilité de développement, pas une configuration à déployer.

Si votre application dessert plusieurs domaines (par exemple un domaine principal et un sous-domaine de préproduction), déclarez chaque origine explicitement dans le tableau AllowedOrigins plutôt que de multiplier les règles CORS séparées. Une seule règle avec plusieurs origines listées est plus simple à auditer qu’une collection de règles éparses, et évite l’erreur classique où une règle de test oubliée reste active en production pendant des mois sans que personne ne s’en aperçoive.

Étape 7 : Automatiser le cycle de vie et la purge des données

Le RGPD impose une durée de conservation limitée pour beaucoup de catégories de données. R2 permet de configurer des règles de cycle de vie qui suppriment automatiquement les objets après un délai défini, ou qui les font transiter vers une classe de stockage moins chère (Infrequent Access) après une période d’inactivité. Configurez cette règle dès la mise en production du bucket, pas six mois après quand le stockage a déjà doublé.

wrangler r2 bucket lifecycle add mon-app-eu-prod \
  --rule-name "purge-logs-90j" \
  --prefix "logs/" \
  --expire-days 90

Créez une règle distincte par catégorie de données plutôt qu’une règle unique sur tout le bucket. Les logs applicatifs, les brouillons non finalisés et les archives contractuelles n’ont pas la même durée légale de conservation, et une seule règle générique vous forcera tôt ou tard à choisir entre purger trop tôt une donnée encore utile ou garder trop longtemps une donnée qui aurait dû disparaître. Documentez la justification de chaque durée directement dans votre registre de traitement RGPD, pas seulement dans le nom de la règle.

Étape 8 : Construire un pipeline avec Cloudflare Pipelines (bêta)

Cloudflare Pipelines, disponible en bêta depuis août 2026 pour les comptes avec un plan Workers payant, permet d’orchestrer des transformations sur les données ingérées dans R2 sans monter une infrastructure ETL séparée. Concrètement, un pipeline reçoit un événement (par exemple un nouvel objet déposé), applique une transformation, puis écrit le résultat dans une destination (un autre bucket, ou une base D1).

wrangler pipelines create mon-pipeline \
  --source r2://mon-app-eu-prod/uploads \
  --destination r2://mon-app-eu-prod/traites \
  --transform ./transform.js

Comme toute fonctionnalité en bêta, Pipelines n’offre pas encore les mêmes garanties de disponibilité que le stockage R2 lui-même. Ne l’utilisez pas comme seul chemin de traitement pour une donnée critique tant que le service n’est pas passé en disponibilité générale. Gardez un mécanisme de rejeu manuel en secours.

Concrètement, un fichier de transformation minimal reçoit l’objet source en entrée et retourne le contenu transformé en sortie. Voici la forme la plus simple pour une conversion de format, par exemple normaliser un nom de fichier et ajouter un horodatage de traitement dans les métadonnées de l’objet de sortie.

// transform.js
export default async function transform(objet) {
  const nomNormalise = objet.key.toLowerCase().replace(/\s+/g, "-");
  return {
    key: `traites/${nomNormalise}`,
    body: objet.body,
    metadata: { ...objet.metadata, traite_le: new Date().toISOString() },
  };
}

Surveillez le statut de chaque exécution de pipeline dans le tableau de bord Workers. En bêta, les erreurs de transformation ne déclenchent pas toujours de notification automatique, il faut donc vérifier manuellement les premières exécutions avant de faire confiance au système en pilote automatique.

Étape 9 : Sécuriser l’accès et activer les journaux d’audit

Au-delà des tokens à portée restreinte vus à l’étape 3, activez les journaux d’audit Cloudflare sur le compte pour tracer chaque opération de lecture, écriture et suppression sur vos buckets sensibles. Ce sont ces journaux que vous présenterez lors d’un audit RGPD ou d’une revue de sécurité fournisseur.

Le catalogue de techniques de menace publié par AWS en juin 2026 met justement l’accent sur le compute hijacking et l’usurpation de rôle comme vecteurs d’attaque montants sur les environnements cloud. La leçon s’applique directement à R2 : un token trop permissif qui fuite dans un log applicatif ou un dépôt public reste le scénario de compromission le plus fréquent, bien avant une faille du service lui-même.

Ajoutez un scan automatique de secrets dans votre pipeline CI, capable de détecter un Access Key ID R2 accidentellement commité avant qu’il n’atteigne la branche principale. Les outils de scan de conteneurs comme ceux évoqués dans le catalogue de menaces AWS de juin 2026 couvrent aussi de plus en plus ce cas d’usage côté stockage objet, avec des règles dédiées à la détection de mauvaise configuration dans les workflows CI/CD. C’est un filet de sécurité peu coûteux à mettre en place et qui évite l’essentiel des incidents liés à une fuite de credentials.

Étape 10 : Surveiller les performances et configurer les alertes

L’incident R2 du 14 juillet 2026 sur la région UE illustre pourquoi la surveillance active n’est pas optionnelle. Dans le tableau de bord Cloudflare, activez les notifications sur le statut du service (via la page de statut officielle) et configurez des alertes sur vos propres métriques applicatives : taux d’erreur 5xx sur les requêtes R2, latence moyenne des uploads, volume de Class A operations (les opérations d’écriture et de listing, facturées plus cher que les lectures).

Un pic soudain de Class A operations est souvent le symptôme d’un bug applicatif qui liste un bucket en boucle plutôt qu’un vrai signal métier. Batchez vos appels de listing avec pagination plutôt que de les répéter à chaque requête utilisateur.

Mettez en place un tableau de bord de suivi séparé pour chaque bucket critique, avec un seuil d’alerte propre à son usage. Un bucket d’archives qui reçoit habituellement quelques écritures par jour et un bucket d’ingestion qui en reçoit des milliers par heure n’ont pas le même profil de bruit, et un seuil unique appliqué aux deux génère soit des faux positifs constants, soit un silence dangereux sur le bucket le plus sensible.

Étape 11 : Sauvegarder les métadonnées avec D1 et le time travel

Cloudflare D1, la base SQL managée de Cloudflare, propose depuis août 2026 une fonctionnalité de time travel : elle permet de définir des points de restauration (bookmarks) et de revenir à un état antérieur de la base via des endpoints dédiés. Combinée à R2, elle sert typiquement à stocker les métadonnées de vos objets (nom original, utilisateur propriétaire, statut de traitement) séparément du contenu binaire lui-même.

wrangler d1 execute mon-app-metadata --command \
  "INSERT INTO objets (bucket_key, proprietaire, statut) VALUES ('uploads/rapport.pdf', 'user_42', 'traite')"

# Point de restauration avant une migration risquée
wrangler d1 time-travel bookmark mon-app-metadata

En cas d’erreur d’import massif, ce bookmark vous évite de reconstruire manuellement une table de métadonnées à partir des logs applicatifs.

Étape 12 : Migrer un bucket S3 existant vers R2

Si vous partez d’un bucket S3 existant, la compatibilité d’API rend la migration triviale avec un outil comme rclone, qui traite R2 comme n’importe quel autre backend S3. Configurez deux remotes, un pour la source AWS, un pour la destination R2, puis synchronisez.

rclone config create s3-source s3 provider=AWS \
  access_key_id=VOTRE_CLE_AWS secret_access_key=VOTRE_SECRET_AWS region=eu-west-3

rclone config create r2-dest s3 provider=Cloudflare \
  access_key_id=$R2_ACCESS_KEY_ID secret_access_key=$R2_SECRET_ACCESS_KEY \
  endpoint=$R2_ENDPOINT

rclone sync s3-source:mon-bucket-aws r2-dest:mon-app-eu-prod --progress

Pour un bucket volumineux, lancez d’abord la synchronisation en heures creuses, vérifiez le nombre d’objets transférés des deux côtés, puis basculez le trafic applicatif seulement après une vérification manuelle d’un échantillon de fichiers.

Gardez le bucket S3 source actif en lecture seule pendant au moins deux semaines après la bascule, le temps de confirmer qu’aucun processus oublié (un cron, un job batch, une intégration tierce) ne pointe encore vers l’ancien endpoint. Coupez ensuite l’accès en écriture avant de programmer la suppression définitive, jamais l’inverse. C’est une précaution qui coûte quelques euros de stockage supplémentaire mais qui évite une perte de données irréversible si la migration s’avère incomplète.

Étape 13 : Tableau comparatif face à S3, Google Cloud Storage et Backblaze B2

Dernière étape avant le projet complet : situer R2 face aux trois alternatives les plus citées par les équipes techniques françaises, sur la base des grilles tarifaires publiques de chaque fournisseur, pour choisir le bon backend selon votre profil d’usage.

FournisseurFrais d’egressCompatibilité S3Choix de juridiction UE explicite
Cloudflare R2AucunOui, nativeOui, depuis 2024, étendu en août 2026
Amazon S3Payant au-delà du free tierRéférence du standardOui, via choix de région AWS
Google Cloud StoragePayant selon destinationPartielle, via interopérabilité S3Oui, via choix de région GCP
Backblaze B2Gratuit jusqu’à 3x le volume stockéOui, via B2 S3 Compatible APIRégions EU disponibles

L’absence de frais d’egress reste l’avantage structurel de R2, particulièrement décisif pour les applications qui diffusent beaucoup de contenu vers des utilisateurs finaux plutôt que de simplement archiver des données à froid. Pour un usage d’archivage pur avec peu de lectures, Backblaze B2 reste compétitif sur le coût de stockage brut.

La compatibilité S3 mérite une nuance pour chacun des trois concurrents. Amazon S3 reste la référence contre laquelle toutes les API compatibles se mesurent, avec la couverture de fonctionnalités la plus large (versioning avancé, réplication cross-région native, classes de stockage à froid comme Glacier). Google Cloud Storage propose une interopérabilité S3 partielle, suffisante pour la plupart des opérations courantes mais qui peut buter sur des fonctionnalités avancées spécifiques à AWS. Backblaze B2 couvre l’essentiel du standard via son API S3 Compatible, avec une communauté d’outils tiers plus restreinte que celle de R2 ou S3. Avant de figer un choix, testez vos opérations les plus critiques (multipart upload, presigned URLs, listing paginé) directement sur le fournisseur visé plutôt que de vous fier uniquement au tableau comparatif.

Projet complet : une architecture de stockage souverain pour une PME

Assemblons les étapes précédentes dans une architecture fonctionnelle typique : une PME française qui héberge les documents contractuels de ses clients et doit garantir leur résidence en UE. L’architecture repose sur trois buckets R2 juridiction eu (un pour les uploads bruts, un pour les documents traités, un pour les archives soumises à purge automatique après la durée légale de conservation), une base D1 pour les métadonnées avec time travel activé, et un pipeline Cloudflare Pipelines qui convertit chaque document déposé en PDF/A archivable.

Le flux applicatif : un client dépose un fichier via un formulaire web protégé par un token à portée restreinte (étape 3), CORS autorise uniquement le domaine de l’application (étape 6), le pipeline transforme et déplace le fichier vers le bucket “traité” (étape 8), une ligne est insérée dans D1 avec le statut (étape 11), et une règle de cycle de vie purge automatiquement les brouillons non finalisés après 30 jours (étape 7). Les journaux d’audit (étape 9) et les alertes de performance (étape 10) tournent en continu en arrière-plan.

Ce montage tient en moins de 200 lignes de configuration et de code applicatif, sans serveur à administrer, et répond directement à l’exigence de traçabilité que réclament les DPO lors d’un contrôle. C’est un point de départ solide, pas une solution clé en main : chaque entreprise devra ajuster la durée de conservation et les permissions selon son propre registre de traitement RGPD.

Sur le plan des coûts, cette architecture reste prévisible parce que R2 ne facture pas la sortie des données. Une PME qui permet à ses clients de retélécharger leurs documents plusieurs fois par mois évite ainsi l’effet boule de neige d’une facture d’egress qui grimpe avec l’usage, un scénario fréquent sur S3 lorsque le volume de téléchargements dépasse les prévisions initiales. Le seul poste de coût à surveiller reste le volume de Class A operations généré par le pipeline de transformation, qu’il vaut mieux dimensionner en amont avec un test de charge sur un échantillon représentatif de documents.

5 erreurs fréquentes à éviter avec Cloudflare R2

  • Créer un bucket sans définir sa juridiction : le choix “auto” est irréversible une fois des objets déposés, et vous ne pourrez pas prouver après coup où les données ont résidé.
  • Utiliser un token Admin Read & Write sur tout le compte : une seule fuite de credentials expose l’intégralité de vos buckets, pas seulement celui visé par l’application concernée.
  • Tester une intégration front-end sans configurer CORS au préalable : les erreurs sont silencieuses côté serveur et ne se voient que dans la console du navigateur, ce qui fait perdre un temps disproportionné en debug.
  • Mélanger les endpoints de juridiction : écrire par erreur dans l’endpoint us alors que le bucket a été créé en juridiction eu génère une erreur d’accès qui ressemble à tort à un problème de permissions.
  • Considérer Cloudflare Pipelines comme prêt pour un flux critique en bêta : le service peut évoluer ou être temporairement instable, gardez toujours un mécanisme de traitement de secours tant qu’il n’atteint pas la disponibilité générale.

Dépannage : 8 problèmes courants et leurs solutions

SymptômeCause probableSolution
Erreur 403 Forbidden à l’uploadToken API sans permission d’écriture sur ce bucket précisRégénérer un token scoped avec la permission Write explicite
SignatureDoesNotMatchHorloge système désynchronisée ou région signée incorrecteSynchroniser l’heure système (NTP) et vérifier region=”auto”
Requête bloquée par le navigateur (CORS)Politique CORS absente ou origine non autoriséeAjouter le domaine exact dans AllowedOrigins et redéployer la règle
“Bucket already exists” à la créationNom de bucket non unique globalement sur le compteChoisir un nom plus spécifique, avec préfixe projet
Commande wrangler introuvableInstallation npm globale absente du PATHRéinstaller avec npm install -g wrangler et vérifier le PATH
Time-out sur un gros fichierUpload en un seul PutObjectCommand au lieu du multipartBasculer sur l’upload multipart pour les fichiers de plus de 100 Mo
Pipeline bloqué en statut “pending”Plan Workers gratuit, la bêta Pipelines exige un plan payantPasser au plan Workers payant ou attendre l’ouverture au plan gratuit
Facture Class A operations anormalement hauteListing du bucket répété sans pagination côté applicationMettre en cache les listings et paginer les appels ListObjectsV2

Conseils avancés pour la production

Une fois les 13 étapes maîtrisées, quelques ajustements font la différence entre un prototype et un service en production. Séparez systématiquement vos buckets par environnement (dev, staging, prod) plutôt que par préfixe dans un bucket unique : cela simplifie les permissions de token et réduit le risque qu’un script de test efface des données réelles.

Activez la réplication inter-buckets pour vos données les plus critiques, en dupliquant vers un second bucket dans la même juridiction avant de considérer une copie multi-juridiction (ce qui, pour des données personnelles UE, nécessite de rester en juridiction eu des deux côtés). Documentez enfin votre politique de rétention directement dans le nom des règles de cycle de vie (comme purge-logs-90j vu à l’étape 7) : un futur DPO ou auditeur doit pouvoir comprendre la politique en lisant simplement la liste des règles, sans creuser dans le code applicatif.

Pour approfondir la question de la localisation des données, la documentation officielle sur la localisation des données R2 détaille précisément quelles métadonnées restent hors juridiction même en mode eu. Sur le volet API, la référence de l’API S3 compatible liste les opérations supportées et celles qui diffèrent d’AWS. Pour le rappel réglementaire, le portail officiel du RGPD reste la référence pour vérifier vos obligations de résidence des données.

FAQ : les questions les plus posées sur Cloudflare R2

Qu’est-ce que Cloudflare R2 et en quoi diffère-t-il d’Amazon S3 ?
R2 est le service de stockage objet de Cloudflare, compatible avec l’API S3 d’Amazon. La différence principale tient à l’absence de frais d’egress et, depuis 2026, à la possibilité de choisir explicitement une juridiction de données (UE ou US) au niveau du bucket.

R2 est-il conforme au RGPD pour une entreprise française ?
R2 propose les outils techniques nécessaires à la conformité, notamment la juridiction eu qui garantit une résidence des données en Union européenne. La conformité effective dépend ensuite de votre contrat de traitement des données (DPA) avec Cloudflare et de votre propre registre de traitement.

Peut-on réellement réutiliser le SDK AWS avec R2 sans le modifier ?
Oui. Il suffit de pointer le client S3 vers l’endpoint R2 de votre compte et de renseigner les clés d’accès générées dans le tableau de bord Cloudflare, comme montré à l’étape 4 de ce guide.

Qu’est-ce que Cloudflare Pipelines et faut-il l’utiliser en production dès maintenant ?
Pipelines est un service d’orchestration de transformations de données sur R2, en bêta depuis août 2026 pour les comptes avec un plan Workers payant. Pour un flux critique, conservez un mécanisme de traitement de secours tant que le service n’a pas atteint la disponibilité générale.

Comment migrer un bucket S3 existant vers R2 sans interruption de service ?
Utilisez un outil comme rclone pour synchroniser les deux backends S3-compatibles, vérifiez le nombre d’objets transférés, puis basculez le trafic applicatif seulement après validation d’un échantillon, comme détaillé à l’étape 12.

Combien coûte Cloudflare R2 par rapport à S3 ?
Le coût de stockage brut de R2 est proche de celui de S3 selon les grilles tarifaires publiques des deux fournisseurs, mais R2 ne facture aucun frais d’egress, ce qui réduit fortement la facture totale pour les applications qui servent beaucoup de contenu à des utilisateurs finaux.

R2 remplace-t-il un CDN complet ?
Non. R2 est un service de stockage objet. Pour de la mise en cache et de la distribution de contenu à grande échelle, R2 se combine généralement avec le CDN Cloudflare ou avec Cloudflare Workers, mais ce n’est pas un CDN en soi.