Le stockage est l’endroit où la plupart des projets de cloud privé réussissent ou échouent en silence. Le calcul est facile à appréhender et facile à remplacer. Le réseau est bien compris. Le stockage est la couche qui détient votre état, porte vos obligations de conformité et constitue l’élément le plus difficile à migrer une fois qu’il est plein. Si vous construisez un cloud souverain ou privé, le stockage en est le socle et, généralement, la partie la plus profonde du chantier.
Voici un parcours neutre de ce que signifie réellement le stockage souverain, des couches à concevoir et une cartographie honnête des options open source. Nous concevons ces systèmes pour gagner notre vie et nous ne vendons aucun produit de stockage : l’objectif ici est de vous aider à bien choisir, pas de vous imposer une pile.
Pourquoi le stockage est la partie difficile
Trois éléments font du stockage le coin compliqué d’un cloud privé.
Premièrement, il est avec état. Vous pouvez vider et reconstruire un nœud de calcul en quelques minutes. Vous ne pouvez pas faire cela avec l’unique copie de vos données. Chaque décision de conception autour de la réplication, du codage d’effacement et de la sauvegarde est une décision sur le niveau de perte de données et d’indisponibilité que vous pouvez tolérer.
Deuxièmement, c’est là que la souveraineté devient concrète. Une charge de travail s’exécutant dans un centre de données de l’UE perd quand même sa souveraineté si la couche de stockage est exploitée par une entité soumise au droit étranger de divulgation. Résidence des données et souveraineté des données ne sont pas la même chose. La résidence, c’est l’endroit où les octets se trouvent physiquement. La souveraineté, c’est qui détient le contrôle juridique et technique sur eux. Des données hébergées dans une région de Francfort d’un hyperscaler exploité par une société américaine peuvent toujours relever du CLOUD Act américain, qui peut contraindre une entreprise américaine à produire des données indépendamment de leur lieu de stockage. L’EDPB a indiqué de façon explicite qu’un chiffrement fort, avec des clés détenues uniquement sous contrôle de l’EEE, est la mesure supplémentaire qui répond à cette exposition. Le stockage est précisément l’endroit où vous mettez en œuvre ce contrôle.
Troisièmement, il est impitoyable sur le plan opérationnel. Les systèmes de stockage distribués ont des modes de défaillance qui n’apparaissent qu’à grande échelle ou sous charge : split-brain, reconstructions lentes, amplification d’écriture, conditions de cluster plein. Bien faire les choses exige une conception délibérée, pas des valeurs par défaut.
Les trois couches : bloc, fichier, objet
Un cloud privé complet a généralement besoin des trois types de stockage. Ils ne sont pas interchangeables.
Le stockage bloc présente des volumes bruts à un hôte, comme un disque virtuel. C’est ce que veulent les machines virtuelles et les bases de données : faible latence, lecture et écriture aléatoires, sémantique mono-écrivain. Le bloc est l’épine dorsale des charges de travail d’hyperviseur et des pods Kubernetes avec état.
Le stockage fichier présente un système de fichiers POSIX partagé que de nombreux clients peuvent monter en même temps. Il convient aux données applicatives partagées, aux répertoires personnels, aux chaînes de production médias et aux logiciels hérités qui attendent un chemin sur disque. La contrepartie est que la sémantique POSIX distribuée est réellement difficile, si bien que les systèmes de fichiers tendent à être le palier le plus complexe à exploiter correctement.
Le stockage objet présente les données sous forme d’objets dans des buckets plats, accessibles via HTTP avec une API de type S3. Il n’y a pas d’écrasement sur place ni de hiérarchie de système de fichiers. En échange, vous obtenez une mise à l’échelle horizontale pratiquement illimitée, des métadonnées intégrées et une adéquation naturelle pour les sauvegardes, les data lakes, les journaux, les corpus d’entraînement d’IA et les ressources applicatives. Le stockage objet est l’hébergement naturel de la majeure partie des données non structurées, c’est pourquoi il se trouve au centre de la plupart des conceptions de stockage souverain.
Le stockage défini par logiciel, en bref
Le stockage défini par logiciel (SDS) découple la logique de stockage du matériel. Au lieu d’un boîtier propriétaire, vous exécutez un logiciel ouvert sur des serveurs standards et le laissez gérer le placement, la réplication et la réparation. C’est ce qui rend le stockage souverain réalisable : l’intelligence est ouverte, auditable et vôtre, et le matériel est interchangeable. Le coût, c’est que vous assumez la complexité opérationnelle, soit avec votre propre équipe, soit via un partenaire de services managés.
Deux stratégies de protection des données traversent tout ce qui suit :
- La réplication conserve N copies complètes de chaque morceau de données. Simple, rapide à restaurer, mais gourmande en stockage : une réplication 3x signifie 3 To de disque brut pour 1 To de données utilisables.
- Le codage d’effacement divise les données en fragments plus parité, ce qui vous permet de survivre aux pannes tout en utilisant beaucoup moins de capacité brute. Un profil d’effacement typique offre une résilience comparable à une réplication 3x tout en nécessitant environ 1,5x de capacité brute. La contrepartie est plus de CPU, des petites écritures plus lentes et des reconstructions plus longues.
Une vaste cartographie des options open source
Il n’existe pas d’outil unique parfait. Le bon choix dépend de l’échelle, des protocoles dont vous avez besoin, de l’expertise de votre équipe et de l’endroit où vit la charge de travail. Voici un panorama honnête.
Ceph est la plateforme SDS unifiée de référence. Un seul cluster sert les trois couches : RBD pour le bloc, CephFS pour le fichier et la RADOS Gateway (RGW) pour le stockage objet compatible S3 et Swift. Il monte à l’échelle du pétaoctet, prend en charge la réplication et le codage d’effacement, et s’auto-répare. Le coût est une réelle complexité opérationnelle : c’est le système le plus exigeant à exploiter en toute sécurité ici, et il est gourmand en RAM et en CPU. Rook est l’opérateur qui exécute Ceph nativement à l’intérieur de Kubernetes et supprime une grande partie des corvées du day-two. Ceph est la réponse par défaut lorsque vous voulez une seule plateforme pour tout, à grande échelle.
LINSTOR avec DRBD emprunte une voie différente : réplication de bloc au niveau du noyau, essentiellement un RAID-1 synchrone entre serveurs, orchestré par LINSTOR. Il offre des performances de disque proches du natif avec une très faible surcharge, ce qui le rend solide pour les bases de données et VM sensibles à la latence. Il est uniquement bloc, et sa mise en place implique des modules noyau et LVM, il est donc moins clé en main. Piraeus apporte LINSTOR à Kubernetes.
Pour le stockage objet compatible S3 spécifiquement, le paysage a évolué récemment et mérite d’être connu :
- MinIO a été pendant des années le serveur S3 léger par défaut. Son édition communautaire est désormais de fait en fin de vie : la console d’administration a été retirée, la distribution des binaires a cessé et le dépôt GitHub a été archivé en février 2026. La licence AGPL qu’il a adoptée signifie que le code peut être (et a été) forké, mais l’édition communautaire en amont n’est plus maintenue. Considérez les déploiements existants comme nécessitant un plan de migration.
- Garage est un magasin d’objets léger et distribué, conçu pour des déploiements géo-redondants sur des sites distincts. Pas de nœud maître, tous les pairs égaux, placement de répliques sensible aux zones, fonctionne sur du matériel modeste et sur ARM. Excellent pour la souveraineté multi-sites et en périphérie. AGPL-3.0.
- SeaweedFS est mature, rapide et particulièrement performant avec de très grands nombres de petits objets. Il propose S3, FUSE et WebDAV, dispose d’une solide intégration Kubernetes et est sous licence Apache-2.0. Un choix polyvalent solide à grande échelle.
Pour les volumes persistants natifs Kubernetes :
- Longhorn est le stockage bloc distribué le plus simple pour Kubernetes : facile à exploiter, bonne interface, instantanés et sauvegardes intégrés. Idéal pour la périphérie et les clusters petits à moyens ; la latence peut s’envoler sous forte charge.
- OpenEBS est modulaire ; son moteur Mayastor offre des IOPS élevés avec un coût CPU inférieur à Ceph, axé sur le bloc, sans fonctionnalités objet.
Pour le substrat de stockage lui-même :
- ZFS est le système de fichiers local de référence : sommes de contrôle, instantanés, compression, chiffrement natif. Il sous-tend bon nombre des systèmes ci-dessus en tant que couche par nœud.
- GlusterFS est un système de fichiers réseau à montée en charge encore présent en production, même si l’élan s’est clairement déplacé vers Ceph et les conceptions axées sur l’objet pour les nouveaux projets.
Le stockage compatible S3 comme alternative souveraine à AWS S3
L’API S3 est devenue le standard de facto du stockage objet, ce qui est une bonne nouvelle pour la souveraineté. Comme tant de logiciels parlent S3, vous pouvez exécuter un magasin compatible S3 sur votre propre infrastructure (Ceph RGW, Garage, SeaweedFS) et conserver le même code applicatif, le même outillage de sauvegarde, les mêmes moteurs de data lake, pendant que vos données restent dans votre juridiction, sous vos clés. Vous bénéficiez de l’ergonomie développeur de S3 sans l’exposition juridique d’un cloud exploité par une entité étrangère. C’est le levier le plus puissant dans la plupart des conceptions de stockage souverain.
Chiffrement, contrôle des clés et résidence
La souveraineté se fait respecter à la frontière des clés, pas au mur du centre de données.
- Le chiffrement au repos doit être activé sur chaque couche qui le prend en charge, de ZFS jusqu’à la passerelle objet.
- Le contrôle des clés, c’est l’essentiel. Si un tiers peut déchiffrer vos données, vous n’êtes pas souverain, peu importe où vivent les disques. Conservez les clés dans un KMS ou HSM contrôlé par l’UE, distinct de l’exploitant du stockage, afin qu’aucune entité étrangère ne puisse contraindre la divulgation de données exploitables.
- La résidence compte toujours : épinglez le placement aux régions de l’UE et prouvez-le. Mais la résidence sans contrôle des clés n’est que du théâtre.
Sauvegarde et reprise après sinistre
La réplication n’est pas une sauvegarde. Elle copie fidèlement vos erreurs. Une vraie conception de stockage souverain dispose de sauvegardes indépendantes (idéalement immuables, de type object-lock) et d’un plan de reprise testé : réplication inter-sites pour les données objet, restauration basée sur les instantanés pour le bloc et le fichier, et des exercices de restauration réguliers. La défaillance que vous n’avez pas répétée est celle qui fera mal.
En interne ou en mode managé
Le SDS open source supprime le verrouillage par licence, pas la charge opérationnelle. Le partage honnête :
- En interne lorsque vous disposez d’une équipe plateforme compétente en stockage et que vous voulez un contrôle total. Prévoyez un budget pour une vraie astreinte et une expertise approfondie ; Ceph en particulier sanctionne les effectifs trop minces.
- En mode managé lorsque vous voulez un stockage souverain et open source, mais pas une astreinte à 3 h du matin pour un cluster dégradé. Un partenaire neutre peut concevoir, construire et exploiter la pile sur votre infrastructure, dans votre juridiction, avec vos clés, et vous la rendre quand vous le souhaitez.
FAQ
Le stockage objet suffit-il à lui seul ? Rarement. L’objet couvre la majeure partie des données non structurées, mais les VM et les bases de données ont besoin de bloc, et les données applicatives partagées ont souvent besoin de fichier. La plupart des clouds privés exécutent les trois.
Ceph ou quelque chose de plus léger ? Ceph si vous voulez une seule plateforme pour le bloc, le fichier et l’objet à grande échelle et que vous pouvez l’armer en personnel. Des outils plus légers et à usage unique (Garage ou SeaweedFS pour l’objet, Longhorn ou LINSTOR pour le bloc) sont plus faciles à exploiter lorsque vous n’avez pas besoin d’une plateforme unifiée.
Compatible S3 veut-il dire exactement comme AWS S3 ? L’API de base est largement compatible, c’est pourquoi les migrations se passent généralement bien. Les fonctionnalités de pointe et les garanties de cohérence varient, alors validez les opérations spécifiques dont dépendent vos applications.
Et la situation de MinIO ? L’édition communautaire n’est plus maintenue depuis le début de 2026. Les utilisateurs existants devraient planifier une migration vers une alternative maintenue ou un fork pris en charge.
La place de Rapid Solutions
Nous sommes un cabinet de conseil en ingénierie neutre et un partenaire de services managés, pas un fournisseur de cloud. Nous concevons et exploitons un stockage souverain, open source d’abord, sur une infrastructure que vous contrôlez, avec une résidence des données dans l’UE et des clés qui restent entre vos mains. Nous nous adaptons à votre pile plutôt que de vous vendre la nôtre.
Si vous planifiez un cloud privé ou repensez l’endroit où vivent vos données, parlez-nous.