Avant, déployer un nouveau service chez moi ressemblait à ça : connexion sur l’interface de mon Proxmox, cloner une VM depuis mon template Debian custom, config l’IP, SSH, écrire le docker-compose, configurer l’host dans mon Nginx Proxy Manager, pousser l’entrée DNS dans Pi-Hole… Bref, un peu fastidieux.

Même si j’avais déjà pensé à me motiver pour préparer un template Terraform propre, Ansible-iser et scripter tout le process afin de me faciliter la vie, je n’avais pas encore eu le temps de m’y mettre qu’Anthropic sortait son plugin Telegram pour Claude Code. Et là, tout est devenu beaucoup plus simple…

Allongé sur mon canapé, je peux simplement envoyer un message Telegram depuis mon iPhone du type : “Déploie-moi Homepage dans un container, expose-le sur home.syspirit.fr et alimente-le avec tous les services que je selfhost.”

Quelques minutes plus tard, Claude m’annonce qu’il a terminé et que c’est UP.

Aujourd’hui, je vais vous expliquer comment j’ai monté tout ça, les possibilités, et surtout les garde-fous que j’ai mis autour.

L’idée

Le principe est simple : faire tourner Claude Code en permanence dans mon homelab, lui donner les clés SSH de mon infra, et brancher un bot Telegram en frontend pour lui parler de n’importe où. Mon téléphone devient une télécommande sur tout mon lab.

Ce n’est plus “l’IA qui répond à des questions”, c’est l’IA qui agit sur mes machines, avec ses propres accès.

L’architecture

iPhone (Telegram) → Bot Telegram → Claude Code (LXC Proxmox)
                                        │
                                        ▼
                                 clés SSH vers l'infra
                                 (host Proxmox, VMs, NPM, Pi-Hole)

Concrètement :

• Un LXC dédié sous Debian sur mon Proxmox, avec un user claude-agent qui lui est réservé.
• Claude Code installé dedans et configuré sous forme de service pour survivre aux déconnexions. Ce n’est pas du confort : les messages n’arrivent que dans une session ouverte, donc il faut un process qui tourne en permanence. La solution d’utiliser tmux est également possible.
• Le plugin Telegram officiel (/plugin install telegram@claude-plugins-official), configuré avec un bot créé via BotFather. Il tourne sous Bun, à installer avant.
• Une allowlist Telegram pour que seul mon compte puisse parler au bot.

Le plugin fait partie des channels, une fonctionnalité en research preview qui permet de pousser des événements dans une session Claude Code en cours. On lance la session avec le flag qui va bien :

claude --channels plugin:telegram@claude-plugins-official

Le LXC a des clés SSH déployées vers les machines que je veux piloter. J’ai généré une paire de clés dédiée à claude-agent plutôt que de réutiliser mes clés perso : si je veux lui couper les accès, je révoque une seule clé, sans toucher aux miennes.

Et surtout, je lui ai fourni un inventaire : la liste des serveurs auxquels il a le droit de se connecter, avec pour chacun son rôle, son IP et l’utilisateur à employer. C’est ce qui fait la différence entre un agent qui tâtonne et un agent qui sait où aller.

Ce que je lui fais faire concrètement

Quelques exemples réels, tirés de mon usage quotidien :

• “Crée-moi une VM Debian 13 sur Proxmox avec 4 Go de RAM.” Il SSH sur le host, lance un qm clone depuis mon template, démarre la VM, attend l’IP DHCP et me la donne.
• “Installe-moi Uptime Kuma dans un container Docker dessus.” Il SSH dans la VM, écrit le docker-compose.yml, lance docker compose up -d.
• “Expose le service sur uptime.syspirit.fr.” Il SSH sur la VM Nginx Proxy Manager, crée le proxy host, demande le certificat Let’s Encrypt, et pousse l’entrée DNS sur Pi-Hole.
• “Fais-moi une note en markdown de ce qu’on vient de déployer.” Il me sort un doc propre, prêt à ranger dans Obsidian.
• “Fais un tour d’horizon du Proxmox et fais-moi un rapport sur les ressources du serveur : CPU/RAM/SWAP/Stockage.” Il se connecte au Proxmox, extrait les données nécessaires, investigue si quelque chose ne va pas et me fait un rapport complet.

En gros, tout ce que je faisais à la main. Sauf que je ne touche plus un clavier.

Le nettoyage marche aussi bien que le déploiement : avant de supprimer quoi que ce soit, il liste ce qu’il s’apprête à retirer et attend mon feu vert. Il demande souvent confirmation, mais rien ne l’y oblige. C’est le modèle qui choisit d’être prudent, pas le système qui l’y contraint, et c’est exactement pour ça que le permission relay dont je parle en conclusion m’intéresse.

