Pourquoi acheter un Mac mini ? Alors qu’un mini PC à 130€ fait tourner Hermes Agent 24h/24 aussi bien

Depuis quelques mois, je vois passer beaucoup de publications et de vidéos YouTube qui expliquent qu’il faut un Mac mini ou un VPS pour faire tourner un agent autonome comme OpenClow ou Hermes Agent. 700€ la machine, ou un abonnement mensuel qui part indéfiniment. Et en y réfléchissant bien, à ce qu’on leur demande concrètement : tourner 24h/24, attendre des messages Telegram, exécuter des workflows la nuit pendant qu’on dort. Pas de l’inférence lourde, pas de rendu 3D. Juste orchestrer et déléguer.

Je vais te montrer une autre voie : un mini PC à 130€, moins gourmand, moins cher, qui fait exactement le même boulot.

Cette machine tourne sans écran ni clavier depuis plusieurs semaines chez moi. Elle reçoit mes ordres par Telegram, exécute des tâches en arrière-plan, et s’appuie sur ma machine principale ou OpenRouter quand elle a besoin de compute. C’est le control plan permanent du setup, pas la brute de calcul.

Voilà comment j’ai fait, brique par brique, avec les détails d’installation que j’aurais aimé trouver en un seul endroit.

1. Le matos et pourquoi pas autre chose

Le mini PC : MLLSE G2 Pro

Intel N150, 12 Go de LPDDR5, 512 Go de SSD, WiFi 5, Bluetooth 5.0. Windows 11 Pro pré-installé, que j’ai remplacé par du Linux en dix minutes.

Le N150 est un quad-core basse consommation. Il ne va pas faire tourner un Llama 70B en local. Ce n’est pas son rôle. Son rôle, c’est d’être sobre et toujours allumé. Sous charge normale de serveur, il tire 9W. C’est ridicule. Une ampoule LED de bureau en consomme davantage. Ramené à l’année entière, ça représente environ 8€ d’électricité pour un serveur qui tourne 24h/24, à comparer aux 180€ d’un VPS entrée de gamme sur la même période, rien qu’en abonnement. Le chassis est conçu pour un usage permanent : pas de batterie qui gonfle, pas de ventilo qui s’encrasse.

Pourquoi pas un VPS cloud ?

5€/mois, ça paraît rien. Sur trois ans, tu as payé 180€ pour une machine qui n’est pas chez toi, qui ne voit pas ton réseau local, et qui te facture chaque byte de trafic sortant. Mon agent IA a besoin de parler à Ollama sur ma machine principale, à ComfyUI, à SearXNG. Avec un VPS, tout ça passerait soit par internet (latence plus coût), soit par un tunnel VPN. Avec un mini PC sur le LAN, c’est une simple requête HTTP sur le réseau interne. Pas de souci.

	Mini PC local	VPS cloud
Coût d’entrée	130€ une fois	0€
Abonnement mensuel	0€	5 à 15€/mois
Coût total sur 3 ans	~154€ (matériel + élec)	180 à 540€
Accès réseau local	✅ Natif, zéro config	❌ Tunnel VPN requis
Latence vers Ollama, ComfyUI	< 1ms (LAN)	20 à 100ms+
Données chez soi	✅	❌ Chez le prestataire
Coupure si impayé	Non	Oui
Upgrade RAM / SSD	✅ Possible	Dépend de l’offre
Accès admin complet	✅ Root physique	✅ Root SSH

Le mini PC coûte plus cher le premier jour. Il est moins cher dès le quatorzième mois, et il reste sur ton réseau.

Pourquoi pas un vieux laptop ?

Un laptop qui tourne 24h/24, c’est une batterie qui gonfle dans les douze mois, un ventilo qui accumule de la poussière, et une consommation 3 à 5× supérieure au mini PC. La machine n’est pas faite pour ça. Le mini PC, si.

Pourquoi pas le Mac mini M4 à 700€ ?

Parce que le gros calcul, je l’ai déjà : Ryzen 9 + RTX 5070 Ti sur ma machine principale. Ce que je cherche ici, c’est un orchestrateur sobre et permanent qui sait déléguer. La même logique headless que partout ailleurs : mettre le bon outil au bon endroit, ne pas gâcher la ressource. Le Mac mini ferait la même chose six fois plus cher.

