Comment apprendre à n8n à réparer les services crashés sur votre serveur

Scène familière : un conteneur avec une base de données ou un serveur média crash en plein milieu de la nuit. Vous vous réveillez avec une alerte, ouvrez le terminal, vérifiez les logs, redémarrez le service crashé, et retournez vous coucher de mauvaise humeur. La surveillance classique ne sait qu'envoyer des messages de panique. Elle voit le symptôme mais ne cherche même pas à comprendre les causes.

Le populaire blogueur tech NetworkChuck a publié un dépôt intéressant appelé n8n-terry-guide. À l'intérieur se trouve un guide pas à pas pour construire Terry. C'est un administrateur système virtuel dans n8n qui vérifie les services, se connecte en SSH aux serveurs pour examiner les logs, et vous demande dans Telegram la permission de redémarrer.

L'idée semble amusante, mais derrière se cache une architecture d'agent pratique et facile à répliquer sur votre propre serveur.

Qui est Terry et pourquoi ce n'est pas qu'un simple bot

D'habitude, l'automatisation homelab est construite sur des scripts rigides. Le service crash — déclenche la commande docker restart. Si le port est occupé par un autre processus, le script se casse et commence à spammer des erreurs.

L'approche par agent LLM fonctionne différemment. L'auteur suggère d'entraîner le modèle comme un apprenti support, en élargissant progressivement ses responsabilités. Dans le dépôt, l'ensemble du processus est décomposé en cinq étapes d'évolution :

1. Vérificateur basique. L'agent ping un endpoint HTTP et vérifie la présence d'un tag HTML spécifique.
2. Diagnostiqueur. Si le service est indisponible, Terry se connecte en SSH, exécute docker ps, récupère le code de sortie et les dernières lignes de logs.
3. Réparateur automatique. Le modèle essaie de relancer le conteneur crashé et re-vérifie la disponibilité du site.
4. Dépanneur. L'agent rencontre un conflit de port, trouve le processus responsable en utilisant les utilitaires système, et prend une décision.
5. Humain dans la boucle. Le modèle trouve la cause de la panne, forme un plan d'action, et attend la confirmation du propriétaire dans le messenger.

La fonctionnalité principale ici est la cinquième étape. Personne de sain d'esprit ne donnerait un accès root à un modèle de langage sans contrôle. Terry peut effectuer des diagnostics de manière autonome, mais toute commande de modification doit être approuvée.

Comment l'intérieur de n8n est câblé

Toute la logique est construite en utilisant les nœuds standard de n8n sans écrire de code TypeScript ou Python personnalisé.

Au centre du schéma se trouve un nœud AI Agent avec un modèle GPT-4o-mini connecté et un bloc Simple Memory. Pour exécuter des commandes sur le serveur, l'auteur a trouvé une solution élégante : un sous-workflow séparé avec un nœud SSH.

Quand l'agent doit vérifier l'état du système, il appelle ce sous-processus comme un Tool, en passant la commande requise :

docker inspect website --format='{{.State.ExitCode}}'
docker logs website --tail 10

Pour automatiser les vérifications, un Schedule Trigger est placé avant l'agent, lançant le scénario toutes les 5 minutes. Pour empêcher le dialogue de devenir un désordre de texte arbitraire, un Structured Output Parser est utilisé en sortie du modèle. L'agent doit retourner du JSON dans un format strictement défini :

{
  "website_up": false,
  "message": "Контейнер остановлен из-за нехватки памяти",
  "applied_fix": false,
  "needs_approval": true,
  "commands_requested": "docker start website"
}

Grâce à la structure stricte, le nœud suivant IF ou Switch comprend instantanément si tout va bien. Si une panne est détectée, le scénario envoie un message sur Telegram avec des boutons de confirmation. Si on appuie sur "Oui" — n8n rend le contrôle à l'agent, et il effectue la réparation.

Connecter du vrai matériel

L'auteur ne s'est pas limité à un site de test sur Nginx. Le guide inclut des prompts système et des exemples de commandes pour quatre systèmes populaires :

• Hyperviseur Proxmox. L'agent obtient le statut des nœuds, la liste des VMs via pvesh get /nodes, et vérifie les conteneurs LXC.
• Équipement réseau UniFi. Requêtes à l'API UniFi Network pour surveiller les points d'accès, le nombre de clients et les consommateurs de trafic.
• NAS (Network Attached Storage). Vérification des attributs SMART des disques via smartctl, lecture du statut du RAID depuis /proc/mdstat, et vérification des erreurs critiques dans journalctl.
• Serveur média Plex. Vérification de l'interface web et redémarrage approprié en cas de plantage.

Pour les disques et le NAS, Terry est configuré pour fonctionner strictement en mode lecture seule. Le prompt interdit explicitement l'exécution de commandes de formatage, de remontage ou d'arrêt de pool.

Les pièges possibles

Si vous décidez de déployer un tel scénario sur votre propre serveur, faites attention à quelques nuances souvent oubliées lors de la configuration d'agents IA.

Premièrement, la limite d'itérations. Par défaut, le nœud AI Agent dans n8n effectue jusqu'à 10 appels d'outils par exécution. Si l'agent est perturbé par la sortie de netstat ou docker ps, il épuisera rapidement la limite et plantera avec une erreur. Les prompts doivent être aussi spécifiques que possible, en réduisant le champ des expérimentations.

Deuxièmement, le passage de session. Lors d'une exécution planifiée, vous n'avez pas de chat en direct, donc l'ID de session chatId doit être généré de manière rigide dans un nœud Edit Fields intermédiaire avant l'envoi à la mémoire de l'agent. Sinon, le contexte des vérifications précédentes sera perdu.

Troisièmement, le soi-disant God-Mode. Dans le dépôt, il y a un prompt avec tous les droits pour corriger automatiquement n'importe quel problème. L'activer sur un serveur de production n'estDefinitely pas recommandé : le modèle peut facilement supprimer un conteneur nécessaire pour libérer un port occupé.

Cela vaut-il le coup d'essayer

Le dépôt n8n-terry-guide ne contient pas de fichiers d'export de workflow prêts à l'emploi — c'est une collection de configurations, d'instructions pas à pas et de prompts affinés. Si vous utilisez déjà n8n pour des besoins personnels ou professionnels, le guide donne un excellent cadre pour créer un assistant de garde.

Le projet plaira à ceux qui en ont marre des alertes stupides et qui veulent recevoir sur Telegram non pas un cri de "service crashé", mais un diagnostic prêt avec un bouton "corriger". Commencez petit : configurez la vérification d'un conteneur de test, essayez l'intégration Telegram, et évaluez à quel point c'est pratique de déléguer des tâches routinières à un modèle de langage.