Les données croissent plus vite que les budgets. Chaque année, une organisation moyenne multiplie son volume de données stockées, et la tentation de simplement « acheter plus de disques » se heurte rapidement à un mur de coûts, de latence et de complexité de gestion. Concevoir un stockage évolutif ne consiste pas à accumuler de la capacité, mais à placer chaque donnée sur le support approprié, avec la redondance adéquate et une trajectoire de croissance qui n'oblige pas à interrompre le service. Cet article passe en revue les trois grandes architectures — bloc, fichier et objet —, le tiering automatique qui les unit et les mécanismes de durabilité qui distinguent un stockage vraiment fiable d'un stockage qui ne semble fiable que jusqu'à la première défaillance.
Bloc, fichier et objet : trois modèles, trois usages
Le stockage en bloc (SAN) expose des volumes bruts via des protocoles tels qu'iSCSI ou Fibre Channel. Le système d'exploitation les voit comme des disques locaux et y pose son propre système de fichiers. C'est le modèle à plus faible latence et aux meilleures IOPS, idéal pour les bases de données transactionnelles et les machines virtuelles. Son point faible : il évolue mal horizontalement et un volume n'est généralement monté que par un seul hôte.
Le stockage fichier (NAS) sert des hiérarchies de dossiers et de fichiers via NFS ou SMB/CIFS. Plusieurs clients partagent le même système de fichiers, avec des droits POSIX ou ACL. C'est le modèle naturel pour les répertoires partagés, les ressources utilisateur et les applications qui attendent des chemins d'accès. Il évolue mieux que le bloc, mais les métadonnées hiérarchiques deviennent un goulot d'étranglement à grande échelle.
Le stockage objet (compatible avec l'API S3) conserve les données sous forme d'objets plats identifiés par une clé, sans réelle hiérarchie de dossiers, avec des métadonnées riches et un accès par HTTP. C'est le modèle qui soutient le cloud : durabilité très élevée, mise à l'échelle quasi illimitée et faible coût par gigaoctet, en échange d'une latence plus importante et d'une cohérence éventuelle ou forte selon le fournisseur. Il est idéal pour les sauvegardes, les archives multimédias, les data lakes et les backups.
Tableau comparatif des architectures de stockage
| Caractéristique | Bloc (SAN) | Fichier (NAS) | Objet (S3) |
|---|---|---|---|
| Unité | Bloc LBA | Fichier en arborescence | Objet + clé |
| Protocole | iSCSI, FC, NVMe-oF | NFS, SMB | HTTP / API S3 |
| Latence | Très faible | Faible à moyenne | Moyenne à élevée |
| Mise à l'échelle | Verticale | Horizontale limitée | Horizontale massive |
| Cas typique | BDD, VM | Ressources partagées | Backup, data lake, média |
| Coût par Go | Élevé | Moyen | Faible |
Tiering automatique : la donnée chaude en haut, la froide en bas
Toutes les données n'ont pas la même valeur et ne sont pas accédées avec la même fréquence. Le tiering automatique déplace les données entre classes de stockage en fonction des schémas d'accès. En pratique, plusieurs niveaux coexistent : hot sur NVMe/SSD pour ce qui est lu et écrit maintenant ; warm sur SAS ou S3 standard pour ce qui est accédé de manière occasionnelle ; et cold/archive sur bande ou classes d'archivage profond pour ce qui n'est presque jamais consulté mais doit être conservé pour des raisons de conformité. Les politiques de cycle de vie (lifecycle policies) automatisent la transition : un objet qui n'a pas été lu depuis 30 jours passe à une classe moins chère, et après 180 jours il est archivé.
Les économies sont réelles mais exigent une conception réfléchie : récupérer une donnée depuis un niveau d'archivage profond peut prendre des heures et entraîner des coûts d'extraction. Déplacer vers l'archive ce dont on a besoin en urgence est une erreur aussi coûteuse que maintenir en NVMe ce que personne ne consulte.
Mise à l'échelle horizontale et stockage défini par logiciel
La différence clé entre un stockage qui évolue et un stockage qui se retrouve rapidement à l'étroit réside dans le modèle de croissance. La mise à l'échelle verticale (scale-up) ajoute des disques à une baie existante jusqu'à épuiser ses contrôleurs : c'est simple, mais cela a un plafond physique et un unique point de défaillance. La mise à l'échelle horizontale (scale-out) ajoute des nœuds à un cluster, répartissant capacité et performances : chaque nœud apporte disque, CPU et réseau, de sorte que le système croît de manière linéaire sans interruption de service. C'est le modèle des systèmes distribués modernes (Ceph, MinIO ou les baies scale-out commerciales) et la raison pour laquelle le stockage objet peut atteindre des tailles en exaoctets.
Sur cette base repose le stockage défini par logiciel (SDS, Software-Defined Storage), qui découple la logique de stockage du matériel propriétaire et l'exécute sur des serveurs standard. Le SDS permet de mélanger les fabricants, d'automatiser le provisionnement par politiques et d'orchestrer les volumes de manière déclarative — particulièrement pertinent dans les environnements de conteneurs, où l'interface CSI (Container Storage Interface) de Kubernetes provisionne des volumes persistants à la demande. La contrepartie est que la complexité se transfère du matériel au logiciel et aux équipes : un cluster distribué mal dimensionné au niveau réseau interne ou en facteur de réplication sera moins performant qu'une baie traditionnelle bien configurée.
Durabilité : RAID, erasure coding et la règle 3-2-1
La fiabilité signifie que la donnée survit à une défaillance matérielle. Le RAID protège contre la perte de disques : le RAID 6 tolère deux disques défaillants simultanément, mais les temps de reconstruction de disques de grande capacité sont si longs qu'ils augmentent la fenêtre de risque. C'est pourquoi le stockage objet moderne utilise l'erasure coding, qui fragmente chaque objet en k données et m fragments de parité distribués ; avec un schéma 10+4, on tolère quatre défaillances simultanées avec un surcoût de capacité bien inférieur à celui de la triple réplication.
Aucun RAID n'est une sauvegarde. La règle 3-2-1 reste l'étalon-or de la fiabilité : trois copies des données, sur deux types de supports différents, dont l'une hors site (offsite). Face au ransomware, la variante 3-2-1-1-0 s'est imposée : une copie immuable ou air-gapped et zéro erreur vérifiée lors des tests de restauration. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est un espoir.
Performances : IOPS, débit et latence ne sont pas la même chose
Dimensionner un stockage exige de distinguer trois grandeurs souvent confondues. Les IOPS (opérations d'entrée/sortie par seconde) mesurent combien de requêtes le système traite ; elles comptent dans les charges de nombreuses petites opérations aléatoires, comme une base de données transactionnelle. Le débit (MB/s) mesure le flux de données transféré ; il prédomine dans les charges séquentielles de grands fichiers, comme les sauvegardes ou la vidéo. Et la latence (millisecondes) mesure le temps de réponse de chaque opération individuelle, ce que l'utilisateur et l'application perçoivent vraiment. Un système peut avoir des IOPS très élevées et pourtant sembler lent si sa latence de queue (les percentiles p99) s'emballe sous charge.
L'erreur de dimensionnement la plus coûteuse est d'optimiser la mauvaise grandeur : acheter des disques à très haut débit pour une base de données qui avait besoin d'IOPS et de faible latence, ou l'inverse. C'est pourquoi la bonne conception commence par caractériser le schéma d'E/S réel de chaque application — taille des blocs, ratio lecture/écriture, aléatoire et pics — avant de choisir le support. Le caching en SSD/NVMe devant des couches plus lentes et la séparation des charges en pools distincts permettent de servir à la fois la base de données et le dépôt de sauvegardes sans que l'un n'étouffe l'autre.
Conformité : chiffrement, rétention et RGPD
Un stockage fiable est aussi un stockage conforme. Le RGPD exige le chiffrement des données personnelles au repos et en transit comme mesure de sécurité appropriée, définit des délais de conservation (on ne conserve pas indéfiniment « au cas où ») et oblige à pouvoir exécuter le droit à l'effacement, ce qui dans un stockage objet avec versionnage et rétention WORM nécessite une conception explicite. L'immuabilité qui protège contre le ransomware (Object Lock) peut entrer en conflit avec le droit à l'effacement si la coexistence des deux besoins n'est pas planifiée. Les bonnes pratiques de gestion de la sécurité de l'information de la famille ISO/IEC 27001 offrent le cadre de contrôles pour gouverner l'ensemble.
Erreurs courantes en architecture de stockage
- Utiliser le stockage objet comme système de fichiers à faible latence. La cohérence et la latence ne correspondent pas aux charges transactionnelles.
- Confondre RAID et sauvegarde. Le RAID protège contre la défaillance de disques, pas contre la suppression accidentelle, la corruption ou le ransomware.
- Ne pas tester les restaurations. Le « zéro erreur » de la règle 3-2-1-1-0 n'existe que si on le vérifie.
- Faire du tiering sans mesurer les accès. Déplacer vers l'archive des données fréquemment consultées fait exploser les coûts de récupération.
- Ignorer le chiffrement au repos. Un disque égaré sans chiffrement constitue une violation notifiable au titre du RGPD.
Questions fréquentes
NAS ou SAN pour une base de données ?
SAN (bloc) pour sa plus faible latence et ses meilleures IOPS. Le NAS convient mieux aux fichiers partagés ; certaines bases de données fonctionnent sur NFS, mais le bloc reste la référence pour les charges transactionnelles exigeantes.
Quelle durabilité offre le stockage objet ?
Les fournisseurs cloud annoncent généralement « onze neuf » (99,999999999 % annuels) grâce à la réplication ou à l'erasure coding entre zones. Ce chiffre décrit la probabilité de ne pas perdre un objet par défaillance de support, sans exempter de maintenir des sauvegardes indépendantes.
Qu'est-ce exactement que le tiering automatique ?
C'est le déplacement des données entre classes de stockage de coût et de performance différents selon leur fréquence d'accès, gouverné par des politiques de cycle de vie qui s'appliquent sans intervention manuelle.
La règle 3-2-1 est-elle encore valable avec le cloud ?
Oui, et elle a été renforcée. Le cloud facilite la copie hors site, mais il convient de conserver au moins une copie immuable et de diversifier les fournisseurs ou les supports pour ne pas dépendre d'un unique point de défaillance.
Conclusion
Le stockage cesse d'être un problème de capacité pour devenir un problème de conception dès que les volumes augmentent : la bonne question n'est pas « combien de téraoctets dois-je acheter ? » mais « quelle donnée vit dans quelle couche, avec quelle redondance et sous quelle politique de cycle de vie ? ». Un système évolutif combine le bloc pour le transactionnel, le fichier pour le partagé et l'objet pour le massif, avec un tiering qui rend les données froides moins coûteuses sans pénaliser les données chaudes, et une stratégie 3-2-1-1-0 qui résiste même au ransomware. Le tout chiffré et avec des délais de rétention conformes au RGPD. Chez Summum Systèmes, nous concevons cette architecture sur mesure en fonction du schéma d'accès réel de chaque client, et nous vérifions les restaurations avant de promettre que la donnée est en sécurité.