Stockage objet pour les fichiers utilisateurs : arrêtez de remplir le disque de votre serveur

Pourquoi le disque local vous lâche

Un dossier rempli de fichiers uploadés fonctionne très bien… jusqu'au jour où plus rien ne fonctionne. Le disque se remplit silencieusement en arrière-plan, et le premier symptôme est souvent votre base de données ou vos logs qui échouent parce que le dossier d'uploads a avalé le dernier gigaoctet. Pire : beaucoup de configurations de déploiement remplacent tout le répertoire de release — un déploiement, et tous les fichiers que vos utilisateurs vous avaient confiés disparaissent.

Vient ensuite la montée en charge. Dès que vous ajoutez un deuxième serveur derrière un répartiteur de charge, la moitié des requêtes atterrissent sur une machine qui ne possède pas le fichier. Les sessions persistantes et les bricolages rsync ne font que repousser le problème. Des fichiers qui vivent sur le disque d'une seule machine sont, par définition, un point de défaillance unique.

Le flux d'upload qui fonctionne

Le schéma est simple : le client envoie le fichier à votre API (ou directement au bucket via une URL présignée), votre API le pousse dans un bucket Nest Storage, et le bucket renvoie une clé d'objet. C'est cette clé — pas le fichier — que vous stockez dans votre base de données.

Votre base de données reste petite et rapide, vos serveurs restent sans état, et le fichier lui-même vit dans un espace conçu pour la durabilité. Voici tout le flux en deux lignes :

const { key } = await nest.upload("avatars", file);
await db.user.update({ id, avatarKey: key });

Buckets privés ou publics

Tous les fichiers ne méritent pas le même traitement. Les logos, les images produit et les autres ressources du site peuvent vivre dans un bucket public et être servis directement — idéalement via un CDN avec un domaine personnalisé. Tout le monde peut les lire, et c'est justement le but.

Les documents des utilisateurs, c'est une autre histoire. Factures, contrats et pièces d'identité vont dans un bucket privé, et votre API accorde l'accès en générant des URL signées qui expirent au bout de quelques minutes. Le fichier n'est jamais accessible publiquement ; seul le lien que vous venez de créer l'est.

• Bucket public pour les images et les ressources statiques
• Bucket privé et URL signées à expiration pour les documents
• Un bucket distinct par environnement, pour que le staging ne touche jamais aux fichiers de production

Nommage, versioning et nettoyage

Les clés d'objet sont votre système de classement : choisissez vos préfixes avec soin. avatars/{userId}/… ou invoices/2026/04/… rendent les fichiers faciles à lister, migrer et supprimer par utilisateur ou par date. Un URI nest:// avec une structure de clés propre se documente tout seul.

Activez le versioning sur les buckets où un écrasement accidentel ferait mal — l'ancienne version reste à un appel API de distance au lieu d'être perdue à jamais. Et ajoutez des règles de cycle de vie pour balayer les fichiers orphelins : les uploads dont la ligne en base a été supprimée, ou les fichiers temporaires vieux de plus d'une semaine, sont nettoyés automatiquement au lieu de vous coûter de l'argent indéfiniment.

Ce que ça coûte

Avec Nest Storage, vous ne payez que deux choses : le stockage que vous utilisez réellement et la bande passante que vous servez réellement. Pas de facturation à la requête, pas de lignes surprises — les prix sont en ₹, prévisibles et faciles à anticiper avant de vous engager.

Il existe un niveau gratuit suffisamment généreux pour les projets personnels : la fonctionnalité d'upload d'avatars que vous construisez ce week-end ne coûte rien tant que les vrais utilisateurs ne sont pas là. Et quand ils arrivent, le même bucket, la même API et les mêmes clés continuent de fonctionner — simplement avec un quota plus grand.