---

2. La stack : ce qu’on installe et pourquoi chaque brique

Avant le détail de l’installation, une vue d’ensemble de l’architecture cible.

[SCHÉMA : tazmenworld ↔ autoserver ↔ Telegram ↔ internet]

Le control plan (autoserver) décide et orchestre. Le compute (tazmenworld) calcule. La seule sortie cloud : les appels LLM vers OpenRouter. C’est du pay-per-use, pas un abonnement fixe. À l’usage courant, quelques dizaines de requêtes par jour sur DeepSeek V4, ça se chiffre en centimes. Tout le reste reste sur le réseau local.

---

3. Ubuntu Server 26.04 LTS : le socle headless

Pas d’interface graphique. C’est un serveur, il vit en console. On choisit Ubuntu Server 26.04 LTS « Resolute Raccoon », supporté jusqu’en 2031 (2036 avec Ubuntu Pro, gratuit jusqu’à 5 machines personnelles).

Créer la clé USB depuis tazmenworld

bash

cd ~/Downloads
wget https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso

# Identifier la clé USB
lsblk

# Écrire l'image (remplace /dev/sdX, ATTENTION : tout sera effacé)
sudo dd if=ubuntu-26.04-live-server-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync
sync

Options d’installation qui comptent

On démarre sur la clé (touche F7 ou Del au boot pour le menu), puis dans l’installeur Subiquity :

Étape	Choix
Type d’installation	Ubuntu Server (minimized), moins de paquets, moins de RAM grignotée
Réseau	DHCP pour l’instant, on passe en IP statique après
Stockage	Use entire disk, pas de LVM pour simplifier
Nom du serveur	autoserver
OpenSSH	✅ À cocher absolument, sinon tu ne peux plus te connecter à distance
Snaps additionnels	Rien, on installe tout manuellement

Une fois installé, on retire la clé USB, on redémarre. La machine boote en console texte. C’est normal, c’est voulu.

Mise à jour complète et outils de base

bash

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

sudo apt install -y \
  curl wget git nano htop net-tools \
  ca-certificates gnupg lsb-release \
  ufw fail2ban unattended-upgrades \
  tree jq ncdu

sudo reboot

IP statique via Netplan

Un serveur ne peut pas changer d’IP à chaque redémarrage. On configure une IP fixe via Netplan, mais avant d’écrire quoi que ce soit, on vérifie la vraie adresse de la passerelle. Sur ton réseau, elle n’est pas forcément 192.168.1.1. La vérifier d’abord sur tazmenworld :

bash

ip route | grep default
# Exemple : default via 192.168.1.254 dev enp14s0
#                       ↑ c'est cette IP qu'on met dans netplan

Puis on identifie l’interface réseau sur autoserver :

bash

ip link show
# Exemple : enp2s0 (Ethernet), préférer l'Ethernet au WiFi pour un serveur

On édite la config :

bash

sudo nano /etc/netplan/00-installer-config.yaml

yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:                        # adapter à ton interface
      addresses:
        - 192.168.1.20/24
      routes:
        - to: default
          via: 192.168.1.254       # ta vraie passerelle, pas une supposée
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      dhcp4: false

On applique et on vérifie :

bash

sudo netplan apply
ip addr show enp2s0        # l'IP 192.168.1.20 doit apparaître
ping -c 3 1.1.1.1          # si ça ne répond pas → passerelle incorrecte
ping -c 3 tazmenworld      # joignabilité réseau local

Synchronisation horaire

bash

sudo timedatectl set-timezone Europe/Paris
timedatectl status
# "System clock synchronized: yes" doit apparaître

Sécurisation SSH

On génère une paire de clés ed25519 sur tazmenworld :

bash

ssh-keygen -t ed25519 -C "tazmenworld→autoserver" -f ~/.ssh/autoserver_key

On copie la clé publique sur autoserver (avec le mot de passe temporaire) :

bash

ssh-copy-id -i ~/.ssh/autoserver_key.pub <votre_user>@192.168.1.20

On teste la connexion par clé :

bash

ssh -i ~/.ssh/autoserver_key <votre_user>@192.168.1.20

