I. Sélection de l’équipement et exigences principales
Je suis développeur backend. Le serveur distant que je louais auparavant était obsolète et manquait de performance suffisante, ne répondant plus à mes besoins d’auto-hébergement. J’ai donc acheté un Zimaboard 2 1664 avec des objectifs clairs : d’abord, construire un serveur domestique auto-hébergé entièrement configuré et avec sauvegarde pour le déploiement d’applications, la gestion des données et la connectivité à distance ; ensuite, sans affecter l’usage principal du serveur, exploiter la performance inoccupée du matériel pour le transformer en console de jeux rétro plug-and-play, réalisant ainsi une double fonctionnalité et équilibrant besoins techniques pratiques et divertissement quotidien.
II. Processus d’installation du serveur auto-hébergé
Choix du système et installation
Après avoir acquis le matériel, j’ai d’abord essayé le ZimaOS fourni avec le Zimaboard 2. Il était facile à utiliser et pratique pour l’accès à distance, mais la nature immuable du système NAS limitait fortement mes déploiements d’applications ultérieurs. En fonction de mes habitudes, j’ai finalement choisi de passer à Fedora Server — le même système que mon ancien serveur, offrant une meilleure compatibilité. Lors de l’installation, je n’ai remplacé que l’outil de création de disque USB bootable du tutoriel. Grâce à l’interface Web locale intégrée de Fedora Server et au terminal, j’ai facilement réalisé les étapes initiales avant la configuration SSH et le renforcement de la sécurité. L’installation s’est déroulée très facilement.
Configuration du stockage et des sauvegardes
Pour assurer une sauvegarde correcte des données du serveur, j’ai utilisé deux disques durs de rechange que j’ai formatés en systèmes de fichiers BTRFS. Ce système est intégré au noyau Linux, supporte nativement les snapshots et est très stable, correspondant parfaitement à mes besoins de sauvegarde pour le serveur auto-hébergé. Il offre aussi une base de stockage fiable pour le fonctionnement stable du serveur.
Déploiement des services principaux
J’ai construit un service auto-hébergé complet sur le serveur en utilisant Docker pour répondre aux besoins quotidiens : Jellyfin comme serveur multimédia pour la gestion unifiée des ressources audio et vidéo personnelles ; Filebrowser pour créer un cloud privé accessible à distance à tout moment ; et Karakeep pour gérer mes favoris et notes, facilitant travail et études. J’ai aussi réservé de l’espace pour déployer des serveurs Minecraft et RustDesk afin d’accueillir des divertissements en ligne futurs avec des amis et d’aider ma famille avec leurs problèmes informatiques et mobiles.
Configuration réseau et surveillance
Pour le reverse proxy, je suis passé de mon habituel Traefik à Godoxy, associé à Tailscale pour assurer l’interconnexion entre le serveur local et le serveur distant d’origine, évitant ainsi l’exposition du réseau domestique. De plus, Godoxy intègre un tableau de bord de surveillance, me permettant de visualiser en temps réel l’état du CPU, de la mémoire, de la température, du disque et d’autres paramètres du serveur, améliorant considérablement l’efficacité de gestion.

III. Rénovation en console de jeux rétro : démarrage/arrêt à la demande, sans interférence serveur
Trois principes clés de la rénovation
Pour garantir que les fonctions de jeu et de serveur ne se gênent pas, je me suis fixé trois principes clés : ① Ne pas installer d’environnement de bureau complet pour éviter de consommer des ressources système et assurer un fonctionnement léger du serveur ; ② Démarrer et arrêter les fonctions de jeu à la demande, en terminant automatiquement tous les processus liés lorsqu’elles ne sont pas utilisées pour ne pas gaspiller la performance matérielle ; ③ Assurer une utilisation simple pour que même des colocataires sans connaissances techniques puissent s’en servir de manière autonome sans mon aide.
Idées principales et combinaisons d’outils
L’idée centrale de toute la transformation est simple. J’ai exploité des outils Linux natifs et des logiciels de jeux open source pour réaliser un démarrage et un arrêt automatiques du service de jeu déclenchés par le branchement/débranchement HDMI : brancher le câble HDMI de la TV lance automatiquement l’interface graphique du jeu ; débrancher le câble HDMI termine immédiatement tous les processus de jeu, revenant à un état purement serveur — entièrement automatisé, sans intervention manuelle. Les outils choisis ont des rôles bien définis et sont tous des produits matures, open source et faciles à configurer :
- règles udev + scripts Shell personnalisés : responsables de la détection du branchement/débranchement HDMI et du déclenchement des commandes de démarrage/arrêt des services correspondants ;
- service systemd : gère le démarrage ordonné et la terminaison propre des sessions de jeu, évitant que des processus résiduels n’affectent le serveur ;
- Gamescope : un compositeur Wayland léger qui optimise la mise à l’échelle de l’écran de jeu, permettant aux jeux anciens de s’adapter parfaitement à la résolution 1080P de la TV ;
- ES-DE + Retroarch : ES-DE sert de frontend pour la bibliothèque de jeux, permettant la gestion par catégorie de console et la capture automatique des jaquettes et descriptions ; Retroarch gère divers émulateurs de consoles rétro et configure automatiquement les manettes, rendant l’utilisation très conviviale.
Étapes pratiques de configuration
1. Configuration des permissions : j’ai ajouté l’utilisateur classique exécutant le service de jeu aux groupes input, video, audio et seat, et activé le service seated pour garantir la création normale des sessions Wayland, préparant ainsi les permissions nécessaires au jeu.
2. Configuration de détection et déclenchement : j’ai créé un fichier de règles udev définissant les conditions de détection du branchement/débranchement HDMI, déclenchant mon script shell personnalisé. Le script contient la logique pour déterminer l’état de connexion HDMI, permettant au système de démarrer et arrêter automatiquement le service systemd de jeu au niveau utilisateur selon l’état HDMI.
3. Configuration du service de jeu : j’ai créé un fichier de service systemd utilisateur définissant la commande principale pour que Gamescope lance ES-DE, et mis en place une double logique « arrêt propre + arrêt forcé » pour éviter que des processus de jeu anormaux n’affectent le serveur.
4. Installation des dépendances : j’ai installé d’un coup tous les pilotes matériels et logiciels nécessaires, incluant les graphismes intégrés Intel, les pilotes de manettes et les logiciels de jeu principaux comme Gamescope, Retroarch et ES-DE, assurant une parfaite compatibilité matérielle et logicielle.
5. Activation de la configuration : j’ai rechargé les règles udev et… Avec le service systemd installé, la modification de la console de jeux rétro est maintenant terminée, et la fonction de jeu est entièrement automatisée pour le démarrage et l’arrêt.
IV. Optimisation et débogage : équilibre entre expérience de jeu et stabilité serveur
Optimisation dédiée à l’expérience de jeu
Pour garantir une expérience de jeu rétro plus fluide, j’ai spécifiquement optimisé la configuration pour les jeux Wii/NGC : j’ai abandonné l’exécution de l’émulateur Dolphin via Retroarch, préférant une opération indépendante pour réduire la surcharge de la couche Libretro ; j’ai ajusté le fichier de configuration de Dolphin pour optimiser le ratio d’aspect et la logique de rendu du jeu ; et j’ai mis à jour les paramètres de démarrage de Gamescope, activant la mise à l’échelle FSR pour offrir une qualité d’image optimale sur TV 1080p. Les tests ont montré que la configuration optimisée maintenait l’utilisation GPU entre 70 % et 80 %, et dans un environnement intérieur à 20℃, la température maximale de l’appareil était seulement de 55℃. Avec le ventilateur officiel, la performance de refroidissement était pleinement suffisante, assurant un jeu fluide sans affecter le serveur par surchauffe.

