# Rapport Hermes — 2026-06-06_12-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 présente des problèmes de mise à jour du template Ansible.  

**Problèmes :**
- La colonne 'Coût' dans le tableau des modèles contient une erreur de format (« ~-bash.24 »)
- La ligne « Utilisation courante » est ambiguë et pourrait être clarifiée
- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor), nécessitant une configuration manuelle

**Suggestions :**
- Corriger le format de la colonne « Coût » pour les sessions de débogage
- Clarifier la recommandation pour l'utilisation courante (ex: « Privilégier Qwen3-8B pour les tâches quotidiennes »)
- Mettre à jour le template Ansible pour inclure les modèles CPU et éviter les interventions manuelles

**État réel connu de Hermes :**  
Le service LiteLLM fonctionne correctement avec les modèles décrits, mais présente un risque de perte de configuration lors de la re-provisionnement du système

---

## ✅ `admin/ia/llama_server.md` — 9/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 :**
- La section des métriques Prometheus mentionne le besoin du flag --metrics mais ne vérifie pas si ce paramètre est actif dans les fichiers de service systemd
- Le paragraphe sur les performances ne fournit pas de benchmarks concrets (temps réel, tests de charge) pour valider les chiffres affichés

**Suggestions :**
- Ajouter une vérification pratique du flag --metrics dans la documentation (ex: 'curl http://192.168.10.20:1234/metrics' si le service est correctement configuré)
- Inclure des exemples de tests de charge avec k6 ou wrk pour les métriques de performance
- Mettre en évidence la dépendance HSA_OVERRIDE_GFX_VERSION=10.3.0 dans la configuration des services

**État réel connu de Hermes :**  
Les trois instances systemd sont configurées correctement avec les modèles Qwen3-8B/Q4_K_M sur GPU et Qwen3-1.7B/Q4_K_M sur CPU. Les métriques Prometheus nécessitent validation pratique, les performances théoriques correspondent aux spécifications matérielles, et les embeddings sont activés avec le pooling mean requis.

---

## ✅ `admin/ia/rag.md` — 8/10

**Statut** : à_jour  
**Résumé** : Documentation complète sur le système RAG de Funk, incluant architecture, composants, limitations et procédures de mise à jour.  

**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 (0.90-0.95) indiquant une perte de discrimination sémantique
- Aucune mention des risques de surcharge du GPU lors de l'ingestion des embeddings

**Suggestions :**
- Déployer un modèle d'embedding dédié comme bge-m3 pour améliorer la pertinence des résultats
- Ajouter une section sur le monitoring des ressources GPU pendant l'ingestion
- Mettre en avant les avantages du déploiement de nomic-embed-text-v1.5 pour les requêtes en français

**État réel connu de Hermes :**  
Le système RAG est opérationnel mais subit des limitations liées au choix du modèle d'embedding. L'index est mis à jour via Ansible et manual avec des délais de 5-10 minutes pour 339 chunks.

---

## ✅ `admin/ia/rocm.md` — 9/10

**Statut** : à_jour  
**Résumé** : Le document ROCm est à jour et couvre les vérifications essentielles pour la configuration AMD RX 6700XT, avec des commandes clés et des notes sur la surcharge HSA_OVERRIDE.  

**Problèmes :**
- La commande 'rocm-smi' n'est pas disponible sur gpu-01, ce qui limite la surveillance du GPU
- Aucune vérification du pilote ROCm spécifique (rocm-driver) n'est mentionnée

**Suggestions :**
- Ajouter une section sur l'installation du pilote ROCm spécifique (rocm-driver)
- Mettre en évidence les risques liés à la surcharge HSA_OVERRIDE_GFX_VERSION
- Ajouter des exemples de sortie attendue pour les commandes clés

**État réel connu de Hermes :**  
ROCm est correctement configuré avec HSA_OVERRIDE_GFX_VERSION=10.3.0, modules amdgpu chargés, utilisateur dans les groupes video/render, et aucun crash détecté. Le manque de 'rocm-smi' reste un point à surveiller.

---

## ✅ `admin/incidents.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document bien structuré avec historique des incidents et résolutions détaillées, mais présente quelques problèmes de mise en forme.  

**Problèmes :**
- Alignement des colonnes dans le tableau d'incidents non parfait
- Manque de séparation entre les sections (index, incident détaillé, état post-migration)
- Utilisation de backticks pour les commandes bash sans explication contextuelle
- Absence de résumé global des incidents

**Suggestions :**
- Ajouter des règles de formatage markdown pour les tableaux (|---| vs |---|---|---|)
- Structurer avec des sous-titres pour chaque incident (## 2026-05-27 etc.)
- Ajouter des explications pour les commandes critiques (ex: pourquoi `mount --bind` ?)
- Inclure un résumé synthétique des incidents à la fin

**État réel connu de Hermes :**  
{'RAID5': 'dégradé [4/3] [UUU_], déprécié après migration', 'sdb': 'marqué comme défaillant, interface SATA problématique', '/srv/data': 'NVMe XFS bind-mount /home/data (opérational)', 'Qdrant': 'correction effectuée pour version.info corrompu', 'Grafana': 'limites mémoire ajustées'}

---