init: seed content from candidature + mvp docs
This commit is contained in:
120
content/docs-mvp/USER_STORIES.md
Normal file
120
content/docs-mvp/USER_STORIES.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# NowYouSea — User Stories (par types de clients)
|
||||
|
||||
Objectif : capturer des **cas d’usage concrets** par type de client, et en déduire :
|
||||
- les **alertes** à produire,
|
||||
- les **données** nécessaires,
|
||||
- les **métriques/KPIs** et critères d’acceptation.
|
||||
|
||||
> Format : *En tant que [persona], je veux [besoin] afin de [valeur].*
|
||||
|
||||
---
|
||||
|
||||
## 1) Capitainerie / Autorité portuaire
|
||||
|
||||
### Alerte “Bateau / trafic atypique”
|
||||
**User story**
|
||||
- En tant que **capitainerie**, je veux être **alerté** quand un bateau génère un niveau sonore anormal (ou une signature inhabituelle) afin de **détecter un incident** (panne, cavitation, vitesse excessive) et réagir.
|
||||
|
||||
**Déclencheurs possibles**
|
||||
- SPL (niveau global) au-dessus d’un seuil
|
||||
- Variation rapide du spectre (ex: bande cavitation)
|
||||
- Détection “événement navire” + classification (option)
|
||||
|
||||
**Critères d’acceptation (MVP)**
|
||||
- Une alerte = timestamp + intensité + courte description + lien vers un extrait audio (10–30 s) + localisation station.
|
||||
- Faux positifs contrôlés : ex < 10% (à définir) sur un site pilote.
|
||||
|
||||
### Alerte “Présence de dauphins / cétacés”
|
||||
**User story**
|
||||
- En tant que **capitainerie**, je veux être alerté d’une **présence probable de dauphins** afin de **adapter la vitesse / trajectoire** et informer les opérateurs.
|
||||
|
||||
**Données / besoins**
|
||||
- Détection bioacoustique (clics/sifflements) : d’abord règle simple + validation humaine, puis modèle.
|
||||
|
||||
**Critères d’acceptation (Phase 2)**
|
||||
- Alerte = probabilité + bande fréquentielle + extrait audio + recommandation (ex: vigilance).
|
||||
|
||||
### Tableau de bord conformité “bruit portuaire”
|
||||
**User story**
|
||||
- En tant que **port**, je veux suivre l’évolution du bruit (jour/nuit, semaine/week-end) afin de **justifier des actions** (régulation trafic, horaires travaux).
|
||||
|
||||
---
|
||||
|
||||
## 2) Gestionnaire d’Aire Marine Protégée (AMP)
|
||||
|
||||
### Alerte “Bruit chantier / événement anthropique”
|
||||
**User story**
|
||||
- En tant que **gestionnaire d’AMP**, je veux être alerté lorsqu’un événement anthropique (travaux, dragage, trafic intense) survient afin de **documenter l’impact** et déclencher une action.
|
||||
|
||||
**Critères d’acceptation**
|
||||
- Export d’un rapport “avant / pendant / après” (métriques SPL + spectre).
|
||||
|
||||
### Suivi “soundscape” (baseline)
|
||||
**User story**
|
||||
- En tant que **gestionnaire AMP**, je veux des séries longues pour **comparer des saisons** et mesurer des tendances.
|
||||
|
||||
---
|
||||
|
||||
## 3) Bureau d’études (EIE/EIA) / projets
|
||||
|
||||
### Monitoring “avant / pendant / après”
|
||||
**User story**
|
||||
- En tant que **bureau d’études**, je veux mesurer le bruit **avant/pendant/après** un chantier pour produire des **livrables EIA** traçables.
|
||||
|
||||
**Critères d’acceptation**
|
||||
- Exports standardisés (CSV/JSON) + métadonnées station + horodatage + méthode.
|
||||
|
||||
---
|
||||
|
||||
## 4) Recherche / Observatoire
|
||||
|
||||
### Accès data / API
|
||||
**User story**
|
||||
- En tant que **chercheur**, je veux accéder aux données via une API afin d’automatiser analyses, comparaisons inter-sites et reproductibilité.
|
||||
|
||||
### Qualité / calibration
|
||||
**User story**
|
||||
- En tant que **chercheur**, je veux des procédures de calibration et des flags de qualité afin de filtrer des périodes non fiables.
|
||||
|
||||
---
|
||||
|
||||
## 5) Industrie / opérateurs (éolien, dragage, maritime)
|
||||
|
||||
### Alerte “seuils contractuels / mitigation”
|
||||
**User story**
|
||||
- En tant qu’**opérateur**, je veux être alerté quand un seuil est dépassé afin d’appliquer une mitigation (pause, réduction puissance, adaptation planning).
|
||||
|
||||
---
|
||||
|
||||
## 6) Associations / ONG / collectivités
|
||||
|
||||
### Indicateurs simples et publics
|
||||
**User story**
|
||||
- En tant qu’**ONG**, je veux des indicateurs simples (tendance, événements) afin de sensibiliser et argumenter.
|
||||
|
||||
---
|
||||
|
||||
# Catalogue d’alertes (proposition)
|
||||
|
||||
## A) Alertes “Anthropique”
|
||||
- Navire détecté
|
||||
- Trafic intense (densité d’événements)
|
||||
- Cavitation probable
|
||||
- Bruit chantier/dragage (signature)
|
||||
|
||||
## B) Alertes “Bio”
|
||||
- Dauphins (sifflements/clics)
|
||||
- Baleines (chants)
|
||||
- Poissons (chorus)
|
||||
|
||||
## C) Alertes “Système”
|
||||
- Batterie faible / panneau absent
|
||||
- 4G down / stockage plein
|
||||
- Hydrophone débranché / bruit parasite
|
||||
|
||||
---
|
||||
|
||||
# Questions ouvertes (à trancher)
|
||||
- Quelle **liste de partenaires** port/AMP cibler en pilote ?
|
||||
- Quel **niveau d’alerte** (info / warning / critical) ?
|
||||
- Quelle stratégie “validation humaine” pour les alertes bio au début ?
|
||||
Reference in New Issue
Block a user