Quand un pod Kubernetes crashe à 3h du matin, deux options : une alerte vous réveille, ou le système se répare seul. Construire la deuxième option de manière responsable — c'est l'objectif de ce projet.
La plupart des projets d'automatisation échouent parce qu'ils ne savent pas s'arrêter. Self-Healing Platform v2 est conçu autour d'un principe inverse : accumuler des preuves avant d'agir. Le Mode Auto n'a été activé qu'après 51 validations humaines consécutives sans aucun rejet.
Tout commence par l'écoute. Prometheus surveille les 7 namespaces prod toutes les 15 secondes. Dès qu'un incident est détecté — CrashLoopBackOff, ImagePullBackOff, DeploymentFailed, OOMKilled — le pipeline se déclenche.
Groq LLaMA 3.3 70B analyse la cause racine et justifie une action recommandée avec un score de confiance de 0 à 100%. Le résultat arrive par email en moins de 2 secondes. Mais rien n'est exécuté — c'est le Mode Observe.
Chaque décision est enregistrée en PostgreSQL avec : namespace, pod, cause racine, action recommandée, score de confiance, modèle LLM utilisé, et version de la plateforme pour permettre des comparaisons futures.
Un constat rapide : laisser le LLM décider seul donne toujours "investigate" par prudence. Ce n'est pas utile. La solution : séparer la décision de la justification.
Le rule engine applique des règles métier strictes — CrashLoopBackOff → restart_pod, DeploymentFailed → rollback_argocd. Groq reçoit l'action déjà décidée et justifie pourquoi elle est correcte, avec un score de confiance sur son analyse de la cause racine.
Un Validator Flask permet de valider chaque décision depuis le navigateur — boutons Approve/Reject avec commentaire optionnel. Chaque validation est enregistrée dans une table incident_validations qui constitue l'audit trail objectif.
Le Mode Auto n'est pas activé parce que l'IA est intelligente. Il est activé parce que 51 incidents consécutifs ont été validés sans aucun rejet. C'est la différence entre de l'automatisation et de l'ingénierie.
Un Executor Flask sur srv-kubernetes reçoit les requêtes de n8n et exécute kubectl rollout restart via subprocess. Cette architecture contourne les restrictions NetworkPolicy entre le pod n8n et l'API K8s.
Chaque action est auditée : action_taken, action_result, MTTR calculé automatiquement, auto_reason. Le MTTR en conditions réelles est inférieur à 2 secondes entre la détection et la confirmation du restart.
deployment_not_found — qui bloque l'action quand le pod n'existe plus — est aussi important que le restart réussi.
