Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Le 13 février 2026, MinIO Inc. a archivé la communauté minio référentiel. Le projet avait dépassé les 59 000 étoiles et plus d'un milliard de téléchargements Docker. La base installée couvre le stockage d'objets Kubernetes, les référentiels d'artefacts CI/CD, les registres de modèles d'apprentissage automatique et les lacs de données sur site. L'ensemble fonctionne désormais sur une base de code qui ne bénéficie plus des correctifs de sécurité en amont.
Pour les équipes qui ont choisi MinIO afin de mettre en place un stockage objet compatible S3 sur les serveurs qu’elles gèrent, la question concrète est de savoir où trouver un support et une maintenance de sécurité continus pour MinIO, maintenant que le support en amont n’est plus assuré. Cet article passe en revue les changements intervenus, les options réalistes et la place qu’occupe le support à cycle de vie illimité de TuxCare dans ce contexte.
Quels changements ont eu lieu et quand ?
Cette transition s'est déroulée par étapes sur une période d'environ quinze mois.
Au début de l'année 2025, MinIO Inc. a supprimé la plupart des fonctionnalités d'administration de la console web de l'édition communautaire, ne conservant qu'un simple navigateur d'objets. L'ensemble des fonctionnalités de gestion a été transféré vers le produit commercial de l'entreprise. La publication de versions binaires précompilées a progressivement cessé au cours de cette même période ; l'édition communautaire n'était désormais plus disponible que sous forme de code source.
Le 3 décembre 2025, l'entreprise a mis le dépôt communautaire en mode maintenance. Le développement de nouvelles fonctionnalités a été suspendu, et les correctifs de sécurité ont été traités au cas par cas plutôt que selon un calendrier précis.
Le 13 février 2026, le dépôt a été archivé sur GitHub. Il est désormais en lecture seule : plus de nouveaux commits, plus de nouvelles pull requests, et plus de correctifs de sécurité de la part de MinIO Inc. sur le code source de la communauté. Le support officiel de MinIO a été entièrement transféré vers AIStor, son successeur commercial.
Plusieurs vulnérabilités (CVE) ont déjà été signalées concernant la dernière version communautaire, notamment CVE-2026-39414, CVE-2026-34204, GHSA-9c4q-hq6p-c237 et GHSA-hv4r-mvr4-25vw. MinIO Inc. a fourni des correctifs pour certains d'entre eux dans AIStor, mais aucun correctif n'est disponible pour la base de code communautaire archivée sur laquelle s'exécute la base installée existante. Pour les équipes qui souhaitent conserver leur déploiement actuel, il s'agit là d'une lacune évidente dans le support de MinIO.
Pourquoi est-ce important pour les opérateurs ?
Deux défis se posent à toute équipe utilisant MinIO en production.
Le premier aspect concerne la conformité. Les normes PCI DSS, HIPAA, SOC 2 et FedRAMP imposent toutes des délais de correction pour les vulnérabilités connues – généralement 30 jours pour les failles à haut risque, parfois moins. Une politique en amont « au cas par cas » était déjà difficile à concilier avec ces délais. Un référentiel archivé sans correctifs supplémentaires est tout simplement inenvisageable. Les constatations d’audit commencent à s’accumuler dès qu’un nouveau CVE est publié et que le compte à rebours commence.
Le deuxième facteur est la dérive des risques. Chaque nouvelle vulnérabilité CVE révélée depuis la dernière version communautaire rend la situation opérationnelle plus difficile à défendre en interne. Les équipes de sécurité montent en puissance. Les registres des risques s'épaississent. L'inaction a elle aussi une date butoir, fixée par le prochain audit.
Les options envisagées
Les opérateurs qui utilisent MinIO aujourd'hui ont quatre options réalistes.
| Option | Coût | Ce qu'il faut | Compromis |
|---|---|---|---|
| Restez sur la version archivée | $0 | Rien | Les vulnérabilités CVE se multiplient ; elles ne sont pas viables dans la plupart des cadres de conformité |
| Passer à AIStor | À partir d'environ 96 000 $ par an pour ≤ 400 TiB d'espace utilisable + frais de migration | Migration des produits, nouvelles licences, recyclage | Un produit différent, un modèle opérationnel différent |
| Passer à une solution open source | Temps de conception | Transfert de données, validation de la compatibilité avec S3, renouvellement de la certification | Projet d'envergure ; aucune alternative ne permet un remplacement à l'identique |
| Souscrire à un programme de maintenance proposé par un tiers | Frais d'abonnement | Continuer à utiliser la version actuelle de MinIO | Cela dépend de la portée du programme et de son mode de mise en œuvre |
Parmi les alternatives open source à prendre en considération, on peut citer SeaweedFS, Garage, RustFS et Ceph RGW. Chacune d'entre elles est un projet concret, soutenu par des développeurs actifs, et présente une architecture différente de celle de MinIO. Aucune d'entre elles ne constitue toutefois un substitut direct.
La quatrième option – la prise en charge de MinIO par des tiers – concerne les programmes qui dérivent du code source communautaire et continuent à le mettre à jour. Leur portée, leur mode de prestation et leurs engagements varient. Le programme « Endless Lifecycle Support » (ELS) de TuxCare pour MinIO en est un exemple. La suite de cet article présente en détail ce qu’il offre et en quoi il se distingue des autres solutions.
Ce qu'offre ELS pour MinIO
Le support à vie proposé par TuxCare pour MinIO permet aux clients de continuer à utiliser la version de MinIO qu'ils exploitent déjà. Les correctifs sont fournis sous forme de paquets binaires (RPM, DEB et binaires Go) qui s'intègrent directement aux déploiements existants sur machines virtuelles, serveurs physiques et sur site, sans nécessiter de refonte de l'environnement d'exécution.
Chaque abonnement comprend :
- Réponse rapide aux CVE via SLA, aussi longtemps que le client a besoin de la version prise en charge
- Couverture complète des dépendances directes et transitives, sans frais supplémentaires
- Mises à jour testées qui garantissent la compatibilité avec les déploiements existants
- Intégration « plug-and-play » avec les flux de travail existants et les pipelines CI/CD
- Mises à jour signées et inviolables provenant des dépôts hébergés par TuxCare
- Une liste des composants logiciels (SBOM) est fournie avec chaque version mise à jour. MinIO étant un binaire Go comportant des dépendances intégrées, la SBOM offre aux opérateurs et aux auditeurs un manifeste unique et faisant autorité sur le contenu réel de chaque version.
- Contexte VEX (Vulnerability Exploitability eXchange) indiquant quelles vulnérabilités CVE de la SBOM ont déjà été corrigées, afin que les équipes de sécurité puissent concentrer leurs efforts sur les points qui nécessitent encore une intervention
- Une assistance spécialisée disponible 24 h/24 et 7 j/7, couvrant le triage des vulnérabilités CVE, les demandes de correctifs personnalisés et le dépannage
Les correctifs sont gérés par les ingénieurs de TuxCare et déployés selon un calendrier garanti par un accord de niveau de service (SLA). Le client continue d'utiliser le code qu'il a validé, tandis que l'assistance pour MinIO est assurée par un fournisseur qui prend en charge ces services sur le plan commercial.
En quoi ELS se distingue-t-il des autres options d'assistance MinIO ?
Trois caractéristiques définissent l'approche d'ELS en matière de maintenance de MinIO.
- Le premier concerne le modèle de distribution. ELS est fourni sous forme de paquets binaires. Les autres programmes de maintenance ne sont disponibles que sous forme d'images de conteneurs sécurisées, ce qui convient aux environnements natifs Kubernetes, mais ne s'adapte pas aux déploiements exécutant MinIO sur des machines virtuelles, du matériel nu ou en local. Un client utilisant MinIO en dehors de conteneurs ne peut pas adopter une solution exclusivement basée sur des conteneurs sans repenser son déploiement.
- Le deuxième point concerne l'étendue de la couverture. ELS s'engage à intégrer les correctifs pour les dépendances directes et transitives dans le cadre de l'abonnement standard. MinIO intègre une arborescence complexe de dépendances Go, et les vulnérabilités CVE affectant ces dépendances intégrées nécessitent régulièrement des intégrations non négligeables. Ce travail fait partie de l'engagement standard d'ELS et ne fait pas l'objet d'un supplément de coût.
- Le troisième élément est l'engagement en matière de livraison. Les correctifs sont fournis selon une fréquence définie et garantie par un accord de niveau de service (SLA), avec des délais de réponse liés au niveau de gravité. Les cadres de conformité tels que PCI DSS, HIPAA, SOC 2 et FedRAMP fixent des délais stricts pour la mise en œuvre des mesures correctives, et c'est grâce à un calendrier de livraison prévisible que les opérateurs peuvent les respecter.
Ces caractéristiques revêtent une importance particulière pour les opérateurs qui utilisent MinIO en dehors de conteneurs, notamment lorsqu'ils sont soumis à des exigences de conformité.
Et maintenant ?
Si vous utilisez MinIO en production et que vous avez besoin d'une assistance continue pour MinIO allant au-delà de l'archivage en amont, le service « Endless Lifecycle Support » de TuxCare est désormais disponible.
Pour en savoir plus ou pour contacter notre équipe afin de discuter de vos besoins en matière d'environnement, rendez-vous sur : https://tuxcare.com/endless-lifecycle-support/minio-eol-support/.
