5.6. Module F — Alertes & Scoring

Voici un prompt prêt-à-copier pour Agent3 👇

You are Agent-3.

🎯 OBJECTIF GLOBAL
Build a **production-ready WebApp Module F – “Alertes & Scoring”** for the Synergia Senior platform.

The WebApp is a **front + minimal backend** that will later be wired to Odoo Online + n8n via webhooks.  
For now, you must **fake all external calls** with in-memory or local JSON data.

---

🛠 TECHNO STACK (OBLIGATOIRE)

- Next.js 14 (App Router, `app/` directory)
- TypeScript
- React
- Zod (validation des schémas)
- Tailwind CSS (design sobre, mobile-first)
- Aucune lib UI externe (optionnellement headless UI primitives si vraiment nécessaire)

⚠️ CONSTRAINTES GÉNÉRALES

- **TOUS les textes UI doivent être en FRANÇAIS** (labels, boutons, placeholders, messages d’erreur).
- **Ne pas** appeler Odoo, n8n ou une API externe en runtime.
- Prévoir des **endpoints d’API internes** (`/api/...`) qui utilisent pour l’instant du mock JSON, mais dont les interfaces seront stables pour être branchées plus tard à Odoo/n8n.
- Code structuré, commenté, prêt pour la prod.

---

📌 CONTEXTE FONCTIONNEL – MODULE F “Alertes & Scoring”

Le module doit agréger des signaux de risque pour un senior :

- Données capteurs : tension, poids, sommeil, activité…
- Répétition de mots-clés dans les visites : “chute”, “douleur”, “confusion”…
- Absence de mesures sur une période donnée.
- Auto-déclaration aidant (v2).

Fonctionnalités métier attendues :

1. **Vue priorisée des patients à surveiller**
   - Liste des seniors avec un **score de risque**.
   - Tri par score, gravité, date de dernière alerte.
2. **Score simple Vert / Orange / Rouge**
   - Badges de couleur : Vert (faible), Orange (modéré), Rouge (élevé).
3. **Explication “Pourquoi ce risque ?”**
   - Texte d’explication lisible (provenant de l’IA ou de règles) : “Chute signalée à 2 reprises…”
4. **Boutons rapides par ligne**
   - `Programmer visite`
   - `Générer transmission`
   - `Appeler`

Maquette de référence (à reproduire en esprit) :  
Carte “ALERTES & SCORING” avec :
- Colonne gauche “Sources d’alertes”
- Colonne droite “Fonctionnalités”
- Tableau patients avec colonnes : **Patient | Risque | Explication | Actions**  
  Exemple de lignes :
  - Mme Martin – Élevé – “Chute signalée à 2 reprises”
  - M. Lefevre – Modéré – “Problèmes de sommeil détectés”
  - Mme Dubois – Faible – “Bonne tension et activité”

---

🧩 CONTEXTE ODOO – MODÈLES EXISTANTS (BACKEND FUTUR)

Ces modèles existent déjà (ou existeront) dans Odoo Online et seront les **sources réelles** des données :

- `res.partner` : seniors, aidants, médecins, infirmiers.
- `res.users` : infirmiers / coordonnateurs qui traitent les alertes.
- `ir.attachment` : pièces jointes éventuelles.
- `calendar.event` : RDV créés par “Programmer visite”.
- `project.task` : tâches de suivi générées.
- `x_synergia_senior_dossier` : dossier du senior (porteur du scoring).
- `x_synergia_visit` : visites (source de mots-clés chute/douleur/confusion…).
- `x_synergia_sensor_measure` : mesures capteurs (tension, poids, sommeil…).

---

📊 NOUVEAU MODÈLE CLÉ : `x_synergia_alert` (représenté côté WebApp)

Chaque enregistrement = **une alerte concrète liée à un patient**.

Crée un **type TypeScript + schéma Zod** `Alert` inspiré de cette structure :

- `id: string` (identifiant interne WebApp)
- `dossierId: string` (→ `x_synergia_senior_dossier.id`)
- `seniorId: string` (→ `res.partner.id`)
- `seniorName: string` (affichage “Patient”, ex. “Mme Martin”)
- `alertType: 'sensor' | 'keywords' | 'missing_data' | 'self_report' | 'other'`
- `severity: 'low' | 'medium' | 'high'`  
  - map vers un `riskColor: 'green' | 'orange' | 'red'`
- `title: string` (ex. “Risque de chute”, “Tension élevée répétée”)
- `message: string` (description courte affichée dans la colonne “Explication”)
- `explanationIa?: string` (explication longue “Pourquoi ce risque ?” affichée en détail)
- `sourceModel?: string` (ex. `x_synergia_sensor_measure`, `x_synergia_visit`, `external_api`)
- `sourceMeasureId?: string` (si mesure capteur liée)
- `sourceVisitId?: string` (si visite liée)
- `reporterPartnerName?: string` (aidant/famille si auto-déclaration)
- `status: 'open' | 'in_progress' | 'resolved' | 'dismissed'`
- `createdAt: string` (ISO datetime)
- `resolvedAt?: string`
- `resolvedByUserName?: string`
- `resolvedNote?: string`
- `scoreNumeric?: number` (0–100, pour l’ordre de priorité)
- `xSource?: string` (source technique : `webapp`, `n8n`, `batch`…)
- `taskId?: string`
- `calendarEventId?: string`
- `transmissionId?: string`
- `callLogId?: string`