Puis on durcit la config SSH sur autoserver :

bash

sudo nano /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers <votre_user>
X11Forwarding no

Spécificité Ubuntu 26.04, deux points à ne pas rater :

1. X11Forwarding en double. Le fichier par défaut contient souvent X11Forwarding yes plus haut. Commente cette ligne, sinon ta ligne no en bas sera ignorée.

2. Socket activation. Ubuntu 26.04 gère le port SSH via ssh.socket. Un simple restart ssh ne suffit pas :

bash

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

⚠️ Teste depuis un deuxième terminal avant de fermer ta session actuelle :

bash

# Depuis tazmenworld, nouveau terminal
ssh -i ~/.ssh/autoserver_key -p 2222 <votre_user>@192.168.1.20

Si ça passe, on peut fermer l’ancienne session. On configure ensuite un profil SSH sur tazmenworld pour ne plus jamais taper l’IP :

bash

nano ~/.ssh/config

Host autoserver
    HostName 192.168.1.20
    Port 2222
    User <votre_user>
    IdentityFile ~/.ssh/autoserver_key
    ServerAliveInterval 60

Désormais : ssh autoserver. C’est tout.

Pare-feu UFW et Fail2ban

bash

# Règles UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment "SSH"
sudo ufw allow 5678/tcp comment "n8n"
sudo ufw allow from 192.168.1.0/24 comment "Réseau local"
sudo ufw enable
sudo ufw status verbose

bash

# Fail2ban, bannissement auto des tentatives de brute-force
sudo nano /etc/fail2ban/jail.local

ini

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 3

[sshd]
enabled  = true
port     = 2222
logpath  = /var/log/auth.log

bash

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Mises à jour automatiques de sécurité

bash

sudo dpkg-reconfigure --priority=low unattended-upgrades
# → Yes

Le serveur se patche tout seul sur les failles de sécurité. On n’a plus à y penser.

---

4. Docker : l’isolement propre

Pour n8n, on containerise. Docker isole le service, simplifie les mises à jour, et évite de polluer le système hôte.

Note Ubuntu 26.04 : Resolute Raccoon a supprimé le support de cgroup v1. Docker le gère nativement depuis la v20.10, mais il faut impérativement passer par le dépôt officiel Docker, pas le paquet docker.io des dépôts Ubuntu qui est souvent en retard.

Installation Docker CE (méthode officielle)

bash

# Supprimer d'éventuelles vieilles versions
sudo apt remove -y docker docker-engine docker.io containerd runc 2>/dev/null

# Clés GPG et dépôt officiel Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
                    docker-buildx-plugin docker-compose-plugin

Si apt update échoue avec une erreur sur le codename resolute : le dépôt Docker n’a peut-être pas encore indexé 26.04. Solution : forcer le codename noble (24.04), les paquets sont compatibles.

bash

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Ajouter l’utilisateur au groupe docker

bash

sudo usermod -aG docker <votre_user>

Piège sur install minimized : newgrp n’est pas disponible. Le groupe ne s’active pas dans la session en cours. Tu dois te déconnecter et te reconnecter, sans message d’erreur explicite, juste un permission denied silencieux sur docker run si tu oublies ce détail.

bash

exit
# puis : ssh autoserver

# Tester depuis la nouvelle session
docker run --rm hello-world
docker compose version

Configurer le daemon Docker

bash

sudo nano /etc/docker/daemon.json

json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-address-pools": [
    {"base": "172.20.0.0/16", "size": 24}
  ]
}

bash

sudo systemctl restart docker
docker info | grep -i "log driver"
# Attendu : Logging Driver: json-file

---

5. Structure des répertoires

bash

sudo mkdir -p /opt/autoserver/{n8n,hermes,shared,backups}
sudo chown -R <votre_user>:<votre_user> /opt/autoserver

/opt/autoserver/
├── n8n/
│   ├── docker-compose.yml
│   ├── .env
│   └── data/            ← volume persistant n8n
├── hermes/
│   └── data/
├── shared/              ← fichiers échangés entre services
└── backups/             ← sauvegardes automatiques

---

6. n8n : le moteur de workflows

