État du Lab — Printemps 2026

Ça faisait un moment que je voulais poser tout ça par écrit. Mon homelab est progressivement passé de “quelques services qui tournent quelque part” à quelque chose qui ressemble davantage à une petite plateforme de production : réseau segmenté, stratégie de sauvegarde, monitoring, GitOps, expérimentations IA, et suffisamment de serveurs DNS pour apaiser les esprits anciens du homelab.

Cet article est un instantané du lab au printemps 2026 : ce qui tourne, où, pourquoi c’est organisé comme ça, ce qui est volontairement isolé, et les sujets sur lesquels j’expérimente en ce moment.

Ce n’est pas une architecture de référence parfaite. C’est un lab personnel : pratique, évolutif, parfois un peu trop travaillé, et suffisamment utile pour qu’une panne soit maintenant considérée comme un incident familial.

Le rack

Le rack contient actuellement :

• UniFi Dream Machine Pro, avec un backup 4G LTE pour la connectivité.
• Switch UniFi 48 ports Pro PoE, qui alimente et connecte une bonne partie du réseau.
• Beelink S12 Pro, Intel N100, 16 Go de RAM, sous Proxmox.
• HP EliteDesk G800 SFF, Intel i7-6700, 32 Go de RAM, sous Ubuntu Server bare metal.
• Synology RS816, avec 3 × 4 To, utilisé comme NAS principal.
• Dell PowerEdge R730, double Xeon E5-2560 v4, 64 Go de RAM, actuellement éteint.
• Raspberry Pi Zero, qui héberge une instance secondaire Pi-hole + Unbound.

Le R730 est le genre de machine qui donne l’impression d’avoir un supercalculateur à la maison, jusqu’au moment où on regarde la consommation électrique. Il est donc éteint la plupart du temps, mais reste disponible pour des expérimentations plus lourdes.

Le Pi Zero, lui, existe pour une raison simple : le DNS ne doit pas être un point de défaillance unique. Et puis bon, le problème c’est toujours le DNS. Évidemment.

Architecture réseau

La stack réseau est principalement basée sur UniFi, avec une segmentation par VLAN. La structure actuelle :

• Trusted LAN : machines personnelles et infrastructure de confiance.
• IoT : objets connectés non fiables, qui n’ont pas à discuter librement avec le reste du réseau.
• Cameras : isolé, sans accès à Internet.
• Guests : réseau invité.
• Agent : isolé et non fiable, utilisé pour mes expérimentations autour des agents autonomes.

Le VLAN Agent mérite un article dédié. En résumé, je considère par défaut tout système capable de comportement autonome comme non fiable. Il a donc son propre segment réseau et uniquement des accès explicites et limités vers le reste du lab.

Pour l’accès externe, j’utilise Headscale avec un VPS qui sert de relais. Ça me permet d’avoir un accès fiable au tailnet malgré les contraintes liées au CGNAT. Je n’expose pas directement mes services sur Internet : l’accès passe par le tailnet.

Ça ne veut pas dire qu’il n’y a plus aucun sujet de sécurité. Ne rien exposer publiquement est une bonne base, pas un bouclier magique. Les frontières internes restent importantes : VLANs, accès limités, principe du moindre privilège, et pas d’agent expérimental qui se balade librement sur le LAN.

Stockage et sauvegardes

Le Synology RS816 est le NAS principal, avec trois disques de 4 To. Il stocke les données persistantes qui doivent survivre à la perte ou au remplacement d’une machine.

Le NAS dispose de sauvegardes quotidiennes hors site. C’est une partie du lab sur laquelle j’essaie de ne pas être trop malin. La redondance locale est utile, mais ce n’est pas une stratégie de sauvegarde à elle seule. Si la maison, le rack ou le système de fichiers passe une mauvaise journée, je veux toujours une copie ailleurs.

Proxmox Backup Server tourne également dans le lab et couvre les besoins de sauvegarde côté VMs et containers Proxmox.

Répartition du compute

Le lab est partagé entre Proxmox et un serveur Ubuntu en bare metal.

Le Beelink S12 Pro est le noeud Proxmox. Il héberge un mélange de services d’infrastructure, de VMs et de LXCs :

• PostgreSQL
• Proxmox Backup Server
• Pi-hole + Unbound
• VM Debian, utilisée comme hôte Docker
• VM Home Assistant OS
• VM Ubuntu Server pour la stack Hermes Agent
• LXC Agent proxy

Le HP EliteDesk tourne directement sous Ubuntu Server et héberge des workloads Docker qui gagnent à être séparés du noeud Proxmox, notamment certains services plus lourds côté média et IA.

J’aime bien cette séparation. Proxmox apporte de la flexibilité pour l’infra et les workloads de type VM, tandis que le serveur bare metal garde certains services Docker simples et prévisibles.

Workloads Docker

Le serveur Ubuntu bare metal héberge actuellement plusieurs services Docker :

• Frigate, pour la partie NVR/caméras.
• BookLore, pour la gestion de bibliothèque personnelle.
• Un tunnel Mullvad VPN exposé comme Tailscale exit node.
• Hindsight, utilisé pour des expérimentations de mémoire LLM.
• Manifest, utilisé pour le routage de requêtes LLM pour agents.
• paperless-ngx, pour la gestion documentaire.
• Komodo periphery agent, pour l’orchestration Docker à distance.

Certains de ces services sont stables et utilisés au quotidien. D’autres font partie de la couche d’expérimentation IA/agents et auront droit à un article dédié.

La VM Debian sur Proxmox sert aussi d’hôte Docker et héberge la stack applicative plus générale :

