Projet : la refonte complète de mon Homelab (2026)

Salut à tous !

Ça faisait un moment que je n’avais pas parlé de mon Homelab ici. Le dernier article où je vous le présentais date de début 2024 : trois serveurs Proxmox, AWX, Terraform, PHPIPAM, Pi-hole… Depuis, beaucoup de choses ont changé. Du coup j’ai décidé de tout reprendre à zéro, proprement. Dans cet article je vous explique pourquoi, comment je m’y suis pris, et ce que ça donne aujourd’hui.

Contexte

Mon Homelab avait grandi un peu dans tous les sens. Une VM par-ci pour tester un truc, un conteneur par-là, des mots de passe notés un peu partout, des adresses IP fixées à la main… Ça marchait, mais :

• je ne savais plus vraiment ce qui tournait et pourquoi ;
• recréer une machine prenait du temps, et je refaisais toujours les mêmes étapes ;
• tout était sur le même réseau que la box, sans vraie séparation ;
• et le jour où mon firewall physique est tombé en panne, je me suis rendu compte que beaucoup de choses dépendaient de lui.

L’objectif que je me suis fixé est simple à dire : pouvoir demander « crée-moi une VM pour X » et que tout se fasse tout seul. Le nom, l’adresse IP, la création de la VM, les comptes, les logiciels, la supervision, la sécurité, le DNS, la page d’accueil… Et surtout : que tout soit du code dans git, rejouable sans moi.

Le matériel

Rien d’extravagant, je voulais quelque chose de silencieux et qui consomme peu :

• un PC Dell (i5-13400, 62 Go de RAM, un NVMe, un SSD de 1 To et un disque de 500 Go pour les sauvegardes) avec Proxmox VE 9 ;
• un petit switch manageable TP-Link (TL-SG108E) pour les VLAN ;
• un NAS Synology DS224+ (RAID 1) pour les photos de la famille ;
• la box de l’opérateur, qui ne fait plus que donner l’accès à Internet.

La méthode : avancer par phases

Plutôt que de tout casser d’un coup, j’ai découpé le projet en phases. À chaque phase, un objectif clair et un critère « c’est fini quand… ». Pas de big bang : les anciennes machines gardent leur adresse jusqu’à leur migration.

Phase	Sujet	Les solutions installées
0	Inventaire	scripts d’inventaire Proxmox
1	Fondations	Git (GitHub privé), sauvegardes Proxmox, conventions
2	Poste de contrôle	VM Debian 13, Claude Code, jeton API Proxmox
3	Usine à machines	OpenTofu, cloud-init, Ansible, Semaphore
4	Services socle	Technitium DNS, Homepage, NetBox, Vaultwarden
5	Supervision	Zabbix 7.4, Grafana, Speedtest Tracker, bot Telegram
6	Sécurité	Wazuh 4.14 (SIEM)
7	Labs	EVE-NG à la demande
8	Firewall et VLAN	OPNsense virtualisé, 7 VLAN, WireGuard
9	Assistant IA et stockage	Open WebUI, LiteLLM, SearXNG, OpenCloud, Syncthing
10	Outillage réseau	VM boîte à outils, tests automatiques, SmokePing

Je vous détaille tout ça phase par phase (chaque partie mériterait son propre article 🙂).

Phase 0 : l’inventaire

Avant de toucher à quoi que ce soit, j’ai fait la liste de tout ce qui tournait : VM, conteneurs, stockages, adresses IP, ce qui était exposé sur Internet. Un script interroge Proxmox (qm list, pct list, ressources de l’hôte) et produit un tableau. Pour chaque machine, une décision : on garde, on migre ou on supprime.

Rien que cette étape m’a fait libérer environ 450 Go de vieilles VM de test et de snapshots oubliés 😅.

Phase 1 : les fondations

