ZimaBlade + OpenClaw : une configuration de homelab assistée par l’IA en conditions réelles

Il ne s'agit pas d'une configuration NAS à usage unique. Un étudiant en génie mécanique utilise un ZimaBlade 7700 dans le cadre d'un homelab à deux nœuds qui associe médias auto-hébergés, automatisation de la maison connectée, supervision, accès à distance, applications personnelles, sauvegardes et administration de serveur assistée par IA.

L'aspect le plus intéressant de cette configuration réside dans la manière dont ses différentes couches fonctionnent ensemble. ZimaOS fournit un environnement de serveur domestique facile à gérer, le ZimaBlade prend en charge les charges de travail légères et fonctionnant en continu aux côtés d'un ancien serveur Dell, et des outils comme OpenClaw et Hermes servent à faciliter le déploiement, la maintenance, le dépannage et l'administration de serveurs à distance.

La configuration en un coup d'œil

Le projet : un homelab à deux nœuds axé sur l'auto-hébergement

L'utilisateur à l'origine de cette configuration est étudiant en dernière année de génie mécanique et s'intéresse à l'automatisation, aux serveurs, aux projets NAS et à l'auto-hébergement. Son objectif est simple : consacrer davantage de temps à configurer une fois des systèmes utiles, puis laisser ces systèmes lui faire gagner du temps et réduire les abonnements récurrents sur le long terme.

Son homelab actuel est réparti entre deux machines plutôt que de concentrer toutes les charges de travail sur un seul serveur. Un ancien ordinateur de bureau Dell a d'abord servi de serveur principal, puis un ZimaBlade 7700 doté de 16 Go de RAM a été ajouté pour étendre l'environnement et offrir davantage de flexibilité pour les services fonctionnant en continu, la supervision, les sauvegardes et les futurs workloads d'IA.

Les deux systèmes sont connectés au même réseau domestique et sont destinés à fonctionner comme des éléments d'un même homelab plutôt que comme des serveurs isolés. L'idée est de déplacer les services entre eux en fonction des besoins en ressources, tout en gardant l'automatisation, la surveillance, les services domotiques et les outils d'IA connectés.

Pourquoi le ZimaBlade convient à ce homelab

Le projet n'avait pas besoin d'un autre ordinateur de bureau moderne au format standard. Il lui fallait quelque chose entre un Raspberry Pi et un PC conventionnel : suffisamment compact pour rester constamment en ligne, abordable pour le budget d'un étudiant, mais suffisamment évolutif pour prendre en charge le stockage et de futures mises à niveau matérielles.

Le ZimaBlade convenait à ce rôle, car il offrait davantage de performances et de flexibilité d'extension que l'ancienne configuration Raspberry Pi 4 de l'utilisateur, tout en restant beaucoup plus petit qu'un serveur de bureau.

Le slot PCIe était particulièrement important. L'utilisateur prévoit d'ajouter une NVIDIA Tesla P4 low-profile avec 8 Go de VRAM pour les charges de travail d'IA locales. Comme cette carte est conçue pour une enveloppe énergétique de 75 watts et ne nécessite pas de connecteur d'alimentation externe distinct pour GPU, elle est devenue une option intéressante pour cette conception de homelab compacte.

L'extension du stockage a également été un facteur. Le ZimaBlade actuel utilise temporairement un stockage USB Samsung, tandis que l'achat de disques durs plus volumineux reste prévu, mais le plan à long terme comprend l'ajout de disques, un RAID1 lorsque cela est approprié et une stratégie de sauvegarde conservant des copies sur des appareils distincts.

Ce que le homelab exécute réellement

L'environnement s'est largement développé au-delà du simple stockage réseau. Il couvre désormais les médias, l'automatisation, l'accès à distance, la surveillance, les bases de données, les applications personnelles, les outils d'IA et la gestion de serveurs de jeux.

Toutes les applications listées ci-dessous ne doivent pas être considérées comme fonctionnant exclusivement sur le ZimaBlade. L'important est que le ZimaBlade fait désormais partie de l'infrastructure qui prend en charge cet environnement auto-hébergé plus vaste, les charges de travail étant réparties entre lui et le serveur Dell.

Infrastructure, réseau et surveillance