⚠️ Tu dois :
- Définir un schéma `AlertSchema` en Zod.
- Créer un **mock dataset** d’alertes (3–5 entrées) couvrant les cas Élevé/Modéré/Faible, différents alertType, différents status.

---

🖥️ ÉCRANS À RÉALISER

### 1. Écran principal : `Alertes & Scoring – Liste`

Route : `app/alertes/page.tsx`

Contenu :

1. **Header**
   - Titre : `Alertes & Scoring`
   - Sous-titre : `Vue priorisée des patients à surveiller`
   - Petit encart latéral “Sources d’alertes” :
     - Liste à puces :
       - `données capteurs (tension, poids, sommeil…)`
       - `mots-clés des visites ("chute", "douleur", "confusion")`
       - `absence de données (non-mesure)`
       - `auto-déclaration aidant (v2)`

2. **Barre de filtres**
   - Select `Filtrer par risque` : Tous / Rouge / Orange / Vert
   - Select `Statut` : Tous / Ouvert / En cours / Résolu / Clôturé
   - Champ de recherche `Rechercher un patient…` (par nom)
   - Tri : bouton toggle `Ordre de priorité` (par `scoreNumeric` desc puis `createdAt`).

3. **Tableau des alertes**
   Colonnes :
   - `Patient`
   - `Risque` (badge couleur + texte : “Élevé”, “Modéré”, “Faible”)
   - `Explication` (utiliser `message`)
   - `Dernière mise à jour` (format humain : `il y a 2 jours` ou `21/11/2025 14:32`)
   - `Statut` (badge)
   - `Actions`

   Actions par ligne :
   - Bouton primaire : `Programmer visite`
   - Bouton secondaire : `Générer transmission`
   - Bouton tertiaire : `Appeler`

   👉 Ces boutons **n’appellent pas encore de vraie API**.
   - Ils ouvrent soit un **modal de confirmation**, soit mettent à jour un état local (ex. “Transmission simulée”).
   - Mais prépare l’interface comme si, demain, on devait envoyer :
     - un POST `/api/alerts/:id/schedule-visit`
     - un POST `/api/alerts/:id/create-transmission`
     - un POST `/api/alerts/:id/log-call`

4. **Affichage détaillé de l’alerte**
   - En cliquant sur une ligne ou une icône “Détails”, ouvrir un **panneau latéral (drawer) ou modal** avec :
     - `Patient`
     - `Titre de l’alerte`
     - `Risque` (badge)
     - `Score numérique` (0–100)
     - `Explication IA – "Pourquoi ce risque ?" (explanationIa)`
     - `Historique rapide` :
       - `Type de source`
       - `Date de création`
       - `Dernier statut`
       - Liens symboliques vers “Mesures récentes”, “Visites associées” (mock).

### 2. API interne & data layer

Crée un petit backend Next.js :

- Route GET `/api/alerts`
  - Retourne la liste des alertes mockées (tableau d’objets `Alert` validés par Zod).
- Route PATCH `/api/alerts/[id]/status`
  - Permet de mettre à jour le `status` (en mémoire) – simulation uniquement.
- Route POST `/api/alerts/[id]/schedule-visit`
  - Retourne un objet simulant la création d’un `calendar_event_id`.
- Route POST `/api/alerts/[id]/create-transmission`
  - Retourne un objet simulant la création d’une `transmissionId`.
- Route POST `/api/alerts/[id]/log-call`
  - Retourne un objet simulant la création d’un `callLogId`.

Tous les handlers doivent :
- Valider `id` et le body avec Zod.
- Retourner des erreurs JSON propres (code + message) en cas de problème.

🧱 Préparer la structure pour qu’on puisse **remplacer plus tard** ces handlers par des appels vers Odoo/n8n (JSON-RPC ou webhooks), sans changer le front.

---

🎨 DESIGN & UX

- Style carte (card) avec bords arrondis, fond clair.
- Badges :
  - Rouge : texte “Élevé”
  - Orange : texte “Modéré”
  - Vert : texte “Faible”
- Mobile-first :
  - Sur mobile, le tableau devient des cartes empilées :
    - Nom du patient
    - Badge risque
    - Explication
    - 3 boutons d’action en ligne ou en pile.
- Empty states :
  - Si aucune alerte : afficher un message “Aucune alerte active pour le moment.”

---

✅ LIVRABLES ATTENDUS

1. Structure complète du projet Next.js 14 (App Router) en TypeScript.
2. Types & schémas Zod pour `Alert`.
3. API routes internes `/api/alerts/...` avec mock data + validation.
4. Page principale `Alertes & Scoring` fonctionnelle, avec filtrage, tri, actions simulées.
5. Composants réutilisables :
   - `RiskBadge`
   - `StatusBadge`
   - `AlertRow` / `AlertCard`
   - `AlertDetailDrawer`
6. Code propre, commenté, prêt à être push sur Replit + déployé sur Vercel.

Return the full project structure and all necessary files.