Je transforme mon garage en datacenter. Il y a environ deux ans, j’ai commencé à construire ce qu’on appelle un « Homelab ». À l’époque, je ne savais même pas que ça portait un nom.

Définition

Un « Homelab » est un laboratoire personnel, dans lequel on fait des expériences en lien avec l’informatique. On teste, on casse, on répare, on remplace. Parfois on s’arrête aussi, puis on reprend. C’est une activité qui s’est beaucoup démocratisée ces dernières années.

Un Homelab n’est pas un objet physique, il n’a pas de définition stricte. Un ordinateur familial peut déjà servir de Homelab. Le mien a commencé avec un PC portable de récup’, aujourd’hui, il contient plusieurs vieux serveurs professionnels.

C’est un terrain de jeu modulaire qui sert à reproduire des workflows, des environnements, tester des principes informatiques, développer ou héberger des applications… Chacun fait de son Homelab ce qu’il veut, ce dont il a besoin.

Avant le Homelab

Après quelques années de développement, j’ai ressenti une forme de lassitude. Les projets se suivaient et se ressemblaient. Quand on y réfléchit, c’est normal : on acquiert de l’expérience dans un domaine, et c’est dans ce domaine qu’on nous recrute. Mais j’avais l’impression de tourner en rond : pour découvrir autre chose, il me fallait une expérience que je n’avais pas et que je ne voyais pas comment acquérir.

À partir de 2021, j’ai eu l’occasion de travailler dans un contexte légèrement différent. Je travaillais toujours de près ou de loin sur de l’e-commerce, mais au lieu de développer en local avec un docker compose et de déployer en prod via git pull, nous utilisions Kubernetes.

Je ne connaissais rien au métier de DevOps, ça a piqué ma curiosité et j’ai voulu m’y former.

Un concours de circonstances a fait que j’ai hérité du rôle de DevOps dans l’équipe pendant 6 mois. C’était extrêmement formateur, mais malheureusement insuffisant pour espérer décrocher un poste équivalent. Et je ne m’en sentais pas encore capable.

Origine de mon Homelab

Ma passion pour le « homelabbing » a commencé dans le courant de l’année 2024. J’avais un poste en full remote depuis peu et donc, inévitablement, moins d’occasions d’apprendre de mes collègues.

J’avais vraiment envie de progresser sur la gestion de nos serveurs (nous utilisions des VPS sous Debian). Je ressentais un inconfort lorsque notre responsable était absent et qu’un problème pointait le bout de son nez. J’ai donc décidé de passer mon ordinateur personnel sous Linux et, peu de temps après, de transformer un vieux PC portable en un mini-serveur.

J’y ai installé une petite distribution Linux (Alpine), configuré le serveur SSH et voilà, j’avais déjà un terrain d’entraînement sympa. C’est un peu l’équivalent du projet « hello world! » quand on apprend un nouveau langage de programmation !

C’est tout ce qu’il m’aura fallu pour « tomber dedans ». En installant l’OS, il fallait que je configure le poste (dotfiles), que j’importe mes clés SSH et, en effleurant à peine la surface, j’ai découvert stow et mon bien-aimé ssh-import-id, deux outils bien pratiques quand on installe un nouveau poste.

Avec le temps, j’ai accumulé du matériel et découvert tout un tas de sujets passionnants allant des VLANs aux vClusters. Le caractère éphémère et sans enjeu d’un homelab offre un excellent contexte d’apprentissage parce qu’il nous plonge dans un grand nombre de domaines. En entreprise, il est assez rare d’endosser autant de responsabilités au sein d’une même équipe, encore moins à une seule personne. Réseau, sécurité, serveur, base de données, applications, outils, sauvegardes…

Ambition de la qualité professionnelle

En travaillant sur mon Homelab, j’avais clairement l’ambition de combler mes lacunes en DevOps, d’en apprendre plus sur Ansible, Terraform, Kube… Et puis, avec le temps, des questions ont commencé à me trotter dans la tête…

Qu’est-ce qui tourne derrière AWS, GCP, Scaleway ?