• Portainer pour la gestion de Docker.
• Tugtainer pour les mises à jour de Docker.
• AdGuard Home pour le blocage des publicités au niveau du réseau.
• Uptime Kuma pour surveiller la disponibilité des applications et des services.
• Scrutiny pour la surveillance de l'état des disques.
• Tailscale pour l'accès à distance.
• Cloudflared pour le tunneling et la connectivité à distance.
• UpSnap pour les fonctions Wake-on-LAN.

Médias et bibliothèques personnelles

• Jellyfin pour le streaming vidéo auto-hébergé.
• Navidrome pour le streaming musical.
• Audiobookshelf pour l'hébergement de livres audio.
• Kavita pour les ebooks.
• Lidarr pour la gestion de la bibliothèque musicale.
• AudioMuse-AI pour l'analyse musicale.
• Picard pour les métadonnées musicales et le nettoyage de la bibliothèque.
• qBittorrent, Prowlarr, RDT Client, Decypharr, SABnzbd et les outils associés dans le cadre du flux de travail multimédia.

Maison intelligente et automatisation

Home Assistant constitue une autre composante majeure du projet. L'utilisateur s'en sert pour les automatisations de contrôle climatique, les routines tenant compte de la localisation, l'éclairage au coucher et au lever du soleil, les alarmes, les minuteurs de sommeil et le contrôle de Sonos via Music Assistant.

HASS Agent et Libre Hardware Monitor lui permettent également de surveiller à distance l'état et l'utilisation des ressources d'un autre PC. Ce système peut être surveillé, réveillé, mis en veille et contrôlé lorsqu'il est loin de chez lui.

n8n fait également partie de la pile d'automatisation globale, ajoutant au homelab une couche supplémentaire pour connecter les services et créer des flux de travail reproductibles.

Cloud personnel et applications

• Nextcloud pour le stockage cloud personnel.
• Syncthing pour la synchronisation des fichiers.
• Mealie pour les recettes.
• Actual Budget pour les finances personnelles.
• Papra pour la gestion des documents.
• Gramps Web pour gérer les liens familiaux et personnels.
• Daymark, une application Android personnalisée de suivi des habitudes qui stocke et synchronise ses données via le serveur.

Bases de données et services annexes

Le homelab comprend également PostgreSQL, Redis, MariaDB et Adminer. Il ne s'agit pas des services phares, mais ils rappellent utilement qu'un environnement auto-hébergé plus vaste devient rapidement bien plus qu'un ensemble d'applications autonomes. De nombreux services dépendent en coulisses de bases de données, de volumes persistants, du réseau et d'autres infrastructures partagées.

La place d'OpenClaw dans la configuration

OpenClaw n'est pas considéré comme une simple tuile de tableau de bord sans lien avec le reste du homelab. Il fait partie d'un flux de travail d'administration assistée par l'IA avec Hermes et un profil « Sysadmin » personnalisé.

L'utilisateur applique cette configuration à des tâches comprenant le déploiement d'applications Docker, la maintenance des serveurs, le dépannage, la configuration, les mises à jour, les automatisations et la gestion via SSH.

Dans un homelab conventionnel, bon nombre de ces tâches obligent l'utilisateur à ouvrir un tableau de bord, consulter les journaux, se connecter via SSH, se souvenir des commandes, modifier une configuration, puis vérifier si le service a correctement redémarré.

Ce projet expérimente une couche supplémentaire au-dessus de ces outils :

L'objectif n'est pas de supprimer Docker, SSH ou les outils de gestion des serveurs. Ceux-ci restent les mécanismes sous-jacents. La couche IA sert à faciliter leur utilisation et la gestion des tâches d'administration répétitives.

De la lecture des journaux à l'administration des serveurs assistée par l'IA

Le flux de dépannage utilisé auparavant par l'utilisateur explique également pourquoi une couche d'administration par IA est pertinente dans ce projet.

Lorsqu'il a commencé à travailler avec Docker et les services Linux, la plupart des problèmes étaient des difficultés classiques de débutant : ports déjà utilisés, variables d'environnement incorrectes, montages de volumes pointant au mauvais endroit et confusion concernant le réseau ou la redirection de ports.

À ce stade, l'IA était principalement un outil de dépannage. Il collait les journaux des applications dans ChatGPT, demandait ce qui s'était mal passé, puis utilisait l'explication pour comprendre le concept Docker ou Linux sous-jacent.

OpenClaw et Hermes représentent la prochaine version de ce flux de travail. Au lieu d'être utilisée uniquement après une panne, l'IA s'intègre progressivement à l'environnement habituel d'administration des serveurs.

