À moins de gérer un datalake de 50 PB, un backend stateless multi-tenant ou des archives immuables, tu n’as pas besoin d’un S3-like. Et je t'explique pourquoi. Dans ton projet, sauf cas exceptionnel, on parle de quelques centaines de milliers de fichiers, quelques millions au pire, pour quelques Go à quelques To. Rien de plus. N'écoute pas les influenceurs qui veulent te vendre de la "scalabilité infinie". Tu veux juste lire et écrire des fichiers, pas bâtir AWS. Un simple système de fichiers POSIX fait ça très bien : rapide, simple, sans surcouche inutile. Object storage n’est pas un filesystem. Pas de ls, pas de grep, pas de rsync. Pas de modification partielle. Pas d’édition directe. Pas de chmod, pas de permissions système. Pas de logique Unix. Pas de sémantique standard. Le plus souvent, tu perds plus que tu ne gagnes. Et la haute dispo ? Elle existait bien avant S3. RAID, ZFS, DRBD, rsync, GlusterFS, CephFS & co font déjà le job. Tu travailles en local, sans latence, sans surcoût, sans vendor lock-in. Et si ton app n’est pas elle-même HA, inutile de complexifier le stockage. Tu pourras toujours le faire évoluer plus tard : c’est souvent la partie la plus simple à modifier. Servir des images, vidéos ou assets statiques à fort volume ? On savait faire il y a 20 ans. En 2005, je gérais une plateforme de contenu qui dépassait 4 Gb/s par serveur, sur des dizaines de machines. Conso RAM ? Moins de 500 MB par serveur Apache. Et pour les backups ? rsync, restic, borg, zfs send | recv, rdiff-backup... Les solutions ne manquent pas, et elles sont souvent plus rapides, plus scriptables, plus récupérables. Pas besoin de payer à la requête pour restaurer un répertoire. Oui, mais je suis déjà sur S3 ? Personne n’est parfait ;) Heureusement, on peut souvent tout récupérer avec rclone. Tu dois exposer tes fichiers via une API REST ? Pas besoin d’object storage pour ça non plus. Expose ton FS via Flask, FastAPI, Express, WebDAV ou autre. Et tu gardes tous les avantages POSIX derrière. Alors, l’object storage ça ne sert à rien ? Pas du tout. Il a des cas d’usage légitimes. On a des clients qui l’utilisent pour de bonnes raisons : Quand tu fais du multi-tenant cloud. Quand tu gères des archives WORM immuables. Quand tu bosses à très grande échelle avec un vrai besoin de découplage applicatif. Mais ce n’est pas un remplacement générique d’un filesystem. *C’est une solution spécifique à un problème spécifique.* Dans la majorité des cas, un vrai FS est plus rapide, plus robuste, plus simple.