Un autre use-case assez impressionnant (je trouve) que je lui ai demandé : “Tous les 2 jours, scan les sites d’offres d’emploi accessibles, récupère celles qui correspondent à mes critères, attribue une note et sors-moi le top 5 en HTML, avec le détail et la justification du choix.”

Il a écrit le script, l’a branché sur un cron, et je reçois mon rapport tous les deux jours.

Pourquoi c’est un vrai changement

Au-delà de l’effet démo, il y a quatre trucs qui ont changé mon quotidien :

• La vitesse. Une tâche de 30 minutes devient 30 secondes de chat. Ça enlève la friction qui me faisait repousser des déploiements.
• La doc automatique. Je peux lui demander de documenter ce qu’on vient de faire, et j’ai une note reliée dans mon vault sans effort.
• L’apprentissage. Il commente ce qu’il fait, donc je vois passer des commandes ou des options que je ne connaissais pas.
• La disponibilité. En train, en voyage, au resto, je peux intervenir sur mon infra depuis mon téléphone.

Les garde-fous

Donner un accès SSH large à une IA, ça se réfléchit. Voici ce que j’ai mis en place :

• Clé SSH dédiée et révocable. claude-agent a sa propre paire de clés. Le jour où je veux lui couper les accès, je révoque cette clé, et rien de ce qui m’appartient ne bouge.

• Allowlist Telegram. Par défaut le bot est en mode pairing : il répond à un inconnu avec un code d’appairage. Je suis passé en allowlist stricte, où tout message d’un compte non autorisé est jeté sans réponse :

  /telegram:access policy allowlist
  /telegram:access allow <mon_user_id>
  

  C’est le point le plus important côté sécurité. Un channel non filtré, c’est une porte d’entrée pour de l’injection de prompt : n’importe qui capable d’écrire au bot met du texte devant Claude, qui a un shell.

• Pas de secrets dans les prompts. Les mots de passe et tokens vivent dans des .env côté VMs, jamais dans le chat.

• Backups réguliers (j’utilise Zerobyte si ça intéresse 😁). Au cas où il fasse une bêtise, je peux revenir en arrière.

Les limites (parlons-en)

Je ne vais pas vendre ça comme magique, il y a quelques bémols :

• Le lancement se fait avec --dangerously-skip-permissions. Comme le nom l’indique, c’est dangereux. Acceptable dans un homelab où j’assume le risque et où j’ai des backups, inacceptable en prod.
• Autant le dire franchement : Claude a les accès root sur mon infra. Un qm clone sur le host Proxmox ou un docker compose sur une VM l’exigent de fait. Combiné au flag ci-dessus, ça veut dire qu’il peut tout faire, y compris tout casser, sans qu’aucun prompt ne l’arrête. C’est le prix de la fluidité, et c’est un prix que je n’accepte que chez moi.
• Les messages envoyés quand le bot est down sont perdus. Il est important de bien gérer la mémoire de Claude.
• L’IA peut se tromper sur des choses subtiles : une mauvaise IP, un port, une syntaxe YAML, une mauvaise clé SSH. Il faut relire et la guider clairement.
• C’est une research preview. Le flag --channels et le contrat des channels peuvent bouger d’une version à l’autre.

Ce que je retiens

C’est sans hésiter mon meilleur upgrade de homelab de l’année. Pas parce que c’est impressionnant en démo, mais parce que ça a supprimé la friction qui me faisait remettre à plus tard la moitié de mes projets.

Je pense sincèrement que ce pattern (une IA avec accès shell, pilotée depuis un chat) va devenir standard côté ops dans un ou deux ans (si ce n’est pas déjà fait…). Le vrai chantier, c’est de sortir du --dangerously-skip-permissions pour rendre ça utilisable en prod : sandboxing, scopes précis, audit log, validation humaine sur les actions sensibles.

Et sur ce dernier point, ça a déjà bougé sans que je le voie passer. En préparant cet article, j’ai découvert que le plugin Telegram sait relayer les demandes de permission : quand Claude veut lancer une commande, le prompt d’autorisation arrive sur mon téléphone avec un identifiant court, et je réponds yes ou no pour valider ou refuser à distance. C’est documenté côté channels et bien présent dans le code du plugin, à partir de Claude Code v2.1.81. Ça ne couvre que les appels d’outils (Bash, Write, Edit), mais c’est exactement ce qui manquait pour se passer du flag dangereux.

Mais dans tous les cas, pour un homelab, aujourd’hui, ça tient déjà largement la route. Et honnêtement, piloter mon infra depuis mon canapé, je ne reviendrai pas en arrière.