# 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.