Ce qu’il faut retenir avant de dimensionner un stockage SAN
- Un SAN transporte du stockage bloc sur un réseau dédié, pas des partages de fichiers.
- Il devient pertinent pour les bases de données, la virtualisation, les ERP et les applications sensibles à la latence.
- La robustesse dépend surtout de la redondance des chemins, des contrôleurs et des commutateurs.
- Le cloud complète souvent le SAN pour la sauvegarde, l’archivage ou la reprise après incident, mais ne le remplace pas toujours.
- Un bon choix ne se fait pas sur la seule capacité: il faut regarder l’I/O, le RPO/RTO et la croissance.
Ce qu’un SAN apporte réellement à une infrastructure
Un SAN est un réseau dédié au stockage, construit pour transporter des volumes de données au niveau bloc. En pratique, le serveur voit un volume logique, pas un partage de fichiers. C’est précisément ce découplage qui intéresse les bases de données, les plateformes de virtualisation, les ERP et les applications qui supportent mal la latence.
Dans les environnements que j’audite, je réserve le SAN aux services où l’I/O, la continuité de service et la reprise rapide comptent davantage que la simplicité d’administration. Le modèle apporte surtout trois choses: une faible latence, une meilleure disponibilité et une séparation nette entre calcul et stockage. Cette séparation réduit les goulots d’étranglement du serveur local et permet de faire évoluer les ressources de façon plus propre.Le revers, c’est qu’un SAN demande de la discipline. Sans segmentation, sans chemins multiples et sans supervision, on obtient vite une architecture coûteuse mais pas vraiment robuste. C’est aussi ce qui explique pourquoi le SAN se combine différemment selon qu’on reste sur site ou qu’on construit un socle hybride.
Comment le SAN s’intègre dans un environnement cloud hybride
Dans une approche cloud hybride, le SAN n’est pas censé disparaître. Il garde un intérêt là où la donnée doit rester proche du calcul, surtout pour les charges transactionnelles. Le cloud complète ensuite l’ensemble pour la sauvegarde, l’archivage, la réplication distante ou certains plans de reprise.
Je vois souvent un malentendu: on oppose SAN et cloud alors qu’ils ne jouent pas le même rôle. Le SAN porte la couche de performance et de disponibilité locale; le cloud prend la relève pour l’extensibilité, la résilience géographique ou les copies hors site. Les architectures hyperconvergées, elles, déplacent une partie de l’intelligence de stockage dans les nœuds du cluster, ce qui simplifie certains déploiements sans faire disparaître les exigences de redondance.
En 2026, je considère le transport NVMe/TCP comme une évolution intéressante pour certains projets modernes, mais le principe reste inchangé: séparer le trafic de stockage du trafic utilisateur. Quand cette séparation est bien pensée, le SAN garde sa pertinence même dans des infrastructures très orientées cloud.
C’est justement ce mélange entre stockage local, réplication et services distants qui rend utile une comparaison claire avec les autres modèles de stockage.
SAN, NAS et stockage cloud ne répondent pas au même besoin
Le plus utile n’est pas de demander quel modèle est le meilleur, mais lequel correspond au bon niveau d’accès. Je conseille rarement de choisir l’un contre l’autre de manière absolue, parce qu’un bon design combine souvent les trois.
| Critère | SAN | NAS | Stockage cloud |
|---|---|---|---|
| Granularité | Bloc | Fichier | Objet ou bloc managé |
| Latence | Très faible, sur réseau dédié | Modérée, dépend du réseau local | Variable, dépend du lien et du service |
| Usage typique | Bases de données, VM, ERP, VDI | Partages de fichiers, collaboration, documents | Sauvegarde, archivage, réplication, distribution |
| Administration | Plus technique | Plus simple | Souvent plus simple à consommer, mais plus dépendante du fournisseur |
| Forces | Performance, disponibilité, isolation | Simplicité, coût, rapidité de mise en service | Élasticité, portée géographique, consommation à la demande |
| Limites | Complexité, coût, besoin de compétences | Moins adapté aux charges transactionnelles lourdes | Latence, coûts de sortie, dépendance au WAN |
Ma lecture est simple: le SAN sert à tenir la pression côté production, le NAS simplifie les usages de partage, et le cloud prend le relais pour étendre, sécuriser ou externaliser une partie du cycle de vie des données. Quand ce trio est bien articulé, l’architecture devient plus lisible et plus facile à défendre devant les équipes métiers comme devant l’exploitation.
Reste à voir ce qui, concrètement, fait qu’un SAN tient la route ou se transforme en source de problèmes.
Les briques techniques qui font la différence dans une architecture fiable
Le matériel compte, mais la topologie compte encore plus. Un SAN proprement pensé repose sur quelques briques qu’il ne faut jamais traiter comme des détails.
- Baies et contrôleurs doubles - deux contrôleurs actifs ou actifs-passifs selon le modèle, pour éviter le point unique de panne.
- Commutateurs SAN - Fibre Channel ou Ethernet dédiés; je préfère deux fabrics séparés dès que la continuité de service devient critique.
- HBA ou NIC redondés - les cartes côté serveur qui portent le trafic de stockage, avec des chemins distincts pour éviter la coupure sèche.
- LUN - Logical Unit Number, c’est le volume logique présenté au serveur comme une cible de stockage.
- Zoning - segmentation des accès dans la fabric, pour limiter qui voit quoi et réduire les erreurs de visibilité.
- Multipathing - plusieurs chemins vers la même cible, avec bascule automatique si un lien ou un switch tombe.
- Snapshots et réplication - utiles pour accélérer la restauration et copier des données vers un autre site, mais ce ne sont pas des sauvegardes complètes.
Je mets aussi la supervision au même niveau que le matériel: capacité, latence, erreurs de ports, saturation des liens et état des chemins doivent être visibles avant que l’utilisateur ne subisse la panne. Un SAN peut être très performant et rester fragile si l’équipe n’a pas de vue claire sur ce qui se passe à l’intérieur de la fabric.
Et c’est précisément là que beaucoup de projets dérapent: non pas sur la technologie, mais sur les mauvaises hypothèses de départ.
Les erreurs que je vois le plus souvent dans les projets SAN
Les incidents que je retrouve le plus souvent sont presque toujours les mêmes, et ils auraient pu être évités avec un peu de méthode.
- Ne dimensionner que la capacité - un SAN se juge aussi en IOPS, c’est-à-dire en opérations d’entrée/sortie par seconde, et en latence.
- N’avoir qu’un seul chemin - un seul switch ou un seul lien suffit à créer un point de panne inutilement risqué.
- Mélanger trafic de sauvegarde et trafic applicatif - sans garde-fous, la fenêtre de backup dégrade les performances de production.
- Croire qu’un snapshot remplace une sauvegarde - un effacement logique ou un ransomware se réplique très bien dans des copies trop proches.
- Oublier l’exploitation - patchs firmware, tests de bascule, documentation et supervision doivent être prévus dès le départ.
Je vois trop de projets techniquement corrects sur le papier, puis fragiles au premier incident, simplement parce que personne n’a testé les scénarios de panne. Un SAN protège la disponibilité; il ne remplace ni une vraie stratégie de sauvegarde, ni la logique 3-2-1, ni une exploitation rigoureuse.
À partir de là, la vraie question devient plus pragmatique: dans quels cas ce choix est-il justifié, et quand faut-il passer son tour?
Dans quels cas je recommande un SAN et quand je l’évite
En 2026, je recommande encore le SAN quand la charge impose une faible latence, une forte disponibilité et une séparation nette entre calcul et stockage. Mais je ne le propose pas systématiquement, parce qu’un bon choix technique doit aussi rester exploitable au quotidien.
Je le recommande si
- vous hébergez des bases de données transactionnelles qui réagissent mal aux variations de latence;
- vous servez un cluster de virtualisation avec plusieurs hôtes qui partagent les mêmes volumes;
- vous devez répliquer rapidement des données vers un site distant pour du PRA ou du basculement;
- vous avez besoin d’isoler clairement le trafic de stockage du reste du réseau;
- vous disposez d’une équipe capable d’administrer la fabric, les chemins et les politiques de stockage.
Lire aussi : Infrastructure serveur - Comment choisir la meilleure option cloud ?
Je l’évite si
- vos besoins sont surtout des fichiers partagés, de la bureautique ou de la collaboration documentaire;
- votre budget ou votre équipe ne peut pas absorber la complexité d’exploitation;
- la charge est peu sensible à la latence et peut vivre avec une solution plus simple;
- votre priorité est l’archivage, la distribution de contenu ou la conservation à long terme;
- un NAS ou un stockage cloud géré couvre déjà l’essentiel du besoin avec moins d’effort.
Le bon test n’est pas d’abord technique, il est applicatif: quelle latence l’application tolère-t-elle, quel RPO et quel RTO faut-il tenir, et qui portera l’exploitation au quotidien? C’est à partir de ces trois réponses que l’architecture devient rationnelle, pas l’inverse.
Ce que je vérifierais avant de valider un projet de stockage
Avant de signer pour un SAN, je regarde toujours trois points très concrets: la sensibilité réelle de l’application à l’I/O, la stratégie de reprise en cas d’incident, et la capacité de l’équipe à maintenir une architecture redondée sans approximation. Si l’un de ces trois blocs est flou, le projet risque d’être solide en démo et bancal en production.- Quelle partie du stockage doit rester locale, et quelle partie peut être répliquée ou externalisée?
- Quels services exigent un accès bloc, et lesquels peuvent vivre avec du fichier ou du cloud?
- La supervision, les tests de bascule et la documentation sont-ils vraiment prévus, ou juste supposés?
Si ces réponses sont claires, le choix devient lisible: SAN pour le cœur transactionnel, NAS pour les échanges de fichiers, cloud pour la copie hors site et l’élasticité. C’est cette répartition, plus que la technologie prise isolément, qui construit une infrastructure sobre, solide et exploitable dans la durée.