L'enfer du homelab : pourquoi votre infrastructure maison finit par vous lâcher

Avoue-le : si tu as joué au SysOps dans ton garage, tu connais ce moment. Celui où tu réalises que tes containers tournent sur trois machines différentes, que ton VPN ne marche que par chance, et que ton DNS est si fragile que débrancher la télé pourrait faire tomber tes services de prod. Bienvenue au club.

L'attrait du self-hosting, tout le monde connaît. Tes données t'appartiennent, tu gères ton infrastructure, tu apprends en faisant. Mais il y a un secret que la communauté homelab évite de mentionner : la complexité s'additionne. Ce qui commence comme un projet weekend rigolo se transforme vite en cauchemar architectural qui s'effondre dès que tu pars en vacances.

Le Piège du Homelab : quand "ça marche" ne suffit plus

Je comprends. L'esthétique mini-PC homelab, c'est séduisant. Tu achètes deux machines N100 à 150€ chacune, tu installes Proxmox, et hop, tu as un bac à sable virtualisé. Tu lances des VMs pour ta base de données, des containers pour tes apps web, peut-être un NAS pour le stockage. Tout fonctionne—au début.

Mais personne ne te prévient : l'infrastructure maison a des modes de défaillance que le cloud ne connaît pas. Ton FAI peut changer ton IP sans prévenir. Le NAT de ton routeur peut décider de ne plus aimer WireGuard. Ce Raspberry Pi qui fait serveur DNS ? Nickel, jusqu'à ce que tu aies besoin d'accéder à tes services depuis l'extérieur et que tu découvres qu'il est débranché depuis trois jours parce que quelqu'un avait besoin de la multiprise pour l'aspirateur.

Le vrai problème, c'est l'interconnexion. Quand tes services sont dispersés sur plusieurs machines, ton réseau maison devient un graphe de dépendances. Le Service A dépend du Service B, qui dépend de DNS, qui dépend de ce Raspberry Pi que tu avais oublié. Débranche n'importe quel élément, et ton écosystème numérique commence à s'effondrer comme des dominos.

J'ai appris ça à mes dépens. Mon ancien setup comptait deux hyperviseurs bare-metal, quelques instances VPS, des Raspberry Pis un peu partout, un NAS Synology pour le stockage, et un Hetzner Storage Box pour les backups. Ça fonctionnait. Plus ou moins. Jusqu'à ce que je parte en vacances et qu'une panne DNS se propage à la majeure partie de ma présence web. Rien de tel qu'un voyage relaxant accompagné d'alertes comme quoi tes services sont inaccessibles depuis six heures, à trois fuseaux horaires de là.

Pourquoi "Mes Données, Leur Calcul" a du sens

Voici la vérité inconfortable sur les labs maison : le compute est souvent le maillon faible. Tes mini-PCs ont une RAM limitée. Ta stratégie de backup, c'est probablement "j'ai des snapshots sur le NAS". Ta garantie de disponibilité, c'est environ "aussi longtemps que le courant tient et que rien ne surchauffe".

Le cloud compute résout ces problèmes proprement. Des providers comme Hetzner, DigitalOcean, ou les gros (AWS, GCP, Azure) offrent une infrastructure fiable et scalable avec de vrais SLAs. Tu obtiens des performances constantes, du réseau redondant, et du matériel qui ne vit pas derrière ta télé.

Le cadre philosophique sur lequel je me suis arrêté est simple : garde tes données là où tu les contrôles, mais laisse quelqu'un d'autre gérer le compute. Tes backups peuvent rester sur un NAS dans ton placard. Tes exports de base de données peuvent partir vers de l'object storage que tu gères. Mais tes services ? Ceux-là peuvent tourner sur un serveur dédié dans un data center, avec climatisation, alimentation redondante, et connectivité gigabit.

Ce n'est pas un concept nouveau. Ce framing "My Data, Your Compute" reconnaît que compute et stockage ont des caractéristiques de fiabilité différentes. Le compute est éphémère—tu peux lancer une nouvelle VM en quelques minutes. Les données sont précieuses et irremplaçables. Traite-les différemment dans ton architecture.

La Question de l'OS : pourquoi j'ai choisi la configuration déclarative

Une fois que tu décides de déplacer le compute hors site, tu fais face à une autre question : quel OS sur ton serveur ? Les options traditionnelles sont des variations sur un thème. Ubuntu Server, Debian, Rocky Linux, AlmaLinux—le même paradigme avec des gestionnaires de paquets différents.

Mais il y a une meilleure voie, et elle s'appelle NixOS.