Cette distinction rend ce homelab particulièrement intéressant. Le projet ne consiste pas simplement à héberger une interface de chat IA. Il explore la manière dont un agent IA peut interagir avec la partie opérationnelle d'un environnement réellement auto-hébergé.

La commande à distance va au-delà du tableau de bord

L'utilisateur a également connecté certaines parties du homelab à Discord. Le serveur sert de lieu central pour les notifications et les interactions à distance, notamment les alertes du serveur, les demandes de livres audio, les outils liés à Minecraft et l'accès au workflow d'administration système Hermes.

Cela signifie que le projet évolue vers un modèle dans lequel l'administration ne commence pas toujours par l'ouverture du tableau de bord de ZimaOS ou le lancement d'une session SSH depuis un ordinateur portable.

Associé à Tailscale et à une connectivité à distance basée sur Cloudflare, l'objectif plus large est de garder les services accessibles et gérables sans dépendre de la redirection directe des ports pour chaque application.

ZimaOS fournit la couche de gestion

Avant d'adopter la configuration actuelle, l'utilisateur a expérimenté Proxmox. Il l'a trouvé puissant, mais apprendre en même temps la virtualisation, Linux, le réseau, Docker, les ports, les montages et les variables d'environnement créait trop de complexité pour un premier homelab.

ZimaOS a changé l'expérience en proposant l'installation d'applications en un clic, des journaux accessibles, des paramètres centralisés et une manière plus visuelle de gérer les services.

Cela n'a pas supprimé la nécessité de comprendre Docker. L'utilisateur recommande toujours aux débutants d'apprendre les bases des ports, des volumes, des montages, des variables d'environnement et du réseau domestique, car ces éléments étaient à l'origine de la plupart de ses premiers problèmes.

La différence est que ZimaOS lui a fourni un environnement plus simple pour mettre ces connaissances en pratique. À mesure que son expérience augmentait, des fonctionnalités telles que la configuration YAML lui ont également offert un contrôle plus direct, sans l'obliger à abandonner l'environnement de gestion visuelle.

Dans ce projet, les deux couches ont des fonctions différentes :

Comment les deux serveurs se répartissent le travail

L'un des aspects les plus pratiques du projet est que l'utilisateur n'essaie pas de remplacer du matériel qui fonctionne déjà avec le ZimaBlade.

Le serveur Dell dispose déjà d'applications configurées et en fonctionnement ; tout déplacer immédiatement créerait donc du travail inutile. À la place, le ZimaBlade est destiné aux services passifs et continus qui gagnent à rester disponibles 24 heures sur 24.

Les charges de travail actuelles ou prévues du ZimaBlade comprennent des services tels que :

• AdGuard Home
• Uptime Kuma
• FlareSolverr
• Cloudflared
• les tâches de sauvegarde
• d’autres services légers fonctionnant en permanence

Cela permet au système Dell de conserver davantage de ressources disponibles pour les charges de travail plus exigeantes, notamment l’IA locale.

Le plan prévoit également que les deux appareils se surveillent mutuellement. Uptime Kuma peut indiquer si les services et les appareils sont disponibles, tandis que les notifications Discord peuvent alerter l’utilisateur lorsqu’un élément cesse de répondre.

Il s’agit d’une architecture de serveur domestique pratique, car la redondance ne signifie pas nécessairement acheter deux machines identiques. Différents systèmes peuvent assumer différentes responsabilités tout en prenant en charge le même environnement auto-hébergé.

La prochaine étape : davantage d’IA locale

Le volet IA locale du projet est encore en développement.

La mise à niveau matérielle prévue est une NVIDIA Tesla P4 dotée de 8 Go de VRAM. Une fois cette carte disponible, l’utilisateur prévoit d’expérimenter Qwen 3.5 9B pour des tâches d’automatisation plus personnelles.

Ces cas d’utilisation prévus comprennent la gestion et la catégorisation des e-mails, les notifications, la gestion des documents et des fichiers, les flux de travail liés aux informations personnelles et d’autres tâches pour lesquelles il serait utile de conserver davantage de traitements dans le homelab.

Cela est distinct de l’administration assistée par l’IA déjà réalisée avec OpenClaw, Hermes et un modèle de pointe. La Tesla P4 et le déploiement de Qwen sont des projets futurs et ne font pas partie de la configuration matérielle actuelle.

