Un SaaS de facturation stocke les PDF clients dans /var/www/uploads. À 200 Go, les sauvegardes nocturnes dépassent la fenêtre autorisée, le VPS sature, et migrer vers une nouvelle instance signifie copier des heures de fichiers. Personne n'a prévu que les médias grandiraient dix fois plus vite que le code.
Le stockage objet (S3 et API compatibles) existe pour ce découplage : fichiers durables, serveur web éphémère. Ce n'est pas une mode cloud — c'est une réponse à un volume qui ne rentrera plus sainement sur un disque local.
Pourquoi le disque local finit par mentir
Sur un VPS ou un mutualisé, uploads et code partagent le même filesystem. Problèmes prévisibles :
- Backups — snapshotter 500 Go de PDF avec la base double le temps et le coût.
- Scaling horizontal — deux serveurs web ne partagent pas
/uploadssans NFS ou objet. - Restauration — remonter un serveur ne suffit pas si les fichiers étaient sur le disque mort.
Le stockage objet externalise les blobs avec redondance, versioning et politiques de rétention natives.
| Critère | Disque local | Stockage objet |
|---|---|---|
| Croissance | Limite du VPS | Quasi illimitée (facturée) |
| Multi-serveur | Complexe | URL ou SDK uniforme |
| Coût egress | Souvent inclus VPS | Ligne séparée — à surveiller |
| Permissions | chmod Unix | IAM / policies bucket |
Le disque local gagne en simplicité au début. L'objet gagne dès que les médias deviennent un actif à part entière.
Architecture type pour un projet web
Bucket privé + CDN ou signed URLs. Les objets restent privés ; le CDN met en cache les médias publics. Les fichiers sensibles passent par des URLs signées à durée limitée.
Préfixe par environnement. prod/media/, staging/media/ — jamais le même bucket sans garde-fous.
Cycle de vie. Archiver vers une classe froide après 90 jours, supprimer les temporaires après 7 jours. Automatisé côté bucket, pas via cron maison.
Métadonnées en base, blobs en objet. La base garde clé, mime, taille ; le fichier vit dans le bucket. Indispensable pour recherche et droits.
Coûts cachés : egress et requêtes
La facture n'est pas que le Go stocké :
- Egress — sortie vers Internet ou vers une autre région cloud.
- Requêtes GET/PUT — millions de mini-fichiers = coût API.
- CDN devant bucket — réduit egress origine, ajoute une ligne CDN.
Estimez avec votre trafic réel : un site média lourd peut payer plus en bande passante qu'en stockage. Comparez les offres européennes (Scaleway Object Storage, OVH, Infomaniak Swiss Backup/object…) dans notre annuaire.
Erreurs fréquentes à l'intégration
Bucket public par défaut. Scan bots + facture surprise. Privé par défaut, public explicitement si besoin.
URLs hardcodées avec région AWS. Changer de fournisseur = réécrire toute la base.
Pas de versioning. Une suppression accidentelle devient définitive.
Sync bidirectionnelle manuelle. Préférez une source de vérité (objet) et des jobs idempotents.
Le sommet : l'objet ne backup pas votre base
C'est le piège post-migration : « tout est sur S3, on est saués ». Croisez avec stratégie de sauvegarde et test de restauration.
Décider et avancer sans angle mort
- Seuil — définissez à partir de quelle taille ou croissance vous basculez (ex. 50 Go ou +10 Go/mois).
- Choisissez un fournisseur EU avec DPA si données personnelles dans les fichiers.
- Intégrez SDK ou plugin avec bucket privé + CDN.
- Activez versioning et cycle de vie.
- Testez restauration d'un objet + cohérence base.
Consultez le comparateur pour filtrer les hébergeurs proposant stockage objet intégré.
Questions fréquentes
Stockage objet ou disque VPS : où trancher ?
Dès que les médias dépassent quelques dizaines de Go, croissent vite, ou doivent survivre à un changement de serveur. Sous ~5 Go d'uploads, le disque local reste plus simple.
Les fichiers objet sont-ils publics par défaut ?
Non. Configurez des buckets privés et servez via URLs signées ou CDN devant le bucket.
Compatible S3 signifie-t-il identique à AWS ?
L'API est largement compatible, mais egress, régions, SLA et cycle de vie varient selon le fournisseur.
Comment migrer des médias WordPress existants ?
Plugins dédiés ou rsync vers bucket + réécriture URLs en base. Testez sur staging ; prévoyez double écriture le temps de la bascule.
Quand les uploads deviennent plus lourds que le déploiement, le stockage objet n'est plus une option « cloud » — c'est la condition pour que votre serveur reste un serveur.