• Git : un dépôt privé sur GitHub qui contient tout (code, scripts, documentation). Si ce n’est pas dans git, ça n’existe pas.
• Sauvegardes : une sauvegarde Proxmox de toutes les VM chaque nuit à 02:30. J’ai choisi « toutes » plutôt qu’une liste, sinon on oublie toujours la dernière VM créée.
• Conventions : des noms en <rôle>-<nn> (zabbix-01, dns-02…), des plages de numéros de VM par usage, et une règle toute simple : l’adresse IP = le numéro de la VM. La VM 121 a l’adresse .121. Plus besoin de chercher une IP libre.
• DHCP de la box réduit à une petite plage, pour laisser le reste du réseau au Homelab.

Phase 2 : le poste de contrôle

Une petite VM Debian 13 d’où tout est piloté. C’est là que tourne le dépôt git et Claude Code (j’en parle plus bas), que je peux utiliser depuis mon téléphone.

Elle ne se connecte pas à Proxmox en root : elle a un utilisateur API dédié avec un jeton, et des clés SSH vers les VM.

Phase 3 : l’usine à machines

C’est le cœur du projet. Avant, créer une VM c’était : cloner un template, changer l’IP, créer l’utilisateur, copier la clé SSH, installer l’agent Zabbix, l’ajouter dans Zabbix, l’ajouter dans le DNS… Une bonne demi-heure, et j’oubliais toujours une étape.

Maintenant, une nouvelle VM c’est une ligne dans un fichier :

"outils-01" = { vmid = 155, cores = 2, memory = 2048, disk = 20, tags = ["infra"] }

Les briques :

• Un template Debian 13 cloud-init, créé à partir de l’image officielle « genericcloud ».
• OpenTofu (le fork libre de Terraform, avec le provider bpg/proxmox) crée la VM dans Proxmox. Il l’enregistre aussi dans NetBox et dans le DNS.
• cloud-init s’occupe du premier démarrage : nom de la machine, comptes, clés SSH, agent QEMU.
• Ansible (rôle base) installe le socle : mises à jour, comptes, sudo, SSH durci (ni root ni mot de passe), mises à jour de sécurité automatiques, DNS, agents Zabbix et Wazuh. L’inventaire est dynamique : Ansible lit directement la liste des VM dans Proxmox.
• Semaphore : une interface web avec des boutons « Créer les VM », « Socle base », « Homepage », « Mises à jour »… OpenTofu montre d’abord ce qu’il va faire, et attend ma confirmation avant d’appliquer.

Semaphore : chaque action du Homelab est un bouton.

Résultat : une VM prête, supervisée et sécurisée en deux minutes, et je peux tout relancer depuis mon téléphone.

Phase 4 : les services de base

• Technitium DNS, sur deux serveurs (primaire et secondaire) : une vraie zone locale home.arpa, le blocage des pubs (listes StevenBlack et HaGeZi) et le DNS chiffré vers l’extérieur. Il remplace Pi-hole. Je l’ai choisi parce qu’OpenTofu peut y créer les noms tout seul.
• Homepage : la page d’accueil du Homelab, entièrement en code, avec des widgets en direct (Proxmox, DNS, Zabbix…). Il remplace Dashy, et les nouvelles VM y apparaissent toutes seules.
• NetBox : l’inventaire et l’IPAM (les VM, les IP, les VLAN). Il remplace PHPIPAM, et son contenu est lui aussi géré par OpenTofu.
• Vaultwarden (un Bitwarden auto-hébergé) : mon coffre de mots de passe et celui de l’automatisation. Plus aucun mot de passe dans les scripts ni dans git : les scripts vont chercher ce dont ils ont besoin au moment de s’exécuter.

Ma page d’accueil Homepage : tous les services, avec leur état en direct.

Phase 5 : la supervision

Mon ancien Zabbix avait le disque presque plein et n’envoyait… aucune alerte. Je l’ai reconstruit proprement :

