Le contexte 2026, sans détours

Le marché du stockage objet on-premise se réorganise depuis trois ans. IBM a repositionné COS plusieurs fois depuis le rachat de Cleversafe en 2015 : d'abord comme produit autonome, ensuite poussé vers IBM Storage Ready Nodes, puis intégré dans le discours « cyber vault » du portfolio Storage Defender. Les clients historiques de Cleversafe — beaucoup d'entre eux avec des déploiements legacy de plus de dix ans sur du matériel Cisco UCS en fin de vie — se demandent quel est le chemin pour les cinq prochaines années avant qu'IBM change de message encore une fois.

Ceph, pendant ce temps, a fait le contraire. Il s'est consolidé. La version actuelle Tentacle (20.2.1, avril 2026) clôt un cycle de maturité entamé avec Reef et Squid. Les contributeurs actifs incluent le CERN, DigitalOcean, Bloomberg, OVH, Clyso, Red Hat/IBM et SUSE. Il est difficile de trouver un projet open source d'infrastructure avec autant d'activité soutenue.

Entre les deux se trouve IBM Storage Ceph : Ceph upstream empaqueté et supporté commercialement par IBM, successeur direct de Red Hat Ceph Storage depuis le rachat de Red Hat. Techniquement, c'est le même Ceph. Commercialement, c'est un abonnement avec SLA vendor tier-1. Il existe parce que certains clients ont des politiques internes ou des cahiers des charges qui exigent un support enterprise avec un nom connu, et que Ceph upstream « nu » ne passe pas ce filtre — même s'il est techniquement identique.

Trois produits, trois modèles commerciaux, trois profils clients distincts.

Les trois protagonistes

Survolez chaque carte pour plus de détails · La « bonne » option dépend de la réalité opérationnelle de chaque client

Les trois fonctionnent. Les différences techniques qui importent ne tiennent pas à ce qu'ils font, mais à comment ils s'opèrent et combien ils coûtent sur cinq ans. Pour une comparaison approfondie de Ceph face à d'autres solutions de stockage distribué — Storage Scale, GPFS, NFS, SMB — nous avons un article dédié : IBM Storage Ceph vs Storage Scale, GPFS, GFS2, NFS et SMB.

Pourquoi nous préférons l'open source

Ce n'est pas de l'idéologie. C'est le résultat de voir, projet après projet, qu'un client avec une bonne équipe interne ou un partenaire compétent obtient sur Ceph upstream la même stabilité opérationnelle que sur n'importe quelle alternative commerciale — avec beaucoup plus de liberté et à moindre coût.

Les arguments sont concrets. Le lock-in des produits propriétaires ne se limite pas au matériel — il concerne aussi la feuille de route. Si IBM repositionne COS encore une fois — et c'est arrivé plusieurs fois depuis 2015 — le client regarde le changement de loin. Avec Ceph, si votre distributeur commercial change de stratégie ou augmente ses prix, vous basculez vers upstream ou un autre distributeur sans migrer les données. La portabilité est réelle, pas un argument marketing. C'est ce que signifie concrètement la souveraineté numérique sur votre infrastructure de stockage.

La communauté est une garantie de continuité qu'un seul fabricant ne peut pas offrir. Un produit propriétaire dépend en dernière instance d'une feuille de calcul au siège du fabricant. Ceph a suffisamment de contributeurs institutionnels que si l'un part — ce qui est arrivé — le projet continue. Pour une infrastructure que vous allez exploiter quinze ou vingt ans, c'est déterminant.

La polyvalence architecturale se rentabilise d'elle-même. Stockage objet aujourd'hui, block demain pour un projet de virtualisation, fichier pour un cas d'usage ponctuel, NVMe-oF quand le besoin apparaît. Tout sur le même matériel, maintenu par la même équipe. COS ne fait bien que le stockage objet. Séparer les plateformes par protocole double les équipes, les procédures et les contrats de support.

La transparence opérationnelle est une autre forme de sécurité. Quand quelque chose casse dans Ceph, vous avez le code. Vous pouvez lire, auditer, déboguer, modifier, appeler un ingénieur qui comprend le commit à l'origine du bug. Quand quelque chose casse dans COS, vous ouvrez un ticket et attendez. Les deux approches sont légitimes. Pour des équipes techniques sérieuses, la première vaut plus qu'il n'y paraît dans une comparaison de features.

Quand IBM COS est la bonne réponse

Si nous étions des intégristes de l'open source, nous vendrions du vent — et il y en a déjà assez sur ce marché. COS est le bon choix pour un profil client assez précis.

Petites équipes opérationnelles sans compétences SDS, sans budget pour les recruter ni pour les externaliser durablement. La courbe d'apprentissage de Ceph est réelle, et si l'organisation ne peut pas l'assumer ni payer quelqu'un pour le faire à sa place, un produit empaqueté et opinionated comme COS réduit la surface de problèmes opérationnels.

