# Rapport Hermes — 2026-06-10_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 les modèles LiteLLM, avec des informations sur les coûts et des avertissements sur les lacunes IaC.  

**Problèmes :**
- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires à ask-agent
- Les configurations CPU sont ajoutées manuellement, ce qui crée une dépendance fragile
- Le coût des modèles Claude n'est pas quantifié avec précision

**Suggestions :**
- Mettre à jour le template Ansible pour inclure tous les modèles disponibles
- Ajouter des exemples concrets de coûts pour les modèles Claude
- Documenter la procédure pour synchroniser les configurations manuelles avec le template Ansible

**État réel connu de Hermes :**  
Le service fonctionne correctement avec des configurations mixtes (automatiques + manuelles), mais présente un risque de dégradation lors de déploiements automatisés

---

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

**Statut** : ok  
**Résumé** : Document complet et structuré décrivant la configuration des trois instances llama-server sur gpu-01, avec paramètres techniques, tests et métriques.  

**Problèmes :**
- Manque une section sur la sécurité (firewall, accès API)
- Aucune mention des dépendances logicielles requises (ROCm, dependencies)

**Suggestions :**
- Ajouter une section 'Dépannage' avec les commandes courantes (journalctl, systemctl status)
- Mettre à jour les exemples de curl avec les headers nécessaires (Authorization, Content-Type)
- Ajouter une note sur la compatibilité des modèles avec les différents backends (GPU/CPU)

**État réel connu de Hermes :**  
Les trois instances sont actives et configurées selon les spécifications. Les métriques Prometheus sont disponibles après activation du flag --metrics. Les tests API fonctionnent comme décrit.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur l'implémentation RAG avec architecture, composants, modèles et procédures de mise à jour.  

**Problèmes :**
- Aucun mention de versionnage ou date de mise à jour
- Temps d'indexation mentionné sans contexte d'optimisation

**Suggestions :**
- Ajouter une section sur la versionnage et les dates de mise à jour
- Proposer des optimisations pour la re-indexation massive

**État réel connu de Hermes :**  
Le RAG est opérationnel avec Qwen3-8B et Qdrant, mais les limitations d'embedding sont documentées. L'index est mis à jour via Ansible ou manuellement avec des instructions claires.

---

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

**Statut** : à_jour  
**Résumé** : Le document ROCm.md est à jour et couvre les vérifications essentielles pour la configuration AMD ROCm sur gpu-01, avec des commandes validées et un état sans divergence le 2026-06-05  

**Problèmes :**
- Redondance dans les vérifications de la variable HSA_OVERRIDE
- Manque de détails sur la configuration des dépôts AMD
- Absence de section sur la gestion des erreurs ROCm

**Suggestions :**
- Regrouper les vérifications de la variable d'environnement HSA_OVERRIDE
- Ajouter une section explicative sur la configuration des dépôts AMD
- Inclure des exemples de résolution des erreurs courantes avec ROCm
- Mettre à jour les commandes pour les versions ROCm récentes

**État réel connu de Hermes :**  
ROCm fonctionne correctement sur gpu-01 avec RX 6700XT (gfx1031) grâce à HSA_OVERRIDE_GFX_VERSION=10.3.0. Aucun problème détecté dans les modules kernel, les groupes utilisateur, ou les services ROCm. Les métriques GPU sont accessibles via les sysfs et les outils comme clinfo/rocminfo.

---

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

**Statut** : à_jour  
**Résumé** : Document d'historique des incidents complet et structuré avec résolutions détaillées  

**Problèmes :**
- La ligne de séparation du tableau d'index a une pipe superflue à la fin
- La colonne 'Disponibilité' manque dans la ligne 'Après' du tableau d'état post-migration
- Les commandes utilisent sudo sans précision sur les droits requis
- Aucune mention des mesures préventives pour éviter les récidives

**Suggestions :**
- Corriger la syntaxe du tableau d'index (enlever la pipe finale)
- Ajouter la colonne 'Disponibilité' dans le tableau d'état post-migration
- Remplacer sudo par des commandes adaptées au contexte d'utilisation
- Ajouter une section sur les mesures préventives et les correctifs à appliquer

**État réel connu de Hermes :**  
Le composant /srv/data a été migré vers un LV NVMe XFS avec succès, les services fonctionnent normalement et les données sont intactes

---