• Zabbix 7.4 : chaque nouvelle VM s’inscrit toute seule (auto-enregistrement), avec le bon modèle et le bon groupe.
• Alertes sur Telegram via un bot, à partir de la gravité « Moyenne », en français. Un gros travail aussi pour réduire le bruit : une alerte qui sonne pour rien, on finit par l’ignorer.
• Des contrôles maison : DNS, sauvegardes (alerte si pas de sauvegarde depuis 26 h), sites web, débit Internet.
• Grafana pour les graphiques.
• Speedtest Tracker : un test de débit toutes les 2 heures, avec alerte si le débit chute trois fois de suite.

Zabbix : toutes les machines se sont inscrites toutes seules.

Les alertes et le résultat des tâches arrivent sur Telegram.

Le tableau de bord Grafana « Homelab — socle » : sauvegardes, DNS, services web et problèmes en cours.

Phase 6 : la sécurité avec Wazuh

Wazuh 4.14 (un SIEM) tourne sur sa propre VM, avec un agent sur toutes les machines, y compris le firewall. Il voit les tentatives de connexion, les modifications de fichiers sensibles, les vulnérabilités…

Les alertes importantes partent aussi sur Telegram. Pour le premier test, j’ai simulé une attaque par force brute en SSH : alerte reçue sur le téléphone en quelques secondes ✅. Depuis, il surveille aussi les connexions à mon coffre de mots de passe.

Pour l’instant Wazuh alerte seulement, il ne bloque rien : je veux d’abord comprendre ce qui remonte.

Phase 7 : les labs à la demande

EVE-NG reste mon outil principal pour les labs (FortiGate, Extreme, Cisco…), comme dans mes articles sur RADIUS et le NAC. Mais il prend 22 Go de RAM, donc maintenant :

• il s’allume avec un bouton dans Semaphore ;
• il s’éteint tout seul dans la nuit (sauf si un lab tourne) ;
• les topologies sont sauvegardées dans git chaque nuit.

Phase 8 : un firewall virtualisé et des VLAN

Mon firewall physique est tombé en panne pendant le projet. Plutôt que d’attendre, j’ai virtualisé OPNsense directement sur le Proxmox. Il route maintenant 7 VLAN :

VLAN	Rôle
10	Gestion (Proxmox)
20	Serveurs
30	Labs
40	DMZ
50	Utilisateurs
60	Objets connectés (caméra, etc.)
70	Invités

Chaque VLAN a son réseau en 10.x.<VLAN>.0/24, avec la passerelle en .1, et toutes les VM ont été migrées. La règle de base : tout est fermé, sauf ce qui est nécessaire. Une caméra dans le VLAN IoT a accès à Internet, mais elle ne voit ni mes PC, ni les serveurs, ni le NAS.

Toute la configuration du firewall (alias, règles, DHCP, VPN) est appliquée par un script qui passe par l’API d’OPNsense. Si je dois reconstruire le firewall, je relance le script.

Le schéma Layer 3 : le firewall et ses VLAN (adresses masquées).

⚠️ Petite leçon : en voulant ouvrir un service avec une redirection de port sur le firewall, je me suis coupé l’accès à tout le réseau 😅. Depuis, j’ai une fiche de dépannage, et je ne fais plus de redirection sur le firewall. Pour accéder aux services depuis l’extérieur, j’utilise un tunnel Cloudflare (pas de port ouvert, et une vérification par e-mail avec Cloudflare Access) et, pour l’administration, un VPN WireGuard sur OPNsense.

Phase 9 : un assistant IA et un « drive » pour la famille

• Open WebUI : un « ChatGPT » pour la maison, avec un compte par personne.
• LiteLLM devant les modèles (via OpenRouter) : un seul point d’accès, un budget plafonné à environ 10 € par mois, et un modèle de secours si l’un est saturé.
• SearXNG pour la recherche web, sans pistage.
• Des serveurs MCP : l’IA peut lire Zabbix (en lecture seule) et nos documents.
• OpenCloud : le « drive » de la famille, et Syncthing pour synchroniser mes notes Obsidian.

L’assistant IA de la maison (Open WebUI).

Phase 10 : vérifier que la segmentation tient vraiment

