Ce document définit les exigences pour organiser, documenter, monitorer et automatiser une infrastructure domestique (homelab). L'objectif principal est de rendre l'infrastructure auto-suffisante, bien documentée, surveillée en continu, automatisée de manière intelligente, et reconstituable rapidement en cas de sinistre — le tout en minimisant les coûts d'API externes. L'infrastructure comprend plusieurs serveurs Proxmox, un pare-feu pfSense, AdGuard, Home Assistant, N8N, un LLM local (Ollama sur RTX 2060), un serveur mail HestiaCP, et divers services (Rustdesk, Teamspeak, Counter-Strike). Le versionnement repose sur GitHub (phase 1) puis GitLab self-hosted avec CI/CD (phase 2).
- Système_Documentation : Module responsable de la génération et du maintien de la documentation de l'infrastructure
- Système_Monitoring : Module centralisé de surveillance des services, VMs, LXCs et ressources matérielles
- Système_Réseau : Ensemble des composants réseau incluant pfSense, switches et configurations IP
- Système_Alerte : Module de notification par email via HestiaCP/SMTP lors d'événements critiques ou informatifs
- Système_Automatisation : Module d'orchestration des workflows via N8N, LLM local et Claude
- Système_Accès : Module de gestion des accès SSH par clés et des droits réseau dynamiques
- Système_Topologie : Module de visualisation de la topologie réseau et de l'inventaire des équipements
- Système_Mail : Module de gestion des emails (tri, archivage, extraction de factures) via HestiaCP et N8N
- Système_Parental : Module de contrôle d'accès réseau dynamique basé sur des demandes par email avec codes d'autorisation
- Système_Recovery : Module de reprise après sinistre basé sur Infrastructure-as-Code (Ansible + Git + PBS)
- Proxmox_Principal : Serveur Proxmox principal hébergeant VMs et LXCs (incluant le LLM local avec GPU passthrough RTX 2060)
- Proxmox_Backup : Serveur dédié aux sauvegardes Proxmox
- Proxmox_Secondaire : Petit serveur Proxmox utilisé pour les déplacements temporaires de VMs et backup redondant
- LLM_Local : Modèle de langage exécuté localement via Ollama en Docker avec GPU passthrough (RTX 2060)
- N8N : Plateforme d'automatisation de workflows self-hosted
- pfSense : Pare-feu et routeur de l'infrastructure (avec API REST pour contrôle programmatique)
- AdGuard : Serveur DNS avec filtrage publicitaire et contrôle parental (API REST native)
- Home_Assistant : Plateforme domotique pour l'automatisation du domicile
- HestiaCP : Panel d'hébergement web incluant serveur mail (SMTP/IMAP) sur domaine personnalisé
- GitHub : Dépôt Git cloud (phase 1) pour versionner l'Infrastructure-as-Code
- GitLab_Local : Instance GitLab self-hosted (phase 2) avec CI/CD intégré pour automatisation Ansible
- Système_Maintenance : Sous-module du Système_Automatisation responsable des mises à jour automatiques avec contrôle de compatibilité, hiérarchie d'exécution par vagues, vérification GPU/NVIDIA, et utilisation du Proxmox secondaire comme tampon de sécurité
- Proxmox_Tampon : Utilisation du Proxmox_Secondaire (NUC) pour héberger temporairement des VMs critiques pendant la mise à jour de l'hyperviseur principal, assurant la continuité des services sans cluster HA
- Système_Logs : Module de centralisation des logs (syslog, journald, Docker) via Loki/Promtail pour recherche et analyse
- WoL : Wake-on-LAN — technologie permettant de démarrer une machine à distance via un paquet Magic Packet envoyé sur le réseau
- Système_Runbooks : Sous-module du Système_Documentation responsable de la génération automatique par IA de guides pas-à-pas, tutoriels et procédures de restauration, maintenus à jour à chaque changement d'infrastructure
- Wiki_Local : Instance Wiki.js self-hosted sur infra-mgmt, synchronisée avec le repo Git, servant d'interface web pour consulter la documentation et les runbooks sans accéder au terminal
- Infra-mgmt : LXC dédié à la gestion de l'infrastructure (192.168.202.50), hébergeant Ansible, Prometheus, Grafana, Uptime Kuma, NetBox, Loki, Wiki.js. Séparé de N8N pour permettre une hiérarchie de mise à jour propre
- Synology_NAS : NAS Synology DS720+ (192.168.150.181), stockage principal (SMB/NFS) hébergeant les documents multi-entreprises, personnels, photos et dossier Scan. Accessible depuis les deux sous-réseaux internes, exposition Internet à minimiser
- Système_DocumentsIA : Module de gestion documentaire intelligente combinant le NAS Synology, le LLM_Local (OCR + classification), une base vectorielle (RAG) pour la recherche sémantique, et un pipeline de tri automatique du dossier Scan
- LiteLLM : Proxy LLM open-source exposant une API compatible OpenAI, hébergé sur infra-mgmt (port 4000), responsable du routage intelligent des requêtes IA entre backends locaux et cloud selon la sensibilité, la complexité et le budget
- Routeur_IA : Module logique englobant LiteLLM + les règles de routage (local/gratuit/payant) + le suivi des coûts + les alertes budget. Point d'entrée unique pour toutes les requêtes IA de l'infrastructure
- Validation_Webhook : Mécanisme de boucle de feedback humain via email : un workflow propose une action avec des boutons cliquables (liens webhook N8N), l'administrateur approuve/refuse d'un clic, le workflow exécute ou annule l'action
User Story : En tant qu'administrateur, je veux une documentation complète et à jour de mon infrastructure, afin de comprendre facilement l'état actuel et de faciliter la maintenance.
- THE Système_Documentation SHALL générer un inventaire de toutes les VMs, LXCs, conteneurs Docker, services applicatifs et équipements réseau en incluant pour chaque entrée : le nom, l'adresse IP, le port d'écoute, le rôle fonctionnel, les dépendances (services ou équipements dont l'entrée dépend pour fonctionner), et le statut de sauvegarde (parmi : « sauvegardé », « non sauvegardé », « exclu »)
- WHEN un nouveau service, une nouvelle VM ou un nouveau LXC est créé ou supprimé sur l'infrastructure, THE Système_Documentation SHALL mettre à jour l'inventaire dans un délai maximum de 5 minutes en ajoutant ou retirant l'entrée correspondante
- THE Système_Documentation SHALL stocker la documentation dans des fichiers au format Markdown ou YAML dans un dépôt Git versionné
- WHEN l'utilisateur consulte la documentation, THE Système_Documentation SHALL afficher la date et l'heure (au format ISO 8601) de dernière mise à jour de chaque entrée
- IF le Système_Documentation ne parvient pas à détecter ou interroger un service ou équipement lors d'un cycle de mise à jour, THEN THE Système_Documentation SHALL conserver la dernière entrée connue, marquer son statut comme « injoignable » et enregistrer la date de la dernière détection réussie
- THE Système_Documentation SHALL supporter un inventaire d'au minimum 50 entrées sans dégradation du délai de mise à jour de 5 minutes
User Story : En tant qu'administrateur, je veux visualiser la topologie de mon réseau avec tous les équipements et leurs adresses IP, afin d'avoir une vue d'ensemble claire et fluide.
- THE Système_Topologie SHALL afficher une carte visuelle de tous les équipements connectés au réseau (jusqu'à 50 équipements) avec possibilité de zoom, de déplacement panoramique et de clic sur chaque nœud, avec un temps de rendu initial inférieur à 3 secondes
- THE Système_Topologie SHALL afficher de manière persistante sur la carte, pour chaque équipement : le nom d'hôte, l'adresse IP et le type (VM, LXC, physique, réseau), et SHALL distinguer visuellement le statut actif (indicateur vert) du statut inactif (indicateur rouge)
- WHEN un nouvel équipement est détecté sur le réseau, THE Système_Topologie SHALL l'ajouter automatiquement à la carte dans un délai de 10 minutes
- THE Système_Topologie SHALL représenter les connexions entre les équipements sous forme de liens indiquant l'appartenance au même sous-réseau ou VLAN, et les dépendances de services configurées
- WHEN l'utilisateur survole un équipement sur la carte, THE Système_Topologie SHALL afficher dans un délai inférieur à 500 ms un panneau contextuel contenant : le nom d'hôte, l'adresse IP, l'adresse MAC, le type d'équipement, le statut actif/inactif, et la durée depuis le dernier changement de statut
- THE Système_Topologie SHALL rafraîchir le statut (actif/inactif) de chaque équipement au minimum toutes les 60 secondes
- IF un équipement précédemment actif ne répond plus lors du rafraîchissement, THEN THE Système_Topologie SHALL mettre à jour son indicateur de statut à inactif et SHALL conserver sa position sur la carte
User Story : En tant qu'administrateur, je veux me connecter à toutes mes VMs et LXCs avec une clé SSH privée unique, afin de simplifier et sécuriser l'accès.
- THE Système_Accès SHALL déployer une clé publique SSH sur le compte root de toutes les VMs et LXCs de l'infrastructure
- WHEN une nouvelle VM ou un nouveau LXC est créé, THE Système_Accès SHALL déployer automatiquement la clé publique SSH sur le compte root de la nouvelle machine dans un délai de 5 minutes et vérifier que la connexion SSH par clé est fonctionnelle
- THE Système_Accès SHALL désactiver l'authentification par mot de passe SSH sur toutes les machines gérées
- IF le déploiement de la clé SSH échoue sur une machine après 3 tentatives espacées de 2 minutes, THEN THE Système_Accès SHALL envoyer une alerte à l'administrateur avec le nom de la machine, l'adresse IP et la raison de l'échec
- THE Système_Accès SHALL maintenir un registre des machines sur lesquelles la clé est déployée incluant le nom de la machine, l'adresse IP, le statut de déploiement (succès/échec/en attente) et la date du dernier déploiement
- IF une machine gérée est temporairement injoignable lors du déploiement, THEN THE Système_Accès SHALL marquer la machine avec le statut "en attente" dans le registre et retenter le déploiement toutes les 10 minutes pendant 24 heures
User Story : En tant qu'administrateur, je veux un monitoring centralisé de toute mon infrastructure, afin de savoir en temps réel ce qui fonctionne, ce qui est en panne et l'utilisation des ressources.
- THE Système_Monitoring SHALL collecter les métriques de CPU (pourcentage d'utilisation), RAM (pourcentage d'utilisation), disque (pourcentage d'espace utilisé) et réseau (débit entrant et sortant en octets/seconde) de toutes les VMs, LXCs et hôtes physiques à une fréquence maximale de 30 secondes entre chaque collecte
- THE Système_Monitoring SHALL vérifier la disponibilité de chaque service toutes les 60 secondes en confirmant qu'une connexion réseau au port principal du service est établie et qu'une réponse valide est reçue dans un délai de 10 secondes
- WHEN un service échoue à 2 vérifications de disponibilité consécutives, THE Système_Monitoring SHALL déclarer ce service indisponible dans un délai maximal de 120 secondes après le premier échec
- THE Système_Monitoring SHALL fournir un tableau de bord centralisé affichant le statut (actif, indisponible, dégradé) de tous les services et ressources, mis à jour au maximum toutes les 60 secondes
- THE Système_Monitoring SHALL conserver un historique des métriques pendant 30 jours minimum
- WHILE le Proxmox_Principal est en fonctionnement, THE Système_Monitoring SHALL surveiller l'utilisation GPU de la RTX 2060 (température en °C, mémoire utilisée en Mo, charge en pourcentage) à une fréquence maximale de 30 secondes entre chaque collecte
- IF une cible de monitoring (VM, LXC ou hôte physique) ne répond à aucune collecte de métriques pendant 5 minutes, THEN THE Système_Monitoring SHALL marquer cette cible comme « injoignable » sur le tableau de bord
User Story : En tant qu'administrateur, je veux recevoir des notifications par email lorsqu'un événement important se produit sur mon infrastructure, afin d'être informé rapidement des problèmes.
- WHEN le Système_Monitoring détecte qu'un service devient indisponible, THE Système_Alerte SHALL envoyer un email à l'administrateur dans un délai de 5 minutes suivant la détection
- WHEN l'utilisation CPU ou RAM d'une VM, d'un LXC ou d'un hôte physique surveillé par le Système_Monitoring dépasse 90% pendant plus de 5 minutes consécutives, THE Système_Alerte SHALL envoyer un email d'avertissement
- WHEN l'espace disque disponible sur une partition surveillée d'une machine passe en dessous de 10% de la capacité totale de cette partition, THE Système_Alerte SHALL envoyer un email d'avertissement
- IF une sauvegarde Proxmox échoue, THEN THE Système_Alerte SHALL envoyer un email avec le nom de la VM/LXC concernée et le message d'erreur
- THE Système_Alerte SHALL inclure dans chaque email : le nom du service ou de la machine concernée, la nature de l'événement, l'horodatage au format ISO 8601 et la sévérité (critique, avertissement, information)
- THE Système_Alerte SHALL regrouper les alertes répétitives par combinaison unique de type d'événement et de machine source, en envoyant au maximum une alerte par combinaison par période de 15 minutes
- WHEN un événement ayant déclenché une alerte de sévérité critique ou avertissement revient à un état normal, THE Système_Alerte SHALL envoyer un email de résolution indiquant le nom de la machine, la nature de l'événement résolu et la durée totale de l'incident
- IF l'envoi d'un email d'alerte échoue, THEN THE Système_Alerte SHALL réessayer l'envoi 3 fois avec un intervalle de 60 secondes entre chaque tentative et journaliser l'échec si toutes les tentatives échouent
User Story : En tant qu'administrateur, je veux que mon IA locale soit le cerveau central de mon infrastructure — elle filtre les alertes, analyse mes emails, résume les événements, et ne me sollicite que pour les décisions importantes — afin de gagner du temps et de ne recevoir que de l'information pertinente et actionnable.
- THE Système_Automatisation SHALL router les requêtes d'IA vers le LLM_Local par défaut pour toutes les tâches d'automatisation
- WHEN le LLM_Local ne parvient pas à traiter une requête (timeout de 60 secondes ou réponse vide/tronquée de moins de 20 caractères), THE Système_Automatisation SHALL escalader la requête vers Claude via l'API
- THE Système_Automatisation SHALL journaliser chaque appel API Claude avec la date, le motif de l'escalade et le coût estimé
- THE Système_Automatisation SHALL exécuter quotidiennement les workflows N8N de maintenance suivants : vérification de l'état des sauvegardes, nettoyage des logs datant de plus de 30 jours, et redémarrage des services détectés comme indisponibles par le Système_Monitoring
- WHEN Home_Assistant détecte un événement domotique configuré, THE Système_Automatisation SHALL déclencher le workflow N8N correspondant dans un délai de 30 secondes
- THE Système_Automatisation SHALL fournir un rapport hebdomadaire incluant le nombre d'appels LLM_Local, le nombre d'appels API Claude, le taux de succès de chaque fournisseur et le coût total estimé des appels Claude
- IF le LLM_Local et l'API Claude sont tous deux indisponibles, THEN THE Système_Automatisation SHALL mettre la requête en file d'attente, envoyer une alerte à l'administrateur et réessayer automatiquement toutes les 5 minutes pendant un maximum de 1 heure
- WHEN une alerte Prometheus ou Uptime Kuma est déclenchée, THE Système_Automatisation SHALL soumettre l'alerte au LLM_Local pour évaluation AVANT d'envoyer une notification à l'administrateur. Le LLM SHALL classifier l'alerte selon : « action requise » (notification immédiate), « information » (inclure dans le résumé quotidien), ou « bruit » (ignorer et journaliser)
- THE Système_Automatisation SHALL formater les notifications « action requise » de manière lisible et actionnable : résumé en une phrase, machine concernée, action recommandée par l'IA, et un bouton/lien de résolution rapide (webhook N8N) quand une action automatisée est disponible
- THE Système_Automatisation SHALL produire un résumé quotidien envoyé par email (06h00) regroupant : toutes les alertes « information » des dernières 24h, l'état global de l'infra, les tâches IA exécutées pendant la nuit, et les éventuelles anomalies détectées
- THE Système_Automatisation SHALL planifier les tâches IA lourdes (indexation de documents, analyse de photos, nettoyage emails en masse, rapports) pendant les heures creuses (22h-06h par défaut) afin de minimiser la charge sur le GPU et la consommation électrique
- THE Système_Automatisation SHALL maintenir une file d'attente de tâches IA avec priorités : « urgent » (traité immédiatement même en journée), « normal » (traité aux heures creuses), « batch » (traité quand le GPU est libre depuis > 10 minutes)
- THE Système_Automatisation SHALL monitorer la charge GPU (via nvidia-smi) et ne lancer une tâche de la file d'attente que si la VRAM disponible est suffisante pour le modèle requis (seuil configurable, par défaut : 1 Go libre minimum)
- IF une tâche IA ne peut pas être traitée par le GPU (VRAM insuffisante ou GPU occupé), THEN THE Système_Automatisation SHALL évaluer si la tâche peut être exécutée en mode CPU-only (modèles légers type phi-3-mini ou gemma-2b) et la basculer si acceptable, sinon la remettre en file d'attente
- THE Système_Automatisation SHALL permettre à Home_Assistant d'envoyer des demandes de décision au LLM_Local via webhook N8N (ex: "Il fait 28°C dans le salon, dois-je fermer les volets ?") et SHALL retourner une décision avec justification dans un délai de 30 secondes
- THE Système_Automatisation SHALL apprendre les préférences de l'administrateur au fil du temps en journalisant les décisions validées/rejetées et en les utilisant comme contexte pour les futures décisions similaires
User Story : En tant qu'administrateur, je veux une gestion fiable et documentée des sauvegardes, afin de garantir la récupération de mes données en cas de problème.
- THE Système_Monitoring SHALL vérifier toutes les 24 heures que chaque VM et LXC dispose d'une sauvegarde de moins de 24 heures sur Proxmox_Backup
- IF une sauvegarde est absente ou date de plus de 24 heures, THEN THE Système_Alerte SHALL envoyer un email à l'administrateur indiquant le nom de la VM/LXC concernée et l'âge de la dernière sauvegarde connue
- THE Système_Documentation SHALL maintenir un registre des politiques de sauvegarde pour chaque VM et LXC, incluant : la fréquence de sauvegarde, la durée de rétention en jours, la destination, et le marquage critique (oui/non)
- WHILE le Proxmox_Secondaire est disponible, THE Système_Automatisation SHALL synchroniser les sauvegardes des VMs et LXCs marquées comme critiques dans le registre vers le Proxmox_Secondaire une fois par jour
- THE Système_Monitoring SHALL mesurer l'espace disque disponible sur Proxmox_Backup toutes les 60 minutes
- WHEN l'espace disque disponible sur Proxmox_Backup passe en dessous de 20%, THE Système_Alerte SHALL envoyer un email à l'administrateur indiquant le pourcentage d'espace restant et la taille totale du volume
- THE Système_Monitoring SHALL vérifier l'intégrité d'au moins une sauvegarde par semaine en exécutant un test de vérification et SHALL consigner le résultat (succès ou échec) dans le registre de sauvegardes
User Story : En tant qu'administrateur, je veux un réseau bien structuré et documenté avec des VLANs et des règles de pare-feu claires, afin d'améliorer la sécurité et la maintenabilité.
- THE Système_Réseau SHALL segmenter le réseau en 4 VLANs distincts (services, gestion, IoT/domotique, invités) avec une politique par défaut de blocage de tout trafic inter-VLAN sauf exceptions explicitement configurées dans les règles de pare-feu pfSense
- THE Système_Documentation SHALL documenter chaque VLAN avec son identifiant VLAN, son sous-réseau, sa plage DHCP, ses règles de pare-feu associées et la liste des flux inter-VLAN autorisés
- THE Système_Réseau SHALL attribuer des adresses IP statiques via réservation DHCP pfSense à tous les serveurs Proxmox, au pare-feu pfSense, aux switches, à Home_Assistant et à tous les conteneurs et VMs hébergeant des services
- IF un conflit d'adresse IP est détecté sur le réseau, THEN THE Système_Réseau SHALL rejeter la nouvelle attribution et THE Système_Alerte SHALL notifier l'administrateur avec les deux équipements en conflit et l'adresse concernée
- THE Système_Documentation SHALL maintenir un plan d'adressage IP couvrant tous les équipements à IP statique et le mettre à jour dans un délai de 24 heures suivant toute modification d'attribution
- WHEN une modification de règle pare-feu est effectuée sur pfSense, THE Système_Documentation SHALL enregistrer la modification avec la date, l'auteur et la justification dans un délai de 48 heures suivant la modification
- THE Système_Réseau SHALL interdire tout accès initié depuis le VLAN invités vers les VLANs services et gestion, et limiter le VLAN IoT/domotique à communiquer uniquement avec Home_Assistant sur le VLAN services
User Story : En tant qu'administrateur et parent, je veux que mes enfants puissent demander l'accès à certains services (jeux, sites) via un système de codes par email, afin de contrôler leur usage tout en leur donnant de l'autonomie.
- THE Système_Parental SHALL maintenir une liste de profils utilisateurs (enfants) avec pour chacun : un nom, une adresse email, une adresse IP ou MAC associée, et une liste de codes d'autorisation valides avec les services associés à chaque code
- WHEN un email est reçu sur l'adresse dédiée (ex: acces@mondomaine.fr) contenant un code d'autorisation valide, THE Système_Parental SHALL vérifier l'expéditeur, le code et le service demandé dans un délai de 5 minutes
- IF le code est valide et l'expéditeur est reconnu, THEN THE Système_Parental SHALL créer automatiquement via l'API pfSense une règle de pare-feu autorisant le trafic depuis l'IP de l'utilisateur vers les serveurs du service demandé, et SHALL créer une exception dans AdGuard pour les domaines associés au service
- THE Système_Parental SHALL appliquer une durée d'accès par défaut de 2 heures à chaque autorisation, configurable par profil et par service
- WHEN la durée d'accès expire, THE Système_Parental SHALL supprimer automatiquement la règle pfSense et réactiver le blocage AdGuard pour les domaines concernés
- THE Système_Parental SHALL envoyer un email de confirmation à l'administrateur à chaque ouverture et fermeture d'accès, incluant : le nom de l'utilisateur, le service, l'heure d'ouverture et la durée accordée
- IF un code invalide ou un expéditeur non reconnu est détecté, THEN THE Système_Parental SHALL ignorer la demande et envoyer une alerte à l'administrateur avec les détails de la tentative
- THE Système_Parental SHALL journaliser toutes les demandes (acceptées et refusées) avec horodatage, expéditeur, code utilisé et résultat dans un log consultable
User Story : En tant qu'administrateur, je veux que mon IA locale prenne en charge ma boîte mail — qu'elle range les emails existants, classe les nouveaux, extraie les factures, et m'aide à garder une inbox propre — afin de gagner du temps et de ne rien perdre.
- THE Système_Mail SHALL se connecter en IMAP au serveur mail HestiaCP et scanner les nouveaux emails toutes les 5 minutes
- THE Système_Mail SHALL classifier chaque email entrant dans une catégorie parmi : facture, notification infrastructure, personnel, commercial/newsletter, spam, autre — en utilisant le LLM_Local pour analyser l'expéditeur, le sujet et le contenu
- WHEN un email est classifié comme "facture", THE Système_Mail SHALL extraire la pièce jointe PDF, la renommer selon le format "AAAA-MM-[Fournisseur]-facture.pdf" et la stocker dans un dossier organisé par année et par fournisseur
- THE Système_Mail SHALL déplacer chaque email classifié dans le dossier IMAP correspondant à sa catégorie (Factures, Infra, Personnel, Commercial, Spam)
- IF un email classifié comme "facture" ne contient pas de pièce jointe PDF, THEN THE Système_Mail SHALL tenter d'extraire le contenu de la facture depuis le corps de l'email et le convertir en PDF
- THE Système_Mail SHALL maintenir un registre des factures extraites avec : la date, le fournisseur, le montant (si détectable), le chemin du fichier et le statut de traitement
- THE Système_Mail SHALL marquer les emails importants (factures, alertes infra) avec un flag "important" et les inclure dans une sauvegarde dédiée hebdomadaire
- THE Système_Mail SHALL fournir un rapport mensuel listant toutes les factures reçues avec les montants détectés et les éventuels échecs de traitement
- THE Système_Mail SHALL effectuer un rangement initial de toute la boîte mail existante (INBOX + dossiers en vrac) lors de la première activation, en classifiant chaque email selon les mêmes catégories que les nouveaux emails, en mode batch heures creuses (exigence 6.C)
- THE Système_Mail SHALL identifier et regrouper les newsletters/emails commerciaux récurrents et proposer des règles de tri automatique (dossier ou suppression) à valider par l'administrateur
- THE Système_Mail SHALL produire un résumé quotidien des emails reçus (catégories, volume, éléments nécessitant attention) intégré au résumé quotidien de l'IA (exigence 6.B.10)
- THE Système_Mail SHALL apprendre des corrections de l'administrateur : si un email est manuellement déplacé vers un autre dossier, le système ajuste ses règles de classification pour les futurs emails similaires
User Story : En tant qu'administrateur, je veux utiliser mon propre domaine pour envoyer et recevoir des emails (notifications infra, échanges personnels, système de codes parental), afin d'être indépendant des services tiers.
- THE Système_Mail SHALL envoyer les emails de notification d'infrastructure via le serveur SMTP de HestiaCP en utilisant le domaine personnalisé de l'administrateur
- THE Système_Mail SHALL configurer correctement les enregistrements DNS suivants pour garantir la délivrabilité : SPF, DKIM et DMARC
- WHEN un email est envoyé par le système, THE Système_Mail SHALL utiliser une adresse expéditeur cohérente avec le type de notification (ex: alertes@mondomaine.fr, acces@mondomaine.fr, rapports@mondomaine.fr)
- THE Système_Mail SHALL supporter la réception d'emails sur plusieurs adresses du domaine et les router vers les workflows N8N appropriés (alertes, demandes d'accès parental, personnel)
- IF le serveur HestiaCP est indisponible pour l'envoi, THEN THE Système_Alerte SHALL basculer temporairement sur un relay SMTP de secours (Gmail/Brevo) et journaliser l'incident
- THE Système_Monitoring SHALL vérifier la disponibilité du service mail HestiaCP (SMTP port 25/587, IMAP port 993) toutes les 60 secondes et alerter en cas d'indisponibilité
User Story : En tant qu'administrateur, je veux pouvoir reconstruire l'intégralité de mon infrastructure à partir de zéro en quelques heures si mon serveur principal est détruit, afin de garantir la continuité de mes services.
- THE Système_Recovery SHALL stocker la totalité de la configuration d'infrastructure sous forme de code (Infrastructure-as-Code) dans un dépôt Git (GitHub phase 1, GitLab_Local phase 2), incluant : tous les playbooks Ansible, les fichiers docker-compose, les configurations des services, et les workflows N8N exportés
- THE Système_Recovery SHALL exporter automatiquement chaque semaine les configurations critiques suivantes vers le dépôt Git : backup XML de pfSense (via API), export YAML d'AdGuard, export JSON des workflows N8N, et snapshot de la configuration NetBox
- THE Système_Recovery SHALL permettre la reconstruction complète de l'infrastructure sur un nouveau serveur Proxmox en exécutant au maximum 5 commandes manuelles (installation Proxmox + clone Git + 3 playbooks Ansible maximum)
- THE Système_Recovery SHALL documenter une procédure de reprise pas-à-pas testée, avec un objectif de temps de reprise (RTO) de 4 heures pour les services critiques et 8 heures pour l'ensemble de l'infrastructure
- THE Système_Recovery SHALL synchroniser les sauvegardes PBS critiques vers le Proxmox_Secondaire quotidiennement ET maintenir une copie offsite chiffrée des configurations (pas des données volumineuses) sur un stockage externe (cloud chiffré ou disque USB rotatif)
- THE Système_Recovery SHALL vérifier trimestriellement la capacité de reprise en exécutant un test de restauration d'au moins une VM critique depuis les backups PBS et en validant que les playbooks Ansible s'exécutent sans erreur en mode dry-run sur une VM de test
- IF le Proxmox_Principal est indisponible pendant plus de 30 minutes, THEN THE Système_Recovery SHALL envoyer une alerte à l'administrateur avec les instructions de reprise et le statut des dernières sauvegardes disponibles
User Story : En tant qu'administrateur, je veux versionner toute ma configuration d'infrastructure dans Git et évoluer vers un déploiement automatisé via CI/CD, afin de tracer chaque modification et d'automatiser les déploiements.
- THE Système_Documentation SHALL versionner dans un dépôt GitHub privé (phase 1) l'ensemble des fichiers de configuration : playbooks Ansible, inventaire, docker-compose, configs exportées, documentation et procédures
- WHEN une modification de configuration est appliquée sur l'infrastructure via Ansible, THE Système_Documentation SHALL créer un commit Git décrivant la modification avec la date, l'auteur et le motif
- THE Système_Automatisation SHALL migrer le dépôt vers une instance GitLab_Local self-hosted (phase 2) lorsque l'infrastructure de base est stable, en configurant un miroir de GitHub vers GitLab_Local
- WHEN le dépôt est migré vers GitLab_Local, THE Système_Automatisation SHALL configurer un pipeline CI/CD GitLab Runner qui exécute automatiquement les playbooks Ansible à chaque commit sur la branche principale, après validation en mode dry-run
- THE Système_Documentation SHALL maintenir un fichier CHANGELOG.md mis à jour automatiquement à chaque modification d'infrastructure avec le résumé des changements
- IF un pipeline CI/CD échoue, THEN THE Système_Alerte SHALL notifier l'administrateur avec le nom du playbook en échec, le message d'erreur et un lien vers les logs
- THE Système_Recovery SHALL configurer un miroir automatique GitLab_Local → GitHub (push mirror) pour garantir qu'une copie du code existe toujours en dehors de l'infrastructure locale
User Story : En tant qu'administrateur, je veux que toutes mes VMs, LXCs, conteneurs Docker et l'hyperviseur Proxmox soient mis à jour automatiquement avec un contrôle d'erreur ultra-précis — incluant la vérification de compatibilité des drivers GPU, le respect d'un ordre d'exécution qui ne casse pas le pipeline d'automatisation, et l'utilisation du Proxmox secondaire (NUC) comme tampon de sécurité — afin de garantir la stabilité à 100% avant, pendant et après chaque mise à jour.
- Proxmox principal (pve-main) : ancien PC gamer avec GPU RTX 2060 en passthrough. Drivers NVIDIA installés directement sur l'hôte Proxmox (DKMS). Un changement de kernel peut casser le module nvidia.
- Proxmox secondaire (pve-nuc) : NUC avec PBS. Peut servir de Proxmox tampon pour héberger temporairement des VMs critiques pendant la mise à jour de pve-main.
- VMs pilotes : N8N (orchestration) et Ansible (exécution) tournent sur pve-main. Elles doivent être mises à jour EN DERNIER car elles pilotent le processus de mise à jour des autres machines.
-
THE Système_Maintenance SHALL respecter un ordre de mise à jour strict organisé en 4 vagues séquentielles, où chaque vague ne démarre que si la précédente est entièrement validée :
- Vague 1 — Machines non-critiques : vm-workertest, vm-csgo2, vm-admin, guillaume-trading
- Vague 2 — Services applicatifs : vm-jitsi, vm-homeassistant, vm-adguard, lxc-llm, wireguard
- Vague 3 — Infrastructure critique : nginx-proxy-manager, vm-hestiacp
- Vague 4 — Pilotes d'automatisation : vm-rustdesk-n8n (N8N + Ansible)
- Vague 5 — Hyperviseur : pve-main (Proxmox + kernel + drivers GPU)
-
THE Système_Maintenance SHALL ne JAMAIS mettre à jour une machine de la Vague N+1 tant que toutes les machines de la Vague N n'ont pas été mises à jour ET validées avec succès
-
IF une machine d'une vague échoue à la validation post-update, THEN THE Système_Maintenance SHALL interrompre le cycle complet (ne pas passer aux vagues suivantes), effectuer le rollback de la machine en échec, et envoyer une alerte critique à l'administrateur avec le détail de l'échec et la liste des machines restantes non mises à jour
-
THE Système_Maintenance SHALL traiter la Vague 4 (N8N/Ansible) avec une précaution spéciale : BEFORE de mettre à jour vm-rustdesk-n8n, THE Système_Maintenance SHALL vérifier que tous les workflows N8N en cours sont terminés, sauvegarder l'export JSON des workflows, et créer un snapshot complet (pas incrémental)
-
BEFORE chaque cycle de mise à jour, THE Système_Maintenance SHALL exécuter une phase d'analyse pré-update sur chaque machine consistant à :
- Lister les packages à mettre à jour (
apt list --upgradable)
- Classifier chaque package : sécurité critique, sécurité normale, fonctionnelle, kernel, driver, optionnelle
- Identifier les packages à risque : tout package touchant au kernel, aux modules DKMS, à systemd, à grub, aux drivers GPU, ou à la stack réseau
-
IF des packages à risque sont détectés sur une machine, THEN THE Système_Maintenance SHALL interroger les sources de compatibilité suivantes AVANT d'appliquer la mise à jour :
- Pour les updates kernel : vérifier la compatibilité avec les modules DKMS installés sur cette machine (
dkms status → le module se recompile-t-il avec le kernel cible ?)
- Pour les updates Proxmox VE : consulter les release notes Proxmox (API forum ou page wiki) pour détecter des breaking changes connus
- Pour les updates Docker : vérifier que les images Docker utilisées sont compatibles avec la nouvelle version du runtime Docker
-
THE Système_Maintenance SHALL soumettre le résultat de l'analyse pré-update au LLM_Local (Ollama) avec le prompt suivant : "Voici la liste des packages à mettre à jour sur [machine], avec la classification de risque et les résultats de compatibilité. Y a-t-il un risque de régression ? Recommandation : GO / HOLD / REVIEW MANUELLE." et SHALL utiliser la réponse comme aide à la décision
-
IF le LLM_Local recommande HOLD ou REVIEW MANUELLE, THEN THE Système_Maintenance SHALL bloquer la mise à jour de cette machine, envoyer un rapport détaillé à l'administrateur par email (via rapports@scijoly.fr) avec les packages concernés, la raison du blocage et la recommandation du LLM, et attendre une validation explicite de l'administrateur
¶ 14.C — Contrôle spécifique GPU/NVIDIA pour Proxmox principal (pve-main)
-
BEFORE toute mise à jour de pve-main impliquant un changement de kernel, THE Système_Maintenance SHALL exécuter les vérifications suivantes dans cet ordre :
- Récupérer la version du driver NVIDIA actuellement installé (
nvidia-smi --query-gpu=driver_version --format=csv,noheader)
- Récupérer la version du kernel cible (depuis le package linux-image à installer)
- Consulter la matrice de compatibilité NVIDIA (https://download.nvidia.com/XFree86/Linux-x86_64/) pour vérifier que la version du driver supporte le kernel cible
- Vérifier que le module DKMS nvidia se compile avec le kernel cible (
dkms build nvidia/<version> -k <kernel_cible> en dry-run si possible)
- Vérifier l'existence d'une version plus récente du driver NVIDIA compatible avec le kernel cible
-
IF la vérification de compatibilité GPU/kernel échoue ou est incertaine, THEN THE Système_Maintenance SHALL :
- BLOQUER la mise à jour kernel de pve-main
- Envoyer une alerte critique à l'administrateur avec : la version kernel actuelle, la version kernel cible, la version driver NVIDIA, le résultat du check de compatibilité, et une recommandation (mettre à jour le driver d'abord / attendre un patch / forcer avec risque)
- NE JAMAIS appliquer un changement de kernel sans confirmation de compatibilité NVIDIA
-
AFTER toute mise à jour de pve-main impliquant un reboot, THE Système_Maintenance SHALL vérifier dans cet ordre :
- Le serveur Proxmox est joignable (ping + API Proxmox port 8006)
- Le module nvidia est chargé (
lsmod | grep nvidia retourne des résultats)
nvidia-smi retourne un résultat valide (pas d'erreur)- Le GPU est visible dans Proxmox (
qm monitor <vmid> info pci ou vérification passthrough)
- Le LXC LLM (ID 113) démarre et le GPU est accessible depuis l'intérieur
- Ollama répond sur le port 11434 (
curl http://192.168.202.14:11434/api/tags)
-
IF une des vérifications GPU post-update échoue, THEN THE Système_Maintenance SHALL immédiatement restaurer le snapshot de pve-main (rollback kernel), envoyer une alerte critique, et redémarrer le LXC LLM une fois le rollback effectué pour vérifier la restauration du GPU passthrough
-
BEFORE de mettre à jour l'hyperviseur pve-main (Vague 5), THE Système_Maintenance SHALL migrer temporairement les VMs critiques de la Vague 3 (nginx-proxy-manager, vm-hestiacp) vers le Proxmox secondaire (pve-nuc) via une migration offline (backup PBS → restore sur NUC), afin de garantir la continuité des services pendant la mise à jour de l'hyperviseur
-
THE Système_Maintenance SHALL vérifier AVANT la migration tampon que :
- Le Proxmox secondaire (NUC) dispose de suffisamment de RAM et disque pour accueillir les VMs à migrer
- Les VMs migrées sont fonctionnelles sur le NUC (check de ports et services) avant de procéder à la mise à jour de pve-main
- Le réseau 150 entre pve-main et pve-nuc est opérationnel
-
AFTER la mise à jour réussie de pve-main ET la validation complète (incluant GPU), THE Système_Maintenance SHALL re-migrer les VMs tampons depuis le NUC vers pve-main et vérifier leur bon fonctionnement, puis nettoyer les copies sur le NUC
-
IF la mise à jour de pve-main échoue et nécessite un rollback prolongé (> 30 minutes), THEN THE Système_Maintenance SHALL maintenir les VMs critiques en fonctionnement sur le NUC et alerter l'administrateur que le mode tampon est actif, avec les limitations de performance associées (NUC moins puissant)
-
BEFORE chaque mise à jour d'une VM ou d'un LXC, THE Système_Maintenance SHALL créer un snapshot Proxmox de la machine concernée OU déclencher un backup incrémental vers Proxmox_Backup si le snapshot n'est pas supporté (ex: disques en ZFS sans thin provisioning)
-
THE Système_Maintenance SHALL vérifier que le snapshot ou le backup a été créé avec succès BEFORE de lancer la mise à jour ; IF la création échoue, THEN la mise à jour de cette machine SHALL être annulée et une alerte SHALL être envoyée à l'administrateur
-
THE Système_Maintenance SHALL exécuter les mises à jour système (apt upgrade) sur chaque VM et LXC, puis redémarrer automatiquement la machine UNIQUEMENT si un redémarrage est requis (vérification de /var/run/reboot-required)
-
AFTER le redémarrage (ou après l'update si pas de reboot nécessaire), THE Système_Maintenance SHALL exécuter les vérifications post-update spécifiques à chaque machine selon son profil :
- Toutes les machines : joignabilité (ping + SSH dans les 5 minutes)
- Machines avec services web : check HTTP sur le port principal (réponse 200/301/302)
- Machines Docker :
docker ps retourne tous les conteneurs attendus en statut "running"
- vm-rustdesk-n8n : N8N accessible sur port 5678 + tous les conteneurs Docker up
- lxc-llm :
nvidia-smi fonctionne + Ollama répond sur 11434
- vm-hestiacp : SMTP port 587 + IMAP port 993 opérationnels
- nginx-proxy-manager : au moins 1 proxy host répond correctement (test d'un sous-domaine)
- vm-adguard : résolution DNS fonctionne (
dig @192.168.202.24 google.com)
- wireguard : interface wg0 up + handshake récent sur au moins 1 peer
-
IF une machine ne passe pas ses vérifications post-update dans un délai de 5 minutes, THEN THE Système_Maintenance SHALL restaurer automatiquement le snapshot Proxmox (rollback) et envoyer une alerte critique à l'administrateur avec : le nom de la machine, les vérifications échouées, les logs pertinents (dernières 50 lignes de journalctl)
-
WHEN la mise à jour et toutes les vérifications post-update sont réussies, THE Système_Maintenance SHALL supprimer le snapshot de sécurité (rétention maximum : 48h)
-
THE Système_Maintenance SHALL mettre à jour les conteneurs Docker (docker-compose pull + docker-compose up -d) sur chaque machine Docker APRÈS avoir mis à jour l'OS hôte et vérifié sa stabilité, en créant un snapshot de la VM/LXC hôte AVANT le pull Docker
-
BEFORE un docker-compose pull, THE Système_Maintenance SHALL comparer les digests des images actuelles avec les images disponibles et ne procéder au pull que si des mises à jour existent réellement (éviter les redémarrages inutiles)
-
AFTER un docker-compose up -d, THE Système_Maintenance SHALL vérifier que tous les conteneurs sont en état "running" (pas "restarting" ou "exited") pendant au moins 2 minutes consécutives avant de considérer la mise à jour Docker comme réussie
-
THE Système_Maintenance SHALL journaliser chaque cycle de mise à jour avec : la date, la vague, la machine concernée, les packages mis à jour (nom + version avant → version après), le résultat (succès/échec/rollback/bloqué), la durée totale du cycle, et le résultat de chaque vérification post-update
-
THE Système_Maintenance SHALL fournir un rapport hebdomadaire de maintenance envoyé par email (rapports@scijoly.fr) incluant :
- Résumé par vague : machines mises à jour, packages concernés, redémarrages effectués
- Rollbacks éventuels avec la cause identifiée
- Machines bloquées (HOLD) avec la raison et la recommandation
- État de compatibilité GPU si un check kernel a été effectué
- Prochaine fenêtre de maintenance planifiée
- Espace disque PBS consommé par les snapshots de sécurité
-
THE Système_Maintenance SHALL permettre d'exclure certaines machines ou certains packages du cycle automatique via une liste d'exclusions configurable dans group_vars/all.yml, avec la possibilité de hold temporaire (date d'expiration) ou permanent
¶ 14.H — Fenêtre de maintenance et déclenchement
-
THE Système_Maintenance SHALL exécuter le cycle complet de mise à jour pendant une fenêtre de maintenance configurable (par défaut : dimanche 3h du matin), déclenchée par un workflow N8N (cron)
-
THE Système_Maintenance SHALL estimer la durée totale du cycle avant de commencer (basée sur le nombre de packages et machines) et SHALL alerter l'administrateur si la durée estimée dépasse la fenêtre de maintenance
-
THE Système_Maintenance SHALL supporter un mode "dry-run" permettant d'exécuter toute la phase d'analyse et de compatibilité sans appliquer aucune mise à jour, et d'envoyer le rapport de ce qui SERAIT fait — utilisable pour valider manuellement avant un cycle réel
-
THE Système_Maintenance SHALL configurer un service watchdog sur le Proxmox secondaire (pve-nuc) qui vérifie la disponibilité de pve-main (ping + API Proxmox port 8006) toutes les 60 secondes, indépendamment de N8N et d'Ansible (script cron ou systemd timer sur le NUC directement)
-
BEFORE toute mise à jour de pve-main impliquant un changement de kernel ou de driver NVIDIA, THE Système_Maintenance SHALL créer un backup complet du disque boot de pve-main (/dev/sdc, 256 Go) via dd compressé avec gzip et l'envoyer sur le NAS Synology (partage NFS dédié /backups/proxmox-os/) avec un nommage horodaté (pve-main-boot-AAAA-MM-JJ.img.gz). La rétention est de 3 images (rotation automatique).
-
THE Système_Maintenance SHALL maintenir en permanence une clé USB Clonezilla bootable branchée sur pve-main, pré-configurée pour restaurer automatiquement la dernière image du disque boot depuis le NAS Synology via NFS — de sorte que la seule intervention physique nécessaire soit de sélectionner le boot USB dans le BIOS
-
IF le watchdog sur pve-nuc détecte que pve-main est injoignable pendant plus de 10 minutes après un reboot planifié (fenêtre de maintenance), THEN le watchdog SHALL exécuter la séquence de failover suivante :
- Étape 1 : Tenter un Wake-on-LAN vers pve-main (3 tentatives espacées de 2 minutes)
- Étape 2 : Si toujours injoignable après WoL → démarrer les VMs critiques (nginx-proxy-manager, vm-hestiacp, vm-adguard) depuis les backups PBS sur le NUC
- Étape 3 : Envoyer une alerte CRITIQUE via un chemin indépendant de pve-main (relay SMTP externe direct depuis le NUC — Gmail App Password ou Ntfy.sh/Pushover en webhook)
- Étape 4 : Passer en mode dégradé et journaliser l'événement
-
THE Système_Maintenance SHALL configurer un chemin d'alerte secondaire indépendant de pve-main pour le watchdog du NUC, utilisant au moins 2 canaux parmi : relay SMTP externe (Gmail), notification push (Ntfy.sh ou Pushover), webhook Telegram, ou notification DSM Synology. Ce chemin secondaire NE DOIT PAS dépendre d'une VM tournant sur pve-main.
-
IF pve-main revient en ligne après un failover (intervention manuelle : restauration Clonezilla ou fix du boot), THEN THE Système_Maintenance SHALL :
- Vérifier l'intégrité de pve-main (API Proxmox, nvidia-smi, ZFS pool status)
- Re-migrer les VMs critiques depuis le NUC vers pve-main
- Vérifier le bon fonctionnement de chaque VM re-migrée
- Envoyer un rapport de fin de failover à l'administrateur
- Nettoyer les copies temporaires sur le NUC
-
THE Système_Maintenance SHALL documenter la configuration BIOS requise pour pve-main (ordre de boot : SSD → USB → PXE) et SHALL vérifier trimestriellement que la clé USB Clonezilla est fonctionnelle et que l'image de restauration sur le NAS est accessible
- THE Système_Maintenance SHALL garantir que le watchdog (pve-nuc) et le chemin d'alerte secondaire fonctionnent de manière autonome avec ZÉRO dépendance sur pve-main, selon le schéma suivant :
- Watchdog : script/systemd sur pve-nuc → ping pve-main → si down → alerte + failover
- Alerte : pve-nuc → pfSense (réseau 150) → Internet → relay SMTP externe / webhook push
- Failover : pve-nuc → PBS local (192.168.150.10) → restore VMs critiques sur pve-nuc
- Aucun de ces composants ne transite par une VM de pve-main
-
THE Système_Maintenance SHALL vérifier hebdomadairement si une mise à jour pfSense est disponible et SHALL envoyer une notification à l'administrateur incluant : la version actuelle, la version disponible, les release notes résumées, et un lien vers le changelog officiel
-
BEFORE toute mise à jour de pfSense (manuelle), THE Système_Maintenance SHALL automatiquement exporter la configuration XML complète via l'API REST (GET /api/v1/system/config), la stocker dans configs/pfsense/backup-AAAA-MM-JJ.xml du repo Git, et pousser vers GitHub. La notification de mise à jour disponible SHALL inclure la confirmation que le backup est fait et son emplacement.
-
THE Système_Maintenance SHALL NE PAS appliquer les mises à jour pfSense automatiquement — la mise à jour est manuelle mais le backup et la notification sont automatiques. L'administrateur applique la mise à jour via l'interface web pfSense.
-
THE Système_Maintenance SHALL mettre à jour le NUC UNIQUEMENT APRÈS que toute l'infrastructure principale (vagues 1-5) soit mise à jour et validée, car le NUC porte les backups de restauration
-
BEFORE de mettre à jour l'hyperviseur NUC (pve-nuc), THE Système_Maintenance SHALL d'abord mettre à jour la VM PBS (ID 100) hébergée sur le NUC, puis vérifier que PBS fonctionne toujours (datastores accessibles, derniers backups lisibles)
-
IF la mise à jour de la VM PBS échoue, THEN THE Système_Maintenance SHALL NE PAS procéder à la mise à jour de l'hyperviseur NUC et alerter l'administrateur
-
THE Système_Monitoring SHALL surveiller le NUC (pve-nuc) via Prometheus node_exporter, et SHALL alerter si le NUC est injoignable depuis plus de 5 minutes — car un watchdog mort est un faux sentiment de sécurité
-
THE Système_Maintenance SHALL configurer un healthcheck externe (service gratuit type UptimeRobot, Hetrixtools, ou cron vers un endpoint externe) qui vérifie que le NUC est vivant. Si le healthcheck échoue → notification push directe sur le téléphone de l'admin (indépendant de toute l'infra locale)
User Story : En tant qu'administrateur, je veux centraliser tous les logs de mes VMs, LXCs et conteneurs Docker en un seul endroit et savoir quand je peux faire une mise à jour en toute sécurité, afin de détecter les problèmes rapidement et planifier les maintenances au bon moment.
- THE Système_Monitoring SHALL collecter et centraliser les logs système (syslog, journald) de toutes les VMs et LXCs dans un système de stockage de logs centralisé avec une rétention configurable (par défaut 30 jours)
- THE Système_Monitoring SHALL collecter les logs des conteneurs Docker (stdout/stderr) de toutes les machines hébergeant des services Docker et les intégrer au système de logs centralisé
- THE Système_Monitoring SHALL fournir une interface de recherche permettant de filtrer les logs par machine, par service, par niveau de sévérité (error, warning, info, debug) et par plage de dates, avec un temps de réponse inférieur à 5 secondes pour les requêtes sur les 24 dernières heures
- THE Système_Automatisation SHALL évaluer quotidiennement la disponibilité de mises à jour sur chaque VM et LXC (apt list --upgradable ou équivalent) et SHALL classer les mises à jour en catégories : sécurité critique, sécurité normale, fonctionnelle, et optionnelle
- THE Système_Automatisation SHALL déterminer si une machine est éligible à une mise à jour automatique en vérifiant : aucune erreur critique dans les logs des dernières 24h, charge CPU < 50%, aucune tâche de backup en cours, et aucun flag d'exclusion dans l'inventaire
- IF des mises à jour de sécurité critiques sont disponibles sur une machine éligible, THEN THE Système_Automatisation SHALL les appliquer automatiquement lors de la prochaine fenêtre de maintenance (avec snapshot préalable selon Exigence 14)
- IF des mises à jour fonctionnelles ou optionnelles sont disponibles, THEN THE Système_Automatisation SHALL envoyer un rapport à l'administrateur listant les packages, la machine concernée et une recommandation (appliquer/attendre) basée sur l'analyse des logs et la stabilité de la machine
- THE Système_Automatisation SHALL permettre à l'administrateur de valider ou rejeter les mises à jour non-critiques via un email de réponse ou un bouton dans le rapport (workflow N8N)
- WHEN l'administrateur valide une mise à jour, THE Système_Automatisation SHALL planifier son application lors de la prochaine fenêtre de maintenance avec le flux snapshot → update → verify → rollback de l'Exigence 14
- THE Système_Monitoring SHALL générer une alerte si un pattern d'erreurs récurrentes est détecté dans les logs d'une machine (plus de 10 erreurs identiques en 1 heure) et SHALL recommander de reporter les mises à jour sur cette machine jusqu'à résolution
User Story : En tant qu'administrateur, je veux pouvoir démarrer automatiquement mes serveurs à distance via Wake-on-LAN depuis pfSense, afin de réduire la consommation électrique en éteignant les machines non critiques quand elles ne sont pas utilisées et de les rallumer à la demande.
- THE Système_Automatisation SHALL maintenir un registre des machines compatibles Wake-on-LAN avec pour chacune : le nom, l'adresse MAC, l'interface réseau pfSense associée, et le planning de fonctionnement (heures actives/veille)
- THE Système_Automatisation SHALL envoyer un paquet Magic Packet (WoL) via pfSense vers une machine cible dans un délai de 30 secondes suivant la demande de démarrage
- WHEN une machine WoL est programmée pour démarrer selon son planning de fonctionnement, THE Système_Automatisation SHALL envoyer automatiquement le Magic Packet à l'heure configurée et vérifier que la machine est joignable (ping + SSH) dans un délai de 5 minutes
- IF une machine WoL ne répond pas dans les 5 minutes suivant l'envoi du Magic Packet, THEN THE Système_Automatisation SHALL réessayer l'envoi 2 fois supplémentaires espacées de 2 minutes et envoyer une alerte à l'administrateur si toutes les tentatives échouent
- THE Système_Automatisation SHALL supporter le déclenchement WoL à la demande via : un workflow N8N déclenché par email (même système de codes que le contrôle parental), un webhook Home Assistant, ou une action manuelle dans le tableau de bord Grafana
- WHEN une machine WoL atteint la fin de sa période d'activité programmée ET qu'aucun utilisateur ou service actif n'est détecté, THE Système_Automatisation SHALL envoyer une commande d'extinction gracieuse (shutdown -h) via SSH et journaliser l'événement
- THE Système_Automatisation SHALL journaliser tous les événements WoL (démarrage, extinction, échecs) avec horodatage et SHALL inclure un résumé dans le rapport hebdomadaire de maintenance
User Story : En tant qu'administrateur, je veux que toute la documentation opérationnelle (tutoriels, runbooks, procédures de restauration) soit générée et maintenue automatiquement par l'IA à chaque changement d'infrastructure, afin de pouvoir reprendre le contrôle même si j'ai oublié les détails après des mois d'inactivité.
L'infrastructure est fortement automatisée. Si un incident survient dans 6 mois ou 1 an, l'administrateur risque d'avoir oublié les détails techniques. La documentation doit être :
- Générée automatiquement (pas de rédaction manuelle)
- Visuelle (schémas, étapes numérotées, captures de commandes attendues)
- Stockée dans le repo Git (GitHub privé, accessible même si l'infra est down)
- Mise à jour à chaque changement significatif
-
THE Système_Documentation SHALL générer automatiquement un runbook (guide pas-à-pas) pour chaque procédure critique de l'infrastructure, incluant au minimum :
- Restauration complète après sinistre (disaster recovery)
- Restauration de l'hyperviseur Proxmox (Clonezilla / réinstall + Ansible)
- Restauration d'une VM individuelle depuis PBS
- Procédure de failover vers le NUC (mode tampon)
- Rollback après mise à jour échouée
- Remplacement du driver NVIDIA après changement de kernel
- Ajout d'une nouvelle VM/LXC à l'infrastructure
- Restauration du serveur mail HestiaCP
- Reconfiguration pfSense depuis le backup XML
-
WHEN un playbook Ansible, un workflow N8N, ou une configuration système est modifié, THE Système_Documentation SHALL régénérer automatiquement les runbooks impactés en utilisant le LLM_Local (Ollama) pour produire un guide lisible par un humain non-expert à ce moment-là
-
THE Système_Documentation SHALL structurer chaque runbook avec :
- Un titre clair et la date de dernière génération
- Les prérequis (accès réseau, clé SSH, outils nécessaires)
- Les étapes numérotées avec les commandes exactes à copier-coller
- Le résultat attendu de chaque étape (quoi vérifier pour confirmer le succès)
- Les erreurs courantes et leur résolution
- Un schéma visuel du flux (diagramme Mermaid)
- Le temps estimé pour chaque étape
-
THE Système_Documentation SHALL stocker tous les runbooks dans le dossier docs/runbooks/ du dépôt Git au format Markdown avec diagrammes Mermaid intégrés, et SHALL les pousser automatiquement vers GitHub à chaque régénération
-
THE Système_Documentation SHALL envoyer un email de rappel trimestriel (via rapports@scijoly.fr) à l'administrateur contenant :
- Un résumé de l'état actuel de l'infrastructure (machines, services, dernières mises à jour)
- La liste des runbooks disponibles avec un lien vers le repo
- Les changements significatifs depuis le dernier rappel
- Un mini-quiz de 3 questions pour vérifier que l'admin se souvient des procédures critiques (ex: "Où est la clé USB Clonezilla ? Quel est l'ordre de restauration ?")
-
WHEN une mise à jour critique est appliquée (kernel, NVIDIA, Proxmox VE), THE Système_Documentation SHALL générer et envoyer par email un résumé "Ce qui a changé" incluant : ce qui a été mis à jour, ce qui pourrait casser si rollback nécessaire, et un lien vers le runbook de restauration correspondant
-
THE Système_Documentation SHALL maintenir un fichier docs/etat-infra.md mis à jour automatiquement chaque semaine contenant une photo synthétique de l'infrastructure : liste des machines avec statut, dernières mises à jour appliquées, prochaine maintenance planifiée, espace disque PBS, et résumé des incidents récents
-
WHEN une nouvelle fonctionnalité est déployée sur l'infrastructure (nouveau service, nouveau workflow, nouvelle règle réseau), THE Système_Documentation SHALL générer un tutoriel expliquant :
- Ce qui a été ajouté et pourquoi
- Comment ça fonctionne (flux simplifié)
- Comment le désactiver/modifier si besoin
- Les dépendances (quels autres services sont impactés)
-
THE Système_Documentation SHALL maintenir un index chronologique (docs/changelog-detaille.md) de tous les changements avec pour chacun : la date, le résumé, le lien vers le tutoriel/runbook généré, et le commit Git associé — servant de "journal de bord" de l'infrastructure
-
THE Système_Documentation SHALL générer la documentation en français, dans un langage accessible (pas de jargon non expliqué), avec des encadrés "⚠️ Attention" pour les étapes à risque et "✅ Vérification" pour les points de contrôle
-
THE Système_Documentation SHALL produire les runbooks dans un format consultable MÊME si l'infrastructure est totalement down, en garantissant qu'au moins une copie est accessible via :
- Le repo GitHub privé (accessible depuis n'importe quel appareil avec Internet)
- Un export PDF généré automatiquement à chaque mise à jour majeure et stocké sur le NAS Synology (ShadowDrive sync → accessible depuis le cloud)
-
THE Système_Documentation SHALL générer un PDF consolidé "Guide de survie infrastructure" (mis à jour mensuellement) regroupant les 5 runbooks les plus critiques dans un seul document, optimisé pour être lu sur smartphone en situation de stress (gros texte, étapes courtes, pas de jargon)
-
IF le LLM_Local est indisponible pour la génération de documentation, THEN THE Système_Documentation SHALL escalader vers Claude API (même mécanisme que l'Exigence 6) et SHALL journaliser l'usage. La documentation NE DOIT PAS être bloquée par l'indisponibilité du LLM local.
-
THE Système_Documentation SHALL valider la cohérence de chaque runbook généré en vérifiant que les commandes référencées correspondent à des fichiers/scripts existants dans le repo, que les IPs et ports mentionnés correspondent à l'inventaire actuel, et SHALL marquer le runbook comme "⚠️ Potentiellement obsolète" si des incohérences sont détectées
User Story : En tant qu'administrateur avec plusieurs entreprises et une vie personnelle, je veux que mon IA locale indexe, classe et me permette d'interroger tous mes documents stockés sur le NAS Synology — et que les nouveaux documents scannés soient automatiquement lus, classés et notifiés — afin de retrouver facilement mes informations et de ne jamais perdre un document important.
- Synology DS720+ (192.168.150.181) : NAS principal avec stockage SMB/NFS
- Dossiers existants : documents multi-entreprises, personnels, photos, dossier Scan
- Contraintes : accès réseau depuis le réseau 150 (accessible depuis toute l'infra), sécurité à renforcer (réduire exposition publique)
- Photos : nombreux doublons sur différents profils à dédupliquer
- Documents : PDF, Word, scans (qualité variable), photos de bâtiments, documents administratifs
- THE Système_Monitoring SHALL surveiller le NAS Synology (192.168.150.181) via SNMP ou l'API DSM en collectant : espace disque utilisé/disponible par volume, santé des disques (SMART), température CPU et disques, statut RAID, charge CPU et RAM, nombre de connexions actives
- THE Système_Monitoring SHALL intégrer les métriques Synology dans Prometheus (via snmp_exporter ou un exporter dédié) et les afficher dans un dashboard Grafana dédié
- THE Système_Alerte SHALL notifier l'administrateur si : un disque Synology présente un état SMART dégradé, l'espace disponible passe sous 15%, la température dépasse 50°C, ou un volume est en état dégradé
- THE Système_Réseau SHALL réduire l'exposition réseau du Synology au strict minimum : désactiver tous les ports non nécessaires (QuickConnect, DSM externe, UPnP), limiter l'accès SMB/NFS aux seuls sous-réseaux internes (192.168.202.0/24 et 192.168.150.0/24), et configurer le pare-feu intégré DSM
- THE Système_Monitoring SHALL vérifier quotidiennement que le Synology n'expose aucun port sur Internet (scan externe depuis pfSense) et alerter si un port non autorisé est détecté
- THE Système_Automatisation SHALL indexer récursivement les dossiers documentaires du Synology (multi-entreprises + personnels) en extrayant le contenu textuel de chaque fichier : OCR pour les scans et images, extraction native pour les PDF et Word
- THE Système_Automatisation SHALL stocker les index dans une base vectorielle (type ChromaDB, Qdrant, ou pgvector) accessible par le LLM_Local pour répondre à des questions en langage naturel sur le contenu des documents (approche RAG — Retrieval-Augmented Generation)
- THE Système_Automatisation SHALL maintenir un catalogue de tous les documents indexés avec : chemin complet, type (facture, contrat, administratif, technique, personnel), entreprise associée, date de dernière modification, et statut d'indexation (indexé, en attente, échec OCR)
- THE Système_Automatisation SHALL ré-indexer automatiquement un document lorsqu'il est modifié sur le NAS (détection via polling du timestamp ou inotify/webhook DSM)
- THE Système_Automatisation SHALL isoler les index par contexte (entreprise A, entreprise B, personnel) et ne mélanger les résultats que sur demande explicite de l'utilisateur — chaque requête IA doit préciser le périmètre de recherche
- THE Système_Automatisation SHALL planifier l'indexation initiale en tâches de batch pendant les heures creuses (exigence 6.C) et estimer la durée totale avant de commencer, en envoyant un rapport de progression quotidien
- WHEN un nouveau fichier apparaît dans le dossier Scan du Synology, THE Système_Automatisation SHALL automatiquement :
- Lire le document (OCR si nécessaire)
- Identifier le type (facture, courrier administratif, contrat, relevé bancaire, autre)
- Identifier l'entreprise ou le contexte personnel concerné
- Extraire les métadonnées clés (date, montant si facture, expéditeur, objet)
- Renommer le fichier selon une convention normalisée :
AAAA-MM-JJ_[Type]_[Entreprise]_[Objet].pdf
- Déplacer le fichier dans le bon dossier (classement par entreprise et par type)
- Indexer le document dans la base vectorielle
- Envoyer une notification email avec un résumé (type, entreprise, métadonnées extraites, emplacement final)
- IF l'IA ne parvient pas à identifier le type ou l'entreprise avec certitude (confiance < 80%), THEN THE Système_Automatisation SHALL placer le document dans un dossier « À trier » et envoyer un email à l'administrateur avec le résumé partiel et une demande de classification manuelle
- THE Système_Automatisation SHALL traiter les nouveaux fichiers du dossier Scan dans un délai maximum de 15 minutes après leur apparition (sauf si heures creuses imposées par la charge GPU)
- THE Système_Automatisation SHALL scanner les dossiers photos du Synology (tous les profils) et identifier les doublons en utilisant un hash perceptuel (pHash) pour détecter les images identiques ou quasi-identiques même si elles ont des noms différents ou des résolutions légèrement différentes
- THE Système_Automatisation SHALL produire un rapport de doublons avec pour chaque groupe : le nombre de copies, les emplacements, les tailles, et une recommandation (garder le fichier de meilleure qualité/résolution)
- THE Système_Automatisation SHALL NE PAS supprimer de fichiers automatiquement — elle produit le rapport et attend une validation de l'administrateur. Les suppressions validées sont journalisées avec le chemin d'origine
- THE Système_Automatisation SHALL planifier le scan de doublons photos en mode batch heures creuses (tâche longue, CPU-intensive, pas besoin de GPU)
- THE Système_Automatisation SHALL accéder aux documents du Synology exclusivement via un montage NFS/SMB depuis infra-mgmt (192.168.202.50) avec des credentials dédiés en lecture seule — seul le déplacement des fichiers du dossier Scan utilise un accès en écriture sur les dossiers cibles
- THE Système_Automatisation SHALL chiffrer la base vectorielle au repos (encryption at rest) et la stocker sur un volume dédié avec accès restreint
- THE Système_Automatisation SHALL journaliser chaque accès à un document (lecture, indexation, déplacement) avec horodatage, source de la requête, et périmètre
¶ Exigence 19 : Routeur IA intelligent et boucle de validation humaine
User Story : En tant qu'administrateur, je veux que toutes les requêtes IA de mon infrastructure soient routées intelligemment entre mon LLM local, des APIs gratuites (Groq, Gemini), et Claude en dernier recours — avec un suivi du coût en temps réel — et que les actions critiques me soient soumises par email avec des boutons de validation avant exécution — afin de maximiser l'économie, la confidentialité des données, et de garder le contrôle sans être submergé.
- LLM local : Ollama qwen2.5:7b (192.168.202.14:11434) — gratuit, privé, 6 Go VRAM
- APIs gratuites : Groq (Llama 70B, 1000 req/jour), Google AI Studio (Gemini Flash), OpenRouter (20+ modèles gratuits)
- API payante : Claude Sonnet/Opus via OpenRouter — $3-15/M tokens
- Orchestrateur : N8N sur vm-rustdesk-n8n (192.168.202.9:5678)
- Proxy LLM : LiteLLM (à déployer) — expose une API compatible OpenAI, route vers les bons backends
- THE Système_Automatisation SHALL déployer un proxy LLM (LiteLLM) exposant une API compatible OpenAI sur un port dédié (par défaut 4000) accessible depuis tout le réseau interne (192.168.202.0/24 et 192.168.150.0/24)
- THE Système_Automatisation SHALL configurer le routeur avec 3 niveaux de routing selon la sensibilité et la complexité de la requête :
- Niveau 1 — Local (hermétique) : Ollama (qwen2.5:7b) pour toute requête contenant des données personnelles, des secrets, des IPs internes, ou des données documentaires — ces requêtes ne sortent JAMAIS du réseau local
- Niveau 2 — Gratuit cloud : Groq (Llama 3.3 70B) et/ou Google Gemini Flash pour les requêtes nécessitant plus de raisonnement mais sans données sensibles — limité aux quotas gratuits
- Niveau 3 — Payant : Claude Sonnet/Opus via OpenRouter pour les requêtes complexes (architecture, debugging avancé, génération longue) quand les niveaux 1 et 2 échouent ou sont insuffisants
- THE Système_Automatisation SHALL router automatiquement vers le bon niveau en analysant le contenu de la requête :
- Si la requête contient des IPs, des mots de passe, des noms de machines, des chemins de fichiers internes, ou la mention "confidentiel" → Niveau 1 obligatoire
- Si la requête nécessite un raisonnement multi-étapes ou un contexte > 8K tokens → Niveau 2 ou 3
- Si le Niveau 2 retourne une erreur (rate limit, timeout) → fallback Niveau 3
- Si le budget mensuel est dépassé → blocage du Niveau 3 avec alerte
- THE Système_Automatisation SHALL configurer un budget mensuel maximal pour le Niveau 3 (par défaut 20€/mois), et SHALL alerter l'administrateur à 50%, 80% et 100% du budget
- THE Système_Automatisation SHALL exposer un endpoint
/health et /stats sur le proxy LLM permettant de connaître en temps réel : le nombre de requêtes par niveau, le coût cumulé du mois, le taux de succès par backend, et les quotas restants sur les APIs gratuites
- THE Système_Automatisation SHALL journaliser chaque requête passant par le routeur IA avec : timestamp, niveau de routing utilisé, modèle appelé, tokens input/output, coût estimé (0 pour local/gratuit), temps de réponse, et résultat (succès/échec/fallback)
- THE Système_Automatisation SHALL produire un rapport hebdomadaire de consommation IA envoyé par email incluant : requêtes par niveau (nombre et pourcentage), coût total Niveau 3, économie estimée (ce qu'aurait coûté le même volume en full Claude), modèles les plus utilisés, et requêtes les plus coûteuses
- THE Système_Automatisation SHALL exposer les métriques du routeur IA vers Prometheus (via un exporter ou un endpoint /metrics) : nombre de requêtes, latence par backend, coût cumulé, erreurs par provider
- THE Système_Automatisation SHALL configurer des alertes Prometheus si : le taux d'erreur d'un backend dépasse 20% sur 5 minutes, le temps de réponse moyen dépasse 30 secondes, ou le LLM local est injoignable
¶ 19.C — Boucle de validation humaine par email (webhooks interactifs)
- THE Système_Automatisation SHALL permettre à tout workflow N8N de soumettre une action à validation humaine en envoyant un email contenant des boutons d'action (liens webhook) permettant à l'administrateur de répondre par un simple clic
- THE Système_Automatisation SHALL formater les emails de validation avec :
- Un résumé clair de l'action proposée (1-2 phrases)
- Le contexte (quelle alerte ou quel événement a déclenché la proposition)
- La recommandation de l'IA (avec le niveau de confiance si disponible)
- Des boutons d'action cliquables : au minimum [APPROUVER] et [REFUSER], avec optionnellement [REPORTER 1h], [REPORTER DEMAIN], [PLUS DE DÉTAILS]
- Chaque bouton est un lien HTTPS vers un webhook N8N avec un token unique (anti-replay)
- WHEN l'administrateur clique sur un bouton d'action dans l'email, THE Système_Automatisation SHALL exécuter l'action correspondante dans un délai de 30 secondes et envoyer un email de confirmation avec le résultat
- THE Système_Automatisation SHALL implémenter un mécanisme d'expiration : si aucune réponse n'est reçue dans un délai configurable (par défaut 2 heures), l'action est annulée automatiquement et un email de rappel est envoyé. Pour les actions critiques, le délai d'expiration est de 30 minutes.
- THE Système_Automatisation SHALL sécuriser les webhooks de validation avec :
- Un token unique par action (UUID v4), valide une seule fois (anti-replay)
- Une expiration du token après le délai configuré
- Une vérification que l'action n'a pas déjà été exécutée (idempotence)
- Un log de chaque clic (IP, timestamp, action, résultat)
- THE Système_Automatisation SHALL classer les actions en 3 catégories déterminant le comportement de validation :
- Informationnel : pas de validation requise, l'email est une notification pure (résumé quotidien, rapport hebdo)
- Standard : validation requise, timeout 2h, action annulée si pas de réponse
- Critique : validation requise, timeout 30 min, rappel à mi-parcours, 2 boutons seulement (APPROUVER/REFUSER)
- THE Système_Automatisation SHALL soumettre à validation humaine (catégorie Standard) les actions suivantes :
- Mise à jour d'un package classifié "à risque" par le LLM
- Redémarrage d'un service critique (HestiaCP, NPM, N8N)
- Suppression de fichiers (doublons photos, emails batch)
- Application de règles pare-feu pfSense
- Toute action proposée par l'IA qui modifie l'état de l'infrastructure
- THE Système_Automatisation SHALL soumettre à validation humaine (catégorie Critique) les actions suivantes :
- Mise à jour kernel de pve-main
- Migration de VMs vers/depuis le NUC
- Rollback d'un snapshot Proxmox
- Modification des drivers GPU
- THE Système_Automatisation SHALL exécuter SANS validation (catégorie Informationnel) les actions suivantes :
- Envoi du résumé quotidien (06h)
- Envoi du rapport hebdomadaire
- Classification et tri des emails (sauf suppression)
- Collecte de métriques et logs
- Redémarrage de services non-critiques détectés comme down par Uptime Kuma (avec notification après action)