Ce que le homelab ne m'a pas appris

Dans à peu près toutes les discussions sur « comment se former en cybersécurité », la même réponse revient : monte un homelab.

Je suis bien placé pour être d'accord. J'ai un Proxmox qui tourne depuis trois ans, avec OPNsense, un VPN mesh, une quinzaine de conteneurs. C'est ce qui m'a fait progresser le plus vite, et de loin.

Mais depuis mon stage, j'ai un avis un peu moins enthousiaste sur ce que cette pratique produit réellement. Pas parce qu'elle serait inutile. Parce qu'on la vend comme suffisante, et elle ne l'est pas.

Ce qu'un homelab apprend vraiment bien

L'autonomie sur les outils. Quand personne ne peut t'aider, tu lis la doc, tu lis les logs, et tu finis par comprendre. C'est irremplaçable, et ça se voit tout de suite chez quelqu'un qui a pratiqué.

Le fait de casser sans conséquence, aussi. J'ai perdu des VM, cassé mon DNS un dimanche soir, mis mon propre pare-feu entre moi et ma machine. On apprend beaucoup en réparant.

Ce qu'il n'apprend pas

Justifier ses choix. Sur mon homelab, mes règles de pare-feu étaient un empilement historique. Je les avais toutes ajoutées pour une bonne raison sur le moment, et j'aurais été incapable d'en expliquer une seule six mois plus tard. Personne ne me l'avait jamais demandé. En stage, on m'a demandé de remplir une matrice de flux avant de toucher au pare-feu, et j'ai découvert que je ne savais pas faire ça.

Travailler à plusieurs sur la même infra. Seul, on peut tout changer, tout de suite, sans prévenir. À trois, une règle modifiée en silence casse le travail des autres. La documentation collaborative n'est pas une contrainte administrative, c'est ce qui permet d'avancer en parallèle. Ça ne s'apprend pas seul, par définition.

Se relire. Un homelab n'a pas de revue de code. Personne ne regarde ton docker-compose.yml et ne demande « pourquoi tu montes le socket Docker ici ? ». Chez moi, cette question n'était jamais posée. En stage, elle l'a été, et j'avais introduit une escalade de privilèges complète sans m'en apercevoir.

Se méfier des valeurs par défaut. C'est le point qui m'a le plus marqué. Un homelab valorise le « ça marche ». On copie un compose, ça démarre, on passe à la suite. Personne ne perd du temps à auditer une image ou à relire les ports publiés par défaut. Les deux vraies failles qu'on a trouvées en fin de stage venaient exactement de là.

Mon avis, donc

Le homelab enseigne les outils. Le travail en équipe enseigne la méthode. Ce sont deux choses différentes, et je pense qu'on brouille les pistes quand on présente la première comme la préparation complète au métier.

Quand je lis « j'ai un homelab » sur un profil, je sais que la personne est autonome et curieuse. C'est déjà beaucoup. Mais ça ne me dit rien sur sa capacité à documenter une décision, à accepter une critique sur sa config, ou à ne pas faire confiance à ce qui marche du premier coup.

Ce que je vais changer chez moi : traiter mon homelab comme s'il ne m'appartenait pas. Une matrice de flux écrite. Les changements versionnés. Et l'habitude de me demander, devant chaque config qui fonctionne, ce qu'elle ouvrirait si quelqu'un prenait la main dessus.

Comment je me tiens au courant

Puisque j'y suis, autant dire d'où viennent mes infos. Je suis les avis du CERT-FR pour les vulnérabilités qui touchent ce que j'administre, les notes de version de Proxmox et d'OPNsense, et le blog de projets que j'utilise directement. Quand le mainteneur de CrowdSec ou de step-ca explique un choix de conception, c'est souvent plus instructif que la doc.

Pour la partie offensive, Hack The Box reste mon terrain d'entraînement, et je lis les write-ups des machines retirées même quand je les ai résolues. Il y a presque toujours un chemin auquel je n'avais pas pensé.

Rien d'exotique. Mais lire régulièrement des gens qui expliquent pourquoi ils ont fait un choix, ça m'a plus appris que n'importe quel tutoriel qui explique comment.