OpenClaw comme Agent d'Infrastructure Homelab — L'Ops Conversationnel
À 2 heures du matin, quand un pod Kubernetes crash, la dernière chose qu'on veut faire est d'ouvrir un laptop, se connecter en SSH, et taper des commandes kubectl. On veut envoyer un message depuis son lit et obtenir une réponse. C'est exactement ce que décrit Merox dans son article sur l'utilisation d'OpenClaw comme agent d'infrastructure homelab. Le concept est simple : remplacer les scripts Python personnalisés et les bots Telegram maintenus à la main par une instance OpenClaw dédiée, qui comprend le langage naturel et exécute les commandes système.
L'auteur part d'un constat familier. Son bot personnalisé, merox-agent, fonctionnait bien mais demandait une maintenance constante. Un serveur FastAPI, la gestion des sessions Telegram, un service systemd à maintenir à travers les migrations de serveurs. OpenClaw consolide tout cela en une seule installation. Plus de bot séparé, plus de gestion de tokens, plus de code à maintenir. L'agent devient une compétence Markdown versionnée dans le même dépôt que les manifests d'infrastructure qu'elle décrit.
Les cas d'usage concrets parlent d'eux-mêmes. Demander quels pods sont down renvoie le résultat de kubectl get pods filtré. Demander les logs Traefik affiche les 50 dernières lignes. Demander de réconcilier flux-system exécute flux reconcile et renvoie la sortie. Les questions sur l'espace disque, la mémoire, la charge système reçoivent des réponses formatées en clair. Demander ce qui a changé dans le dépôt d'infrastructure affiche le git log. Et pour les opérations destructives comme redémarrer Jellyfin, l'agent demande confirmation avant d'agir.
L'architecture est minimaliste et sécurisée. OpenClaw tourne directement sur le VPS, avec accès shell à l'infrastructure. Le Gateway se bind uniquement sur loopback, donc aucun port public exposé. Tailscale Serve expose l'interface de contrôle sur le tailnet personnel. Le bot Telegram se connecte directement à l'API Telegram. La politique dmPolicy avec allowlist garantit que seul l'utilisateur autorisé peut interagir avec l'agent, identifié par son ID numérique Telegram.
La configuration repose sur une compétence Markdown, la fameuse SKILL.md. Cette compétence décrit le cluster Kubernetes Talos Linux avec FluxCD GitOps, les manifests stockés dans /srv/kubernetes/infrastructure, et les opérations courantes comme kubectl get nodes, flux check, ou task reconcile. Elle documente aussi les services Docker gérés via Ansible sur le VPS : Traefik, Pi-hole, Portainer, Homepage, Netdata, Garage S3. Les règles de sécurité interdisent les opérations destructrices sans confirmation, privilégient le GitOps sur les kubectl apply directs, et protègent les fichiers sensibles comme age.key, les manifests sops.yaml, les kubeconfigs et les fichiers .env.
L'intégration avec Anthropic utilise directement l'API Claude, pas le flux OAuth de Claude Code CLI. Cela implique une clé API séparée et une facturation au token. Pour un assistant d'infrastructure personnel avec quelques requêtes par jour, l'auteur estime le coût entre 1 et 3 dollars par mois sur claude-sonnet-4-6. C'est raisonnable pour la commodité obtenue, surtout comparé au temps de maintenance économisé sur un bot personnalisé.
Le setup se déploie en quelques étapes standardisées. Installation de Node.js 24 via le dépôt NodeSource, puis npm install -g openclaw. Configuration des secrets dans ~/.openclaw/.env avec la clé Anthropic, le token du bot Telegram, et l'ID utilisateur. Création du fichier openclaw.json qui configure le modèle claude-sonnet-4-6, le channel Telegram avec allowlist, le gateway bindé sur loopback avec authentification token, et l'intégration Tailscale en mode serveur. La compétence infra va dans ~/.openclaw/workspace/skills/infra/SKILL.md. Un service systemd openclaw-gateway.service démarre le tout automatiquement au boot.
La beauté du système réside dans sa portabilité. La compétence infra est versionnée dans le même dépôt Git que les manifests d'infrastructure. Migrer de serveur signifie copier un fichier Markdown. Pas de code Python à adapter, pas de configuration FastAPI à reproduire, pas de gestion de dépendances pip. L'agent s'adapte au contexte décrit dans la compétence, et le tour est joué.
Pour les homelabs et les petites infrastructures, cette approche change la donne. L'ops devient conversationnel. On ne tape plus des commandes dans un terminal, on discute avec son infrastructure. Les barrières techniques s'effondrent : plus besoin de mémoriser les syntaxes kubectl complexes, plus besoin de scripts bash fragiles, plus besoin de dashboards à maintenir. L'agent comprend le langage naturel, traduit en commandes système, et renvoie des réponses lisibles.
Les implications pour la sécurité méritent attention. OpenClaw a accès shell direct au serveur. Une compromission de l'agent ou de la clé API Anthropic expose l'infrastructure complète. La politique allowlist limite les dégâts potentiels en restreignant l'accès à un seul utilisateur Telegram, mais la surface d'attaque reste réelle. Les règles de confirmation avant opérations destructrices ajoutent une couche de protection, mais ne remplacent pas une authentification forte et une surveillance des logs.
L'article de Merox démontre qu'OpenClaw peut aller bien au-delà de l'assistant conversationnel générique. Configuré correctement, il devient un opérateur d'infrastructure autonome, capable de diagnostiquer, réparer, et maintenir un homelab complexe. Pour les sysadmins fatigués de maintenir des bots maison, c'est une alternative élégante. Pour les homelabbers qui veulent gérer leur infrastructure depuis leur canapé, c'est le rêve devenu réalité. L'ops conversationnel n'est plus une promesse futuriste, c'est une technologie déployable aujourd'hui.