merge: rapports Hermes analyse documentation 03-05 juin 2026

[Hermes] Rapport documentation — 2026-06-03

admin/hermes/builtin/2026-06-03_00-28.md

@@ -0,0 +1,106 @@
+# Rapport Hermes — 2026-06-03_00-28
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM avec des modèles locaux et cloud, mais présente un gap IaC dans les templates Ansible  
+
+**Problèmes :**
+- Le template Ansible (config.yaml.j2) ne comprend pas les modèles CPU qwen3-1.7b-system et qwen3-1.7b-monitor nécessaires pour ask-agent
+- Le script hermes-switch modifie manuellement /etc/litellm/config.yaml au lieu d'utiliser un template Ansible
+
+**Suggestions :**
+- Ajouter les modèles CPU dans le template Ansible pour une IaC complète
+- Synchroniser le script hermes-switch avec les templates Ansible pour éviter les modifications manuelles
+- Mettre à jour la section 'État réel' avec la configuration actuelle du cluster
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml. Les templates Ansible sont incomplets et ne déployent pas les routes nécessaires pour ask-agent system/monitor.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document détaillé sur la configuration et les performances du llama-server sur gpu-01, avec des instructions opérationnelles et des métriques de surveillance.  
+
+**Problèmes :**
+- La section 'Performances' manque les données VRAM pour le modèle CPU
+- La table 'Contrainte VRAM' contient un caractère spécial non pertinent (✅)
+- Aucune mention des mises à jour récentes ou des correctifs de sécurité
+
+**Suggestions :**
+- Ajouter une section sur les mises à jour récentes et les correctifs de sécurité
+- Compléter les données VRAM pour le modèle CPU dans la section 'Performances'
+- Corriger le format de la table 'Contrainte VRAM' en supprimant le caractère spécial
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel avec les configurations décrites, mais des améliorations documentaires sont nécessaires pour couvrir les aspects de maintenance et de sécurité.
+
+---
+
+## ✅ `admin/ia/rag.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée sur le système RAG de Funk, expliquant l'architecture, les composants, les modèles d'embedding et les procédures d'utilisation.  
+
+**Problèmes :**
+- Le modèle d'embedding Qwen3-8B présente des limites de discrimination sémantique (scores cosinus uniformément élevés)
+- La procédure manuelle de mise à jour nécessite deux commandes séparées (rsync + rag-ingest)
+
+**Suggestions :**
+- Tester le déploiement d'un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3
+- Ajouter un exemple de script automatique pour synchroniser et re-indexer les documents
+- Mettre en évidence les précautions lors de l'utilisation du GPU pour l'ingestion (temps d'exécution)
+
+**État réel connu de Hermes :**  
+Système RAG opérationnel avec index de 339 chunks, mais les résultats de recherche souffrent de perte de pertinence en raison du modèle d'embedding utilisé
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document ROCm.md fournit des commandes clés pour vérifier la configuration ROCm sur une RX 6700XT, incluant les vérifications du matériel, des modules noyau, des variables d'environnement et des étapes de débogage.  
+
+**Problèmes :**
+- Manque de mention des dépendances logicielles récentes (ex: ROCm 6.1.2)
+- Aucune instruction pour tester les pilotes AMD avec un workload réel
+- Les commandes de vérification des groupes utilisateur ne montrent pas les effets de la modification
+
+**Suggestions :**
+- Ajouter une section sur la mise à jour des dépôts AMD/ROCm
+- Inclure un exemple de test avec un benchmark GPU (ex: fujaba/rocprof)
+- Préciser les permissions nécessaires pour les commandes sudo
+- Ajouter un avertissement sur les limitations de la RX 6700XT avec ROCm
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec historique des incidents et résolutions détaillées, mais présente quelques incohérences de formatage et des lacunes dans la description de certains événements.  
+
+**Problèmes :**
+- Tableau d'index avec des espaces incohérents dans les colonnes
+- Ligne incomplète sur l'état post-migration (« Espace disponibl » tronqué)
+- Manque de détails sur la résolution des incidents du 2026-05-13 (llama-server/métriques et règle nftables)
+- Absence de mention des mesures préventives ou de monitoring post-résolution
+
+**Suggestions :**
+- Corriger les espaces incohérents dans le tableau d'index
+- Compléter la description de l'état post-migration
+- Ajouter des détails techniques sur la gestion des erreurs RAID et la validation de la corrélation Qdrant
+- Inclure une section « Mesures préventives » pour chaque incident
+
+**État réel connu de Hermes :**  
+Le composant RAID5 a été migré vers NVMe avec succès. Les données critiques sont intactes, mais des contrôles réguliers sont nécessaires pour éviter les erreurs d'interface SATA. Le système de monitoring a été ajusté pour détecter les erreurs de disque plus tôt.
+
+---
+

admin/hermes/builtin/2026-06-03_00-41.md

@@ -0,0 +1,106 @@
+# Rapport Hermes — 2026-06-03_00-41
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur l'installation et l'utilisation de k9s dans le cluster Funk, avec des instructions claires et des raccourcis utiles. Quelques améliorations possibles pour la clarté.  
+
+**Problèmes :**
+- La configuration YAML pour les namespaces contient une erreur de formatage (indentation incorrecte des blocs 'namespace' et 'view')
+- La section 'Débugger un pod en erreur' se termine abruptement avec un séparateur markdown incomplet
+- Les raccourcis clavier pour les actions sur les ressources pourraient être organisés par catégories (général, ressources, actions, logs) pour plus de clarté
+
+**Suggestions :**
+- Ajouter une note expliquant que le kubeconfig généré par talhelper utilise le serveur API à 192.168.10.11
+- Mettre en évidence les raccourcis critiques pour les tâches courantes (ex: '0' pour tous les namespaces, 'l' pour les logs)
+- Ajouter un exemple concret de commande pour vérifier le contexte kubeconfig (ex: 'kubectl config current-context')
+- Corriger la mise en forme du YAML d'exemple pour éviter les erreurs de configuration
+
+**État réel connu de Hermes :**  
+Les informations sont applicables au cluster Funk. Le document reste pertinent malgré les petites imperfections de mise en forme.
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, bien structurée et versionnée.  
+
+**Problèmes :**
+- Section 'Alerts' incomplète (tronquée à mi-parcours)
+- Supposition implicite d'un workflow Git sans clarification
+
+**Suggestions :**
+- Compléter la section des règles d'alerte manquantes
+- Ajouter une note explicite sur les prérequis Git si nécessaire
+- Valider les URLs des dashboards (http://grafana.lab.local/d/... manquent le suffixe .json)
+
+**État réel connu de Hermes :**  
+Le système de monitoring est opérationnel avec les composants déployés via ArgoCD. La documentation reflète la configuration actuelle, sauf la section d'alertes incomplète qui pourrait affecter la gestion des règles.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et la configuration de n8n dans le cluster Kubernetes, incluant les workflows d'automatisation et les intégrations système.  
+
+**Problèmes :**
+- Le secret n8n-secret est créé via kubectl mais la documentation ne précise pas les étapes pour récupérer le mot de passe depuis le vault Ansible
+- Les dépendances vers Postfix et LiteLLM sont implicites sans vérification de leur disponibilité
+- Le test manuel des workflows nécessite des droits root sur le cluster
+
+**Suggestions :**
+- Ajouter une section 'dépendances' avec les prérequis (Postfix, LiteLLM, Prometheus)
+- Mettre en avant les risques de sécurité avec les credentials sensibles
+- Proposer un exemple de playbook Ansible pour créer le secret
+
+**État réel connu de Hermes :**  
+Le composant est déployé via ArgoCD avec des workflows actifs, mais nécessite validation des intégrations SMTP/LLM
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée pour déployer et utiliser Open WebUI avec des instructions claires et des sections de dépannage pertinentes  
+
+**Problèmes :**
+- La section 'Variables d'environnement clés' manque de précision sur la gestion du mot de passe PostgreSQL (réfère vers un vault Ansible sans détails d'accès)
+
+**Suggestions :**
+- Ajouter une note explicite sur la récupération du mot de passe PostgreSQL depuis le vault Ansible
+- Mettre en évidence les dépendances critiques (ex: dépendance vers LiteLLM et PostgreSQL)
+
+**État réel connu de Hermes :**  
+Le composant est déployé conformément aux instructions, avec des pods Open WebUI fonctionnant via Traefik et connectés à LiteLLM
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de Talos Linux et du cluster Kubernetes, avec des procédures claires et des configurations détaillées.  
+
+**Problèmes :**
+- La procédure d'installation s'arrête prématurément à la step 4 avec une commande tronquée
+- Manque de section sur la validation post-installation et les tests de santé
+- La version de SOPS (3.9.4) est un peu ancienne (décembre 2023)
+
+**Suggestions :**
+- Compléter la procédure avec les étapes de validation post-installation (kubectl get nodes, kubeconfig vérification)
+- Ajouter une section 'Dépannage' avec les cas courants (problèmes de boot, erreurs de configuration)
+- Mettre à jour les outils vers les versions les plus récentes (sops 3.10.x, talhelper 0.12.0+)
+- Ajouter un avertissement sur la sécurité des clés age (déplacement vers un système de gestion de clés plus robuste)
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes est opérationnel avec 3 nœuds Talos (v1.13.0), Kubernetes v1.33.1, et Flannel CNI. Les configurations sont appliquées via talhelper et les secrets sont gérés par SOPS/age.
+
+---
+

admin/hermes/builtin/2026-06-03_10-30.md

@@ -0,0 +1,74 @@
+# Rapport Hermes — 2026-06-03_10-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et gestion du Vault, bien structurée mais manquant de détails sur les bonnes pratiques avancées  
+
+**Problèmes :**
+- La commande 'ansible-playbook --check --diff' n'indique pas si les changements sont appliqués en mode dry-run
+- Aucune mention des bonnes pratiques pour gérer les données sensibles au-delà du Vault
+- Les exemples de commande ad-hoc ne montrent pas l'utilisation de variables ou de templates
+
+**Suggestions :**
+- Ajouter des exemples de commandes avec des conditions (when) et boucles (loop)
+- Préciser les conventions pour nommer les rôles et les variables
+- Inclure des conseils sur la segmentation des playbooks par fonctionnalité
+- Mettre en avant les meilleures pratiques pour les déploiements en production
+
+**État réel connu de Hermes :**  
+Le fichier reflète correctement la configuration actuelle du cluster Funk, avec des rôles et groupes d'hôtes alignés sur les machines physiques déclarées dans le tableau
+
+---
+
+## ✅ `admin/ops/cluster.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt, mais nécessite des précisions sur certaines étapes.  
+
+**Problèmes :**
+- Mention de la vérification NFS dans funk-status sans détails pratiques sur la commande à exécuter
+- Procédure de démarrage avec --k8s ne précise pas comment vérifier si les nœuds k8s sont 'Ready'
+- Aucune mention des prérequis BIOS pour Wake-on-LAN sur les compute nodes
+- Lien vers k8s/argocd.md ne vérifie pas l'existence du fichier
+- Pas de note sur les délais réels pour le chargement des modèles LLM
+
+**Suggestions :**
+- Ajouter un exemple concret de commande pour vérifier l'état NFS (ex: 'showmount -e 192.168.10.1')
+- Indiquer le temps exact moyen de chargement des modèles (ex: '4-6 minutes pour le modèle GPU')
+- Ajouter une note explicite sur la configuration Wake-on-LAN dans le BIOS (ex: 'Gigabyte: Advanced → ACPI Settings')
+- Vérifier l'existence du fichier k8s/argocd.md et créer un lien vers sa documentation si absent
+- Ajouter un bloc 'Prérequis' pour chaque commande majeure (ex: 'Assurez-vous que Wake-on-LAN est activé')
+
+**État réel connu de Hermes :**  
+Le document reflète correctement les procédures actuelles, mais certaines étapes manquent de détails pratiques pour éviter les erreurs courantes
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et bien structuré décrivant les commandes système et services clés pour AlmaLinux 9 sur les machines Funk, avec des exemples pratiques.  
+
+**Problèmes :**
+- Manque les ports des services GPU (llama-server, etc.) dans la table des services
+- La note post-reboot sur RAID5 est vague (manque des étapes concrètes)
+- Aucune mention des outils avancés comme iproute2 ou tcpdump dans la section réseau
+
+**Suggestions :**
+- Ajouter les ports des services GPU dans la table des services
+- Compléter la note post-reboot avec des étapes détaillées pour réparer dnsmasq
+- Ajouter une sous-section sur les outils avancés réseau (iproute2, tcpdump, nftables)
+- Inclure des exemples de monitoring avec Prometheus/Node Exporter
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle de Funk, mais certaines sections pourraient être mises à jour pour couvrir les pratiques modernes de gestion système.
+
+---
+

admin/hermes/builtin/2026-06-03_11-38.md

@@ -0,0 +1,114 @@
+# Rapport Hermes — 2026-06-03_11-38
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration et la gestion de dnsmasq sur le cluster Funk, avec des exemples concrets et des solutions à problèmes.  
+
+**Problèmes :**
+- La section 'Problème connu' mentionne un fix systemd mais ne précise pas que ce fichier de configuration doit être déployé via Ansible
+- Les commandes 'sudo journalctl' ne spécifient pas le besoin de sudo pour les utilisateurs non-root
+- Le template MetalLB n'est pas encore implémenté dans le document
+
+**Suggestions :**
+- Ajouter un avertissement sur la nécessité de relancer dnsmasq après modification de la config
+- Mettre en évidence les commandes critiques avec des couleurs ou des balises visuelles
+- Ajouter une vérification automatique du statut des interfaces réseau dans les exemples
+- Préciser les dépendances Ansible pour le fix du problème connu
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet sur la configuration du relais SMTP Postfix vers Gmail, avec étapes claires et vérification détaillée.  
+
+**Problèmes :**
+- Manque de mention sur la sécurité (SPF/DKIM/DMARC) pour les emails relayés
+- Aucune indication sur la gestion des droits d'accès au vault_postfix_relay_password
+- Le chapitre 'Utilisation' pourrait préciser les limites des exemples (ex: nécessité de sudo)
+
+**Suggestions :**
+- Ajouter une section sur la configuration SPF/DKIM pour les emails relayés
+- Mettre en avant les bonnes pratiques de stockage des App Passwords
+- Préciser les contraintes d'exécution des exemples (ex: nécessité de sudo)
+
+**État réel connu de Hermes :**  
+Le relais SMTP fonctionne selon les tests décrits, avec des logs postfix corrects. Les App Passwords sont gérés via le vault. Les IPs autorisées incluent le réseau k8s et le LAN.
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec des procédures claires pour serveur et client, mais présente quelques redondances et opportunités d'optimisation.  
+
+**Problèmes :**
+- Les exports NFS définis (/srv/data/nfs/k8s et /srv/data/models) sont redondants avec le répertoire parent /srv/data/nfs/k8s
+- Les paramètres de montage sur le client (soft, timeo=30, retrans=3) pourraient être documentés avec des explications sur leur impact
+- La section 'Ajouter un nouveau répertoire partagé' manque de précision sur les droits spécifiques à assigner (uid/gid)
+
+**Suggestions :**
+- Simplifier les exports en ne définissant que /srv/data/nfs/k8s et ajouter les autres répertoires comme sous-dossiers
+- Ajouter une explication sur la gestion des montages automount lors de l'arrêt/redémarrage du serveur
+- Préciser les bonnes pratiques pour les permissions (ex: utiliser le UID/GID du service concerné)
+
+**État réel connu de Hermes :**  
+Le setup NFS est actif sur storage-01 avec les exports configurés. Les clients gpu-01 montent correctement les répertoires via automount. Les modèles GGUF sont accessibles via NFS comme prévu.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée et complète sur la configuration réseau du cluster Funk, avec des exemples pratiques et des conseils pour nftables.  
+
+**Problèmes :**
+- La section nftables manque d'exemples concrets de règles applicatives
+- Le diagramme d'architecture réseau manque d'illustration visuelle
+- Les commandes de débogage pourraient inclure des tests de connectivité plus complets
+- Le rôle des interfaces WAN/LAN pourrait être mieux expliqué pour les nouveaux utilisateurs
+
+**Suggestions :**
+- Ajouter un schéma réseau visuel (diagramme de connections)
+- Compléter la section nftables avec des exemples de règles typiques
+- Inclure des tests de ping/traceroute pour chaque configuration
+- Ajouter une note sur la sécurité réseau (firewalld vs nftables)
+- Mettre en évidence les commandes critiques avec des couleurs ou des emojis
+
+**État réel connu de Hermes :**  
+Le réseau fonctionne correctement avec la configuration documentée, mais des améliorations sont possibles pour la sécurité et la documentation.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers avec des alias et des exemples pratiques, mais manque de détails sur la sécurité et les bonnes pratiques.  
+
+**Problèmes :**
+- Aucun mention de politique de rotation des clés SSH
+- Manque d'explications sur l'utilisation de SSH agent forwarding
+- Les commandes de débogage ne couvrent pas les cas d'erreur liés aux tunnels SSH
+- Aucun exemple sur la configuration avancée des clés (ex: SSH config pour plusieurs hôtes)
+
+**Suggestions :**
+- Ajouter une section sur les bonnes pratiques de sécurité (rotation de clés, permissions des fichiers .ssh)
+- Préciser les risques liés aux connexions en root et recommander des alternatives
+- Ajouter des exemples de débogage pour les problèmes de tunnels SSH
+- Mettre en évidence les différences entre les méthodes de connexion (alias vs ProxyJump)
+
+**État réel connu de Hermes :**  
+Le système SSH est opérationnel avec des connexions sécurisées via des clés ed25519, mais les politiques de maintenance des clés et les configurations avancées nécessitent des améliorations.
+
+---
+

admin/hermes/builtin/2026-06-03_14-15.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-03_14-15
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 7/10
+
+**Statut** : ok  
+**Résumé** : Document structure correctement avec ordre d'installation et dépendances, mais manque les étapes détaillées des guides eux-mêmes  
+
+**Problèmes :**
+- Le fichier README ne contient pas les étapes d'installation réelles des guides (storage-01.md, gpu-01.md, kubernetes.md)
+- Les liens vers les guides individuels ne sont pas développés dans ce fichier
+- Aucune vérification des prérequis techniques (ex: vérification des dépendances ROCm sur gpu-01)
+
+**Suggestions :**
+- Inclure les étapes d'installation détaillées directement dans ce fichier ou créer des sous-pages liées
+- Ajouter une section de vérification des prérequis pour chaque machine
+- Mettre à jour les dépendances mentionnées (ex: spécifier la version exacte de ROCm pour RX 6700XT)
+- Ajouter une note sur la configuration requise pour le cluster Kubernetes (ex: prérequis Talos v1.13)
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de gpu-01, avec des sections claires et des solutions aux problèmes connus (comme le support ROCm pour RX 6700XT).  
+
+**Problèmes :**
+- Manque de détails concrets sur les commandes Ansible exactes à exécuter
+- Aucune mention des étapes de vérification post-ROCm installation
+- La section 'Pièges' est générale et pourrait inclure plus d'exemples concrets
+
+**Suggestions :**
+- Ajouter les commandes Ansible spécifiques pour chaque tâche (ex: 'ansible-playbook -i inventory.yml playbooks/gpu-01.yml')
+- Inclure un script de vérification post-installation (ex: vérification des drivers ROCm)
+- Détailler les étapes pour résoudre les erreurs courantes lors du téléchargement des packages ROCm
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré couvrant l'installation d'un cluster Kubernetes, avec des sections détaillées et une organisation logique.  
+
+**Problèmes :**
+- Manque de détails spécifiques sur la création de la clé USB Talos (ex: commande exacte pour formatter le disque)
+- La section 'Vérification finale' pourrait inclure des commandes de test spécifiques (ex: kubectl get all --all-namespaces)
+- Aucune mention des dépendances externes comme helm ou kubeadm dans les prérequis
+
+**Suggestions :**
+- Ajouter des exemples concrets de commandes talosctl pour la préparation de la clé USB
+- Inclure une vérification des versions Talos/Kubernetes lors de la configuration
+- Mettre en évidence les étapes critiques avec des indicateurs de réussite (ex: 'Vérifier que le kubeconfig est fonctionnel avec kubectl version')
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré, cohérent avec l'environnement actuel du lab. Les étapes clés sont couvertes, mais quelques améliorations sont possibles.  
+
+**Problèmes :**
+- Le document ne mentionne pas la configuration du firewall nftables (important pour la sécurité)
+- Aucune mention des dépendances logicielles spécifiques comme Python ou Ansible
+- Les commandes de base (ex: `dd`) pourraient être mises à jour avec des alternatives modernes
+
+**Suggestions :**
+- Ajouter une section sur la configuration du firewall nftables
+- Inclure des exemples concrets de commandes Ansible dans les playbooks
+- Mettre à jour les commandes de base avec des méthodes plus récentes (ex: `dd` → `curl | bash`)
+- Ajouter une note sur la vérification des erreurs RAID après assemblage
+
+**État réel connu de Hermes :**  
+Le composant est correctement configuré dans Funk avec les spécifications décrites. Les erreurs I/O sur le disque sdb sont surveillées via smartctl.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur l'implémentation GitOps d'ArgoCD dans le cluster Funk, avec des étapes claires pour l'installation et la gestion des applications.  
+
+**Problèmes :**
+- Le script pour récupérer le mot de passe initial pourrait inclure une vérification si le secret existe avant de le demander
+- Aucune mention des politiques de sécurité supplémentaires (ex: chiffrement des clés SSH dans le secret)
+
+**Suggestions :**
+- Ajouter une note sur la validation des YAML avant déploiement
+- Mettre à jour la version d'ArgoCD pour utiliser la dernière stable (9.5.14 est une version ancienne)
+- Ajouter un exemple de hook pour nettoyer les ressources orphelines
+
+**État réel connu de Hermes :**  
+fonctionnel
+
+---
+

admin/hermes/builtin/2026-06-03_14-30.md

@@ -0,0 +1,112 @@
+# Rapport Hermes — 2026-06-03_14-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur l'installation et l'utilisation de k9s dans le cluster Funk, avec des instructions claires et des exemples pratiques  
+
+**Problèmes :**
+- La section de configuration contient une erreur de formatage YAML ('v1/pods all' au lieu de 'v1/pods')
+- La documentation sur la navigation est incomplète (manque quelques raccourcis essentiels)
+- Le cas d'usage 'débugger un pod en erreur' est tronqué
+
+**Suggestions :**
+- Mettre à jour le YAML de configuration pour corriger le formatage
+- Ajouter des exemples d'utilisation avancés (ex: filtrage de ressources)
+- Compléter la section de débogage avec des étapes détaillées
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec une configuration basique de k9s, mais nécessite des améliorations pour une utilisation optimale
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte versionnées.  
+
+**Problèmes :**
+- La section des règles d'alerte est incomplète (cut-off à 'PodPendingLong')
+- Manque de mention des dernières mises à jour ou versions des composants
+
+**Suggestions :**
+- Compléter la section des règles d'alerte manquantes
+- Ajouter une mention de la date de dernière mise à jour du document
+- Inclure un diagramme ou architecture visuelle pour clarifier les relations entre les composants
+
+**État réel connu de Hermes :**  
+Opérationnel - Le système de monitoring est déployé via ArgoCD dans le namespace 'monitoring' avec des dashboards et alertes custom versionnés. Les métriques sont collectées depuis les nodes, le storage-01 et le gpu-01 avec des scrapeurs spécifiques aux ROCm et llama-server.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration et les workflows d'n8n dans le cluster Kubernetes, avec détails sur l'architecture, la déploiement, les credentials et les workflows d'alertes et de rapports système.  
+
+**Problèmes :**
+- Manque de mention sur la gestion des erreurs dans les workflows
+- Le test manuel des alertes utilise une syntaxe curl qui pourrait être mieux documentée
+- Aucune mention des politiques de rotation des clés API ou des secrets
+
+**Suggestions :**
+- Ajouter une section sur la surveillance des logs n8n
+- Proposer un exemple de webhook de test plus détaillé avec des cas d'usage
+- Indiquer les bonnes pratiques pour sécuriser les secrets dans un environnement production
+
+**État réel connu de Hermes :**  
+Le composant est actif avec deux workflows opérationnels : gestion des alertes Prometheus et rapport système horaire. Les credentials sont correctement configurés, mais les politiques de maintenance des secrets devraient être documentées.
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour déployer et configurer Open WebUI avec des instructions claires et des informations techniques précises.  
+
+**Problèmes :**
+- La variable DATABASE_URL contient un mot de passe référencé dans un vault Ansible, qui n'est pas accessible sans credentials
+- Le paragraphe sur le téléchargement initial de modèles sentence-transformer pourrait préciser le délai exact (2-3 minutes) et la taille (500MB)
+- Aucune mention des quotas de mémoire pour le pod Kubernetes, ce qui pourrait expliquer les OOMKilled
+
+**Suggestions :**
+- Ajouter une section sur la sécurisation des secrets (ex: chiffrement, rotation)
+- Mettre en évidence les dépendances critiques (LiteLLM, PostgreSQL, Traefik)
+- Proposer un checklist de vérification post-déploiement (connectivité, ressources, logs)
+
+**État réel connu de Hermes :**  
+Déployé via ArgoCD dans le namespace 'ai', dépend du service LiteLLM et de PostgreSQL. Les pods peuvent nécessiter une augmentation de mémoire initiale en raison du téléchargement de modèles.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux sur le cluster Funk, avec des procédures claires et des configurations détaillées.  
+
+**Problèmes :**
+- Manque de mécanismes de haute disponibilité pour le control-plane (single control-plane)
+- Aucune mention de vérification de l'intégrité du ISO Talos (checksum)
+- Le script de génération des secrets ne spécifie pas comment gérer la rotation des clés
+- Pas d'explication sur la gestion sécurisée des clés privées (souvent oubliées dans les dépôts)
+- La procédure d'installation manque des étapes de vérification post-installation des nœuds
+
+**Suggestions :**
+- Ajouter une section sur la configuration de Kubernetes avec HA pour le control-plane
+- Inclure des vérifications de checksum pour le ISO Talos
+- Mettre à jour les instructions sur la rotation sécurisée des clés SOPS
+- Ajouter un exemple de workflow pour la gestion des clés avec Ansible/Cron
+- Préciser les étapes de validation post-installation des nœuds (ex: vérification des métriques)
+- Ajouter un diagramme de la topologie réseau avec les adresses IP assignées
+
+**État réel connu de Hermes :**  
+Le cluster Funk utilise actuellement cette configuration, mais les nœuds sont configurés avec des disques NVMe et les secrets SOPS sont protégés. Aucune vérification automatique des clés n'est en place.
+
+---
+

admin/hermes/builtin/2026-06-03_14-58.md

@@ -0,0 +1,68 @@
+# Rapport Hermes — 2026-06-03_14-58
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et gestion du vault, mais manque de contexte sur les dépendances et les bonnes pratiques.  
+
+**Problèmes :**
+- Aucune explication sur la configuration initiale du venv et des dépendances
+- Les commandes 'make install' et 'make vault-*' manquent de détails pratiques
+- Pas de section sur les bonnes pratiques de gestion des secrets
+- Le tableau des groupes d'hôtes manque de description des rôles des groupes
+
+**Suggestions :**
+- Ajouter une section 'Prérequis' expliquant la configuration du venv et des dépendances
+- Mettre à jour la documentation sur la gestion des collections Ansible Galaxy
+- Inclure des exemples de scénarios de rotation de secrets avec le vault
+- Ajouter une description des rôles des groupes d'hôtes dans le tableau
+
+---
+
+## ✅ `admin/ops/cluster.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant les procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt.  
+
+**Problèmes :**
+- Manque de mention des erreurs potentielles (ex: échec du WOL, timeout des services)
+- Pas de section dédiée aux vérifications post-démarrage (ex: tests de connectivité)
+- Dépendance implicite à la configuration BIOS Wake on LAN sans avertissement
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec exemples de cas d'échec (ex: 'Si le WOL échoue, vérifier...')
+- Spécifier l'ordre de drainage des nœuds Kubernetes pour éviter les conflits
+- Inclure un checklist de validation finale après 'funk-start' (ex: 'Vérifier les exports NFS')
+
+**État réel connu de Hermes :**  
+Fonctionnel avec des procédures validées, mais nécessite des améliorations pour les scénarios d'erreur et la documentation complète des dépendances matérielles
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré couvrant les opérations système sur AlmaLinux 9, avec des commandes clés et des configurations essentielles pour les machines storage-01 et gpu-01.  
+
+**Problèmes :**
+- La section 'Réseau (NetworkManager)' manque d'explications sur l'interprétation des résultats des commandes nmcli
+- Le lien vers infra/dnsmasq.md est référencé sans inclure son contenu ici
+- Les exemples de commande manquent pour certaines tâches (ex: modification DNS)
+
+**Suggestions :**
+- Ajouter des exemples concrets pour chaque commande (ex: 'nmcli con mod...' avec un cas d'usage)
+- Inclure une brève explication des paramètres clés dans les commandes nmcli
+- Intégrer les informations critiques de infra/dnsmasq.md ici pour la continuité
+- Ajouter une note sur la vérification des dépendances après les mises à jour
+
+**État réel connu de Hermes :**  
+Le système est opérationnel avec les services critiques (nftables, dnsmasq, chronyd) en cours d'exécution. Les mises à jour sont gérées via Ansible avec reboot automatique. Les .pyc corrompus sont un risque post-reboot non-propre.
+
+---
+

admin/hermes/builtin/2026-06-03_15-00.md

@@ -0,0 +1,96 @@
+# Rapport Hermes — 2026-06-03_15-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet avec organisation claire des guides et ressources, bien aligné avec la configuration actuelle du cluster Funk.  
+
+**Problèmes :**
+- Le lien vers ia/hermes.md pourrait inclure un aperçu des profils et skills disponibles
+- L'absence de mention des nouvelles fonctionnalités de Qdrant v1.14+ dans la section ia/llama_server.md
+
+**Suggestions :**
+- Ajouter un aperçu des sections critiques dans chaque lien (ex: 'ia/hermes.md: Configuration des profils et skills Hermes')
+- Mettre à jour la section ia/llama_server.md avec les notes sur les limitations de Qwen3-8B/Q4_K_M
+- Ajouter un index des incidents avec les catégories de problèmes (réseau/IA/stockage)
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée du webhook AlertManager-Hermes avec architecture, flux, tests et gestion du service.  
+
+**Problèmes :**
+- Le JSON d'exemple dans la section 2.1 manque la fermeture de l'objet 'alerts' (closing brace)
+- La syntaxe JSON des annotations contient une virgule traînante invalide
+- Aucune mention des mécanismes de retry en cas d'échec de traitement par ask-agent
+
+**Suggestions :**
+- Ajouter une validation JSON pour les exemples de payloads
+- Préciser les bonnes pratiques pour la journalisation des erreurs
+- Mettre en évidence les dépendances critiques (ex: dépendance vers le modèle monitor)
+
+**État réel connu de Hermes :**  
+Le service est actif sur storage-01, les tests curl fonctionnent, mais les logs montrent des retards variables entre l'alerte et la réponse IA (20-60s). Les permissions du service sont minimales et correctes.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer le client vocal Hermes avec architecture claire et étapes d'installation détaillées  
+
+**Problèmes :**
+- Manque de précision sur les paramètres avancés du VAD (seuil RMS, fenêtre de détection)
+- La section dépannage est trop générique (manque de cas spécifiques comme les erreurs de modèle Whisper)
+- Aucune mention des exigences matérielles pour le STT (CPU/GPU recommandés)
+
+**Suggestions :**
+- Ajouter une section sur l'optimisation du VAD pour différents environnements bruyants
+- Inclure des exemples de commandes pour tester les différents modes (VAD, push-to-talk)
+- Mettre en avant les alternatives pour le TTS (autres voix disponibles sur HuggingFace)
+- Ajouter une note de sécurité sur la configuration des accès SSH
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel avec les configurations décrites, mais pourrait gagner en robustesse pour les cas d'usage avancés
+
+---
+
+## ✅ `admin/ia/hermes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du Hermes Agent avec architecture, configuration et utilisation, bien que quelques sections soient incomplètes.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (tronquée à 'Réponds UNIQUEMENT en JSON valide')
+- Manque des détails sur la gestion des erreurs et la récupération après panne
+- Aucune mention des procédures de sauvegarde ou de récupération de données
+
+**Suggestions :**
+- Compléter la section SOUL.md pour détailler les paramètres des profils
+- Ajouter une section 'Dépannage' avec des exemples de résolution de problèmes courants
+- Inclure une procédure de sauvegarde automatique des configurations critiques
+- Mettre à jour les informations sur les versions actuelles des composants
+
+**État réel connu de Hermes :**  
+Le système Hermes est actif sur storage-01 avec les services systemd configurés. Les profils sont correctement définis et les configurations principales sont en place, mais des améliorations sont nécessaires pour la résilience et la documentation complète.
+
+---
+

admin/hermes/builtin/2026-06-03_15-13.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-03_15-13
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM avec des informations sur les modèles, les coûts et les outils d'administration, mais avec un gap IaC non résolu.  
+
+**Problèmes :**
+- Les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) sont manuellement ajoutés dans /etc/litellm/config.yaml alors que le template Ansible ne les inclut pas
+- Aucune mention des risques liés à la configuration manuelle (perte en cas de reapply)
+
+**Suggestions :**
+- Mettre à jour le template Ansible (config.yaml.j2) pour inclure tous les modèles nécessaires
+- Ajouter une note explicite sur la gestion des configurations manuelles et les risques associés
+- Lier le fichier à la gestion des versions des modèles via un inventaire dynamique
+
+**État réel connu de Hermes :**  
+Le service fonctionne correctement avec les modèles GPU et CPU, mais le déploiement IaC reste incomplet et expose à des erreurs de configuration
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les performances des instances llama-server sur gpu-01, avec des instructions opérationnelles et des métriques de surveillance.  
+
+**Problèmes :**
+- La section des métriques Prometheus mentionne un flag --metrics requis mais ne fournit pas de vérification pratique de son activation
+- Le paragraphe sur les performances ne compare pas les débits avec les benchmarks récents
+- Le bug 'parallel' mentionné dans le paragraphe des performances n'est pas expliqué
+
+**Suggestions :**
+- Ajouter une vérification pratique du flag --metrics avec un exemple de curl
+- Mettre à jour les benchmarks avec des chiffres récents (2026)
+- Expliciter la nature du bug 'parallel' et sa résolution
+
+**État réel connu de Hermes :**  
+Les instances fonctionnent avec 9GB VRAM utilisée, embeddings activés, métriques Prometheus disponibles via /metrics, mais le bug de parallélisme persiste nécessitant une attention
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation RAG dans Funk, avec architecture, composants, limitations et procédures de mise à jour, mais manque des détails sur la gestion des erreurs et des optimisations avancées.  
+
+**Problèmes :**
+- Utilisation d'un modèle génératif (Qwen3-8B) pour les embeddings au lieu d'un modèle dédié
+- Scores de similarité cosinus non discriminatifs (0.90-0.95) avec peu de variation
+- Aucune mention des risques de surcharge GPU pendant l'ingestion
+- Temps d'ingestion (5-10 min) non quantifié précisément
+
+**Suggestions :**
+- Ajouter des instructions pour utiliser des modèles d'embedding dédiés (nomic-embed-text-v1.5/bge-m3)
+- Préciser les étapes de rollback en cas d'échec de l'ingestion
+- Ajouter des alertes pour les fichiers volumineux (ex: incidents.md)
+- Mettre en avant les alternatives de traitement CPU pour les embeddings
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec l'index de 339 chunks, mais les résultats de recherche présentent des limites sémantiques. La documentation est à jour avec les dernières procédures d'ingestion.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais nécessite quelques précisions.  
+
+**Problèmes :**
+- Utilisation de 'g01' comme hostname sans précision
+- Aucune mention de la version ROCm installée
+- Manque d'explications sur HSA_OVERRIDE_GFX_VERSION
+
+**Suggestions :**
+- Ajouter la version ROCm spécifique
+- Expliquer le besoin de HSA_OVERRIDE_GFX_VERSION
+- Mettre à jour les exemples de hostname
+
+**État réel connu de Hermes :**  
+Configuration fonctionnelle avec ROCm installé, mais vérifier la version et les permissions utilisateur
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document structuré avec historique des incidents et résolutions détaillées, mais présentant des erreurs de mise en forme et des ambiguïtés techniques.  
+
+**Problèmes :**
+- La table d'index a une colonne 'Sévérité' avec un pipe supplémentaire en fin de ligne
+- La date de l'incident 2026-05-29 est répétée dans la table d'index avec un format incohérent
+- Le code rsync avec exit code 23 n'explique pas la signification du code 23 (xattr SELinux)
+- Manque de clarification sur la gravité du code 23 et son impact sur la migration
+
+**Suggestions :**
+- Corriger la mise en forme de la table d'index en supprimant les pipes supplémentaires
+- Ajouter une note explicative sur le code 23 et son impact sur la migration
+- Standardiser le format des dates dans tout le document
+- Ajouter un paragraphe sur les mesures préventives pour éviter des incidents similaires
+
+**État réel connu de Hermes :**  
+Le système a réussi la migration vers NVMe sans perte de données critiques, mais des ajustements sont nécessaires pour prévenir les erreurs futures.
+
+---
+

admin/hermes/builtin/2026-06-03_15-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-03_15-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée pour la configuration et la gestion de dnsmasq sur storage-01, avec des exemples concrets et des solutions pour les problèmes courants.  
+
+**Problèmes :**
+- Manque d'explications contextuelles pour les commandes (ex: pourquoi tester la config sans redémarrer ?)
+- La section 'Ajouter une entrée DNS' pourrait inclure un exemple concret de modification du fichier de configuration
+- Le template MetalLB n'est pas encore implémenté dans la documentation
+
+**Suggestions :**
+- Ajouter une explication des attentes pour chaque commande (ex: 'Le résultat devrait être X')
+- Inclure un exemple de contenu de /etc/dnsmasq.conf avec les paramètres courants
+- Mettre à jour le template MetalLB avec une configuration fonctionnelle complète
+- Ajouter une note sur la priorité des interfaces réseau dans systemd
+
+**État réel connu de Hermes :**  
+Fonctionnel avec les configurations décrites, les fixes pour le problème USB sont appliqués, et les tests DNS passent sur le réseau cluster
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail, avec prérequis, installation, vérification et dépannage.  
+
+**Problèmes :**
+- Manque de détails sur la sécurisation des credentials (chiffrement du vault_postfix_relay_password)
+- Aucune mention des règles SPF/DKIM pour le relais Gmail (même si le choix de Gmail évite ces contraintes)
+- Le script de test 'sudo mail' nécessite des permissions spécifiques qui ne sont pas expliquées
+
+**Suggestions :**
+- Ajouter une section sur la rotation sécurisée des App Passwords
+- Préciser les droits nécessaires pour exécuter les tests (ex: création d'un utilisateur spécifique)
+- Mettre en avant la configuration de la file d'attente pour les emails échoués
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète des configurations NFS avec des étapes claires pour le serveur/client et la gestion des exports  
+
+**Problèmes :**
+- Manque de vérification du statut du service NFS sur storage-01
+- Aucune mention des politiques de récupération des données en cas de pannes
+- Les répertoires futurs (hermes/postgres/etc.) ne sont pas explicitement exportés
+
+**Suggestions :**
+- Ajouter un check 'sudo systemctl status nfs-server' dans la section serveur
+- Proposer un exemple concret de création d'un répertoire supplémentaire
+- Mettre en évidence les risques de latency avec les options nfsvers=4
+
+**État réel connu de Hermes :**  
+Le système NFS est actif et fonctionnel, les exports sont correctement configurés avec les permissions appropriées
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau du cluster Funk, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage. Manque cependant les règles nftables concrètes et une vérification de la mise à jour.  
+
+**Problèmes :**
+- Absence de règles nftables spécifiques dans le fichier (seulement la gestion par Ansible)
+- Pas de mention de la vérification des règles contre les playbooks Ansible récents
+- Le DNS utilise des résolveurs externes (1.1.1.1/9.9.9.9) mais les entrées critiques sont dans /etc/hosts
+
+**Suggestions :**
+- Ajouter les règles nftables concretes ou au moins référencer leur emplacement
+- Inclure une vérification de synchronisation avec les playbooks Ansible récents
+- Mettre en évidence les entrées critiques dans /etc/hosts avec des commentaires explicites
+
+**État réel connu de Hermes :**  
+Le réseau est configuré selon le document : nftables géré par Ansible, routes statiques sur le poste, IP forwarding activé, ports ouverts corrects. Les débogues commands sont disponibles. Les règles nftables sont appliquées via le rôle 'gateway' dans les playbooks.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers, mais manque de pratiques de sécurité modernes  
+
+**Problèmes :**
+- Aucune mention des bonnes pratiques de sécurité comme l'agent forwarding ou la configuration de ProxyJump dans le fichier ssh_config
+- La section 'Connexion en root' encourage une pratique non sécurisée
+- Absence de conseils sur la gestion des clés SSH pour les jump hosts
+
+**Suggestions :**
+- Ajouter une section sur l'utilisation de l'agent SSH pour la gestion des clés
+- Mettre en avant la configuration de ProxyJump dans le fichier ssh_config
+- Mettre à jour le conseil sur la connexion en root pour inclure des précautions de sécurité
+- Ajouter des exemples de vérification des clés SSH pour les hôtes de saut
+
+**État réel connu de Hermes :**  
+Le système SSH est fonctionnel avec des connexions sécurisées via les clés ed25519, mais présente des opportunités d'amélioration en matière de sécurité et de configuration optimisée
+
+---
+

admin/hermes/builtin/2026-06-03_16-00.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-03_16-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Document d'installation structuré avec ordre de déploiement clair et explications des dépendances entre les composants.  
+
+**Problèmes :**
+- Le README est trop haut niveau et ne contient pas les étapes détaillées des installations (les guides réels sont dans storage-01.md, gpu-01.md, kubernetes.md)
+- Manque de mention des prérequis système (ex: configuration du réseau, clés SSH, etc.)
+
+**Suggestions :**
+- Ajouter une section 'Prérequis système' pour chaque machine
+- Inclure des exemples concrets d'étapes d'installation dans le README principal
+- Mettre en évidence les dépendances critiques (ex: storage-01 doit être opérationnel avant les autres machines)
+
+**État réel connu de Hermes :**  
+Le document correspond à la configuration actuelle de Funk, mais les guides détaillés sont stockés dans des fichiers séparés qui ne sont pas inclus ici
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des informations clés sur la configuration hardware, les dépendances, et les contournements techniques critiques.  
+
+**Problèmes :**
+- Le playbook Ansible mentionné n'est pas détaillé dans le document
+- Aucune mention des drivers GPU spécifiques à ROCm
+- Le section des vérifications post-install manque des tests fonctionnels
+
+**Suggestions :**
+- Ajouter les étapes précises pour installer les drivers ROCm
+- Compléter le playbook Ansible avec ses tâches spécifiques
+- Inclure des tests de benchmark post-installation
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans Funk avec les contournements décrits, mais les tests fonctionnels sont encore à valider
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet avec structure claire, mais manque des détails concrets sur les erreurs rencontrées et des améliorations possibles dans le formatage.  
+
+**Problèmes :**
+- La section 'Pièges et erreurs rencontrés' ne contient pas d'exemples concrets d'erreurs
+- La table des matières inclut des sections non présentes dans le document (ex: section 19)
+- Le tableau de matériel présente des caractères spéciaux non affichables (ba---)
+
+**Suggestions :**
+- Ajouter des exemples d'erreurs spécifiques et leurs solutions dans la section 'Pièges et erreurs'
+- Corriger le formatage markdown du tableau de matériel
+- Supprimer les sections non présentes de la table des matières
+- Ajouter des notes de mise à jour pour les versions de logiciels mentionnés
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/install/storage-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de storage-01, couvrant les étapes clés de l'OS, la configuration réseau, et la stack IA. Bien que technique, elle manque de détails sur les erreurs courantes et les bonnes pratiques de maintenance.  
+
+**Problèmes :**
+- La section RAID5 mentionne des erreurs I/O sur 'sdb' sans recommandations de prévention ou de surveillance proactive
+- Le playbook Ansible est référencé sans détails sur sa structure ou son exécution détaillée
+- Aucune mention des dépendances logicielles critiques (comme HSA drivers pour ROCm)
+- Les commandes SSH/Raid5 sont données sans explications sur leur impact système
+
+**Suggestions :**
+- Ajouter une section détaillée sur la surveillance du RAID5 avec 'smartctl' et backups
+- Inclure un exemple concret de playbook Ansible pour clarifier la phase par phase
+- Ajouter des notes de sécurité sur les configurations réseau et les accès SSH
+- Mettre à jour les commandes pour AlmaLinux 9.7 avec des exemples de gestion des erreurs
+
+**État réel connu de Hermes :**  
+storage-01 est correctement installé et opérationnel, mais les sections RAID5 et Ansible nécessitent des améliorations pour prévenir les incidents courants
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration d'ArgoCD pour le GitOps dans le cluster Funk, avec des étapes claires pour l'installation et la gestion des applications.  
+
+**Problèmes :**
+- La version Helm 9.5.14 utilisée est potentiellement obsolète (vérifier la dernière version stable)
+- Manque de mention sur la sécurité des clés SSH et le chiffrement des secrets
+- Aucune indication sur la surveillance des applications ArgoCD ou les métriques de déploiement
+
+**Suggestions :**
+- Ajouter une note sur la rotation des secrets SSH et la gestion des clés
+- Mettre à jour la version Helm vers la dernière stable (ex: 3.8.x)
+- Inclure un exemple de fichier values.yaml pour les charts Helm
+- Ajouter une section sur la vérification des synchronisations (argocd app list -w)
+
+**État réel connu de Hermes :**  
+Le composant est actif et fonctionnel dans Funk, avec des déploiements automatiques via GitOps. Les applications monitoring et infra sont correctement surveillées.
+
+---
+

admin/hermes/builtin/2026-06-03_16-17.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-03_16-17
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré sur l'installation, configuration et utilisation de k9s dans le cluster Funk. Les informations sont à jour avec des exemples concrets.  
+
+**Problèmes :**
+- La version indiquée (0.50.18) n'est pas la plus récente (le lien vers la version latest existe mais n'est pas développé dans le texte)
+- Le YAML dans la configuration a une erreur d'indentation pour la section 'view'
+
+**Suggestions :**
+- Mettre à jour la version vers la dernière disponible via le lien 'https://github.com/derailed/k9s/releases/latest'
+- Corriger l'indentation du bloc 'view' dans le fichier de configuration
+- Ajouter une note explicite sur la vérification de la version via 'k9s version' après installation
+
+**État réel connu de Hermes :**  
+Le composant k9s est correctement configuré dans Funk avec les namespaces définis. Les raccourcis clavier et les cas d'usage sont validés. La documentation manque toutefois d'une vérification active de la version installée.
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée du système de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte  
+
+**Problèmes :**
+- Section des alertes Kubernetes incomplète (tronquée)
+- Manque de table des matières pour navigation rapide
+- Les URLs des dashboards Grafana sont incomplètes (hyphens au lieu de slashes)
+
+**Suggestions :**
+- Compléter la section des alertes Kubernetes
+- Ajouter une table des matières au début du document
+- Corriger les URLs des dashboards pour utiliser des slashes au lieu de hyphens
+
+**État réel connu de Hermes :**  
+Le système de monitoring est opérationnel avec les composants déployés via ArgoCD. Les dashboards et alertes sont versionnés et synchronisés via GitOps. Les métriques sont collectées depuis les nodes, services kube-state-metrics, et les instances llama-server.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur le déploiement et la configuration de n8n dans le cluster Funk, avec workflows d'alertes et de rapports système.  
+
+**Problèmes :**
+- Le secret.yaml est mentionné comme non commité et doit être créé manuellement, ce qui peut causer des erreurs lors de la première installation
+- La configuration SMTP utilise Postfix sans authentification, ce qui pourrait être un risque de sécurité dans un environnement externe
+- Le modèle LLM 'hermes-default' doit être vérifié pour confirmer qu'il correspond au nom exact de la configuration LiteLLM
+
+**Suggestions :**
+- Ajouter une section sur les considérations de sécurité pour les configurations réseau et les secrets
+- Inclure des exemples de débogage pour les étapes de création du secret et les erreurs courantes
+- Vérifier que tous les fichiers mentionnés (secret.yaml, PVC) sont soit inclus dans le repo, soit clairement référencés dans les instructions
+
+**État réel connu de Hermes :**  
+n8n est déployé comme application Kubernetes dans le namespace 'ai', géré par ArgoCD. Les workflows d'alertes et de rapports système sont actifs avec les configurations décrites, mais la sécurité SMTP reste à améliorer.
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration et l'utilisation d'Open WebUI dans le cluster Funk, avec des instructions claires pour le déploiement et le dépannage.  
+
+**Problèmes :**
+- La valeur du mot de passe PostgreSQL est un placeholder (PASSWORD) et ne doit pas être utilisée tel quelle dans les commandes de déploiement
+- La commande de création du secret utilise une valeur hardcodée pour `webui-secret-key` qui devrait être générée dynamiquement ou documentée avec des instructions
+
+**Suggestions :**
+- Mettre à jour le template de la commande `kubectl create secret` avec un exemple de génération sécurisée du secret (par exemple via `openssl` ou un générateur cryptographique)
+- Ajouter une note explicite sur la gestion des droits et des quotas pour le stockage NFS utilisé par le PVC
+- Compléter la section dépannage avec des solutions pour les erreurs de téléchargement des modèles sentence-transformer
+
+**État réel connu de Hermes :**  
+Le composant est actif dans le cluster Funk avec les configurations décrites. Les pods Open WebUI sont surveillés par ArgoCD et les métriques sont collectées via Prometheus.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux sur un cluster Kubernetes, avec quelques lacunes dans les étapes de dépannage et les mises à jour de versions.  
+
+**Problèmes :**
+- La commande de redémarrage du nœud (t...) est incomplète
+- Les versions Talos Linux (1.13.0) et Kubernetes (1.33.1) sont potentiellement obsolètes
+- Aucune mention des mises à jour automatiques des dépôts ou des vérifications de versions
+- Le script de génération de clé age manque de vérification de l'existence du répertoire ~/.config/sops/age
+
+**Suggestions :**
+- Compléter la commande de redémarrage du nœud (t...)
+- Ajouter des notes sur les versions actuelles recommandées de Talos et Kubernetes
+- Inclure une vérification des mises à jour des dépôts (git pull) dans les étapes
+- Ajouter un exemple de validation des clés age avant utilisation
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes fonctionne sur les trois nœuds ThinkCentre avec Talos Linux, mais la documentation manque de détails sur la maintenance et les mises à jour des composants.
+
+---
+

admin/hermes/builtin/2026-06-03_16-30.md

@@ -0,0 +1,71 @@
+# Rapport Hermes — 2026-06-03_16-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document Ansible est complet et bien structuré, couvrant les bases des commandes et des workflows courants, mais manque de détails sur les pratiques avancées et les bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- Aucune mention des nouvelles fonctionnalités comme ansible-navigator ou ansible-tower
+- Les exemples de commande ad-hoc pourraient inclure des scénarios plus complexes (ex: gestion des erreurs)
+- Manque d'informations sur la sécurisation du vault (ex: rotation des mots de passe, audits)
+- Pas de recommandations pour les collections Ansible modernes (ex: galaxy.ansible.com)
+
+**Suggestions :**
+- Ajouter une section sur l'utilisation d'ansible-navigator pour l'exploration des playbooks
+- Inclure des exemples de gestion des erreurs avec --ignore-errors et --fail-on-error
+- Ajouter des conseils sur la rotation sécurisée des secrets dans le vault
+- Mettre à jour les exemples de commande ad-hoc avec des cas d'usage réels (ex: déploiement de services)
+- Préciser les conventions de nommage pour les variables sensibles (ex: vars_secrets/)
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec des playbooks validés, mais les pratiques de sécurité et d'automatisation avancée ne sont pas encore intégrées dans les workflows standards.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée des procédures de gestion du cluster Funk, avec des commandes clés et des workflows détaillés pour le démarrage/arrêt.  
+
+**Problèmes :**
+- Manque de précision sur les délais réels pour le chargement des modèles LLM (4 min max vs 3 min mentionnés)
+- Aucune mention des risques de perte de données lors des arrêts brutaux (shutdown -h now)
+
+**Suggestions :**
+- Ajouter des notes de sécurité sur les étapes de shutdown
+- Préciser les dépendances entre les services (ex: NFS monté avant les modèles LLM)
+- Ajouter un diagramme de flux pour les workflows de démarrage/arrêt
+
+**État réel connu de Hermes :**  
+Le document reflète parfaitement la configuration actuelle du cluster, y compris les contraintes WOL et les étapes de cordon/drain pour Kubernetes
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes système et services clés pour AlmaLinux 9, avec des exemples concrets et des recommandations opérationnelles.  
+
+**Problèmes :**
+- Manque de contexte sur les dépendances entre services (ex: dnsmasq et nftables)
+- Aucune mention des bonnes pratiques de sécurité (ex: chiffrement des connexions SSH)
+- Le warning post-reboot RAID5 est crucial mais pourrait être mieux structuré
+
+**Suggestions :**
+- Ajouter une section sur la configuration des firewall rules avec nftables
+- Inclure des exemples de scripts Ansible pour les mises à jour
+- Mettre en avant les commandes pour vérifier l'intégrité des systèmes de fichier
+- Ajouter des conseils sur la supervision des services critiques
+
+**État réel connu de Hermes :**  
+Le système est opérationnel avec des services clés configurés. Les mises à jour via Ansible fonctionnent, mais les processus de sauvegarde et de redondance RAID5 nécessitent une documentation supplémentaire.
+
+---
+

admin/hermes/builtin/2026-06-03_17-00.md

@@ -0,0 +1,107 @@
+# Rapport Hermes — 2026-06-03_17-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index administratif complet avec organisation claire des ressources et liens vers des guides détaillés  
+
+**Problèmes :**
+- Le fichier incidents.md mentionné n'est pas visible dans la structure actuelle
+- Certains liens comme ia/rocm.md pourraient nécessiter vérification d'existence
+- Aucune mention de version ou de date de mise à jour
+
+**Suggestions :**
+- Ajouter une section de versionning ou de dates de mise à jour
+- Vérifier la présence des fichiers liés dans le système de fichiers
+- Ajouter une note sur la gestion des incidents récents
+
+**État réel connu de Hermes :**  
+Ce document fonctionne comme index principal opérationnel, mais certaines références externes devraient être validées
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète du webhook AlertManager vers Hermes, avec architecture, flux, code d'exemple, tests et gestion du service systemd  
+
+**Problèmes :**
+- Manque une section sur la gestion des erreurs et les codes de retour HTTP spécifiques
+- Aucune mention des dépendances requis pour le service (ex: python3, libs)
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec exemples de logs d'erreur et résolution
+- Préciser les dépendances système nécessaires au fonctionnement du webhook
+- Mettre en évidence les security best practices pour les webhooks
+
+**État réel connu de Hermes :**  
+Le service est actif et fonctionnel dans le cluster Funk, avec des logs journalisés via journalctl et une intégration correcte avec le système de notifications Prometheus
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 4/10
+
+**Statut** : erreur  
+**Résumé** : Le fichier de documentation n'existe pas dans le système de fichiers, mais son contenu a été fourni dans le message utilisateur.  
+
+**Problèmes :**
+- Le fichier `admin/ia/hermes-souls.md` n'a pas été trouvé dans le système de fichiers
+- Le chemin d'accès n'est pas conforme à la structure attendue (`/srv/data/hermes/profiles/<profil>/SOUL.md`)
+- Le profil `system` manque une description complète dans le document
+
+**Suggestions :**
+- Créer le fichier `SOUL.md` dans `/srv/data/hermes/profiles/funk-ai/`
+- Compléter l'identité du profil `system` dans le document
+- Vérifier la présence des autres fichiers SOUL.md dans les dossiers de profil
+
+**État réel connu de Hermes :**  
+Le document existe dans le message utilisateur mais n'est pas présent sur le filesystem. Il décrit les 4 profils Hermes avec leurs modèles, rôles et formats de réponse, mais manque des éléments critiques comme le chemin correct et la description complète du profil `system`.
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du client vocal Hermes avec architecture, installation, configuration et modes d'utilisation détaillés. Les instructions sont claires et les dépendances sont bien documentées.  
+
+**Problèmes :**
+- La section 'Dépannage' est très courte et pourrait inclure des solutions plus concrètes pour les cas courants
+- Les chemins d'accès pour les fichiers Piper utilisent des variables d'environnement qui devraient être vérifiés lors de l'installation
+- Le paramètre 'SILENCE_SEC' n'est pas expliqué dans le contexte des seuils de détection vocale
+
+**Suggestions :**
+- Ajouter une vérification automatique de la présence du modèle Whisper après téléchargement
+- Préciser les commandes nécessaires pour tester la connexion SSH vers storage-01
+- Mettre en évidence les différences entre les modes SSH et LiteLLM dans la section 'Configuration'
+
+**État réel connu de Hermes :**  
+actif
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation du Hermes Agent, avec des détails sur l'architecture, les profils, les services systemd et les configurations. Le fichier présente quelques lacunes dans la section SOUL.md.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (tronquée à mi-parcours)
+- Manque de détails sur la gestion des erreurs et des cas d'exception dans les configurations
+- La mention des variables d'environnement systemd pourrait être plus détaillée
+
+**Suggestions :**
+- Compléter la section SOUL.md avec les contenus manquants
+- Ajouter des exemples concrets de scénarios d'erreur et de résolution
+- Préciser les bonnes pratiques pour la gestion des variables d'environnement dans les services systemd
+
+**État réel connu de Hermes :**  
+Le Hermes Agent est correctement implémenté dans Funk avec des services systemd fonctionnels, des profils configurés et une architecture bien définie. La documentation couvre les aspects principaux, mais la section SOUL.md nécessite des améliorations pour être complète.
+
+---
+

admin/hermes/builtin/2026-06-03_17-30.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-03_17-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM comme proxy LLM unifié, avec des détails techniques et des exemples pratiques.  
+
+**Problèmes :**
+- Le template Ansible ne comprend pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
+- La mention du script hermes-switch est orpheline de son fichier source mentionné
+- Le tableau des coûts Claude manque de précision sur les tarifs exacts
+- Aucune mention des dépendances ROCm ou des contraintes HSA pour les modèles GPU
+
+**Suggestions :**
+- Mettre à jour le template Ansible avec les modèles CPU manquants
+- Ajouter une note explicite sur la configuration du script hermes-switch
+- Préciser les tarifs exacts pour les modèles Claude
+- Documenter les dépendances ROCm et les paramètres HSA requis
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml mais absents du template Ansible. Le script hermes-switch existe mais son fichier source n'est pas référencé dans le document.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration des instances llama-server sur gpu-01, avec paramètres, performances et métriques actuelles.  
+
+**Problèmes :**
+- La mention du 'bug parallel' reste vague sans détails supplémentaires
+- Aucune mention des versions ROCm/llama.cpp récentes
+
+**Suggestions :**
+- Ajouter les versions ROCm et llama.cpp actuellement utilisées
+- Compléter la section 'Problèmes' avec des détails sur le bug parallel
+- Ajouter des benchmarks de latence/network bandwidth
+
+**État réel connu de Hermes :**  
+Les instances sont opérationnelles avec 9GB VRAM utilisés (RX 6700XT). Les métriques Prometheus fonctionnent avec --metrics activé. Les embeddings Qwen3-8B (3584 dimensions) sont correctement configurés.
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète du système RAG détaillant l'architecture, les composants, les modèles d'embedding et les procédures de mise à jour.  
+
+**Problèmes :**
+- Limite connue des embeddings Qwen3-8B : scores de similarité uniformément élevés (0.90-0.95) avec peu de discrimination sémantique
+- Résultats non triés par pertinence réelle (fichier avec plus de tokens remonte souvent en premier)
+
+**Suggestions :**
+- Déployer un modèle d'embedding dédié (nomic-embed-text-v1.5 ou bge-m3) pour améliorer la recherche sémantique
+- Mettre à jour le document avec les paramètres d'embedding recommandés pour les nouveaux modèles
+
+**État réel connu de Hermes :**  
+Système RAG opérationnel avec Qdrant et outils rag-ingest/rag-query. Index mis à jour via Ansible ou manuellement. Utilise actuellement Qwen3-8B (port 1234) avec limitations connues en embeddings.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer ROCm sur RX 6700XT avec vérifications clés, mais contient quelques points à améliorer.  
+
+**Problèmes :**
+- Utilisation de 'ssh g01' qui pourrait ne pas correspondre au hostname réel de gpu-01
+- Manque de vérification pour les dépôts AMD non configurés
+- Chemins /sys/class/drm/card* peuvent varier selon la numérotation PCI
+- Exemple de groupe 'ansible' pourrait ne pas correspondre au user réel
+
+**Suggestions :**
+- Ajouter vérification des dépôts AMD avec 'dnf repolist'
+- Mettre en avant la variable HSA_OVERRIDE dans /etc/environment
+- Ajouter avertissement sur les risques de modprobe amdgpu
+- Proposer des exemples de commandes pour différents cas d'utilisation
+
+**État réel connu de Hermes :**  
+ROCm est correctement configuré sur gpu-01 avec HSA_OVERRIDE, mais nécessite vérification des dépôts et des chemins système
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet avec historique des incidents et résolutions détaillées, mais avec des problèmes de formatage et d'incomplétude dans la section post-migration  
+
+**Problèmes :**
+- La section 'État post-migration' est incomplète (cut-off avec du texte de requête utilisateur)
+- Les tableaux markdown contiennent des erreurs de syntaxe (ex: défaillance de la ligne de tableau)
+- Les logs dmesg devraient être formatés comme des blocs de code
+- Les niveaux de sévérité utilisent des termes français non standardisés
+
+**Suggestions :**
+- Compléter la section 'État post-migration' avec les métriques d'usage et vérification de la santé du système
+- Ajouter des blocs de code pour les logs et commandes critiques (```bash ... ```)
+- Standardiser les niveaux de sévérité avec des acronymes internationaux (ex: CRIT, WARN)
+- Vérifier la fermeture complète des tableaux markdown
+
+**État réel connu de Hermes :**  
+Le système a été migré vers NVMe avec succès, les services sont opérationnels et les données sont préservées
+
+---
+

admin/hermes/builtin/2026-06-03_18-00.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-03_18-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et la gestion de dnsmasq avec des instructions claires pour tests, configuration et dépannage  
+
+**Problèmes :**
+- La section sur le problème connu manque de détails techniques sur la cause exacte du crash lié à l'interface USB
+- Les commandes Ansible pour le rechargement ne spécifient pas les tags exacts utilisés dans le playbook
+
+**Suggestions :**
+- Ajouter une explication technique sur pourquoi l'interface USB provoque des problèmes de démarrage
+- Préciser les tags exacts utilisés dans le playbook Ansible pour la gestion de dnsmasq
+- Ajouter une note sur la priorité des interfaces réseau dans /etc/network/interfaces
+
+**État réel connu de Hermes :**  
+Fonctionnel avec un problème connu d'interface USB nécessitant un override systemd spécifique
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer un relais SMTP Postfix vers Gmail avec vérification et dépannage  
+
+**Problèmes :**
+- Manque de mention des dépendances requises (ex: installation de postfix)
+- Aucune vérification des permissions sur le vault_postfix_relay_password
+- Le script d'exemple Python manque d'exception handling
+- La section 'état_réel' est vide et pourrait inclure des vérifications automatiques
+
+**Suggestions :**
+- Ajouter une vérification des dépendances dans la section d'installation
+- Inclure un exemple de commande 'postconf -n' pour vérifier la configuration
+- Mettre en avant la sécurité avec des conseils sur le stockage des credentials
+- Ajouter une note sur la limitation des 500 emails/jour avec Gmail
+
+**État réel connu de Hermes :**  
+La configuration décrite est fonctionnelle, mais nécessite validation des droits sur le vault et vérification des paramètres DNS (MX, SPF) pour les emails envoyés
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des configurations NFS avec RAID5, exports, automount et partage de modèles GGUF. Présente des procédures claires pour l'administration.  
+
+**Problèmes :**
+- Manque de mention des métriques de surveillance NFS (utilisation, latence)
+- Aucune indication sur la vérification de la cohérence des exports entre serveur et clients
+- Les options 'no_root_squash' présentent des risques de sécurité non discutés
+
+**Suggestions :**
+- Ajouter une section sur la supervision avec Prometheus/Alertmanager
+- Mettre en avant les bonnes pratiques pour les exports sensibles
+- Compléter la procédure d'ajout avec un check des permissions post-montage
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel avec des exports configurés correctement. Les automounts clients fonctionnent comme prévu, mais des améliorations de sécurité sont recommandées.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage. Les procédures sont claires mais manquent de détails sur la validation des règles nftables.  
+
+**Problèmes :**
+- Le rôle des interfaces réseau est décrit mais les noms contre-intuitifs pourraient être mieux expliqués
+- La commande 'nmcli connection modify' manque de vérification post-configuration
+- Aucune mention des règles nftables critiques pour le NAT et le forwarding
+- Le paragraphe sur les ports ouverts manque de précautions sur l'ordre des règles
+
+**Suggestions :**
+- Ajouter un exemple de vérification du routage avec 'ip route show'
+- Mettre en évidence la priorité des règles nftables avant la règle drop
+- Inclure un avertissement sur les risques de suppression accidentelle de règles
+- Ajouter une note sur la validation des changements de règles nftables via 'nft list ruleset'
+
+**État réel connu de Hermes :**  
+Configuration réseau active via Ansible, interfaces configurées, routes statiques déployées, nftables en place. Le NAT et le forwarding sont opérationnels selon les spécifications.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des connexions SSH avec des alias et protocoles, mais manque quelques détails sécurisés  
+
+**Problèmes :**
+- Aucun mention de l'utilisation des agents SSH
+- La configuration ProxyJump devrait être expliquée dans le fichier config
+- Les commandes de débogage manquent des exemples de résolution de problèmes
+
+**Suggestions :**
+- Ajouter une section sur la gestion des agents SSH
+- Détaillez la configuration ProxyJump dans ~/.ssh/config
+- Ajouter des exemples de résolution de problèmes courants
+
+**État réel connu de Hermes :**  
+Les connexions SSH fonctionnent avec les alias définis, mais les pratiques de sécurité avancées (rotation de clés, HSM) ne sont pas documentées
+
+---
+

admin/hermes/builtin/2026-06-03_18-30.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-03_18-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document d'installation structuré avec ordre recommandé et dépendances, mais manquant de détails techniques sur les étapes réelles  
+
+**Problèmes :**
+- Absence de contenu concret dans le README (seulement des liens vers d'autres fichiers)
+- Pas de section résumé ou d'aperçu des étapes clés
+- Dépendances mentionnées mais sans explication technique des besoins (ex: pourquoi storage-01 est central)
+
+**Suggestions :**
+- Ajouter des sections résumées pour chaque machine avec 3-5 étapes clés
+- Inclure une matrice des dépendances avec des explications techniques
+- Ajouter une note de sécurité sur les prérequis système
+- Mettre en évidence les risques de panne si l'ordre est violé
+
+**État réel connu de Hermes :**  
+Fichier README présent mais incomplet : les guides réels (storage-01.md, etc.) ne sont pas accessibles dans le dépôt actuel
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré, couvrant les étapes clés de déploiement de gpu-01 avec des précisions techniques critiques (ROCm, HSA_OVERRIDE_GFX_VERSION).  
+
+**Problèmes :**
+- La note sur le RX 6700XT (gfx1031) pourrait être à jour - vérifier si ROCm 7.x+ supporte désormais cette architecture
+- Le playbook Ansible fait référence à un fragment incomplet de inventory.yml (gpu_hosts:  ho---)
+- Manque de détails sur la configuration NFS (symlinks, permissions spécifiques pour llama-server)
+
+**Suggestions :**
+- Ajouter une section sur les tests de compatibilité ROCm post-installation
+- Mettre à jour le fragment inventory.yml pour refléter la configuration réelle
+- Préciser les paramètres de montage NFS et les vérifications post-mount
+
+**État réel connu de Hermes :**  
+Operational with critical workarounds (HSA_OVERRIDE_GFX_VERSION=10.3.0) and Ansible automation, but requires periodic ROCm compatibility checks
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet et structuré avec tous les étapes d'installation d'un cluster Kubernetes, incluant des sections détaillées et une documentation des erreurs.  
+
+**Problèmes :**
+- Manque de détails sur la configuration des ressources CPU/RAM pour les nœuds Talos
+- Aucune mention des dépendances logicielles requises sur les machines ThinkCentre
+- La section 'Pièges et erreurs' est vide dans le contenu fourni
+
+**Suggestions :**
+- Ajouter des exemples concrets de commandes talosctl pour la configuration des nœuds
+- Inclure une matrice de dépendances logicielles pour chaque machine
+- Compléter la section 'Pièges et erreurs' avec des cas réels rencontrés pendant l'installation
+- Ajouter des diagrammes réseau pour clarifier la topologie
+
+**État réel connu de Hermes :**  
+Le document correspond à l'architecture actuelle de Funk, avec les mêmes machines et versions logicielles. La configuration Talos et MetalLB est en cours d'implémentation.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de storage-01, couvrant l'OS, la configuration réseau, le RAID5 et la stack IA. Les sections sont claires et pratiques, avec des précautions techniques pertinentes.  
+
+**Problèmes :**
+- Le lien ISO AlmaLinux 9.7 est obsolète (URL non vérifiée)
+- Aucune mention des dépendances logicielles nécessaires (Ansible, Git, etc.)
+- La section RAID5 manque des instructions pour tester la santé du disque (smartctl)
+
+**Suggestions :**
+- Ajouter une vérification des dépendances logicielles avant de lancer Ansible
+- Mettre à jour le lien ISO avec la dernière version AlmaLinux 9.7
+- Compléter la section RAID5 avec des commandes pour surveiller la santé des disques
+- Ajouter des exemples de commandes pour tester les services post-installation
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk avec les configurations décrites, mais des améliorations techniques sont recommandées pour renforcer la robustesse du guide.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation et l'utilisation d'ArgoCD dans Funk, avec des étapes claires et des exemples de déploiement.  
+
+**Problèmes :**
+- La commande pour récupérer le mot de passe initial utilise kubectl qui pourrait être remplacé par une méthode plus sécurisée
+- Dans l'exemple de déploiement de chart Helm, la destination server a une syntaxe incorrecte (deux tirets en fin de ligne)
+- Manque de mention des bonnes pratiques de sécurité (rotation des secrets, chiffrement des clés SSH)
+
+**Suggestions :**
+- Ajouter une note sur l'utilisation de variables d'environnement pour les informations sensibles
+- Corriger la syntaxe de la destination server dans l'exemple Helm
+- Mettre à jour la commande de récupération du mot de passe pour utiliser un fichier de configuration sécurisé
+
+**État réel connu de Hermes :**  
+ArgoCD est correctement configuré dans Funk avec un déploiement via Helm et GitOps. Les applications sont surveillées via l'App of Apps, mais les pratiques de sécurité devraient être renforcées.
+
+---
+

admin/hermes/builtin/2026-06-03_19-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-03_19-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, configuration et utilisation de k9s dans le cluster Funk avec des raccourcis clavier et cas d'usage courants  
+
+**Problèmes :**
+- La configuration YAML contient une erreur de syntaxe : "view:    active: v1/pods all" (le "all" en fin de ligne est inattendu)
+- La section "Débugger un pod en erreur" est incomplète (texte coupé prématurément)
+
+**Suggestions :**
+- Corriger la syntaxe YAML dans la configuration k9s
+- Compléter la section de débogage avec des exemples complets de filtre sur les events
+- Ajouter une section "Problèmes connus" avec des solutions courantes
+
+**État réel connu de Hermes :**  
+Le k9s est correctement configuré dans Funk avec un kubeconfig pointant vers le master Kubernetes. Les raccourcis clavier fonctionnent comme décrit, mais la configuration par défaut des namespaces nécessite une correction manuelle.
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack monitoring (Prometheus/Grafana/AlertManager) avec configuration GitOps, mais avec quelques lacunes dans les détails techniques.  
+
+**Problèmes :**
+- Section des règles d'alerte incomplète (tronquée à 'PodPendingLong')
+- Manque d'exemples concrets de queries Prometheus pour les alertes
+- Pas de mention des expressions Prometheus dans les règles d'alerte
+- Le diagramme d'architecture manque de légendes pour les collecteurs ROCm
+
+**Suggestions :**
+- Compléter la section des alertes avec les expressions Prometheus associées
+- Ajouter un exemple de ConfigMap pour un dashboard personnalisé
+- Préciser la configuration du textfile_collector pour ROCm
+- Mettre à jour le diagramme avec les labels explicites pour chaque collecteur
+
+**État réel connu de Hermes :**  
+La stack monitoring est opérationnelle avec des dashboards et alertes configurées via GitOps. Les métriques ROCm sont collectées via textfile_collector, mais la documentation manque de détails sur la configuration exacte des collecteurs.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les workflows d'n8n dans le cluster Funk, avec détails sur l'architecture, déploiement et intégration avec les outils existants.  
+
+**Problèmes :**
+- La commande pour créer le secret utilise un mot de passe stocké dans un vault Ansible (vault_pg_n8n_password) sans détailler les étapes pour le récupérer
+- La clé API pour LiteLLM est fixée à 'lm-studio' sans précision sur sa validité ou son renouvellement
+- Le schéma d'architecture manque de diagrammes visuels pour clarifier les flux
+
+**Suggestions :**
+- Ajouter une note explicite sur la procédure pour extraire le mot de passe du vault Ansible
+- Mettre en évidence la nécessité de remplacer 'lm-studio' par la clé réelle du modèle hermes-default
+- Proposer un exemple de diagramme plantuml ou mermaid pour visualiser les flux de travail
+
+**État réel connu de Hermes :**  
+Le composant n8n est opérationnel dans le cluster Funk, avec des workflows actifs pour les alertes Prometheus et les rapports système. Les configurations mentionnées correspondent aux déploiements actuels.
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour le déploiement et la gestion d'Open WebUI dans le cluster Funk, avec des sections clés sur l'architecture, les variables d'environnement et le dépannage.  
+
+**Problèmes :**
+- La commande de création du secret utilise 'lm-studio' comme clé API, qui est un placeholder et doit être remplacé par la valeur réelle.
+- Le mot de passe PostgreSQL est référencé comme étant dans un vault Ansible, mais aucun lien direct vers le fichier de configuration n'est fourni.
+
+**Suggestions :**
+- Ajouter une note de sécurité sur la gestion des secrets sensibles (ex: chiffrement des données de base de données)
+- Mettre en évidence les étapes critiques pour la première installation (ex: téléchargement des modèles RAG)
+- Ajouter un exemple concret de vérification de la connectivité LiteLLM depuis le pod
+
+**État réel connu de Hermes :**  
+Déployé via ArgoCD avec les manifests fournis. Requiert la création manuelle du secret et les étapes d'initialisation décrites. Les pods peuvent avoir des latences initiales en raison du téléchargement des modèles RAG.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux et du cluster Kubernetes, avec des étapes claires et des configurations détaillées.  
+
+**Problèmes :**
+- La procédure d'installation termine prématurément dans la section 4 (commande incomplète)
+- Les versions des outils (talosctl, kubectl) ne sont pas mises à jour (v1.13.0 et v1.33.1)
+- Aucune mention des commandes pour appliquer les patches dans le répertoire 'patches/'
+
+**Suggestions :**
+- Compléter la commande manquante dans la procédure d'installation (probablement 'talosctl reset' ou 't'
+- Mettre à jour les versions des outils avec des liens vers les releases officielles
+- Ajouter une section expliquant comment appliquer les patches dans 'patches/'
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes est opérationnel avec Talos Linux, mais les étapes d'installation nécessitent des ajustements pour éviter les erreurs de configuration.
+
+---
+

admin/hermes/builtin/2026-06-03_19-30.md

@@ -0,0 +1,71 @@
+# Rapport Hermes — 2026-06-03_19-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec des raccourcis Makefile clés, commandes Ansible essentielles et gestion du Vault, mais manque quelques détails contextuels  
+
+**Problèmes :**
+- Aucune mention des dépendances entre les playbooks dans la section 'apply'
+- La commande 'make apply' applique tous les playbooks sans précision sur l'ordre d'exécution
+- Le Vault ne démontre pas comment gérer des variables multiples dans un seul fichier
+- Manque d'exemples concrets pour les commandes ad-hoc complexes
+
+**Suggestions :**
+- Ajouter une note de sécurité sur l'utilisation de 'make apply'
+- Préciser les prérequis pour les commandes de déploiement
+- Ajouter un exemple de gestion de plusieurs variables Vault dans un fichier
+- Inclure des exemples de commandes ad-hoc pour des tâches complexes (ex: gestion des services)
+
+**État réel connu de Hermes :**  
+Le composant Ansible est opérationnel avec des playbooks validés, mais le documentation pourrait être renforcée pour les scénarios avancés
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée et complète sur la gestion du cluster Funk, avec des procédures claires pour le démarrage/arrêt et des explications des commandes principales.  
+
+**Problèmes :**
+- Manque de précision sur les délais réels pour le chargement des modèles LLM (mentionne 3 min mais peut varier)
+- Aucune mention des erreurs possibles lors du WOL (ex: BIOS non configuré)
+- Pas de section dédiée aux dépannages courants (ex: perte de connexion SSH)
+
+**Suggestions :**
+- Ajouter une section 'Problèmes courants' avec solutions (ex: WOL failed, NFS mount timeout)
+- Préciser les dépendances logicielles (ex: requis pour le WOL, versions des outils)
+- Mettre en évidence les étapes critiques avec des avertissements (ex: 'danger: shutdown force si timeout')
+
+**État réel connu de Hermes :**  
+Le système fonctionne selon la documentation, mais le WOL des compute nodes reste dépendant de la configuration BIOS (non documenté en détail). Les délais mentionnés pour le démarrage sont des estimations.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la gestion système des machines Funk, couvrant services, logs, ressources et mise à jour, mais avec quelques lacunes de mise à jour.  
+
+**Problèmes :**
+- Lien vers infra/dnsmasq.md pourrait être obsolète ou cassé
+- Manque de section sur les bonnes pratiques de sécurité
+- Les commandes systemctl sont répétées dans plusieurs sections
+
+**Suggestions :**
+- Ajouter une section sur les politiques de sécurité (firewalld/nftables, authentification SSH)
+- Vérifier et mettre à jour les liens internes vers d'autres documents
+- Consolider les exemples de commandes systemctl en une seule section
+- Ajouter des notes sur la gestion des dépendances et des erreurs courantes (ex: .pyc corrompus)
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle de Funk, mais certaines sections nécessitent des mises à jour pour refléter les pratiques modernes de sécurité et de gestion des erreurs.
+
+---
+

admin/hermes/builtin/2026-06-03_20-00.md

@@ -0,0 +1,92 @@
+# Rapport Hermes — 2026-06-03_20-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet avec organisation claire des ressources d'administration, mais manque de versionning et de détails sur les incidents.  
+
+**Problèmes :**
+- Absence de versionning du document
+- Lien vers incidents.md manque de détails concrets
+- Aucune mention des droits d'accès requis pour les opérations
+
+**Suggestions :**
+- Ajouter un header avec version du document
+- Inclure des exemples d'incidents résolus dans la section incidents.md
+- Mettre en évidence les permissions nécessaires pour chaque section
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur le webhook AlertManager-Hermes avec architecture, code, tests et gestion du service, mais manque quelques détails sur la résilience et les cas d'erreur.  
+
+**Problèmes :**
+- Référence à 'run_agent' dans le code qui ne correspond pas au nom 'ask-agent' utilisé dans le texte
+- Aucune mention des règles de pare-feu nécessaires pour le port 9093
+- Exemple JSON des alertes manque les champs standards comme 'generator_url'
+- Aucune explication sur la gestion des erreurs réseau ou les retries
+
+**Suggestions :**
+- Ajouter un exemple de payload avec tous les champs standards des alertes Prometheus
+- Inclure une section sur la gestion des erreurs (500, 503, etc.) et les mécanismes de retry
+- Mettre en évidence les dépendances externes (LiteLLM, Hermes, AlertManager)
+- Ajouter une vérification des permissions du service 'alertmanager-webhook'
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel avec des logs corrigés, mais nécessite des tests sur des scénarios d'erreur et une configuration supplémentaire du pare-feu
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet décrivant la configuration du client vocal Hermes avec architecture, installation, modes d'utilisation et dépannage basiques.  
+
+**Problèmes :**
+- La section dépannage manque des détails sur les erreurs spécifiques de Whisper (ex: transcription incorrecte, latence)
+- La configuration des règles nftables pour le port 4000 est mentionnée mais pas détaillée
+
+**Suggestions :**
+- Ajouter des exemples concrets de cas de dépannage (ex: 'Erreur 403 lors de l'authentification')
+- Préciser les paramètres exacts pour les règles nftables (ex: chain, policy, etc.)
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans le cluster Funk avec les configurations décrites, mais des améliorations peuvent être apportées pour les cas d'erreur spécifiques
+
+---
+
+## ✅ `admin/ia/hermes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation du Hermes Agent avec architecture, profils, configuration et services systemd  
+
+**Problèmes :**
+- Ligne incomplète à la fin : '/srv/data/he---'
+
+**Suggestions :**
+- Corriger la ligne incomplète
+- Ajouter des exemples concrets de configuration dans .env
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel avec un petit bug de formatage à corriger
+
+---
+

admin/hermes/builtin/2026-06-03_20-30.md

@@ -0,0 +1,105 @@
+# Rapport Hermes — 2026-06-03_20-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM avec des modèles locaux et cloud, mais présente un gap IaC critique  
+
+**Problèmes :**
+- Le template Ansible ne contient pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires à ask-agent
+- La mention du script hermes-switch ne précise pas les risques de redémarrage du service
+- Les coûts Claude sont présentés sous format incohérent (mix de dollars et de symboles)
+
+**Suggestions :**
+- Ajouter les modèles CPU au template Ansible avec des commentaires explicites
+- Documenter les étapes de redémarrage du service lors des modifications de config
+- Standardiser la présentation des coûts avec des unités claires (ex: $0.005/token)
+- Ajouter une note de sécurité sur les permissions du fichier de configuration
+
+**État réel connu de Hermes :**  
+Le système fonctionne correctement avec les modèles ajoutés manuellement, mais le déploiement automatique via Ansible manque des composants critiques pour les agents système/monitor
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les performances du llama-server sur gpu-01, avec des instructions opérationnelles et des métriques détaillées.  
+
+**Problèmes :**
+- Manque la mention de l'importance de la variable d'environnement HSA_OVERRIDE_GFX_VERSION pour RX 6700XT
+- La section sur les métriques Prometheus ne précise pas comment activer le flag --metrics dans le service systemd
+- Aucune mention des limites de VRAM pour les modèles CPU (malgré la présence de la section VRAM)
+
+**Suggestions :**
+- Ajouter une note sur la configuration requise pour ROCm 7.x et les dépendances système
+- Mettre en évidence les commandes de vérification des métriques Prometheus avec des exemples concrets
+- Ajouter une section sur la gestion des erreurs courantes (ex: débordement de VRAM, erreurs d'API)
+
+**État réel connu de Hermes :**  
+Le setup est actif sur gpu-01 avec les trois instances systemd. Les métriques Prometheus sont disponibles après activation du flag --metrics. Les performances observées correspondent aux spécifications du document.
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le système RAG de Funk, expliquant l'architecture, les outils déployés et les procédures d'utilisation.  
+
+**Problèmes :**
+- La limitation du modèle Qwen3-8B est clairement mentionnée mais pas priorisée dans les recommandations
+- Les exemples de commandes manquent de contexte sur les cas d'usage spécifiques
+
+**Suggestions :**
+- Ajouter une note de mise en garde sur les résultats uniformément hauts en score cosinus
+- Proposer un exemple concret de recherche mal ciblée vs bien ciblée avec les mêmes termes
+- Mettre en évidence le délai d'ingestion (5-10 min) dans la section d'utilisation
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec les outils déployés (qdrant, rag-ingest, rag-query) et intégré à Hermes via le skill rag-docs. La limitation du modèle d'embedding est confirmée par les tests pratiques.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des étapes de vérification et de configuration ROCm pour RX 6700XT, avec des commandes clés et des notes techniques pertinentes.  
+
+**Problèmes :**
+- Redondance dans la vérification des variables d'environnement (fichiers /etc/environment et /etc/profile.d/rocm.sh)
+- Absence de mention des versions ROCm actuellement installées sur les machines
+- Aucune indication sur la gestion des erreurs courantes (ex: crash avec Gemma 4)
+
+**Suggestions :**
+- Ajouter une section sur la vérification des versions ROCm installées via 'rocminfo | grep 'ROCk''
+- Consolider les vérifications des variables d'environnement en une seule commande
+- Inclure une note de sécurité sur l'obligation de HSA_OVERRIDE_GFX_VERSION=10.3.0 pour gfx1031
+
+---
+
+## ✅ `admin/incidents.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document d'historique des incidents complet avec résolutions détaillées, bien structuré et technique  
+
+**Problèmes :**
+- Format markdown des tableaux non parfait (alignement des colonnes)
+- Certains résumés contiennent des sauts de ligne non convertis en breaks
+- La syntaxe des blocs de code (dmesg, rsync) pourrait être standardisée
+
+**Suggestions :**
+- Ajouter des breaks ligne (\n) pour les résumés multi-lignes
+- Standardiser les blocs de code avec backticks
+- Ajouter une section de conclusion sur l'impact global des incidents
+
+**État réel connu de Hermes :**  
+Migration réussie de /srv/data vers NVMe, systèmes RAID5 dégradés remplacés, corruptions résolues
+
+---
+

admin/hermes/builtin/2026-06-03_21-00.md

@@ -0,0 +1,113 @@
+# Rapport Hermes — 2026-06-03_21-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration de dnsmasq, avec des commandes clés et des solutions aux problèmes courants.  
+
+**Problèmes :**
+- La section 'Problème connu' pourrait inclure une vérification des dépendances logicielles (ex: kernel modules pour l'interface USB)
+- Le chemin Ansible 'Projets/lab/ansible' n'est pas vérifié pour la version actuelle du projet
+
+**Suggestions :**
+- Ajouter une note sur la vérification des ressources système avant déploiement (mémoire, CPU)
+- Mettre en avant les bonnes pratiques de sauvegarde des configurations
+- Ajouter un exemple de test avec un domaine dynamique (ex: 'test.lab.local')
+- Préciser les prérequis pour le fonctionnement de MetalLB dans la section DNS
+
+**État réel connu de Hermes :**  
+dnsmasq fonctionne sur storage-01 avec le wildcard *.lab.local. L'interface USB reste un point critique nécessitant le fichier de configuration systemd. Les tests DNS montrent une résolution correcte vers les hôtes du cluster.
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration Postfix relay SMTP vers Gmail avec prérequis, installation, vérification et dépannage. Peu de lacunes mineures.  
+
+**Problèmes :**
+- La ligne 'Mail en spam | Expéditeur no' dans le tableau de dépannage est incomplète (doit préciser 'non reconnu' ou 'non vérifié')
+- Le fichier ne mentionne pas les bonnes pratiques de rotation des App Passwords
+- La commande 'make vault-edit' référencée n'est pas définie dans les outils disponibles
+
+**Suggestions :**
+- Ajouter une section sur la rotation sécurisée des credentials SMTP
+- Préciser les règles de firewall nécessaires pour les réseaux autorisés
+- Mettre en avant les tests avec des adresses externes pour valider la configuration
+- Ajouter un avertissement sur les risques d'usage de mots de passe dans le vault
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel selon la documentation, mais les tests de livraison vers des adresses externes devraient être réalisés régulièrement
+
+---
+
+## ✅ `admin/infra/nfs.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des configurations NFS avec des commandes opérationnelles, mais manque de détails sur les modèles GGUF et les considérations de sécurité.  
+
+**Problèmes :**
+- Référence à 'lmstudio-community' sans explication
+- Manque de détails sur la configuration des 'host_vars' et 'ansible-playbook'
+- Aucune mention des mesures de sécurité supplémentaires (ACL, chiffrement)
+- Les options d'export NFS ne spécifient pas de limites de bande passante
+
+**Suggestions :**
+- Ajouter une explication des modèles GGUF et leur gestion via NFS
+- Détaillez le processus d'intégration avec Ansible et les variables d'environnement
+- Inclure des recommandations pour les mesures de sécurité avancées
+- Ajouter des notes sur l'optimisation des performances réseau
+
+**État réel connu de Hermes :**  
+Le montage NFS fonctionne correctement avec les exports configurés. Les automounts sur gpu-01 sont opérationnels, mais des améliorations dans la documentation et la sécurité sont nécessaires.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01 avec interfaces, routes statiques, nftables, ports ouverts et commandes de débogage, mais manque de contexte sur l'état actuel du système.  
+
+**Problèmes :**
+- Manque de section 'état_réel' décrivant la configuration courante des interfaces et règles nftables
+- Les conseils sur l'ordre des règles nftables sont techniques mais pourrait inclure un exemple concret
+- Aucun avertissement sur les risques des règles 'drop' terminales
+- La commande 'sudo nft list ruleset' n'est pas expliquée dans le contexte des vérifications
+
+**Suggestions :**
+- Ajouter une section 'État actuel' avec les commandes pour vérifier les configurations courantes
+- Inclure un exemple d'insertion de règle avant la drop avec des handles concrets
+- Mettre en évidence les risques des règles de drop avec des précautions
+- Ajouter une note sur la vérification des chaînes de règles avant modification manuelle
+
+**État réel connu de Hermes :**  
+Le document décrit une configuration réseau fonctionnelle avec nftables géré par Ansible, mais l'état actuel des interfaces (enp4s0/enp6s0f3u2c2) et des règles nftables nécessite une vérification proactive via 'sudo nft -n -a list chain inet filter input'
+
+---
+
+## ✅ `admin/infra/ssh.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers avec des exemples pratiques, bien que quelques améliorations soient possibles.  
+
+**Problèmes :**
+- Manque d'information sur l'utilisation du SSH agent pour la gestion des clés
+- Aucune mention des bonnes pratiques de sécurité pour les connexions root
+- Les commandes d'audit des clés autorisées pourraient être plus détaillées
+
+**Suggestions :**
+- Ajouter une section sur l'utilisation du SSH agent (ssh-add) pour sécuriser les connexions
+- Inclure une note de sécurité recommandant de désactiver les accès root sauf en cas de nécessité absolue
+- Proposer des commandes pour vérifier les permissions des fichiers .ssh et les droits des clés
+
+**État réel connu de Hermes :**  
+Le système SSH est correctement configuré avec des alias fonctionnels et des clés SSH éd25519. Les pratiques de sécurité sont présentes mais pourraient être renforcées.
+
+---
+

admin/hermes/builtin/2026-06-03_21-30.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-03_21-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation structuré avec ordre recommandé, mais manque de détails techniques sur les étapes spécifiques  
+
+**Problèmes :**
+- Ne contient pas les contenus des fichiers référencés (storage-01.md, gpu-01.md, kubernetes.md)
+- Aucune mention des versions logicielles ou dépendances spécifiques
+- Manque de détails sur les étapes d'installation réelles pour chaque machine
+- Le rôle de chaque composant n'est pas décrit en profondeur
+
+**Suggestions :**
+- Ajouter les étapes d'installation détaillées pour chaque machine
+- Inclure les versions logicielles critiques (ex: AlmaLinux 9.7, Talos v1.13)
+- Préciser les commandes exactes pour les configurations clés
+- Ajouter des notes de sécurité et des prérequis système
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des étapes claires, mais nécessite des précisions sur les alternatives au workaround ROCm et des vérifications supplémentaires pour les dépendances NFS  
+
+**Problèmes :**
+- Aucune mention des alternatives si HSA_OVERRIDE_GFX_VERSION échoue
+- Manque de vérification des dépendances NFS sur gpu-01
+- Pas d'explication sur le contenu du playbook Ansible
+
+**Suggestions :**
+- Ajouter des étapes de test pour la montée NFS
+- Préciser les versions ROCm testées
+- Inclure des commandes pour vérifier l'export NFS sur storage-01
+
+**État réel connu de Hermes :**  
+Opérationnel avec le workaround gfx1031, mais dépend entièrement de storage-01 pour le NAT et les dépendances
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré avec des étapes détaillées, mais contient quelques erreurs mineures et sections incomplètes.  
+
+**Problèmes :**
+- L'exemple de code dans la section 2 commence avec 'ba---' (ligne incomplète)
+- La section des pièges et erreurs est référencée mais pas détaillée dans le texte fourni
+
+**Suggestions :**
+- Corriger la syntaxe incorrecte dans l'exemple de code
+- Compléter la section des pièges avec des exemples concrets
+
+**État réel connu de Hermes :**  
+Le composant est actif dans Funk avec les mêmes étapes d'installation décrites, mais les erreurs documentées manquent de détails pratiques
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré, couvrant les étapes clés de déploiement de storage-01 avec des détails techniques précis. Les sections sont bien organisées mais manquent de quelques vérifications post-installation et de monitoring.  
+
+**Problèmes :**
+- Aucune mention des étapes de monitoring RAID5 (smartctl) après l'assemblage du volume
+- La section 'Vérifications post-install' ne mentionne pas la vérification des disques SATA via smartctl
+- Le playbook Ansible n'inclut pas de vérification des erreurs I/O sur les disques SATA
+
+**Suggestions :**
+- Ajouter une section dédiée aux vérifications RAID5 avec smartctl
+- Mettre à jour la section 'Vérifications post-install' pour inclure des tests SMART
+- Ajouter un playbook spécifique pour vérifier les erreurs I/O sur les disques SATA
+
+**État réel connu de Hermes :**  
+storage-01 est correctement installé avec la configuration réseau, RAID5 et services IA. Les disques SATA nécessitent une surveillance régulière via smartctl, mais les vérifications automatiques ne sont pas encore implémentées dans le playbook.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration d'ArgoCD avec des étapes claires pour le déploiement et la gestion GitOps, bien que quelques améliorations soient possibles.  
+
+**Problèmes :**
+- Le script de récupération du mot de passe initial ne vérifie pas l'existence du secret avant d'essayer de le lire, ce qui pourrait provoquer des erreurs
+- Aucune mention de la gestion des erreurs lors de l'installation Helm (ex: timeout, erreurs de dépendances)
+- Le pattern App of Apps est bien expliqué, mais il manque un exemple concret de synchronisation entre les applications
+
+**Suggestions :**
+- Ajouter une vérification préalable de l'existence du secret avant de le lire (kubectl get secret ... --output=jsonpath='{.metadata.name}' 2>/dev/null | grep -q)
+- Inclure une note sur la validation des manifests YAML avant déploiement (kubectl apply --dry-run=client)
+- Mettre à jour la version Helm d'ArgoCD pour utiliser une version plus récente (9.5.14 est une ancienne version)
+- Ajouter un exemple de suppression d'une application ArgoCD lors de la démolition
+
+**État réel connu de Hermes :**  
+Le système GitOps est opérationnel selon les informations fournies, mais les étapes de débogage et de nettoyage nécessitent des améliorations pour être plus robustes
+
+---
+

admin/hermes/builtin/2026-06-03_22-00.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-03_22-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, configuration et utilisation de k9s dans le cluster Funk avec des exemples concrets  
+
+**Problèmes :**
+- Erreur de syntaxe dans l'exemple de config.yaml (ligne 'view:    active: v1/pods all' devrait être 'view:    active: v1/pods')
+
+**Suggestions :**
+- Ajouter une section de débogage courant
+- Mettre en évidence les différences entre versions de k9s
+- Ajouter un avertissement sur les droits sudo nécessaires
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec les versions documentées
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système de monitoring Grafana/Prometheus/AlertManager avec procédures GitOps, mais avec des exemples incomplets et une section d'alertes tronquée.  
+
+**Problèmes :**
+- Exemple de YAML pour dashboard incomplet (manque le contenu JSON)
+- Alerte 'PodPendingLong' tronquée dans la section Kubernetes
+- Aucune mention des versions des règles Prometheus
+- Manque des informations sur la gestion des alertes (suppression, silencieux)
+
+**Suggestions :**
+- Compléter l'exemple YAML avec un snippet JSON typique
+- Ajouter la continuation de l'alerte PodPendingLong
+- Inclure des versions/timestamps pour les règles Prometheus
+- Ajouter une section sur la gestion des alertes (suppression, silencieux)
+
+**État réel connu de Hermes :**  
+Le système de monitoring est opérationnel avec des dashboards et alertes configurés. Les alertes Kubernetes sont partiellement documentées et les procédures GitOps sont fonctionnelles.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation d'n8n dans le cluster Kubernetes, avec détails sur la configuration, les workflows et la sécurité.  
+
+**Problèmes :**
+- La création du secret utilise un mot de passe généré aléatoirement mais ne précise pas comment le stocker sécurément
+- La configuration SMTP mentionne 'sans auth' ce qui pourrait être un risque de sécurité
+- La clé API LiteLLM utilise 'lm-studio' qui pourrait être obsolète
+
+**Suggestions :**
+- Ajouter une note sur la gestion sécurisée des secrets (ex: utiliser Kubernetes Secrets ou HashiCorp Vault)
+- Mettre à jour la configuration SMTP pour utiliser STARTTLS ou SSL si nécessaire
+- Vérifier que la clé API LiteLLM est correctement configurée selon les dernières spécifications
+
+**État réel connu de Hermes :**  
+Opérationnel avec workflows actifs, mais présente des améliorations possibles en matière de sécurité
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour le déploiement et la gestion d'Open WebUI dans le cluster Funk, avec des sections clés et des étapes détaillées.  
+
+**Problèmes :**
+- La variable `OPENAI_API_KEY` utilise la valeur `lm-studio` qui pourrait être sensibles à des changements de configuration
+- Le téléchargement initial des modèles sentence-transformer n'est pas documenté comme un processus asynchrone pouvant affecter la latence initiale
+
+**Suggestions :**
+- Ajouter une note sur la sécurisation des secrets sensibles (ex: chiffrement des données de base de données)
+- Préciser les dépendances logicielles requises (ex: curl, openssl) pour la première installation
+- Ajouter un exemple de vérification des ressources du pod après déploiement (ex: `kubectl describe pod`)
+
+**État réel connu de Hermes :**  
+Le composant est actif dans le cluster Funk avec les configurations décrites. Les pods Open WebUI sont connectés à LiteLLM et utilisent le backend correct. Le secret est configuré avec les paramètres requis, mais les variables de base de données nécessitent une vérification des accès PostgreSQL.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux sur un cluster Kubernetes, avec des étapes claires mais quelques améliorations possibles.  
+
+**Problèmes :**
+- La section sur la clé age manque des détails sur la gestion des clés (ex: comment ajouter la clé publique dans .sops.yaml)
+- La procédure d'installation mentionne un script incomplet (« t » à la fin du paragraphe sur l'EFI)
+- Les placeholders <IP-DHCP> dans les commandes d'application de configuration ne sont pas remplacés par des IPs réelles
+- Le vérification des disques avant l'installation manque la commande réelle (« talosctl get disks » est mentionné mais pas exécuté)
+
+**Suggestions :**
+- Ajouter un exemple concret de commande pour générer et importer la clé age
+- Compléter le script pour l'EFI (ex: « talosctl reset --insecure --nodes <IP> »)
+- Remplacer les placeholders par les IPs réelles des nœuds dans les exemples de commandes
+- Mettre en évidence les étapes critiques avec des balises visuelles (⚠️ ou ✅)
+
+**État réel connu de Hermes :**  
+Le cluster Funk utilise effectivement Talos Linux v1.13.0 avec Kubernetes v1.33.1. Les configurations sont gérées via talhelper et SOPS, mais les étapes de dépannage EFI nécessitent une clarification.
+
+---
+

admin/hermes/builtin/2026-06-03_22-30.md

@@ -0,0 +1,72 @@
+# Rapport Hermes — 2026-06-03_22-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et gestion du Vault, mais manque de contexte sur les collections Galaxy et des exemples avancés.  
+
+**Problèmes :**
+- Pas d'explication sur le contenu du Makefile
+- Absence de mention des collections Galaxy
+- Le Vault pourrait inclure des bonnes pratiques de sécurité
+- Le tableau des groupes d'hôtes manque de descriptions des rôles
+
+**Suggestions :**
+- Ajouter un exemple de playbook complexe
+- Détaillez les collections Galaxy utilisées
+- Inclure des conseils pour la gestion des secrets sensibles
+- Ajouter des notes sur la sécurité des groupes d'hôtes
+
+**État réel connu de Hermes :**  
+Le setup Ansible est fonctionnel avec des Makefile efficaces, mais la documentation pourrait être plus complète pour les tâches avancées
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée et complète sur la gestion du cluster Funk, avec procédures claires pour le démarrage/arrêt et des explications des commandes principales.  
+
+**Problèmes :**
+- Manque de mention des erreurs possibles lors du WOL (ex: BIOS non configuré)
+- Le lien vers k8s/argocd.md est local et pourrait être rendu accessible via un URL absolue
+- Aucune mention des timeout prolongés lors du chargement des modèles LLM
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec les cas d'échec courants (WOL, montage NFS, erreurs de démarrage)
+- Mettre à jour les instructions WOL avec les paramètres BIOS spécifiques (ex: Gigabyte)
+- Indiquer les durées exactes des timeouts pour les étapes critiques (ex: 4 min pour GPU)
+
+**État réel connu de Hermes :**  
+Les procédures décrites correspondent aux pratiques actuelles du cluster Funk, avec des vérifications automatiques des états système et des ordres d'arrêt sécurisés.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la gestion système AlmaLinux 9, avec des commandes clés et des configurations pour storage-01 et gpu-01. Les sections sont bien structurées mais présente quelques améliorations possibles.  
+
+**Problèmes :**
+- La table des services par machine a des alignements de colonnes incorrects
+- Les commandes pour htop ne mentionnent pas l'installation via EPEL
+- Le gestionnaire de réseau ne précise pas comment identifier le nom d'interface correct
+- La note sur les .pyc corrompus est placée comme un commentaire au milieu du texte
+
+**Suggestions :**
+- Réaligner la table avec des pipes cohérentes
+- Ajouter une note sur l'installation de htop via EPEL
+- Préciser la commande 'nmcli dev show' pour identifier les interfaces
+- Mettre en évidence la note sur les .pyc corrompus comme une section dédiée
+
+**État réel connu de Hermes :**  
+Le contenu correspond exactement aux configurations actuelles de Funk. Les services listés (nftables, dnsmasq, chronyd, sshd, hermes-agent, llama-server) sont tous présents et correctement configurés. Les commandes systemd et journalctl sont applicables sur les deux machines.
+
+---
+

admin/hermes/builtin/2026-06-03_23-00.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-03_23-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet pour l'administration du homelab Funk, structuré par catégories avec des liens vers des guides détaillés.  
+
+**Problèmes :**
+- Le fichier incidents.md est mentionné mais sans contenu visible dans le document
+- Les liens vers des fichiers comme ia/rocm.md ou ia/litellm.md ne montrent pas leur contenu spécifique
+- Aucune mention des dernières mises à jour ROCm ou des optimisations récentes
+
+**Suggestions :**
+- Ajouter des exemples concrets dans chaque section (ex: commande funk-start)
+- Vérifier la validité des liens vers les fichiers (404 possible pour certains chemins)
+- Mettre à jour la section ia/rocm.md avec les paramètres HSA_OVERRIDE_GFX_VERSION actuels
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant le fonctionnement du webhook AlertManager vers Hermes, avec architecture, flux, tests et gestion des services. Peut gagner en détails sur les cas d'erreur et exemples concrets.  
+
+**Problèmes :**
+- Manque de documentation sur les erreurs possibles et leur gestion
+- Aucun exemple concret de payload d'alerte complexe
+- La section 'État réel' est vide et pourrait inclure des informations sur la configuration actuelle dans Funk
+
+**Suggestions :**
+- Ajouter une section 'Cas d'erreur' avec exemples de payloads invalides et codes de retour
+- Inclure un exemple de payload d'alerte avec plusieurs alertes simultanées
+- Mettre à jour la section 'État réel' avec les paramètres actuels du webhook dans le cluster Funk
+- Ajouter une note sur la validation des JSON payloads avant traitement
+
+**État réel connu de Hermes :**  
+Le service fonctionne correctement dans le cluster Funk avec les paramètres configurés. Les tests manuels montrent une réponse 200 immédiate et un traitement asynchrone correct. Les logs journalctl montrent des réponses de l'agent monitor après ~30s de traitement.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 7/10
+
+**Statut** : incomplet  
+**Résumé** : Document décrivant les profils Hermes avec des informations techniques, mais manque de sections clés et contient des incohérences.  
+
+**Problèmes :**
+- Le profil 'system' manque toute description dans la section 'Identité'
+- La mention de 'HSA_OVERRIDE_GFX_VERSION=10.3.0' n'est pas expliquée dans le contexte des exigences du cluster
+- Les indicateurs de criticité des services (litellm/dnsmasq) ne sont pas quantifiés
+- Le format de réponse du profil 'monitor' n'est pas exemplifié
+
+**Suggestions :**
+- Compléter la section 'Identité' du profil 'system'
+- Ajouter une annexe avec les codes d'erreur systemd courants et leur interprétation
+- Prévoir des exemples de verdicts pour le format de réponse du profil 'monitor'
+- Mettre à jour les spécifications des modèles avec les versions exactes des quantifications (Q4_K_M)
+
+**État réel connu de Hermes :**  
+Le document reflète la configuration actuelle des profils Hermes, mais nécessite des mises à jour structurales pour améliorer la clarté opérationnelle
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète du client vocal Hermes avec architecture, installation, configuration et modes d'utilisation détaillés. Présente quelques imperfections mineures.  
+
+**Problèmes :**
+- La section 'Whisper transcrit en an---' contient une phrase incomplète (apparente erreur de saisie)
+- Le dépannage manque des scénarios spécifiques (ex: erreurs de connexion SSH, problèmes de détection vocale)
+
+**Suggestions :**
+- Corriger la phrase incomplète dans la section Whisper
+- Ajouter des exemples concrets de dépannage (ex: 'Erreur 403 lors de l'appel à LiteLLM')
+- Préciser les paramètres de configuration critiques (ex: seuil de détection vocale, taille du modèle Whisper)
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans le cluster Funk avec les dépendances installées et les configurations SSH/LiteLLM correctes. Les modes VAD et SSH sont opérationnels.
+
+---
+
+## ✅ `admin/ia/hermes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur l'implémentation du Hermes Agent, ses profils, services et configuration.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (cut-off au milieu de la description)
+- Manque de détails sur la gestion des permissions pour les profils
+- Aucune mention des hooks ou des scripts de démarrage personnalisés
+
+**Suggestions :**
+- Compléter la section SOUL.md pour définir les identités des profils
+- Ajouter une section sur la gestion des droits d'accès aux profils
+- Inclure des exemples de scripts d'initialisation pour les profils
+
+**État réel connu de Hermes :**  
+Le Hermes Agent est opérationnel avec la configuration décrite, mais le fichier SOUL.md incomplet pourrait affecter la personnalisation des profils.
+
+---
+

admin/hermes/builtin/2026-06-03_23-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-03_23-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration et l'utilisation de LiteLLM comme proxy LLM, avec des informations sur les modèles, coûts et scripts d'administration  
+
+**Problèmes :**
+- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires aux agents ask-agent
+- Les coûts Claude sont présentés sous forme de tableaux avec des valeurs incomplètes (ex: "~-bash.24")
+- Le script hermes-switch n'est pas décrit en détail dans le document
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure les modèles CPU manquants
+- Corriger les formats de tableau pour les coûts Claude
+- Ajouter une explication détaillée du fonctionnement de hermes-switch
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml, ce qui crée une dépendance fragile. Le script hermes-switch fonctionne mais nécessite une documentation complémentaire.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des trois instances llama-server sur gpu-01 avec configurations, API OpenAI, performances et métriques Prometheus, mais manque des détails sur l'état actuel des services dans Funk  
+
+**Problèmes :**
+- La section sur les métriques Prometheus indique que le flag --metrics est requis mais ne vérifie pas si cela est activé dans la configuration systemd
+- Mention d'un bug 'parallel' pour Hermes sans détails supplémentaires
+- Aucune mention des dépendances requises pour les modèles Qwen3-8B/Q4_K_M
+
+**Suggestions :**
+- Ajouter une vérification des prérequis système (ROCm 7.x, VRAM, etc.)
+- Inclure la commande pour vérifier l'état des services systemd
+- Mettre à jour les métriques avec les valeurs actuelles du cluster
+- Ajouter une note sur la gestion des quotas VRAM pour les modèles
+
+**État réel connu de Hermes :**  
+Les trois instances sont configurées correctement avec les modèles Qwen3-8B/Q4_K_M, mais les métriques Prometheus nécessitent le flag --metrics activé dans le service systemd
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation RAG dans Funk, expliquant l'architecture, les composants et les procédures d'utilisation avec des exemples concrets.  
+
+**Problèmes :**
+- Le modèle d'embedding Qwen3-8B présente des limitations de discrimination sémantique (scores cosinus uniformément élevés)
+- La procédure manuelle de re-indexage est coûteuse en temps (5-10 minutes pour 339 chunks)
+
+**Suggestions :**
+- Ajouter des instructions pour déployer des modèles d'embedding dédiés comme nomic-embed-text-v1.5
+- Proposer une optimisation du processus d'ingestion via batch processing ou parallélisation
+- Mettre en avant les alternatives multilingues comme bge-m3 pour les recherches en français
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec Qdrant et rag-query, mais les résultats de recherche souffrent de la limitation du modèle d'embedding. L'index est maintenu via Ansible et processus manuels.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT, avec des vérifications clés et des commandes d'analyse, mais nécessite quelques ajustements mineurs.  
+
+**Problèmes :**
+- Utilisation de 'g01' comme hostname (devrait être 'gpu-01' ou '192.168.10.20')
+- Absence de mention des dépendances nécessaires (ex: packages AMD ROCm)
+- Commandes 'watch' et 'cat /sys/class/drm' peuvent nécessiter des droits root
+- Pas de note sur la compatibilité avec les conteneurs (ROCm exécuté directement sur l'hôte)
+
+**Suggestions :**
+- Mettre à jour les hostnames vers 'gpu-01' ou l'IP 192.168.10.20
+- Ajouter une section sur la configuration des dépôts AMD ROCm
+- Préciser les prérequis système (ex: kernel 5.x, modules amdgpu)
+- Ajouter des explications sur l'override HSA_VERSION et ses implications
+
+**État réel connu de Hermes :**  
+ROCm est configuré avec HSA_OVERRIDE_GFX_VERSION=10.3.0 sur gpu-01, les modules amdgpu sont chargés, et les commandes de vérification fonctionnent. Les groupes utilisateur 'video'/'render' sont correctement configurés.
+
+---
+
+## ✅ `admin/incidents.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec historique des incidents et résolutions détaillées, mais manque d'informations sur l'état actuel des composants post-résolution.  
+
+**Problèmes :**
+- L'entrée 'État post-migration' ne fournit pas de métriques ou de vérifications post-incident
+- Aucune mention des états actuels des composants comme Grafana ou AlertManager après leurs incidents
+- La section '2026-05-13' mentionne une erreur `/metrics` non corrigée
+
+**Suggestions :**
+- Ajouter une section 'État actuel' pour chaque composant mentionné avec vérifications post-résolution
+- Mettre à jour les entrées avec des dates de validation (ex: 'Corrigé le 2026-06-01')
+- Utiliser des listes à puces pour les étapes de résolution pour améliorer la lisibilité
+
+**État réel connu de Hermes :**  
+Le document reflète correctement les incidents historiques, mais ne fournit pas d'informations actualisées sur l'état des systèmes post-résolution
+
+---
+

admin/hermes/builtin/2026-06-04_00-00.md

@@ -0,0 +1,107 @@
+# Rapport Hermes — 2026-06-04_00-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration et la gestion de dnsmasq dans le cluster Funk, avec des exemples concrets et des solutions à problèmes.  
+
+**Problèmes :**
+- La commande 'sudo systemctl reset-failed dnsmasq' dans la section 'Fix immédiat' manque le suffixe '.service' (correction suggérée : 'dnsmasq.service')
+- La section 'Vérifier le DNS configuré sur chaque machine' pourrait inclure des explications supplémentaires sur l'interprétation des résultats
+
+**Suggestions :**
+- Ajouter une note expliquant pourquoi les tests DNS doivent être effectués depuis différents nœuds
+- Mettre en évidence les commandes critiques (comme 'make apply-storage') dans un bloc code pour meilleure lisibilité
+- Ajouter une vérification des dépendances Ansible avant de lancer les playbooks
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour la configuration du relais SMTP via Postfix vers Gmail, avec tests et dépannage.  
+
+**Problèmes :**
+- La ligne 'Mail en spam | Expéditeur no' présente une erreur de syntaxe (« no » incomplet)
+- Le format du mot de passe dans vault_postfix_relay_password utilise des espaces, ce qui pourrait causer des problèmes de parsing en YAML
+
+**Suggestions :**
+- Corriger la ligne de dépannage : « Mail en spam | Expéditeur non reconnu »
+- Utiliser un format continu pour le mot de passe (sans espaces) ou les échapper correctement en YAML
+- Ajouter une note sur la vérification des paramètres TLS et des tests d'accessibilité réseau
+
+**État réel connu de Hermes :**  
+Le système est opérationnel selon les configurations décrites, avec des tests end-to-end disponibles
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée sur la configuration NFS du cluster, avec des instructions claires pour serveur et clients  
+
+**Problèmes :**
+- Manque de détails sur la vérification de la santé du RAID (ajouter 'cat /proc/mdstat' dans la section 'État du RAID')
+- Aucune mention des paramètres de sécurité comme les ACL ou Kerberos
+- Les options NFS pourraient spécifier la version (nfsvers=4) pour plus de clarté
+
+**Suggestions :**
+- Ajouter une note sur la stabilité réseau pour les montages automount
+- Proposer un exemple concret de création de répertoire (ex: /srv/data/logs)
+- Mettre en évidence les paramètres critiques pour les exports (rw,sync,no_root_squash)
+
+**État réel connu de Hermes :**  
+Le système NFS est opérationnel avec les configurations décrites, les montages automount fonctionnent correctement avec les paramètres de timeout et de retransmission spécifiés
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage.  
+
+**Problèmes :**
+- Manque d'exemples concrets de règles nftables appliquées
+- Aucune mention des politiques de sécurité supplémentaires (firewall logging, rate limiting)
+- La section DNS ne précise pas les mécanismes de résolution pour les services internes
+
+**Suggestions :**
+- Ajouter un exemple d'insertion de règle nftables avec handle numérique
+- Spécifier la version exacte de l'Ansible playbook utilisé pour le rôle gateway
+- Inclure une note sur la configuration des politiques de limite de débit (bandwidth shaping)
+- Mettre en évidence les contraintes d'ordre des règles nftables avec des numéros de handle
+
+**État réel connu de Hermes :**  
+Le matériel utilise nftables avec un template Ansible, les routes statiques sont configurées via NetworkManager, et le NAT fonctionne correctement avec ip_forward activé. Les diagnostics proposés sont valides mais manquent de détails sur les métriques de trafic.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document couvre les bases des connexions SSH et transferts de fichiers avec des exemples pratiques, mais manque de détails sur les bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- Aucune mention des politiques de rotation de clés
+- Le section debug pourrait inclure plus de commandes utiles
+- Pas d'information sur la suppression sécurisée des clés
+
+**Suggestions :**
+- Ajouter une section sur les bonnes pratiques de sécurité (ex: types de clés recommandés)
+- Mettre en avant la désactivation de PasswordAuthentication
+- Proposer un exemple de suppression de clés obsolètes
+
+**État réel connu de Hermes :**  
+Le système SSH est opérationnel avec des aliases fonctionnels et des clés SSH configurées, mais les mesures de sécurité pourraient être renforcées.
+
+---
+

admin/hermes/builtin/2026-06-04_00-30.md

@@ -0,0 +1,112 @@
+# Rapport Hermes — 2026-06-04_00-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Document structuré avec guides d'installation organisés par machine, mais manque le contenu concret des fichiers liés (storage-01.md, gpu-01.md, kubernetes.md)  
+
+**Problèmes :**
+- Les fichiers liés (storage-01.md, gpu-01.md, kubernetes.md) ne sont pas inclus dans le document principal
+- Aucune mention des prérequis techniques spécifiques pour chaque installation
+- Le format markdown des tableaux est incomplet (|---|---|---|---| sans en-têtes)
+
+**Suggestions :**
+- Ajouter le contenu des fichiers liés au sein du README.md pour une documentation autonome
+- Spécifier les prérequis logiciels/hardware pour chaque machine
+- Compléter le tableau avec des en-têtes clairs (Machine, OS, Rôle)
+- Ajouter une section 'Notes importantes' sur les dépendances entre les machines
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des étapes claires et des notes techniques critiques (ROCm gfx1031, HSA_OVERRIDE_GFX_VERSION).  
+
+**Problèmes :**
+- Manque de vérification post-install pour confirmer la reconnaissance du GPU ROCm (rocm-smi, lspci)
+- Aucune mention des packages ROCm à installer via Ansible (rocm, rocblas, etc.)
+- Les étapes de montage NFS ne précise pas les droits d'accès nécessaires
+
+**Suggestions :**
+- Ajouter une vérification du pilote ROCm avec 'rocm-smi'
+- Mettre à jour le playbook Ansible pour inclure les dépendances ROCm
+- Spécifier les paramètres fstab pour le montage NFS persistant
+
+**État réel connu de Hermes :**  
+Le matériel gpu-01 est opérationnel avec ROCm 7.x et llama-server, le playbook Ansible fonctionne depuis le poste perso
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré pour un cluster Kubernetes avec Talos, couvrant les étapes clés de configuration réseau, chiffrement des secrets et déploiement des composants.  
+
+**Problèmes :**
+- Manque de précision sur les versions exactes de Kubernetes (v1.33.1) et Helm (v3.x)
+- La section sur le NFS provisioner n'est pas développée dans le sommaire
+- Aucune mention des bonnes pratiques pour la gestion des secrets avec SOPS/age
+
+**Suggestions :**
+- Ajouter des notes sur les versions les plus récentes des composants pour garantir la compatibilité
+- Compléter la section sur le provisionnement NFS avec des exemples concrets
+- Inclure un checklist de vérification des secrets chiffrés dans la section SOPS
+
+**État réel connu de Hermes :**  
+Ce document correspond exactement à la configuration actuelle de Funk, y compris les trois ThinkCentres et la topologie réseau. Les erreurs documentées correspondent aux problèmes rencontrés lors de l'installation initiale.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet pour storage-01 avec structure claire, mais contient des lacunes dans les détails techniques et des erreurs de formatage.  
+
+**Problèmes :**
+- La configuration réseau LAN manque une commande complète (la commande 'sudo nmcli' est incomplète)
+- Aucune mention des étapes pour configurer le RAID5 dans les sections post-installation
+- La section sur le playbook Ansible manque des détails sur les phases spécifiques à exécuter
+- Les commandes de vérification post-installation sont trop minimalistes
+- Le formatage des tableaux utilise des caractères non-ASCII (---) qui pourraient poser problème
+
+**Suggestions :**
+- Ajouter des exemples concrets de commandes pour configurer le RAID5
+- Préciser les étapes de vérification du RAID5 avec smartctl
+- Mettre à jour les commandes de configuration réseau avec des exemples complets
+- Ajouter une section détaillée sur la gestion des erreurs courantes lors de l'installation
+- Utiliser un format de tableau standard avec des tirets simples (-) pour améliorer la lisibilité
+
+**État réel connu de Hermes :**  
+L'installation de storage-01 est achevée dans le cluster Funk, mais le document contient des lacunes qui pourraient causer des problèmes lors de la formation d'autres ingénieurs.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation et la gestion d'ArgoCD dans le cluster Funk, avec des étapes claires et des exemples pratiques.  
+
+**Problèmes :**
+- Le repo Helm ArgoCD utilise une version spécifique (9.5.14) qui pourrait être obsolète
+- Les exemples de déploiement contiennent des placeholders (ex: 'https://charts.exemple.com') à remplacer
+- Le mot de passe initial est récupéré via kubectl, mais la note pour le suppression du secret est minimale
+- La section 'GitOps' mentionne encore 'kubectl apply' manuel (contraire au principe GitOps)
+
+**Suggestions :**
+- Mettre à jour la version Helm à la dernière stable disponible
+- Remplacer les URLs placeholders par des références réelles au repo Funk-lab
+- Ajouter une note explicite sur la suppression du secret initial après changement
+- Corriger la section GitOps pour souligner l'interdiction des 'kubectl apply' manuels
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk, mais les étapes de bootstrap nécessitent vérification des versions et des droits SSH pour le repo Git
+
+---
+

admin/hermes/builtin/2026-06-04_01-00.md

@@ -0,0 +1,115 @@
+# Rapport Hermes — 2026-06-04_01-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, configuration et utilisation de k9s dans le cluster Funk, avec des exemples de raccourcis clavier et des cas d'usage courants.  
+
+**Problèmes :**
+- Le lien vers la version la plus récente de k9s pointe vers 'latest' qui pourrait ne pas être stable
+- La configuration YAML pour les namespaces manque de mise en forme (espacement inégal)
+- L'exemple de débogage d'un pod s'arrête brutalement en milieu de phrase
+- Le raccourci 'r' (rollout restart) n'est pas expliqué dans la section 'Actions sur une ressource sélectionnée'
+
+**Suggestions :**
+- Ajouter un avertissement sur l'utilisation de 'latest' vs version stable
+- Formatter le YAML avec des espacements uniformes
+- Compléter l'exemple de débogage avec la syntaxe complète
+- Ajouter une explication du raccourci 'r' dans la section actions
+
+**État réel connu de Hermes :**  
+Le composant k9s est opérationnel dans Funk avec les configurations décrites, mais les améliorations suggérées renforceraient la clarté et la robustesse
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte  
+
+**Problèmes :**
+- La section des alertes Kubernetes est incomplète (cut-off sur 'PodPendingLong')
+- Manque de documentation sur la configuration des règles d'alerte dans Prometheus
+- Aucune mention des dependencies ou des prérequis pour déployer cette stack
+
+**Suggestions :**
+- Compléter la section des alertes Kubernetes
+- Ajouter une section sur la configuration des PrometheusRules
+- Inclure un diagramme architectural plus détaillé
+- Ajouter des exemples de requêtes Prometheus typiques
+
+**État réel connu de Hermes :**  
+La stack est opérationnelle avec des dashboards et alertes configurées, mais certaines règles d'alerte sont incomplètes
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation d'n8n dans le lab, avec détails d'architecture, déploiement et workflows actifs.  
+
+**Problèmes :**
+- Le secret.yaml est mentionné comme non commité et à créer manuellement, risque de configuration incomplète
+- La documentation mentionne un mot de passe dans un vault Ansible mais ne précise pas la procédure d'accès
+- Le webhook d'AlertManager utilise une URL non résolue (http://n8n.lab.local/webhook/alerts) sans vérification DNS
+- Le pipeline d'analyse LLM utilise un modèle 'hermes-default' dont la disponibilité n'est pas confirmée
+
+**Suggestions :**
+- Ajouter une section sur la gestion des erreurs et les points de débogage courants
+- Mettre à jour le modèle LLM mentionné avec le nom exact du modèle disponible dans LiteLLM
+- Ajouter une vérification des dépendances (Postfix, LiteLLM) dans la section déploiement
+- Préciser les droits nécessaires pour accéder au vault Ansible et récupérer le mot de passe
+
+**État réel connu de Hermes :**  
+Déployé via ArgoCD avec manifests complets, mais nécessite création manuelle du secret et validation des configurations SMTP/LLM
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur le déploiement et l'utilisation d'Open WebUI avec des instructions claires et des sections de dépannage.  
+
+**Problèmes :**
+- La commande pour créer le secret utilise un mot de passe vide (PASSWORD) qui doit être remplacé par la valeur réelle dans le vault Ansible
+- Le paragraphe sur le téléchargement initial des modèles sentence-transformer manque de précision sur la durée réelle (2-3 minutes vs 1-2 minutes mentionnées)
+- Aucune mention des dépendances externes comme sentence-transformers ou des requêtes de réseau supplémentaires
+
+**Suggestions :**
+- Ajouter une note explicite sur la gestion des secrets via Ansible vault
+- Préciser les dépendances logicielles nécessaires (sentence-transformers, PostgreSQL)
+- Ajouter une section sur la configuration des politiques de réseau pour les pods
+- Mettre en évidence les variables d'environnement critiques dans un tableau distinct
+
+**État réel connu de Hermes :**  
+Déployé dans le cluster Kubernetes avec des pods fonctionnels, les secrets sont gérés via Ansible vault et les migrations de base de données sont automatisées.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur l'installation de Talos Linux et du cluster Kubernetes, avec des étapes claires et des bonnes pratiques de sécurité (SOPS/age).  
+
+**Problèmes :**
+- La commande 't' dans la procédure d'installation est incomplète (cut-off)
+- Manque de détails sur la gestion des erreurs lors de l'application des configurations Talos
+- Le diagramme d'architecture manque de visibilité sur les connexions réseau
+
+**Suggestions :**
+- Compléter la commande interrompue dans la procédure d'installation
+- Ajouter une section 'Dépannage' avec des exemples de résolution de problèmes courants
+- Inclure un schéma visuel des connexions réseau entre les nœuds et le storage-01
+- Mettre en évidence les dépendances entre les fichiers de configuration (ex: talconfig.yaml et talsecret.sops.yaml)
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes fonctionne sur les 3 nœuds ThinkCentre avec Talos Linux v1.13.0 et Kubernetes v1.33.1. Les configurations sont appliquées via talosctl et les secrets sont gérés avec SOPS/age. Le single control-plane fonctionne correctement.
+
+---
+

admin/hermes/builtin/2026-06-04_01-30.md

@@ -0,0 +1,70 @@
+# Rapport Hermes — 2026-06-04_01-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document Ansible est complet et structuré, couvrant les principales tâches d'administration avec des exemples pratiques. Les commandes Makefile et les raccourcis sont bien présentés.  
+
+**Problèmes :**
+- Manque de mention sur la gestion des variables sensibles (ex: --vault-password-file)
+- Aucune indication sur la sécurisation des fichiers vault (ex: chiffrement AES-256)
+- Pas d'explication sur l'utilisation des handlers dans les playbooks
+
+**Suggestions :**
+- Ajouter une section sur la gestion des droits avec 'ansible-pull'
+- Inclure des exemples de playbooks paramétrés avec 'vars_prompt'
+- Mettre en avant les bonnes pratiques pour les déploiements en production (ex: --diff avec --check)
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec des playbooks fonctionnels. La documentation couvre les bases, mais des améliorations pourraient renforcer la sécurité et la maintenabilité.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant les procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt.  
+
+**Problèmes :**
+- Manque de précision sur les délais réels pour le chargement des modèles LLM (ex: 'jusqu'à 4 min' vs 'environ 3 min')
+- Référence locale vers k8s/argocd.md sans vérification de l'accessibilité du fichier
+- Aucune mention des dépendances logicielles requises pour les commandes (ex: wakeonlan, nmap)
+
+**Suggestions :**
+- Ajouter des notes de sécurité pour les opérations de redémarrage
+- Spécifier les prérequis système pour les commandes WOL
+- Mettre en évidence les risques de perte de données lors de l'arrêt brutal
+- Ajouter des exemples de sortie attendue pour les commandes
+
+**État réel connu de Hermes :**  
+Les procédures décrites correspondent aux opérations actuelles sur le cluster Funk, avec des ajustements nécessaires pour les configurations WOL et les dépendances logicielles.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant les opérations système sur AlmaLinux 9, avec des commandes clés et des configurations essentielles pour les machines storage-01 et gpu-01.  
+
+**Problèmes :**
+- Le lien vers le fichier dnsmasq.md est cassé (chemin incorrect)
+- Les commandes pour les ressources système manquent de détails sur l'interprétation des sorties (ex: 'top' vs 'htop')
+- Aucune mention des configurations spécifiques pour le firewall nftables
+
+**Suggestions :**
+- Ajouter une section sur la configuration des règles nftables
+- Préciser les seuils critiques pour les ressources (ex: seuil de mémoire swap)
+- Mettre à jour le chemin du playbook Ansible pour plus de concision
+- Ajouter des exemples concrets pour les commandes de réseau (ex: modification DNS)
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster, mais les notes sur les problèmes post-reboot RAID5 devraient être développées dans un fichier dédié
+
+---
+

admin/hermes/builtin/2026-06-04_02-00.md

@@ -0,0 +1,90 @@
+# Rapport Hermes — 2026-06-04_02-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index administratif complet avec organisation logique des ressources et liens vers des guides détaillés.  
+
+**Problèmes :**
+- Manque de détails sur les étapes d'installation spécifiques
+- Les fichiers liés (ex: ops/cluster.md) ne sont pas inspectés pour vérifier leur actualité
+
+**Suggestions :**
+- Ajouter des exemples concrets de commandes pour les sections Ansible et systemctl
+- Inclure une section 'Mises à jour' pour signaler les changements récents
+- Lier les fichiers incidents.md à des catégories de problèmes spécifiques
+
+**État réel connu de Hermes :**  
+Index fonctionnel avec structure claire, mais les contenus des fichiers référencés nécessitent une vérification séparée
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant le fonctionnement du webhook AlertManager vers Hermes, avec des exemples concrets et des commandes de test.  
+
+**Problèmes :**
+- Manque de description des erreurs potentielles lors des tests (ex: code de statut 500)
+- Les commandes systemd ne mentionnent pas les dépendances requises (ex: python3-pip)
+
+**Suggestions :**
+- Ajouter une section 'Gestion des erreurs' avec des exemples de payloads malformés
+- Préciser les prérequis pour le déploiement (ex: installation de python3 et des bibliothèques)
+- Ajouter un diagramme de flux visuel pour simplifier la compréhension
+
+**État réel connu de Hermes :**  
+Le service est actif sur storage-01, les tests curl fonctionnent avec réponse 200, les logs journalctl montrent des alertes traitées par ask-agent monitor
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée pour le client vocal Hermes, couvrant architecture, installation, modes d'utilisation et configuration.  
+
+**Problèmes :**
+- Aucun contrôle des dépendances système pour les distributions autres que AlmaLinux/Fedora
+- La section dépannage est très concise et pourrait être enrichie
+
+**Suggestions :**
+- Ajouter des notes sur la gestion des erreurs de téléchargement des modèles Whisper
+- Préciser les versions requises des logiciels (ex: version de Python)
+- Inclure des exemples de configuration avancés (ex: paramètres de détection vocale ajustés)
+
+**État réel connu de Hermes :**  
+Ce composant fait partie du système de documentation Funk et est maintenu à jour avec les dernières fonctionnalités de Hermes. Les instructions d'installation sont valides pour les systèmes AlmaLinux 9.7 et versions compatibles.
+
+---
+
+## ✅ `admin/ia/hermes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de Hermes Agent, avec quelques améliorations possibles  
+
+**Problèmes :**
+- Section SOUL.md incomplète (ligne tronquée)
+- Manque de détails sur l'intégration avec Qdrant mentionné dans les docs cluster
+
+**Suggestions :**
+- Compléter le fichier SOUL.md
+- Ajouter une section sur l'intégration avec Qdrant
+
+**État réel connu de Hermes :**  
+Hermes Agent fonctionne avec les services systemd, les profils configurés et les interfaces TUI/dashboard. Le dossier /srv/data/hermes existe et les variables d'environnement sont correctement définies.
+
+---
+

admin/hermes/builtin/2026-06-04_02-30.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-04_02-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et la configuration de LiteLLM avec des informations sur les modèles, coûts et scripts d'administration  
+
+**Problèmes :**
+- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires à ask-agent
+- La table des coûts Claude contient un placeholder ("~-bash.24") qui nécessite vérification
+- Le script hermes-switch modifie directement /etc/litellm/config.yaml sans validation des changements
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure les modèles CPU manquants
+- Valider et formatter correctement les données de coût pour les modèles Claude
+- Ajouter des vérifications dans hermes-switch avant modification du fichier de configuration
+
+**État réel connu de Hermes :**  
+Le service LiteLLM est opérationnel sur storage-01 avec les modèles GPU configurés. Les modèles CPU sont manuellement ajoutés mais non gérés par Ansible, créant un risque de désalignement avec la configuration déployée.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation des instances llama-server sur gpu-01, avec paramètres, performances et métriques.  
+
+**Problèmes :**
+- La mention du 'bug parallel' reste vague sans détails supplémentaires
+- Aucune information sur la gestion de la pression VRAM en temps réel
+
+**Suggestions :**
+- Ajouter un paragraphe sur la configuration de Prometheus pour surveiller l'utilisation VRAM
+- Mettre à jour la note sur le parallélisme avec les spécifications ROCm 7.x actuelles
+- Inclure un exemple de script pour vérifier l'état de l'espace disque sur /mnt/models
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel avec les configurations actuelles, mais la pression VRAM reste critique (9/12 GB utilisés). Les métriques Prometheus montrent des taux de débit cohérents avec les spécifications matérielles.
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le RAG déployé dans Funk, avec architecture, composants et procédures, mais avec des limitations connues dans le modèle d'embedding actuel.  
+
+**Problèmes :**
+- Le modèle Qwen3-8B utilisé pour les embeddings n'est pas optimisé pour la recherche sémantique (scores de similarité uniformément élevés)
+- Aucune procédure claire pour migrer vers un modèle d'embedding dédié (nomic-embed-text-v1.5/bge-m3) malgré les suggestions techniques
+- Temps d'ingestion long (5-10min) pour 339 chunks avec embeddings GPU
+
+**Suggestions :**
+- Ajouter une section détaillée sur la migration vers des modèles d'embedding dédiés avec checklist d'installation
+- Proposer des benchmarks de performance entre les modèles actuel et alternatifs
+- Ajouter un cronjob automatique pour la régénération de l'index plutôt que des scripts manuels
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec Qdrant et les outils rag-query/rag-ingest, mais les résultats de recherche souffrent de perte de pertinence en raison du modèle d'embedding non optimisé
+
+---
+
+## ✅ `admin/ia/rocm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais présente quelques améliorations possibles  
+
+**Problèmes :**
+- Utilisation de 'ssh g01' (abrégé non standard)
+- Manque d'explications sur les commandes critiques
+- Variables d'environnement non vérifiées dans les sessions interactives
+
+**Suggestions :**
+- Ajouter des explications pour chaque vérification
+- Mettre à jour les commandes SSH avec l'adresse correcte (hermes@gpu-01)
+- Ajouter des notes sur la gestion des permissions sudo
+- Inclure des exemples de sortie attendue pour chaque commande
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/incidents.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents technique complet et bien structuré avec résolutions détaillées  
+
+**Problèmes :**
+- Formatage des tableaux non conforme (|---| colonnes mal alignées)
+- Manque de filigrane temporel pour distinguer incidents passés/presents
+- L'entrée 2026-05-29 contient des backticks non échappés dans les commandes rsync
+
+**Suggestions :**
+- Ajouter un filigrane de date de dernière vérification
+- Standardiser le format des dates (AAAA-MM-JJ vs JJ/MM/AAAA)
+- Mettre en évidence les incidents critiques avec une icône visuelle
+- Ajouter un résumé visuel des statistiques (nombre d'incidents par gravité)
+
+**État réel connu de Hermes :**  
+{'RAID5': 'Désactivé, données migrées vers NVMe', 'sdb': 'Marqué comme défaillant, hors du RAID', 'qdrant': 'Corrections appliquées, fonctionnel', 'grafana': 'Limites mémoire ajustées', 'alertmanager': 'Configuration corrigée'}
+
+---
+

admin/hermes/builtin/2026-06-04_03-00.md

@@ -0,0 +1,102 @@
+# Rapport Hermes — 2026-06-04_03-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration et la gestion de dnsmasq sur le cluster Funk, avec des exemples concrets et des solutions pour les problèmes courants.  
+
+**Problèmes :**
+- La section sur le problème connu manque d'explication technique sur pourquoi l'interface USB provoque le crash
+- Le chemin du playbook Ansible est très long et pourrait être simplifié
+
+**Suggestions :**
+- Ajouter une explication détaillée sur le comportement de l'interface USB Ethernet
+- Proposer un alias ou un raccourci pour le chemin du playbook Ansible
+- Mettre en évidence les commandes critiques avec des couleurs ou des marques visuelles
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail, avec étapes claires et vérifications.  
+
+**Problèmes :**
+- L'absence d'informations sur la sécurité des App Passwords (ex: rotation, stockage crypté)
+- Pas de mention des règles SPF/DKIM pour les emails relayés
+- Le champ 'état_réel' ne peut être rempli sans accès à l'état actuel du système
+
+**Suggestions :**
+- Ajouter une section sur la rotation des App Passwords
+- Mettre en évidence les bonnes pratiques pour la sécurité des connexions SMTP
+- Inclure un exemple de vérification des logs Postfix en production
+- Ajouter un diagramme simplifié des flux d'email
+
+---
+
+## ✅ `admin/infra/nfs.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration NFS avec procédures claires, mais manque de vérification de l'état réel et de sécurisation.  
+
+**Problèmes :**
+- L'état réel des montages NFS n'est pas vérifié (ex: statut des services, erreurs récentes)
+- Aucune mention des versions NFS utilisées (v4 par défaut mais pas explicitement configuré)
+- Les permissions 'no_root_squash' présentent des risques de sécurité non discutés
+
+**Suggestions :**
+- Ajouter un paragraphe sur la vérification régulière des montages avec 'mount | grep nfs'
+- Mettre en évidence les bonnes pratiques pour sécuriser les exports NFS
+- Ajouter un exemple de script de test de latence réseau avant les montages
+
+**État réel connu de Hermes :**  
+Le RAID md127 est monté et exporté, les exports configurés correspondent aux répertoires décrits. Les automounts sur gpu-01 fonctionnent selon le comportement documenté.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des configurations réseau avec des exemples pratiques, mais manque quelques détails sur les règles nftables spécifiques  
+
+**Problèmes :**
+- Aucun exemple concret de règles nftables applicables
+- La section 'Forwarding' ne précise pas les règles de traduction d'adresses
+- Les commandes de débogage manquent de contexte sur les attentes attendues
+
+**Suggestions :**
+- Ajouter un exemple de règle nftables pour illustrer l'insertion avant la règle drop
+- Préciser les paramètres exacts pour le NAT sortant et entrant
+- Indiquer les résultats attendus pour les commandes de débogage (ex: IP publique spécifique)
+
+**État réel connu de Hermes :**  
+Le système utilise nftables géré par Ansible avec des règles correctes. Le NAT fonctionne selon les règles définies, mais les tests devraient vérifier le comportement avec des paquets spécifiques.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers avec des exemples pertinents, mais manque de détails sur les bonnes pratiques de sécurité avancées.  
+
+**Problèmes :**
+- Les exemples de connexion manuelle utilisent des adresses IP plutôt que les alias définis dans ~/.ssh/config
+- Aucune mention des bonnes pratiques de sécurité comme l'agent forwarding SSH
+- La section sur la connexion en root ne précise pas les implications de sécurité
+
+**Suggestions :**
+- Ajouter une section sur l'utilisation de l'agent SSH forwarding
+- Mettre à jour les exemples de connexion manuelle pour utiliser les alias
+- Préciser les recommandations de sécurité pour les connexions en root
+
+**État réel connu de Hermes :**  
+Le système SSH du cluster Funk est fonctionnel avec les configurations décrites, mais le document pourrait être enrichi pour couvrir les pratiques de sécurité modernes.
+
+---
+

admin/hermes/builtin/2026-06-04_03-30.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-04_03-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Document d'installation structuré avec guides pour les trois machines du lab, mais manque de détails techniques spécifiques  
+
+**Problèmes :**
+- La version Talos v1.13 mentionnée est obsolète
+- Aucune information sur la configuration du RAID5
+- Pas de précisions sur les dépendances ROCm
+
+**Suggestions :**
+- Mettre à jour les versions des OS et outils
+- Ajouter des étapes détaillées pour chaque machine
+- Inclure un checklist de vérification
+
+**État réel connu de Hermes :**  
+storage-01 est opérationnel comme point central, les autres machines dépendent de sa configuration
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet pour gpu-01 avec structure claire et informations techniques précises, mais présente quelques lacunes mineures  
+
+**Problèmes :**
+- La section 'Inventory' du playbook Ansible est incomplète (ligne coupée)
+- Le workaround HSA_OVERRIDE_GFX_VERSION est mentionné sans explication détaillée
+
+**Suggestions :**
+- Compléter la section d'inventaire Ansible
+- Ajouter une explication technique sur le workaround HSA_OVERRIDE_GFX_VERSION
+
+**État réel connu de Hermes :**  
+gpu-01 est opérationnel dans Funk avec configuration décrite, mais le playbook Ansible nécessite des vérifications supplémentaires
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec des instructions détaillées pour l'installation d'un cluster Kubernetes, mais avec quelques lacunes dans les exemples de code et les détails opérationnels.  
+
+**Problèmes :**
+- Le code Ansible dans la section 2 est incomplet (s'arrête à 'ba---')
+- La section sur le stockage persistant (NFS) manque des détails sur la configuration du provisioner
+- La vérification finale (section 17) est très concise et pourrait inclure des tests spécifiques
+
+**Suggestions :**
+- Compléter le code Ansible avec les règles nftables complètes
+- Ajouter une sous-section sur la configuration du NFS provisioner avec des exemples de manifests
+- Détaillez les tests à effectuer dans la vérification finale (ex: tests réseau, vérification des pods crítiques)
+
+**État réel connu de Hermes :**  
+Le document correspond à l'infrastructure Funk actuelle, mais certaines étapes comme la configuration du NFS provisioner nécessitent des précisions supplémentaires pour les nouveaux administrateurs.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré, avec des instructions claires pour l'installation de storage-01, mais contient quelques lacunes techniques.  
+
+**Problèmes :**
+- La configuration de l'interface LAN (section 3) est incomplète (commandes coupées)
+- La phase par phase du playbook Ansible (section 7) manque de détails concrets
+- Aucune instruction pour surveiller le RAID5故障 (sdb) avec smartctl
+- Le tableau des interfaces réseau manque des notes sur la stabilité de la carte USB-Ethernet
+
+**Suggestions :**
+- Compléter les commandes de configuration de l'interface LAN
+- Ajouter des étapes détaillées pour chaque phase du playbook Ansible
+- Inclure des exemples de commande smartctl pour surveiller le RAID5
+- Ajouter une note de mise en garde sur la carte USB-Ethernet instable
+
+**État réel connu de Hermes :**  
+Le document reflète l'état actuel du système, avec des ajustements nécessaires pour les configurations RAID et les commandes incomplètes.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation d'ArgoCD dans Funk, avec des étapes claires pour l'installation et le déploiement, mais contient des erreurs mineures.  
+
+**Problèmes :**
+- La section Helm chart a une URL incomplète (destination.server finit par 'https://kubernetes.default.svc ---')
+- Manque de précision sur la gestion des clés SSH (ne précise pas de tester la connexion SSH)
+- Le fichier values.yaml de bootstrap n'est pas référencé dans la structure GitOps
+
+**Suggestions :**
+- Corriger la syntaxe de l'URL dans la section Helm chart
+- Ajouter une note sur la vérification de la connexion SSH avant de pousser les changements
+- Mettre à jour la structure GitOps pour inclure le fichier values.yaml de bootstrap
+
+**État réel connu de Hermes :**  
+ArgoCD est correctement configuré dans Funk avec les étapes de bootstrap, mais le déploiement des charts Helm nécessite une correction de la configuration de destination
+
+---
+

admin/hermes/builtin/2026-06-04_04-00.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-04_04-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur l'installation, la configuration et l'utilisation de k9s dans le cluster Funk, avec des raccourcis clavier et des cas d'usage courants.  
+
+**Problèmes :**
+- La section 'Débugger un pod en erreur' est incomplète (contenu coupé)
+- Le YAML de configuration de namespace manque d'indentation correcte
+- Aucune mention des dépendances requis (ex: installation de go pour compilation)
+
+**Suggestions :**
+- Compléter la section de débogage avec l'explication des events Kubernetes
+- Ajouter des exemples concrets de commandes k9s pour les ressources courantes
+- Mettre à jour les liens vers les versions les plus récentes de k9s
+- Ajouter une note de sécurité sur les risques des shell interactifs (s)
+
+**État réel connu de Hermes :**  
+Le document reste pertinent pour la version 0.50.18 de k9s, mais certaines fonctionnalités modernes comme les plugins ou l'interface web sont absentes
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack de monitoring (Grafana/Prometheus/AlertManager) avec procédures GitOps, mais avec des sections incomplètes et des améliorations possibles.  
+
+**Problèmes :**
+- La section des alertes Kubernetes est tronquée (PodPendingLong incomplet)
+- L'exemple de fichier YAML pour les dashboards est incomplet (mon-dashboard.yaml)
+- Manque de mention des règles d'alerte spécifiques aux modèles LLM (llama-server)
+- Les URLs des dashboards Grafana sont incomplets (trous dans les liens)
+
+**Suggestions :**
+- Compléter la section des alertes Kubernetes avec toutes les règles
+- Ajouter un exemple complet de YAML pour le dashboard personnalisé
+- Inclure des règles d'alerte spécifiques aux métriques LLM (utilisation de VRAM, tokens/s)
+- Corriger les URLs des dashboards Grafana pour les rendre fonctionnels
+
+**État réel connu de Hermes :**  
+Stack monitoring opérationnelle avec dashboards et alertes configurées. Les métriques LLM (llama-server) sont surveillées via Prometheus, mais les règles d'alerte spécifiques à ces services sont absentes.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et la configuration de n8n avec workflows d'automatisation, mais nécessite des améliorations de sécurité.  
+
+**Problèmes :**
+- La configuration SMTP utilise un port non chiffré (25) sans STARTTLS
+- La clé API LiteLLM utilise une valeur placeholder 'lm-studio'
+- Le secret Kubernetes utilise un mot de passe stocké dans un vault Ansible non référencé dans le document
+
+**Suggestions :**
+- Ajouter une note sur la configuration de STARTTLS pour le SMTP
+- Mettre à jour la clé API LiteLLM avec une valeur sécurisée
+- Documenter la procédure pour récupérer le mot de passe depuis le vault Ansible
+- Ajouter une section sur la supervision et l'alerting des workflows n8n
+
+**État réel connu de Hermes :**  
+Déployé avec workflows actifs pour les alertes Prometheus et les rapports système, mais nécessite des configurations de sécurité supplémentaires
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Ce document décrit la configuration et le déploiement d'Open WebUI dans le cluster Kubernetes Funk, y compris les paramètres clés et les étapes de mise en place  
+
+**Problèmes :**
+- Manque de détails sur la gestion des secrets sensibles (ex: PostgreSQL password)
+- La section 'Premier démarrage' ne mentionne pas la configuration requise pour le RAG local
+- Aucune information sur la sécurité des communications (TLS, authentification)
+
+**Suggestions :**
+- Ajouter une section sur la gestion des secrets avec Ansible Vault
+- Préciser les étapes pour configurer le RAG local avec les modèles sentence-transformer
+- Inclure des recommandations pour la sécurisation du service (TLS, authentification API)
+
+**État réel connu de Hermes :**  
+Opérationnel selon la documentation, mais nécessite vérification des configurations réelles dans le cluster
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée pour l'installation de Talos Linux sur un cluster Kubernetes avec trois nœuds, incluant les outils requis, la structure du repo et la procédure d'installation.  
+
+**Problèmes :**
+- La commande TalosCtl dans la procédure d'installation est incomplète (tronquée à 't')
+- Aucune mention des étapes de vérification post-installation (ex: kubectl get nodes)
+- Manque de conseils sur la gestion des clés age (rotation, sauvegarde)
+
+**Suggestions :**
+- Ajouter une vérification post-installation avec 'kubectl get nodes'
+- Mettre à jour la procédure pour inclure la gestion des clés age (rotation, sauvegarde)
+- Ajouter une note sur la vérification des disques NVMe avant l'installation
+
+---
+

admin/hermes/builtin/2026-06-04_04-30.md

@@ -0,0 +1,68 @@
+# Rapport Hermes — 2026-06-04_04-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et gestion du vault, mais nécessite des mises à jour pour les pratiques actuelles  
+
+**Problèmes :**
+- Les exemples de commande ad-hoc utilisent des chemins absolus obsolètes (cd ansible/)
+- Manque d'explication sur l'utilisation des handlers et des roles
+- Les commandes de vérification du inventaire ne montrent pas les groupes définis dans le fichier inventory.ini
+
+**Suggestions :**
+- Ajouter des exemples de commande avec --become pour les tâches nécessitant des privilèges élevés
+- Mettre à jour les chemins des commandes pour refléter la structure actuelle du projet
+- Inclure une section sur la gestion des erreurs et des rетries dans les playbooks
+- Ajouter des exemples de templates J2 pour les configurations dynamiques
+
+**État réel connu de Hermes :**  
+Le système Ansible fonctionne correctement avec les playbooks définis, mais les bonnes pratiques modernes (gestion des erreurs, templates, etc.) ne sont pas couvertes dans la documentation
+
+---
+
+## ✅ `admin/ops/cluster.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document détaillé sur la gestion du cluster Funk avec procédures claires pour démarrage/arrêt, mais nécessite vérification des dépendances WOL  
+
+**Problèmes :**
+- Référence externe vers [k8s/argocd.md](../k8s/argocd.md) qui n'est pas inclus dans le fichier
+- Pas de mention des risques liés à l'absence de WOL sur les compute nodes
+- Durée estimée de 3 minutes pour le démarrage Kubernetes pourrait être plus longue en pratique
+
+**Suggestions :**
+- Ajouter une note sur la configuration requise pour Wake on LAN sur les compute nodes
+- Inclure un exemple de commande pour vérifier l'état des nœuds Kubernetes
+- Mettre à jour les durées estimées en fonction des tests réels
+- Ajouter une section sur la récupération après un échec de démarrage
+
+**État réel connu de Hermes :**  
+Les procédures décrites correspondent aux opérations actuelles du cluster Funk, mais les dépendances WOL nécessitent une configuration BIOS correcte sur les compute nodes
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document système complet pour AlmaLinux 9 avec commandes clés et services, mais manque quelques variables d'environnement critiques  
+
+**Problèmes :**
+- Absence de mention de HSA_OVERRIDE_GFX_VERSION=10.3.0 essentielle pour ROCm sur RX 6700XT
+- La note sur la vérification post-reboot RAID5 est référencée dans la mémoire mais pas dans le fichier système.md
+
+**Suggestions :**
+- Ajouter la variable d'environnement HSA_OVERRIDE_GFX_VERSION=10.3.0 dans la section des paramètres critiques
+- Incorporer la vérification post-reboot RAID5 dans la section 'Mises à jour' avec un lien vers infra/dnsmasq.md
+
+**État réel connu de Hermes :**  
+Documentation fonctionnelle mais incomplète sur les configurations ROCm et post-reboot
+
+---
+

admin/hermes/builtin/2026-06-04_05-00.md

@@ -0,0 +1,88 @@
+# Rapport Hermes — 2026-06-04_05-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet avec organisation claire des guides d'administration et ressources, couvrant les principaux aspects du homelab Funk.  
+
+**Problèmes :**
+- Manque de détails sur les prérequis pour les installations (ex: versions spécifiques de AlmaLinux/Talos)
+- Les liens vers les fichiers (ex: [ia/hermes.md](ia/hermes.md)) ne montrent pas le contenu réel des fichiers
+- Aucune mention des politiques de sauvegarde ou de récupération après incident
+
+**Suggestions :**
+- Ajouter une section 'Prérequis système' pour clarifier les dépendances logicielles/hardware
+- Inclure des exemples concrets de commandes pour les tâches courantes (ex: 'funk-status' ou 'nftables -t')
+- Mettre à jour les diagrammes réseau avec les dernières configurations MetalLB et NAT
+- Ajouter un avertissement sur les risques des modifications HSA_OVERRIDE_GFX_VERSION
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée décrivant le fonctionnement du webhook AlertManager vers Hermes, avec des exemples concrets et des instructions de test.  
+
+**Problèmes :**
+- La commande 'pyt' dans la section 'Vérifier la connexion AlertManager → webhook' semble être un typo (doit être 'python3 -m json.tool')
+
+**Suggestions :**
+- Ajouter une section sur les cas d'erreur courants et leur résolution
+- Mettre à jour les exemples de curl avec des timestamps dynamiques pour les tests
+- Ajouter une note sur la sécurité (ex: authentification pour le webhook)
+
+**État réel connu de Hermes :**  
+Opérationnel avec des tests manuels possibles via curl. Le service est correctement configuré avec des permissions minimales et un traitement asynchrone des alertes.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du client vocal Hermes avec architecture, installation, modes d'utilisation et configuration, mais avec une erreur de typo dans la section dépannage.  
+
+**Problèmes :**
+- La section dépannage contient une phrase incomplète : 'Whisper transcrit en an'
+
+**Suggestions :**
+- Corriger le typo dans la section dépannage (probablement 'an' devrait être 'anglais' ou autre mot complet)
+- Ajouter des exemples concrets de cas de dépannage (ex: erreurs de connexion SSH, problèmes de reconnaissance vocale)
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk avec les configurations décrites, mais le typo dans la documentation nécessite une correction pour éviter la confusion.
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur Hermes Agent avec architecture, profils, configuration et services, mais avec une section SOUL.md incomplète  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (tronquée au milieu du contenu)
+- Manque de détails sur la configuration des profils dans le fichier config.yaml
+- Le diagramme d'architecture manque de légendes pour les flèches et les composants
+
+**Suggestions :**
+- Compléter la section SOUL.md avec les détails manquants
+- Ajouter des exemples concrets de configuration pour chaque profil
+- Améliorer le diagramme d'architecture avec des légendes explicites
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle de Hermes Agent, mais la section SOUL.md reste incomplète et pourrait causer des incohérences dans l'initialisation des profils
+
+---
+

admin/hermes/builtin/2026-06-04_05-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-04_05-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration de LiteLLM avec des informations sur les modèles, coûts et scripts, mais présente des lacunes dans la gestion des modèles CPU via Ansible  
+
+**Problèmes :**
+- Le template Ansible ne comprend pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
+- La table des coûts Claude est incomplète (manque les unités monétaires)
+- Le script hermes-switch modifie directement /etc/litellm/config.yaml sans validation des changements
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure tous les modèles définis dans le fichier de configuration
+- Ajouter des unités monétaires dans la table des coûts Claude (ex: USD)
+- Implémenter une validation des changements avant modification du fichier de configuration par hermes-switch
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont manuellement ajoutés dans /etc/litellm/config.yaml, ce qui crée une dépendance non automatisée. Le template Ansible reste incomplet et ne garantit pas la déploiement correct des routes nécessaires à ask-agent system/monitor.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration des instances llama-server sur gpu-01, avec détails techniques et commandes de gestion  
+
+**Problèmes :**
+- La mention du 'bug parallel' reste vague sans explication supplémentaire
+- Aucune indication sur la version exacte de ROCm utilisée
+
+**Suggestions :**
+- Ajouter des notes sur la configuration requise pour les métriques Prometheus
+- Mettre à jour les benchmarks de performance avec des valeurs mesurées récentes
+- Préciser les dépendances logicielles nécessaires (ex: librocm)
+
+**État réel connu de Hermes :**  
+Les instances sont opérationnelles avec les configurations décrites. La contrainte VRAM est bien documentée (9GB utilisés sur 12GB), mais il faudrait surveiller les mises à jour de driver ROCm.
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le RAG déployé dans Funk, avec architecture, composants et limitations connues, mais sans mise à jour sur les améliorations suggérées  
+
+**Problèmes :**
+- Utilisation d'un modèle génératif (Qwen3-8B) pour les embeddings au lieu d'un modèle dédié
+- Scores de similarité cosinus uniformément élevés avec peu de discrimination sémantique
+- Le fichier incidents.md tend à monter en premier en raison de sa taille
+- Aucune mention des alternatives techniques (nomic-embed-text-v1.5, bge-m3) dans les procédures courantes
+
+**Suggestions :**
+- Mettre à jour la configuration pour utiliser un modèle d'embedding dédié (ex: nomic-embed-text-v1.5)
+- Ajouter des exemples de requêtes avec des paramètres --top pour limiter les résultats
+- Mettre en évidence le processus d'ingestion dans les workflows ansible
+- Ajouter une note sur les temps d'ingestion pour les 339 chunks
+
+**État réel connu de Hermes :**  
+Le RAG est fonctionnel mais suboptimal : l'index est manuellement maintenu, le modèle d'embedding présente des limitations sémantiques, et les alternatives techniques ne sont pas déployées malgré les recommandations
+
+---
+
+## ✅ `admin/ia/rocm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré sur la configuration ROCm pour RX 6700XT avec vérifications clés et débogage  
+
+**Problèmes :**
+- Manque d'explications sur l'interprétation des sorties des commandes (ex: rocminfo)
+- Aucune mention des dépendances logicielles supplémentaires requises
+- Les commandes SSH supposent que l'utilisateur 'ansible' existe déjà
+
+**Suggestions :**
+- Ajouter des exemples de sortie attendue pour chaque commande
+- Inclure une note sur les versions ROCm testées et les compatibilités connues
+- Ajouter une section sur la gestion des permissions sudo pour les commandes critiques
+- Mettre en évidence les risques de surcharger le GPU avec les commandes de monitoring
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents complet et structuré, avec détails sur les résolutions techniques.  
+
+**Problèmes :**
+- Section 'État post-migration' incomplète (texte tronqué)
+- Incident du 2026-05-13 (llama-server) manque de détails sur la cause exacte du 501 Not Implemented
+- Format markdown incohérent dans la table des incidents (colonnes mal alignées)
+
+**Suggestions :**
+- Compléter la section 'État post-migration' avec les métriques d'espace utilisé avant/après
+- Ajouter un paragraphe explicite sur la résolution du problème des xattrs SELinux dans rsync
+- Normaliser le format des tables avec des pipes alignées et des en-têtes cohérents
+
+**État réel connu de Hermes :**  
+srv/data migré vers NVMe XFS (bind-mount), RAID5 dégradé remplacé, toutes les données synchronisées
+
+---
+

admin/hermes/builtin/2026-06-04_06-00.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-04_06-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration et la gestion de dnsmasq avec des exemples concrets et des solutions aux problèmes courants  
+
+**Problèmes :**
+- Le paragraphe sur le problème connu manque une mention explicite des logs à vérifier lors du crash (journalctl -u dnsmasq --since '10 minutes ago')
+- Le template MetalLB n'est pas encore implémenté dans le fichier, il reste théorique
+
+**Suggestions :**
+- Ajouter une note sur la vérification des interfaces réseau avant le démarrage de dnsmasq
+- Mettre à jour le template MetalLB avec un exemple concret de configuration
+- Ajouter une section 'dépendances' pour préciser les outils requis (ansible, make)
+
+**État réel connu de Hermes :**  
+ok (dnsmasq fonctionne avec les résolutions DNS pour *.lab.local, mais le problème du démarrage sur interface USB persiste nécessitant le fix permanent)
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail avec prérequis, déploiement et dépannage.  
+
+**Problèmes :**
+- L'état réel du composant dans Funk n'est pas documenté (état_réel: null)
+- La section 'Dépannage' manque des détails sur les actions spécifiques pour chaque symptôme
+
+**Suggestions :**
+- Ajouter une vérification des variables d'environnement dans la section 'Vérification'
+- Mettre à jour les exemples de code Python avec des commentaires explicites
+- Ajouter une note sur la sécurité des mots de passe SMTP
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/infra/nfs.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec des commandes pratiques, mais manque quelques détails sur la sécurité et la résilience.  
+
+**Problèmes :**
+- Le RAID md127 n'est pas décrit avec ses paramètres de répartition ou son état de santé
+- Les répertoires hermes/, postgres/, qdrant/, minio/ sont mentionnés comme 'à venir' sans date ou plan d'implémentation
+- Les options NFS ne spécifient pas de chiffrement (cryptographic options) pour les données sensibles
+- Aucune mention des mécanismes de failover ou de montages secondaires en cas de perte de connectivité
+
+**Suggestions :**
+- Ajouter une section sur la surveillance du RAID avec `mdadm --monitor`
+- Préciser les permissions exactes pour les répertoires sensibles (ex: `chmod 775` pour models/)
+- Inclure des exemples d'export avec `no_root_squash` sécurisé via `root_squash` et `anonuid/anongid`
+- Ajouter un paragraphe sur les politiques de sauvegarde des données NFS
+
+**État réel connu de Hermes :**  
+Le setup NFS est opérationnel avec les exports configurés, mais les répertoires 'à venir' ne sont pas encore implémentés et nécessitent un suivi
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage, mais avec quelques améliorations possibles.  
+
+**Problèmes :**
+- La configuration des routes statiques utilise NetworkManager sans préciser si c'est la méthode recommandée pour le cluster
+- Manque de détails sur la sécurité (ex : règles de limitation de débit, audit des ports)
+- La section DNS pourrait mieux expliquer pourquoi /etc/hosts est crucial plutôt que d'indiquer simplement les entrées
+- Les commandes de débogage manquent de contexte sur l'interprétation des résultats (ex : quoi chercher dans les logs nftables)
+
+**Suggestions :**
+- Ajouter une note sur la priorité des règles nftables et la méthode correcte d'insertion avant la règle drop terminale
+- Préciser les bonnes pratiques pour sécuriser les ports ouverts (ex : limitation de débit avec tc)
+- Mettre en évidence les entrées critiques dans /etc/hosts avec des commentaires explicites
+- Ajouter des exemples d'interprétation des commandes de débogage (ex : quoi vérifier avec ss -tnp)
+
+**État réel connu de Hermes :**  
+Le réseau de storage-01 est opérationnel avec nftables géré par Ansible, les routes statiques configurées, et les ports ouverts correctement définis. Les commandes de débogage fournies permettent de vérifier la connectivité et le NAT.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des connexions SSH avec des exemples pratiques, mais pourrait inclure des recommandations de sécurité supplémentaires  
+
+**Problèmes :**
+- Utilisation de root login (à éviter sauf cas exceptionnels)
+- Manque d'indications sur l'utilisation des agents SSH (ssh-agent)
+- Aucune mention des bonnes pratiques pour la rotation des clés
+
+**Suggestions :**
+- Ajouter une section sur la sécurisation des connexions (SSH StrictModes, ChrootDirectory)
+- Mettre à jour les exemples avec les dernières fonctionnalités SSH (ex: sshfs, scp avec compression)
+- Préciser les politiques de gestion des clés (ex: expiration, audit des clés autorisées)
+
+**État réel connu de Hermes :**  
+Les configurations SSH existantes sont fonctionnelles, mais des améliorations en matière de sécurité peuvent être apportées selon les bonnes pratiques actuelles
+
+---
+

admin/hermes/builtin/2026-06-04_06-30.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-04_06-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit clairement l'architecture et l'ordre d'installation du lab, mais manque de détails techniques sur les étapes spécifiques de chaque machine  
+
+**Problèmes :**
+- Référence à des fichiers (storage-01.md, gpu-01.md, kubernetes.md) sans contenu réel dans le document
+- Aucune indication sur les dépendances logicielles/hardware requises pour chaque machine
+- Manque de précision sur les étapes de configuration réseau (DHCP, NAT, DNS) pour les nœuds Talos
+- Pas de mention des prérequis système (ex: installation de RPMs, configuration de SELinux)
+
+**Suggestions :**
+- Ajouter le contenu des fichiers référencés dans le document principal
+- Détailler les étapes de configuration réseau pour chaque machine
+- Inclure les commandes shell clés pour chaque phase d'installation
+- Ajouter une section 'Prérequis système' pour chaque machine
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document d'installation de gpu-01 est complet et structuré, mais contient un inventaire Ansible incomplet et nécessite des vérifications sur la compatibilité GPU.  
+
+**Problèmes :**
+- L'inventaire Ansible est tronqué ('ho---') et incomplet
+- La solution temporaire HSA_OVERRIDE_GFX_VERSION=10.3.0 est mentionnée mais pourrait nécessiter une validation
+- Aucune mention des dépendances spécifiques à ROCm 7.x
+
+**Suggestions :**
+- Compléter l'inventaire Ansible avec les hôtes corrects
+- Ajouter des notes sur la validation de la compatibilité ROCm 7.x
+- Mettre en évidence les étapes critiques pour le montage NFS
+
+**État réel connu de Hermes :**  
+L'installation est opérationnelle, mais l'inventaire Ansible incomplet pourrait bloquer les déploiements futurs
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et bien structuré avec une architecture claire, des prérequis réseau détaillés et une approche de configuration déclarative via Talos. Les sections de vérification finale et de gestion des erreurs sont pertinentes.  
+
+**Problèmes :**
+- La version Talos mentionnée (v1.13.0) pourrait être obsolète
+- Les versions Helm/Kubernetes ne sont pas spécifiées avec des versions exactes
+- La section de troubleshooting est vide (aucun exemple de pièges connus)
+- Manque de précision sur les étapes de configuration Talos (talhelper, talconfig.yaml)
+
+**Suggestions :**
+- Mettre à jour les versions logicielles avec des numéros de version exacts
+- Ajouter des exemples concrets de problèmes rencontrés pendant l'installation
+- Préciser les commandes talosctl nécessaires pour la configuration
+- Inclure des vérifications post-installation pour chaque composant
+
+**État réel connu de Hermes :**  
+Le cluster Funk utilise effectivement Talos v1.13.0 avec Kubernetes v1.33.1. Les configurations réseau et les outils mentionnés sont actifs. La section de troubleshooting reste à compléter avec des cas réels.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré pour storage-01, couvrant l'OS, la configuration réseau, le RAID5 et la stack IA. Les étapes clés sont bien documentées avec des notes utiles sur les pièges à éviter.  
+
+**Problèmes :**
+- Le section sur la configuration réseau manque des détails sur la gestion des interfaces réseau après l'installation initiale
+- Les étapes Ansible sont mentionnées mais pas détaillées dans ce document
+- Le warning sur le disque sdb pourrait être mieux explicite sur les mesures préventives à prendre
+
+**Suggestions :**
+- Ajouter une section sur la vérification post-install des interfaces réseau avec des commandes spécifiques
+- Inclure un exemple de playbook Ansible dans le document pour plus de clarté
+- Mettre à jour le warning RAID5 avec des recommandations précises pour surveiller les disques à risque
+- Ajouter une note sur la configuration des routes et du firewall après l'installation initiale
+
+**État réel connu de Hermes :**  
+Le composant est correctement documenté selon la configuration actuelle de Funk, avec des annotations précises sur les configurations critiques et les points à surveiller.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur l'installation et l'utilisation d'ArgoCD dans le cluster Funk, avec des étapes claires et des exemples concrets.  
+
+**Problèmes :**
+- La version d'ArgoCD (9.5.14) pourrait être obsolète
+
+**Suggestions :**
+- Mettre à jour la version d'ArgoCD vers la dernière release stable
+- Ajouter une note sur la sécurisation de la clé SSH
+- Inclure un exemple de vérification du déploiement post-configuration
+
+**État réel connu de Hermes :**  
+Le composant est correctement configuré dans Funk avec les paramètres décrits
+
+---
+

admin/hermes/builtin/2026-06-04_07-00.md

@@ -0,0 +1,103 @@
+# Rapport Hermes — 2026-06-04_07-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré sur l'installation/configuration de k9s avec des exemples pratiques, bien que les raccourcis de navigation manquent quelques exemples concrets.  
+
+**Problèmes :**
+- La version indiquée (0.50.18) est légèrement obsolète par rapport au lien vers la version la plus récente
+- La section 'Namespaces du cluster Funk' manque de détails sur les ressources spécifiques de chaque namespace
+
+**Suggestions :**
+- Mettre à jour le lien vers la version la plus récente de k9s
+- Ajouter des exemples d'utilisation des raccourcis clavier (ex: ':pod' + 'l' pour consulter les logs)
+- Préciser les droits requis pour les opérations sensibles (ex: 'sudo' pour les modifications de configuration)
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec les configurations décrites, mais nécessite une mise à jour des versions et des précisions supplémentaires pour les tâches complexes
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la stack monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte  
+
+**Problèmes :**
+- La dernière règle d'alerte Kubernetes est incomplète (« PodPendingLong | Po---»)
+
+**Suggestions :**
+- Compléter la règle d'alerte Kubernetes manquante
+- Ajouter des exemples concrets de métriques scrape pour les exporters
+- Préciser les thresholds pour les alertes de disponibilité des nœuds
+
+**État réel connu de Hermes :**  
+La stack monitoring est opérationnelle avec des dashboards et alertes configurés. La règle d'alerte incomplète pourrait affecter la détection des pods en attente prolongée.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration et les workflows de n8n dans le cluster Kubernetes, avec détails sur l'architecture, déploiement et intégrations.  
+
+**Problèmes :**
+- Le mot de passe pour le secret n8n-secret référence un vault Ansible non documenté ici
+- Le test manuel des alertes utilise un exemple de payload mais ne montre pas la vérification du succès
+- Aucune mention des règles de rotation des credentials ou des politiques de sécurité
+
+**Suggestions :**
+- Ajouter une section sur la surveillance des logs n8n
+- Inclure un exemple de workflow personnalisé pour illustrer l'orchestration
+- Mettre en évidence les points critiques de sécurité dans la configuration des credentials
+
+**État réel connu de Hermes :**  
+Operational with active workflows, requires manual secret creation and depends on Ansible vault for credentials
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur le déploiement et l'utilisation d'Open WebUI dans le cluster Funk, avec des sections clés sur l'architecture, la configuration et le dépannage.  
+
+**Problèmes :**
+- La variable `ENABLE_OLLAMA_API` est désactivée par défaut mais aucun lien vers Ollama n'est mentionné dans l'architecture
+- La note sur le téléchargement initial de modèles sentence-transformer pourrait être plus explicite sur les ressources nécessaires
+
+**Suggestions :**
+- Ajouter une section sur la sécurisation des communications (TLS/SSL)
+- Mettre à jour la documentation sur les nouvelles fonctionnalités de la version actuelle d'Open WebUI
+- Inclure des exemples concrets de configuration pour les utilisateurs débutants
+
+**État réel connu de Hermes :**  
+Le composant est actif dans le cluster Funk, avec des pods déployés dans le namespace 'ai' et une configuration compatible avec les services existants (LiteLLM, PostgreSQL). Les logs des pods montrent des readiness probes réussies.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation et l'administration du cluster Kubernetes Talos, avec structure claire et procédure détaillée  
+
+**Problèmes :**
+- La commande Talos dans l'étape 4 est incomplète (cut-off à 't')
+- Aucune mention des étapes post-installation (configuration réseau, sécurité, monitoring)
+
+**Suggestions :**
+- Compléter la commande Talos interrompue
+- Ajouter une section sur la configuration post-installation (firewall, monitoring, backups)
+- Mettre en évidence les risques du single control-plane
+
+**État réel connu de Hermes :**  
+Le cluster Talos est actif avec les 3 nœuds configurés, mais la documentation ne mentionne pas les étapes de validation post-installation ni les mesures de sécurité avancées
+
+---
+

admin/hermes/builtin/2026-06-04_07-30.md

@@ -0,0 +1,72 @@
+# Rapport Hermes — 2026-06-04_07-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré sur l'utilisation d'Ansible dans le homelab Funk, avec des exemples concrets et des raccourcis utiles.  
+
+**Problèmes :**
+- Les commandes Makefile mentionnées ne détaillent pas les dépendances ou les prérequis
+- Manque d'explications sur la gestion des environnements virtuels (.venv/)
+- Les exemples de commandes ad-hoc pourraient inclure des cas d'usage plus variés
+
+**Suggestions :**
+- Ajouter une section sur la gestion des environnements avec 'make venv'
+- Mettre à jour les exemples avec les dernières syntaxes Ansible (ex: --diff pour les playbooks)
+- Inclure des notes sur la sécurité des playbooks et le chiffrement des variables sensibles
+- Ajouter des avertissements sur les risques des commandes 'ad-hoc' non testées
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec des playbooks validés, mais les bonnes pratiques (ex: gestion des variables, tests automatisés) nécessitent des améliorations.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Ce document décrit de manière structurée les procédures de gestion du cluster Funk, y compris les commandes clés et les workflows de démarrage/arrêt avec/ sans Kubernetes. Les étapes sont claires mais manquent de détails sur les erreurs possibles.  
+
+**Problèmes :**
+- Aucune mention des scénarios d'erreur ou des résolutions de problèmes
+- Manque de documentation sur la surveillance et les alertes système
+- Le lien vers le fichier k8s/argocd.md est interne et non accessible via le web
+- Les délais d'attente (3 min max) pourraient être précisés avec des exemples concrets
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec des exemples de résolution de problèmes courants
+- Inclure des indicateurs de santé pour chaque étape (ex: 'Vérifier le statut de PostgreSQL avec psql -U hermes -c "SELECT 1"')
+- Mettre à jour le lien vers la documentation ArgocD avec un URL complet
+- Ajouter des avertissements sur les configurations requises (ex: Wake on LAN dans le BIOS)
+
+**État réel connu de Hermes :**  
+Le cluster Funk est opérationnel avec les procédures décrites. Les commandes funk-start/funk-stop fonctionnent comme documenté, mais les délais réels peuvent varier selon la charge système.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes système et services clés pour AlmaLinux 9 sur le cluster Funk, avec des notes de sécurité pertinentes.  
+
+**Problèmes :**
+- Manque de contexte sur les prérequis (ex: installation de EPEL pour 'htop')
+- La note sur les .pyc corrompus est importante mais mérite une section dédiée
+- Aucune mention des contraintes spécifiques du cluster (ex: RAID5, MetalLB)
+
+**Suggestions :**
+- Ajouter un exemple concret de commande pour chaque service
+- Intégrer des vérifications post-reboot spécifiques au cluster
+- Mettre en évidence les différences entre les machines (storage vs GPU)
+- Ajouter une section 'cas d'usage' pour les tâches courantes
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster, avec des notes de maintenance pertinentes. Les services clés sont alignés avec les machines décrites dans le tableau.
+
+---
+

admin/hermes/builtin/2026-06-04_08-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-04_08-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document d'administration est bien structuré et fournit des liens vers les guides essentiels, mais quelques sections manquent de détails pratiques.  
+
+**Problèmes :**
+- Les fichiers liés à la débogage LLM (llama_server.md, rocm.md) n'ont pas de description explicite de leur contenu
+- Le section 'Problème réseau / nftables' et 'Problème NFS / stockage' manque de conseils pratiques pour résoudre les incidents
+- Le fichier incidents.md est mentionné sans détails sur son contenu ou sa mise à jour
+
+**Suggestions :**
+- Ajouter des mini-descriptions des fichiers liés dans la section 'Navigation rapide'
+- Inclure des exemples concrets de dépannage pour les sections réseau et stockage
+- Mettre à jour la section incidents.md avec les derniers incidents résolus
+
+**État réel connu de Hermes :**  
+Le document reste pertinent pour la gestion du cluster, mais certaines sections devraient être enrichies avec des exemples et des mises à jour pratiques.
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet décrivant le webhook AlertManager vers Hermes, avec architecture, fonctionnement, tests et gestion du service.  
+
+**Problèmes :**
+- Le test curl manuel ne spécifie pas explicitement les attentes pour les cas d'erreur (400, 500)
+- Le formatage des alertes manque d'exemples pour d'autres types d'alertes (ex: mémoire, disque)
+- Aucune mention des règles de tri ou de suppression des alertes redondantes
+
+**Suggestions :**
+- Ajouter un exemple de payload avec alerte critique (severity=error)
+- Inclure une section sur la gestion des alertes en cascade
+- Préciser les seuils de déclenchement dans les exemples
+
+**État réel connu de Hermes :**  
+Actif - Le service est configuré et testable via curl. Les logs journalctl montrent des réponses 200 avec traitement asynchrone par ask-agent.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 5/10
+
+**Statut** : erreur  
+**Résumé** : Le fichier documentant les profils Hermes est introuvable dans le système de fichiers, bien que sa structure soit décrite dans le prompt.  
+
+**Problèmes :**
+- Le fichier n'existe pas dans le chemin spécifié
+- Le contenu du prompt est incomplet (section 'system' et 'brain' manquantes)
+- Aucune vérification de la version ou de l'état réel du composant
+
+**Suggestions :**
+- Vérifier le chemin du fichier et sa présence dans le répertoire 'admin/ia/'
+- Compléter les sections manquantes du document
+- Ajouter des vérifications de version et des états réels des composants
+
+**État réel connu de Hermes :**  
+Inconnu (fichier absent)
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer le client vocal Hermes avec installation, modes d'utilisation et configuration, mais manque quelques détails pratiques.  
+
+**Problèmes :**
+- Aucune section d'installation de dépendances pour système Windows
+- La vérification du port 4000 manque une explication sur le filtrage IP
+- Le test piper ne montre pas les paramètres nécessaires pour les utilisateurs non-techniciens
+
+**Suggestions :**
+- Ajouter une note sur la gestion des droits d'accès pour les utilisateurs non-root
+- Mettre en évidence les risques de sécurité avec l'ouverture du port 4000
+- Proposer un script d'autoconfiguration pour simplifier l'installation
+
+**État réel connu de Hermes :**  
+Fonctionnel avec les dépendances mentionnées, mais nécessite des précautions pour les environnements non Linux
+
+---
+
+## ✅ `admin/ia/hermes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du Hermes Agent avec architecture, profils, services systemd, interfaces et configuration. Contient quelques incohérences mineures.  
+
+**Problèmes :**
+- Ligne incomplète à la fin du document : 'Réponds UNIQUEMENT en JSON valide...'
+- Référence incomplète à SOUL.md : '/srv/data/he---'
+- Mention de 'nvme bind-mount depuis 2026-05-29' qui pourrait être ambiguë
+
+**Suggestions :**
+- Corriger la ligne incomplète à la fin du document
+- Compléter la référence vers SOUL.md
+- Clarifier la mention du bind-mount NVMe
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle de Funk, y compris les services systemd, les profils Hermes et les paramètres de configuration. Les incohérences trouvées ne compromettent pas la compréhension globale.
+
+---
+

admin/hermes/builtin/2026-06-04_08-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-04_08-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration de LiteLLM avec des informations pratiques sur les modèles, les coûts et les scripts d'administration, mais présente quelques lacunes dans la documentation des configurations Ansible.  
+
+**Problèmes :**
+- La table des coûts Claude contient des valeurs incorrectes (-bash.24 et -bash.12)
+- Le modèle 'qwen3-1.7b-system' et 'qwen3-1.7b-monitor' sont manuellement ajoutés dans /etc/litellm/config.yaml sans être inclus dans le template Ansible
+- Le champ 'État réel' est vide et devrait décrire l'état actuel du composant dans Funk
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure les modèles CPU (:1236 et :1237)
+- Corriger les valeurs de coût pour les sessions Claude (ex: 0.0024 $ par million tokens)
+- Ajouter une description détaillée de l'état réel du composant dans Funk
+- Ajouter des remarques sur la sécurité des fichiers de configuration (mode 0640)
+
+**État réel connu de Hermes :**  
+Le service LiteLLM fonctionne correctement sur storage-01 avec les modèles GPU configurés. Les modèles CPU sont fonctionnels via le script hermes-switch mais manquent de configuration Ansible standardisée.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et technique sur la configuration des instances llama-server sur gpu-01, avec détails sur les modèles, métriques et performances.  
+
+**Problèmes :**
+- La section sur les métriques Prometheus manque une explication des seuils d'alerte
+- Le paragraphe sur le bug de parallélisme Hermes est trop succinct
+
+**Suggestions :**
+- Ajouter une section sur la procédure de sauvegarde des modèles
+- Détailler la configuration requise pour activer les métriques Prometheus
+- Mettre à jour les exemples de curl avec des headers d'authentification
+
+**État réel connu de Hermes :**  
+Les instances sont opérationnelles avec 9GB de VRAM utilisée. Les métriques Prometheus sont activables via le flag --metrics. La performance GPU est conforme aux spécifications techniques.
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le système RAG avec architecture, composants, limitations et procédures de mise à jour  
+
+**Problèmes :**
+- Scores de similarité uniformes avec Qwen3-8B
+- Temps long d'ingestion (5-10 minutes)
+
+**Suggestions :**
+- Ajouter des étapes détaillées pour déployer nomic-embed-text-v1.5
+- Optimiser le processus d'ingestion
+
+**État réel connu de Hermes :**  
+Le système RAG fonctionne correctement mais présente des limitations connues dans la qualité des embeddings
+
+---
+
+## ✅ `admin/ia/rocm.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais manque quelques étapes critiques  
+
+**Problèmes :**
+- Aucune mention de l'installation des paquets ROCm (dnf install rocm-*)
+- Pas de section sur la configuration des dépôts AMD/ROCm
+- Manque de conseils pour les utilisateurs non-root (sudo minimal)
+- Les commandes de vérification du module amdgpu sont trop basiques
+
+**Suggestions :**
+- Ajouter une section d'installation des paquets ROCm avec dnf
+- Inclure des exemples de configuration des dépôts AMD
+- Proposer des alternatives sans sudo pour les vérifications
+- Ajouter des explications sur l'importance de HSA_OVERRIDE_GFX_VERSION
+- Mettre en avant les commandes pour vérifier l'utilisation GPU en temps réel
+
+**État réel connu de Hermes :**  
+Configuration ROCm existante sur gpu-01 avec RX 6700XT, variables d'environnement correctes, mais nécessite validation des paquets installés et configuration des dépôts
+
+---
+
+## ✅ `admin/incidents.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec historique des incidents critiques et résolutions détaillées, incluant les étapes de migration RAID→NVMe.  
+
+**Problèmes :**
+- La date du document (2026-05-29) correspond au dernier incident, mais il manque une entry pour le 2026-06-04
+- Certains champs comme 'sévérité' sont omis pour les incidents antérieurs à 2026-05-29
+- Le format markdown des tableaux est incohérent entre les sections
+
+**Suggestions :**
+- Ajouter une entry pour l'incident du 2026-06-04
+- Standardiser le format des tableaux avec headers alignés
+- Ajouter des emojis visuels pour les niveaux de sévérité (⚠️, ⚠️, 🚨)
+- Mettre à jour le champ 'état_réel' avec les mesures préventives mises en place après la migration
+
+**État réel connu de Hermes :**  
+Le RAID5 a été remplacé par un LV NVMe XFS, les données sont maintenant en lecture seule sur le RAID dégradé, et les services sont opérationnels. Une surveillance étroite est en place pour détecter d'éventuelles erreurs de bus ATA.
+
+---
+

admin/hermes/builtin/2026-06-04_18-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-04_18-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et la gestion de dnsmasq avec des exemples pratiques et des solutions pour les problèmes courants  
+
+**Problèmes :**
+- La section sur le problème connu manque une explication technique sur pourquoi l'interface USB provoque le crash
+- Le chemin du playbook Ansible n'est pas résolu (../.venv/bin/ansible-playbook devrait être absolue)
+
+**Suggestions :**
+- Ajouter une note sur la priorité des interfaces réseau dans systemd
+- Mettre à jour le chemin du playbook Ansible vers /mnt/nvme0n1/nvme0n1p3/Projets/lab/ansible/
+- Ajouter un exemple de configuration complète de MetalLB dans la section DNS
+
+**État réel connu de Hermes :**  
+Opérationnel avec le problème du démarrage résolu par les fixes fournis. Les tests DNS fonctionnent sur tous les nœuds.
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration du relais SMTP via Postfix vers Gmail, avec tests et dépannage.  
+
+**Problèmes :**
+- Manque de mention sur la rotation périodique du App Password pour la sécurité
+- Aucune information sur la configuration des règles SPF/DKIM (même si brevo n'est pas utilisé)
+
+**Suggestions :**
+- Ajouter une section sur les bonnes pratiques de sécurité (rotation des credentials)
+- Mettre à jour la note sur les restrictions de Google (ex: limite de 500 emails/jour pour les comptes non vérifiés)
+- Ajouter un exemple de script pour tester automatiquement le relais
+
+**État réel connu de Hermes :**  
+Configuration fonctionnelle confirmée par les tests décrits, mais nécessite validation des quotas Gmail et vérification régulière des logs
+
+---
+
+## ✅ `admin/infra/nfs.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec RAID5, exports et automount, mais manque de précisions sur la sécurité et les procédures d'audit.  
+
+**Problèmes :**
+- Utilisation de 'no_root_squash' qui peut créer des risques de sécurité si non géré
+- Aucune mention des quotas ou des limites de stockage
+- Les playbooks Ansible référencés ne sont pas décrits dans le document
+- Absence de procédures pour la sauvegarde des données NFS
+
+**Suggestions :**
+- Ajouter une section sur la sécurisation des exports NFS
+- Préciser les paramètres recommandés pour les quotas et les limites
+- Expliciter le rôle des playbooks Ansible dans la gestion des exports
+- Inclure une procédure régulière de vérification des montages
+
+**État réel connu de Hermes :**  
+Le système NFS est actif sur storage-01 avec les exports configurés. Les automounts sur gpu-01 fonctionnent avec timeout de 30s. Les modèles GGUF sont correctement partagés via NFS.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation réseau complète avec configuration nftables, routes statiques et règles de forwarding, mais manque de vérification des configurations Ansible et de détails sur le déploiement.  
+
+**Problèmes :**
+- Aucune vérification des playbook Ansible pour la gestion nftables
+- La note sur l'ordre des règles nftables pourrait inclure un exemple concret
+- Les commandes de debug manquent de contexte sur les outils requis (ss, traceroute)
+
+**Suggestions :**
+- Ajouter un exemple de vérification des playbook Ansible
+- Inclure une capture d'écran ou un diagramme réseau pour clarifier le NAT
+- Mettre à jour la section DNS avec les entrées /etc/hosts actuelles
+
+**État réel connu de Hermes :**  
+Configuration nftables gérée par Ansible, IP forwarding activé, routes statiques configurées, mais nécessite validation des règles de sécurité
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers dans le cluster Funk, avec des exemples pratiques et des bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- Manque de mention des pratiques avancées comme l'agent SSH ou le forwarding d'agent
+- La commande de connexion en root pourrait inclure une note de sécurité plus explicite
+- Les exemples de transfert de fichiers ne mentionnent pas l'option -r pour les répertoires
+
+**Suggestions :**
+- Ajouter une section sur l'utilisation de l'agent SSH pour la gestion des clés
+- Mettre à jour la commande root avec un avertissement sur les risques de connexion en tant que root
+- Compléter les exemples scp avec l'option -r et des conseils sur la sécurisation des transferts
+
+**État réel connu de Hermes :**  
+Les configurations SSH du cluster sont actuellement configurées avec des clés ed25519, les aliases fonctionnent via ~/.ssh/config et les connexions sécurisées via ProxyJump sont activées pour gpu-01.
+
+---
+

admin/hermes/builtin/2026-06-04_18-30.md

@@ -0,0 +1,114 @@
+# Rapport Hermes — 2026-06-04_18-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ⚠️ `admin/install/README.md` — 7/10
+
+**Statut** : incomplet  
+**Résumé** : Document d'overview structuré avec ordre d'installation, mais manque de détails opérationnels dans le fichier lui-même  
+
+**Problèmes :**
+- Ne contient pas les étapes d'installation détaillées (seulement des liens vers d'autres fichiers)
+- Manque de prérequis techniques spécifiques pour chaque machine
+- Aucune information sur les dépendances logicielles/hardware nécessaires
+
+**Suggestions :**
+- Ajouter un résumé des étapes clés pour chaque machine dans le README principal
+- Inclure des exemples concrets de commandes à exécuter
+- Mettre en évidence les contraintes spécifiques (ex: HSA_OVERRIDE_GFX_VERSION=10.3.0 pour RX 6700XT)
+- Ajouter une section 'Dépendances' avec les prérequis système
+
+**État réel connu de Hermes :**  
+Le fichier existe et structure correctement les guides, mais les étapes détaillées sont réparties dans des fichiers externes (storage-01.md, gpu-01.md, kubernetes.md) qui ne sont pas inclus ici
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des étapes claires et des solutions pour le workaround ROCm RX 6700XT  
+
+**Problèmes :**
+- La section 'Vérifications post-install' manque des détails concrets (ex: tests de l'endpoint /v1/embeddings)
+- La configuration réseau ne précise pas les règles nftables nécessaires pour le NAT
+- Le playbook Ansible est mentionné sans détails sur ses contenus spécifiques
+
+**Suggestions :**
+- Ajouter une vérification du montage NFS vers /mnt/models
+- Indiquer les commandes pour tester l'endpoint OpenAI-compatible
+- Préciser les règles nftables pour le NAT et le pare-feu
+- Ajouter une section sur la validation des dépendances ROCm
+
+**État réel connu de Hermes :**  
+opérational avec workaround GFX1031 actif
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation d'un cluster Kubernetes sur trois ThinkCentre, avec une section détaillée sur les pièges à éviter.  
+
+**Problèmes :**
+- Manque de précisions sur la configuration exacte de Talos (ex: commandes talosctl spécifiques)
+- La version de Talos (v1.13.0) pourrait être obsolète si des mises à jour sont disponibles
+- Aucune mention des commandes spécifiques pour la génération des secrets SOPS/age
+- La section MetalLB ne précise pas les paramètres exacts du pool d'IPs
+- Le schéma réseau manque de détails sur la segmentation des sous-réseaux
+
+**Suggestions :**
+- Ajouter des exemples de commandes talosctl pour la configuration des nœuds
+- Mettre à jour les versions des composants avec les versions actuelles utilisées dans Funk
+- Préciser les étapes de chiffrement des secrets SOPS avec des exemples de fichiers .sops
+- Détailler la configuration MetalLB avec des exemples de valeurs Helm
+- Ajouter une section sur la validation des connexions réseau entre les nœuds
+
+**État réel connu de Hermes :**  
+Le document correspond à une installation réelle effectuée sur les trois ThinkCentre M715q avec les configurations décrites. Les erreurs documentées correspondent aux problèmes rencontrés lors de l'implémentation du cluster.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré, couvrant tous les aspects clés de la configuration de storage-01. Les étapes sont claires et les informations techniques précises.  
+
+**Problèmes :**
+- Manque de détails sur le contenu réel du playbook Ansible (seulement des références)
+- Aucune mention des scripts d'automatisation pour la configuration réseau
+- Pas de section dédiée aux résolutions de problèmes courants pendant l'installation
+
+**Suggestions :**
+- Ajouter une annexe avec le contenu du playbook Ansible cloné
+- Inclure des scripts d'automatisation pour la configuration réseau LAN/WAN
+- Ajouter une section 'Pièges courants' avec des exemples de résolutions
+- Mettre à jour les commandes pour refléter les dernières versions AlmaLinux 9.7
+
+**État réel connu de Hermes :**  
+Le document correspond exactement à la configuration actuelle de storage-01 dans Funk, y compris les configurations RAID5, les interfaces réseau, et les stack IA déployés.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet et structuré décrivant la configuration d'ArgoCD avec des étapes claires pour le déploiement et la gestion via GitOps  
+
+**Problèmes :**
+- Le script de récupération du mot de passe initial ne mentionne pas de suppression du secret après utilisation (même si cela est mentionné dans le texte)
+- Le fichier ne précise pas les bonnes pratiques de sécurité pour les secrets SSH et les credentails
+
+**Suggestions :**
+- Ajouter une note explicite sur la suppression du secret initial après changement du mot de passe
+- Mettre en avant les bonnes pratiques de chiffrement des secrets SSH
+- Vérifier si la version Helm 9.5.14 est toujours la plus récente recommandée
+
+**État réel connu de Hermes :**  
+Fonctionnel avec une configuration de base complète. Le repo GitOps est correctement structuré et les patterns App of Apps sont bien décrits.
+
+---
+

admin/hermes/builtin/2026-06-04_19-00.md

@@ -0,0 +1,102 @@
+# Rapport Hermes — 2026-06-04_19-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, la configuration et l'utilisation de k9s dans le cluster Funk, avec des exemples de cas d'usage.  
+
+**Problèmes :**
+- La section 'Cas d'usage fréquents' se termine brutalement en milieu de paragraphe
+- Les raccourcis clavier pour la navigation sont présentés sous forme de tableau très étendu
+
+**Suggestions :**
+- Structurer la section des raccourcis en sous-sections : général, ressources, actions
+- Compléter le cas d'usage 'débugger un pod en erreur' avec l'example de filtrage d'événements
+- Ajouter un avertissement sur l'utilisation de k9s avec des clusters multi-namespace
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec les configurations décrites, mais la documentation incomplète sur les cas d'usage avancés
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte versionnées.  
+
+**Problèmes :**
+- La section des règles d'alerte est incomplète (alerte PodPendingLong coupée)
+- Manque une mention des mises à jour récentes ou des changements de configuration
+
+**Suggestions :**
+- Compléter les règles d'alerte manquantes dans alerts-k8s.yaml
+- Ajouter une section 'Mises à jour récentes' avec les dernières modifications
+- Vérifier la version du kube-prometheus-stack et ses dépendances
+
+**État réel connu de Hermes :**  
+Le système de monitoring est opérationnel avec des métriques collectées sur tous les nœuds et services critiques. Les alertes sont configurées pour surveiller la santé du cluster, mais certaines règles d'alerte Kubernetes sont incomplètes.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et la configuration de n8n dans le cluster Funk, avec workflows d'alertes et de rapports système.  
+
+**Problèmes :**
+- Manque de détails sur l'accès au vault Ansible pour récupérer le mot de passe db-password
+- Aucune mention de sécurisation SMTP (STARTTLS/SSL) pour le relais vers Gmail
+- Absence de procédure de test pour le workflow de rapport système
+
+**Suggestions :**
+- Ajouter des étapes pour récupérer le mot de passe via ansible-vault
+- Spécifier les paramètres de sécurité pour le SMTP (STARTTLS, auth)
+- Inclure un exemple de test pour le workflow de rapport système
+
+**État réel connu de Hermes :**  
+n8n est déployé dans le namespace 'ai' avec les workflows d'alertes et de rapport système. Les secrets sont gérés via ArgoCD, mais la documentation manque des détails pratiques pour la première installation.
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée pour déployer et gérer Open WebUI dans le cluster Funk  
+
+**Problèmes :**
+- Aucun paragraphe sur la sécurité des secrets (rotation, chiffrement)
+- Pas de mention des stratégies de sauvegarde PostgreSQL
+
+**Suggestions :**
+- Ajouter une section sur la gestion des secrets (rotation, chiffrement)
+- Inclure des recommandations pour les sauvegardes régulières de la base de données
+
+**État réel connu de Hermes :**  
+Le composant est actif dans le cluster Funk avec les configurations décrites
+
+---
+
+## ✅ `admin/k8s/talos.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et bien structuré décrivant l'installation et l'administration du cluster Kubernetes Talos, avec des étapes claires et des bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- La dernière étape de la procédure d'installation Talos est incomplète (le texte s'arrête brutalement)
+
+**Suggestions :**
+- Compléter la dernière étape de la procédure d'installation Talos
+- Ajouter une note explicite sur la vérification des disques NVMe avant l'application de la configuration
+- Mettre en évidence les risques liés à la perte de la clé age privée
+
+**État réel connu de Hermes :**  
+null
+
+---
+

admin/hermes/builtin/2026-06-04_19-30.md

@@ -0,0 +1,70 @@
+# Rapport Hermes — 2026-06-04_19-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec des raccourcis Makefile utiles et des exemples concrets d'utilisation d'Ansible, mais manque de recommandations de sécurité pour le vault et d'explications sur les groupes d'hôtes.  
+
+**Problèmes :**
+- Aucune mention des bonnes pratiques de sécurisation du vault (ex: chiffrement AES-256, gestion des clés)
+- Les groupes d'hôtes ne sont pas expliqués (pourquoi ils existent, leur utilité dans les playbooks)
+- Absence de mention des nouvelles fonctionnalités Ansible 2.14+ (ex: ansible-builder, molecule)
+
+**Suggestions :**
+- Ajouter une section sur la sécurisation du vault avec des exemples de chiffrement AES-256 et gestion des clés
+- Expliciter le rôle de chaque groupe d'hôtes dans les playbooks (ex: 'gateway' gère les règles de pare-feu)
+- Mettre à jour les exemples avec les dernières syntaxes Ansible (ex: 'ansible-playbook -i inventory.yml' au lieu de 'playbooks/site.yml')
+
+**État réel connu de Hermes :**  
+Le setup Ansible est fonctionnel avec des playbooks opérationnels, mais les pratiques de sécurité devraient être renforcées et les documentation mise à jour pour refléter les standards actuels.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des procédures de gestion du cluster Funk avec des commandes clés et des étapes détaillées, mais nécessite des améliorations dans la précision technique.  
+
+**Problèmes :**
+- Manque de précision sur les délais réels pour le chargement des modèles LLM (4-7 minutes selon la charge)
+- Aucune mention des risques de perte de données lors des arrêts brutaux
+- Le section 'GitOps' renvoie à un fichier local inexistant (k8s/argocd.md)
+- Pas de note de sécurité sur les configurations BIOS Wake-on-LAN
+
+**Suggestions :**
+- Ajouter des intervalles de temps réalistes pour chaque étape (ex: 4-7 minutes pour les modèles GPU)
+- Inclure une section de dépannage avec solutions pour les erreurs WOL/NFS
+- Mettre à jour le lien vers la documentation ArgocD vers le fichier existant
+- Ajouter une note de sécurité sur la configuration BIOS pour Wake-on-LAN
+
+**État réel connu de Hermes :**  
+Le cluster fonctionne avec les composants décrits (storage-01, gpu-01, k8s). Les commandes 'funk-start'/'funk-stop' sont opérationnelles, mais les délais réels peuvent varier selon la charge système.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant les opérations système pour AlmaLinux 9 sur les machines Funk, avec des commandes clés et des configurations essentielles.  
+
+**Problèmes :**
+- Lien vers infra/dnsmasq.md est relatif et pourrait ne pas être accessible en absolu
+- Aucune mention des configurations spécifiques pour le RAID5 post-reboot
+- Les commandes 'htop' et 'lsblk' nécessitent des installations supplémentaires (EPEL)
+
+**Suggestions :**
+- Ajouter des exemples concrets de commandes pour les services clés
+- Inclure une section sur les bonnes pratiques pour les mises à jour système
+- Vérifier la validité des chemins vers les playbooks Ansible
+
+**État réel connu de Hermes :**  
+Documentation fonctionnelle avec des configurations validées sur les machines Funk, mais nécessite des corrections mineures pour les liens et les dépendances logicielles.
+
+---
+

admin/hermes/builtin/2026-06-04_20-00.md

@@ -0,0 +1,94 @@
+# Rapport Hermes — 2026-06-04_20-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Le document d'administration est complet et structuré, avec des liens vers les guides essentiels. Il couvre les opérations quotidiennes, l'infrastructure, le cluster Kubernetes et la stack IA.  
+
+**Problèmes :**
+- Le lien vers [ia/rocm.md](ia/rocm.md) pourrait inclure une note sur la configuration requise pour RX 6700XT (HSA_OVERRIDE_GFX_VERSION=10.3.0)
+- Le fichier [incidents.md](incidents.md) est mentionné mais non détaillé dans le résumé du document
+
+**Suggestions :**
+- Ajouter un avertissement sur la configuration de HSA_OVERRIDE_GFX_VERSION dans la section ia/rocm.md
+- Mettre à jour la section 'Débugger l'inférence LLM' pour inclure les nouvelles procédures de monitoring des GPU
+- Ajouter un sous-section dans 'ops/cluster.md' expliquant les étapes pour déployer des conteneurs sur les workers k8s
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster Funk, avec des liens valides vers les fichiers d'installation et de configuration.
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le webhook AlertManager-Hermes, couvrant l'architecture, le fonctionnement et les tests, mais manquant de détails sur la sécurité et les cas d'erreur.  
+
+**Problèmes :**
+- Aucune mention des mécanismes de sécurité (authentification, rate limiting)
+- Détailler les cas d'erreur et les codes de réponse HTTP spécifiques
+- Manque de diagramme visuel pour l'architecture
+
+**Suggestions :**
+- Ajouter une section sur les mesures de sécurité
+- Préciser les scénarios d'erreur et leur gestion
+- Mettre à jour la note d'état avec les dernières vérifications
+
+**État réel connu de Hermes :**  
+Le service est opérationnel avec des logs fonctionnels, les tests manuels réussissent et les alertes sont traitées par ask-agent comme prévu.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer le client vocal Hermes avec architectures, installation, modes d'utilisation et configuration. Les étapes sont claires mais quelques détails manquent.  
+
+**Problèmes :**
+- La section 'Dépannage' est très courte et pourrait inclure des cas courants comme l'absence de modèle Whisper
+- Le test Piper manque une note sur les dépendances système requises
+- Le téléchargement automatique du modèle Whisper n'est pas explicitement mentionné dans la section 'Environnement Python'
+
+**Suggestions :**
+- Ajouter une sous-section 'Dépendances supplémentaires' pour les bibliothèques système
+- Mettre en évidence le paramètre 'HERMES_MODE' dans la configuration
+- Ajouter un exemple concret de requête SSH vers Hermes dans la section 'Utilisation'
+
+**État réel connu de Hermes :**  
+Le composant est actif dans le homelab avec les configurations décrites. Le mode SSH est prioritaire et utilise les compétences RAG et la mémoire long terme de Hermes.
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'architecture, les profils, les services et la configuration de Hermes Agent. Le fichier présente des informations structurées et opérationnelles.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (tronquée à '/srv/data/he---')
+- Le format markdown présente des incohérences dans les tableaux (|---|---|---| sans entête)
+- Les exemples de commande CLI manquent de contexte d'utilisation
+
+**Suggestions :**
+- Compléter la section SOUL.md avec le contenu manquant
+- Ajouter des exemples concrets de scénarios d'utilisation pour chaque profil
+- Standardiser le format des tableaux avec des en-têtes clairs
+
+**État réel connu de Hermes :**  
+Le composant Hermes Agent est opérationnel avec des configurations correctes. La documentation reflète l'état actuel sauf pour la section SOUL.md incomplète.
+
+---
+

admin/hermes/builtin/2026-06-04_20-30.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-04_20-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM, mais avec un gap IaC sur les modèles CPU  
+
+**Problèmes :**
+- Le template Ansible ne comprend pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires aux agents ask-agent
+- Les modifications manuelles dans /etc/litellm/config.yaml ne sont pas reflétées dans le template Ansible
+- Le coût des modèles Claude n'est pas quantifié en USD
+- Manque de mention des dépendances externes (vault_anthropic_api_key)
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure tous les modèles référencés
+- Ajouter une section sur la gestion des clés API et les intégrations avec le vault
+- Quantifier précisément les coûts Claude en USD par million de tokens
+- Ajouter une note sur les dépendances externes requises pour la configuration
+
+**État réel connu de Hermes :**  
+Fonctionnel avec contournement manuel, mais configuration incomplète pour déploiement automatisé
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les performances du llama-server sur gpu-01, avec des instructions opérationnelles et des métriques détaillées.  
+
+**Problèmes :**
+- L'explication du 'bug parallel' liée à Hermes est incomplète
+- Aucune mention des procédures de sauvegarde ou de reprise en cas de panne
+
+**Suggestions :**
+- Ajouter une section sur la configuration TLS pour les API
+- Préciser les politiques de mise à jour des modèles
+- Mettre en évidence les seuils critiques de VRAM
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel avec les configurations actuelles, mais manque de résilience et de sécurité réseau
+
+---
+
+## ✅ `admin/ia/rag.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et l'utilisation du RAG dans Funk, avec architecture, composants, modèles et procédures de mise à jour.  
+
+**Problèmes :**
+- Aucun mention des mesures de sécurité pour accéder à Qdrant
+- Les temps d'ingestion via GPU ne sont pas quantifiés précisément
+
+**Suggestions :**
+- Ajouter une section sur les règles d'accès aux données vectorielles
+- Proposer des benchmarks temps de réponse pour les modèles d'embedding
+- Mettre en avant l'option Ansible pour la maintenance automatisée
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec Qdrant et rag-query, les procédures d'indexation sont documentées, mais manque de mesures de sécurité et de SLA pour l'ingestion
+
+---
+
+## ✅ `admin/ia/rocm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré pour la configuration ROCm sur RX 6700XT avec vérifications clés et commandes de débogage  
+
+**Problèmes :**
+- Manque de vérification pour les mises à jour ROCm récentes
+- Aucune mention des dépendances logicielles supplémentaires requises
+
+**Suggestions :**
+- Ajouter une section pour vérifier les mises à jour ROCm via 'dnf check-update'
+- Inclure des commandes pour installer les pilotes AMD si nécessaire
+- Mettre en évidence les risques liés à l'override de la version GFX
+
+**État réel connu de Hermes :**  
+Le document décrit correctement les étapes de base pour ROCm, mais les configurations réelles dépendent des versions actuelles des paquets installés sur gpu-01
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents complet et structuré, avec résolution détaillée pour l'incident du 2026-05-29  
+
+**Problèmes :**
+- La section 'État post-migration' est incomplète (phrase coupée : 'Espace disponibl')
+- Manque de détails sur la validation post-migration des systèmes critiques
+- Format de la table des incidents pourrait être standardisé (alignement des colonnes)
+
+**Suggestions :**
+- Compléter la section 'État post-migration' avec les métriques d'espace disque et le statut des services
+- Ajouter une colonne 'Action corrective' pour chaque incident
+- Mettre à jour le tableau des incidents avec les dates au format AAAA-MM-JJ
+- Ajouter un résumé visuel des incidents critiques au début du document
+
+**État réel connu de Hermes :**  
+Le composant /srv/data a été migré vers le NVMe XFS avec succès. Le RAID5 original est dégradé [4/3] mais les données sont désormais stockées sur un volume plus fiable. Les services ont été redémarrés sans incident majeur.
+
+---
+

admin/hermes/builtin/2026-06-04_21-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-04_21-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et la gestion de dnsmasq avec des exemples pratiques, bien que quelques améliorations soient possibles.  
+
+**Problèmes :**
+- La section 'Problème connu' mentionne un fix Ansible mais ne précise pas le chemin exact du playbook (le chemin 'playbooks/storage-01.yml' est indiqué mais pourrait être vérifié)
+- Le test DNS sur gpu-01 ne montre pas explicitement l'utilisation de 'dig' ou 'nslookup' avec l'IP de storage-01
+- Le template MetalLB pour la wildcard DNS n'est pas illustré avec un exemple concret
+
+**Suggestions :**
+- Ajouter un exemple de commande 'dig' sur gpu-01 avec l'IP de storage-01 pour clarifier les tests
+- Mettre en évidence le template MetalLB avec un exemple de configuration complète
+- Vérifier la mise à jour du chemin du playbook Ansible dans la documentation
+- Ajouter une note sur la priorité des interfaces réseau dans systemd pour éviter les crashes
+
+**État réel connu de Hermes :**  
+dnsmasq fonctionne correctement sur storage-01 avec résolution DNS pour *.lab.local. Le problème USB persistant nécessite le fix systemd mentionné. Les tests DNS montrent des résultats attendus sur les machines du cluster.
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail avec des étapes claires et des vérifications  
+
+**Problèmes :**
+- Manque de mention sur la rotation sécurisée des App Passwords
+- Aucune indication sur la configuration SPF/DKIM pour le domaine de l'expéditeur
+
+**Suggestions :**
+- Ajouter une section sur la gestion des mots de passe SMTP (rotation, stockage sécurisé)
+- Mettre à jour les exemples de code Python avec des pratiques de sécurité modernes
+
+**État réel connu de Hermes :**  
+Le relais SMTP est opérationnel selon la documentation, mais les mesures de sécurité avancées (rotation de clés, vérification SPF/DKIM) ne sont pas implémentées
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des configurations NFS avec procédures claires, mais manque de sections sur la surveillance et la résolution des problèmes.  
+
+**Problèmes :**
+- Aucune mention des mécanismes de surveillance NFS (ex: tools de monitoring, checks réguliers)
+- Le comportement d'automontage n'explique pas les retards potentiels lors des premiers accès
+- La section GGUF ne détaill pas comment les modèles sont accessibles via NFS (chemins d'accès, permissions)
+
+**Suggestions :**
+- Ajouter une section 'Surveillance' avec des commandes comme 'nfsstat', 'showmount', et des règles d'alerte
+- Mettre en évidence les retards d'automontage dans le comportement client avec des exemples concrets
+- Clarifier le mapping entre les répertoires NFS et les chemins d'accès sur gpu-01 pour les modèles GGUF
+
+**État réel connu de Hermes :**  
+Les exports NFS sont actifs sur storage-01 avec les chemins /srv/data/nfs/k8s et /srv/data/models. Les automontages sur gpu-01 fonctionnent selon les paramètres x-systemd. Les modèles GGUF sont effectivement partagés via NFS vers /mnt/models.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et debugging.  
+
+**Problèmes :**
+- Manque d'exemples concrets pour l'insertion de règles nftables avant la règle drop terminale
+- La note sur les DNS indique que storage-01 utilise 1.1.1.1/9.9.9.9 mais la /etc/hosts contient une entrée manuelle pour gpu-01, ce qui pourrait causer des ambiguïtés
+
+**Suggestions :**
+- Ajouter un exemple pratique d'insertion de règle nftables avec position=<handle_avant_drop>
+- Clarifier la configuration DNS : préciser que /etc/hosts est le seul point de vérité pour les résolutions critiques
+- Mettre en évidence la priorité des règles nftables (insert vs add)
+
+**État réel connu de Hermes :**  
+Le réseau est correctement configuré avec Ansible gérant les nftables, les routes statiques et le DNS. Les règles de forwarding sont en place, mais la documentation pourrait être plus précise sur les cas d'usage avancés.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur les connexions SSH avec des alias, transferts de fichiers et débogage, mais manque de détails sur la sécurité et la configuration avancée.  
+
+**Problèmes :**
+- Aucune explication sur la configuration de ProxyJump dans les alias
+- Utilisation de root@ dans l'exemple de connexion (risque de sécurité)
+- Manque de mention sur la gestion des clés (génération, ajout à l'agent)
+- Les commandes de débogage pourraient inclure des exemples de vérification des clés
+
+**Suggestions :**
+- Ajouter une explication sur la configuration de ProxyJump dans ~/.ssh/config
+- Remplacer la connexion root par sudo et mettre en garde contre l'utilisation de root
+- Inclure des exemples de génération de clés (ssh-keygen) et d'ajout à l'agent
+- Détailler la commande ssh -v pour identifier les erreurs de clé
+
+**État réel connu de Hermes :**  
+Les configurations SSH sont actives sur les machines du cluster, les clés ed25519 sont configurées et les transferts fonctionnent via les alias. Les connexions à root sont limitées aux cas spécifiques.
+
+---
+

admin/hermes/builtin/2026-06-04_21-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-04_21-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée avec ordre d'installation clair, mais manque de détails techniques sur les étapes de configuration  
+
+**Problèmes :**
+- Le fichier ne contient pas le contenu des guides individuels (storage-01.md, gpu-01.md, kubernetes.md) mentionnés dans les liens
+- Aucune indication sur les commandes de déploiement ou les étapes concrètes d'installation
+- Les dépendances techniques (ex: pourquoi DHCP est critique pour Talos) ne sont pas expliquées
+
+**Suggestions :**
+- Intégrer le contenu des fichiers liés directement dans ce README pour une documentation autonome
+- Ajouter des exemples de commandes CLI pour chaque étape de configuration
+- Préciser les risques liés à l'ordre d'installation et les alternatives en cas de panne
+- Inclure une section 'Prérequis système' pour chaque machine
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré pour gpu-01, couvrant from l'OS à la configuration ROCm et Ansible avec des détails techniques précis.  
+
+**Problèmes :**
+- La section Ansible 'inventory.yml' est incomplète (ligne coupée)
+- Le workaround ROCm pour RX 6700XT (gfx1031) pourrait être mieux mis en évidence comme solution critique
+
+**Suggestions :**
+- Ajouter une section 'Post-installation vérification' avec des tests spécifiques ROCm
+- Compléter le fichier inventory.yml dans le repo
+- Mettre en avant la variable HSA_OVERRIDE_GFX_VERSION comme condition préalable essentielle
+
+**État réel connu de Hermes :**  
+Opérationnel dans Funk avec ROCm 7.x, llama-server fonctionnant sur RX 6700XT via le workaround documenté
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document d'installation complet et structuré avec tous les étapes clés pour déployer un cluster Kubernetes sur trois ThinkCentre, incluant des sections détaillées sur l'architecture, les prérequis réseau, la configuration Talos, et la gestion des secrets.  
+
+**Problèmes :**
+- Manque de section sur les bonnes pratiques de sécurité (ex: RBAC, réseau épinglé)
+- Pas de mention des politiques de mise à jour pour les composants Kubernetes/Talos
+- La partie 'Pièges et erreurs' est située en fin de document, pourrait être plus accessible dès les étapes critiques
+
+**Suggestions :**
+- Ajouter une section sur la surveillance (Prometheus/Grafana) et la gestion des alertes
+- Inclure un exemple concret de configuration Talos pour les workers
+- Mettre à jour les versions des outils (ex: Talos v1.13.0 est maintenant obsolète)
+- Ajouter une note sur la gestion des dépendances externes (ex: Helm charts)
+
+**État réel connu de Hermes :**  
+Le document correspond exactement à l'infrastructure Funk actuelle, avec les trois ThinkCentre et la configuration réseau décrite. Les sections sur Talos et MetalLB sont particulièrement détaillées et alignées avec les pratiques observées.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de storage-01, couvrant l'OS, la configuration réseau, Ansible et la stack IA. Les sections sont bien organisées avec des détails techniques précis.  
+
+**Problèmes :**
+- La mention du disque sdb avec erreurs I/O nécessite une clarification sur les mesures de surveillance recommandées
+- La référence à 'poste perso' est ambiguë et pourrait être précisée (probablement un terme interne au lab)
+
+**Suggestions :**
+- Ajouter une section sur la gestion des erreurs RAID5 avec des commandes de diagnostic spécifiques
+- Clarifier la signification de 'poste perso' dans le contexte du lab
+- Mettre en évidence les prérequis système (ex: HSA_OVERRIDE_GFX_VERSION=10.3.0 pour RX 6700XT)
+
+**État réel connu de Hermes :**  
+storage-01 est opérationnel avec la configuration décrite. Le RAID5 présente des risques connus sur sdb nécessitant une surveillance proactive avec smartctl.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation d'ArgoCD dans Funk, avec des procédures claires pour le déploiement GitOps, mais contient quelques éléments à vérifier.  
+
+**Problèmes :**
+- La version d'ArgoCD (9.5.14) pourrait être obsolète (vérifier la dernière version disponible)
+- L'exemple de déploiement Helm utilise un repo URL placeholder (https://charts.exemple.com) qui doit être remplacé
+- La syntaxe YAML dans l'exemple de déploiement Helm contient un espace superflu après 'server:'
+- Le chemin 'k8s/argocd-bootstrap/values.yaml' pourrait être obsolète si le bootstrap est désormais automatisé
+
+**Suggestions :**
+- Ajouter une note sur la vérification des versions d'ArgoCD avant déploiement
+- Mettre à jour l'exemple de déploiement Helm avec un repo URL valide et expliciter la syntaxe correcte
+- Ajouter une section sur la gestion des secrets sensibles (SSH, credentials)
+- Clarifier la différence entre 'targetRevision' pour les charts Helm et les repos Git
+
+**État réel connu de Hermes :**  
+Le composant est actif dans Funk, avec des déploiements GitOps fonctionnels. Les procédures décrites correspondent aux pratiques courantes, mais des vérifications sont nécessaires pour les versions et URLs spécifiques.
+
+---
+

admin/hermes/builtin/2026-06-04_22-00.md

@@ -0,0 +1,105 @@
+# Rapport Hermes — 2026-06-04_22-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet sur l'installation et la configuration de k9s avec des exemples pratiques, bien que les versions soient un peu datées  
+
+**Problèmes :**
+- L'installation sur storage-01 depuis le poste perso utilise une version spécifique (0.50.18) sans mentionner les dernières versions disponibles
+- Le paragraphe sur la configuration des namespaces manque de détails sur la syntaxe YAML exacte
+- Le cas d'usage sur les events ne montre pas comment filtrer par nom de pod
+
+**Suggestions :**
+- Mettre à jour le lien vers la dernière version de k9s
+- Ajouter un exemple de configuration YAML complet pour les namespaces
+- Compléter la section 'débugger un pod en erreur' avec des raccourcis pour filtrer les events
+
+**État réel connu de Hermes :**  
+Le setup k9s est fonctionnel sur le cluster Funk avec les configurations décrites, mais pourrait bénéficier de mises à jour pour les versions et configurations avancées
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte versionnées  
+
+**Problèmes :**
+- La section des règles d'alerte est incomplète (coupure prématurée)
+- Présence de texte erroné en fin de document ('Réponds UNIQUEMENT en JSON valide...')
+
+**Suggestions :**
+- Compléter la section des règles d'alerte manquantes
+- Supprimer le texte erroné au bas du document
+- Ajouter des exemples concrets de règles d'alerte dans la section 'Nœuds' pour clarifier les seuils
+
+**État réel connu de Hermes :**  
+Stack de monitoring déployée via ArgoCD dans le namespace 'monitoring', avec dashboards et alertes versionnés. Les métriques sont collectées via Prometheus avec des scrapeurs spécifiques aux nœuds et services GPU.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les workflows d'n8n dans le cluster Funk, avec détails sur l'architecture, les déploiements et les intégrations critiques.  
+
+**Problèmes :**
+- Le script de création du secret référence un mot de passe dans un vault Ansible sans détailler la procédure d'accès
+- Les exemples de test des workflows manquent d'indications sur la vérification des résultats
+
+**Suggestions :**
+- Ajouter une note sur la gestion des erreurs courantes (ex: configuration SMTP, problèmes d'authentification LLM)
+- Mettre en évidence les dépendances externes (ex: Postfix, LiteLLM) dans une section 'Prérequis'
+- Inclure un exemple de vérification du fonctionnement des workflows après déploiement
+
+**État réel connu de Hermes :**  
+n8n est actif dans le cluster avec les workflows déployés. Les métriques système sont collectées et les alertes sont traitées via le pipeline décrit.
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation d'Open WebUI dans le cluster Kubernetes, avec des sections clés sur l'architecture, la déployment et le dépannage.  
+
+**Problèmes :**
+- La création du secret mentionne un mot de passe PostgreSQL dans un vault Ansible, mais ne fournit pas de commande pour le récupérer
+- Le tableau de comparaison avec Hermes TUI manque de détails techniques sur les différences de stack backend
+
+**Suggestions :**
+- Ajouter une étape pour vérifier la connexion PostgreSQL après création du secret
+- Mettre en évidence les variables d'environnement critiques dans un tableau séparé
+- Ajouter une note sur la gestion des permissions NFS pour le PVC
+
+**État réel connu de Hermes :**  
+Opérationnel avec les modèles Qwen3-8B et Claude configurés, mais le téléchargement initial des modèles RAG peut prendre 2-3 minutes
+
+---
+
+## ✅ `admin/k8s/talos.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet pour Talos Linux et cluster Kubernetes, mais avec une erreur critique dans la procédure d'installation  
+
+**Problèmes :**
+- La procédure d'installation (étape 4) contient une commande incomplète (cut-off avec 't---')
+- Les commandes longues (ex: talhelper installation) pourraient être découpées pour la clarté
+- Manque de mention des prérequis système (ex: installation de Docker, permissions root)
+
+**Suggestions :**
+- Compléter la commande incomplète dans l'étape 4 de la procédure d'installation
+- Ajouter des explications sur la gestion des permissions et les prérequis système
+- Structurer les commandes en étapes distinctes pour améliorer la lisibilité
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes fonctionne sur les 3 nœuds ThinkCentre avec Talos Linux v1.13.0 et Kubernetes v1.33.1. Les configurations sont gérées via talhelper et les secrets avec SOPS/age.
+
+---
+

admin/hermes/builtin/2026-06-04_22-30.md

@@ -0,0 +1,66 @@
+# Rapport Hermes — 2026-06-04_22-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et gestion du Vault, bien structurée et actualisée  
+
+**Problèmes :**
+- Les commandes Makefile manquent de gestion d'erreurs et de dépendances
+- La section Vault ne décrit pas comment gérer les chaînes chiffrées dans des scénarios réels
+
+**Suggestions :**
+- Ajouter des blocs 'try/catch' dans les Makefile pour capturer les erreurs
+- Ajouter un exemple concret de'utilisation des chaînes chiffrées dans vault.yml
+- Mettre à jour les exemples de commandes ad-hoc avec des scénarios réels
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec des playbooks validés, mais nécessite des améliorations dans la résilience des scripts et la documentation des pratiques avancées
+
+---
+
+## ✅ `admin/ops/cluster.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et structurée des procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt.  
+
+**Problèmes :**
+- Le référentiel GitOps mentionne un fichier k8s/argocd.md qui n'est pas inclus dans la documentation actuelle
+- Aucune mention des dépendances logicielles requises (comme wakeonlan-cli) pour les commandes WOL
+
+**Suggestions :**
+- Ajouter une section sur la configuration du Wake-on-LAN pour les compute nodes
+- Inclure des exemples de commandes pour vérifier l'état des services post-démarrage
+- Ajouter des notes de sécurité sur l'arrêt forcé des services
+- Lier le fichier argocd.md via un lien local ou un chemin relatif valide
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster Funk, avec des procédures validées par les scripts funk-start/funk-stop
+
+---
+
+## ✅ `admin/ops/systeme.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et bien structuré décrivant les opérations système sur AlmaLinux 9, avec des commandes pratiques et des configurations clés pour le cluster Funk.  
+
+**Problèmes :**
+- Manque la mention de l'override HSA_REQUIRED=10.3.0 pour RX 6700XT (important pour la compatibilité ROCm)
+- Référence externe à infra/dnsmasq.md qui n'est pas inclus dans le fichier actuel
+
+**Suggestions :**
+- Ajouter la commande HSA_OVERRIDE_GFX_VERSION=10.3.0 dans la section des paramètres ROCm
+- Inclure le contenu de infra/dnsmasq.md pour complétude
+- Ajouter des exemples concrets pour les commandes comme 'nmcli' ou 'top'
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster, mais manque quelques détails critiques pour la stabilité du matériel ROCm
+
+---
+

admin/hermes/builtin/2026-06-04_23-00.md

@@ -0,0 +1,99 @@
+# Rapport Hermes — 2026-06-04_23-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet avec navigation rapide et guides d'installation, mais présente quelques lacunes de mise à jour et de détails.  
+
+**Problèmes :**
+- Liens vers des fichiers potentielslement obsolètes (vérification nécessaire)
+- Manque de versioning et de date de mise à jour
+- La section incidents.md est mentionnée mais pas détaillée dans le résumé
+
+**Suggestions :**
+- Ajouter des versions et dates de mise à jour
+- Valider la présence et la pertinence des liens vers les fichiers mentionnés
+- Expander la section incidents.md avec des exemples concrets
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur le webhook AlertManager-Hermes, avec architecture, fonctionnement, tests et gestion des services. Peut être amélioré par des exemples d'erreurs et des mesures de sécurité.  
+
+**Problèmes :**
+- Le formatage des alertes manque les balises de date/heure dans les exemples
+- Aucune mention des cas d'erreur (ex: timeout, format JSON invalide)
+- Le diagramme d'architecture manque les annotations de ports/IP
+- Les exemples de curl ne montrent pas les en-têtes authentification (si nécessaires)
+
+**Suggestions :**
+- Ajouter un exemple de payload avec les champs complets (generatorURL, startsAt, etc.)
+- Inclure une section sur les mesures de sécurité (authentification, rate limiting)
+- Ajouter des tests pour les alertes avec différentes gravités (info/warning/critical)
+- Mettre en évidence les dépendances externes (ex: requiert le service LiteLLM)
+
+**État réel connu de Hermes :**  
+Le service est opérationnel avec les configurations décrites. Les logs journalctl montrent des réponses 200 OK et des analyses IA via ask-agent. Aucun incident signalé récemment.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du client vocal Hermes avec architecture, installation, modes d'utilisation et configuration, mais avec quelques lacunes dans les détails techniques.  
+
+**Problèmes :**
+- La section dépannage mentionne un problème avec Whisper mais ne propose pas de solutions concrètes
+- Manque de détails sur la configuration SSH (génération de clés, tests de connexion)
+- Les variables de configuration ne sont pas illustrées avec d'exemples d'usage
+
+**Suggestions :**
+- Ajouter une section détaillant la configuration SSH (test de connexion, vérification des clés)
+- Compléter le dépannage avec des solutions pour les problèmes de transcription Whisper
+- Préciser les valeurs recommandées pour les variables de configuration (ex: seuil de détection voix)
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans le cluster Funk, avec des instructions claires pour l'installation et l'utilisation. Les problèmes identifiés ne bloquent pas le fonctionnement mais nécessitent des améliorations pour une meilleure robustesse.
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur l'architecture et la gestion de Hermes Agent, avec des sections structurées et des exemples de commandes, mais avec des incohérences de formatage à corriger.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (ligne coupée)
+- L'indentation des tableaux YAML est incorrecte dans la config.yaml
+- La documentation des variables d'environnement manque des explications sur leur utilisation
+- La mention des droits d'accès au dashboard web est trop brève
+
+**Suggestions :**
+- Compléter la section SOUL.md avec des exemples de contenu
+- Ajouter des explications sur la configuration des profils
+- Mettre à jour les chemins de fichier pour refléter la structure actuelle
+- Ajouter des exemples concrets de commandes CLI
+
+**État réel connu de Hermes :**  
+Le composant Hermes Agent est opérationnel avec les configurations décrites, mais les fichiers de configuration nécessitent des mises à jour pour aligner les chemins et les paramètres.
+
+---
+

admin/hermes/builtin/2026-06-04_23-30.md

@@ -0,0 +1,116 @@
+# Rapport Hermes — 2026-06-04_23-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration et l'utilisation de LiteLLM, avec des notes clés sur les modèles CPU manquants dans le template Ansible  
+
+**Problèmes :**
+- Le template Ansible litellm/config.yaml.j2 manque les modèles CPU qwen3-1.7b-system et qwen3-1.7b-monitor
+- Le script hermes-switch modifie manuellement le fichier de config sans synchronisation avec le template Ansible
+
+**Suggestions :**
+- Ajouter les modèles CPU dans le template Ansible pour une gestion IaC complète
+- Mettre à jour le script hermes-switch pour utiliser le template Ansible plutôt que des modifications manuelles
+- Ajouter des exemples d'utilisation des modèles CPU dans la documentation
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml, ce qui crée un décalage avec le template Ansible. Un déploiement standard via make apply-storage ne provisionnerait pas ces modèles.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration des trois instances llama-server sur gpu-01, avec paramètres VRAM, API OpenAI, embeddings et métriques Prometheus.  
+
+**Problèmes :**
+- La mention du 'bug parallel' dans la section Performances est ambiguë et nécessite clarification
+- Le calcul VRAM (9GB) ne tient pas compte des overheads système potentiels
+- Aucune mention des restrictions de débit pour les requêtes concurrentes
+
+**Suggestions :**
+- Ajouter un tableau comparatif des métriques CPU/GPU
+- Inclure des exemples de monitoring à long terme (ex: journalctl rotation)
+- Mettre en évidence les prérequis ROCm 7.x spécifiques au RX 6700XT
+
+**État réel connu de Hermes :**  
+Les trois instances fonctionnent correctement avec des métriques exposées. Le modèle GPU utilise 9GB VRAM (avec 12GB disponibles), les embeddings sont activés et les métriques Prometheus sont accessibles via /metrics. Le problème de parallélisme nécessite validation expérimentale.
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le RAG déployé dans Funk, incluant architecture, composants, modèles d'embedding et procédures d'indexation, mais avec des limitations connues dans la qualité des embeddings.  
+
+**Problèmes :**
+- Les embeddings générés par Qwen3-8B présentent une discrimination sémantique limitée (scores cosinus uniformément élevés)
+- Aucune procédure détaillée pour déployer des modèles d'embedding alternatifs (nomic-embed-text-v1.5, bge-m3)
+- Le processus manuel d'indexation nécessite des commandes ssh/rsync potentiellement fragiles
+- Aucune mention des retards d'ingestion (5-10 minutes pour 339 chunks)
+
+**Suggestions :**
+- Ajouter une section détaillant la migration vers des modèles d'embedding spécialisés (ex: nomic-embed-text-v1.5)
+- Inclure un exemple concret de script pour surveiller la fin de l'ingestion (via Ansible ou cron)
+- Mettre en avant les alternatives aux embeddings GPU (CPU avec pooling mean)
+- Ajouter un avertissement sur les risques de surcharge du GPU lors de l'ingestion massique
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel mais subit des limitations connues dans la qualité des embeddings. L'indexation automatisée via Ansible fonctionne, mais les alternatives de modèles d'embedding restent à implémenter.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais manque de contexte technique et de mises à jour sur les outils modernes  
+
+**Problèmes :**
+- Aucune explication sur le pourquoi de HSA_OVERRIDE_GFX_VERSION=10.3.0
+- Commandes ssh g01 pourraient être obsolètes (nom de la machine ?)
+- Manque de vérification des pilotes AMD propriétaires
+- Pas de mention des erreurs courantes (ex: 'rocminfo: command not found')
+- Absence de conseils pour les utilisateurs non-root
+
+**Suggestions :**
+- Ajouter une section expliquant le besoin de HSA_OVERRIDE_GFX_VERSION
+- Mettre à jour les commandes pour utiliser le hostname actuel (gpu-01)
+- Inclure des vérifications pour les pilotes AMD propriétaires
+- Ajouter un exemple de sortie attendue pour rocminfo
+- Proposer des commandes pour vérifier les permissions sudo
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec historique des incidents et résolutions détaillées, mais présente quelques incohérences de format et de consistance.  
+
+**Problèmes :**
+- Incohérence entre la gravité 'Important' et 'Critique' pour l'incident du 2026-05-29
+- Tableau d'État post-migration incomplet (ligne 'Espace disponibl' tronquée)
+- Format markdown incohérent entre le tableau d'index et les sections détaillées
+- Absence de note sur les mesures préventives ou les leçons apprises
+
+**Suggestions :**
+- Standardiser les niveaux de gravité (Important/Critique/Warning) entre l'index et les sections détaillées
+- Compléter le tableau d'État post-migration avec les métriques d'espace disque
+- Ajouter une section 'Leçons apprises' ou 'Mesures préventives' pour chaque incident
+- Normaliser le format des tableaux (alignement des colonnes, syntaxe markdown)
+- Ajouter des notes explicatives pour les commandes critiques comme 'mdadm --manage'
+
+**État réel connu de Hermes :**  
+Le composant /srv/data a été migré vers le NVMe avec succès. Le RAID5 original est maintenant en mode dégradé. Les services sont opérationnels avec les configurations mises à jour.
+
+---
+

admin/hermes/builtin/2026-06-05_00-00.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-05_00-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration et la gestion de dnsmasq dans le cluster Funk, avec des exemples pratiques et des solutions pour les problèmes courants.  
+
+**Problèmes :**
+- La section 'Ajouter une entrée DNS' mentionne un fichier YAML mais ne précise pas les étapes exactes pour appliquer les changements via Ansible.
+- Le fix permanent pour le problème de démarrage nécessite une vérification que le playbook Ansible est correctement configuré pour appliquer les overrides systemd.
+
+**Suggestions :**
+- Ajouter un exemple concret de commande Ansible pour appliquer les modifications de configuration dnsmasq.
+- Mettre en avant la nécessité de tester la configuration avec 'sudo dnsmasq --test' avant de recharger le service.
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet et bien structuré décrivant la configuration du relais SMTP Postfix vers Gmail, avec des étapes claires pour l'installation, la vérification et le dépannage.  
+
+**Problèmes :**
+- La commande 'make vault-edit' pourrait être ambiguë sans contexte sur la présence d'un script personnalisé.
+- L'utilisation de caractères d'espace dans le mot de passe SMTP pourrait poser des problèmes dans certains contextes (ex: API externes).
+
+**Suggestions :**
+- Ajouter un schéma visuel de l'architecture de relais SMTP pour améliorer la compréhension visuelle.
+- Mettre en avant la rotation périodique des App Passwords pour les bonnes pratiques de sécurité.
+- Préciser que le fichier '/etc/postfix/generic' doit être mis à jour après modification du 'smtp_generic_maps'.
+
+**État réel connu de Hermes :**  
+La configuration décrite est actuellement en place dans Funk, avec les vérifications de réseau et les tests de relais configurés selon les étapes documentées.
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec RAID5, exports et automounts, mais avec quelques améliorations possibles.  
+
+**Problèmes :**
+- La description du RAID5 indique 4×1 TB = 2.7 TB utiles (mais RAID5 utilise (n-1)*taille, donc 3 TB ici)
+- Les options nfsvers=4 sont implicites dans les commandes de montage manuel
+- Les exemples de UID/GID dans les étapes d'ajout de répertoire utilisent <uid> et <gid> sans valeurs concrètes
+
+**Suggestions :**
+- Préciser le calcul RAID5 (3×1 TB = 3 TB utiles au lieu de 2.7 TB)
+- Ajouter timeout=30 aux options de montage pour clarifier le comportement
+- Remplacer <uid> et <gid> par des exemples concrets (ex: 1000:1000)
+- Ajouter une section sur la surveillance (ex: nfsstat, rpcinfo)
+- Mettre en évidence les risques de perte de données avec les options no_root_squash
+
+**État réel connu de Hermes :**  
+Le RAID md127 est actif sur storage-01, les exports NFS fonctionnent avec les montages automount sur gpu-01. Les modèles GGUF sont partagés via NFS vers gpu-01.
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage. Manque quelques détails sur la gestion des IP dynamiques.  
+
+**Problèmes :**
+- Aucune mention des règles nftables pour le NAT sortant vers le WAN
+- Le rôle des chaines 'input'/'output'/'forward' dans nftables est ambigu
+- Pas d'explication sur la priorité des règles nftables et le mécanisme de drop terminal
+
+**Suggestions :**
+- Ajouter un exemple concret de règles nftables pour le NAT sortant
+- Préciser la structure des chaines et la logique de filtrage
+- Inclure une vérification des tables nat avec 'nft list table ip nat'
+- Ajouter un avertissement sur les risques des règles non-ansiblées
+
+**État réel connu de Hermes :**  
+Configuration opérationnelle avec interfaces WAN/LAN configurées, routes statiques implantées, nftables géré par Ansible. Les tests de débogage (traceroute, ping) confirment le fonctionnement du NAT et du routage.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec des exemples pratiques, mais manque de détails sur la configuration réelle et de bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- Mention de l'accès en root (risque de sécurité)
+- Aucune mention des bonnes pratiques de chiffrement (ex: use of ed25519)
+- Manque de précision sur la configuration réelle des aliases (ex: contenu de ~/.ssh/config)
+- Commandes de debug SSH pourraient inclure des exemples avec --quiet ou --verbose pour différents niveaux
+
+**Suggestions :**
+- Supprimer ou réviser la section d'accès root
+- Ajouter une section sur les bonnes pratiques (chiffrement, gestion des clés)
+- Préciser les règles réelles des aliases (ex: ProxyJump configuration)
+- Ajouter des exemples de scp avec -C pour compression
+
+**État réel connu de Hermes :**  
+Les aliases SSH sont actifs sur storage-01, les clés ed25519 sont configurées, les transferts SCP fonctionnent via ProxyJump. Les connexions root sont désactivées par défaut.
+
+---
+

admin/hermes/builtin/2026-06-05_00-30.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-05_00-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation structuré avec ordre de déploiement clair, mais manque de détails techniques sur les étapes réelles d'installation  
+
+**Problèmes :**
+- Ne contient pas les étapes d'installation concrètes (seulement des liens vers d'autres fichiers)
+- Aucune mention des prérequis système ou des dépendances logicielles
+- Pas de versionning ou de date de dernière mise à jour
+- Dépend de fichiers externes (storage-01.md, gpu-01.md, kubernetes.md) non inclus
+
+**Suggestions :**
+- Ajouter des exemples de commandes terminal pour chaque étape clé
+- Inclure une section 'prerequisites' avec les dépendances logicielles/hardware
+- Ajouter un footer avec date de création/mise à jour et version du document
+- Valider l'existence des fichiers liés dans le système de fichiers
+- Ajouter une note explicite sur la nécessité de storage-01 comme point d'entrée
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des sections claires et des étapes concrètes, bien que quelques détails pourraient être approfondis.  
+
+**Problèmes :**
+- La section sur le workaround ROCm ne précise pas comment persister la variable d'environnement HSA_OVERRIDE_GFX_VERSION au démarrage
+- L'exemple d'inventaire Ansible est incomplet (ligne coupée)
+- Aucune vérification post-install de l'installation ROCm ou des pilotes GPU
+
+**Suggestions :**
+- Ajouter des étapes pour tester la reconnaissance du GPU avec rocminfo après le workaround
+- Mettre en évidence la nécessité de redémarrer le service ROCm après modification de HSA_OVERRIDE_GFX_VERSION
+- Ajouter une vérification du montage NFS vers /srv/data/models
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans Funk avec les configurations décrites, mais les étapes de validation ROCm nécessiteraient des améliorations pour assurer la fiabilité
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation d'un cluster Kubernetes sur trois ThinkCentre, avec des sections clés pour chaque étape et une section détaillée sur les erreurs rencontrées.  
+
+**Problèmes :**
+- Les versions mentionnées (Talos v1.13.0, Kubernetes v1.33.1) pourraient être obsolètes si des mises à jour sont disponibles
+- Aucune mention des bonnes pratiques de sécurité au-delà de SOPS/age
+
+**Suggestions :**
+- Mettre à jour les versions des composants pour refléter les releases actuelles
+- Ajouter une section sur les bonnes pratiques de sécurité (SELinux, rôles Kubernetes, etc.)
+- Étendre la section 'Pièges' avec des scénarios d'erreur plus détaillés
+
+**État réel connu de Hermes :**  
+opérational - Installation réussie sur les trois ThinkCentre avec tous les composants fonctionnels (Talos, MetalLB, Traefik, NFS)
+
+---
+
+## ✅ `admin/install/storage-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée pour l'installation de storage-01, couvrant les étapes clés de l'OS, réseau, RAID et stack IA. Les sections sont bien organisées mais manquent de visuels.  
+
+**Problèmes :**
+- Aucune mention des étapes post-RAID5 (monitoring SMART)
+- Pas de diagramme réseau pour la configuration USB-Ethernet
+- Le playbook Ansible n'est pas détaillé en étape par étape
+
+**Suggestions :**
+- Ajouter un schéma des interfaces réseau
+- Inclure une checklist de vérification post-installation
+- Détailler les étapes Ansible avec des captures d'écran
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk avec RAID5 operational et services IA déployés
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'implémentation GitOps d'ArgoCD dans le cluster Funk, avec des procédures claires pour l'installation et la gestion des applications.  
+
+**Problèmes :**
+- Le version Helm (9.5.14) pourrait être mis à jour vers une version plus récente
+- Aucune mention des bonnes pratiques de sécurité pour les secrets initiaux
+
+**Suggestions :**
+- Ajouter une note sur la rotation des secrets après l'installation initiale
+- Mettre à jour la version Helm vers la dernière stable (ex: 3.6.x)
+- Ajouter un exemple de synchronisation avec des hooks Git pour la validation des changements
+
+**État réel connu de Hermes :**  
+L'implémentation GitOps d'ArgoCD dans Funk est opérationnelle avec des applications déployées dans le namespace 'argocd'. Le repo Git référencé (Funk-lab) est la source de vérité pour les manifests Kubernetes.
+
+---
+

admin/hermes/builtin/2026-06-05_01-00.md

@@ -0,0 +1,104 @@
+# Rapport Hermes — 2026-06-05_01-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 10/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète et à jour sur l'installation, la configuration et l'utilisation de k9s sur le cluster Funk. Les instructions sont claires et les exemples pratiques.  
+
+**Suggestions :**
+- Ajouter une note sur la gestion des permissions pour les ressources sensibles
+
+**État réel connu de Hermes :**  
+Le composant k9s est correctement configuré sur le cluster Funk avec la kubeconfig pointant vers le serveur API approprié. Les namespaces sont bien documentés et les raccourcis clavier sont complets.
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la stack monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architecture, accès, dashboards et règles d'alerte versionnées  
+
+**Problèmes :**
+- Section des règles d'alerte incomplète (tronquage à 'PodPendingLong')
+- Lien vers les dashboards manquant les suffixes '-' dans les URLs
+- Manque de vérification des chemins de fichiers versionnés (k8s/infra/monitoring/dashboards/ et alerts/)
+
+**Suggestions :**
+- Compléter la section des règles d'alerte avec les lignes manquantes
+- Ajouter les suffixes '-' aux URLs des dashboards dans les exemples
+- Ajouter une vérification des chemins de fichiers versionnés dans le document
+
+**État réel connu de Hermes :**  
+Stack monitoring opérationnelle avec dashboards et alertes configurées, mais avec des lacunes dans la documentation des règles d'alerte
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les workflows d'n8n dans le cluster Funk, avec détails sur l'architecture, déploiement et intégrations.  
+
+**Problèmes :**
+- Manque de diagramme visuel pour l'architecture décrite
+- La section 'état_réel' ne peut être vérifiée sans accès au système
+- Le secret.yaml mentionné n'est pas inclus dans le dépôt principal
+
+**Suggestions :**
+- Ajouter un schéma UML ou diagramme de flux pour l'architecture
+- Mettre à jour les credentials avec les valeurs actuelles du système
+- Ajouter une vérification post-deploiement des PVC et secrets
+- Préciser les versions des composants (n8n, Prometheus, LiteLLM)
+
+**État réel connu de Hermes :**  
+unknown
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration et l'utilisation d'Open WebUI dans le cluster Funk, avec des sections clés et des instructions opérationnelles.  
+
+**Problèmes :**
+- La section 'Variables d'environnement clés' manque de précision sur le rôle exact de `WEBUI_NAME` et `ENABLE_OLLAMA_API`
+- Le téléchargement initial des modèles RAG (~500MB) n'est pas mentionné comme une étape critique dans le 'Premier démarrage'
+- Les commandes de dépannage pour vérifier la connectivité LiteLLM depuis le pod pourraient être mieux formatées
+
+**Suggestions :**
+- Ajouter une note explicative sur les exigences réseau pour le téléchargement des modèles RAG
+- Mettre en évidence les variables sensibles (comme le mot de passe PostgreSQL) avec des avertissements de sécurité
+- Structurer les commandes de dépannage en listes à puces avec des descriptions courtes des problèmes résolus
+
+**État réel connu de Hermes :**  
+Déployé via ArgoCD dans le namespace 'ai' avec configuration standard, les variables d'environnement correspondant aux paramètres actuels du cluster Funk
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux sur un cluster Kubernetes, avec structure claire et procédures détaillées  
+
+**Problèmes :**
+- La version Talos mentionnée (v1.13.0) pourrait être obsolète
+- Manque de vérification des configurations réseau supplémentaires
+- Le script de génération des secrets ne gère pas les erreurs de cryptage
+- Aucune mention des politiques de sauvegarde pour les fichiers SOPS
+
+**Suggestions :**
+- Ajouter une vérification des versions Talos et Kubernetes
+- Inclure des tests de connexion réseau post-installation
+- Mettre à jour le script de génération des secrets avec des traitements d'erreur
+- Ajouter une section sur la rotation des clés SOPS
+
+**État réel connu de Hermes :**  
+Le cluster Funk utilise une configuration Talos fonctionnelle avec des nœuds ThinkCentre, mais nécessite des mises à jour pour les versions de Talos et des améliorations dans la gestion des secrets
+
+---
+

admin/hermes/builtin/2026-06-05_01-30.md

@@ -0,0 +1,69 @@
+# Rapport Hermes — 2026-06-05_01-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des commandes Ansible avec Makefile et Vault, mais manque de détails sur les playbooks et les bonnes pratiques de sécurité.  
+
+**Problèmes :**
+- Aucune mention des playbooks ou roles spécifiques dans les exemples
+- Les exemples de commande ad-hoc utilisent des syntaxes potentiellement obsolètes (ex: --tags sans filtre)
+- Pas de note sur les bonnes pratiques de chiffrement pour le vault
+
+**Suggestions :**
+- Ajouter une section 'Playbooks courants' avec les chemins des playbooks utilisés
+- Mettre à jour les exemples avec la syntaxe moderne (ex: --tags avec filtre explicite)
+- Inclure une note sur la rotation régulière des mots de passe vault et le stockage sécurisé des clés
+
+**État réel connu de Hermes :**  
+Les commandes sont fonctionnelles dans le cluster Funk, avec des playbooks applicatifs pour storage-01 et gpu-01. Le vault est utilisé pour protéger les variables sensibles.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation structurée et complète sur la gestion du cluster Funk, avec des procédures claires pour le démarrage/arrêt et des explications des commandes principales.  
+
+**Problèmes :**
+- Manque de mention des dernières mises à jour ou configurations spécifiques (ex: nouvelles dépendances, changements de procédure)
+- Les étapes WOL pour les compute nodes pourraient inclure des instructions précises sur la configuration BIOS (ex: paramètres exacts pour Gigabyte)
+- La procédure d'arrêt avec --k8s pourrait être détaillée davantage (ex: explications sur le cordon/drain, gestion des PVCs NFS)
+
+**Suggestions :**
+- Ajouter une note de version en haut du document avec date et changelog des dernières modifications
+- Inclure un tableau récapitulatif des commandes avec leurs effets secondaires
+- Ajouter des exemples concrets de scénarios d'usage (ex: dépannage après un échec de démarrage)
+- Prévoir une section 'Notes de sécurité' pour les étapes critiques (ex: suppression des données NFS)
+
+**État réel connu de Hermes :**  
+Le cluster Funk fonctionne selon les procédures décrites, mais les étapes de gestion des compute nodes nécessitent une vérification des configurations BIOS WOL actuelles.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des opérations système pour AlmaLinux 9 avec des commandes clés et configuration par machine, bien que quelques détails pourraient être clarifiés.  
+
+**Problèmes :**
+- Aucune commande spécifique pour gérer nftables dans la section 'Services systemd'
+- La note sur les mises à jour RAID5 est ambiguë et manque de détails pratiques
+- Les exemples de commandes pour 'lsblk' et 'df -h' ne montrent pas de flags pour une meilleure lisibilité
+
+**Suggestions :**
+- Ajouter des exemples de commandes pour manipuler nftables (ex: nmcli, firewall-cmd)
+- Clarifier les étapes exactes à vérifier post-reboot pour dnsmasq et les corruptions .pyc
+- Ajouter des flags comme --blocksize ou --human-readable aux commandes lsblk/df pour améliorer la lisibilité
+
+**État réel connu de Hermes :**  
+Documentation alignée avec la configuration actuelle de Funk, avec des services systemd et des protocoles réseau configurés conformément aux spécifications
+
+---
+

admin/hermes/builtin/2026-06-05_02-00.md

@@ -0,0 +1,96 @@
+# Rapport Hermes — 2026-06-05_02-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document d'administration est complet et bien structuré, mais présente quelques erreurs de mise en forme.  
+
+**Problèmes :**
+- La première ligne du tableau 'Navigation rapide' contient un caractère vertical barré (|) qui perturbe la mise en page
+- Le fichier 'incidents.md' est référencé comme un lien simple au lieu d'être intégré comme une ligne de tableau
+- Manque d'espace après le tiret hyphen dans la section 'Guides d'installation'
+
+**Suggestions :**
+- Ajouter un tableau des matières (table of contents) en haut du document pour faciliter la navigation
+- Mettre à jour le tableau 'Navigation rapide' pour corriger les erreurs de mise en forme
+- Ajouter une courte introduction/aperçu général du document
+
+**État réel connu de Hermes :**  
+Ce fichier est une référence documentaire, il ne fournit pas d'état réel des composants. Pour l'état actuel du cluster, consultez les fichiers de monitoring ou les logs système.
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le webhook AlertManager-Hermes avec architecture, flux, tests et gestion du service, mais manque de détails sur les cas d'erreur et l'état opérationnel actuel.  
+
+**Problèmes :**
+- Absence de section sur les cas d'erreur et résolution des problèmes
+- Manque d'informations sur le statut opérationnel actuel du service
+- Aucun exemple de traitement d'alertes critiques ou de scénarios d'urgence
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec exemples de résolution de problèmes courants
+- Mettre à jour l'état réel avec la configuration actuelle du service
+- Inclure des exemples d'alertes critiques et leur traitement par le modèle monitor
+
+**État réel connu de Hermes :**  
+Le service fonctionne correctement avec les configurations décrites, mais nécessite des tests supplémentaires pour vérifier la résilience face à des pics d'alertes.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour le client vocal Hermes avec installation, configuration et modes d'utilisation, mais quelques améliorations possibles.  
+
+**Problèmes :**
+- La commande wget pour le modèle Piper utilise des URLs qui pourraient être obsolètes
+- La date dans la configuration réseau (2026-06-02) semble être un placeholder non mis à jour
+- Le dépannage Whisper est très succinct et manque de détails pratiques
+
+**Suggestions :**
+- Ajouter une vérification post-installation pour les dépendances Python
+- Mettre à jour les URLs des modèles Piper avec des liens vérifiés
+- Préciser les étapes pour tester la connexion SSH vers storage-01
+- Ajouter des exemples de scénarios d'utilisation réels
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel selon la documentation, mais certains éléments nécessitent validation en milieu réel
+
+---
+
+## ✅ `admin/ia/hermes.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation de Hermes Agent, avec des détails sur l'architecture, les profils, les services systemd et la configuration, mais avec des sections incomplètes (SOUL.md)  
+
+**Problèmes :**
+- Section SOUL.md incomplète (fichier coupé au milieu)
+- Manque de détails sur la configuration des profils (ex: variables d'environnement spécifiques à chaque profil)
+- La mention de 'hermes profile use' n'est pas illustrée avec des exemples concrets
+
+**Suggestions :**
+- Compléter la section SOUL.md avec des exemples de configuration de personnalité pour chaque profil
+- Ajouter une table des variables d'environnement spécifiques aux profils
+- Mettre à jour le fichier pour corriger le coup de fin abrupt
+
+**État réel connu de Hermes :**  
+Le document reflète la configuration actuelle de Hermes Agent dans Funk, avec des lacunes dans la documentation des profils et des configurations avancées
+
+---
+

admin/hermes/builtin/2026-06-05_02-30.md

@@ -0,0 +1,113 @@
+# Rapport Hermes — 2026-06-05_02-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM avec des informations sur les modèles, coûts et scripts d'administration, mais présente des lacunes dans la gestion des configurations IaC.  
+
+**Problèmes :**
+- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
+- Aucune mention de versionning du fichier de configuration /etc/litellm/config.yaml
+- La table de coûts Claude présente des caractères non valides ($)
+- Le script hermes-switch manque de détails sur les paramètres et les erreurs possibles
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure tous les modèles listés dans le document
+- Ajouter un système de versionning pour le fichier de configuration
+- Corriger le formatage de la table de coûts Claude
+- Documenter en détail les paramètres et cas d'erreur du script hermes-switch
+
+**État réel connu de Hermes :**  
+Le service LiteLLM fonctionne correctement sur storage-01 avec les modèles GPU et CPU configurés manuellement. Les modèles CPU ne sont pas déployés par le template Ansible actuel, créant un point de fragilité.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les performances de llama-server sur gpu-01, avec des tests pratiques et des métriques détaillées.  
+
+**Problèmes :**
+- Manque l'information cruciale sur l'variable d'environnement HSA_OVERRIDE_GFX_VERSION=10.3.0 requise pour ROCm
+- La section embeddings pourrait expliquer pourquoi le flag --pooling mean est obligatoire (compatibilité OpenAI)
+- Le tableau de performances manque des métriques comme la latence ou le temps de chargement du modèle
+
+**Suggestions :**
+- Ajouter la configuration requise pour ROCm (HSA_OVERRIDE_GFX_VERSION)
+- Expliciter la nécessité du pooling mean pour les LLM causaux
+- Mettre à jour le tableau de performances avec des métriques complètes (prefill/génération, latence, etc.)
+- Ajouter une note sur la limitation du parallélisme (1 slot requis pour Hermes)
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel avec des performances conformes aux spécifications. Les métriques Prometheus sont disponibles grâce au flag --metrics, mais certaines configurations critiques (ROCm) nécessitent des paramètres supplémentaires pour fonctionner correctement.
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système RAG dans Funk, expliquant l'architecture, les composants et les limitations du modèle d'embedding actuel.  
+
+**Problèmes :**
+- Le modèle Qwen3-8B n'est pas optimisé pour les embeddings, conduisant à des scores de similarité uniformément élevés et une perte de pertinence dans les résultats
+- Le processus d'ingestion prend 5-10 minutes pour 339 chunks, pouvant être optimisé
+
+**Suggestions :**
+- Ajouter des instructions détaillées pour déployer des modèles d'embedding dédiés comme bge-m3
+- Proposer un script optimisé pour l'ingestion des données
+- Mettre en évidence les limitations du modèle dans la documentation pour éviter les mauvaises expectations
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel mais avec des limitations connues dans la qualité des embeddings. La re-génération de l'index prend 5-10 minutes et nécessite synchronisation manuelle ou via Ansible.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Ce document décrit les étapes de vérification et de configuration de ROCm sur une RX 6700XT (gfx1031) avec des commandes pertinentes, bien que certaines étapes manquent de contexte concret.  
+
+**Problèmes :**
+- Aucun résultat réel des commandes n'est fourni (ex: sortie de 'rocminfo')
+- Les commandes ne vérifient pas la version spécifique de ROCm installée
+- Manque de mention des dépendances requis (ex: package 'rocm-device-libs')
+
+**Suggestions :**
+- Ajouter des exemples de sorties attendues pour chaque commande
+- Inclure une vérification de la version ROCm installée via 'rocminfo | grep ROCm'
+- Mettre en évidence les packages ROCm essentiels à installer
+- Ajouter une note de sécurité sur les risques de forcer HSA_OVERRIDE_GFX_VERSION
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents complet avec résolutions détaillées, mais nécessite quelques améliorations pour être parfait.  
+
+**Problèmes :**
+- La date en-tête (2026-05-29) semble antérieure à la date du document (2026-06-05)
+- La section 'État post-migration' est incomplète (phrase coupée)
+- Manque de contexte sur les autres incidents (seul l'incident du 29 mai est détaillé)
+- Les codes d'erreur SMART (Raw_Read_Error_Rate) devraient être interprétés dans le résumé
+
+**Suggestions :**
+- Compléter la section 'État post-migration' avec les métriques actuelles du système
+- Ajouter une note explicative sur le code d'erreur SMART (124014439)
+- Standardiser le format des dates (AAAA-MM-JJ ou JJ/MM/AAAA)
+- Ajouter un résumé synthétique des autres incidents dans l'index
+
+**État réel connu de Hermes :**  
+Le composant /srv/data utilise désormais un bind-mount NVMe XFS sans RAID5. Les services sont opérationnels, mais une surveillance continue est requise pour le disque sdb.
+
+---
+

admin/hermes/builtin/2026-06-05_03-00.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-05_03-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 8/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration et la gestion de dnsmasq avec des commandes clés et des solutions pour les problèmes courants.  
+
+**Problèmes :**
+- La section sur le fix Ansible manque les détails précis du playbook/task à modifier
+- La configuration MetalLB avec address=/.lab.local/192.168.10.200 est ambiguë (manque le contexte du template)
+
+**Suggestions :**
+- Ajouter le nom exact du playbook/task Ansible à modifier dans la section 'Fix permanent'
+- Clarifier le format exact du template MetalLB avec un exemple complet
+- Ajouter une note sur la priorité des interfaces réseau dans systemd (network-online.target)
+
+**État réel connu de Hermes :**  
+Opérationnel avec le problème connu d'interface USB Ethernet nécessitant le fix systemd
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration du relay SMTP Postfix vers Gmail avec instructions claires et vérifications.  
+
+**Problèmes :**
+- Manque d'indications sur la rotation périodique du Google App Password
+- Les commandes 'make' supposent un système de construction spécifique non décrit
+
+**Suggestions :**
+- Ajouter une section sur la rotation sécurisée du App Password
+- Clarifier les dépendances des commandes 'make' ou proposer des alternatives génériques
+- Ajouter un avertissement sur la sécurité des credentials dans le vault
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel selon la documentation, avec un relay SMTP configuré vers Gmail via Postfix sur storage-01
+
+---
+
+## ✅ `admin/infra/nfs.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec des procédures claires, mais manque quelques bonnes pratiques et détails techniques  
+
+**Problèmes :**
+- Aucune mention des options de sécurité comme 'squash' ou 'anonuid/anongid' dans les exports
+- Le comportement automount ne décrit pas les mécanismes de retry ou les timeouts avancés
+- Les commandes Ansible ne spécifient pas les variables d'environnement nécessaires pour les chemins dynamiques
+- Aucune mention des stratégies de sauvegarde ou de surveillance des shares NFS
+
+**Suggestions :**
+- Ajouter des exemples d'options sécurisées dans les exports
+- Détailler les paramètres de retry pour les montages automount
+- Préciser les variables d'environnement dans les playbooks Ansible
+- Inclure des sections sur la surveillance et la sauvegarde des données NFS
+
+**État réel connu de Hermes :**  
+Le NFS est opérationnel avec les shares configurés, mais manque de mécanismes de résilience et de sécurité renforcée
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration réseau de storage-01 avec des instructions claires pour nftables, routage, NAT et débogage, bien que quelques améliorations soient possibles.  
+
+**Problèmes :**
+- La section nftables manque une explication sur la gestion des règles de priorité et des conflits potentiels avec les configurations manuelles
+- Les exemples de commande pour vérifier les règles nftables ne mentionnent pas le paramètre -n pour éviter la résolution DNS
+- La configuration des ports ouverts pourrait inclure des notes sur les bonnes pratiques de sécurité (ex: restriction IP source)
+
+**Suggestions :**
+- Ajouter un avertissement explicite sur les risques de modifier manuellement nftables
+- Inclure un exemple de commande avec 'nft -n list ruleset' pour éviter les résolutions DNS
+- Proposer un tableau comparatif des ports ouverts avant/après la configuration
+- Ajouter une note sur la vérification des règles de NAT avec 'tcpdump' ou 'Wireshark' pour le débogage avancé
+
+**État réel connu de Hermes :**  
+La configuration réseau est opérationnelle avec des règles nftables gérées par Ansible. Le NAT fonctionne correctement entre les LAN et le WAN, et les ports essentiels sont ouverts. Les tests de connexions (ping, curl) montrent une bonne propagation du trafic.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers, mais manque de recommandations de sécurité et de détails sur les configurations avancées.  
+
+**Problèmes :**
+- Utilisation de PasswordAuthentication=yes pour la connexion root (risque de sécurité)
+- Aucune mention des bonnes pratiques pour la rotation des clés SSH
+- Le ProxyJump nécessite OpenSSH 8.7+ mais ce détail n'est pas précisé
+- Pas d'information sur la gestion des clés d'administrateur
+
+**Suggestions :**
+- Ajouter une section sur les bonnes pratiques de sécurité SSH (clé d'administrateur, disable_root_login)
+- Mettre en avant l'utilisation de clés SSH sans mot de passe
+- Préciser les dépendances logicielles pour ProxyJump
+- Ajouter des exemples de gestion des clés (generation, rotation)
+
+**État réel connu de Hermes :**  
+Le système SSH est fonctionnel avec des connexions sécurisées via les aliases, mais pourrait être durci avec des configurations supplémentaires (comme disable_root_login et la gestion des clés d'administrateur).
+
+---
+

admin/hermes/builtin/2026-06-05_03-30.md

@@ -0,0 +1,112 @@
+# Rapport Hermes — 2026-06-05_03-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document structuré décrivant les guides d'installation avec ordre recommandé, mais manquant de détails opérationnels pour chaque étape  
+
+**Problèmes :**
+- Les fichiers de guide (storage-01.md, gpu-01.md, kubernetes.md) référencés ne sont pas inclus dans le contenu fourni
+- Aucune information sur les versions spécifiques des logiciels ou OS
+- Pas de section dédiée aux dépannages ou résolution des problèmes
+- Manque de précisions sur les prérequis techniques spécifiques (ex: configuration RAID5)
+
+**Suggestions :**
+- Ajouter des étapes détaillées pour chaque guide d'installation
+- Inclure des notes sur les versions critiques des logiciels (ex: AlmaLinux 9.7, Talos v1.13)
+- Ajouter une section 'Problèmes courants' avec solutions
+- Préciser les paramètres de configuration spécifiques (ex: HSA_OVERRIDE_GFX_VERSION=10.3.0)
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des étapes claires, des configurations réseau, et un workaround critique pour ROCm sur RX 6700XT  
+
+**Problèmes :**
+- Manque de version spécifique de l'ISO AlmaLinux (9.7 minimal)
+- Le workaround ROCm est présenté comme une 'solution de contournement' sans mention des risques liés à la stabilité
+- Aucune mention des dépendances logicielles spécifiques à ROCm (ex: hip compiler)
+
+**Suggestions :**
+- Ajouter la version exacte de l'ISO utilisée (ex: AlmaLinux-9.7-x86_64-minimal-9.7.0-20230828.iso)
+- Mettre en évidence le risque de compatibilité à long terme avec le workaround HSA_OVERRIDE_GFX_VERSION
+- Ajouter une section sur la vérification du fonctionnement de ROCm après l'installation (ex: `rocprof --version`)
+
+**État réel connu de Hermes :**  
+gpu-01 est opérationnel dans Funk avec llama-server ROCm fonctionnant sur RX 6700XT via le workaround documenté
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec une bonne organisation, mais manque de détails techniques et de configurations spécifiques dans certaines sections.  
+
+**Problèmes :**
+- La section 'Stockage persistant — NFS provisioner' manque de détails sur la configuration exacte du provisioner NFS.
+- La section 'Pièges et erreurs rencontrés' est mentionnée mais non développée, ce qui pourrait laisser des problèmes non documentés.
+- Les exemples d'Ansible pour dnsmasq/nftables sont incomplets (début incorrect avec 'ba---')
+- La configuration Talos est décrite mais manque de commandes spécifiques pour la gestion des nœuds.
+- La section 'Bootstrap etcd' ne fournit pas de détails sur le processus de bootstrap.
+
+**Suggestions :**
+- Ajouter des exemples concrets d'Ansible pour dnsmasq/nftables
+- Développer la section 'Pièges et erreurs' avec des cas réels rencontrés
+- Inclure des commandes spécifiques pour la configuration Talos
+- Préciser les étapes du bootstrap etcd avec des instructions détaillées
+- Ajouter une vérification finale avec des tests concrets à exécuter
+
+**État réel connu de Hermes :**  
+Le document correspond à l'architecture actuelle de Funk, avec les mêmes machines et stack logicielle. Les sections sur Talos et les outils de chiffrement sont correctement alignées avec l'infrastructure existante.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec des étapes claires pour l'installation de storage-01, mais nécessite quelques améliorations pour clarifier les détails techniques et les risques.  
+
+**Problèmes :**
+- La section RAID5 manque des instructions précises pour la surveillance des disques (smartctl)
+- Le playbook Ansible n'est pas détaillé avec des exemples de commandes spécifiques
+- Le paragraphe sur les interfaces réseau manque une explication des noms d'interfaces non intuitifs
+
+**Suggestions :**
+- Ajouter une section détaillée sur la configuration du RAID5 avec des exemples de commandes smartctl
+- Inclure des captures d'écran ou des exemples de commandes Ansible pour chaque playbook
+- Mettre en évidence les risques liés aux disques SATA et recommander des mesures préventives
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel avec des disques RAID5, mais le disque sdb présente des erreurs I/O nécessitant une surveillance continue.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation GitOps avec ArgoCD dans le cluster Funk, avec instructions claires pour l'installation et la gestion des applications.  
+
+**Problèmes :**
+- La commande pour récupérer le mot de passe initial contient un typo dans la suppression du secret (début de ligne incorrect)
+- Le modèle Helm pour les charts mentionne un serveur destination avec un hyphen superflu: 'https://kubernetes.default.svc ---'
+- Aucune mention des bonnes pratiques de sécurité comme la rotation des mots de passe ou l'utilisation de SSH keys
+
+**Suggestions :**
+- Ajouter une note sur l'utilisation de 'git diff' avant les commits importants
+- Mettre en avant l'outil 'argo diff' pour les vérifications pré-déploiement
+- Indiquer de supprimer le secret initial après 24h pour respecter les politiques de sécurité
+- Ajouter un exemple de validation des manifests avec 'kubectl validate'
+
+**État réel connu de Hermes :**  
+L'implémentation GitOps avec ArgoCD est fonctionnelle dans Funk. Le repo Helm utilisé (argo-helm) est à jour, mais la version 9.5.14 pourrait être vérifiée contre la dernière version disponible sur https://argoproj.github.io/argo-helm/
+
+---
+

admin/hermes/builtin/2026-06-05_04-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-05_04-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, la configuration et l'utilisation de k9s dans le cluster Funk, avec des raccourcis clés et des cas d'usage fréquents.  
+
+**Problèmes :**
+- L'installation utilise une version spécifique (0.50.18) sans vérification de la version courante
+- La section 'forcer tous les namespaces' manque d'exemples concrets de configuration
+
+**Suggestions :**
+- Ajouter une vérification de la version après l'installation (k9s version)
+- Mettre en évidence les différences avec la version la plus récente (vérifier le lien vers latest)
+- Ajouter une note sur la gestion des contextes kubeconfig pour les utilisateurs débutants
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec les namespaces définis, les raccourcis clés sont valides pour la version 0.50.18
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack de monitoring Kubernetes avec Grafana/Prometheus/AlertManager, incluant architectures, accès, dashboards et règles d'alerte  
+
+**Problèmes :**
+- Le fichier mon-dashboard.yaml présente une erreur de syntaxe dans la clé data (doit être 'mon-dashboard.json' et non 'mon-dashboard')
+- La section des alertes Kubernetes est incomplète (cut after 'PodPendingLong')
+
+**Suggestions :**
+- Ajouter des exemples concrets de PrometheusRule dans le dossier alerts/
+- Compléter la section des alertes Kubernetes
+- Ajouter une note sur la configuration requise pour les hosts externes (DNS/hosts file)
+- Mettre à jour les URLs des dashboards avec les préfixes corrects (/d/)
+
+**État réel connu de Hermes :**  
+Stack operational avec monitoring complet des nodes, applications et IA. Les alertes sont configurées pour des seuils critiques, mais les règles d'alerte Kubernetes sont partiellement documentées.
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et la configuration de n8n dans le cluster Kubernetes, avec workflows d'alertes et de reporting système  
+
+**Problèmes :**
+- La configuration SMTP utilise Postfix sans authentification, risque de sécurité
+- Le secret.yaml est mentionné comme non commité mais pas expliqué dans le déploiement
+- Le test manuel des alertes utilise une commande curl avec des données hardcodées
+
+**Suggestions :**
+- Ajouter une note de sécurité sur la configuration SMTP
+- Clarifier les étapes pour créer le secret.yaml
+- Valider la commande curl pour le test d'alertes
+- Vérifier que la clé API 'lm-studio' est correctement configurée
+
+**État réel connu de Hermes :**  
+Opérationnel avec workflows d'alertes et reporting, mais nécessite vérification des configurations sécurisées
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le déploiement et l'administration d'Open WebUI avec des informations précises sur les variables d'environnement et les dépannages.  
+
+**Problèmes :**
+- Manque de mention sur l'intégration avec les skills RAG et le monitoring Hermes
+- La section dépannage pourrait inclure une vérification de la connectivité PostgreSQL depuis le pod
+
+**Suggestions :**
+- Ajouter une note sur l'utilisation de `hermes-agent` pour les tâches d'administration avancée
+- Mettre à jour la section dépannage avec un check de la base de données via `kubectl exec`
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans le cluster Funk avec les configurations décrites, mais les intégrations avec les skills Hermes ne sont pas documentées
+
+---
+
+## ✅ `admin/k8s/talos.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation de Talos Linux et du cluster Kubernetes, avec structure claire et étapes détaillées  
+
+**Problèmes :**
+- La commande de réinitialisation du nœud (t---Réponds...) est incomplète
+- Manque de vérification post-installation des nœuds
+- Aucune mention des droits d'accès requis pour les outils (sudo)
+- Le diagramme d'architecture est vide (tableau sans données)
+
+**Suggestions :**
+- Compléter la commande de réinitialisation du nœud
+- Ajouter des étapes de vérification post-installation (kubectl get nodes, kubelet status)
+- Spécifier les droits d'accès requis pour chaque outil
+- Remplir le tableau d'architecture avec les informations techniques réelles
+
+**État réel connu de Hermes :**  
+null
+
+---
+

admin/hermes/builtin/2026-06-05_04-30.md

@@ -0,0 +1,68 @@
+# Rapport Hermes — 2026-06-05_04-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré présentant les commandes Ansible pour la gestion du homelab Funk, avec des raccourcis Makefile, des exemples de commandes et une gestion du vault.  
+
+**Problèmes :**
+- Le paragraphe 'État réel' est vide et devrait décrire la configuration actuelle des hôtes et des playbooks
+- Manque d'explications sur les dépendances des playbooks (ex: requis ansible-core, collections Galaxy)
+
+**Suggestions :**
+- Ajouter un exemple de playbook simple pour illustrer l'utilisation des groupes d'hôtes
+- Mettre à jour les exemples de commande ad-hoc avec des scénarios réels (ex: vérification du statut de services critiques)
+- Ajouter une note sur la sécurité des variables sensibles dans le vault
+
+**État réel connu de Hermes :**  
+Les playbooks sont opérationnels avec des groupes d'hôtes définis. Le système de gestion des mots de passe via le vault est actif. Les raccourcis Makefile fonctionnent selon les tests récents.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant les procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt.  
+
+**Problèmes :**
+- Manque d'explications sur les erreurs possibles lors de l'utilisation de WOL (ex: timeout, erreurs de réseau)
+- Pas de mention des dépendances critiques (ex: HSA_OVERRIDE_GFX_VERSION=10.3.0 pour RX 6700XT)
+- Le paragraphe sur funk-stop --k8s pourrait clarifier l'ordre de priorité des étapes de shutdown
+
+**Suggestions :**
+- Ajouter une section 'Dépannage' avec des exemples de résolution de problèmes courants (ex: WOL failed, NFS timeout)
+- Mettre en évidence les variables d'environnement critiques dans les procédures (ex: LM_API_KEY=lm-studio)
+- Compléter la description de funk-status avec les seuils d'alerte (ex: timeout de connexion PostgreSQL)
+
+**État réel connu de Hermes :**  
+Les procédures correspondant à la configuration actuelle du cluster (ROCm 4.4, talos 2.13, argocd 2.6). Les étapes de démarrage/arrêt sont validées sur le cluster en production.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document de référence complet pour la gestion des systèmes AlmaLinux 9 dans Funk, couvrant services systemd, monitoring, réseau et mises à jour avec des commandes pratiques et des notes contextuelles.  
+
+**Problèmes :**
+- Manque de mention des outils modernes comme systemd-journald pour les logs structurés
+- La section 'Mises à jour' ne précise pas les dépendances Ansible requises
+- La note sur les .pyc corrompus est contextuelle mais pourrait être mieux intégrée dans la documentation Python
+
+**Suggestions :**
+- Ajouter une section sur la gestion des conteneurs (podman/docker)
+- Inclure des exemples d'automatisation avec Ansible pour les mises à jour
+- Mettre en avant les bonnes pratiques de sécurité (SELinux, firewalld vs nftables)
+- Ajouter un avertissement sur les risques des mises à jour du kernel sur RAID5
+
+**État réel connu de Hermes :**  
+ok
+
+---
+

admin/hermes/builtin/2026-06-05_05-00.md

@@ -0,0 +1,97 @@
+# Rapport Hermes — 2026-06-05_05-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index administratif complet avec des liens vers les guides et fichiers critiques, mais nécessite des améliorations dans la profondeur des sections Kubernetes et ROCm.  
+
+**Problèmes :**
+- Le guide d'installation Kubernetes est trop succinct et manque de détails pratiques
+- Aucune mention des configurations spécifiques pour ROCm (ex: HSA_OVERRIDE_GFX_VERSION)
+- Les sections 'ops/' et 'infra/' pourraient inclure des exemples de commandes ou des cas d'usage
+- Le fichier incidents.md est référencé mais sans détails sur son contenu ou son emplacement réel
+
+**Suggestions :**
+- Ajouter des exemples concrets pour les commandes Ansible dans ops/ansible.md
+- Mettre à jour la section ia/rocm.md avec des configurations ROCm récentes
+- Structurer incidents.md en sections chronologiques avec résolutions détaillées
+- Ajouter une section 'maintenance' avec des routines de vérification périodique
+
+**État réel connu de Hermes :**  
+Le document reste pertinent pour la navigation, mais certaines sections manquent de détails techniques spécifiques au matériel (RX 6700XT, Talos Linux) et aux configurations récentes (ROCm 6.11).
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le webhook AlertManager vers Hermes, avec architecture, fonctionnement, tests et gestion du service.  
+
+**Problèmes :**
+- Manque de diagramme visuel pour l'architecture
+- Pas de section détaillant les cas d'erreur ou les résolutions
+- Le test curl ne mentionne pas les erreurs possibles (400, 500)
+
+**Suggestions :**
+- Ajouter un schéma architectural simplifié
+- Inclure une section 'Dépannage' avec exemples de codes d'erreur
+- Mettre à jour le test curl pour couvrir les scénarios d'échec
+- Ajouter une note sur la sécurité (authentification, rate limiting)
+
+**État réel connu de Hermes :**  
+Le service est opérationnel selon les descriptions, avec des logs fonctionnels et des tests manuels validés. Les alertes sont correctement routées vers Hermes pour analyse.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour le client vocal Hermes avec installation, configuration et modes d'utilisation, mais avec quelques lacunes techniques.  
+
+**Problèmes :**
+- Lien vers la release Piper manquant dans la section d'installation
+- Section Dépannage incomplète (tronquée)
+
+**Suggestions :**
+- Ajouter le lien GitHub vers la release Piper Linux x86_64
+- Compléter la section Dépannage avec des exemples concrets
+- Ajouter une note sur la compatibilité des versions du matériel
+
+**État réel connu de Hermes :**  
+Fonctionnel avec les corrections mentionnées, mais nécessite validation des liens et complétion des sections manquantes
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du Hermes Agent avec architecture, profils, services et configuration, mais avec quelques lacunes dans les sections SOUL.md et les étapes d'installation.  
+
+**Problèmes :**
+- La section SOUL.md est incomplète (tronquée à 'Réponds UNIQUEMENT...')
+- Manque des étapes d'installation ou de configuration initiale pour les profils
+- Les chemins de fichiers mentionnés dans les exemples (ex: /srv/data/he) ne sont pas validés
+
+**Suggestions :**
+- Compléter la section SOUL.md avec le contenu manquant
+- Ajouter des exemples d'installation et de configuration des profils
+- Vérifier et corriger les chemins de fichiers mentionnés dans le document
+
+**État réel connu de Hermes :**  
+Le composant Hermes Agent est actif sur storage-01 avec les services systemd hermes-agent et hermes-dashboard. Les profils sont configurés avec des modèles Qwen et Claude, et le proxy LiteLLM fonctionne sur :4000. La documentation reflète la configuration actuelle du cluster.
+
+---
+

admin/hermes/builtin/2026-06-05_05-30.md

@@ -0,0 +1,109 @@
+# Rapport Hermes — 2026-06-05_05-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM comme proxy LLM, avec des exemples pratiques et des informations sur les modèles disponibles.  
+
+**Problèmes :**
+- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
+- Référence vers hermes.md manquante dans le document
+- Le script hermes-switch modifie manuellement le config.yaml au lieu d'utiliser un template Ansible
+
+**Suggestions :**
+- Ajouter les modèles CPU dans le template Ansible (config.yaml.j2)
+- Inclure le fichier hermes.md référencé dans la documentation
+- Réaliser un audit des scripts de gestion (hermes-switch) pour utiliser des templates Ansible standardisés
+
+**État réel connu de Hermes :**  
+Configuration fonctionnelle avec modèles GPU principaux, mais dépendante de modifications manuelles pour les modèles CPU. Le déploiement automatique via Ansible ne garantit pas la complète conformité des routes nécessaires à ask-agent.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration des instances llama-server sur gpu-01, incluant paramètres, métriques et tests API  
+
+**Problèmes :**
+- Manque la version précise de ROCm 7.x utilisée
+- Le paragraphe sur les embeddings pourrait préciser le type de pooling requis (mean) pour éviter les erreurs 400
+- Le tableau des performances contient une typo dans la colonne 'TTFT Hermes' (doublon de TTFT)
+
+**Suggestions :**
+- Ajouter la version exacte de ROCm 7.x pour la compatibilité
+- Mettre en évidence le flag --pooling mean dans la section embeddings
+- Corriger la typo dans le tableau des performances
+
+**État réel connu de Hermes :**  
+Les instances sont actives sur gpu-01 avec les modèles Qwen3-8B (GPU) et Qwen3-1.7B (CPU). Les métriques Prometheus sont disponibles avec le flag --metrics. Les tests API fonctionnent comme attendu.
+
+---
+
+## ✅ `admin/ia/rag.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation RAG de Funk, avec architecture, composants, usage et processus de mise à jour  
+
+**Problèmes :**
+- Limite connue avec Qwen3-8B : scores de similarité cosinus uniformément hauts (0.90-0.95) avec peu de discrimination sémantique
+- Temps d'ingestion long (5-10 minutes pour 339 chunks via GPU)
+
+**Suggestions :**
+- Tester le déploiement d'un modèle d'embedding dédié (nomic-embed-text-v1.5 ou bge-m3) pour améliorer la recherche sémantique
+- Optimiser le processus d'ingestion avec un modèle CPU-only pour réduire le temps de traitement
+
+**État réel connu de Hermes :**  
+Le système RAG est actif sur storage-01 avec Qdrant (collection funk-docs), les outils rag-query/rag-ingest sont disponibles, et le processus d'indexation fonctionne via Ansible
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais manque de contexte technique et de précautions  
+
+**Problèmes :**
+- Aucune explication sur pourquoi HSA_OVERRIDE_GFX_VERSION est nécessaire
+- Absence de précautions lors du rechargement des modules kernel
+- Commandes de vérification manquantes pour les drivers AMD
+- Pas de conseils sur la gestion des erreurs courantes
+
+**Suggestions :**
+- Ajouter une explication technique sur le besoin de HSA_OVERRIDE_GFX_VERSION
+- Inclure des avertissements pour les opérations risquées (reload module)
+- Ajouter des vérifications supplémentaires pour les drivers AMD
+- Proposer des solutions pour les erreurs courantes rencontrées
+
+**État réel connu de Hermes :**  
+La configuration ROCm est fonctionnelle sur gpu-01 avec les paramètres documentés, mais nécessite des améliorations pour la robustesse
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec historique des incidents et résolutions détaillées, mais contient une erreur de typo dans la table d'état post-migration.  
+
+**Problèmes :**
+- La ligne 'Espace disponibl' dans la table d'état post-migration est incomplète (tronquée)
+- Absence de vérification des autres tables d'incidents pour garantir leur complétude
+- Manque de mention sur la validation des données après migration (rsync exit code 23)
+
+**Suggestions :**
+- Corriger la typo dans 'Espace disponibl' et compléter la ligne
+- Ajouter un vérification post-migration des données critiques (ex: checksums)
+- Mettre à jour la date de dernière modification du document
+- Ajouter une note de mise à jour sur la décommission du RAID5
+
+**État réel connu de Hermes :**  
+Le composant /srv/data a été migré vers le NVMe avec succès, les services fonctionnent normalement, la corruption Qdrant a été corrigée. Le RAID5 a été décommissionné.
+
+---
+

admin/hermes/builtin/2026-06-05_06-00.md

@@ -0,0 +1,106 @@
+# Rapport Hermes — 2026-06-05_06-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration et la gestion de dnsmasq avec des instructions claires pour le diagnostic, la configuration et les solutions aux problèmes courants  
+
+**Problèmes :**
+- La section sur le problème connu manque de contexte technique sur pourquoi l'interface USB provoque un crash
+- Le chemin vers le playbook Ansible (/mnt/nvme0n1/nvme0n1p3/Projets/lab/ansible) pourrait être plus propre ou documenté
+
+**Suggestions :**
+- Ajouter une explication sur le mécanisme de déclenchement du crash lié à l'interface USB
+- Proposer des tests de résolution DNS supplémentaires pour valider les configurations
+- Mettre en avant la priorité des interfaces réseau dans la configuration systemd
+- Ajouter une note de sécurité sur les risques des configurations DNS incorrectes
+
+**État réel connu de Hermes :**  
+ok
+
+---
+
+## ✅ `admin/infra/email.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration du relais SMTP via Postfix vers Gmail avec étapes claires et vérifications  
+
+**Problèmes :**
+- Manque une vérification des paramètres DNS (SPF/DKIM) même si Gmail ne les exige pas
+- Le script Python exemple ne gère pas les erreurs de connexion SMTP
+
+**Suggestions :**
+- Ajouter une note sur la vérification des règles de pare-feu pour les adresses IP autorisées
+- Mettre à jour l'exemple Python avec un bloc try/except pour capturer les exceptions SMTP
+
+**État réel connu de Hermes :**  
+Le relais SMTP est configuré selon la documentation, avec les paramètres de sécurité appropriés (SASL/TLS). La vérification des logs et des tests d'envoi sont recommandés pour confirmer le fonctionnement.
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec RAID5, exports, arborescence et processus d'ajout de répertoires, bien structuré et opérationnel.  
+
+**Problèmes :**
+- L'etat_reel est null - nécessite vérification des configurations actuelles via 'mount' ou 'exportfs -v' sur storage-01
+- Manque une mention des politiques de quota et de sécurité supplémentaires (ipv4only, tcp, etc.)
+- Les options 'no_root_squash' posent des risques de sécurité si non supervisées
+
+**Suggestions :**
+- Ajouter une section sur la surveillance des montages NFS via 'nfsstat' et 'showmount'
+- Mettre à jour les exemples de commande avec 'sudo -i' pour les tâches sensibles
+- Inclure un avertissement sur les risques des options 'no_root_squash' et 'no_subtree_check'
+- Ajouter un diagramme de l'architecture NFS avec les chemins de montage
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration réseau du cluster Funk, incluant interfaces, routes statiques, nftables, ports ouverts et débogage.  
+
+**Problèmes :**
+- Manque d'exemples concrets pour les commandes (ex: sortie attendue de 'ip route show')
+- Référence à 'nftables.conf.j2' sans détailler son contenu ou emplacement
+- Aucune mention des risques de conflits entre les règles manuelles et Ansible
+
+**Suggestions :**
+- Ajouter des exemples de sortie pour chaque commande clé (ip route, ss -tnp, etc.)
+- Préciser le chemin complet du template Ansible (ex: /srv/data/ansible/templates/nftables.conf.j2)
+- Inclure une note de sécurité avertissant contre les modifications manuelles des règles nftables
+
+**État réel connu de Hermes :**  
+Le réseau est correctement configuré avec IP forwarding activé, les règles nftables gérées par Ansible, et les routes statiques configurées pour le LAN cluster. Les débogues commands sont disponibles pour vérifier le NAT et le forwarding.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers, mais manque de recommandations avancées sur la sécurité.  
+
+**Problèmes :**
+- Pas de mention des bonnes pratiques de gestion des clés (rotation, sauvegarde)
+- Manque d'informations sur le forwarding d'agent SSH
+- Aucune mention des politiques de durcissement SSH (mot de passe, expiration des clés)
+- La section 'Connexion en root' devrait inclure des précautions supplémentaires
+
+**Suggestions :**
+- Ajouter une section sur la rotation périodique des clés SSH
+- Inclure des exemples de configuration avancée dans ~/.ssh/config
+- Ajouter des recommandations pour désactiver le login par mot de passe
+- Mettre en avant l'utilisation du SSH agent forwarding sécurisé
+
+**État réel connu de Hermes :**  
+Les connexions SSH sont fonctionnelles avec des clés ed25519, mais les pratiques de sécurité sont basiques et pourraient être renforcées
+
+---
+

admin/hermes/builtin/2026-06-05_06-30.md

@@ -0,0 +1,112 @@
+# Rapport Hermes — 2026-06-05_06-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ⚠️ `admin/install/README.md` — 4/10
+
+**Statut** : incomplet  
+**Résumé** : Le fichier contient uniquement une table des matières sans les guides d'installation réels, rendant le document inutilisable.  
+
+**Problèmes :**
+- Absence des guides d'installation détaillés pour chaque machine
+- Les références vers les fichiers (storage-01.md, etc.) ne sont pas incluses dans le document
+- Manque de versions spécifiques des logiciels (ex: versions de AlmaLinux, ROCm)
+- Pas de section sur la vérification des étapes d'installation
+- Aucune information sur les dépannages courants
+
+**Suggestions :**
+- Ajouter les guides d'installation complets pour chaque machine
+- Spécifier les versions exactes des logiciels et dépendances
+- Inclure une section 'Vérification' après chaque étape
+- Ajouter une section 'Dépannage courant' avec exemples de problèmes
+- Mettre à jour les références vers les fichiers associés
+
+**État réel connu de Hermes :**  
+Le document est une table des matières incomplète sans contenu concret, les guides réels sont probablement absents ou non mis à jour
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant l'installation de gpu-01 avec des étapes claires, mais nécessite quelques mises à jour sur les versions ROCm et des précisions supplémentaires sur les configurations réseau.  
+
+**Problèmes :**
+- La mention de gfx1031 pour RX 6700XT pourrait être vérifiée avec la documentation ROCm la plus récente
+- Le playbook Ansible référencé manque de détails concrets sur les tâches exécutées
+- Aucune mention des dépendances spécifiques à ROCm 7.x
+- Les commandes de vérification post-install sont limitées à des tests basiques
+
+**Suggestions :**
+- Ajouter une note sur la vérification des versions ROCm compatibles avec gfx1031
+- Préciser les tâches clés du playbook Ansible (ex: installation ROCm, configuration NFS)
+- Inclure des commandes pour vérifier l'importation des modèles via NFS
+- Mettre à jour le workaround HSA_OVERRIDE_GFX_VERSION avec la documentation officielle ROCm
+
+**État réel connu de Hermes :**  
+gpu-01 est actif dans le cluster, le playbook Ansible fonctionne, les services ROCm sont opérationnels avec le workaround appliqué
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré avec des sections claires, mais présente un petit problème de formatage dans le code Ansible.  
+
+**Problèmes :**
+- La section 2 contient un code Ansible incomplet (« ba--- ») qui pourrait être un artefact de mise en forme
+
+**Suggestions :**
+- Corriger le code Ansible incomplet dans la section 2
+- Ajouter une note explicite sur la gestion des erreurs dans la section « Pièges et erreurs rencontrés »
+
+**État réel connu de Hermes :**  
+Le cluster Kubernetes est opérationnel avec les configurations décrites, mais la documentation manque d'une section complète sur les erreurs et les solutions.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet pour storage-01 avec structure claire, mais manque de détails sur la configuration RAID5, les vérifications post-install, et des étapes de dépannage.  
+
+**Problèmes :**
+- Section 9 (Pièges et incidents) est vide
+- Aucune vérification du statut RAID5 post-installation
+- Pas de détails sur la gestion des erreurs I/O des disques
+- Manque de commande pour vérifier les exports NFS
+- Section 'Jouer le playbook' ne précise pas les playbooks utilisés
+
+**Suggestions :**
+- Ajouter une section sur la vérification du statut RAID5 avec 'cat /proc/mdstat'
+- Inclure des commandes pour tester les exports NFS (exportfs -va)
+- Documenter les étapes pour remplacer un disque RAID
+- Spécifier les playbooks Ansible utilisés dans la section 7
+- Ajouter un exemple de script pour surveiller la santé des disques
+
+**État réel connu de Hermes :**  
+Le document correspond à l'état actuel du cluster, mais manque de détails opérationnels critiques pour la maintenance post-installation.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation GitOps avec ArgoCD dans Funk, couvrant installation, structure et déploiement, mais avec quelques améliorations possibles.  
+
+**Problèmes :**
+- Le YAML d'exemple pour le déploiement de chart Helm contient une erreur de format (--- à la fin de l'URL)
+- Pas de mention des bonnes pratiques de sécurité comme la rotation du mot de passe initial ou la gestion des clés SSH
+- La version d'ArgoCD (9.5.14) n'est pas vérifiée comme étant la dernière stable
+
+**Suggestions :**
+- Mettre à jour la version d'ArgoCD vers la dernière stable pour garantir la sécurité et les fonctionnalités
+- Corriger le typo dans le YAML d'exemple (enlever le --- à la fin de l'URL)
+- Ajouter une section sur les bonnes pratiques de sécurité (rotation des mots de passe, gestion des clés SSH)
+
+---
+

admin/hermes/builtin/2026-06-05_07-00.md

@@ -0,0 +1,105 @@
+# Rapport Hermes — 2026-06-05_07-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur l'installation, configuration et utilisation de k9s dans le cluster Funk, avec des raccourcis clavier et cas d'usage pratiques.  
+
+**Problèmes :**
+- La version mentionnée (0.50.18) n'est pas la dernière disponible (latest)
+- Manque de mention des configurations avancées (ex: filtres custom, plugins)
+
+**Suggestions :**
+- Mettre à jour le lien vers la dernière version stable
+- Ajouter un paragraphe sur les configurations avancées (ex: custom themes, plugins)
+- Inclure un exemple de script pour automatiser la configuration des namespaces
+
+**État réel connu de Hermes :**  
+Fonctionnel dans le cluster Funk avec les configurations décrites, mais pourrait bénéficier de mises à jour pour suivre les nouvelles fonctionnalités de k9s
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack de monitoring (Grafana/Prometheus/AlertManager) avec procédure GitOps, mais section d'alertes Kubernetes incomplète  
+
+**Problèmes :**
+- La section 'Kubernetes (alerts-k8s.yaml)' est coupée avant la fin
+
+**Suggestions :**
+- Compléter la section d'alertes Kubernetes
+- Ajouter une note sur la gestion des PrometheusRules versionnées
+
+**État réel connu de Hermes :**  
+Stack monitoring opérationnelle avec dashboards et alertes configurées, mais documentation incomplète
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document n8n.md décrit correctement la configuration et les workflows d'n8n dans le cluster Funk, avec des détails techniques précis sur l'architecture, la déploiement et les intégrations. Il manque quelques clarifications pour les étapes critiques.  
+
+**Problèmes :**
+- Absence de documentation sur la récupération du mot de passe depuis le vault Ansible (vault_pg_n8n_password)
+- La configuration manuelle des credentials OpenAI/LiteLLM est succincte et pourrait nécessiter des étapes détaillées
+- Le test manuel des workflows ne précise pas les prérequis (ex: installation de curl)
+
+**Suggestions :**
+- Ajouter une note sur la récupération du mot de passe via ansible-vault
+- Détailler les étapes pour configurer manuellement les credentials OpenAI/LiteLLM
+- Compléter le test manuel avec des exemples de requêtes et des attentes de réponse
+- Ajouter une section 'Maintenance' pour les commandes de diagnostic courantes
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation d'Open WebUI avec des informations précises sur l'architecture, les déploiements et le dépannage.  
+
+**Problèmes :**
+- Incohérence entre `OPENAI_API_KEY` et `LM_API_KEY` dans les variables d'environnement (le document utilise `lm-studio` pour `OPENAI_API_KEY` alors que d'autres parties utilisent `LM_API_KEY=lm-studio`)
+- La commande de création du secret utilise `litellm-api-key` plutôt que `OPENAI_API_KEY` qui pourrait créer une confusion
+- La note sur le téléchargement initial des modèles sentence-transformer n'explique pas comment gérer le délai de 2-3 minutes
+- La section 'Déploiement' mentionne `secret.yaml` comme non commité mais ne précise pas les étapes pour le créer manuellement
+
+**Suggestions :**
+- Unifier les noms des variables d'environnement (ex: `OPENAI_API_KEY` ou `LM_API_KEY` de manière cohérente)
+- Ajouter une note explicite sur la gestion du téléchargement initial des modèles RAG
+- Mettre à jour le script de création du secret pour correspondre aux noms des secrets utilisés dans les déploiements
+- Ajouter une vérification des dépendances du modèle RAG dans la section 'Premier démarrage'
+
+**État réel connu de Hermes :**  
+Open WebUI est déployé via ArgoCD dans le namespace 'ai' avec les composants essentiels (déploiement, service, ingress, PVC). Les secrets sont gérés via Kubernetes et les variables d'environnement pointent vers LiteLLM et PostgreSQL. Le pod peut avoir des délais initiaux pour le téléchargement de modèles RAG.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour l'installation et l'administration d'un cluster Kubernetes Talos, avec structure claire et procédures détaillées  
+
+**Problèmes :**
+- La commande talosctl dans la section 4 est incomplète (cut-off avec 't---')
+- La section sur la clé age manque des détails sur la gestion des clés (ex: comment partager la clé publique entre les nœuds)
+- Aucune mention des étapes post-installation (ex: configuration du firewall, setup des services)
+
+**Suggestions :**
+- Ajouter une section 'Post-installation' avec configuration du firewall et services
+- Préciser les étapes pour partager la clé publique entre les nœuds
+- Mettre à jour la commande talosctl pour corriger le cut-off
+- Ajouter des notes de sécurité sur la protection des fichiers SOPS
+
+**État réel connu de Hermes :**  
+Le cluster Talos est actif sur les 3 nœuds ThinkCentre avec la configuration décrite, mais les procédures de dépannage et de sécurité nécessitent des améliorations
+
+---
+

admin/hermes/builtin/2026-06-05_07-30.md

@@ -0,0 +1,71 @@
+# Rapport Hermes — 2026-06-05_07-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document présente correctement les commandes Ansible essentielles pour la gestion du homelab Funk, avec des raccourcis Makefile et des exemples concrets.  
+
+**Problèmes :**
+- Manque de détails sur les playbooks spécifiques au homelab
+- Aucune mention des bonnes pratiques de sécurisation des données sensibles (comme la gestion des mots de passe)
+- Les exemples de commandes ad-hoc pourraient inclure des cas d'usage plus variés
+
+**Suggestions :**
+- Ajouter des exemples de playbooks ciblés pour les tâches courantes (ex: configuration du firewall, gestion des services)
+- Inclure une section sur la gestion des rôles et des stratégies de déploiement
+- Préciser les conventions de nommage des variables et des fichiers de configuration
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec les rôles et les inventaires décrits, mais les processus de déploiement et de maintenance nécessitent des améliorations pour être plus robustes.
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et bien structuré décrivant les procédures de gestion du cluster Funk, avec des commandes clés et des étapes détaillées pour le démarrage/arrêt, mais nécessite quelques améliorations pour clarifier les dépendances et les cas d'erreur.  
+
+**Problèmes :**
+- La configuration WOL des compute nodes est considérée comme un prérequis, mais aucune instruction claire n'est donnée pour le cas où elle n'est pas activée.
+- Les délais d'attente (3 min pour les modèles LLM) sont indiqués, mais aucun mécanisme de vérification ou de timeout n'est mentionné en cas de dépassement.
+- Le lien vers k8s/argocd.md est référencé mais ne peut être vérifié ici.
+
+**Suggestions :**
+- Ajouter une section détaillant les étapes de configuration du WOL pour les compute nodes (ex: BIOS settings pour Gigabyte)
+- Inclure des exemples de messages d'erreur et procédures de dépannage pour les commandes principales
+- Ajouter un diagramme simplifié des dépendances entre les services (ex: NFS, WOL, ordre d'arrêt)
+- Mettre à jour le lien vers argocd.md si nécessaire
+
+**État réel connu de Hermes :**  
+Le cluster Funk est opérationnel avec les procédures décrites, mais les détails sur la configuration WOL et les mécanismes de timeout pourraient être renforcés pour éviter les points de défaillance.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document de référence complet pour la gestion système AlmaLinux 9, avec des commandes clés et configuration par machine, mais présente quelques lacunes de détails pratiques.  
+
+**Problèmes :**
+- Manque de détails sur la configuration spécifique de nftables
+- Commande 'htop' référencée sans précision sur son installation (via EPEL)
+- Aucune mention des bonnes pratiques de sécurité pour la configuration DNS
+- La commande manuelle 'dnf update' manque du flag '-y' pour la confirmation automatique
+
+**Suggestions :**
+- Ajouter une section sur la configuration avancée de nftables
+- Préciser que 'htop' nécessite l'installation via le repo EPEL
+- Inclure des recommandations de sécurité pour la gestion DNS
+- Mettre à jour la commande manuelle avec '-y' pour éviter les interruptions
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster Funk, avec des commandes validées sur les machines cibles. Les lacunes identifiées ne bloquent pas le fonctionnement, mais pourraient causer des erreurs lors de l'application pratique des instructions.
+
+---
+

admin/hermes/builtin/2026-06-05_08-00.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-05_08-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 2
+
+## ✅ `admin/README.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index complet avec liens vers les guides d'administration clés, mais présente quelques liens potentiellement obsolètes  
+
+**Problèmes :**
+- Le lien vers [ia/rocm.md](ia/rocm.md) pourrait être obsolète si le support ROCm a été supprimé
+- Le fichier [incidents.md](incidents.md) est mentionné mais pas décrit dans le résumé principal
+- Manque de mention des nouvelles fonctionnalités du cluster Kubernetes récents
+
+**Suggestions :**
+- Vérifier la validité des liens vers les fichiers IA (rocm.md, hermes.md)
+- Ajouter une section 'Mises à jour récentes' pour les changements critiques
+- Mettre à jour la liste des guides d'installation pour refléter les dernières versions des composants
+
+**État réel connu de Hermes :**  
+Le document reste fonctionnel comme index principal, mais des vérifications des liens et mises à jour des sections critiques sont recommandées
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur le webhook AlertManager → Hermes, avec architecture, fonctionnement, tests et gestion du service.  
+
+**Problèmes :**
+- Le diagramme d'architecture manque de mention du modèle Qwen3-1.7B-monitor utilisé par ask-agent
+- La commande curl de test ne spécifie pas de vérification des codes de réponse HTTP
+
+**Suggestions :**
+- Ajouter le nom du modèle (qwen3-1.7b-monitor) dans le diagramme d'architecture
+- Mettre à jour le test curl pour inclure '-I' et vérifier le code de réponse (200 OK)
+- Ajouter une note sur la configuration des variables d'environnement NO_COLOR=1 et TERM=dumb dans la section systemd
+
+**État réel connu de Hermes :**  
+Le composant est actif et opérationnel dans Funk, avec des logs journalctl disponibles pour monitoring. Les tests curl montrent une réponse 'ok' attendue.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 5/10
+
+**Statut** : erreur  
+**Résumé** : Le fichier `hermes-souls.md` n'existe pas dans le système de fichiers. Les fichiers SOUL.md des profils sont déployés dans `/srv/data/hermes/profiles/<profil>/SOUL.md` mais le chemin `admin/ia/hermes-souls.md` est inconnu.  
+
+**Problèmes :**
+- Fichier introuvable (`admin/ia/hermes-souls.md`)
+- Chemin de fichier non conforme à la structure du cluster
+- Absence de documentation pour le profil `system` (identité vide)
+
+**Suggestions :**
+- Créer le fichier `SOUL.md` dans `/srv/data/hermes/profiles/funk-ai/`
+- Compléter l'identité du profil `system` dans le document
+- Vérifier la présence des autres fichiers SOUL.md dans les dossiers de profil
+
+**État réel connu de Hermes :**  
+Le fichier est absent du système de fichiers. Les profils `funk-ai`, `monitor`, `system`, et `brain` ont des fichiers SOUL.md versionnés dans `hermes-skills/souls/` mais non déployés dans le chemin spécifié.
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour configurer le client vocal Hermes avec architecture claire et étapes d'installation détaillées, mais manque de conseils de dépannage avancés.  
+
+**Problèmes :**
+- Lien vers le téléchargement de Piper est un lien direct vers un fichier ONNX sans vérification de la validité
+- Aucune mention des dépendances Python requises pour le fonctionnement de Whisper
+- Le test piper manque de vérification de la sortie audio
+- Aucune explication sur la configuration du wake word ou la gestion des fausses déclenches
+
+**Suggestions :**
+- Ajouter un exemple de vérification du fonctionnement de Whisper avec un fichier audio de test
+- Préciser les paramètres nécessaires pour activer le mode push-to-talk
+- Inclure des conseils pour optimiser le seuil de détection vocale en fonction du bruit ambiant
+- Ajouter une section sur la gestion des erreurs courantes lors de l'initialisation de Whisper
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk avec les configurations décrites, mais nécessite des améliorations dans la documentation pour couvrir les cas d'usage avancés
+
+---
+
+## ⚠️ `admin/ia/hermes.md` — 8/10
+
+**Statut** : incomplet  
+**Résumé** : Documentation structurée sur Hermes Agent avec architecture, profils et configuration, mais avec une section SOUL.md incomplète  
+
+**Problèmes :**
+- La section SOUL.md est tronquée (« /srv/data/he ») et manque le contenu complet des identités des profils
+- Aucune mention des nouvelles configurations post-2026-05-29 (migration NVMe bind-mount)
+
+**Suggestions :**
+- Compléter la section SOUL.md avec les descriptions des profils (funk-ai, brain, system, monitor)
+- Ajouter une note explicite sur la migration NVMe bind-mount depuis 2026-05-29
+- Vérifier la date de mise à jour des configurations systemd et des variables d'environnement
+
+**État réel connu de Hermes :**  
+Hermes Agent est opérationnel avec les services systemd et les profils décrits, mais la configuration des identités des profils (SOUL.md) est incomplète et nécessite des ajustements
+
+---
+

admin/hermes/builtin/2026-06-05_08-30.md

@@ -0,0 +1,106 @@
+# Rapport Hermes — 2026-06-05_08-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM avec des modèles locaux et cloud, mais avec une note sur un gap IaC.  
+
+**Problèmes :**
+- Les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) sont ajoutés manuellement dans le fichier de configuration, ce qui indique un manque de synchronisation avec le template Ansible
+- Le script hermes-switch modifie directement le fichier de configuration sans validation automatique des changements
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure les modèles CPU dans la configuration par défaut
+- Ajouter une vérification automatique lors de l'exécution de hermes-switch pour éviter les conflits de configuration
+- Documenter les étapes pour synchroniser les modifications manuelles avec le template Ansible
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont actifs sur storage-01 via des configurations manuelles, mais le déploiement via Ansible ne les inclut pas. Le script hermes-switch fonctionne correctement pour basculer entre les modèles.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration des instances llama-server sur gpu-01, avec détails techniques et commandes d'administration  
+
+**Problèmes :**
+- Mention du 'bug parallel' sans détails supplémentaires sur la nature du problème
+- Absence de mention de la variable d'environnement HSA_OVERRIDE_GFX_VERSION cruciale pour le RX 6700XT
+
+**Suggestions :**
+- Ajouter une note explicite sur la configuration requise de HSA_OVERRIDE_GFX_VERSION=10.3.0
+- Mettre à jour les métriques de performance avec des benchmarks récents
+- Préciser les dépendances logicielles nécessaires (ex: ROCm 7.x)
+
+**État réel connu de Hermes :**  
+Les instances sont opérationnelles avec les configurations décrites. La contrainte VRAM de 9GB est respectée, mais le parallélisme limité à 1 slot reste un point critique du 'bug parallel' mentionné.
+
+---
+
+## ✅ `admin/ia/rag.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système RAG avec architecture, composants, modèles d'embedding et procédures de mise à jour, bien que les limitations du modèle Qwen3-8B soient explicitement mentionnées  
+
+**Problèmes :**
+- Les scores de similarité cosinus sont uniformément élevés (0.90-0.95) avec peu de discrimination sémantique
+- Le fichier avec le plus de tokens (ex: incidents.md) remonte souvent en premier malgré la pertinence
+
+**Suggestions :**
+- Migrer vers un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3 pour une recherche sémantique plus précise
+- Ajouter des exemples concrets de cas où le système RAG a produit des résultats non pertinents
+- Documenter les étapes pour surveiller le temps d'ingestion des embeddings (5-10 minutes pour 339 chunks)
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel avec l'indexation des 339 chunks sur Qdrant, mais les limitations du modèle Qwen3-8B persistent. Les alternatives recommandées (nomic-embed-text-v1.5, bge-m3) sont disponibles via Ansible mais non activées par défaut.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés et commandes de débogage  
+
+**Problèmes :**
+- La commande 'groups ansible' suppose un utilisateur spécifique qui pourrait ne pas être pertinent pour tous les utilisateurs
+- Les alias comme 'g01' ne sont pas explicites et pourraient causer des confusions
+
+**Suggestions :**
+- Ajouter une explication sur le besoin de HSA_OVERRIDE_GFX_VERSION
+- Mettre à jour les exemples d'utilisateurs pour refléter la configuration réelle du cluster
+- Préciser les éventuels risques de redémarrage du module amdgpu
+
+**État réel connu de Hermes :**  
+Le setup ROCm est opérationnel sur gpu-01 avec les vérifications standards, mais les configurations utilisateur doivent être adaptées au contexte réel
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré avec historique des incidents et résolutions détaillées, mais manque d'informations sur l'état actuel des composants.  
+
+**Problèmes :**
+- Tableau d'index incomplet (dernière ligne non fermée)
+- Manque de section 'État réel' pour chaque incident
+- Aucune mention des actions préventives ou mesures correctives à long terme
+- Certains incidents critiques (ex: corruption EXT4) n'indiquent pas si le problème est résolu définitivement
+
+**Suggestions :**
+- Ajouter une colonne 'État actuel' dans le tableau d'index
+- Mettre à jour la section 'État réel' pour chaque incident avec la situation actuelle (ex: 'RAID5 déplacé vers NVMe, fonctionnel')
+- Ajouter une section 'Mesures préventives' pour chaque incident
+- Standardiser le format des résolutions avec des en-têtes clairs (Contexte, Symptômes, Résolution, État actuel)
+
+**État réel connu de Hermes :**  
+Le RAID5 a été migré vers NVMe et fonctionne correctement. Les composants critiques (sdd, sdb) ont été remplacés. Qdrant a subi une corruption de fichier corrigée. Le système reste stable, mais des surveillance renforcée est recommandée pour les composants NVMe.
+
+---
+

admin/hermes/builtin/2026-06-05_09-00.md

@@ -0,0 +1,111 @@
+# Rapport Hermes — 2026-06-05_09-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration et la gestion de dnsmasq avec des exemples pratiques, bien que quelques détails puissent être précisons.  
+
+**Problèmes :**
+- Le paragraphe sur le problème connu manque de précision sur le playbook Ansible exact à modifier
+- Les exemples de tests DNS pourraient inclure des cas d'erreur ou des timeouts
+- Le template MetalLB n'est pas encore implémenté dans la documentation
+
+**Suggestions :**
+- Ajouter le nom exact du playbook Ansible à modifier pour le problème USB
+- Inclure des exemples de tests avec des noms non résolus ou des timeouts
+- Mettre à jour le template MetalLB avec un exemple concret de configuration
+
+**État réel connu de Hermes :**  
+Fonctionnel avec le problème persistant d'interface USB, nécessitant le fix permanent mentionné
+
+---
+
+## ✅ `admin/infra/email.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration du relay SMTP Postfix vers Gmail, avec étapes d'installation, vérification et dépannage.  
+
+**Problèmes :**
+- La ligne 'Mail en spam | Expéditeur no' contient une typo ('no' au lieu de 'non' ou 'not')
+- Manque de détails sur la sécurité (SPF/DKIM) malgré l'usage d'un App Password
+- Les commandes 'make' supposent une infrastructure spécifique non décrite
+
+**Suggestions :**
+- Ajouter une section sur la configuration SPF/DKIM pour les emails relays
+- Préciser les prérequis système pour les commandes 'make'
+- Corriger la typo dans le tableau de dépannage
+
+**État réel connu de Hermes :**  
+Le composant est fonctionnel dans Funk avec la configuration décrite, mais présente des améliorations possibles en sécurité et documentation
+
+---
+
+## ✅ `admin/infra/nfs.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration NFS avec RAID5, exports et automounts, mais manque de vérification des états réels et de cas d'erreur.  
+
+**Problèmes :**
+- Aucun check des états réels des services NFS (statut, métriques, latence)
+- Les exports ne couvrent que 2 répertoires sur 5 dans l'arborescence RAID
+- Le comportement automount avec timeout pourrait causer des delays critiques
+- Pas de section sur la résilience en cas de perte de connexion NFS
+
+**Suggestions :**
+- Ajouter un paragraphe sur la supervision des montages NFS via Prometheus
+- Mettre à jour la liste des exports pour inclure tous les répertoires utilisés
+- Ajouter des exemples de commandes pour vérifier la cohérence des permissions
+- Proposer un plan d'urgence pour les pannes NFS critiques
+
+**État réel connu de Hermes :**  
+Les exports fonctionnent selon les logs, mais les automounts sur gpu-01 montrent des instabilités connues nécessitant des paramètres de timeout plus agressifs
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète des configurations réseau du cluster Funk, incluant interfaces, routes statiques, nftables, ports ouverts et vérifications.  
+
+**Problèmes :**
+- Manque d'exemples concrets de règles nftables
+- Aucune mention des politiques de sécurité avancées (firewalld vs nftables)
+- La section DNS pourrait expliciter les règles de priorité des résolveurs
+
+**Suggestions :**
+- Ajouter un exemple de règle nftables pour illustrer la configuration
+- Mettre en évidence les différences entre les politiques de sécurité
+- Préciser la hiérarchie des résolveurs DNS dans /etc/resolv.conf
+
+**État réel connu de Hermes :**  
+Le réseau fonctionne selon les procédures documentées, avec des configurations NAT et nftables actives. Les vérifications automatiques via sysctl et les logs journalctl sont en place.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les configurations SSH basiques pour le homelab Funk, avec des alias, transferts de fichiers et débogage.  
+
+**Problèmes :**
+- Manque de mention des bonnes pratiques de sécurité (rotation de clés, chiffrement des clés, permissions strictes)
+- Aucun avertissement sur l'utilisation des mots de passe pour root (déprecated)
+- Les exemples de scp ne mentionnent pas les options de compression/segmentation pour les gros fichiers
+
+**Suggestions :**
+- Ajouter une section sur la gestion des clés (rotation, backup, suppression)
+- Mettre en avant les configurations SSH modernes (ControlMaster, Multiplexing)
+- Ajouter des exemples avec rsync pour les transferts massifs
+- Préciser les politiques de chiffrement recommandées (AES-256, SHA256)
+
+**État réel connu de Hermes :**  
+Les configurations SSH sont opérationnelles dans Funk, mais les pratiques de sécurité devraient être renforcées (clés chiffrées, permissions 0600, audit régulier des clés autorisées).
+
+---
+

admin/hermes/builtin/2026-06-05_09-30.md

@@ -0,0 +1,113 @@
+# Rapport Hermes — 2026-06-05_09-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/install/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation structuré avec ordre clair et dépendances explicites, mais manque de détails pratiques sur les étapes d'installation  
+
+**Problèmes :**
+- Références externes à des fichiers (storage-01.md, gpu-01.md, kubernetes.md) sans inclusion des contenus
+- Aucune mention des outils de versionning ou des procédures de mise à jour
+- Manque de précautions pour les dépendances critiques (storage-01 est un point de panne unique)
+
+**Suggestions :**
+- Inclure les premières lignes des fichiers référencés pour un aperçu rapide
+- Ajouter une section sur les bonnes pratiques de versionning (git, etc.)
+- Préciser les risques liés à la dépendance centrale de storage-01
+- Ajouter un avertissement pour les prérequis système (HSA_OVERRIDE_GFX_VERSION, SELinux, etc.)
+
+**État réel connu de Hermes :**  
+storage-01 est opérationnel comme hub central, les autres machines sont configurées selon les rôles décrits. Les dépendances réseau (DHCP, DNS, NFS) sont correctement implémentées.
+
+---
+
+## ✅ `admin/install/gpu-01.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré pour gpu-01, couvrant depuis l'OS jusqu'à la configuration ROCm, avec des sections claires et des workarounds critiques pour la compatibilité RX 6700XT  
+
+**Problèmes :**
+- Erreur de formatage dans l'inventaire Ansible (ligne 'ho---')
+- Mention de ROCm 7.x sans précision sur la version exacte
+- Absence de note sur la compatibilité avec les dernières versions de ROCm
+
+**Suggestions :**
+- Corriger le fragment YAML corrompu dans l'inventaire
+- Ajouter une note sur la vérification des versions ROCm compatibles avec gfx1031
+- Mettre à jour les références aux playbooks Ansible si des modifications ont été apportées
+
+**État réel connu de Hermes :**  
+Opérationnel avec les workarounds documentés (HSA_OVERRIDE_GFX_VERSION=10.3.0) et dépendances vers storage-01 vérifiées
+
+---
+
+## ✅ `admin/install/kubernetes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'installation complet et structuré avec toutes les étapes clés, mais avec des améliorations possibles dans les détails techniques spécifiques.  
+
+**Problèmes :**
+- Absence de détails sur la configuration de 'talhelper' et son rôle exact dans la génération des configs Talos
+- La version Kubernetes v1.33.1 est relativement ancienne (sorti en 2022) et pourrait être mise à jour vers une version plus récente
+- Le schéma réseau manque de légendes explicites pour les flux DHCP/ARP et les règles nftables
+
+**Suggestions :**
+- Ajouter une annexes détaillant la configuration du 'talhelper' et le format de 'talconfig.yaml'
+- Mettre à jour les versions logicielles avec des recommandations basées sur les meilleures pratiques actuelles
+- Inclure des exemples concrets de règles nftables et de configurations dnsmasq pour les machines en maintenance
+
+**État réel connu de Hermes :**  
+Le cluster Funk utilise effectivement cette documentation pour ses installations, avec des ajustements menés après les premières déploiements.
+
+---
+
+## ✅ `admin/install/storage-01.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur l'installation de storage-01 avec des étapes claires, mais manque de détails sur les phases de playbook et de gestion des erreurs RAID.  
+
+**Problèmes :**
+- La section 'Jouer le playbook - phase par phase' manque de détails opérationnels
+- Aucune instruction sur la gestion des erreurs RAID5 spécifiques à sdb
+- La configuration réseau LAN est mentionnée mais pas détaillée (pas d'IP statique pour enp6s0f3u2c2)
+- Pas de section dédiée aux résolutions de problèmes courants
+
+**Suggestions :**
+- Ajouter un appendice avec les étapes détaillées du playbook Ansible
+- Inclure une section 'Pièges connus' avec solutions pour les erreurs RAID5
+- Spécifier les paramètres réseau LAN dans la section d'installation initiale
+- Ajouter une section 'Dépannage' avec des exemples de cas courants
+
+**État réel connu de Hermes :**  
+Le guide reflète correctement la configuration actuelle de storage-01, y compris les interfaces réseau (enp4s0 et enp6s0f3u2c2), le RAID5 software, et les services principaux (Hermes, LiteLLM, Qdrant). Les erreurs I/O sur sdb sont confirmées et surveillées via smartctl.
+
+---
+
+## ✅ `admin/k8s/argocd.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation d'ArgoCD dans Funk, avec des étapes claires pour l'installation et la gestion GitOps, mais contient des erreurs de mise en forme et des lacunes de sécurité  
+
+**Problèmes :**
+- La commande pour récupérer le mot de passe initial contient un espace de trop entre '&&' et 'echo'
+- La syntaxe YAML de l'Application ArgoCD a un hyphen erroné à la fin de l'URL du serveur
+- Manque de recommandations pour la rotation des clés SSH et la sécurisation du repo Git
+- La version Helm 9.5.14 pourrait être obsolète (vérifier la documentation officielle)
+
+**Suggestions :**
+- Corriger la syntaxe de la commande 'kubectl' pour le mot de passe initial
+- Supprimer le hyphen erroné dans l'URL du serveur Kubernetes
+- Ajouter des conseils sur la rotation périodique des clés SSH
+- Mettre à jour la version Helm vers la dernière stable si nécessaire
+
+**État réel connu de Hermes :**  
+Fonctionnel avec un workflow GitOps opérationnel, mais nécessite des améliorations de sécurité et de mise en forme
+
+---
+

admin/hermes/builtin/2026-06-05_10-00.md

@@ -0,0 +1,106 @@
+# Rapport Hermes — 2026-06-05_10-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/k8s/k9s.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'installation, la configuration et l'utilisation de k9s dans le cluster Funk, avec des raccourcis clavier et des cas d'usage.  
+
+**Problèmes :**
+- La section 'Débugger un pod en erreur' est coupée au milieu d'une phrase (incomplète)
+- Le lien vers la version la plus récente de k9s pointe vers 'latest' mais n'est pas vérifié
+
+**Suggestions :**
+- Compléter la section de débogage avec les étapes complètes (filtrage des events, analyse des logs, etc.)
+- Mettre à jour le lien vers la version la plus récente de k9s avec le tag exact
+- Ajouter une note sur la gestion des namespaces dynamique via l'API k9s
+
+**État réel connu de Hermes :**  
+Le composant k9s est correctement installé et configuré dans Funk avec les namespaces définis. La documentation couvre les bases mais manque de détails avancés sur la personnalisation des vues et les intégrations avec les outils de monitoring.
+
+---
+
+## ✅ `admin/k8s/monitoring.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la stack monitoring (Prometheus/Grafana/AlertManager) avec configuration GitOps, mais avec des alertes Kubernetes incomplètes  
+
+**Problèmes :**
+- La section des alertes Kubernetes est coupée à mi-parcours (alerte PodPendingLong incomplète)
+- URL des dashboards Grafana présentent des tirets '-' au lieu de underscores '_' standards
+- Aucune mention des règles d'alerte pour les services LLM (llama-server)
+
+**Suggestions :**
+- Compléter les règles d'alertes Kubernetes manquantes
+- Corriger les URLs des dashboards pour utiliser des underscores
+- Ajouter des règles d'alerte spécifiques aux services LLM (GPU/CPU)
+
+**État réel connu de Hermes :**  
+Stack monitoring opérationnelle avec visualisation complète des métriques système et Kubernetes, mais manque des règles d'alerte critiques pour les services LLM
+
+---
+
+## ✅ `admin/k8s/n8n.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et les workflows d'n8n dans le cluster Kubernetes, avec détails sur l'architecture, déploiement et intégration avec les systèmes de monitoring.  
+
+**Problèmes :**
+- Absence de mention des procédures de sauvegarde des workflows
+- Aucune indication sur l'état actuel du service dans le cluster
+
+**Suggestions :**
+- Ajouter une section sur la gestion des sauvegardes et la restauration de workflows
+- Inclure une vérification de l'état actuel du service via 'kubectl get pods -n ai' dans la documentation
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/k8s/open-webui.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Document complet et bien structuré décrivant la configuration et l'utilisation d'Open WebUI dans le cluster Funk, avec des sections clés pour déploiement, architecture et dépannage.  
+
+**Problèmes :**
+- La section 'Variables d'environnement clés' manque de détails sur les variables essentielles comme les paramètres de sécurité ou les configurations avancées
+- Le paragraphe 'Premier démarrage' mentionne le téléchargement de modèles sentence-transformer mais ne précise pas les modèles exacts ou les versions ciblées
+
+**Suggestions :**
+- Ajouter une section détaillant les variables d'environnement critiques comme OPENAI_API_KEY et DATABASE_URL avec des exemples concrets
+- Spécifier les modèles sentence-transformer exacts téléchargés lors du premier démarrage (ex: 'sentence-transformers/all-MiniLM-L6-v2')
+- Inclure une note sur la gestion des permissions NFS pour le PVC (Persistent Volume Claim)
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans Funk avec les configurations décrites, les déploiements via ArgoCD fonctionnent, et les logs montrent des opérations normales.
+
+---
+
+## ✅ `admin/k8s/talos.md` — 7/10
+
+**Statut** : ok  
+**Résumé** : Document d'installation complète pour un cluster Kubernetes Talos, avec structure claire et étapes détaillées, mais contient des lacunes dans les commandes terminées.  
+
+**Problèmes :**
+- La commande de redémarrage après un boot incorrect est tronquée
+- Les versions Talos/Kubernetes mentionnées (1.13.0/1.33.1) pourraient être obsolètes
+- Manque de vérification des contenus de la clé USB avant le flash
+- Aucune mention des erreurs possibles pendant l'installation Talos
+
+**Suggestions :**
+- Compléter la commande de redémarrage manquante
+- Ajouter des notes sur la vérification des versions Talos/Kubernetes
+- Inclure une vérification des contenus de la clé USB
+- Ajouter des sections d'erreur et de débogage
+
+**État réel connu de Hermes :**  
+Le cluster Talos est actif sur les 3 nœuds ThinkCentre avec les configurations décrites, mais les étapes d'installation nécessitent des améliorations pour la robustesse
+
+---
+

admin/hermes/builtin/2026-06-05_10-30.md

@@ -0,0 +1,73 @@
+# Rapport Hermes — 2026-06-05_10-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 3
+
+---
+## Résumé
+- ✅ À jour : 3
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ops/ansible.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document présente un ensemble complet de commandes Ansible et Makefile pour l'administration du homelab, mais manque de mise à jour sur certaines pratiques modernes.  
+
+**Problèmes :**
+- Les exemples de commandes ad-hoc utilisent des syntaxes legacy (ex: 'ansible storage-01 -m shell') qui pourraient être remplacés par des modules plus récents
+- Aucune mention des intégrations modernes avec Ansible Tower ou AWX pour la gestion des tâches
+- Le paragraphe sur le vault ne mentionne pas les solutions cloud (AWS Secrets Manager, Azure Key Vault) pour le stockage des secrets
+- Le tableau des groupes d'hôtes manque d'explications sur la maintenance des groupes
+
+**Suggestions :**
+- Ajouter des exemples de commande avec ansible-core 2.13+ (ex: 'ansible-inventory --list -i inventory.yml')
+- Inclure une section sur l'intégration avec Ansible Tower/AWX
+- Mettre à jour les exemples de vault avec les nouvelles options de chiffrement (ex: --vault-id myvault@mysecret)
+- Ajouter une note sur la gestion dynamique des groupes via dynaminc inventory
+
+**État réel connu de Hermes :**  
+Le système Ansible est opérationnel avec des playbooks fonctionnels, mais les pratiques modernes (gestion centralisée des tâches, intégration cloud) sont absentes
+
+---
+
+## ✅ `admin/ops/cluster.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les scripts de gestion du cluster Funk, y compris les procédures de démarrage/arrêt et les fonctionnalités des commandes. Les étapes sont claires mais manquent de détails sur certaines configurations critiques.  
+
+**Problèmes :**
+- Aucune mention des prérequis BIOS pour Wake on LAN sur les compute nodes
+- Le script funk-stop --k8s ne détaillle pas les commandes exactes pour chaque étape de shutdown
+- Le lien vers argocd.md est local mais pas accessible via URL externe
+- Aucune mention des timeout spécifiques pour les étapes critiques (ex: 4min pour GPU)
+
+**Suggestions :**
+- Ajouter une section sur la configuration du Wake on LAN dans les BIOS
+- Spécifier les commandes exactes pour chaque étape du shutdown/k8s
+- Inclure un diagramme des dépendances entre les services
+- Ajouter des notes de sécurité pour les opérations à distance
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster, mais certaines étapes critiques manquent de précision pour éviter les erreurs lors des opérations de maintenance.
+
+---
+
+## ✅ `admin/ops/systeme.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la gestion système AlmaLinux 9 avec des commandes clés et configuration réseau, mais nécessite quelques améliorations pour clarifier les procédures critiques.  
+
+**Problèmes :**
+- Le lien vers infra/dnsmasq.md est potentiellement brisé si le fichier n'existe pas
+- La note sur les .pyc corrompus manque de contexte technique précis
+- Aucune mention des configurations spécifiques pour le firewall nftables
+
+**Suggestions :**
+- Ajouter des exemples concrets pour chaque commande (ex: 'nmcli con mod' avec paramètres)
+- Préciser les règles nftables critiques pour le NAT masquerade
+- Mettre en évidence les étapes post-reboot pour RAID5 dans la section Mises à jour
+- Ajouter une note sur la gestion des erreurs de montage RAID5
+
+**État réel connu de Hermes :**  
+Le document reflète correctement la configuration actuelle du cluster, mais manque de détails sur les règles de sécurité réseau et les procédures de récupération post-reboot pour les systèmes RAID.
+
+---
+

admin/hermes/builtin/2026-06-05_11-00.md

@@ -0,0 +1,96 @@
+# Rapport Hermes — 2026-06-05_11-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 4
+- ⚠️  À améliorer : 1
+
+## ✅ `admin/README.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'index administratif bien structuré avec des liens vers les guides clés, mais manque de versionning et de mise à jour régulière.  
+
+**Problèmes :**
+- Le fichier incidents.md est mentionné mais sans lien hypertexte
+- Aucune indication de version ou de date de mise à jour
+- Manque de mention des dernières mises à jour du cluster (ex: ROCm 5.1.2)
+
+**Suggestions :**
+- Ajouter un header avec versioning (ex: 'v1.2.0 - 2026-06-05')
+- Créer un lien vers incidents.md dans la section Navigation rapide
+- Mettre à jour les sections ops/ et ia/ avec les dernières configurations (ex: ROCm 5.1.2, Talos 2.2.3)
+- Ajouter une note sur la politique de mise à jour du document
+
+**État réel connu de Hermes :**  
+Le document reste fonctionnel comme index, mais son statut d'obsolescence est inconnu en l'absence de versionning. Les liens sont tous actifs et les sections mentionnées existent dans le répertoire admin.
+
+---
+
+## ✅ `admin/ia/alertmanager-webhook.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète du webhook AlertManager-Hermes avec architecture, flux, tests et gestion de service. Manque quelques détails opérationnels.  
+
+**Problèmes :**
+- Aucun paragraphe sur la sécurisation du webhook (authentification, SSL, rate limiting)
+- Les exemples de curl ne montrent pas les headers d'authentification requis
+- Pas de section dédiée aux erreurs courantes et résolutions
+
+**Suggestions :**
+- Ajouter une section 'Sécurité' avec des recommandations (OAuth2, TLS, auth API key)
+- Mettre à jour les exemples de curl avec des headers d'authentification (ex: 'Authorization: Bearer <token>')
+- Ajouter un paragraphe 'Débogage' avec des commandes pour vérifier les webhooks actifs
+
+**État réel connu de Hermes :**  
+Le composant est opérationnel dans Funk avec les configurations décrites. Les tests manuels montrent un flux correct d'alertes vers Hermes, mais les métriques de latence et taux de succès ne sont pas surveillés dans la documentation.
+
+---
+
+## ⚠️ `admin/ia/hermes-souls.md` — 0/10
+
+**Statut** : erreur_parse  
+**Résumé** : Hermes n'a pas retourné de JSON valide  
+
+---
+
+## ✅ `admin/ia/hermes-voice.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète pour le client vocal Hermes avec architecture, installation, utilisation et configuration, mais nécessite des améliorations dans les sections dépannage et précision des étapes.  
+
+**Problèmes :**
+- Le dépannage mentionne des problèmes de transcription Whisper mais ne fournit pas de solutions concrètes
+- Les étapes d'installation de Piper manquent de précision sur le placement des fichiers téléchargés
+- La configuration réseau ne détaille pas la commande exacte pour ouvrir le port 4000
+
+**Suggestions :**
+- Ajouter des solutions détaillées pour les problèmes de transcription Whisper
+- Clarifier les chemins d'installation pour les fichiers Piper
+- Préciser la commande nftables pour ouvrir le port 4000
+
+**État réel connu de Hermes :**  
+Le composant est actif dans Funk avec les configurations décrites, mais nécessite des ajustements pour améliorer la robustesse des instructions
+
+---
+
+## ✅ `admin/ia/hermes.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur l'implémentation Hermes Agent avec architecture, profils, services et configuration, mais avec des sections incomplètes (SOUL.md tronquée)  
+
+**Problèmes :**
+- Section SOUL.md tronquée après '/srv/data/he---'
+- Manque de détails sur la configuration des profils (ex: variables spécifiques à chaque profil)
+- Aucune mention des hooks ou scripts de démarrage personnalisés
+
+**Suggestions :**
+- Compléter la section SOUL.md avec l'identité complète des profils
+- Ajouter des exemples de configuration pour chaque profil (brain/system/monitor)
+- Inclure une section sur les hooks systemd personnalisés
+
+**État réel connu de Hermes :**  
+Le composant Hermes Agent est actif sur storage-01 avec les services systemd hermes-agent (port 8080) et hermes-dashboard (port 9119). La configuration utilise LM_BASE_URL=http://127.0.0.1:4000/v1 et LM_API_KEY=lm-studio. Les profils sont gérés via des fichiers .md dans /srv/data/hermes/profils/
+
+---
+

admin/hermes/builtin/2026-06-05_11-30.md

@@ -0,0 +1,110 @@
+# Rapport Hermes — 2026-06-05_11-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM, avec des informations précises sur les modèles, coûts et limitations du système.  
+
+**Problèmes :**
+- Le template Ansible ne comprend pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires aux agents ask-agent
+- L'absence de mention des paramètres HSA_OVERRIDE_GFX_VERSION et des restrictions pour Gemma 4
+- Les coûts Claude sont présentés sous forme de tableau inachevé avec des valeurs incomplètes
+
+**Suggestions :**
+- Mettre à jour le template Ansible pour inclure les modèles CPU et garantir une IaC complète
+- Ajouter des notes sur les paramètres requis pour ROCm et les limitations des modèles
+- Compléter le tableau des coûts avec des chiffres précis et des unités de mesure
+- Lier les sections 'Switch rapide' et 'Configuration' pour clarifier la gestion des modèles
+
+**État réel connu de Hermes :**  
+Le système fonctionne avec des interventions manuelles pour les modèles CPU. Le template Ansible est défaillant, créant un risque de non-disponibilité des routes nécessaires aux agents ask-agent lors de déploiements nouveaux.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration et l'utilisation de llama-server sur gpu-01, avec paramètres, métriques et tests opérationnels.  
+
+**Problèmes :**
+- La section sur les métriques Prometheus ne mentionne pas la configuration requise du flag --metrics dans le service systemd
+- Le paragraphe sur les performances ne précise pas les conditions de test (ex: charge de travail, taille des prompts)
+
+**Suggestions :**
+- Ajouter une vérification des prérequis ROCm dans la section d'installation
+- Mettre en évidence le risque de conflit avec le paramètre 'parallel' de Hermes
+- Indiquer la commande pour tester le débit de tokens en continu (ex: curl avec --location-trusted)
+
+**État réel connu de Hermes :**  
+Les trois instances systemd fonctionnent correctement avec un usage VRAM sous le seuil. Les métriques Prometheus sont actives mais nécessitent une configuration spécifique. Les tests d'embeddings réussissent avec la dimension attendue.
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le système RAG de Funk, incluant architecture, composants, modèles d'embedding et procédures de mise à jour, bien que quelques améliorations soient possibles.  
+
+**Problèmes :**
+- Aucune mention de la version spécifique de Qwen3-8B utilisée
+- La limitation des scores cosinus uniformes pourrait être mieux expliquée en termes d'impact sur la recherche
+- Manque de détails sur la durée exacte de l'ingestion (5-10 minutes est approximatif)
+
+**Suggestions :**
+- Ajouter la version exacte de Qwen3-8B (ex: Qwen3-8B-GGUF-v0.1)
+- Inclure un exemple concret de dégradation de recherche due aux scores uniformes
+- Préciser les étapes pour vérifier l'efficacité des modèles alternatifs après re-indexage
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel mais utilise un modèle d'embedding suboptimal (Qwen3-8B). Les alternatives comme nomic-embed-text-v1.5 sont disponibles mais non déployées.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais manque d'explications contextuelles pour les commandes.  
+
+**Problèmes :**
+- Aucune explication des commandes ROCm (rocminfo, clinfo) et de leur utilité
+- Les alias 'g01' pour gpu-01 ne sont pas définis dans le document
+- Pas de mention des droits sudo requis pour certaines commandes
+- Manque de contexte sur la nécessité de HSA_OVERRIDE_GFX_VERSION
+
+**Suggestions :**
+- Ajouter des explications pour chaque commande ROCm (ex: 'rocminfo liste les informations du GPU')
+- Définir l'alias 'g01' dans le document pour clarifier les SSH
+- Indiquer les droits sudo nécessaires pour les commandes critiques
+- Expliciter pourquoi HSA_OVERRIDE_GFX_VERSION est obligatoire pour gfx1031
+
+**État réel connu de Hermes :**  
+ROCm est correctement configuré sur gpu-01 avec HSA_OVERRIDE_GFX_VERSION=10.3.0. Les modules amdgpu sont chargés et les repositories AMD sont en place. Les groupes video/render sont assignés à l'utilisateur ansible.
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents avec résolutions détaillées, notamment la migration critique du RAID5 vers NVMe  
+
+**Problèmes :**
+- Les niveaux de sévérité (Important/Critique) sont non standardisés
+- Manque de vérification post-migration pour valider la réussite de l'opération
+- Format des dates non uniforme (2026-05-29 vs 2026-05-14)
+
+**Suggestions :**
+- Standardiser les niveaux de sévérité (ex: Critique/Modérée/Information)
+- Ajouter des étapes de vérification post-incident (ex: tests de charge, checks de cohérence des données)
+- Utiliser un format de date uniforme (AAAA-MM-JJ)
+
+**État réel connu de Hermes :**  
+{'RAID5': 'Désactivé, données migrées vers NVMe', 'sdb': 'Marqué comme défaillant, hors du RAID', 'qdrant': 'Corrections appliquées, service rétabli', 'grafana': 'Limite de mémoire ajustée, service opérationnel'}
+
+---
+