Combien de RAM pour un NAS ? Guide complet par système 2026

Mis à jour : 2026-07-23· Dernière vérification juillet 2026

Peu de questions sur les NAS reçoivent une réponse aussi gonflée que celle-ci. Demandez sur un forum combien de RAM il faut à votre machine et l'un citera une règle qui évolue avec la taille du disque, un autre insistera pour dire que 64 Go sont le minimum raisonnable, et un troisième vous racontera que son Synology à quatre disques tourne depuis dix ans sur 2 Go sans un accroc. Les trois décrivent des machines différentes faisant des travaux différents, et c'est exactement pour cela qu'un chiffre unique ne colle jamais. La quantité de mémoire dont un NAS a besoin est fixée presque entièrement par le logiciel qui tourne et les extras que vous empilez par-dessus, d'où l'intérêt de répondre par système : avec des chiffres concrets et une note sur le moment où chacun devrait monter. Si vous cherchez la vue d'ensemble sur la façon dont le système d'exploitation dirige tout le reste du matériel, elle se trouve dans notre guide du matériel NAS ; ici, nous restons étroits et répondons directement à la question de la RAM.

La réponse courte, puis le tableau

Le mécanisme qui explique presque tout ce qui suit est simple : un NAS utilise la mémoire libre comme cache des fichiers touchés récemment, il paraît donc rapide quand les données sont chaudes et rend cette mémoire dès qu'une application la réclame. C'est pour cela que « la RAM libre est de la RAM gaspillée » est un adage juste, et pour cela qu'une machine qui « utilise » presque toute sa mémoire n'est pas une machine qui en manque. La capacité brute déplace à peine le chiffre, car mettre en cache une bibliothèque de 40 To et une de 4 To coûte à peu près la même empreinte au repos ; ce qui la déplace, ce sont les programmes qui tournent, qu'il s'agisse de VMs, de conteneurs ou d'une fonction ZFS qui échange de la mémoire contre un gain précis. Le tableau ci-dessous est la réponse courte pour les cinq systèmes que les gens installent vraiment.

Lisez le tableau comme un plancher et une cible confortable, pas comme un plafond : rien ne casse si vous montez plus haut, et la colonne « montez si » est le vrai déclencheur de dépense. La conclusion, c'est que pour un premier NAS dont le rôle est fichiers, sauvegardes et peut-être quelques applis, 8 Go sont un point d'atterrissage sensé sur presque tous les systèmes, et les sections ci-dessous expliquent pourquoi chacun se situe là où il se situe.

NAS boîtier : Synology DSM et QNAP

Un boîtier scellé est réglé pour paraître réactif avec peu de mémoire, donc les 2 à 4 Go d'usine d'un Synology ou QNAP d'entrée de gamme suffisent vraiment pour le travail central : partager des fichiers et faire tourner des sauvegardes. ASUSTOR, qui vend la même classe de machine, le dit clairement dans son propre guide : 2 à 4 Go suffisent largement pour le stockage et le partage de fichiers de base, et 8 Go ou plus commencent à valoir le coup dès que la virtualisation, plusieurs applis ou des services plus lourds entrent en jeu. Au moment où votre boîtier cesse d'être un serveur de fichiers pour devenir un petit serveur d'applications, ce chiffre d'usine devient juste.

Ce qui pousse réellement un boîtier à réclamer plus de RAM est prévisible : une pile de conteneurs Docker, Synology Surveillance Station qui enregistre plusieurs caméras, une bibliothèque Photos qui construit son index de visages et d'objets, ou une VM légère. Le piège à surveiller, c'est que beaucoup de modèles d'entrée à deux et quatre baies soudent leur mémoire à la carte : la RAM que vous achetez le premier jour est celle que vous gardez. Si vous savez déjà que vous voulez des conteneurs, de l'enregistrement de caméras ou de l'indexation photo, le geste concret est de choisir un palier de modèle qui embarque 8 Go ou expose un slot SODIMM, plutôt que d'économiser vingt euros sur une machine que vous ne pouvez pas faire grandir. Quel palier, cela dépend de la même décision de plateforme que travaille notre guide d'achat NAS.

