docs: roadmap tâches 1.9-8 (briefs, gates de validation, designs tâche 2) + plans d'implémentation

Cartographie complète (liste_taches/coherence_taches), briefs tacheN + gates
validation_tacheN, design tâche 2 (docs/design/tache2/), specs/plans jalon 1-2
et tâche 1.9/2 (Phase 1, Phase 2, SJ-0→3). Validations consignées (1.9 ✅, 2-8 🟡).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

coherence_taches.md

@@ -0,0 +1,122 @@
+# 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 :
+
+```text
+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é :
+
+```text
+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.