n8n, c’est le chef d’orchestre des automatisations que tu as câblées. Il sait : « à 7h chaque matin, lance cette recherche ; si tel webhook arrive, déclenche ce traitement ». Interface visuelle, scriptable, il se connecte à des centaines de services.

Fichier d’environnement

bash

nano /opt/autoserver/n8n/.env

env

# Réseau
N8N_HOST=0.0.0.0
N8N_PORT=5678
N8N_PROTOCOL=http
WEBHOOK_URL=http://192.168.1.20:5678/

# Sécurité
N8N_ENCRYPTION_KEY=<générer_avec_openssl_rand_-hex_16>
GENERIC_TIMEZONE=Europe/Paris
NODE_ENV=production

# Indispensable en HTTP local, voir section "pièges"
N8N_SECURE_COOKIE=false

# Désactiver la télémétrie (évite des erreurs réseau parasites dans les logs)
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false

# Connexion Ollama sur tazmenworld
OLLAMA_BASE_URL=http://192.168.1.100:11434

Pour générer une clé d’encryption solide :

bash

openssl rand -hex 16

Docker Compose n8n

bash

nano /opt/autoserver/n8n/docker-compose.yml

yaml

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    env_file:
      - .env
    volumes:
      - ./data:/home/node/.n8n
      - /opt/autoserver/shared:/shared
    networks:
      - autoserver_net
    extra_hosts:
      - "tazmenworld:192.168.1.100"

networks:
  autoserver_net:
    name: autoserver_net
    driver: bridge

Le extra_hosts permet d’appeler http://tazmenworld:11434 depuis les workflows n8n au lieu d’une IP brute : plus lisible, et ça survit à un changement d’IP sans tout recâbler.

Fix permissions du volume (indispensable)

n8n tourne dans son container sous l’utilisateur node (UID 1000). Si le dossier data appartient à root, il ne peut pas écrire et crashe en boucle dès le démarrage sans message clair.

bash

sudo chown -R 1000:1000 /opt/autoserver/n8n/data

Autoriser Docker à sortir sur internet (UFW)

Par défaut, UFW bloque le forwarding des containers. n8n démarre correctement, mais tout appel HTTP externe échoue en silence : les workflows ne peuvent pas joindre d’API extérieure.

bash

sudo nano /etc/default/ufw
# Changer cette ligne :
# DEFAULT_FORWARD_POLICY="DROP"  →  DEFAULT_FORWARD_POLICY="ACCEPT"

sudo ufw reload

Lancer n8n

bash

cd /opt/autoserver/n8n
docker compose up -d
docker compose logs -f     # Ctrl+C pour quitter

Quand tu vois n8n ready on ::, port 5678, l’interface est accessible depuis tazmenworld via http://192.168.1.20:5678.

---

7. Hermes Agent : l’IA qui décide seule

C’est la brique qui fait passer le setup d’un serveur d’automatisation classique à un agent IA autonome. Hermes Agent est un projet open-source de Nous Research (licence MIT) : mémoire persistante entre les sessions, génération de ses propres skills, terminal sandboxé sous Docker, et gateway Telegram intégré. Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif et se débrouille.

Installation

bash

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Le script gère tout : Python 3.11, Node.js 22, ripgrep, ffmpeg. Il lance ensuite automatiquement le wizard de configuration.

Prérequis : internet doit être accessible depuis autoserver. Si curl -I https://github.com répond No route to host, tu as un problème de passerelle dans Netplan. Voir la section sur l’IP statique.

Configuration via le wizard

Les choix qui importent :

Étape	Choix
Backend LLM	OpenRouter, pour requêter DeepSeek V4
Clé API OpenRouter	sk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Modèle	deepseek/deepseek-v4
Outils	Tout cocher ✅ (web search, génération d’image, browser, terminal)
Terminal backend	Docker, sandbox isolé, propre
Messaging	Set up messaging now → Telegram
Type de service	System service, démarre au boot sans session ouverte

Configurer le bot Telegram

1. Ouvre Telegram, cherche @BotFather → /newbot
2. Donne un nom et un identifiant à ton bot
3. Récupère le token : 123456789:AAH-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4. Cherche @userinfobot → note ton User ID numérique
5. Renseigne le token et l’User ID dans le wizard
6. Réponds Y pour le Home Channel (DM direct avec le bot)
7. Réponds Y pour installer comme service en arrière-plan