OpenMediaVault et Debian pur : la base peu gourmande en RAM

OpenMediaVault se situe à l'extrémité frugale de l'échelle parce qu'il n'est qu'une fine couche de gestion au-dessus de Debian Linux, et Debian se contente de très peu. Les prérequis matériels du projet indiquent 1 Gio de RAM comme minimum, ce qui fait d'OpenMediaVault le choix classique pour un Raspberry Pi ou un mini-PC recyclé servant quelques disques. En pratique, 2 à 4 Go vous donnent une marge confortable pour l'interface web, les partages SMB et une poignée de plugins sans jamais penser à la mémoire.

Le chiffre ne commence à compter que lorsque vous étendez OpenMediaVault avec les plugins Docker et Portainer et faites tourner des conteneurs, moment où ce sont les conteneurs, et non le système de base, qui deviennent le budget. Comme une machine Debian ou OpenMediaVault classique utilise ext4 ou Btrfs plutôt que ZFS, il n'y a pas de cache ARC qui réclame de la mémoire en silence, donc ce que vous allouez aux conteneurs se rapproche de ce que la machine consomme. La conclusion : pour un serveur de fichiers simple sous OpenMediaVault, 4 Go sont généreux, et vous ne prévoyez plus que quand vous savez que la liste de conteneurs s'allonge. Si vous le comparez aux alternatives, notre comparatif Unraid vs TrueNAS vs OpenMediaVault cartographie où chacun s'inscrit.

Unraid : l'array est bon marché, les extras ne le sont pas

Unraid est l'exemple le plus clair de pourquoi la capacité brute est la mauvaise référence pour dimensionner la RAM. Son array lit et écrit un disque à la fois au lieu de répartir sur tous, l'array lui-même est donc peu exigeant en mémoire quel que soit le nombre de téraoctets qu'il contient, et de modestes 4 Go font tourner la seule partie stockage. La raison pour laquelle les gens mettent 16, 32 ou 64 Go dans une machine Unraid n'a rien à voir avec l'array et tout à voir avec ce qu'ils empilent par-dessus.

Cette couche est là où va le vrai budget : les conteneurs Docker que font tourner la plupart des utilisateurs d'Unraid, une ou plusieurs machines virtuelles, et la mémoire qu'un pool de cache NVMe actif aime avoir autour de lui. Un serveur multimédia avec une douzaine de conteneurs plus une VM Windows est une machine véritablement différente d'un serveur de fichiers nu, et 8 Go sont une base confortable pour l'array plus un jeu léger de conteneurs, tandis que le saut vers plus de RAM est dicté par votre liste précise d'applis et de VMs. Comme l'auto-hébergement est tout le but de la plupart des builds Unraid, notre guide de l'auto-hébergement sur NAS est le meilleur endroit pour dimensionner cet appétit de conteneurs, et le comparatif de systèmes lié plus haut couvre où le modèle à un disque d'Unraid gagne et perd. La conclusion : dimensionnez la RAM d'Unraid en additionnant conteneurs et VMs, et traitez l'array comme presque gratuit.

TrueNAS et ZFS : le mythe du 1 Go par To

C'est le système autour duquel le folklore s'est construit, il mérite donc la correction la plus claire. ZFS traite la mémoire libre comme un cache de lecture appelé Adaptive Replacement Cache, ou ARC, qui équilibre les données utilisées récemment contre celles utilisées fréquemment pour qu'un pool chaud paraisse rapide même sur des disques mécaniques. Comme ce cache se dilate pour remplir la RAM que vous lui donnez et se rétracte à l'instant où une application a besoin de mémoire, plus de RAM achète surtout des lectures plus rapides plutôt que de satisfaire une obligation stricte, tout le contraire de ce que suggère la règle du « 1 Go par To ».

