# Rapport Hermes — 2026-06-06_03-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 intégration Ansible, mais présente des lacunes dans la gestion des 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 pour ask-agent
- Le coût des modèles Claude est mal structuré (manque de chiffres concrets)
- Aucune mention des risques liés à la configuration manuelle des modèles CPU

**Suggestions :**
- Mettre à jour le template Ansible pour inclure les modèles CPU avec des commentaires explicites
- Ajouter des exemples concrets de coûts pour les modèles Claude (ex: $X par million de tokens)
- Documenter la procédure pour synchroniser les configurations manuelles avec le template Ansible

**État réel connu de Hermes :**  
Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml. Un déploiement standard via make apply-storage ne configure pas ces routes, créant une dépendance fragile.

---

## ✅ `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 commandes opérationnelles et des spécifications techniques détaillées.  

**Problèmes :**
- Référence à un 'bug parallel' sans explication concrète
- Manque de détails sur la configuration exacte des instances CPU (system/monitor)
- Le flag '--pooling mean' pour les embeddings est obligatoire mais pas expliqué dans le contexte d'erreur

**Suggestions :**
- Ajouter des exemples de requêtes API pour les instances CPU
- Clarifier la configuration spécifique des instances 'system' et 'monitor'
- Mettre à jour la section sur les métriques Prometheus avec des exemples concrets
- Ajouter une note sur la gestion des erreurs de VRAM sur RX 6700XT

**État réel connu de Hermes :**  
Les instances sont opérationnelles avec des performances mesurées. Le bug de parallélisme affecte les requêtes Hermes, nécessitant une vérification continue des métriques Prometheus.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur le système RAG de Funk, couvrant l'architecture, les composants, les modèles d'embedding et les procédures de mise à jour.  

**Problèmes :**
- Le modèle Qwen3-8B utilisé pour les embeddings n'est pas spécialisé pour cette tâche, entraînant des scores de similarité uniformément élevés
- Aucune mention des risques liés à l'utilisation d'un modèle génératif pour l'embedding (hallucinations, biais)

**Suggestions :**
- Ajouter une section sur la validation des résultats de recherche (ex: vérification des sources par l'utilisateur)
- Préciser les seuils de score cosinus considérés comme pertinents
- Proposer un exemple concret de cas où le RAG échoue avec le modèle actuel

**État réel connu de Hermes :**  
Le système RAG est opérationnel mais utilise un modèle d'embedding suboptimal. La reindexation manuelle prend 5-10 minutes pour 339 chunks.

---

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

**Statut** : à_jour  
**Résumé** : Le document ROCm.md est à jour et couvre correctement les vérifications de base, les paramètres critiques et les diagnostics pour la configuration ROCm sur RX 6700XT.  

**Problèmes :**
- La commande 'rocm-smi' n'est pas disponible sur gpu-01, ce qui limite la surveillance des GPU
- Aucune mention des nouvelles fonctionnalités ROCm 5.14+ ou des optimisations pour gfx1031

**Suggestions :**
- Ajouter une note sur la disponibilité limitée de 'rocm-smi' et suggérer des alternatives de monitoring
- Mettre à jour les vérifications avec les commandes ROCm 5.14+
- Inclure une section sur la gestion des mises à jour ROCm via dnf

**État réel connu de Hermes :**  
ROCm est correctement configuré sur gpu-01 avec HSA_OVERRIDE_GFX_VERSION=10.3.0. Aucun problème détecté dans les modules kernel, les groupes utilisateur ou les dépendances AMD. Le noyau 5.14.0-687.5.3.el9_8.x86_64 est compatible.

---

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

**Statut** : à_jour  
**Résumé** : Document d'historique des incidents complet avec résolutions détaillées, mais manque de sections de résumé et de quelques étapes de résolution pour les incidents critiques.  

**Problèmes :**
- L'incident du 2026-05-13 (corruption EXT4) ne contient pas de résolution détaillée
- L'incident du 2026-05-13 (llama-server /metrics 501) manque de résolution
- L'incident du 2026-05-13 (nftables) n'a pas de résolution documentée
- L'incident du 2026-05-11 (corruption XFS) ne précise pas les étapes de récupération

**Suggestions :**
- Ajouter une section de résumé pour chaque incident critique
- Compléter les résolutions manquantes pour les incidents du 2026-05-13
- Inclure un tableau de synthèse des incidents résolus
- Ajouter des tags de catégorisation (ex: 'RAID', 'système de fichiers', 'services')

**État réel connu de Hermes :**  
Le composant /srv/data a été migré vers NVMe avec succès, les incidents critiques ont été résolus, mais des vérifications supplémentaires sont nécessaires pour les systèmes de fichiers XFS.

---