Transparence. Cet article a été rédigé par Claude, l’IA d’Anthropic avec laquelle je travaille sur mon homelab, à partir de nos sessions de travail. Je l’ai relu, corrigé et validé. Je trouve qu’il serait hypocrite, et à contre-courant de ce que je défends ici, de présenter comme purement humain un texte qui ne l’est pas. Les passages à la première personne sont les miens ; la section « Le point de vue de l’IA » est celui de Claude.

Un homelab commence souvent comme un terrain de jeu. Puis, un jour, on se rend compte que la famille stocke ses photos dessus, que les mots de passe de tout le monde y sont, que la musique de la maison en dépend et que le blog que vous lisez tourne dessus. Le terrain de jeu est devenu une infrastructure, avec tout ce que ça implique : un pare-feu, deux NAS dont un hors site, un reverse proxy, un IDS, un VPN, une trentaine de services… et une mémoire humaine qui, elle, n’a pas grossi.

Le vrai risque d’un homelab qui grandit, ce n’est pas la panne. C’est l’oubli. Pourquoi cette règle de pare-feu existe-t-elle ? Qu’est-ce que j’avais testé la dernière fois ? Ce port ouvert, c’était pour quoi déjà ? À force, on n’ose plus toucher à rien, et un système qu’on n’ose plus toucher est un système qu’on n’entretient plus.

Depuis quelques semaines, j’ai changé ma façon de travailler. Voici comment, et ce que j’en retire.

Le dispositif : une IA branchée sur la documentation, pas sur les machines

J’utilise Claude Code, l’assistant d’Anthropic, dans mon terminal. Il est connecté par MCP (Model Context Protocol, un standard qui permet de brancher une IA sur des outils externes) à homelabl, l’outil où je tiens l’inventaire et la documentation de mon homelab.

Le point essentiel, c’est la répartition des rôles :

  • Claude lit et écrit la documentation. Il consulte les fiches avant de proposer quoi que ce soit, et les met à jour une fois qu’une chose est vérifiée.
  • Claude n’a aucun accès à mes machines. Il me propose des commandes, je les exécute sur le pare-feu ou les NAS, et je lui colle le résultat. Il n’agit jamais directement sur l’infrastructure.
  • Je décide. Priorités, arbitrages, « on le fait maintenant » ou « on verra plus tard » : c’est moi.

Ce choix n’est pas qu’une précaution. Il m’oblige à lire chaque commande avant de la lancer, et donc à comprendre ce que je fais. L’IA accélère le raisonnement ; elle ne me dépossède pas de mon infra.

Quatre documents qui changent tout

La documentation s’organise autour de quatre piliers, tous tenus à jour au fil de l’eau.

Les fiches équipements. Une par machine : rôle, services, ports, configuration, procédure de mise à jour, tableau de dépannage et un changelog daté. Quand quelque chose change, la fiche change le jour même, pas « quand j’aurai le temps ».

Le backlog. Une liste numérotée de tout ce qui reste à faire, avec une priorité (de P0, critique, à P3, confort) et un statut. Un point n’est jamais supprimé : il passe à Fait, Sans objet ou En attente, avec la date et la preuve. On y trouve aussi bien « programmer les tests SMART des disques » que « retirer un certificat expiré depuis 2024 ». Il approche aujourd’hui les soixante-dix entrées, et c’est étonnamment rassurant : ce qui est écrit n’a plus besoin d’être retenu.

Le journal d’incidents. Chaque incident a sa page : détection, cause racine, impact, correction, vérification. Et une rubrique que je trouve précieuse : « faux diagnostics à ne pas rejouer ». Les fausses pistes coûtent cher ; les noter évite de les reprendre dans six mois.

Les décisions d’architecture. Pour chaque choix structurant : la date, la décision, la raison et les alternatives écartées, avec pourquoi. Le « pourquoi pas » est souvent plus utile que le « pourquoi » : il empêche de rouvrir indéfiniment les mêmes débats avec soi-même.

À côté, un runbook rassemble les procédures récurrentes : diagnostiquer une réplication, contrôler l’exposition du reverse proxy depuis l’extérieur, etc.

Une journée type

Rien ne vaut un exemple. Voici, en résumé, une journée de travail récente.

Un bug silencieux trouvé en préparant autre chose

Je voulais ajouter une détection des tentatives de connexion sur Nextcloud. Avant de construire quoi que ce soit, Claude a proposé une vérification en lecture seule : quelle adresse IP Nextcloud voit-il pour ses visiteurs ?

Réponse : toujours la même, celle du reverse proxy. Nextcloud ne faisait pas confiance au proxy placé devant lui, et voyait donc tout le monde arriver de la même adresse. Conséquence : sa protection contre les attaques par force brute aurait ralenti tous les utilisateurs dès la première attaque.

La correction tenait en une ligne. La vérification, elle, a été faite proprement : une tentative de connexion volontairement ratée depuis mon téléphone, en 4G, à travers un VPN. Le journal de Nextcloud a bien enregistré l’IP publique du VPN. Corrigé, prouvé, documenté.

Savoir ne pas faire

Le projet initial, c’était d’installer un agent de détection supplémentaire. Mais les journaux ne montraient aucune tentative de connexion ratée, la double authentification était active, et la protection native de Nextcloud fonctionnait désormais. J’avais demandé explicitement de ne pas monter une usine à gaz.

Décision : on ne l’installe pas. Le point passe En attente dans le backlog, avec l’architecture retenue et le critère de réouverture (des échecs de connexion réguliers depuis des IP inconnues). Ne pas ajouter une brique à maintenir, c’est aussi de l’entretien.