Cette distinction est importante, car le projet explore en pratique deux utilisations différentes de l’IA :

• L’IA pour gérer le homelab grâce à l’administration, au dépannage, à la configuration et à l’automatisation.
• L’IA en tant que service hébergé par le homelab pour les flux de travail personnels privés et les futures tâches liées à la domotique.

Ce qui fonctionne bien

Le principal avantage pour l’utilisateur ne réside pas dans une application en particulier. Il tient à la possibilité de regrouper dans un même environnement contrôlé par l’utilisateur des services qui seraient normalement répartis entre des abonnements distincts ou des plateformes indépendantes.

Le streaming musical, la vidéo, le stockage cloud, la domotique, la surveillance, les applications personnelles, les serveurs de jeux et l’administration assistée par l’IA peuvent tous interagir au sein du même homelab.

Cette intégration modifie la valeur du matériel. Le ZimaBlade n’est pas simplement utilisé comme un ordinateur supplémentaire sur le réseau. Il fait partie de l’infrastructure qui prend en charge des services restant en ligne, communiquant entre eux et pouvant être automatisés ou gérés à distance.

Ce que l’utilisateur aimerait encore améliorer

La configuration n’est pas non plus présentée comme exempte de contraintes. L’utilisateur identifie plusieurs aspects qu’il aimerait voir améliorer dans ZimaOS.

Sa demande prioritaire concerne une meilleure intégration avec LinuxServer.io et les sources d’applications basées sur GitHub. Il a rencontré des cas où d’anciennes images d’applications étaient toujours installées et où le tableau de bord ne signalait pas la disponibilité d’une version plus récente, ce qui l’obligeait à réinstaller une application à partir d’une autre source d’image.

Il souhaiterait également :

• Un bouton de terminal web accessible directement depuis le tableau de bord principal.
• Un passage plus rapide entre la configuration des applications et les journaux lors du dépannage.
• Une documentation plus complète sur les GPU pris en charge, notamment les cartes telles que la Tesla P4.
• Des conseils destinés aux débutants et couvrant les concepts importants de l’auto-hébergement.
• Une gestion et une visibilité facilitées des attributions de ports des applications.
• Une meilleure utilisation de l’espace horizontal dans le tableau de bord ZimaOS.

Ces limites sont utiles pour comprendre le contexte, car il s’agit d’un déploiement réel et non d’un environnement de démonstration soigneusement préparé. À mesure que le homelab de l’utilisateur s’est complexifié, ses attentes sont passées de la simple installation d’applications à la gestion des mises à jour, de la compatibilité matérielle, du dépannage et de configurations Docker de plus en plus avancées.

Ce qui rend ce projet ZimaBlade intéressant

La particularité de cette configuration ne réside pas dans le nombre d’applications installées. Les longues listes d’applications auto-hébergées sont courantes dans les homelabs.

Ce qui ressort, c’est l’architecture construite autour d’eux.

Un ZimaBlade compact prend en charge une partie de l’infrastructure fonctionnant en continu. Un ancien PC Dell reste utile au lieu d’être mis au rebut. ZimaOS fournit une couche de gestion visuelle. Docker offre une flexibilité supérieure à celle de l’App Store. Home Assistant et n8n relient les automatisations. Des services de surveillance supervisent l’environnement. Discord fournit une autre interface de contrôle à distance. OpenClaw et Hermes ajoutent par-dessus une couche d’administration assistée par l’IA.

Il s’agit d’un homelab mêlant matériel et logiciels, fondé sur une idée simple : utiliser chaque composant pour la tâche qu’il accomplit le mieux, plutôt que d’attendre d’un seul appareil ou d’une seule interface qu’il fasse tout.

Pour cet utilisateur, ZimaBlade est devenu l’un de ces composants - un nœud compact et extensible qui peut rester en ligne, prendre en charge des services persistants, gérer le stockage et les extensions PCIe futurs, et participer à un système auto-hébergé bien plus vaste.

Rejoignez la communauté pour accéder à davantage d’informations utiles

Bienvenue dans la  communauté Discord d’IceWhale. Nous publierons davantage de tutoriels de configuration détaillés, d’études de cas d’utilisateurs et d’actualités produits afin de vous aider à naviguer facilement dans le monde numérique et à trouver la plateforme matérielle idéale pour chaque passion.