Projet Supervision & automatisation

Mises à jour Linux pilotées par IA : Zabbix détecte, l'IA décide, Jenkins exécute

Mon rôle : Conception, développement et exploitation

Contexte

Sur une flotte de serveurs Linux, les correctifs de sécurité s'appliquent « quand on aura le temps » — c'est-à-dire trop tard. Chaque jour de retard, une faille déjà connue reste ouverte et exploitable.

Démarche

Une chaîne où Zabbix détecte les paquets et correctifs en attente sur chaque serveur, n8n orchestre le traitement, un LLM trie entre correctifs de sécurité sûrs (appliqués automatiquement) et changements sensibles (revue humaine), puis déclenche les jobs Jenkins qui exécutent les mises à jour. Chaque pipeline Jenkins : snapshot avant, application par vagues, re-contrôle de santé via Zabbix, rollback automatique si dégradation, journal d'audit complet.

Cadres : Supervision · Automatisation · Sécurité

Livrables

  • Détection des mises à jour et correctifs de sécurité en attente sur la flotte via Zabbix (apt list --upgradable, dnf check-update)
  • Workflow n8n : collecte du contexte, appel de l'IA, notifications et journalisation
  • Tri assuré par le LLM, qui déclenche les jobs Jenkins correspondants : correctifs sûrs en automatique, changements sensibles en revue humaine
  • Exécution par pipelines Jenkins : snapshot avant, déploiement par vagues, re-contrôle de santé et rollback automatique si dégradation
  • Journal d'audit complet et notifications (mail / chat) à chaque étape

Faits clés

Détection
Orchestration
Décision & tri
Exécution
Sûreté
Traçabilité

Propriétés techniques du produit/projet, vérifiables.

Stack technique

Logos des solutions open source utilisées, à titre indicatif.

Le besoin

Quand on administre une flotte de serveurs Linux, les correctifs de sécurité s’appliquent trop souvent « quand on aura le temps ». Entre la publication d’un correctif et son installation, la faille reste ouverte trop longtemps — et c’est précisément cette fenêtre que les attaquants exploitent.

Le problème n’est pas de savoir patcher — c’est le temps. Le vrai frein n’est pas technique, il est humain : trier à la main les paquets en attente sur chaque machine, lire les changelogs, décider quoi appliquer et quand, c’est un travail sans fin qu’on repousse. Résultat, des correctifs simples et sûrs attendent, pendant que la surface d’exposition grandit.

Ce que j’ai construit

Une chaîne qui retire ce travail répétitif sans retirer le contrôle. Zabbix supervise déjà la flotte : je m’en sers pour détecter les paquets et correctifs en attente sur chaque serveur (apt list —upgradable, dnf check-update, mises à jour de sécurité) et lever un événement. Zabbix connaît aussi le rôle et l’état de santé de chaque machine — un contexte précieux pour la suite.

n8n reçoit l’événement et orchestre le reste : il rassemble le contexte (paquets concernés, gravité des CVE, criticité du serveur), passe la main à l’IA, puis notifie et journalise.

Le LLM fait le tri. Il lit la gravité des CVE, les changelogs et le rôle du serveur, puis sépare ce qui peut s’appliquer seul — les correctifs de sécurité sûrs — de ce qui mérite une revue humaine, accompagné d’un résumé clair et d’une recommandation. C’est l’IA qui déclenche ensuite les tâches sur le serveur Jenkins : selon sa décision, elle lance le job qui correspond. Sur les serveurs sensibles, je reste dans la boucle : l’IA propose, je valide, le job part.

Le travail réel se fait dans des pipelines Jenkins, encadrés de bout en bout : snapshot avant, déploiement par vagues, re-contrôle de santé via Zabbix après, et rollback automatique si quelque chose se dégrade. Chaque étape est notifiée (mail ou chat) et consignée dans un journal d’audit.

L’esprit

Un outil sobre et auditable, pensé pour durer sans maintenance lourde. Il ne cherche pas à décider à ma place : il abat le travail répétitif et sûr, garde une trace de tout, et me réserve les décisions qui engagent.

Les correctifs sûrs ne dépendent plus d’une disponibilité ; l’humain ne tranche que ce qui compte ; tout est tracé.