Quelle interface les employés utilisent-ils au quotidien ?

Comment gèrent-ils les machines ?

C’est cette curiosité qui m’anime, qui me motive à continuer de travailler sur ce Homelab grandissant.

Parfois, en poursuivant un objectif clair et précis, on tombe dans un puits sans fond.

Déployer un cluster Kubernetes multi-nœuds

Pour ça il faudrait plusieurs machines, mais ces machines on veut qu’elles soient identiques, donc il faudrait faire des playbooks Ansible pour les configurer et puis pour simplifier le processus il faudrait industrialiser l’installation de l’OS et…
Mince, ça fait déjà un mois que j’ai commencé et j’ai toujours pas déployé ce fichu cluster.

Mais au bout d’un moment, on prend du recul, on voit le travail accompli, on fait le point sur tout ce qu’on a appris et, franchement, ça en vaut la peine.

L’expérience, les compétences et l’assurance acquises en travaillant sur mes projets m’ont permis de déployer en production une application sur un cluster K8s début 2026, une première pour l’entreprise. À ce jour, aucun incident ne s’est produit sur cette application.

Principes

Voici les principes qui me guident lorsque j’expérimente dans mon Homelab :

Faillible

Tout casser dans son Homelab est de bon augure. Mieux vaut perdre toutes ses données sur une mauvaise manip’ dans son Homelab que sur un serveur de production. L’expérience acquise en commettant des erreurs aide à anticiper, reconnaître et éviter les situations délicates.

Inachevé

Il sera toujours possible de faire mieux, plus tard. Je n’utilise pas Wazuh à son plein potentiel, mais je l’ai installé de bout en bout seul et c’est suffisant pour moi aujourd’hui. Si je décide un jour d’approfondir, je reprendrai là où je m’étais arrêté. Chaque heure passée à expérimenter en vaut la peine. Ce qui compte le plus, c’est le voyage, pas la destination.

Souverain

Je suis le CTO. Si je ne veux pas de VM, il n’y a pas de VM. Je fixe mes propres règles : technos, infra, distribution Linux… C’est un bon moyen de s’entraîner à prendre des décisions en tenant compte de la vue d’ensemble. C’est aussi à moi de fixer mon niveau de risque : rien ne m’oblige à passer des heures à durcir chaque règle.

Vivant

Ce que je croyais vrai hier ne le sera peut-être plus demain. Par exemple, j’ai essayé Gitea, puis utilisé une instance GitLab pendant un an, avant de passer finalement sur Forgejo (un fork de Gitea). Le Homelab ne développe pas seulement les compétences techniques : il entraîne aussi l’esprit critique. La remise en question est une étape indispensable de l’amélioration.

Pourquoi cette série

Dès le début de ce projet, j’ai eu envie de partager mon aventure et mes expériences.

J’aimerais transmettre ce que j’ai découvert, et peut-être éveiller votre curiosité pour ces sujets.

Je souhaite écrire cette série d’articles pour raconter l’histoire de mon homelab et comment j’en suis arrivé à transformer mon garage en un mini-datacenter (vous verrez, on n’en est pas si loin).

J’aimerais vous expliquer pourquoi je suis passé par Portainer et Coolify avant d’utiliser mon propre PaaS, pourquoi j’ai installé puis désinstallé bon nombre d’applications et, qui sait, je finirai peut-être par vous expliquer pourquoi je n’aime pas les VM (si je comprends moi-même pourquoi).

Développeurs, DevOps, étudiants ou plus largement passionnés d’informatique, c’est à vous que je m’adresse. Je ne prétends pas en savoir plus que vous, mais peut-être que j’arriverai à vous souffler l’outil qui répondra un jour à l’un de vos besoins.

Je serais ravi d’échanger avec vous : vos retours d’expérience et vos propres convictions m’intéressent. Le plus simple, c’est de m’écrire sur LinkedIn.

Dans le prochain épisode, je vous présenterai de quoi est composé mon Homelab aujourd’hui, les étapes par lesquelles je suis passé, ainsi que les premiers outils que j’utilise.