Agentic AI : Veille agentique

Sommaire & objectif

Ce projet a pour but de mettre en place un cluster K3s sur mon homelab, afin d'y faire tourner des agents IA qui s'occupent de la veille à ma place et qui surveillent le cluster lui-même. Plutôt que de passer du temps chaque matin à parcourir des flux RSS, des bulletins de sécurité et des articles sur l'IA, l'idée est que des agents fassent le tri et m'envoient directement ce qui est pertinent.

Nous avons quatre types de veille :

• la veille technologique : infrastructure, Kubernetes, réseau, cloud, DevOps et outils IA pour les ops ;
• la veille innovation : des idées de produits ou de services autour de l'IA qui pourraient intéresser des gens ;
• la veille vulnérabilités : les CVE qui touchent mon parc, triées et priorisées ;
• la veille cluster : l'analyse des alertes du cluster, avec des propositions de correction appliquées uniquement avec mon accord.

La veille technologique, la veille innovation et la veille cluster sont gérées par des agents Hermès, la veille vulnérabilités par un workflow n8n. La raison de ce choix est expliquée plus bas.

Les agents communiquent avec moi via Telegram : un bot par agent de veille, un bot pour les alertes du cluster et l'agent Maintainer, et un bot d'audit qui me demande de valider chaque action de ce dernier. Pour la partie IA, c'est Claude (API Anthropic) qui est utilisé, mais jamais en direct : tous les appels passent par une passerelle, LiteLLM, qui centralise les clés, les budgets et le suivi des coûts.