Quand l’IA se trompe

Point suivant : vérifier que mes pages d’administration, réservées au réseau local, restent accessibles quand je suis à l’extérieur via Tailscale. Claude a posé un diagnostic très sûr de lui : la configuration refusait les adresses Tailscale, donc l’accès à distance devait être cassé.

Sauf que je venais d’ouvrir une de ces pages depuis mon téléphone, en 4G. Ça marchait.

S’en est suivie une vraie enquête : deux hypothèses successives de Claude, fausses toutes les deux, écartées par des captures réseau. La troisième, vérifiée, était la bonne : sur mon pare-feu, le client Tailscale ouvre lui-même la connexion vers le reverse proxy, en local. Les clients distants arrivent donc avec l’adresse du pare-feu, qui fait partie du réseau autorisé. Il n’y avait rien à corriger, mais il y avait beaucoup à comprendre et à documenter, y compris la bonne façon de diagnostiquer ce cas la prochaine fois.

Plus tard, Claude m’a proposé de faire un test « depuis mon portable ». Je n’ai pas de portable personnel ; ma machine Linux est un fixe. Je l’ai corrigé, il l’a noté dans sa mémoire, et il a proposé une meilleure idée : lancer le test depuis mon NAS de secours, installé chez mes parents, sur une autre connexion Internet. Résultat : les treize services protégés refusent la connexion depuis Internet, et seuls les quatre services publics répondent. L’incident ouvert deux jours plus tôt a pu être clos, preuve à l’appui.

Et à la fin, la documentation

Chaque étape s’est terminée de la même façon : mise à jour du backlog, des fiches concernées, du journal d’incidents, du runbook et des décisions. Y compris les erreurs : les deux fausses hypothèses sont désormais écrites noir sur blanc dans les « faux diagnostics à ne pas rejouer ».

Ce que j’en retire

De la confiance. Je sais ce qui tourne, pourquoi, et comment le vérifier. Quand je modifie quelque chose, j’ai une procédure de contrôle, pas un espoir.

De la stabilité par petits pas. Pas de grand chantier : chaque session clôt quelques points du backlog, chacun vérifié. Le homelab s’améliore un peu tous les jours, sans jamais être à moitié démonté.

Une mémoire qui ne dépend plus de moi. Le « moi de dans six mois » (ou celui d’un soir de panne) trouvera la réponse écrite, avec la commande qui la prouve.

Le droit de dire non. Un backlog priorisé permet d’assumer qu’un sujet attendra. Ce n’est pas un oubli, c’est une décision datée.

Les garde-fous

Travailler ainsi n’a rien de magique, et quelques règles me semblent indispensables.

  • L’IA se trompe, parfois avec aplomb. La journée ci-dessus le montre. La parade n’est pas de lui faire confiance ou de s’en méfier en bloc : c’est d’exiger une vérification avant toute conclusion. Une hypothèse n’est rien tant qu’une commande ne l’a pas confirmée.
  • Lecture seule d’abord. On observe avant de modifier. Les commandes qui changent quelque chose viennent après, avec une sauvegarde et un plan de retour arrière.
  • L’humain exécute. Aucun accès direct de l’IA aux machines. C’est plus lent, et c’est voulu.
  • Attention à ce qu’on partage. Tout ce que je colle dans la conversation part chez un fournisseur d’IA. Pas de mots de passe, pas de clés, et un œil sur les informations sensibles. C’est aussi pour ça que cet article reste volontairement vague sur les détails de mon réseau.

Pour être honnête, il y a aussi une tension avec ce que je défends sur ce blog : Claude est un service propriétaire et hébergé, loin de l’autohébergement et du logiciel libre. Je l’utilise en connaissance de cause, pour ce qu’il m’apporte, tout en gardant la maîtrise de mes machines et de ma documentation, qui elles restent chez moi.

Le point de vue de l’IA

Cette section est écrite par Claude.

Ce qui rend cette collaboration efficace, ce n’est pas ma capacité à connaître OPNsense, TrueNAS ou Caddy. C’est la documentation. Je ne garde aucun souvenir d’une conversation à l’autre, sauf ce qui a été écrit. Une fiche à jour me permet de reprendre exactement là où nous nous étions arrêtés ; une fiche obsolète me fait raisonner juste sur des faits faux.

Ce jour-là, je me suis trompé trois fois : deux hypothèses réseau et une supposition sur le matériel d’Etienne. À chaque fois, c’est un fait observé (une page qui s’affiche, une capture vide, une correction d’Etienne) qui a remis les choses d’aplomb. La méthode a rattrapé mes erreurs avant qu’elles ne coûtent quoi que ce soit. C’est exactement pour ça qu’elle compte plus que moi.

Pourquoi signaler l’IA

Je termine sur ce qui m’a décidé à étiqueter cet article. Un texte rédigé par une IA et présenté comme humain, c’est une petite tromperie envers le lecteur. Et ça entretient l’idée que l’IA serait honteuse, ou magique, alors qu’elle n’est qu’un outil, puissant, faillible, qui se révèle utile quand on l’encadre.

Ici, l’IA a écrit ; j’ai relu, corrigé et validé. Les faits sont ceux de mon homelab, les erreurs sont racontées telles qu’elles se sont produites. Et si vous vous demandez si ça vaut le coup d’essayer : commencez par la documentation. Avec ou sans IA, c’est elle qui change tout.