# Plan d'implementation des suggestions d'audit

Date: 2026-03-28  
Base: audits multi-profils + clarifications produit validees le 2026-03-28.

## 1. Objectif

Implementer les recommandations de l'audit en priorisant:
1. la correction fonctionnelle (contrats/theme-scoping),
2. la fiabilite (scheduler + SSE + coverage CI deterministe),
3. la maintenabilite (simplification/refactoring progressif sans regression).

## 2. Contraintes de reference (deja decidees)

1. Creation de theme possible sans categories utilisateur.
2. Categories par defaut toujours presentes: `Divers`, `Sans date`.
3. `GET /themes/{id}/schedule` retourne `200` avec `null` si absent.
4. Valeurs par defaut theme: `max_items_per_category=4`, `summary_length=3`.
5. Sources et "preferred" strictement scopes par theme.
6. Import/export sources toujours lies au theme selectionne.
7. Mode d'extraction "LLM vs HTML" deprecie (HTML uniquement).
8. Couverture deterministe CI obligatoire avant release pour flows critiques.

## 3. Sequencement recommande

## Phase 0 - Stabilisation des contrats (3-5 jours)

### Backend
1. Rendre `theme_id` obligatoire pour create/bulk/import-csv/export-csv/preferred.
2. Scoper `PUT /sources/preferred` par `theme_id`.
3. Verifier ownership `theme_id` sur tous les writes sources.
4. Aligner defaults backend sur `4/3`.
5. Aligner validation theme create/update sur les regles finales.

### Frontend
1. Adapter clients API (`sources.ts`, `themes.ts`, `schedules.ts`) aux nouveaux contrats.
2. Garantir l'envoi systematique du `theme_id` dans tous les flux sources.
3. Aligner creation de theme (draft sans categories utilisateur).
4. Gerer explicitement `schedule: null`.

### QA
1. Ajouter tests d'integration contrat API (theme + sources + schedule).
2. Ajouter tests d'isolation multi-theme (import/export/preferred).

### Definition of Done
1. Contrats API aligns avec docs.
2. Tests integration P0 verts en CI.
3. Aucun flux UI principal casse.

## Phase 1 - Fiabilite runtime + gates CI (4-6 jours)

### Backend
1. Ajouter timeout explicite sur execution scheduler (parite avec generation manuelle).
2. Brancher cleanup periodique `job_store.cleanup_expired()` au runtime.
3. Renforcer erreurs non silencieuses (`.ok()` critiques -> logs/warn explicites).

### QA
1. Tests d'integration deterministes scheduler:
   - due selection, anti-double-run, conflit job actif, succes/echec email.
2. Tests d'integration deterministes SSE:
   - sequence `progress -> complete/error`, ownership, resilience.
3. Rendre ces suites bloquantes dans CI.

### Definition of Done
1. Scheduler/SSE couverts par tests deterministes.
2. Gate CI "release" bloque si ces suites echouent.

## Phase 2 - Coherence produit et hygiene code (4-6 jours)

### Frontend
1. Corriger enums/filters `ArticleHistory` pour coller au contrat backend.
2. Supprimer hardcoded strings (i18n centralise).
3. Appliquer regle stricte `Button` (remplacer les `<button>` bruts).
4. Eliminer fetch directs dans pages au profit du client API.

### Backend
1. Supprimer toute trace fonctionnelle du mode extraction LLM deprecie.
2. Verification complete des defaults/documentation runtime.

### QA
1. Tests unitaires/frontend sur i18n + rendering + article-history filters.
2. Tests integration pour cas no-date -> `Sans date`.

### Definition of Done
1. Plus de drift visible entre spec/doc/code pour ces zones.
2. Lint/tests frontend/backend verts.

## Phase 3 - Simplification structurelle (1-2 sprints)

### Backend
1. Decomposer `services/synthesis.rs` par phases:
   - `init`, `phase1`, `phase2`, `finalize`, `trace`.
2. Extraire structures de contexte pour limiter l'etat mutable partage.
3. Ajouter tests de caracterisation avant et apres refactor.

### Frontend
1. Decomposer `ThemeManager`, `Settings`, `Admin/Providers`.
2. Introduire hooks/metiers (`useThemeEditor`, `useGenerationProgress`, etc.).
3. Nettoyer anti-patterns reactivite (side effects en render).

### Definition of Done
1. Complexite par fichier/fonction reduite de facon mesurable.
2. Aucun changement comportemental non voulu (tests non-regression verts).

## Phase 4 - Durcissement final (3-5 jours)

1. Optimiser points chauds (N+1 `article_history`, insertions bulk).
2. Completer observabilite (logs structurés, erreurs pipeline visibles).
3. Mettre a jour templates PR/checklists anti-drift docs/spec/code.
4. Synchroniser `qa_guidelines` avec inventaire reel genere en CI.

## 4. Plan QA global (obligatoire)

1. Gate CI minimal:
   - backend unit
   - backend integration (incluant scheduler + SSE + source-scoping)
   - frontend typecheck
   - frontend unit tests
2. E2E live provider reste non-bloquant (supplementaire).
3. Aucun merge sur branches release si gate deterministe rouge.

## 5. Risques et mitigation

1. Risque: regression sur flux theme/sources.
   - Mitigation: tests d'integration multi-theme en premier.
2. Risque: refactor structurel trop tot.
   - Mitigation: refactor uniquement apres Phases 0-2 stabilisees.
3. Risque: fausse confiance via tests live externes.
   - Mitigation: CI bloquee sur suites deterministes internes.

## 6. Ordre d'execution concret (suggestion)

1. Sprint A: Phase 0 complete.
2. Sprint B: Phase 1 complete.
3. Sprint C: Phase 2 complete.
4. Sprint D-E: Phase 3.
5. Sprint F: Phase 4 + cloture.