• Gitea
• Homepage
• InfluxDB, utilisé pour suivre mes sessions d’astrophotographie
• Komodo, comme control plane Docker
• NTP
• Orbital Sync, pour synchroniser les instances Pi-hole
• Synapse
• Traefik
• Promtail / Loki / Grafana
• Uptime Kuma
• Vaultwarden
• Pingvin
• Authentik

C’est la partie du lab qui ressemble le plus à une petite plateforme interne. Il y a de l’identité, du reverse proxy, de l’observabilité, du monitoring, de l’hébergement Git, du contrôle de déploiement, et un mélange d’applications personnelles.

Observabilité et opérations

La stack de monitoring repose sur Promtail, Loki et Grafana, avec Uptime Kuma pour les checks de disponibilité simples.

Je ne prétends pas faire du SRE niveau entreprise dans mon garage. C’est un homelab. Mais je veux quand même retrouver certaines qualités de base d’un système sérieux :

• savoir quand quelque chose tombe ;
• pouvoir inspecter les logs sans me connecter en SSH sur chaque machine ;
• comprendre les liens entre plusieurs erreurs ;
• redéployer proprement sans modifier des fichiers à la main sur les serveurs.

L’objectif n’est pas la complexité pour la complexité. L’objectif, c’est la répétabilité. Quand quelque chose casse, je veux que la correction devienne une partie du système, pas une commande lancée une fois et oubliée trois mois plus tard.

GitOps avec Komodo

J’utilise Komodo comme control plane Docker, avec un workflow proche du GitOps.

Les stacks Compose sont versionnées dans Git. Quand je pousse des modifications sur main, les stacks modifiées sont redéployées. Le workflow est simple :

1. modifier la définition Compose ;
2. commit et push ;
3. laisser la plateforme appliquer le changement ;
4. revenir en arrière depuis Git si nécessaire.

C’est probablement une des améliorations les plus utiles que j’ai apportées au lab. Les changements deviennent explicites et traçables. Ça rapproche aussi le lab de la façon dont j’aime voir fonctionner des systèmes en production : déclaratifs, reproductibles, et ennuyeux aux bons endroits.

Expérimentations IA et agents

La partie la plus expérimentale du lab en ce moment concerne l’IA.

J’ai récemment testé des workloads LLM locaux, notamment Qwen 3.6 27B avec 256K de contexte sur une RTX 4090 via llama.cpp. Ce n’est pas un service always-on dans le rack, mais ça fait partie de l’environnement global du lab.

Le but n’est pas seulement de “faire tourner un modèle local parce que c’est cool”, même si, soyons honnêtes, ça compte un peu. Ce qui m’intéresse surtout, c’est ce qui devient possible quand on combine des modèles locaux avec un accès contrôlé à une infrastructure personnelle : recherche documentaire, tagging, mémoire, état des services, données d’astrophotographie, et à terme workflows autonomes.

Deux projets en cours s’inscrivent dans cette logique.

OCR et tagging IA pour paperless-ngx

Je travaille sur une intégration OCR et tagging assisté par IA pour paperless-ngx. L’objectif est de rendre l’ingestion de documents plus utile sans transformer ça en nouveau système de classement manuel.

Un bon système documentaire doit aider à retrouver des réponses plus tard, pas seulement stocker des PDF dans une arborescence un peu plus jolie.

Hermes, agent autonome

Hermes est mon expérimentation d’agent autonome auto-apprenant.

Il vit dans le VLAN isolé Agent et n’a pas d’accès large au LAN. À la place, il peut interagir avec certains services internes via une API Fastify qui expose uniquement un ensemble limité de capacités : données d’astrophotographie, état de santé de certains services, et autres endpoints contrôlés.

L’environnement est volontairement contraint. Je ne veux pas d’un agent capable d’explorer librement le LAN ou de modifier l’infrastructure parce qu’il a eu une idée intéressante à 2 h du matin. L’architecture repose donc sur des frontières explicites : réseau isolé, surface API réduite, accès contrôlé aux données utiles.

Il y aura un article dédié sur Hermes, le VLAN Agent, Hindsight, Manifest et l’architecture agent dans son ensemble. Celui-ci est déjà suffisamment long, et il faut encore que les gens croient que je sors parfois prendre l’air.

Pourquoi construire tout ça ?

Un homelab est un bon endroit pour pratiquer les parties les moins spectaculaires, mais souvent les plus importantes, de l’ingénierie.

Faire tourner des services, c’est facile. Faire tourner des services segmentés, sauvegardés, observables, reproductibles, et pas complètement terrifiants à modifier, c’est là que ça devient intéressant.

Ce lab me permet de travailler sur :

• administration Linux ;
• réseau et design VLAN ;
• reverse proxy et identité ;
• sauvegarde et restauration ;
• Docker et Compose ;
• workflows GitOps ;
• observabilité ;
• intégration IA locale ;
• frontières de sécurité pour systèmes autonomes.

C’est aussi un terrain d’essai avant d’appliquer des patterns similaires dans un contexte professionnel. Les enjeux sont plus faibles que sur une vraie production, mais suffisamment réels pour que les mauvaises décisions se voient vite. Si Home Assistant, le DNS ou le réseau tombe, le système d’alerte familial est très efficace.

La suite

Les prochains articles devraient entrer davantage dans le détail de :

• le VLAN Agent et l’isolation des systèmes autonomes ;
• Hermes, mon expérimentation d’agent auto-apprenant ;
• Hindsight et la mémoire LLM ;
• Manifest et le routage de requêtes pour agents ;
• OCR et tagging IA dans paperless-ngx ;

Pour l’instant, voilà l’état du lab : globalement stable, volontairement segmenté, de plus en plus automatisé, et encore assez expérimental pour rester intéressant.

Et sauvegardé. Parce que j’aimerais que mon futur moi continue à m’adresser la parole.