Monter un homelab en 2026 avec des mini-PC reste l’un des meilleurs moyens d’apprendre la virtualisation sans transformer son bureau en baie informatique. Les machines compactes actuelles offrent assez de cœurs, de mémoire et de stockage NVMe pour reproduire une grande partie des scénarios rencontrés en entreprise : cluster de virtualisation, migration à chaud, réseaux segmentés, sauvegardes, Kubernetes, supervision et automatisation.
Le choix de l’hyperviseur est toutefois devenu moins évident. Proxmox VE est aujourd’hui très accessible et bénéficie d’une communauté active. ESXi reste une référence technique, mais son accès dans le cadre d’une licence personnelle est désormais plus restreint qu’autrefois. Quant à vSAN ESA, il peut être tentant de vouloir le tester sur trois mini-PC NVMe, mais il faut distinguer un exercice pédagogique utile d’un environnement artificiellement forcé.
Ce retour d’expérience s’appuie sur un homelab composé de trois mini-PC récents, chacun équipé d’un processeur mobile x86 à 8 cœurs logiques ou davantage, de 64 Go de RAM, de deux SSD NVMe et d’une connectivité Ethernet 2,5 GbE. Ce format est réaliste en 2026 : silencieux, peu encombrant, relativement sobre et suffisamment puissant pour faire fonctionner plusieurs dizaines de petites VM ou de conteneurs.
Une base matérielle cohérente pour 2026
Le mini-PC n’est pas un serveur rack miniaturisé. Il faut accepter ses contraintes : peu de ports réseau, pas ou peu de gestion hors bande, capacité mémoire limitée selon les modèles, refroidissement compact et choix parfois réduit pour le stockage. En contrepartie, le ratio performances, bruit et consommation est excellent pour un environnement personnel.
Une configuration homogène simplifie sensiblement la vie. Pour trois noeuds, la cible raisonnable est la suivante :
- processeur récent avec virtualisation matérielle activable dans l’UEFI ;
- 32 Go de RAM comme minimum réaliste, 64 Go recommandés ;
- deux SSD NVMe par noeud si l’objectif inclut le stockage distribué ;
- réseau 2,5 GbE au minimum, idéalement 10 GbE si le budget et les adaptateurs le permettent ;
- un petit switch administrable pour les VLAN ;
- un quatrième équipement léger pour les sauvegardes, le quorum ou les services d’infrastructure.
Le premier écueil concerne les cartes réseau. Les chipsets Ethernet intégrés aux mini-PC récents sont souvent très bien pris en charge sous Linux, mais leur support peut être plus variable sous ESXi. Avant tout achat, il faut valider précisément la compatibilité du contrôleur réseau et du contrôleur de stockage avec la version d’hyperviseur visée. Une carte 2,5 GbE fonctionnelle sous Proxmox VE ne garantit pas qu’elle sera reconnue nativement par ESXi.
Le second écueil est le stockage. Les SSD NVMe grand public sont rapides en lecture et en écriture séquentielle, mais la virtualisation et le stockage distribué sollicitent surtout les écritures aléatoires, les latences de synchronisation et la régularité des performances. Un modèle sans DRAM, avec un cache SLC agressif ou une endurance faible peut produire des résultats instables dès que plusieurs VM écrivent simultanément. Pour aller plus loin, consultez notre guide complet pour construire son homelab.
Pour un lab, il ne faut pas viser les SSD les plus onéreux du marché professionnel, mais il est préférable de choisir des modèles connus pour leur endurance et leur comportement soutenu. La capacité compte aussi : 1 To par disque devient vite confortable, surtout lorsque l’on conserve plusieurs snapshots, images ISO et sauvegardes locales temporaires.
Proxmox VE : le choix le plus naturel pour apprendre au quotidien
Proxmox VE s’impose souvent comme la plateforme la plus pragmatique pour un homelab moderne. Son installation est simple, son interface est complète, et les composants sous-jacents sont standards : KVM pour les machines virtuelles, LXC pour les conteneurs, Linux pour le système, ZFS ou Ceph pour le stockage selon l’architecture retenue.
L’avantage principal n’est pas seulement son coût. L’absence de licence obligatoire enlève une friction importante : il devient possible de reconstruire un cluster, de tester une mise à niveau ou de casser une configuration sans craindre de perdre l’accès à une fonctionnalité essentielle.
Avec trois noeuds, on peut créer un cluster rapidement :
pvecm create homelab-2026
Sur les autres noeuds, la commande d’ajout fournie par le premier serveur suffit généralement :
pvecm add 192.168.50.11
Le cluster Proxmox VE permet ensuite d’expérimenter :
- la haute disponibilité ;
- la migration à chaud de VM ;
- les VLAN sur bridges Linux ;
- les sauvegardes intégrées ;
- les rôles et permissions ;
- les templates cloud-init ;
- l’automatisation avec l’API, Terraform ou Ansible ;
- les conteneurs LXC, particulièrement utiles pour les services légers.
Pour un petit lab, ZFS local constitue un excellent point de départ. Il apporte les snapshots, la compression, les contrôles d’intégrité et une administration lisible. En revanche, ZFS ne transforme pas à lui seul trois hôtes en stockage partagé. La migration à chaud sans indisponibilité exige un stockage commun ou une réplication adaptée au scénario.
Proxmox VE propose une réplication ZFS entre noeuds. Elle est intéressante pour comprendre la reprise après incident, mais il faut garder en tête qu’elle est asynchrone. Une VM peut redémarrer sur un autre noeud après une panne, mais les dernières écritures non répliquées peuvent être perdues. C’est acceptable pour un lab, à condition de l’assumer.
Ceph devient pertinent lorsque le but est précisément de comprendre le stockage distribué. Trois noeuds, deux NVMe par noeud et un réseau correct permettent de bâtir un cluster Ceph fonctionnel. Il faut toutefois rester lucide : sur du 2,5 GbE, les performances ne seront pas comparables à une infrastructure équipée de liens 25 GbE ou 100 GbE. Le résultat reste néanmoins très formateur.
La commande suivante donne une première vue de la santé du cluster Ceph :
ceph -s
Dans un homelab, Ceph doit être considéré comme un sujet d’apprentissage, pas comme une obligation. Il consomme de la RAM, exige une surveillance minimale et ajoute des couches de diagnostic. Pour héberger quelques VM personnelles, ZFS local et des sauvegardes rigoureuses sont souvent plus judicieux.
Ce type de cluster sert aussi de terrain d’exercice pour des besoins plus professionnels : de nombreux développeurs auto-hébergent leurs environnements de dev et de staging sur une infrastructure Proxmox ou ESXi personnelle plutôt que de multiplier les VPS. Ce guide d’hébergement et de déploiement Symfony détaille les options côté application, à combiner avec la maîtrise de l’hyperviseur vue ici.
ESXi en 2026 : toujours instructif, mais moins accessible
ESXi reste important à connaître, en particulier pour les administrateurs travaillant dans des environnements historiques ou fortement standardisés autour de l’écosystème VMware. Les concepts restent structurants : datastores, vSwitch, port groups, vMotion, DRS, HA, politiques de stockage et intégration à vCenter.
Le problème n’est pas technique, mais pratique. L’accès à une licence personnelle utilisable durablement et aux composants nécessaires pour reproduire une plateforme complète est devenu plus contraint. Les modalités de téléchargement, d’évaluation et de droits associés évoluent régulièrement. Il faut donc vérifier les conditions officielles au moment du déploiement plutôt que de partir d’anciens tutoriels.
Pour un lab ESXi, la première difficulté est la compatibilité matérielle. Les mini-PC grand public utilisent fréquemment des contrôleurs Ethernet ou NVMe absents des listes de compatibilité formelles. Dans certains cas, il existe des pilotes communautaires ou des images personnalisées. Dans d’autres, il faut ajouter un adaptateur réseau USB compatible ou choisir un matériel plus ancien mais mieux supporté.
Cette situation est révélatrice : un homelab ESXi demande désormais plus de préparation qu’un homelab Proxmox VE sur le même matériel. Ce n’est pas nécessairement un défaut si l’objectif est d’apprendre le dépannage, l’analyse des journaux ou les contraintes de qualification matérielle. En revanche, c’est un mauvais point de départ pour quelqu’un qui veut consacrer son temps à la virtualisation plutôt qu’à contourner des incompatibilités de pilotes. Pour aller plus loin, consultez l’état de l’art de Proxmox VE.
ESXi conserve un intérêt concret dans trois cas :
- reproduire des opérations réalisées dans un environnement professionnel existant ;
- préparer une migration, une montée de version ou une validation de procédure ;
- comprendre les concepts VMware sans chercher à construire une plateforme permanente à coût nul.
Dans tous les autres cas, son statut de plateforme de homelab généraliste est moins évident qu’il y a quelques années. La restriction des options personnelles réduit la liberté d’expérimentation, notamment autour des fonctions dépendantes de vCenter.
vSAN ESA sur NVMe grand public : expérience utile, plateforme peu réaliste
vSAN ESA, pour Express Storage Architecture, attire naturellement les personnes qui veulent expérimenter une architecture de stockage distribuée moderne. Son positionnement repose sur une pile optimisée pour les périphériques flash, avec une logique différente des architectures historiques organisées autour de groupes de disques cache et capacité.
Sur le papier, trois mini-PC dotés de deux NVMe chacun semblent parfaits pour l’exercice. En pratique, plusieurs limites s’accumulent.
La première est matérielle. vSAN ESA a des exigences précises en matière de compatibilité, de contrôleurs, de périphériques NVMe, de réseau et de versions logicielles. Les SSD grand public ne sont généralement pas qualifiés pour une utilisation vSAN de production. Cela ne veut pas dire qu’ils ne fonctionneront jamais dans un lab, mais qu’un comportement anormal ne sera ni surprenant ni forcément diagnostiquable.
La seconde limite est le réseau. Le stockage distribué n’est pas seulement une question de débit théorique. La latence, la stabilité et la capacité à encaisser des écritures synchrones sont déterminantes. Un réseau 2,5 GbE permet de découvrir les mécanismes et de lancer des tests simples, mais il devient rapidement le goulot d’étranglement. Les résultats de benchmarks risquent alors de mesurer davantage le réseau et les limites thermiques des mini-PC que l’architecture ESA elle-même.
La troisième limite est la consommation de ressources. Un cluster vSAN ESA, vCenter et plusieurs VM de charge représentent un besoin mémoire non négligeable. Avec 32 Go par noeud, l’environnement fonctionne vite à l’étroit. Avec 64 Go par noeud, l’expérience devient plus confortable, mais les mini-PC atteignent parfois leur plafond mémoire ou deviennent coûteux.
Tester vSAN ESA peut donc avoir du sens si l’objectif est explicitement pédagogique :
- comprendre les objets de stockage et les politiques ;
- observer les mécanismes de tolérance aux pannes ;
- manipuler les alarmes et la reconstruction ;
- étudier l’impact d’une panne de disque ou de noeud ;
- pratiquer les procédures de maintenance ;
- comparer les latences avec un datastore local ou NFS.
En revanche, il ne faut pas transformer ce test en recommandation d’architecture. Un cluster ESA basé sur des NVMe grand public et du réseau 2,5 GbE est un banc d’essai. Ce n’est pas une maquette fidèle d’un déploiement d’entreprise, ni une plateforme domestique nécessairement plus fiable qu’un hôte unique avec de bonnes sauvegardes.
Un test utile consiste à instrumenter les VM plutôt que de se contenter d’un chiffre IOPS. Par exemple, lancer une charge fio depuis une VM et suivre simultanément la latence côté stockage, l’utilisation réseau et la température des SSD :
fio --name=randwrite --filename=/mnt/test/fio.img --size=20G \
--bs=4k --rw=randwrite --iodepth=32 --numjobs=2 \
--direct=1 --time_based --runtime=300 --group_reporting
Le résultat intéressant n’est pas uniquement le débit moyen. Il faut observer les percentiles de latence, les variations en fin de cache SLC, les erreurs éventuelles et la dégradation après plusieurs minutes de charge.
Réseau, sauvegarde et énergie : les sujets qui font réellement progresser
Dans un homelab, la couche réseau est souvent plus éducative que le choix de l’hyperviseur. Un switch administrable permet de séparer proprement les flux :
- administration des hôtes ;
- trafic des VM ;
- migration ;
- stockage distribué ;
- sauvegarde ;
- réseau de test exposé à Internet, si nécessaire.
Avec Proxmox VE, une configuration VLAN-aware sur un bridge Linux permet de tester cette segmentation sans multiplier les interfaces physiques :
auto vmbr0
iface vmbr0 inet static
address 192.168.50.11/24
gateway 192.168.50.1
bridge-ports enp1s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
La sauvegarde est l’autre domaine à ne pas négliger. Un cluster n’est pas une sauvegarde. La réplication n’est pas une sauvegarde. Un datastore distribué n’est pas une sauvegarde. Une suppression logique, un chiffrement malveillant, une erreur de configuration ou une corruption répliquée peuvent affecter tous les noeuds.
La règle minimale consiste à conserver une copie hors du cluster. Un NAS, un disque USB chiffré tournant par rotation, un serveur de sauvegarde séparé ou un stockage objet sont de bonnes options selon le budget. L’objectif est de pouvoir restaurer une VM complète et, surtout, de tester cette restauration.
Enfin, il faut mesurer la consommation réelle. Trois mini-PC modernes peuvent rester sous les 60 à 100 W au repos selon les disques, la mémoire et les réglages d’alimentation. Cela reste raisonnable, mais un lab laissé allumé toute l’année a un coût. Programmer l’arrêt des charges inutiles, suspendre les VM de test et éviter les benchmarks prolongés apporte plus de valeur qu’une optimisation obsessionnelle de quelques watts. Pour aller plus loin, consultez automatiser son homelab.
Verdict : privilégier Proxmox VE, garder ESXi et vSAN comme laboratoires ciblés
Pour un homelab d’apprentissage en 2026, Proxmox VE est le choix le plus équilibré. Il s’installe facilement sur des mini-PC récents, exploite bien le matériel grand public, propose des fonctions de cluster utiles et permet d’aller progressivement de la VM simple à Ceph, l’automatisation et l’infrastructure déclarative.
ESXi conserve une valeur pédagogique pour les personnes qui doivent travailler avec cet environnement dans leur contexte professionnel. Mais il faut l’aborder comme un lab spécifique, préparé autour de la compatibilité matérielle et des droits disponibles, pas comme l’option gratuite par défaut.
vSAN ESA mérite d’être testé si l’on veut comprendre ses mécanismes ou pratiquer des opérations de stockage distribué dans cet écosystème. En revanche, essayer de le faire tourner en permanence sur des NVMe grand public et un réseau modeste apporte rarement un bénéfice proportionnel à la complexité introduite.
Le meilleur homelab n’est pas celui qui empile le plus de produits. C’est celui que l’on peut reconstruire, sauvegarder, documenter et faire évoluer. Trois mini-PC, 64 Go de RAM par noeud, du NVMe correct, un réseau VLANisé et Proxmox VE constituent en 2026 une base durable pour apprendre réellement la virtualisation.
