Un mot de Zima
Merci, Bob, d’avoir transformé ton expérience avec ZimaCube en quelque chose de bien plus utile qu’un test conventionnel. Ton journal de suivi accompagne la machine à mesure qu’elle change de rôle — des premières impressions et du démontage matériel à ZimaOS, Windows Server, Proxmox, aux sauvegardes, à la supervision, aux agents d’IA et même à un routeur virtualisé — tout en conservant dans le même compte rendu les aspects que tu apprécies et ceux qui te frustrent. Ce type d’expérimentation honnête sur le long terme nous aide à comprendre non seulement ce que ZimaCube peut faire, mais aussi ce qui se passe après son intégration à un véritable homelab.
— Zima
Découvrez Bob Loves Tech
Bob Loves Tech est un passionné de homelab et un créateur de contenu technologique dont le travail couvre Windows, Linux, la virtualisation, les réseaux, l’auto-hébergement et le matériel qui les fait fonctionner.
Sa relation avec le matériel Zima est antérieure à ce projet. Bob avait déjà passé du temps avec d’anciens produits Zima, notamment ZimaBoard et ZimaBlade, avant de rejoindre le programme Zima Pioneer. Lorsque ZimaCube est arrivé, il a décidé de ne pas publier un unique test soigné avant de passer à autre chose. Il a plutôt créé le blog d’expérience ZimaCube, un dépôt public qui continue de s’enrichir à mesure que la machine évolue avec son homelab.
Bob décrit son projet comme un journal de suivi plutôt que comme un test formel. Cette distinction résume bien le projet. Il comprend sa première réaction au matériel, les éléments découverts après l’avoir ouvert, les systèmes d’exploitation essayés, l’infrastructure construite autour de la machine et les conclusions qui ont évolué après plusieurs semaines d’utilisation.
Documenter ZimaCube au-delà de la première impression
Les premiers articles du projet de Bob commencent comme la plupart des récits consacrés au matériel : déballer la machine, examiner la qualité de fabrication, vérifier les ports et les tiroirs pour disques, puis déterminer ce qui semble différent une fois le matériel posé physiquement sur le bureau.
Mais le journal ne s’arrête pas là. Bob revient au matériel après avoir vécu avec. Son dépôt comprend une présentation détaillée du matériel, un démontage complet, un suivi après six semaines, un examen plus approfondi des raisons pour lesquelles la mémoire, plutôt que les cœurs du processeur, est devenue le principal goulot d’étranglement en pratique, ainsi qu’un article distinct qui pose la question finalement essentielle pour tout évaluateur : dépenserait-il réellement son propre argent pour l’acheter ?
Cette progression fait toute la valeur du projet. Une première impression vous montre comment arrive un produit. Un journal de suivi vous montre ce qui résiste une fois la nouveauté passée.
Ouvrir le matériel et suivre les détails
L’un des chapitres consacrés au matériel s’intitule simplement Le démonter, ce qui en dit long sur l’approche de Bob.
Au lieu de considérer le ZimaCube comme un appareil NAS fermé, il a ouvert le châssis et documenté les composants internes, notamment le système de refroidissement et les petits détails matériels qui ne deviennent visibles que lorsque quelqu’un décide que la machine doit être réparable et modifiable.
Ce démontage alimente ensuite une autre partie du journal : ce qui a changé après six semaines et ce qui n’a pas changé. Certaines observations perdent de leur importance avec le temps. D’autres — notamment le refroidissement, le comportement du ventilateur, la capacité mémoire, l’accès aux mises à niveau et l’intégration du matériel dans un environnement fonctionnant en permanence — deviennent plus importantes.
Pour les lecteurs qui souhaitent approfondir les mêmes questions matérielles, notre guide de démontage du ZimaCube présente plus en détail la disposition interne et les possibilités de mise à niveau, tandis que 7 détails ingénieux de la conception du ZimaCube examine de plus près des éléments qui deviennent visibles lorsque le système est ouvert, plutôt qu’observé uniquement à travers un tableau de caractéristiques techniques.
Découvrir que la RAM compte davantage que d’ajouter des cœurs au processeur
L’une des entrées matérielles ultérieures aboutit à une conclusion bien plus utile qu’un énième graphique de benchmark : le ZimaCube n’avait pas besoin de davantage de cœurs de processeur pour la charge de travail de Bob. Il avait besoin de plus de mémoire.
Son journal décrit un système exécutant dix machines invitées, tandis que l’utilisation du processeur restait autour de 4 %, mais que la consommation mémoire avait grimpé à environ 27 Go. Cela change la manière dont il faut évaluer le matériel. Le processeur n’était pas la première limite pratique. C’était la configuration mémoire d’origine.
Pour une machine qui devient progressivement un hôte de virtualisation, un serveur de sauvegarde, un nœud de surveillance, un hôte de machines virtuelles faisant office de routeur et un environnement d’expérimentation de l’IA, la capacité mémoire devient une infrastructure plutôt qu’une simple caractéristique technique.
C’est exactement le genre de conclusion que peut faire émerger le récit d’une longue expérience utilisateur. Elle ne vient pas d’une analyse de ce que le processeur peut faire en théorie, mais de l’observation du système après l’accumulation progressive de charges de travail réelles.
Effacement de ZimaOS et installation de Windows Server 2025
L’expérience la plus marquante du dépôt de Bob a commencé lorsqu’il a supprimé ZimaOS et installé Windows Server 2025 directement sur le ZimaCube.
Bob décrit cette combinaison comme un assemblage étrange, et c’est précisément pour cela qu’il l’a essayée. Le projet est devenu un moyen de tester le matériel sans dépendre de l’environnement logiciel avec lequel il était livré : comportement de l’installation, recherche de pilotes, réseau, stockage, et pertinence persistante d’une plateforme NAS compacte lorsqu’elle est utilisée comme un serveur Windows polyvalent.
Cette expérience illustre également un aspect important de la philosophie matérielle de Zima. Supprimer ZimaOS ne met pas fin à la vie utile de la machine. Le matériel x86 reste une plateforme qui peut être reconstruite autour d’un autre système d’exploitation.
Nous avons transformé cette expérience en un guide plus structuré d’installation de Windows Server 2025 sur ZimaCube, qui couvre le processus d’installation, la configuration du pilote réseau Intel et la configuration du stockage pour les utilisateurs souhaitant explorer la même voie.
Soumettre ZimaOS à un test équitable avant de passer à autre chose
Windows Server ne représente qu’une partie de l’histoire des systèmes d’exploitation. Bob a également publié un avis sur ZimaOS dédié dans le journal du homelab.
Sa conclusion est volontairement plus nuancée que « bon » ou « mauvais ». Le dépôt présente ZimaOS comme une solution particulièrement adaptée aux appareils plus modestes, tout en s’interrogeant sur l’adéquation entre cette expérience simplifiée et ce qu’il attend d’un ZimaCube poussé plus loin dans la virtualisation et l’infrastructure de homelab.
Cette critique est utile, car Bob n’évalue pas ZimaOS comme quelqu’un qui essaie l’auto-hébergement pour la première fois. Il l’évalue du point de vue d’une personne qui exploite déjà un homelab composé de plusieurs systèmes et qui est à l’aise avec la gestion des couches inférieures elle-même.
Pour un autre utilisateur, la simplicité peut être une raison de rester. Pour Bob, la complexité croissante de l’infrastructure est finalement devenue une raison de partir.
Le même compromis est examiné dans notre comparatif entre ZimaOS, Proxmox et Windows Server, issu du même ensemble plus vaste d’expérimentations.
Faire de Proxmox le centre du homelab
Après avoir exploré d’autres pistes, Bob est finalement parvenu à une conclusion bien plus tranchée concernant le système d’exploitation qu’il voulait installer sur le ZimaCube : Proxmox était l’environnement le plus adapté à son homelab.
Le journal décrit un ZimaCube fonctionnant avec un stockage NFS de Synology et intégrant une flotte de trois hôtes. À ce stade, la machine n’est plus principalement évaluée comme un NAS. Elle est devenue une infrastructure.
Ce changement ouvre la voie à plusieurs articles ultérieurs du journal, car Proxmox fournit la base des prochaines expériences : infrastructure de sauvegarde, surveillance, services d’IA et virtualisation du réseau.
Pour les utilisateurs souhaitant mettre en place la même base, notre guide de configuration ZimaCube + Proxmox couvre le parcours, de la préparation du BIOS aux machines virtuelles, aux conteneurs LXC, au stockage, au réseau et au passthrough.
Construire les sauvegardes autour de l’infrastructure
Lorsqu’une machine devient une infrastructure, la question suivante n’est plus de savoir si elle peut exécuter davantage de services, mais ce qui se passe lorsque l’un de ces services disparaît.
Le journal Sauvegardes de Bob suit cette transition. Proxmox Backup Server entre en scène, avec l’épineuse question circulaire de la sauvegarde d’une infrastructure à l’aide d’une infrastructure qui fait elle-même partie du système protégé.
Le résultat consiste moins à trouver une cible de sauvegarde parfaite qu’à créer des couches rendant la récupération suffisamment prévisible pour que les sauvegardes cessent d’être une préoccupation constante pour Bob.
Cette expérience a servi de base à notre guide Proxmox Backup Server, qui développe cette idée avec les sauvegardes incrémentielles de machines virtuelles et de conteneurs, la rétention, la vérification et des couches de protection supplémentaires.
Surveiller le parc plutôt que le vérifier constamment
La question suivante de Bob est familière à tous ceux dont le homelab a dépassé le stade de quelques services : de quel niveau de surveillance une seule personne a-t-elle réellement besoin ?
Son article Surveiller le parc présente notamment des outils comme Pulse et Proxmox Data Center Manager, mais l’objectif le plus intéressant consiste à réduire l’attention manuelle requise par l’infrastructure.
Un système de surveillance efficace ne devrait pas ajouter un tableau de bord supplémentaire à consulter toute la journée. Il devrait rendre le fonctionnement normal discret et signaler clairement les pannes lorsque votre intervention est réellement nécessaire.
Nous avons approfondi cet aspect de l’expérience de Bob dans notre guide de surveillance d’un serveur personnel, qui couvre Pulse, Uptime Kuma, Proxmox Data Center Manager, ainsi que le moment où la surveillance devrait réduire la maintenance plutôt que l’augmenter.
Offrir un domicile permanent à un agent d’IA
Le journal évolue finalement vers un autre niveau de l’auto-hébergement : l’exécution d’un agent d’IA persistant sur le ZimaCube.
Dans Pourquoi Hermes Agent a sa place sur votre ZimaCube, Bob considère la machine non seulement comme une infrastructure de stockage ou de virtualisation, mais aussi comme un lieu toujours disponible où héberger un agent auto-hébergé.
Cette association prend tout son sens dans le contexte de tout ce qui l’a précédée. Une fois le ZimaCube connecté en permanence, relié au homelab, sauvegardé et surveillé, un agent peut devenir un service persistant supplémentaire plutôt que quelque chose lié à une session sur ordinateur portable.
Si vous souhaitez explorer ce flux de travail directement sur ZimaOS, notre guide de configuration de Hermes Agent pour ZimaOS couvre l’installation, la configuration des modèles, l’intégration des services de messagerie et l’accès au tableau de bord Hermes.
Transformer le ZimaCube en routeur OPNsense
L’une des expériences ultérieures les plus intéressantes confère à nouveau à la machine un rôle complètement différent : l’infrastructure réseau.
Le journal OPNsense de Bob examine les deux interfaces 2,5 GbE du ZimaCube avec Proxmox et se demande si une machine virtuelle de routeur ne serait pas encore l’un des usages les plus convaincants de ce matériel.
C’est ici que la décision précédente concernant le système d’exploitation commence à porter ses fruits. Proxmox permet à la même machine physique d’héberger des charges de travail qui auraient traditionnellement nécessité plusieurs appareils, tandis que les deux interfaces Ethernet offrent une voie naturelle pour séparer le WAN et le LAN au sein d’une configuration de pare-feu virtualisé.
Notre guide Proxmox explore également l’exécution d’OPNsense comme machine virtuelle de routeur logiciel sur ZimaCube, notamment la possibilité de transmettre des interfaces 2,5 GbE distinctes à l’appliance réseau.
L’intérêt réside dans le journal, pas dans une conclusion définitive
Pris dans son ensemble, le projet de Bob est bien plus intéressant qu’un test aboutissant à une conclusion définitive.
Le même ZimaCube apparaît sous plusieurs formes au fil de l’évolution du dépôt.
Tout commence par un nouveau matériel. Bob le déballe, examine sa fabrication, ouvre le châssis, s’interroge sur le refroidissement et commence à réfléchir aux mises à niveau.
L’expérience passe à Windows Server. La suppression de ZimaOS permet de vérifier si le matériel reste utile sans le logiciel avec lequel il a été livré.
La question du système d’exploitation revient sur le tapis. Bob évalue d’abord ZimaOS avant de conclure que son environnement, de plus en plus complexe, a besoin d’autre chose.
Il devient un hôte Proxmox. À partir de là, la machine rejoint un parc plus vaste et commence à assumer de nouvelles responsabilités d’infrastructure.
Il s’intègre au système de sauvegarde et de supervision. Proxmox Backup Server, Pulse et la gestion du parc font évoluer l’objectif : il ne s’agit plus seulement d’« ajouter des services », mais de les rendre suffisamment fiables pour ne plus avoir à y penser.
Il devient ensuite un hôte IA et un équipement réseau. Hermes Agent et OPNsense ne sont pas des expériences isolées ; elles sont possibles parce que les couches d’infrastructure précédentes sont déjà en place.
Le résultat correspond exactement à ce que Bob avait promis au départ : non pas un test formel, mais des notes, des expériences, des opinions qui évoluent avec l’expérience et un projet de homelab de plus en plus ambitieux.
L’histoire d’un utilisateur est devenue une bibliothèque de guides ZimaCube
Le projet de Bob montre également pourquoi les tests menés à long terme par la communauté ont une valeur qui dépasse le homelab d’une seule personne.
Plusieurs expériences documentées dans le blog ZimaCube Experience ont depuis donné naissance à des ressources Zima plus approfondies : installation de Windows Server, déploiement de Proxmox, choix du système d’exploitation, architecture des sauvegardes et supervision du homelab.
Cela crée une boucle utile entre l’expérience de la communauté et la documentation. Bob essaie quelque chose par curiosité. Le journal consigne ce qui s’est passé. Les éléments utiles deviennent plus faciles à reproduire pour la personne suivante.
L’histoire est toujours en cours d’écriture
L’histoire de Bob Loves Tech et de Zima est toujours en cours d’écriture. Son blog ZimaCube Experience est déjà passé du déballage et du démontage du matériel à ZimaOS, Windows Server, Proxmox, aux sauvegardes, à la supervision d’un parc, à Hermes Agent et à OPNsense — et tout l’intérêt d’un journal régulièrement alimenté est qu’il n’est pas nécessaire d’avoir une configuration finale.
À mesure que le homelab évolue, le rôle du ZimaCube peut évoluer avec lui. Si vous voulez voir ce que Bob expérimentera ensuite, suivez le blog continu ZimaCube Experience sur GitHub.