Les chiffres honnêtes sont bien plus doux que la règle. Le guide matériel de TrueNAS traite 8 Go comme le plancher de travail et oriente la plupart des builds vers 16 Go, ce qui signifie qu'un pool multimédia domestique de 40 To tourne parfaitement sur 16 ou 32 Go plutôt que sur les 40 Go qu'exigerait la règle populaire. La seule chose qui évolue vraiment avec la capacité, c'est la déduplication, que le même guide chiffre à environ 5 Go de RAM par To de données dédupliquées, et le dedup est une fonction que vous activez délibérément, pas un réglage par défaut. Il vaut la peine de savoir que la règle empirique n'a pas totalement disparu : même les prérequis système de Proxmox indiquent toujours environ 1 Go de mémoire par To quand l'hôte utilise ZFS, comme chiffre de planification prudent et non comme un mur. Là où la RAM supplémentaire gagne vraiment sa place sous ZFS, c'est plus étroit qu'on ne le croit : le dedup comme ci-dessus, les pools chargés de métadonnées avec des millions de petits fichiers, et les charges multi-utilisateurs ou de virtualisation où un cache plus grand relève le taux de succès. Pour l'histoire complète de l'ARC, plus l'ECC, les HBA et les périphériques de cache, notre analyse détaillée des prérequis matériels de ZFS descend d'un cran ; la conclusion ici : démarrez un pool ZFS domestique à 16 Go, passez à 32 Go pour beaucoup d'utilisateurs ou de VMs, et ne courez après un chiffre par To que si vous activez le dedup à dessein.

Proxmox et virtualisation : ce sont les VMs qui fixent le budget

Proxmox renverse tout le cadrage, car un hôte de virtualisation se définit par ses invités, pas par son stockage. L'hyperviseur lui-même est léger : les prérequis de Proxmox VE demandent environ 2 Go pour le système d'exploitation et ses services, puis chaque machine virtuelle et conteneur ajoute son allocation fixe par-dessus. Une VM Windows à laquelle vous donnez 8 Go prend vraiment 8 Go du pool, l'arithmétique mémoire est donc additive d'une manière qu'elle ne l'est jamais sur un simple serveur de fichiers.

Cela transforme le dimensionnement en liste de courses plutôt qu'en règle : additionnez ce dont chaque VM et conteneur prévu a besoin, ajoutez les quelques gigaoctets de l'hôte et laissez une marge pour l'ARC de ZFS si l'hôte utilise du stockage ZFS. Un homelab qui fait tourner quelques VMs plus une pile de conteneurs atterrit de façon réaliste à 16 à 32 Go, et les labs plus lourds grimpent à partir de là. Comme c'est la charge qui dirige, la même planification d'auto-hébergement s'applique : décidez d'abord des services, puis achetez la RAM qu'ils totalisent. La conclusion : dimensionnez la RAM de Proxmox pour les invités, traitez l'hôte comme une erreur d'arrondi, et laissez toujours de la place pour démarrer une machine de plus.

Ce qui consomme vraiment de la RAM, et ce qui n'en consomme pas

Dès que vous cessez de dimensionner la mémoire d'après la taille du disque, il aide de savoir quelles charges la consomment vraiment et lesquelles sont innocentes en silence, car c'est justement dans cet écart que se produit la majorité des dépenses de trop. La liste ci-dessous classe les suspects habituels, et les deux dernières entrées sont celles que l'on comprend le plus souvent à l'envers.

• Les machines virtuelles sont le plus gros consommateur unique, car vous allouez un bloc fixe de RAM à chacune, réservé tant que la VM tourne.
• Les conteneurs Docker sont modestes individuellement mais s'additionnent sur une pile, et ceux à base de données comme Immich ou Nextcloud pèsent plus qu'un simple conteneur utilitaire.
• La déduplication ZFS est la vraie origine de la règle par To, à environ 5 Go de RAM par To de données dédupliquées, d'où son statut de fonction optionnelle et non de réglage par défaut.
• Le cache utilise toute la mémoire libre comme cache de lecture, donc des valeurs élevées d'« utilisé » sont normales et saines ; le système rend cette mémoire à l'instant où un programme en a besoin.
• Le transcodage vidéo est la fausse alerte célèbre : c'est un travail de CPU ou de GPU, pas un problème de RAM. La doc de Jellyfin décrit le déchargement du transcodage à la volée sur un GPU pour tourner efficacement sans solliciter le CPU, et ni Plex ni Jellyfin ne font de la mémoire le goulot d'étranglement.

