Téléchargements protégés avec Supabase, Stripe, R2 et Cloudflare

Les produits numériques payants ont besoin d’une base ennuyeuse mais importante : les acheteurs doivent pouvoir payer, se connecter et télécharger le bon fichier sans exposer un lien ZIP public.

ImgKit utilise un schéma simple de téléchargements protégés :

1. Supabase gère la connexion.
2. Stripe gère le checkout.
3. L’application enregistre l’accès au produit.
4. R2 stocke les fichiers privés.
5. Cloudflare Functions renvoient des URL signées de courte durée.

Pourquoi les téléchargements protégés sont importants

Si un fichier ZIP payant se trouve dans un dossier public, toute personne ayant l’URL peut le partager. Cela peut être acceptable pour des échantillons gratuits, mais c’est faible pour des produits payants.

Les téléchargements protégés ajoutent une vérification côté serveur :

• Qui est l’utilisateur ?
• Cet utilisateur a-t-il acheté le produit ?
• L’asset de téléchargement est-il actif ?
• Le serveur peut-il générer une URL temporaire ?

L’utilisateur obtient toujours un téléchargement normal dans le navigateur, mais le chemin de stockage permanent n’est pas public.

Connexion Supabase

Supabase fournit à ImgKit une identité de compte. Un acheteur se connecte par e-mail, puis le checkout et les téléchargements peuvent être rattachés à ce compte.

Pour les premiers produits, la connexion par e-mail suffit. Les acheteurs n’ont pas besoin d’un tableau de bord compliqué juste pour télécharger un fichier protégé.

Checkout Stripe

Stripe gère la session de paiement. L’acheteur lance le checkout depuis le site, paie et revient sur ImgKit.

Le serveur doit alors relier la session terminée à l’accès au produit. Cela peut se faire via des webhooks et un point de terminaison de synchronisation du checkout, afin que l’acheteur voie l’accès peu après le paiement.

Accès au produit

L’accès au produit doit être séparé des étiquettes d’adhésion génériques. Un acheteur peut posséder un produit mais pas un autre.

Dans le cas d’ImgKit, le Builder Case Study abandonné utilisait son propre droit produit. Ce modèle permet encore d’exister pour des produits futurs sans transformer chaque acheteur en membre d’un abonnement large.

Stockage privé R2

R2 stocke le paquet ZIP réel en dehors du bundle public du site. Le site ne lie pas directement à l’objet R2.

À la place, un point de terminaison de téléchargement vérifie l’accès et demande une URL temporaire au stockage.

URL signées

Une URL signée donne un accès temporaire à un fichier privé. Si l’URL expire après une courte fenêtre, elle devient moins utile à partager de façon permanente.

Ce n’est pas un DRM lourd. C’est une limite pratique de livraison payante pour un MVP.

Ce qu’ImgKit a appris

La page archivée de ImgKit Builder Case Study préserve les décisions d’implémentation autour : pourquoi la vente de logiciels payants a été suspendue, comment les téléchargements protégés ont été façonnés, et comment le paquet de code source a été testé comme première offre payante.

Ce contexte compte parce que le flux technique n’est que la moitié du produit. L’autre moitié consiste à décider quoi vendre en premier.

Questions fréquentes

Pourquoi ne pas mettre les fichiers ZIP payants dans un dossier public ?

Les fichiers publics peuvent être partagés directement. La livraison protégée permet au serveur de vérifier l'accès du compte et de renvoyer des URL de téléchargement de courte durée.

Stripe stocke-t-il le fichier ?

Non. Stripe gère le paiement. L'accès au produit et la livraison du téléchargement sont gérés par l'application et le stockage privé.

Pourquoi utiliser des URL signées ?

Les URL signées permettent de télécharger un fichier privé pendant une durée limitée sans exposer un accès permanent au stockage.