Faire des VLAN c’est bien, mais comment être sûr que les règles font vraiment ce qu’on croit ? J’ai créé une VM « boîte à outils » (iperf3, nmap, tcpdump, mtr, hping3…) qui a une patte dans chaque VLAN. Depuis chaque zone, elle teste ce qui doit être ouvert et ce qui doit être fermé : 58 tests, tous les lundis matin, et un message Telegram seulement s’il y a un écart.

Et dès le premier lancement… surprise : le VLAN de gestion avait accès à tout. La règle par défaut d’OPNsense « Default allow LAN to any » n’avait jamais été retirée, donc mes règles ne servaient à rien. Sans ces tests, je ne l’aurais jamais vu. Corrigé en deux minutes, mais ça m’a bien rappelé qu’il faut tester, pas supposer.

J’ai ajouté SmokePing pour suivre la qualité de la ligne dans le temps (latence et pertes vers le firewall, la box et Internet).

Les mises à jour

Toutes les VM installent les correctifs de sécurité chaque nuit. Et le 1er et le 15 de chaque mois, un playbook Ansible fait les mises à jour complètes, une machine à la fois, redémarre seulement si c’est nécessaire, et m’envoie le résumé sur Telegram.

Les noms grecs

Petit clin d’œil : tous les comptes techniques portent un nom de la mythologie grecque, choisi selon leur rôle. zeus c’est moi (l’administrateur), hermes le messager qui fait l’automatisation, argos le géant aux cent yeux pour la supervision en lecture seule, hades pour les sauvegardes, athena pour la sécurité… C’est plus sympa que svc_backup01, et on comprend tout de suite qui fait quoi.

Les sauvegardes

C’est la partie la moins drôle mais la plus importante :

• toutes les VM sont sauvegardées chaque nuit ;
• le NAS fait des instantanés des photos (impossibles à supprimer pendant 7 jours, utile contre un rançongiciel) ;
• une copie des photos part chaque semaine sur un SSD externe avec Hyper Backup ;
• et une copie hors de la maison est en préparation.

Rappel : le RAID n’est pas une sauvegarde 😉. Il protège d’une panne de disque, pas d’une suppression ou d’un incendie.

Et l’IA dans tout ça ?

Je vais être honnête : je ne l’ai pas fait seul. J’ai travaillé avec Claude Code, un assistant IA qui tourne sur une VM dédiée de mon Homelab, et que je pilote souvent… depuis mon téléphone. Je décide de l’architecture et des choix, je valide chaque action sensible (rien n’est supprimé ni modifié sur le firewall sans mon accord), et lui écrit le code OpenTofu/Ansible, applique, teste et documente.

Ce que j’ai trouvé vraiment intéressant :

• tout est dans git : je peux relire chaque changement, et tout rejouer sans l’IA via Semaphore ;
• la documentation se met à jour au fur et à mesure (dans mes notes Obsidian) ;
• et ça m’a forcé à être beaucoup plus rigoureux : snapshot avant chaque modification, plan relu avant chaque application, tests après chaque changement réseau.

Ce que je retiens

• Découper en phases, avec un critère de fin clair. Sinon on ne finit jamais.
• Tout en code. Une VM qui n’est pas dans git n’existe pas.
• Tester plutôt que supposer, surtout pour le firewall.
• Un coffre de mots de passe dès le début, ça évite beaucoup de ménage après.
• Garder une porte de secours : le jour où le firewall tombe, il faut encore pouvoir accéder à l’hyperviseur.

La suite

• un nouveau switch TP-Link T2600G pour faire du NAC (802.1X / RADIUS) à la maison, comme dans mon dernier lab, avec un VLAN attribué selon l’appareil ;
• une borne Wi-Fi avec un réseau par VLAN ;
• un port miroir pour voir qui consomme quoi sur le réseau ;
• et des articles plus détaillés sur chaque partie : l’usine à VM, OPNsense et les VLAN, Wazuh…

N’hésitez pas à me laisser un commentaire si une partie vous intéresse en particulier, ou si vous avez des questions sur votre propre Homelab !