Ce dernier point mérite d'être retenu quand vous planifiez une machine multimédia, car le réflexe d'acheter plus de RAM « pour Plex » est mal orienté. Ce qu'un serveur multimédia veut vraiment, c'est un CPU ou un GPU avec transcodage matériel, ce que couvre notre guide du stockage pour Plex Media Server aux côtés du volet stockage. Pour les bidouilleurs : avant de dépenser en mémoire, mesurez la machine sous une charge réaliste avec free -h ou htop, et sous ZFS vérifiez le taux de succès de l'ARC avec arcstat ; un taux qui reste élevé quand la machine est occupée signifie que le cache est à l'aise et que plus de RAM apporterait peu, tandis qu'un taux qui s'effondre sous charge est le vrai signal pour en ajouter. Cette approche mesurée bat à chaque fois le dimensionnement d'après la capacité du pool. La conclusion : financez généreusement les VMs, les conteneurs et le dedup, et cessez de vous soucier du transcodage et de la capacité brute.

Un mot rapide sur l'ECC

Une clarification évite une confusion courante : combien de RAM il vous faut et si cette RAM doit être ECC sont deux questions distinctes. La mémoire ECC (code correcteur d'erreurs) concerne l'intégrité des données, elle corrige en silence le bit occasionnellement retourné avant qu'il n'atteigne vos disques, pas la capacité ni la vitesse, ajouter de l'ECC ne change donc rien aux chiffres du tableau ci-dessus. OpenZFS lui-même qualifie l'ECC de fortement recommandée plutôt qu'obligatoire, et les histoires d'horreur propres à ZFS sont un mythe. La version courte et honnête : l'ECC vaut le coup sur un build dont toute la raison d'être est des données irremplaçables, et se saute sur une machine multimédia décontractée, mais nous développons le cas complet, et quelles plateformes la prennent en charge, dans RAM ECC pour NAS et ZFS. La conclusion : décidez d'abord la quantité d'après votre charge, puis séparément si les données justifient l'ECC.

Recommandation : ce qu'il faut vraiment acheter

Pour un simple serveur de fichiers, une cible de sauvegarde ou une machine Time Machine, 4 à 8 Go sont toute l'histoire, et sur un boîtier la mémoire d'usine suffit généralement. Pour un serveur multimédia avec quelques conteneurs (Plex ou Jellyfin plus les applis auxiliaires habituelles), 8 Go sont le point d'atterrissage confortable, et l'argent que vous mettriez dans plus de RAM est mieux placé dans un CPU à transcodage matériel. Pour un pool domestique TrueNAS ou ZFS, démarrez à 16 Go et ne passez à 32 Go que lorsque vous ajoutez beaucoup d'utilisateurs simultanés ou des machines virtuelles, en ignorant la règle du 1 Go par To sauf si vous activez la déduplication à dessein, où vous prévoyez plutôt environ 5 Go par To. Pour un homelab qui fait tourner des machines virtuelles sous Unraid ou Proxmox, dimensionnez la RAM en additionnant invités et conteneurs, ce qui signifie de façon réaliste 32 Go ou plus. Dans tous les cas, une habitude bat n'importe quelle règle : si la carte le permet, achetez un palier au-dessus et laissez un slot libre, sinon démarrez raisonnablement et laissez l'usage réel, pas un fil de forum, vous dire quand ajouter. Une fois la mémoire réglée, vérifiez les disques et l'agencement du pool derrière face à des modèles réels dans notre base de données de disques NAS, et dimensionnez la capacité elle-même dans le calculateur RAID.

Articles liés

Guide du matériel NAS 2026 : quoi regarder selon l'OS et le système de fichiers

Prérequis matériels de ZFS 2026 : RAM, ECC, HBA et SLOG

RAM ECC pour NAS et ZFS : obligatoire ou mythe ?

Unraid vs TrueNAS vs OpenMediaVault : le comparatif complet des systèmes NAS

Auto-hébergement sur NAS : remplacez vos abonnements cloud par vos propres services