NixOS, c'est une distribution Linux où toute ta configuration système est déclarée dans un fichier unique (ou un ensemble de fichiers). Au lieu de configurer SSH en bidouillant /etc/ssh/sshd_config, tu écris une déclaration dans ta config Nix. Au lieu d'installer des paquets avec apt, tu les déclares dans ta configuration et tu reconstruis. Le résultat : un système entièrement reproductible, déclaratif, et auditable.

Pour un serveur auto-hébergé, c'est transformateur. Si ton serveur meurt demain, tu peux provisionner un nouveau from scratch en appliquant ta config Nix. Chaque paramètre, chaque paquet, chaque configuration de service est versionné et documenté en code. Plus de "attends, comment j'avais configuré ça déjà ?" au moment où le désastre frappe.

La courbe d'apprentissage est réelle—NixOS a la réputation d'être excentrique—mais les bénéfices s'accumulent avec le temps. Ton infrastructure devient du code au sens le plus pur. Une mauvaise mise à jour ? Tu sélectionnes la génération précédente au boot. Tu veux ajouter un nouveau service ? Tu l'ajoutes à ta configuration et tu reconstruis. Tout ton setup serveur est documenté, versionné, reproductible.

La Réalité Sécurité des IPs publiques

Voici où ça devient intéressant—et potentiellement flippant. Quand tu fais tourner un serveur dans un data center, ton IP est publique par défaut. C'est à la fois un avantage et une responsabilité significative.

Du côté positif, tu peux exposer les ports que tu veux sans bidouillages NAT ou forwards de ports. Un serveur WebRTC ? Tu ouvres l'UDP 3478 et c'est bon. Besoin de règles firewall custom ? Elles sont à toi.

Mais cette ouverture est une arme à double tranchant. Une configuration Docker mal faite peut exposer tes services à tout internet. Expose accidentellement le port 2375 (le daemon Docker) sans auth, et tu viens de donner aux attaquants un shell sur ton serveur. Oublie de configurer ton firewall correctement, et tes services sont visibles par quiconque scanne ta plage IP.

C'est pourquoi la configuration déclarative compte autant. Avec NixOS, tu déclares tes règles firewall explicitement. Tu specifies exactement quels ports sont exposés et à qui. Pas d'ambiguïté du type "je crois que j'avais configuré ça correctement il y a trois mois". Ta posture sécurité est documentée et auditable.

La Migration Pratique : du Homelab à l'Infrastructure Hybride

Alors concrètement, ça ressemble à quoi ? Voici le cadre sur lequel je me suis arrêté :

Les données restent locales (ou semi-locales) : Tes backups vivent sur un NAS que tu possèdes, ou peut-être un storage box que tu gères. Tes fichiers personnels sont sur ton réseau maison ou un VPS sous ton contrôle. Le principe clé : les données qui comptent vivent quelque part d'où tu peux les récupérer.

Le compute part à distance : Tes services tournent sur un VPS ou serveur dédié dans un data center. Utilise NixOS pour la configuration déclarative. Laisse le provider gérer les pannes hardware, la redondance électrique, et la disponibilité réseau.

Embrasse la redondance : Ne compte pas sur un point de défaillance unique. Fais tourner ta base de données chez un provider, tes serveurs applicatifs chez un autre. Utilise de l'object storage pour les backups. Le cloud est assez bon marché maintenant pour qu'un peu de redondance ne ruine personne.

Automatise tout : Utilise Ansible, Terraform, ou les configurations NixOS pour gérer ton infrastructure. Si tu ne peux pas reconstruire ton setup from scratch en un après-midi, tu n'as pas une infrastructure fiable—tu as une infrastructure fragile maintenue par de la connaissance institutionnelle.

La Leçon

Le self-hosting n'a pas à signifier tout faire tourner depuis ton sous-sol. Le meilleur homelab, c'est celui qui est assez fiable pour que tu n'y penses pas, assez résilient pour survivre à tes vacances, et assez simple pour que tu puisses l'expliquer à quelqu'un en moins de cinq minutes.

La philosophie "My Data, Your Compute" n'est pas une capitulation face au cloud—c'est une reconnaissance que compute et données ont des caractéristiques différentes et méritent un traitement différent. Garde tes données près de toi, et ton compute là où la fiabilité rencontre la commodité.

Ton homelab devrait améliorer tes compétences et servir tes besoins, pas devenir un second job à maintenir une infrastructure fragile. Parfois, le move de self-hosting le plus malin, c'est de savoir quand laisser quelqu'un d'autre gérer le hardware.