Ordinateurs & périphériques

SAN vs NAS : la différence qui compte quand plusieurs serveurs lisent le même disque

Élise Prévost-Lemercier 8 min de lecture
SAN vs NAS : stockage disque partagé pour plusieurs serveurs

Choisir entre SAN et NAS revient à répondre à une seule question : vos applications ont-elles besoin de voir un disque, ou vos utilisateurs ont-ils besoin de voir un dossier ? Cette distinction, entre stockage par blocs et stockage par fichiers, détermine tout le reste : protocoles, performances, coûts, complexité de gestion. Les deux architectures répondent à des besoins de stockage en réseau, mais elles ne jouent pas dans la même catégorie, et les confondre mène souvent à des choix d’infrastructure coûteux à corriger.

Qu’est-ce qu’un SAN ?

Un SAN (Storage Area Network) est un réseau de stockage dédié qui expose des blocs de données bruts aux serveurs qui s’y connectent. Concrètement, un serveur relié à un SAN voit un espace de stockage comme s’il s’agissait d’un disque local, alors que ce disque se trouve en réalité dans une baie distante. Cette illusion est rendue possible par des protocoles spécialisés, Fibre Channel, iSCSI, ou plus récemment NVMe-oF (NVMe over Fabrics), qui transportent les commandes de lecture et d’écriture à très faible latence.

Infographie comparative san vs nas illustrant la différence entre stockage par blocs et stockage par fichiers
Infographie comparative san vs nas illustrant la différence entre stockage par blocs et stockage par fichiers

Le fonctionnement par blocs et les LUN

Dans un SAN, l’espace de stockage est découpé en unités appelées LUN (Logical Unit Numbers). Chaque LUN est un bloc de capacité alloué à un serveur ou à une application donnée, sans structure de fichiers imposée par le SAN lui-même : c’est le système d’exploitation du serveur qui formate ce bloc et y organise ses propres fichiers. Ce fonctionnement en bas niveau explique pourquoi le SAN offre des performances élevées et une latence réduite : il n’y a pas de couche d’abstraction supplémentaire entre la demande d’écriture et le disque physique.

Pour quels usages le SAN est-il pensé ?

Le SAN est la solution privilégiée pour les bases de données transactionnelles, les environnements de virtualisation avec de nombreuses machines virtuelles, et plus largement toutes les applications critiques qui exigent une disponibilité continue. Dans un cluster de virtualisation, plusieurs hyperviseurs peuvent accéder simultanément aux mêmes LUN, ce qui permet de déplacer des machines virtuelles d’un serveur physique à un autre sans interruption de service, un mécanisme central dans les infrastructures d’entreprise à haute disponibilité.

Qu’est-ce qu’un NAS ?

Un NAS (Network Attached Storage) est un dispositif de stockage connecté à un réseau Ethernet classique, qui met à disposition des fichiers plutôt que des blocs. Contrairement au SAN, le NAS apparaît sur le réseau comme un volume partagé, un dossier accessible par plusieurs utilisateurs ou machines à la fois, via des protocoles de partage de fichiers.

Les protocoles NFS et SMB/CIFS

Le NAS s’appuie sur des protocoles orientés fichiers : NFS pour les environnements Linux/Unix, SMB/CIFS pour les environnements Windows. Ces protocoles gèrent directement la structure des dossiers et des permissions, ce qui rend le NAS immédiatement compréhensible pour un utilisateur non technique : il ouvre un lecteur réseau exactement comme il ouvrirait un dossier local. Cette simplicité est la grande force du NAS : ni l’installation ni la prise en main ne demandent de compétences réseau poussées.

Un usage pensé pour le partage

Le NAS répond avant tout à un besoin de partage de fichiers entre plusieurs utilisateurs : documents d’équipe, sauvegardes, médiathèques, archives. Sur le marché grand public et PME, des références comme le QNAP TR-004 (autour de 199,99 euros, 4 baies) ou le TerraMaster D2 (269,99 euros, 2 baies, compatible Thunderbolt 3 à 40 Gbit/s) illustrent bien ce positionnement accessible, à mi-chemin entre le NAS réseau et le boîtier de stockage direct.

Les différences qui séparent vraiment SAN et NAS

Au-delà du vocabulaire technique, trois différences structurent tout le reste : la nature des données transportées, le protocole réseau utilisé, et la façon dont le stockage se présente au système qui l’utilise.

Blocs contre fichiers : la distinction fondamentale

C’est la ligne de partage la plus importante. Le SAN transporte des blocs bruts sans connaissance de leur contenu ; le NAS transporte des fichiers déjà structurés, avec une arborescence, des noms, des permissions. Un serveur de base de données préfère écrire directement sur un bloc, sans intermédiaire, pour garder un contrôle total sur la façon dont les données sont organisées sur le disque. C’est pour cela que les SGBD critiques tournent presque toujours sur du SAN plutôt que sur du NAS.

Performances, latence et bande passante

