Contexte : MinIO passe en maintenance mode
MinIO était la référence pour le stockage objet open source, utilisé massivement par des clusters Kubernetes, pipelines CI/CD, data lakes, et des solutions SaaS.
Le 3 décembre 2025, l’annonce tombe via le README du répertoire GitHub : le projet MinIO passe en “maintenance mode”. Concrètement, cela signifie la fin du développement de nouvelles fonctionnalités et l’arrêt de l’acceptation des pull requests communautaires. Une décision commerciale qui peut être compréhensible, mais qui a créé un point de rupture pour de nombreuses équipes.
Il y avait quelques signes avant-coureurs de ce rug-pull, notamment en juin 2025 MinIO a retiré certaines fonctionnalités d’administration de la console web dans la version community. Mais ce n’était pas suffisant pour le voir arriver.
L’urgence de l’alternative : Du jour au lendemain, les équipes d’infrastructure et de stockage se sont retrouvées au pied du mur. Deux options se présentent :
- Passer à la caisse avec la solution entreprise (MinIO AIStor), dont le ticket d’entrée avoisine les 96 000 $/an selon les estimations communautaires (pour un cluster de 400 To).
- Trouver une alternative open source crédible dans l’urgence absolue.
Pour celles et ceux qui refusent d’être otages d’une licence propriétaire, la chasse à l’alternative est ouverte.
Périmètre : Cet article s’adresse aux équipes gérant des infrastructures de stockage critiques: clusters multi-sites, exigences de résilience forte (RPO=0), capacités > 50 To, et environnements de production avec SLA stricts. Pour des besoins plus modestes (dev local, < 20 To, mono-site), une des quatre solutions décrites plus bas peut constituer une bonne alternative.
Cadre de décision
Voici les critères de sélection sur lesquels nous nous sommes basés pour trouver la meilleure alternative en 2026 :
Gouvernance : l’open source ne suffit pas. Il faut une solution soutenue par une fondation derrière pour éviter le risque de single-vendor comme MinIO. Une fondation comme la Linux Foundation ou la CNCF impose une gouvernance multi-stakeholder : décisions collégiales, impossibilité pour un seul acteur de changer la licence, roadmap transparente. MinIO, Redis, Terraform, MongoDB… tous contrôlés par une seule entreprise qui a fini par pivoter vers des licences restrictives. Avec une fondation, ce scénario est structurellement impossible.
Licence : gratuit avec usage commercial, notamment Apache 2.0 ou LGPL
Compatibilité S3 : support complet de l’API S3 pour faciliter la migration
Maturité : une solution qui a fait ses preuves, qui a été testée pendant un moment en production et non pas des solutions toujours en phase de bêta-test
Scalabilité : une solution capable de stocker un très grand volume de données allant du Téraoctet au Pétaoctet ou plus sans dégradation de performance
Résilience : une solution capable de protéger les données en cas de sinistres par des mécanismes de protection multi-site, protection multi-géo, RPO=0 via réplication synchrone.
Les alternatives évaluées
1. SeaweedFS
C’est un projet très bien conçu, inspiré de l’architecture Facebook Haystack. Il sépare clairement les métadonnées (Master) du stockage pur (Volume Servers).
Points forts
Il est très performant sur les petits fichiers (le cauchemar habituel du stockage objet). Côté Ops, c’est léger : un binaire Go simple à déployer, peu gourmand en RAM par rapport à Java ou C++. Idéal pour réduire la facture hardware.
Points faibles
Il y a des limites structurelles sur la résilience, notamment l’impossibilité d’écrire pendant le backup des volumes, ce qui est bloquant pour du 24/7 critique. Mais le vrai “No-Go”, c’est la gouvernance. Derrière SeaweedFS, c’est une seule entreprise (et son créateur) et non pas une fondation. On risque de reproduire le pattern MinIO.
2. RustFS
Projet très récent (fin 2024) qui a comme ambition de remplacer MinIO en misant tout sur le langage Rust et l’optimisation matérielle.
Points forts
L’optimisation est brutale. Il utilise les instructions SIMD des CPU modernes pour accélérer les calculs d’Erasure Coding et de checksums (2,3x plus rapide que MinIO selon les benchmarks). Ça permet de tenir de grosses charges sur du hardware standard moins cher.
Points faibles
C’est trop jeune. En 2026, le projet est encore en version alpha. Mettre des pétaoctets de données critiques sur une solution qui a zéro validation long-terme en production, c’est du suicide opérationnel. Sur le plan de la gouvernance, sans fondation, les créateurs de RustFS conservent le droit légal de changer la licence un jour (exactement comme MinIO).
3. Garage
Garage est aussi écrit en Rust, mais avec une philosophie différente : la résilience avant la vitesse brute. Il utilise des structures de données CRDT (Conflict-free Replicated Data Types) pour gérer la cohérence.
Points forts
Il est conçu pour tourner sur du matériel hétérogène et peu fiable (vieux serveurs, réseau lent) réparti sur plusieurs zones géographiques. Il se “répare” tout seul. Côté gouvernance, c’est un modèle rassurant : le projet est porté par une association française à but non lucratif (Deuxfleurs). C’est la garantie d’une souveraineté numérique européenne, loin de la Silicon Valley.
Points faibles
Bien que techniquement fascinant, Garage fonctionne sur un modèle “Full Mesh” où chaque nœud doit se synchroniser avec tous les autres. Cela fonctionne bien pour des clusters de petite taille (10 à 20 nœuds), mais au-delà de 100 nœuds, le protocole de synchronisation (gossip/CRDT) peut devenir bavard. De plus, sa gouvernance reste très communautaire (associative) et n’a pas la puissance de la Fondation Linux pour garantir le support entreprise à long terme.
4. CubeFS
Un projet “graduated” de la CNCF, solide sur la gouvernance (aucun risque de rachat), utilisé massivement par des géants chinois (JD.com, OPPO, …)
Points forts
Architecture hybride (MetaNodes / DataNodes) qui permet de scaler les performances indépendamment de la capacité. C’est du solide, capable de gérer des fichiers et des objets simultanément.
Points faibles
CubeFS est conçu prioritairement comme un système de fichiers (POSIX) optimisé pour les conteneurs, avec le S3 comme fonctionnalité secondaire. De plus, bien que le code soit open source, la dynamique communautaire et la documentation technique pointue restent très orientées vers les grands acteurs de la tech chinoise.
Le choix de Ceph
Le choix de Ceph ne s’est pas fait par défaut, mais par conviction stratégique. Il est moins séduisant au premier abord, mais indestructible sur la durée.
1. Gouvernance
C’est l’argument décisif en 2026. Ceph est sous la Ceph Foundation (Linux Foundation) depuis 2018. Contrairement à MinIO, il n’y a pas d’entreprise unique qui possède le copyright et peut décider du jour au lendemain de le mettre en “mode maintenance”. C’est un projet communautaire avec des contributeurs majeurs (Red Hat, Canonical, Intel, IBM).
2. Maturité
Ceph est un projet né en 2004 dans le milieu académique, avec plus de 20 ans d’évolution. Il n’est pas en “bêta”. Des institutions comme le CERN l’utilisent pour gérer des centaines de pétaoctets de données. Quand on cherche une alternative pour les 10 prochaines années, on ne parie pas sur une promesse, mais sur un historique.
3. Résilience et échelle
Sur la protection des données, Ceph a fait ses preuves sur des environnements de très grande échelle. Via la gateway S3 (RGW), il supporte nativement la réplication multi-sites (active-active ou active-passive). Il offre des mécanismes de “Self-Healing” (auto-réparation) et d’Erasure Coding très fins. Là où d’autres solutions craquent quand on perd plusieurs disques ou nœuds simultanément, Ceph se rebalance tout seul.
4. Pas que du S3
MinIO ne faisait que de l’objet. Ceph nous offre une plateforme unifiée :
• Objet (RGW) : Pour remplacer MinIO (compatible S3).
• Bloc (RBD) : Pour les volumes persistants Kubernetes (PVC).
• Fichier (CephFS) : Pour les besoins POSIX partagés.
Avoir une seule stack technologique pour tout le stockage simplifie finalement l’architecture globale, même si l’outil en lui même est complexe.
Le prix de la robustesse: la complexité
Soyons honnêtes, Ceph n’est pas adapté à tout le monde. Pour des besoins inférieurs à 10-20 To, c’est clairement over-kill. La courbe d’apprentissage est raide et l’effort opérationnel (“Day 2 ops”) est réel. Cependant, grâce à des orchestrateurs modernes comme Rook (pour Kubernetes), cette complexité est aujourd’hui largement abstraite. D’autre part, le coût politique d’un verrouillage propriétaire est beaucoup moins important que le coût d’entrée technique.
Conclusion
Le choix de Ceph ne s’est pas fait par facilité, mais par nécessité. Certes, c’est une technologie exigeante qui demande une véritable maîtrise technique, tant pour le déploiement initial (Day 1) que pour la maintenance opérationnelle (Day 2).
Cependant, face aux limites de scalabilité de Garage ou aux incertitudes de jeunesse de RustFS, Ceph reste la seule alternative “Production Ready” sans risque de gouvernance capable d’encaisser des charges massives. C’est le prix à payer pour une infrastructure robuste et pérenne.
Au-delà de la technique, ce coup MinIO nous a appris à la dure qu’en 2026, l’open Source ne suffit plus. Avoir accès au code sur GitHub ne vous protège de rien si le projet est piloté par une seule entité commerciale. La véritable sécurité, c’est la Gouvernance Ouverte. Désormais, avant d’intégrer une brique critique dans votre stack, ne regardez plus seulement la licence, regardez qui est derrière le projet. Si ce n’est pas une fondation neutre (Linux Foundation, CNCF, Apache), vous ne construisez pas sur du solide, vous risquez toujours des rug-pulls.