Pour plus tard : monter Ollama sur une machine avec un vrai GPU (pas les ressources pour l'instant), pour que Claude se concentre sur le boulot qui demande de la cervelle et que les modèles légers en local se tapent le tri en masse.

Architecture

Voici une architecture globale du lab déployé pour ce projet :

Composant	Rôle
K3s	Distribution Kubernetes légère, en mono-nœud.
Ansible	Installation de la machine : prérequis Debian, K3s, ArgoCD et l'application racine.
ArgoCD	Déploiement en GitOps : le cluster se synchronise sur le contenu du dépôt Git.
Sealed Secrets	Permet de stocker les secrets chiffrés dans Git, seul le cluster peut les déchiffrer.
cert-manager	Génère les certificats HTTPS du lab et ceux de Linkerd.
Linkerd	Service mesh, chiffre automatiquement les échanges entre les applications (mTLS).
Traefik	Point d'entrée HTTPS pour les interfaces web, via la Gateway API.
LiteLLM	Passerelle vers Claude, avec une clé et un budget par agent.
Prometheus / Alertmanager	Métriques du cluster et envoi des alertes sur Telegram.
Grafana	Visualisation des coûts LLM et de l'état du cluster.
n8n	Outil de workflows, utilisé pour la veille vulnérabilités.
Hermès	Agents IA pour la veille technologique, innovation et la maintenance du cluster.
Serveur MCP Kubernetes	Donne à l'agent Maintainer un accès contrôlé au cluster (lecture, et écriture limitée sous approbation).

Chaque namespace bloque par défaut tout le trafic réseau, et on n'ouvre que ce qui est nécessaire. Seul le serveur MCP a accès à l'API Kubernetes, avec des droits limités, et seul LiteLLM connaît la clé de l'API Anthropic.

Agentic AI

Un chatbot classique répond à une question, puis s'arrête. Il n'agit pas et ne se souvient de rien d'une conversation à l'autre.

Un agent IA va plus loin : c'est un modèle de langage auquel on donne des outils (recherche web, lecture de pages, commandes...) et qu'on fait tourner en boucle. Concrètement, il reçoit un objectif, réfléchit à ce qu'il doit faire, utilise un outil, analyse le résultat, et recommence jusqu'à avoir terminé.

En plus de ça, un agent dispose généralement :

• d'une mémoire, afin de retenir ce qu'il a déjà vu et ce que l'on préfère ;
• de tâches planifiées, pour se déclencher tout seul sans attendre qu'on lui parle ;
• d'un canal de communication, dans notre cas Telegram.

Il faut cependant garder en tête qu'un agent peut se tromper. Il peut inventer une information (hallucination), se faire manipuler par un contenu piégé qu'il lit sur le web (injection de prompt), ou tourner en boucle et consommer du budget. C'est pour cette raison que les agents sont isolés au niveau réseau, que leur budget est limité, et qu'on ne leur confie pas les tâches qui doivent être exactes à 100 %.

Hermès

Hermès Agent est un agent IA open source (licence MIT) développé par Nous Research, sorti en février 2026. Ses principales fonctionnalités sont :

• une mémoire persistante : il garde le contexte d'une session à l'autre ;
• des skills : des capacités qu'il peut utiliser et améliorer ;
• il est agnostique du modèle : il fonctionne avec n'importe quel fournisseur compatible OpenAI. Dans notre cas, il passe uniquement par LiteLLM ;
• une passerelle de messagerie : il se connecte à Telegram, Discord, Slack, etc. ;
• des tâches planifiées : on peut lui demander de faire sa veille tous les jours à une heure précise ;
• des profils : chaque agent a son propre dossier avec sa configuration, sa mémoire et ses tâches.

Hermès a été préféré à OpenClaw, l'autre agent open source populaire, à cause des nombreux problèmes de sécurité rencontrés par ce dernier en 2026.

Les agents

Agent	Rôle	Fréquence
veille-tech	Veille technologique, avec une section « À tester dans le lab »	Chaque matin en semaine
veille-innovation	Idées de projets autour de l'IA	Chaque semaine
Maintainer	Analyse et correction des incidents du cluster, avec mon accord	À chaque alerte

Déploiement dans le cluster

Architecture

Chaque agent correspond à un Deployment avec un seul pod. Il n'y a pas de réplicas, car un agent possède une seule mémoire et un seul bot Telegram : deux instances entreraient en conflit.

Tous les agents utilisent le même chart Helm, situé dans applications/hermes/. Chaque agent a ensuite son propre fichier de valeurs et sa propre application ArgoCD.

Configuration et stockage

Au démarrage, un initContainer copie la configuration (config.yaml et SOUL.md) depuis Git vers le dossier de l'agent. La mémoire, les sessions et les tâches planifiées sont stockées sur un volume persistant, et sont donc conservées après un redémarrage.

Secrets

Chaque agent possède un secret contenant :

• le token de son bot Telegram ;
• mon identifiant Telegram, qui est le seul autorisé à lui parler ;
• sa clé LiteLLM, avec un budget mensuel limité.

Réseau

Par défaut, un agent peut uniquement joindre LiteLLM et Internet en HTTPS. Il n'a pas accès au réseau local ni aux autres applications du cluster.

Veille Technologique & Innovation

Ces deux agents utilisent le même outil, mais avec des consignes différentes :

• veille-tech : chaque matin en semaine, une synthèse de 5 à 10 éléments, avec pour chacun le titre, la source, un résumé et pourquoi c'est intéressant. Une section « À tester dans le lab » termine la synthèse ;
• veille-innovation : 3 à 5 idées par semaine autour de l'IA, avec le problème, la cible, ce qui existe déjà, ce qui serait différenciant et un premier pas réalisable rapidement.

Pour ce type de veille, une petite approximation n'est pas grave. Par contre, il est intéressant que l'agent apprenne avec le temps ce qui m'intéresse, et c'est justement ce que propose Hermès.

Notification Telegram de l'agent Hermès "veille-tech"

Suivi des coûts par agent (LiteLLM)

Veille Cluster (Maintainer)

Le Maintainer ne fait pas de veille sur l'actualité, mais sur le cluster lui-même. Son rôle est d'analyser ce qui se passe quand une alerte se déclenche, de m'expliquer le problème, et de proposer puis appliquer une correction, mais uniquement avec mon accord.

L'idée n'est pas de lui laisser les clés du cluster. Il peut tout lire pour comprendre, mais chaque action d'écriture doit être validée par moi sur Telegram, et ses droits sont limités au strict nécessaire.

Démonstration : une alerte s'est déclenchée et le bot d'alertes HomeLab m'a prévenu en privé (Alertmanager). Sur le groupe HOC, l'agent m'a ensuite fourni son analyse et ses actions, que j'ai simplement approuvées avec un « Go ». Enfin, le bot d'audit (Guardline LiteLLM) m'a demandé de confirmer l'intervention.

Fonctionnement

Quand une alerte arrive, l'agent suit toujours la même procédure :

1. il analyse l'état du cluster (pods, événements, logs, applications ArgoCD) pour trouver la cause, et pas seulement le symptôme ;
2. il m'envoie un rapport dans le groupe Telegram : résumé de l'incident, cause probable, solution proposée, et la liste des commandes qu'il veut lancer, chacune expliquée ;
3. il attend mon feu vert avant de faire quoi que ce soit ;
4. il exécute les commandes une par une, et chacune d'elles me demande une approbation ;
5. il vérifie le résultat. Si le problème est réglé, il me fait un retour. Sinon, il recommence une analyse, avec un maximum de 3 tentatives avant de me passer la main ;
6. si la solution sort de son périmètre (modification dans Git, droits manquants, problème matériel), il me le dit directement et m'explique ce que je devrais faire.

Ses consignes contiennent aussi la description de la stack. Il complète ensuite ses connaissances au fil des incidents grâce à sa mémoire persistante.

Serveur MCP Kubernetes

Pour agir sur le cluster, l'agent utilise un serveur MCP (Model Context Protocol). Un serveur MCP expose des outils à un agent IA. Celui-ci correspond en quelque sorte à un kubectl traduit en outils : lister les pods, lire des logs, consulter les événements, supprimer un pod, mettre à l'échelle un déploiement, etc.

Le serveur interroge l'API Kubernetes avec son propre ServiceAccount. Ce qu'il peut faire est donc exactement ce que son RBAC autorise :

Droits	Objet RBAC	Portée
Lecture (pods, logs, événements, déploiements, applications ArgoCD...)	ClusterRole + ClusterRoleBinding	Tout le cluster
Écriture opérationnelle (supprimer un pod, redémarrer ou mettre à l'échelle un déploiement, supprimer un Job, suspendre un CronJob)	ClusterRole + RoleBinding	Uniquement les namespaces n8n, litellm, hermes et grafana

C'est le type de binding qui décide de la portée : un même ClusterRole relié par un RoleBinding ne s'applique que dans le namespace du binding. C'est ce qui permet à l'agent de redémarrer un pod dans grafana, mais pas dans kube-system.

Certains droits ne sont accordés nulle part, car ils permettraient de contourner les protections :

• la lecture des Secrets ;
• exec et port-forward dans les pods, qui donneraient accès aux secrets montés ou permettraient de passer outre les NetworkPolicies ;
• la création de pods, qui pourrait servir à monter n'importe quel secret ou le disque de la machine ;
• la modification du RBAC, des nodes, des namespaces, des volumes et des applications ArgoCD.

Il faut aussi garder en tête que tout ce qui est géré par ArgoCD serait de toute façon remis en état par le selfHeal. L'agent se limite donc aux actions opérationnelles, et pour le reste, il propose la modification à faire dans Git.

Guardline (LiteLLM)

L'agent ne parle jamais directement au serveur MCP : tous ses appels passent par LiteLLM, qui sert de passerelle MCP. Une NetworkPolicy garantit que seul LiteLLM peut joindre le serveur, il est donc impossible de contourner la passerelle.

Dans LiteLLM, un garde-fou (Guardline sur le tool d'AI Gateway) écrit en Python s'exécute avant chaque appel d'outil :

• pour une lecture, l'appel passe et une notification m'est envoyée en privé ;
• pour une écriture, l'appel est bloqué et une demande d'approbation avec deux boutons (Approuver / Refuser) est envoyée dans le groupe, avec les arguments exacts de la commande. Sans réponse dans les 120 secondes, la commande est refusée.

Quelques choix de sécurité importants :

• le garde-fou fonctionne avec une liste d'outils de lecture autorisés. Tout outil inconnu, ou ajouté par une future version du serveur, demande une approbation par défaut ;
• seul mon identifiant Telegram peut approuver ;
• le bot qui envoie les demandes appartient uniquement à LiteLLM. L'agent n'a pas son token, il ne peut donc ni simuler une approbation ni effacer une notification ;
• en cas d'erreur (Telegram injoignable, code qui plante), la commande est refusée.

Les autres agents ont une clé LiteLLM qui leur interdit explicitement l'accès au serveur MCP. Seule la clé du Maintainer y a accès.

Organisation sur Telegram

Conversation	Contenu
Privé avec le bot d'alertes	Les alertes brutes d'Alertmanager
Groupe Homelab Operation Center (HOC)	Les rapports de l'agent et les demandes d'approbation
Privé avec le bot d'audit	Les notifications de lecture, pour garder une trace sans polluer le groupe

Réseau

Contrairement aux agents de veille, le Maintainer n'a pas accès à Internet : il peut uniquement joindre LiteLLM (pour le modèle et le serveur MCP) et les plages d'adresses officielles de Telegram.

Ajouter un nouvel agent

Voici les étapes pour ajouter un agent, par exemple veille-cloud.

1. Créer son fichier de valeurs dans applications/hermes/values-veille-cloud.yaml :

agent:
  name: veille-cloud

model:
  default: smart
  fallback: fast

soul: |
  Tu es un agent de veille cloud.
  Domaines : AWS, Azure, GCP, FinOps.
  Chaque lundi, une synthèse de 5 éléments maximum avec le titre,
  la source, un résumé en deux phrases et l'impact concret.
  Réponds en français, de façon concise.

Le champ soul correspond aux consignes de l'agent. Plus elles sont précises (format, longueur, ce qu'il doit ignorer), meilleure sera la veille.

2. Créer son application ArgoCD en copiant applications-manifest/hermes-veille-tech.yaml, puis en adaptant le nom, la release et le fichier de valeurs.

3. Créer son bot Telegram avec la commande /newbot de @BotFather, puis démarrer la conversation avec le bot. Sans cette étape, il ne pourra pas envoyer de message en premier.

4. Créer sa clé LiteLLM, avec un budget mensuel.

5. Créer son secret (token du bot, identifiant Telegram, clé LiteLLM).

6. Commit et push : ArgoCD crée l'agent automatiquement.

7. Planifier la veille en écrivant directement au bot sur Telegram, par exemple : « Chaque lundi à 8h, fais ta veille et envoie-moi la synthèse ici ».

n8n

n8n est un outil d'automatisation de workflows, qu'il est possible d'héberger soi-même. On construit des enchaînements de nœuds via une interface graphique : un déclencheur (planification, webhook...), des appels HTTP, des filtres, des transformations et des envois (Telegram, mail...). Chaque exécution est historisée, ce qui permet de voir exactement ce qui s'est passé.

n8n propose également un nœud AI Agent, qui permet d'intégrer un agent IA à un endroit précis du workflow. Dans notre cas, ce nœud utilise LiteLLM avec sa propre clé.

Veille Vulnérabilités déterministe

Le but est d'être averti rapidement lorsqu'une vulnérabilité touche mon matériel ou mes logiciels (FortiGate, hyperviseurs, systèmes, applications du lab), avec les informations nécessaires pour décider quoi faire : la CVE, son score, si elle est exploitée activement et si un correctif existe.

Sources

Les sources utilisées sont structurées et fiables : la base NVD, le catalogue CISA KEV (vulnérabilités activement exploitées), les bulletins CERT et les avis de sécurité des éditeurs.

Workflow

Sans entrer dans le détail, le workflow fonctionne en quatre étapes :

1. récupération des vulnérabilités depuis les différentes sources ;
2. filtrage selon mon inventaire, pour ne garder que ce qui me concerne ;
3. priorisation et rédaction de la synthèse par le nœud AI Agent ;
4. envoi du résultat sur Telegram.

Pourquoi n8n et pas Hermès ?

Pour la veille vulnérabilités, il n'y a pas de place pour l'approximation. Il faut être exhaustif, pour ne rater aucune CVE critique, et exact, avec le bon identifiant, les bonnes versions et le bon score.

Un agent autonome comme Hermès n'est pas fiable sur ce point. Il peut oublier une entrée, se tromper de version, ou même inventer un numéro de CVE, sans que l'on s'en rende compte. Et comme c'est lui qui déciderait quoi chercher, il serait impossible de garantir qu'il n'a rien oublié.

Avec n8n, les rôles sont séparés :

• la liste des vulnérabilités est produite par le workflow (appels API et filtres), elle est donc déterministe : la même entrée donne toujours le même résultat ;
• l'IA intervient uniquement à la fin, sur une liste déjà établie, pour prioriser et rédiger un résumé lisible ;
• chaque exécution est traçable dans n8n.

Pour résumer, Hermès est utilisé pour ce qui demande du jugement, et n8n pour ce qui demande de la rigueur. L'IA sert à rédiger, pas à trouver les informations.