Secteurs réglementés avec des exigences de conformité très spécifiques — WORM audité, rétention SEC 17a-4, Compliance Enabled Vaults, NENR. L'écosystème IBM est très mature sur ce terrain et les audits vont plus vite quand tout le stack vient du même fabricant avec des certifications déjà obtenues.

Politique d'entreprise « une seule gorge à serrer » avec préférence explicite pour le vendor tier-1. Il y a des organisations — banques conservatrices, administrations publiques, défense — où le CISO ou le responsable achats n'accepte pas une architecture sans une facture unique et un SLA contractuel. Discuter de l'extérieur avec cette politique est une perte de temps ; le bon réflexe est d'aider le client à choisir le produit empaqueté qui correspond le mieux.

Écosystème IBM déjà déployé. Si le client a déjà Spectrum Protect, Storage Defender, Fusion, Power ou Z, consolider le stockage objet dans le même périmètre vendor a une logique opérationnelle et commerciale.

Très grande échelle (hauts pétaoctets ou exaoctets) avec workload prévisible et stable, où la simplicité opérationnelle d'un produit mature compense le coût de la licence. Nous avons vu des clients avec plus d'un exaoctet sous support IBM pour qui migrer représenterait un projet de trois ans et des dizaines de millions d'euros — dans ces cas l'analyse est différente et la réponse est souvent de rester et d'optimiser.

Quand Ceph upstream avec un bon partenaire est la réponse

C'est le scénario où nous pensons que se trouve la majorité du marché, même si celui-ci ne le sait pas toujours.

Profils où Ceph upstream s'impose clairement :

• Client avec une équipe technique compétente en Linux et infrastructure, ou prêt à avoir un partenaire de support continu.
• Échelle moyenne à grande, de centaines de TB à dizaines de PB, où l'abonnement commercial commence à peser sur le budget.
• Besoin ou intention d'unifier stockage objet, block et fichier sur la même plateforme.
• Renouvellement matériel en cours sans volonté de s'attacher à une liste certifiée d'un fabricant unique.
• Intégration native avec Kubernetes via Rook, si une plateforme cloud-native est dans les plans.
• Préférence, simplement, pour pouvoir voir ce qu'il y a sous le capot.

Il faut ici affronter un mythe qui circule depuis des années : que Ceph est difficile. C'est à moitié vrai. Ceph est complexe — comme l'est tout système distribué sérieux — mais il n'est ni chaotique ni instable. La différence entre un cluster Ceph qui donne du fil à retordre et un qui tourne des années sans incident ne tient pas au logiciel. Elle tient à la conception du déploiement, au tuning des placement groups et du balancer, au choix d'un matériel cohérent, à la supervision, et au fait d'avoir quelqu'un au bout du téléphone qui sait quoi faire quand quelque chose d'inhabituel apparaît dans ceph health detail.

Le problème n'est pas Ceph. Le problème est de déployer Ceph sans expertise. C'est un problème propre à toute infrastructure complexe, pas un défaut du produit.

Un cluster Ceph bien opéré fonctionne aussi bien avec un support upstream plus un partenaire compétent qu'avec un abonnement enterprise. La vraie différence, c'est qui décroche le téléphone à trois heures du matin — et les partenaires qui font ce travail le décrochent aussi. Nous avons un article sur l'erreur Ceph la plus fréquente et comment la corriger si vous voulez voir concrètement comment nous travaillons.

IBM Storage Ceph : l'option intermédiaire

Nous allons être plus directs ici, parce que sur ce produit on écrit peu clairement.

IBM Storage Ceph est, techniquement, Ceph. Le même Ceph que vous téléchargez sur le site du projet. Empaqueté, testé, intégré avec des outils propres à IBM, supporté commercialement avec SLA, et certifié dans plusieurs environnements réglementés. C'est ce que vous payez. Techniquement, vous n'avez rien que vous ne pourriez avoir avec upstream.

Quand ça a du sens de le payer :

• Appels d'offres publics ou privés qui imposent un fournisseur tier-1 avec support contractuel, sans marge de négociation.
• Organisations où la politique achats oblige au support enterprise sans exception, et où il n'y a aucun moyen d'homologuer un partenaire externe comme alternative.
• Clients qui ont déjà un ELA (Enterprise License Agreement) avec IBM et auxquels ajouter Storage Ceph au package revient moins cher que le prix catalogue.
• Secteurs avec des audits où le nom du fabricant sur la facture raccourcit le processus.

Quand ça ne vaut pas la peine :

Dans pratiquement tous les autres cas. Si votre conformité ne vous y oblige pas et que vous avez un partenaire décent, payer un abonnement pour upstream est un surcoût évitable. Pour être concrets sans donner de chiffres officiels : à l'échelle de dizaines de pétaoctets, la différence entre abonnement commercial et partenaire de support sur upstream peut avoisiner des centaines de milliers d'euros par an. À l'échelle de l'exaoctet, on passe au million. Cet argent, pour la plupart des clients, vaut mieux réinvesti dans l'équipe, le matériel ou n'importe quoi d'autre.