Le SAN, en particulier lorsqu’il s’appuie sur Fibre Channel ou NVMe-oF, offre une latence nettement plus faible et un débit d’IOPS plus élevé que le NAS. Cette différence provient en partie du réseau dédié : un SAN circule généralement sur son propre réseau physique, isolé du trafic bureautique, alors qu’un NAS partage souvent le réseau Ethernet standard de l’entreprise. Le NAS reste largement suffisant pour du partage de fichiers ou de la sauvegarde, mais il montre ses limites face à des charges de travail exigeant des milliers d’opérations par seconde en continu.

Complexité de mise en œuvre et de gestion

Un NAS se déploie en quelques minutes : on le branche au réseau, on crée des partages, et les utilisateurs y accèdent immédiatement. Un SAN demande une expertise réseau plus poussée, configuration du zoning en Fibre Channel, gestion des LUN, dimensionnement de la baie, et s’accompagne souvent d’une infrastructure dédiée. Cette complexité a un coût, à la fois en matériel spécialisé et en compétences internes ou externalisées nécessaires pour l’exploiter.

Une image aide à saisir cette différence sans jargon réseau : le SAN livre les fils bruts, les blocs de capacité, sans dire comment les organiser, et c’est au serveur connecté de construire sa propre structure par-dessus. Le NAS, lui, livre directement le tissu fini, une arborescence de dossiers déjà organisée, prête à l’emploi. C’est pourquoi migrer d’un NAS vers un SAN n’est jamais un simple changement de câble : on passe d’une structure finie à des blocs bruts qu’il faut réapprendre à organiser.

Avantages et inconvénients selon le contexte

Aucune des deux architectures n’est supérieure dans l’absolu : chacune est optimisée pour un type de charge de travail différent.

Ce que le SAN apporte, et ce qu’il coûte

Le SAN excelle sur la performance, la faible latence et la capacité à supporter plusieurs milliers de machines virtuelles ou des bases de données à forte volumétrie transactionnelle. Il offre aussi une meilleure isolation du trafic, ce qui renforce la fiabilité pour les applications critiques. En contrepartie, son coût d’acquisition et de maintenance est plus élevé, et sa mise en œuvre exige des compétences réseau spécifiques que toutes les équipes IT ne possèdent pas en interne.

Ce que le NAS apporte, et où il montre ses limites

Le NAS se distingue par sa simplicité de déploiement, son coût maîtrisé et sa facilité d’extension : ajouter de la capacité ou de nouveaux utilisateurs se fait sans reconfiguration lourde. Beaucoup de modèles NAS intègrent aussi le RAID nativement, ce qui apporte une redondance des données sans matériel supplémentaire. Sa limite principale apparaît quand la charge de travail devient intensive : partage réseau saturé, applications critiques en attente d’écriture, ou environnements virtualisés à grande échelle. Ce sont autant de scénarios où le NAS montre un plafond de performance que le SAN ne connaît pas.

Critère SAN NAS
Type de stockage Par blocs (LUN) Par fichiers
Protocoles Fibre Channel, iSCSI, NVMe-oF NFS, SMB/CIFS
Performance et latence Élevée, faible latence Correcte, suffisante pour le partage
Simplicité de déploiement Complexe, expertise réseau requise Simple, prêt à l’emploi
Coût Plus élevé Maîtrisé
Usage typique Bases de données, virtualisation intensive Partage de fichiers, sauvegarde

Comment choisir entre SAN et NAS selon vos besoins ?

Le choix se joue rarement sur une préférence technique abstraite : il dépend du type de données à stocker, du nombre d’utilisateurs ou d’applications qui y accèdent, et du budget disponible.

Quand le SAN est le bon choix

Optez pour un SAN si vous exploitez des bases de données critiques, un cluster de virtualisation avec de nombreuses machines virtuelles, ou toute application où la moindre latence supplémentaire se traduit par une perte de performance mesurable. Le SAN est également pertinent dès que la haute disponibilité et la reprise après sinistre sont des exigences non négociables, car son architecture permet une redondance et une bascule plus fine entre serveurs.

Quand le NAS suffit largement

Pour du partage de fichiers entre collaborateurs, de la sauvegarde centralisée, de l’archivage ou un usage personnel avancé, le NAS répond parfaitement au besoin, avec un investissement initial et une courbe d’apprentissage bien plus légers. Une PME qui cherche avant tout à centraliser ses documents et à automatiser ses sauvegardes trouvera dans le NAS une solution largement suffisante, sans avoir à recruter de compétences réseau spécialisées.

Le budget et l’évolutivité comme arbitres finaux

Deux critères pratiques, indépendants des besoins techniques, tranchent souvent le débat : le budget disponible et la trajectoire de croissance de l’organisation. Un SAN est un investissement structurant, à envisager quand la volumétrie et la criticité des données justifient ce coût sur la durée. Un NAS, plus abordable et plus simple à faire évoluer par ajout de baies ou de capacité, convient mieux aux structures dont les besoins de stockage grandissent progressivement plutôt que par paliers massifs. Dans certains cas, les deux architectures coexistent au sein d’une même infrastructure : un SAN pour les charges critiques, un NAS pour le partage quotidien et les sauvegardes.

Élise Prévost-Lemercier

Partager cet article

Retour en haut