Activer le linger : le détail qui rend le setup vraiment autonome

Le gateway Telegram tourne en user service systemd. Sans cette configuration, il ne démarre pas au boot si aucune session utilisateur n’est ouverte. Résultat : après une coupure de courant à 3h du matin, ton agent reste silencieux jusqu’à ce que quelqu’un se connecte en SSH.

bash

sudo loginctl enable-linger <votre_user>

# Vérifier
loginctl show-user <votre_user> | grep Linger
# Attendu : Linger=yes

Une fois activé, le serveur peut redémarrer seul : le gateway Telegram revient en ligne sans intervention de ta part.

Vérification et commandes utiles

bash

# Statut du gateway
systemctl --user status hermes-gateway

# Test CLI interactif
source ~/.bashrc
hermes
> Bonjour, que peux-tu faire sur ce serveur ?

# Changer de modèle à chaud, sans redémarrage
hermes setup model

# Mettre à jour
hermes update

# Diagnostic complet
hermes doctor

---

8. Intégration avec la stack de tazmenworld

Depuis n8n ou Hermes sur autoserver, tous les services de tazmenworld sont accessibles directement par IP locale :

Ollama        → http://192.168.1.100:11434
Open WebUI    → http://192.168.1.100:3000
ComfyUI       → http://192.168.1.100:8188
SearXNG       → http://192.168.1.100:8080
n8n principal → http://192.168.1.100:5678

Pour centraliser ça proprement :

bash

nano /opt/autoserver/.env.global

env

TAZMENWORLD_IP=192.168.1.100
AUTOSERVER_IP=192.168.1.20

OLLAMA_URL=http://192.168.1.100:11434
OPENWEBUI_URL=http://192.168.1.100:3000
COMFYUI_URL=http://192.168.1.100:8188
SEARXNG_URL=http://192.168.1.100:8080
N8N_TAZMEN_URL=http://192.168.1.100:5678

OPENROUTER_BASE_URL=https://openrouter.ai/api/v1
OPENROUTER_API_KEY=sk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Et les deux instances n8n peuvent se parler : depuis autoserver, un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<ton-webhook-id> déclenche un workflow sur tazmenworld. Les deux instances bossent ensemble.

---

9. Hermes en action : la démo Telegram

Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif en langage naturel et se débrouille pour l’atteindre. Sa mémoire persistante lui permet de se souvenir des échanges précédents et d’ajuster son comportement au fil du temps.

Exemple concret, hier soir depuis le téléphone :

Moi :    Fais une veille sur les modèles open-weight sortis cette semaine.
         Résume les 5 plus intéressants en 3 lignes chacun et dépose
         le résumé dans /shared/veille.md

Hermes : Je lance les recherches. Je te préviens quand c'est déposé.

[quelques minutes plus tard]

Hermes : ✅ Résumé déposé dans /shared/veille.md, 5 modèles couverts.

Le fichier était là le matin. Je n’avais pas rouvert l’app entre les deux messages.

Ce qui rend ça possible, c’est le linger activé plus haut. L’agent tourne en fond, il n’a pas besoin que tu sois connecté en SSH, il n’attend pas que l’écran soit allumé. Il fait son boulot, prévient, et attend le prochain ordre.

---

10. Les trois pièges que j’ai rencontrés

Piège 1 : La passerelle réseau qu’on suppose à tort

En configurant l’IP statique, j’ai mis 192.168.1.1 comme passerelle sans vérifier. Résultat : ping local OK, accès internet mort. Impossible d’installer Hermes : curl -I https://github.com répondait No route to host.

La règle : ne jamais supposer l’IP de la passerelle. La vérifier en amont avec ip route | grep default sur une machine qui marche, reporter la vraie valeur dans Netplan. Vingt secondes de vérification qui évitent une heure de debug.

Piège 2 : Les permissions Docker sur trois fronts

Trois problèmes distincts, tous liés aux permissions, tous bloquants à leur façon.

Le groupe docker ne s’active pas immédiatement. Après usermod -aG docker, sur une install minimized newgrp n’est pas disponible. Le groupe ne prend effet qu’après déconnexion/reconnexion, sans message d’erreur explicite, juste un permission denied sur docker run.