Si votre réalité vous pousse vers le premier ou le deuxième, nous serons là pour vous aider à bien l'opérer. Mais la majorité des clients avec lesquels nous travaillons découvrent, après un assessment honnête, que le troisième leur convient mieux qu'ils ne le pensaient.

Ceph comme infrastructure pour l'IA souveraine

Une précision qui revient de plus en plus dans les conversations avec nos clients : Ceph n'est pas seulement du stockage. C'est le backend de stockage des infrastructures d'IA souveraine on-premise à grande échelle.

Quand une organisation veut déployer un LLM privé — un grand modèle de langage hébergé entièrement dans sa propre infrastructure — ou construire une AI Factory souveraine, le stockage distribué est la couche qui le rend viable. Ceph avec son interface RGW compatible S3 est la solution standard pour servir des datasets d'entraînement, des checkpoints de modèles et des résultats d'inférence à des clusters GPU orchestrés avec Kubernetes. Pour servir les modèles en production, SIXE déploie vLLM ou llama.cpp selon la volumétrie, la latence requise et le matériel disponible — et Ceph est la couche qui garantit que vos données ne quittent pas votre réseau.

IBM COS, par son architecture propriétaire et sa liste de matériel certifié, n'est pas l'option habituelle pour ces architectures d'IA souveraine. Ceph si — et c'est là que nous voyons le plus de nouveaux projets en 2026.

Trois cas réels

Anonymisés, parce que les NDAs sont les NDAs. La morale est toujours la même : la bonne question n'est pas « lequel est le meilleur en abstrait » mais « lequel convient à cette réalité concrète ».

Ce que la plupart des comparatifs ne disent pas

Quatre choses qui n'apparaissent jamais dans les whitepapers des éditeurs et que nous avons vu faire trébucher de nombreuses équipes techniques.

Migrer à l'échelle pétaoctet ne consiste pas à copier des données

C'est migrer de la configuration : lifecycle policies, rétention, legal holds, ACLs, CORS, bucket policies, versioning, notifications d'événements, tagging, réplication. On migre le contexte autant que les octets. Un projet de migration mal cadré s'en aperçoit à mi-chemin et voit son calendrier doubler.

Le dialecte S3 n'est pas uniforme

Entre AWS S3, Ceph RGW et IBM COS, il y a des différences subtiles dans les headers, le comportement de LIST avec beaucoup d'objets, les cas limites de multipart upload, la sémantique du versioning. Les applications clientes ont parfois besoin d'ajustements. Il faut tester, pas supposer.

La protection des données change de philosophie selon le produit

L'IDA de COS, l'erasure coding de Ceph et la réplication triple traditionnelle ne sont pas interchangeables en termes de garanties de durabilité ni de profil de pannes qu'ils tolèrent. Traduire un IDA 10/8/7 de COS en un profil d'erasure coding Ceph demande du jugement, pas de l'arithmétique.

Le quotidien opérationnel est radicalement différent

Dans COS, vous diagnostiquez avec storagectl list et le shell d'administration du Manager. Dans Ceph avec ceph -s, ceph osd tree, ceph health detail, placement groups, OSDs, CRUSH maps. Reformer une équipe prend entre six et douze mois de transition effective. Il faut le budgéter — ça ne peut pas être une note de bas de page du projet.

Comment nous travaillons chez SIXE

Le schéma est simple et fonctionne depuis des années. D'abord un assessment : nous passons en revue l'architecture actuelle, les workloads réels, le profil de l'équipe opérationnelle, les contraintes réglementaires, le budget à trois ou cinq ans et les options techniques viables. Le livrable est une recommandation motivée avec des alternatives — et parfois c'est « restez où vous êtes ». Nous l'avons dit plus d'une fois.

Ensuite un design, s'il y a migration ou changement substantiel. Architecture cible, plan par phases, fenêtres opérationnelles, matrice de risques, runbooks. Deux migrations ne se ressemblent pas.

Puis l'exécution. Migration par phases avec double fonctionnement quand c'est possible, validation des données, QA fonctionnelle avec les applications clientes, ajustements fins post-bascule.

Et enfin le handover avec mentoring à l'équipe du client, plus un support technique Ceph continu si vous voulez que nous restions disponibles à moyen terme. Beaucoup de clients préfèrent ce modèle — SIXE comme extension de leur équipe — plutôt qu'un abonnement commercial traditionnel. C'est exactement ce qui rend Ceph upstream viable en production sérieuse. Pour les équipes qui souhaitent monter en compétence en interne, nous proposons le cours d'administration Ceph et le cours pratique IBM Storage Ceph.

Notre équipe diagnostique un DONT-START-DAEMON sur un slicestor ClevOS avec la même aisance qu'un placement group inactive+incomplete sur Ceph. Nous ne sommes pas un partenaire « d'IBM » ni « de Ceph ». Nous sommes un partenaire de stockage objet, et nous connaissons les trois options suffisamment bien pour recommander celle qui convient dans chaque situation.