Techniques pratiques de débogage
Durant la modification, j’ai aussi compilé un ensemble de techniques de débogage simples et efficaces. Ces techniques permettent non seulement de résoudre les problèmes rencontrés pendant la modification, mais aussi de s’adapter à plus d’émulateurs non gérés par Retroarch : utiliser la commande journalctl pour voir en temps réel les logs des événements udev, déclencher manuellement les événements de changement d’état HDMI et tester l’efficacité des règles ; retirer temporairement les règles udev, se connecter à l’appareil via SSH, lancer manuellement le programme de jeu et personnaliser la configuration de la manette ; après débogage, restaurer les règles pour revenir au mode d’utilisation automatisé. L’opération est simple et efficace.
V. Résultat final : double fonctionnalité, exploitation complète du potentiel matériel
Après une série d’installations et de modifications, mon Zimaboard 2 remplit parfaitement les doubles fonctions de serveur et de console de jeux rétro : au quotidien, c’est un serveur auto-hébergé stable et à faible consommation, gérant silencieusement les tâches principales comme le déploiement d’applications, la sauvegarde des données et l’accès à distance. La performance du processeur Intel N150 est parfaitement adaptée à ma charge de travail quotidienne. Pendant les temps d’inactivité, il suffit de brancher le câble HDMI de la TV sur l’appareil pour lancer automatiquement l’interface de jeu, permettant de profiter des jeux rétro classiques comme PS1 et Wii, avec même un support multijoueur local. Débrancher le câble HDMI termine immédiatement tous les processus de jeu, revenant au mode serveur pur, sans aucune interférence entre les deux.


Cette installation et modification du Zimaboard 2 m’a permis d’exploiter pleinement le potentiel du matériel et de redécouvrir la flexibilité du système Linux ainsi que le charme de la technologie open source. Une petite carte de développement ne se limite jamais à répondre à un seul besoin ; tant qu’on la combine avec ses propres scénarios d’utilisation et qu’on ose essayer et expérimenter, on peut en libérer une valeur bien plus grande.
Rejoignez la communauté pour débloquer plus de contenus utiles !
Bienvenue dans la communauté IceWhale Discord ! Nous publierons davantage de tutoriels détaillés, d’études de cas utilisateurs et de mises à jour produits pour vous aider à naviguer facilement dans le monde numérique et trouver la plateforme matérielle parfaite pour chaque passion.
Centre de campagne Zima
À lire aussi

Que se passe-t-il lorsque deux agents IA se disputent un serveur ?
L'expérience de cybersécurité IA de Zero Noichi a utilisé deux appareils ZimaBoard 2 pour simuler des agents attaquants et défenseurs, démontrant comment les serveurs...

IA locale sur le ZimaCube 2 — Extension PCIe, Ollama et pérennisation de votre homelab
Le ZimaCube 2 est livré avec 4 emplacements NVMe, un slot d'extension PCIe et de la RAM DDR5 — prêt à l'emploi pour Ollama,...

Guide de surveillance du laboratoire domestique ZimaCube : de Uptime Kuma aux agents IA
Surveillez votre serveur domestique avec Uptime Kuma, Pulse, Proxmox Data Center Manager ou un agent IA pour suivre le temps de fonctionnement, les sauvegardes,...

