Migrer un stockage de fichiers local vers S3 (Garage) : retour d'expérience client

Un client stockait ses fichiers directement sur le disque de son serveur Express : uploads utilisateurs, exports, backups d'application, tout au même endroit. Ça fonctionnait, jusqu'à ce que les alertes de seuil disque commencent à tomber — 80 %, puis 90 %, puis 100 %. Pas d'espace, pas de redondance, un seul point de défaillance pour 300 Go de données.

Ce post-mortem vient d'un projet client en production, pas d'un lab. On a migré ce stockage vers un cluster S3 auto-hébergé avec Garage, en gardant tout chez le client — pas de facture cloud supplémentaire, une redondance à 3 replicas, et un serveur principal enfin déchargé. Deux jours de développement, une après-midi de transfert. Voilà ce qu'on a fait, ce qu'on a écarté, et ce qui a failli mal tourner.

Le serveur Express du client stockait tout en local : un répertoire /uploads qui grossissait sans limite, sans réplication, sans stratégie de purge. Le monitoring disque envoyait des alertes automatiques à 80 %, 90 %, puis 100 % d'occupation — le dernier seuil ayant déjà été franchi une fois avant qu'on intervienne.

Le risque n'était pas seulement l'espace disque. En cas de panne matérielle du serveur, il n'existait aucune copie des fichiers ailleurs. Une seule défaillance disque suffisait à perdre l'intégralité des uploads clients — factures, documents, médias — sans aucun filet de sécurité.

On gère ce type de setup pour des clients qui ne veulent pas d'équipe DevOps interne. En parler.

AWS S3 était l'option évidente sur le papier : robuste, largement documenté, aucune infrastructure à maintenir. Mais à 300 Go et une croissance continue, le coût mensuel cumulé (stockage + sortie de données) dépassait largement ce que le client était prêt à payer pour un service qui, en pratique, allait tourner sur un serveur déjà loué et sous-utilisé. Sortir les données du réseau du client pour les stocker ailleurs n'apportait aucun bénéfice concret dans ce cas précis.

MinIO a été écarté pour une raison différente : le projet open source est passé en mode maintenance fin 2025, avant que son dépôt communautaire ne soit archivé début 2026, après le retrait des fonctionnalités d'administration de l'édition gratuite. Construire une infrastructure de production sur un projet dont l'avenir open source est incertain n'avait pas de sens pour un déploiement fait pour durer des années.

Garage, développé par Deuxfleurs, a coché toutes les cases : compatible API S3, pensé pour l'auto-hébergement sur du matériel modeste, réplication native configurable, licence libre stable. C'est ce qu'on a retenu.

Le déploiement s'est fait directement sur le serveur privé du client, à côté de l'application existante — pas de nouveau serveur à provisionner, pas de coût d'infrastructure supplémentaire. Garage a été configuré avec un facteur de réplication de 3 : chaque fichier est stocké en trois exemplaires, répartis pour survivre à la perte d'un nœud ou d'une partition disque sans perte de données.

Côté application, le changement principal a porté sur la couche de stockage du serveur Express : remplacer les écritures directes sur le système de fichiers local par des appels à l'API S3-compatible de Garage. Le SDK AWS S3 fonctionne tel quel avec Garage — aucune bibliothèque spécifique à apprendre, juste un endpoint et des credentials différents.

// Avant : écriture directe sur le disque local
fs.writeFileSync(`/uploads/${fileId}`, buffer)
 
// Après : écriture via l'API S3-compatible (Garage)
await s3Client.send(new PutObjectCommand({
  Bucket: "client-uploads",
  Key: fileId,
  Body: buffer,
}))

Le transfert des 300 Go existants s'est fait en une après-midi, fichier par fichier, avec vérification d'intégrité à chaque copie avant de couper l'ancien chemin de stockage.

Le coût de stockage tombe à zéro parce que Garage tourne sur une machine que le client louait déjà — aucune facture cloud supplémentaire, contrairement à une bascule vers AWS S3. La latence reste identique parce que Garage sert les fichiers depuis le même réseau local que l'application, sans aller-retour vers un datacenter externe.

Pendant la mise en place, on a supprimé un replica par erreur — une commande d'administration Garage exécutée sur le mauvais nœud pendant les tests de configuration. Aucune perte de données : il restait deux copies sur les trois, largement suffisant pour reconstruire automatiquement la réplication manquante une fois l'erreur corrigée.

Ça n'a rien cassé, mais ça montre bien pourquoi un facteur de réplication de 3 n'est pas un excès de prudence. Avec seulement 2 replicas, la même erreur aurait laissé une seule copie du fichier en jeu pendant la réparation — un risque qu'on préfère ne jamais courir sur des données clients.

Si votre application stocke des fichiers directement sur le disque d'un serveur applicatif, la question n'est pas si vous allez manquer d'espace ou perdre des données un jour, mais quand. Découpler le stockage de fichiers de l'application, avec une API S3-compatible, résout ce problème sans dépendre d'un fournisseur cloud si votre infrastructure existante peut l'accueillir.

Pour les cas où l'auto-hébergement n'a pas de sens (pas de serveur existant, besoin de CDN mondial), notre comparatif hébergement mutualisé, VPS et cloud managé détaille les options et leurs coûts réels. Et pour les projets qui veulent rester hors du cloud américain tout en gardant une infrastructure gérée, on a testé Kyun.sh, un hébergeur cloud privacy-first sans KYC, qui suit la même logique de contrôle des données.

Cet article a été rédigé avec l'aide de l'IA et relu par un humain avant publication.