system_update/coherence_taches.md

Revue de cohérence — tâches system_update

But : vérifier que les tâches 1.9 à 8 s'enchaînent proprement vers l'objectif final : une webapp serveur system_update exploitable via Docker Compose, avec API extensible et clients futurs.

---

1. Verdict global

Les tâches sont globalement cohérentes.

Il n'y a pas de contradiction bloquante détectée entre :

• moteur templates/scripts ;
• frontend web ;
• backend/API ;
• BDD ;
• Hermes/MCP ;
• optimisation/nettoyage ;
• app locale future.

Les recouvrements repérés sont normaux : certains sujets sont transverses et doivent apparaître dans plusieurs tâches, mais avec responsabilités différentes.

---

2. Flux de développement recommandé

Ordre logique :

1. Validation tâche 1.9  → schéma BDD cible
2. Validation tâche 2    → templates, APT, Docker, contrats JSON
3. Validation tâche 4    → scripts post-install/hardware/profils
4. Validation tâche 5    → backend/API/jobs/storage
5. Validation tâche 3    → frontend web/tuiles/paramètres/layout
6. Validation tâche 6    → Hermes/MCP/skills
7. Validation tâche 7    → optimisation/nettoyage/sécurité/découverte
8. Validation tâche 8    → app Rust/GNOME future

Pourquoi cet ordre :

• la BDD et les contrats JSON structurent tout ;
• les scripts/templates produisent les données ;
• le backend stocke, orchestre et expose ;
• le frontend consomme ces contrats ;
• Hermes/MCP et optimisations s'appuient sur le backend ;
• l'app Rust/GNOME reste une évolution future via API commune.

---

3. Recouvrements acceptés

Métriques simples

• tache4.md : définit le script SSH machine_metrics_simple.
• tache5.md : définit stockage/API/snapshot.
• tache7.md : définit affichage footer, optimisation et usage observabilité.
• tache1.9.md : définit tables machine_metrics_latest.

Ce n'est pas un doublon : chaque tâche couvre une couche différente.

Logs, rapports et messages importants

• tache5.md : stockage backend, API, rétention.
• tache6.md : accès Hermes/MCP.
• tache7.md : nettoyage/rétention.
• tache1.9.md : tables.

Ce recouvrement est nécessaire.

Paramètres frontend

• tache3.md : UX paramètres.
• tache1.9.md : stockage app_settings, user_preferences, machine_ui_state.
• tache5.md : API /api/settings.

Ce découpage est cohérent.

App locale Rust/GNOME

• tache8.md : client natif futur.
• tache5.md : API commune/capabilities.
• tache1.9.md : table api_clients.

Ce n'est pas un chantier immédiat ; il doit rester futur.

---

4. Points corrigés pendant la revue

• tache2.md et validation_tache2.md parlaient encore de 7 questions d'investigation alors que la tâche en contient 8 après ajout des profils machine. Corrigé.

---

5. Objectif final Docker Compose

Objectif final confirmé :

Une webapp serveur system_update déployable via Docker Compose :
- backend API ;
- frontend web servi par le backend ou reverse proxy ;
- SQLite persisté en volume ;
- reports/logs persistés en volume ;
- configuration via variables d'environnement ;
- secrets master key hors image ;
- accès réseau vers machines SSH ;
- option future reverse proxy/TLS.

Cet objectif doit rester un critère transversal dans les validations, surtout tâches 5, 7 et le plan d'implémentation final.

---

6. Risques à surveiller

• Ne pas implémenter toutes les tâches en un seul jalon : trop grand.
• Garder les actions dangereuses validées UI, même si Hermes ou l'app Rust les demande.
• Ne pas exposer les credentials SSH/sudo/API dans logs, UI, Hermes, MCP ou clients locaux.
• Garder SQLite au MVP, mais écrire le schéma pour migrer vers PostgreSQL.
• Garder les scripts critiques versionnés sur disque, pas uniquement en BDD.
• Ne pas confondre terminal live d'exécution, vrai terminal SSH interactif et conversation Hermes.