n8n crashe en boucle au démarrage. Le container tourne sous l’UID 1000 (node). Si le dossier data appartient à root, n8n ne peut pas écrire et redémarre toutes les trente secondes. Fix : sudo chown -R 1000:1000 /opt/autoserver/n8n/data. C’est la première chose à faire avant de lancer le container.

n8n ne sort pas sur internet. UFW bloque par défaut le forwarding des containers. Les workflows se déclenchent, mais tout appel HTTP externe échoue en silence. Fix : passer DEFAULT_FORWARD_POLICY de "DROP" à "ACCEPT" dans /etc/default/ufw, puis sudo ufw reload.

Piège 3 : Le cookie n8n qui bloque la connexion

Tu ouvres l’interface, tu entres tes identifiants, ça ne passe pas. Aucun message d’erreur clair. n8n exige par défaut un cookie sécurisé qui ne fonctionne qu’en HTTPS. En HTTP sur le réseau local, c’est l’impasse.

Une ligne dans le .env règle l’affaire :

env

N8N_SECURE_COOKIE=false

Redémarre le container, l’interface s’ouvre. À ne configurer qu’en local sur un réseau de confiance. Dès qu’on expose vers l’extérieur, on passe par un reverse proxy HTTPS.

---

11. Ce qu’on peut faire avec

Le setup une fois en place, voilà ce qui tourne concrètement.

Veille techno automatique. Chaque matin à 7h, n8n déclenche une recherche via SearXNG sur tazmenworld, envoie les résultats à l’agent, et m’expédie un digest propre sur Telegram. J’ouvre le téléphone au réveil avec un résumé au lieu de vingt onglets à scroller.

Tâches longues en arrière-plan. Je donne un objectif à Hermes le soir (un comparatif de solutions, une analyse de logs, une rédaction), il découpe, cherche, rédige, et dépose le fichier dans /shared/. Au matin, c’est prêt. Le « pendant que tu dors » du titre, c’est littéralement ça.

Délégation au GPU. L’agent reçoit une demande de génération d’image, mais le N150 n’a pas de GPU sérieux. Pas de souci : il envoie le job à ComfyUI sur tazmenworld via http://192.168.1.100:8188, récupère le résultat, me le renvoie. Le control plan décide, le compute exécute.

Webhooks inter-machines. Un workflow sur autoserver peut déclencher un workflow sur le n8n de tazmenworld via un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<id>. Les deux instances se parlent sans passer par internet.

Sauvegarde automatique à 3h du matin. Un cron sauvegarde les volumes Docker et garde les 7 dernières copies. Un alias as-status donne en deux secondes l’état des containers, la RAM, le disque, et la connectivité vers tazmenworld. Le serveur se surveille tout seul.

---

Conclusion

Il y a six mois, monter ce genre de setup demandait une connaissance pointue de Docker, des agents IA, et du self-hosting Linux. Aujourd’hui, l’installation tient en une soirée, et le résultat c’est un control plan IA permanent sur ton réseau local, piloté depuis ton téléphone, qui bosse sans te demander la permission.

Le Mac mini n’est pas mauvais. Il est juste disproportionné pour ce rôle. Et le vrai problème d’un VPS, ce n’est pas le prix : c’est qu’il ne voit pas ton réseau local. Un agent IA qui ne peut pas parler à tes services, c’est un outil à moitié aveugle.

Le mini PC à 130€ règle les deux problèmes : il est sur ton LAN, il est sobre, il ne s’arrête pas. Le calcul lourd, il a juste à savoir l’adresse de ta vraie machine pour le déléguer. C’est la même logique qu’on applique partout ici : ne pas gâcher la ressource, mettre le bon outil au bon endroit.

---

Matériel : MLLSE G2 Pro (Intel N150, 12 Go LPDDR5, 512 Go SSD). Stack : Ubuntu Server 26.04 LTS, Docker, n8n, Hermes Agent (Nous Research, licence MIT), DeepSeek V4 via OpenRouter. Les tokens, clés API et mots de passe dans les exemples sont des espaces réservés, génère les tiens avec les commandes indiquées.