Le point de départ
Après plusieurs mois à faire grossir ce homelab — un cluster k3s de 6 nœuds sur Raspberry Pi, un NAS qui sert de hub média et de cible de sauvegarde, une poignée de sites derrière un tunnel — une question me trottait dans la tête : qu’est-ce que j’ai raté ?
Pas au sens « est-ce que ça marche » (le monitoring répond à ça tous les jours), mais au sens « qu’est-ce qui pourrait, en silence, faire perdre mes données, exposer ma vie privée, ou griller du matériel ». Ce sont exactement les angles morts qu’on ne voit plus à force de vivre dans son infra.
Alors j’ai tenté une expérience : donner à un agent IA — Claude Fable 5 — l’accès à mes trois sources de vérité (mes notes, mes dépôts Git, et le cluster en direct) et lui demander un audit de sécurité complet. Ce billet raconte la méthode, ce qu’un tel audit trouve réellement, le moment où l’IA s’est trompée, et pourquoi ce moment-là est le plus instructif de tous.
Note volontaire : je ne publie aucun détail exploitable de mon infra (adresses, noms d’hôtes, ports ouverts, failles encore ouvertes). Publier la carte de ses propres trous serait une faille en soi. Tout ce qui suit est présenté comme des leçons transférables, pas comme un plan de mon réseau.
1. La méthode : trois sources, des agents en parallèle, et une règle d’or
La première bonne surprise, c’est la façon dont l’agent a découpé le travail. Plutôt que de tout lire séquentiellement, il a lancé plusieurs sous-agents en parallèle, chacun sur un domaine indépendant :
- un sur mes notes (mon vault de documentation : revues d’infra, runbooks, stratégie de sauvegarde) ;
- un sur mes dépôts Git (manifests du cluster, code des applis) — à la recherche de secrets commités, de permissions trop larges, de configs risquées ;
- un sur les applications elles-mêmes.
Et surtout, une règle qui change tout : vérifier avant d’affirmer. Là où c’était possible, l’agent ne se contentait pas de lire une config — il testait le comportement réel. Un service est-il vraiment joignable ? Répond-il vraiment sans authentification ? La sauvegarde existe-t-elle vraiment ? La différence entre « le fichier de conf suggère X » et « j’ai vérifié que X se produit » est toute la différence entre un audit qui sert et un audit qui rassure à tort.
2. Ce qu’un audit de homelab trouve vraiment
Les trouvailles les plus utiles ne sont pas des CVE exotiques. Ce sont des hypothèses de confiance qu’on avait posées sans les tester. Voici les catégories qui reviennent — et qui s’appliquent probablement à la plupart des homelabs.
Le pare-feu qui ne filtrait rien
La leçon la plus marquante : mon pare-feu me donnait une fausse assurance. J’avais des règles propres, une liste de ports autorisés courte et rassurante. Sauf que la majorité de mes services tournent en conteneurs — et le moteur de conteneurs insère ses propres règles réseau avant celles du pare-feu applicatif. Résultat : des ports que je croyais filtrés étaient en réalité joignables depuis tout le réseau local.
La règle à retenir : sur un hôte Docker, la vraie surface d’exposition, c’est la liste des ports: publiés — pas la sortie de votre pare-feu. Vérifiez-le vous-même en testant depuis une autre machine, pas en lisant votre configuration.
Le LAN n’est pas une zone de confiance
Corollaire du point précédent : plusieurs services répondaient sans aucune authentification sur le réseau local. On se dit « c’est le LAN, c’est chez moi ». Mais « chez moi », c’est aussi le téléphone d’un invité, un objet connecté bas de gamme, ou n’importe quel appareil compromis sur le même réseau. Un service qui manipule des données personnelles ne devrait jamais compter sur le LAN comme périmètre de sécurité.
RAID n’est pas une sauvegarde — et une sauvegarde qu’on peut effacer n’en est pas vraiment une
Deux niveaux ici. Le premier est classique : le RAID protège contre la panne d’un disque, pas contre une suppression, un ransomware ou une erreur humaine. Le second est plus subtil : ma sauvegarde hors-site existait bien, mais le compte qui l’écrivait pouvait aussi la supprimer. Un processus malveillant sur la machine source aurait pu détruire l’original et la copie en même temps.
La brique manquante, c’est l’immuabilité : une cible en mode append-only, ou un jeton sans droit de suppression, pour qu’une copie survive même à la compromission de la source. C’est la différence entre une sauvegarde et un vœu pieux.
Les secrets vivent longtemps dans l’historique Git
Un classique indémodable : un identifiant commité une fois, retiré plus tard, mais toujours présent dans l’historique — et donc dans chaque clone, y compris le miroir de sauvegarde. « Je l’ai supprimé » ne suffit pas ; un secret exposé doit être considéré comme compromis et tourné, pas juste effacé du dernier commit.
Les clés qui ouvrent tout, sans cadenas
Enfin, les clés d’accès stockées sans passphrase sur un poste dont le chiffrement disque n’était pas confirmé. Un gestionnaire de secrets bien fait pour les cas d’urgence ne remplace pas l’hygiène de tous les jours : la clé que vous utilisez chaque matin est souvent le maillon le plus exposé.
Aucune de ces trouvailles n’est spectaculaire prise isolément. C’est leur accumulation qui compte — et c’est précisément ce qu’un audit systématique, mené sans complaisance, met en lumière.
3. Le moment le plus important : quand l’IA s’est trompée
Voici la section que je tenais le plus à écrire, parce qu’elle est le contraire d’un argumentaire commercial.
Après l’audit, on est passés à la maintenance : vérifier quelles applications avaient besoin d’une mise à jour. L’agent a produit un joli tableau et a classé en priorité critique une mise à jour de sécurité d’un composant de stockage, en citant une faille et une version corrective précise.
Sauf que la version corrective n’existait pas.
En voulant appliquer le correctif, la première étape a été de vérifier que la nouvelle version était réelle. Le registre officiel ne la connaissait pas : la version la plus récente disponible était exactement celle que je faisais déjà tourner. Le projet avait en réalité arrêté ses publications communautaires — il n’y avait tout simplement rien de plus récent à installer. L’agent avait halluciné un numéro de version et une faille plausibles, mais faux.
La leçon n’est pas « l’IA est peu fiable ». La leçon, c’est que la règle d’or — vérifier avant d’agir — n’est pas un luxe, c’est le garde-fou qui a transformé une erreur en non-événement. Si l’agent avait appliqué son propre conseil sans vérifier, il aurait épinglé une image inexistante et cassé le déploiement. Parce qu’on vérifiait chaque cible avant de la toucher, l’erreur est morte à l’étape de contrôle, sans conséquence.
Un agent qui a le droit d’agir sur de la vraie infrastructure doit être tenu en laisse par des preuves, pas par sa propre confiance. C’est vrai pour une IA. C’est d’ailleurs vrai pour un humain fatigué à 23 h.
4. De l’audit à l’action : un upgrade k3s en rolling
Un audit qui ne débouche sur rien ne vaut pas grand-chose. On a donc enchaîné sur du concret, avec le même principe partout : une étape, une vérification, un point de retour arrière possible.
Le morceau le plus intéressant a été la montée de version mineure de Kubernetes sur les 6 nœuds, sans coupure de service. Quelques décisions qui ont bien vieilli :
- Remplacer le binaire, pas la configuration. Plutôt que de relancer le script d’installation (qui aurait pu réécrire des fichiers de configuration sensibles), on a échangé uniquement le binaire — vérifié par sa somme de contrôle — en conservant l’ancien binaire sur chaque nœud. Rollback en quelques secondes si un nœud refusait de repartir.
- Un instantané avant de commencer. Une sauvegarde de l’état du cluster prise juste avant, comme ancre de retour arrière.
- Un nœud à la fois, avec une barrière entre chaque. Les nœuds de contrôle d’abord, puis les nœuds de travail, jamais deux en même temps. Et entre chaque nœud de stockage, on attendait que le stockage distribué ait reconstruit sa redondance avant de toucher le suivant. C’est la seule étape où l’on peut réellement perdre des données si on va trop vite ; c’est donc là qu’il faut être le plus patient.
Détail savoureux : au premier nœud mis à jour, un composant réseau intégré s’est mis à échouer en boucle pendant deux minutes. Panique ? Non — c’était le comportement attendu d’une fenêtre où les nœuds n’ont pas tous la même version, et ça s’est résolu tout seul dès le deuxième nœud. Le fait de l’avoir anticipé dans le plan a fait la différence entre « incident » et « note de bas de page ».
Résultat : les 6 nœuds sur la nouvelle version, zéro perte de données, zéro coupure visible, tout vérifié à la fin (santé du cluster, stockage, et chaque service public répondant à travers le tunnel).
5. Travailler avec un agent IA sur de la vraie infra
Si je devais résumer ce qui a rendu l’exercice sûr plutôt que risqué :
- Un périmètre clair et découpé. Des domaines indépendants, traités en parallèle, chacun avec un objectif précis. « Audite tout » ne marche pas ; « cherche les secrets commités dans ces dépôts et redonne-moi fichier + ligne, valeurs masquées » marche.
- Exiger des preuves, pas des affirmations. Chaque conclusion importante doit être adossée à un test reproductible. « La config suggère » n’est pas « j’ai vérifié ».
- Des barrières entre les étapes. Sur une opération à risque, on ne continue pas tant que l’étape précédente n’est pas confirmée saine. Un critère de passage explicite avant chaque nœud, chaque service.
- Toujours un point de retour arrière. Un instantané, une copie de l’ancien binaire, une sauvegarde vérifiée. On n’entame pas une action irréversible sans filet.
- Garder l’humain aux décisions irréversibles. L’agent propose, exécute le réversible, et s’arrête aux choix qui engagent — publier, supprimer, casser. Le jugement final reste au clavier.
- Ne jamais publier la carte de ses failles. Y compris dans un billet de blog. Les leçons se partagent ; les coordonnées de vos trous, non.
Bilan
Ce qui m’a le plus marqué, ce n’est pas que l’IA ait trouvé des choses — un scanner en trouve aussi. C’est la combinaison : la capacité à ratisser trois sources hétérogènes en parallèle, à croiser mes notes avec l’état réel du cluster, à formuler des trouvailles comme des leçons actionnables — et, quand elle s’est trompée, le fait que la discipline de vérification l’ait rattrapée avant tout dégât.
Un agent IA compétent ne remplace pas le jugement. Il amplifie une bonne méthode — et amplifierait tout aussi bien une mauvaise. La valeur n’était pas dans l’outil seul, mais dans le cadre qu’on lui a donné : des preuves, des barrières, des points de retour, et un humain qui garde la main sur ce qui ne se défait pas.
Le meilleur audit de sécurité, ce n’est pas celui qui vous rassure. C’est celui qui vous montre, calmement et preuves à l’appui, ce que vous aviez cessé de voir.