Canevas 7C — Spécification détaillée serveur application supervision » History » Revision 4
Revision 3 (Redmine Admin, 06/19/2026 04:54 AM) → Revision 4/5 (Redmine Admin, 06/19/2026 04:54 AM)
# Canevas 7C — Spécification détaillée serveur application supervision
# Canevas 7C — Spécification détaillée serveur / application / supervision
## 1. Objet du document
### 1.1 Finalité de la spécification détaillée serveur / application
Cette partie précise l’objectif du document.
La spécification détaillée serveur / application décrit les exigences applicables à la partie applicative centrale du système : serveur applicatif, API, base de données, interface opérateur, interface administrateur, gestion des équipements, réception des données, gestion des alarmes, historiques, utilisateurs, droits, supervision applicative, reporting, exports, sauvegarde applicative et interfaces avec les systèmes tiers.
Elle constitue la déclinaison applicative de la spécification globale, de l’architecture système, du dossier infrastructure, du dossier des modes de fonctionnement et des spécifications d’interfaces.
Elle doit rester une spécification : elle décrit **ce que la partie serveur doit faire**, sans entrer encore dans le détail de la conception interne du logiciel, des classes, des frameworks, de la structure exacte du code ou du modèle physique détaillé de base de données.
**Exemple :**
> Le présent document a pour objectif de spécifier les exigences détaillées applicables au serveur applicatif, à l’application web, aux API, à la base de données, aux fonctions de supervision, d’administration, d’historisation, de gestion des alarmes, de gestion des utilisateurs et d’interfaçage avec les équipements embarqués et systèmes externes.
### 1.2 Positionnement dans le cycle en V
Cette partie situe la spécification détaillée serveur / application dans le cycle en V.
Elle est produite après la spécification globale, l’architecture système, le dossier infrastructure et la spécification des interfaces principales. Elle sert d’entrée à la conception détaillée serveur, à la conception base de données, à la conception API, au développement backend/frontend, aux tests unitaires applicatifs, aux tests d’intégration serveur/équipement, aux tests d’IHM et aux tests système.
```text
Spécification globale
↓
Architecture système / conception globale
↓
Dossier infrastructure
↓
Spécification détaillée serveur / application / supervision
↓
Conception détaillée serveur / API / base de données / IHM
↓
Développement backend / frontend / scripts / configuration
↑
Tests unitaires applicatifs
↑
Tests d’intégration serveur / DB / IHM
↑
Tests d’intégration équipement / serveur
↑
Tests système
↑
Validation client
```
### 1.3 Différence avec le dossier infrastructure
Cette partie précise la frontière entre le dossier infrastructure et la spécification applicative.
Le dossier infrastructure décrit **où et comment l’application est hébergée** : serveurs, réseau, OS, sauvegarde, supervision technique, accès, sécurité infrastructure.
La spécification serveur / application décrit **ce que l’application doit faire** : recevoir des données, les traiter, les stocker, afficher les états, gérer les alarmes, gérer les utilisateurs, fournir des API, produire des rapports, etc.
**Exemple :**
```text
Dossier infrastructure :
Le serveur applicatif est installé sur SRV-APP-PROD-01 et communique avec SRV-DB-PROD-01 via le VLAN applicatif.
Spécification serveur / application :
Le serveur applicatif doit recevoir les mesures transmises par les équipements, vérifier leur cohérence, les enregistrer en base de données et les rendre consultables via l’interface opérateur.
```
### 1.4 Différence avec la conception détaillée serveur
Cette partie précise la frontière entre spécification et conception.
La spécification décrit **les comportements attendus**.
La conception détaillée expliquera **comment ces comportements sont réalisés techniquement**.
**Exemple :**
```text
Spécification détaillée serveur :
Le serveur doit permettre la consultation de l’historique des alarmes filtré par équipement, date, criticité et statut.
Conception détaillée serveur :
L’historique des alarmes est exposé via l’endpoint GET /api/alarms/history. Les filtres sont transmis en paramètres de requête. Les résultats sont paginés et triés par horodatage décroissant. La table alarms possède les index equipment_id, severity, status et created_at.
```
### 1.5 Responsabilités de rédaction et d’approbation
Cette partie précise qui rédige, relit et valide le document.
La spécification détaillée serveur / application est généralement rédigée par le responsable backend, l’architecte applicatif ou le responsable logiciel serveur, avec contribution de l’ingénieur système, du responsable infrastructure, du responsable IHM, du responsable base de données, du responsable cybersécurité, du responsable validation, de l’exploitation et des futurs utilisateurs.
**Exemple :**
```text
Rédaction : responsable applicatif / architecte logiciel serveur / responsable backend
Contribution : ingénieur système, infrastructure, base de données, IHM, cybersécurité, validation, exploitation
Relecture : chef de projet technique, responsable qualité, responsable tests
Approbation : responsable technique fournisseur et client si le document est contractuel
```
---
## 2. Références et documents applicables
### 2.1 Documents d’entrée
Cette partie liste les documents utilisés pour rédiger la spécification serveur / application.
Ces documents doivent être identifiés, versionnés et approuvés afin que l’application soit spécifiée à partir d’une base stable.
**Exemples :**
```text
- Cahier des charges / expression du besoin
- Dossier de validation client / cahier de recette
- Spécification globale / spécification système
- Architecture système / conception globale
- Dossier des modes de fonctionnement
- Dossier infrastructure informatique / réseau / sauvegarde
- Spécification détaillée software embarqué
- Spécification détaillée hardware
- Spécification des interfaces
- Contraintes cybersécurité
- Contraintes d’exploitation
- Contraintes de maintenance
- Contraintes de sauvegarde et restauration
```
### 2.2 Documents applicables
Cette partie liste les documents que l’application doit respecter.
**Exemples :**
```text
- politique de sécurité informatique client ;
- règles de gestion des comptes utilisateurs ;
- politique de mots de passe ;
- exigences de journalisation ;
- règles de conservation des données ;
- politique de sauvegarde ;
- standard d’ergonomie ou charte IHM ;
- standard API ;
- standard de développement logiciel ;
- règles de gestion de configuration ;
- exigences RGPD si données personnelles ;
- exigences d’audit ou de traçabilité.
```
### 2.3 Documents produits à partir de cette spécification
Cette partie liste les documents dérivés.
**Exemples :**
```text
- conception détaillée serveur ;
- conception détaillée API ;
- conception détaillée base de données ;
- conception détaillée IHM ;
- procédures de tests unitaires backend ;
- procédures de tests API ;
- procédures de tests IHM ;
- procédures de tests d’intégration équipement / serveur ;
- procédures de tests de sauvegarde applicative ;
- manuel utilisateur ;
- manuel administrateur ;
- manuel exploitant ;
- dossier de configuration applicative livrée.
```
### 2.4 Gestion des versions
Cette partie précise que les versions applicatives doivent être maîtrisées.
Une évolution côté serveur peut modifier les API, les formats de données, les règles d’alarme, l’IHM, la base de données ou la compatibilité avec les équipements embarqués.
**Exemple :**
> Toute modification d’une API, d’un format de message, d’une règle de traitement d’alarme, d’un modèle de données, d’un droit utilisateur ou d’un écran d’exploitation doit faire l’objet d’une analyse d’impact sur le firmware, les tests d’intégration, les procédures de validation, la documentation utilisateur et la configuration livrée.
---
## 3. Définitions, acronymes et conventions
### 3.1 Définitions
Cette partie définit les termes utilisés dans le document.
**Exemples :**
```text
Serveur applicatif :
Composant logiciel central chargé de recevoir, traiter, stocker et restituer les données du système.
API :
Interface logicielle permettant à un composant externe ou interne d’interagir avec le serveur applicatif.
Équipement :
Unité matérielle ou embarquée communiquant avec le serveur.
IHM :
Interface utilisateur permettant la consultation, l’administration ou l’exploitation du système.
Alarme active :
Alarme dont la condition d’apparition est toujours présente ou non clôturée.
Historique :
Ensemble des données passées conservées pour consultation, diagnostic ou audit.
Utilisateur habilité :
Utilisateur disposant des droits nécessaires pour réaliser une action donnée.
```
### 3.2 Acronymes
**Exemples :**
```text
API : Application Programming Interface
BDD : Base de données
CSV : Comma-Separated Values
DB : Database
HTTP : HyperText Transfer Protocol
HTTPS : HyperText Transfer Protocol Secure
IHM : Interface Homme-Machine
JSON : JavaScript Object Notation
JWT : JSON Web Token
LDAP : Lightweight Directory Access Protocol
REST : Representational State Transfer
TLS : Transport Layer Security
UI : User Interface
VPN : Virtual Private Network
```
### 3.3 Convention d’identification des exigences serveur
Cette partie définit la codification des exigences.
**Exemple :**
```text
SRV-REC-001 : exigence de réception de données
SRV-VAL-001 : exigence de validation de message
SRV-ALM-001 : exigence de gestion des alarmes
SRV-HIST-001 : exigence d’historisation
SRV-IHM-001 : exigence d’interface utilisateur
SRV-USER-001 : exigence de gestion utilisateur
SRV-RIGHT-001 : exigence de droits
SRV-API-001 : exigence API
SRV-DB-001 : exigence base de données
SRV-EXP-001 : exigence d’export
SRV-SUP-001 : exigence de supervision applicative
SRV-SEC-001 : exigence de sécurité
SRV-TEST-001 : exigence de testabilité
```
### 3.4 Convention de formulation des exigences
Cette partie rappelle qu’une exigence doit être claire, vérifiable et non ambiguë.
**Exemples :**
```text
Correct :
SRV-REC-001 — Le serveur doit recevoir les messages de mesure transmis par les équipements autorisés.
Incorrect :
Le serveur doit bien récupérer les données.
Correct :
SRV-ALM-003 — Le serveur doit afficher les alarmes actives avec leur identifiant, criticité, équipement concerné, date d’apparition et statut.
Incorrect :
Le serveur doit afficher correctement les alarmes.
```
### 3.5 Convention de criticité
Cette partie permet de classer les exigences selon leur importance.
**Exemple :**
```text
Critique :
sécurité, état sûr, alarmes critiques, intégrité des données, accès non autorisé.
Élevée :
fonction majeure d’exploitation, communication équipement, historisation, supervision.
Moyenne :
fonction importante mais non bloquante pour le fonctionnement principal.
Faible :
fonction de confort, affichage secondaire, export optionnel ou amélioration ergonomique.
```
---
## 4. Vue générale de l’application serveur
### 4.1 Présentation générale
Cette partie décrit le rôle de la partie serveur dans le système global.
Elle doit permettre de comprendre ce que le serveur apporte par rapport à l’équipement embarqué : centralisation, historisation, interface utilisateur, administration, supervision, reporting, consolidation multi-équipements et intégration avec d’autres systèmes.
**Exemple :**
> La partie serveur assure la réception des données transmises par les équipements embarqués, leur validation, leur historisation, la consolidation des états, la gestion des alarmes, l’accès aux interfaces opérateur et administrateur, la gestion des utilisateurs, les exports, les rapports et la supervision applicative.
### 4.2 Fonctions principales
Cette partie liste les grandes fonctions applicatives.
**Exemples :**
```text
- réception des données équipements ;
- validation des messages reçus ;
- historisation des mesures ;
- gestion des alarmes ;
- gestion des événements ;
- affichage des états équipements ;
- affichage des historiques ;
- gestion des utilisateurs ;
- gestion des droits ;
- gestion des configurations ;
- interface opérateur ;
- interface administrateur ;
- interface maintenance ;
- API ;
- exports ;
- reporting ;
- supervision applicative ;
- journalisation ;
- sauvegarde applicative ;
- interface avec systèmes tiers.
```
### 4.3 Frontières applicatives
Cette partie précise ce qui relève de l’application et ce qui relève d’autres sous-systèmes.
**Exemple :**
```text
Inclus dans l’application serveur :
- réception des données ;
- traitement des alarmes ;
- stockage en base ;
- interface web ;
- gestion utilisateurs ;
- API ;
- exports ;
- logs applicatifs.
Externe à l’application serveur :
- système d’exploitation ;
- réseau physique ;
- sauvegarde infrastructure ;
- firmware embarqué ;
- capteurs physiques ;
- administration générale du SI client ;
- système de supervision client externe.
```
### 4.4 Interactions avec les équipements embarqués
Cette partie décrit les échanges entre le serveur et les équipements.
**Exemples :**
```text
- réception de mesures ;
- réception d’alarmes ;
- réception d’événements ;
- réception de diagnostics ;
- envoi d’acquittements ;
- envoi de configuration ;
- envoi de commandes autorisées ;
- demande de resynchronisation ;
- suivi de l’état de connexion.
```
### 4.5 Interactions avec les utilisateurs
Cette partie décrit les profils utilisateurs qui interagissent avec l’application.
**Exemples :**
```text
- opérateur ;
- technicien de maintenance ;
- administrateur ;
- superviseur ;
- utilisateur lecture seule ;
- support technique ;
- responsable exploitation.
```
### 4.6 Interactions avec l’infrastructure
Cette partie décrit les dépendances techniques.
**Exemples :**
```text
- base de données ;
- serveur web ;
- reverse proxy ;
- certificat TLS ;
- système de fichiers ;
- serveur de sauvegarde ;
- service de supervision ;
- service d’authentification ;
- réseau ;
- DNS ;
- horloge NTP.
```
---
## 5. Exigences de réception des données équipements
### 5.1 Objet de la réception des données
Cette partie décrit la capacité du serveur à recevoir les messages transmis par les équipements embarqués.
Ces messages peuvent contenir des mesures, états, alarmes, événements, informations de diagnostic, versions, logs ou résultats de commandes.
### 5.2 Types de données reçues
**Exemples :**
```text
- mesures périodiques ;
- mesures événementielles ;
- alarmes ;
- événements système ;
- changements de mode ;
- états de communication ;
- informations de diagnostic ;
- logs ;
- configuration active ;
- version firmware ;
- résultat de commande ;
- données resynchronisées après perte réseau.
```
### 5.3 Identification de l’équipement émetteur
Cette partie décrit comment le serveur identifie l’origine des données.
**Exemples d’exigences :**
```text
SRV-REC-001 — Le serveur doit identifier l’équipement émetteur de chaque message reçu.
SRV-REC-002 — Le serveur doit refuser ou signaler un message provenant d’un équipement non connu si cette situation est considérée comme anormale.
SRV-REC-003 — Le serveur doit associer chaque donnée reçue à l’équipement correspondant.
```
**Exemple explicatif :**
> Chaque message reçu doit contenir ou permettre de déterminer l’identifiant de l’équipement. Cet identifiant permet de rattacher les mesures, alarmes et événements au bon objet dans l’IHM et dans l’historique.
### 5.4 Horodatage des données reçues
Cette partie décrit la gestion du temps.
Il faut distinguer l’horodatage produit par l’équipement et l’horodatage de réception serveur.
**Exemples :**
```text
SRV-REC-TIME-001 — Le serveur doit conserver l’horodatage d’origine transmis par l’équipement lorsque celui-ci est disponible.
SRV-REC-TIME-002 — Le serveur doit ajouter un horodatage de réception serveur.
SRV-REC-TIME-003 — Le serveur doit permettre d’identifier les données dont l’horodatage d’origine est absent, incertain ou incohérent.
```
**Exemple :**
```text
Horodatage équipement : 2026-07-03 14:02:10
Horodatage réception serveur : 2026-07-03 14:05:42
Cas possible : donnée retransmise après perte réseau.
```
### 5.5 Acquittement des messages
Cette partie décrit le comportement du serveur après réception.
**Exemples :**
```text
SRV-REC-ACK-001 — Le serveur doit produire un acquittement pour les messages nécessitant une confirmation de réception.
SRV-REC-ACK-002 — L’acquittement doit permettre à l’équipement de déterminer si le message a été accepté, rejeté ou mis en attente.
SRV-REC-ACK-003 — En cas de rejet, le serveur doit fournir un motif exploitable si le protocole le permet.
```
### 5.6 Gestion des messages dupliqués
Cette partie est importante lors des resynchronisations après perte réseau.
**Exemples :**
```text
SRV-REC-DUP-001 — Le serveur doit détecter ou gérer les doublons de messages si le protocole d’échange le permet.
SRV-REC-DUP-002 — Un message retransmis après perte réseau ne doit pas créer de doublon fonctionnel dans les historiques critiques.
SRV-REC-DUP-003 — Les doublons détectés doivent être ignorés, fusionnés ou historisés selon la règle définie.
```
### 5.7 Gestion des messages en retard
Cette partie décrit les données reçues tardivement.
**Exemple :**
```text
SRV-REC-LATE-001 — Le serveur doit accepter les données retransmises après une période de perte communication, en conservant leur horodatage d’origine.
SRV-REC-LATE-002 — Le serveur doit permettre d’identifier les données reçues en différé si cette information est utile à l’exploitation.
```
### 5.8 Tests associés
**Exemples :**
```text
- réception mesure nominale ;
- réception alarme ;
- réception événement ;
- réception message équipement inconnu ;
- réception message sans horodatage ;
- réception message retransmis ;
- réception doublon ;
- acquittement accepté ;
- acquittement rejeté ;
- réception données après coupure réseau.
```
---
## 6. Exigences de validation des messages
### 6.1 Objet de la validation des messages
Cette partie décrit les contrôles réalisés par le serveur avant d’accepter une donnée.
La validation protège l’intégrité du système contre les messages incomplets, incohérents, mal formés, incompatibles ou non autorisés.
### 6.2 Contrôles de format
**Exemples :**
```text
SRV-VAL-FMT-001 — Le serveur doit vérifier que le message reçu respecte le format attendu.
SRV-VAL-FMT-002 — Le serveur doit rejeter un message dont la structure est invalide.
SRV-VAL-FMT-003 — Le serveur doit journaliser les erreurs de format répétées.
```
### 6.3 Contrôles de contenu
Cette partie décrit la vérification des champs obligatoires.
**Exemples :**
```text
- identifiant équipement ;
- type de message ;
- horodatage ;
- numéro ou identifiant de message ;
- version de protocole ;
- données mesurées ;
- unité ;
- criticité ;
- statut ;
- signature ou contrôle d’intégrité si applicable.
```
**Exemple d’exigence :**
```text
SRV-VAL-CONT-001 — Le serveur doit refuser un message de mesure ne contenant pas l’identifiant équipement ou la valeur mesurée.
```
### 6.4 Contrôles de cohérence
Cette partie décrit les règles métier ou techniques.
**Exemples :**
```text
- valeur hors plage ;
- unité inconnue ;
- équipement non compatible ;
- version protocole non supportée ;
- date future incohérente ;
- message plus ancien que la dernière donnée connue ;
- alarme sans équipement associé ;
- statut invalide ;
- criticité inconnue.
```
### 6.5 Contrôle d’autorisation
Cette partie décrit les contrôles d’origine du message.
**Exemples :**
```text
SRV-VAL-AUTH-001 — Le serveur doit accepter uniquement les messages provenant d’équipements autorisés.
SRV-VAL-AUTH-002 — Un équipement désactivé ne doit pas pouvoir alimenter les historiques de production sans décision explicite.
SRV-VAL-AUTH-003 — Les erreurs d’autorisation doivent être journalisées.
```
### 6.6 Gestion des messages rejetés
Cette partie décrit ce que le serveur fait des messages invalides.
**Exemples :**
```text
- rejet simple ;
- journalisation ;
- alerte technique ;
- conservation en quarantaine ;
- réponse d’erreur à l’équipement ;
- incrément d’un compteur d’erreurs ;
- blocage temporaire si erreurs répétées ;
- création d’un incident si seuil dépassé.
```
### 6.7 Tests associés
**Exemples :**
```text
- message valide ;
- message mal formé ;
- champ obligatoire absent ;
- valeur hors plage ;
- protocole non supporté ;
- équipement inconnu ;
- équipement désactivé ;
- message avec horodatage futur ;
- erreurs répétées ;
- journalisation du rejet.
```
---
## 7. Exigences de gestion des équipements
### 7.1 Objet de la gestion des équipements
Cette partie décrit comment le serveur connaît, affiche, administre et suit les équipements embarqués.
Un équipement doit être identifié, rattaché à une configuration, éventuellement à un site ou une zone, et associé à des données, alarmes, historiques et états.
### 7.2 Fiche équipement
Cette partie décrit les informations minimales associées à un équipement.
**Exemple :**
```text
Identifiant équipement :
Nom affiché :
Numéro de série :
Type :
Version hardware :
Version firmware :
Site :
Zone :
Adresse ou localisation :
Statut administratif : actif / inactif / maintenance / retiré
Dernière communication :
Configuration associée :
Date de mise en service :
Commentaires :
```
### 7.3 Création d’un équipement
**Exemples :**
```text
SRV-EQP-001 — Le serveur doit permettre la création d’un équipement par un utilisateur habilité.
SRV-EQP-002 — Chaque équipement doit disposer d’un identifiant unique.
SRV-EQP-003 — Le serveur doit empêcher la création de deux équipements actifs avec le même identifiant technique.
```
### 7.4 Activation et désactivation d’un équipement
Cette partie décrit les statuts administratifs.
**Exemples :**
```text
SRV-EQP-010 — Le serveur doit permettre de désactiver un équipement sans supprimer son historique.
SRV-EQP-011 — Un équipement désactivé ne doit plus être affiché comme équipement opérationnel actif.
SRV-EQP-012 — Les données reçues d’un équipement désactivé doivent être rejetées, ignorées ou signalées selon la règle définie.
```
### 7.5 État de connexion
Cette partie décrit comment le serveur affiche la connectivité.
**Exemples :**
```text
- connecté ;
- non joignable ;
- jamais connecté ;
- en retard de communication ;
- en maintenance ;
- désactivé ;
- état inconnu.
```
**Exemple d’exigence :**
```text
SRV-EQP-COM-001 — Le serveur doit afficher l’état de communication de chaque équipement actif.
```
### 7.6 Association équipement / configuration
Cette partie décrit comment une configuration est associée à un équipement.
**Exemples :**
```text
SRV-EQP-CFG-001 — Le serveur doit associer chaque équipement à une configuration active.
SRV-EQP-CFG-002 — Le serveur doit conserver l’historique des configurations appliquées à un équipement si cette traçabilité est requise.
SRV-EQP-CFG-003 — Le serveur doit signaler une divergence entre la configuration attendue et la configuration déclarée par l’équipement.
```
### 7.7 Tests associés
**Exemples :**
```text
- création équipement ;
- création doublon refusée ;
- désactivation équipement ;
- réception message équipement désactivé ;
- affichage état connecté ;
- affichage état non joignable ;
- changement de configuration ;
- consultation historique équipement.
```
---
## 8. Exigences de gestion des alarmes
### 8.1 Objet de la gestion des alarmes
Cette partie décrit comment le serveur reçoit, crée, consolide, affiche, historise et clôture les alarmes.
Certaines alarmes sont générées par l’équipement embarqué. D’autres peuvent être générées directement par le serveur, par exemple absence de communication, échec de sauvegarde applicative, incohérence de données ou erreur de traitement.
### 8.2 Sources d’alarmes
**Exemples :**
```text
- équipement embarqué ;
- serveur applicatif ;
- base de données ;
- supervision applicative ;
- infrastructure ;
- utilisateur ;
- système tiers ;
- processus de sauvegarde ;
- processus de synchronisation.
```
### 8.3 Informations associées à une alarme
**Exemples d’exigences :**
```text
SRV-ALM-001 — Chaque alarme doit comporter un identifiant ou type d’alarme.
SRV-ALM-002 — Chaque alarme doit être associée à un équipement, un service ou un composant lorsque cette association est applicable.
SRV-ALM-003 — Chaque alarme doit comporter une criticité.
SRV-ALM-004 — Chaque alarme doit comporter une date d’apparition.
SRV-ALM-005 — Chaque alarme doit comporter un statut : active, acquittée, disparue, clôturée ou historisée selon le modèle retenu.
```
### 8.4 Niveaux de criticité
Cette partie décrit la classification.
**Exemple :**
```text
Information :
événement à historiser sans action immédiate.
Mineure :
défaut limité, sans impact significatif immédiat.
Majeure :
défaut impactant une fonction importante ou nécessitant intervention.
Critique :
défaut impactant la sécurité, la disponibilité, les données critiques ou l’état sûr.
```
### 8.5 Alarme active et historique
Cette partie distingue les alarmes présentes des alarmes passées.
**Exemples :**
```text
SRV-ALM-ACT-001 — Le serveur doit afficher séparément les alarmes actives et l’historique des alarmes.
SRV-ALM-ACT-002 — Une alarme active doit rester visible tant que sa condition de clôture n’est pas satisfaite.
SRV-ALM-HIST-001 — Les alarmes clôturées doivent être conservées dans l’historique.
```
### 8.6 Acquittement des alarmes
Cette partie décrit les règles d’acquittement.
**Exemples :**
```text
SRV-ALM-ACK-001 — Le serveur doit permettre l’acquittement d’une alarme par un utilisateur habilité.
SRV-ALM-ACK-002 — L’acquittement doit être journalisé avec l’identité de l’utilisateur, la date et l’alarme concernée.
SRV-ALM-ACK-003 — L’acquittement ne doit pas supprimer l’alarme si la condition d’apparition est toujours présente.
SRV-ALM-ACK-004 — Certaines alarmes critiques peuvent nécessiter une action spécifique avant clôture.
```
### 8.7 Clôture des alarmes
Cette partie décrit comment une alarme se termine.
**Exemples :**
```text
- disparition automatique de la condition ;
- retour à la normale signalé par l’équipement ;
- action de maintenance ;
- acquittement + disparition ;
- clôture administrative par utilisateur habilité ;
- remplacement d’équipement ;
- correction serveur.
```
### 8.8 Consolidation et anti-doublon
Cette partie évite la multiplication excessive d’alarmes.
**Exemples :**
```text
SRV-ALM-DUP-001 — Le serveur doit éviter la création d’alarmes dupliquées pour un même défaut actif sur un même équipement.
SRV-ALM-DUP-002 — Si un défaut persiste, le serveur doit mettre à jour l’alarme existante plutôt que créer une nouvelle alarme à chaque message.
SRV-ALM-DUP-003 — Les répétitions peuvent être historisées sous forme de compteur ou d’événements associés.
```
### 8.9 Affichage des alarmes
Cette partie décrit les besoins de l’IHM.
**Exemples :**
```text
- liste des alarmes actives ;
- couleur ou pictogramme selon criticité ;
- filtre par équipement ;
- filtre par site ;
- filtre par criticité ;
- filtre par statut ;
- tri par date ;
- détail alarme ;
- historique ;
- export ;
- acquittement.
```
### 8.10 Tests associés
**Exemples :**
```text
- réception alarme équipement ;
- création alarme serveur ;
- affichage alarme active ;
- acquittement autorisé ;
- acquittement refusé ;
- clôture alarme ;
- historique alarme ;
- anti-doublon ;
- filtre criticité ;
- export historique alarmes.
```
---
## 9. Exigences d’historisation des données
### 9.1 Objet de l’historisation
Cette partie décrit les données à conserver dans le temps.
L’historisation permet la consultation, l’analyse, le diagnostic, la preuve, le reporting et la maintenance. Elle concerne les mesures, alarmes, événements, commandes, changements de configuration, connexions utilisateurs et opérations d’administration.
### 9.2 Données historisées
**Exemples :**
```text
- mesures ;
- états équipements ;
- alarmes ;
- événements ;
- transitions de mode ;
- commandes ;
- modifications de configuration ;
- connexions utilisateurs ;
- erreurs applicatives ;
- exports ;
- opérations de maintenance ;
- mises à jour ;
- sauvegardes ;
- restaurations.
```
### 9.3 Historisation des mesures
**Exemples :**
```text
SRV-HIST-MES-001 — Le serveur doit enregistrer les mesures reçues des équipements autorisés.
SRV-HIST-MES-002 — Chaque mesure historisée doit être associée à un équipement, un type de mesure, une valeur, une unité et un horodatage.
SRV-HIST-MES-003 — Les mesures retransmises après perte réseau doivent être historisées avec leur horodatage d’origine.
```
### 9.4 Historisation des événements
**Exemples :**
```text
SRV-HIST-EVT-001 — Le serveur doit historiser les événements significatifs transmis par les équipements.
SRV-HIST-EVT-002 — Le serveur doit historiser les événements applicatifs significatifs.
SRV-HIST-EVT-003 — Les événements doivent être consultables avec des filtres par date, type, équipement et criticité si applicable.
```
### 9.5 Durées de conservation
Cette partie précise combien de temps les données doivent être conservées.
**Exemple :**
```text
Mesures détaillées : 12 mois
Alarmes : 24 mois
Événements critiques : 24 mois
Logs applicatifs : 90 jours
Actions administrateur : 12 mois
Exports temporaires : 30 jours
```
### 9.6 Purge et archivage
Cette partie décrit ce qui se passe lorsque les données deviennent anciennes.
**Exemples :**
```text
SRV-HIST-ARCH-001 — Le serveur doit permettre l’archivage ou la purge des données selon la politique de conservation définie.
SRV-HIST-ARCH-002 — La purge ne doit pas supprimer des données encore nécessaires à une obligation contractuelle, réglementaire ou de maintenance.
SRV-HIST-ARCH-003 — Les opérations de purge ou d’archivage doivent être journalisées si elles concernent des données critiques.
```
### 9.7 Consultation des historiques
Cette partie décrit les fonctions de recherche.
**Exemples :**
```text
- filtre par équipement ;
- filtre par période ;
- filtre par type de donnée ;
- filtre par criticité ;
- filtre par statut ;
- tri ;
- pagination ;
- export ;
- affichage graphique ;
- comparaison entre équipements.
```
### 9.8 Tests associés
**Exemples :**
```text
- historisation mesure ;
- historisation alarme ;
- historisation événement ;
- consultation par période ;
- filtre par équipement ;
- conservation horodatage d’origine ;
- purge contrôlée ;
- export historique ;
- performance sur historique volumineux.
```
---
## 10. Exigences de base de données
### 10.1 Objet de la base de données
Cette partie décrit le rôle de la base de données dans l’application.
Elle stocke les données opérationnelles, historiques, configurations, utilisateurs, alarmes, événements, droits, traces et paramètres.
### 10.2 Familles de données en base
**Exemples :**
```text
- équipements ;
- mesures ;
- alarmes ;
- événements ;
- utilisateurs ;
- rôles ;
- droits ;
- configurations ;
- journaux ;
- commandes ;
- rapports ;
- exports ;
- paramètres applicatifs ;
- versions ;
- incidents.
```
### 10.3 Exigences d’intégrité
Cette partie décrit les règles permettant d’éviter les données incohérentes.
**Exemples :**
```text
SRV-DB-INT-001 — Une mesure historisée doit être rattachée à un équipement identifié.
SRV-DB-INT-002 — Une alarme doit être rattachée à un équipement, un service ou une source identifiée lorsque cela est applicable.
SRV-DB-INT-003 — La suppression d’un équipement ne doit pas entraîner la perte non maîtrisée de son historique.
SRV-DB-INT-004 — Les modifications de configuration doivent être historisées si la traçabilité est requise.
```
### 10.4 Exigences de performance base de données
**Exemples :**
```text
SRV-DB-PERF-001 — La base de données doit permettre la consultation des alarmes actives dans un délai compatible avec l’exploitation.
SRV-DB-PERF-002 — La consultation des historiques doit rester possible sur la période de conservation définie.
SRV-DB-PERF-003 — Les requêtes fréquentes doivent être compatibles avec le nombre d’équipements et le volume de données prévu.
```
### 10.5 Migration de base de données
Cette partie décrit les évolutions de schéma.
**Exemples :**
```text
SRV-DB-MIG-001 — Toute évolution du modèle de données doit être associée à une procédure de migration.
SRV-DB-MIG-002 — Une migration de base doit être testée sur un environnement représentatif avant production.
SRV-DB-MIG-003 — Un retour arrière ou une sauvegarde préalable doit être prévu avant migration critique.
```
### 10.6 Sauvegarde de base de données
Cette partie renvoie au dossier infrastructure, mais précise les exigences applicatives.
**Exemples :**
```text
SRV-DB-BKP-001 — Les données applicatives critiques doivent être sauvegardables.
SRV-DB-BKP-002 — La restauration d’une sauvegarde doit permettre le redémarrage cohérent de l’application.
SRV-DB-BKP-003 — Le serveur doit permettre de vérifier la cohérence applicative après restauration.
```
### 10.7 Tests associés
**Exemples :**
```text
- création mesure ;
- création alarme ;
- intégrité équipement / mesure ;
- conservation historique après désactivation équipement ;
- migration base ;
- restauration base ;
- performance requête historique ;
- purge ancienne donnée.
```
---
## 11. Exigences d’API
### 11.1 Objet des API
Cette partie décrit les interfaces logicielles exposées ou consommées par le serveur.
Il peut s’agir d’API entre équipement et serveur, entre IHM et serveur, entre serveur et système tiers, ou entre services internes.
### 11.2 Types d’API
**Exemples :**
```text
- API de réception équipements ;
- API de consultation IHM ;
- API d’administration ;
- API de configuration ;
- API de diagnostic ;
- API d’export ;
- API de supervision ;
- API vers système tiers ;
- API interne entre services.
```
### 11.3 API équipement / serveur
Cette partie décrit les exigences générales de l’API utilisée par les équipements.
**Exemples :**
```text
SRV-API-EQP-001 — Le serveur doit exposer ou utiliser une interface permettant la réception des messages équipements.
SRV-API-EQP-002 — L’API équipement doit permettre l’identification de l’équipement émetteur.
SRV-API-EQP-003 — L’API équipement doit permettre l’acquittement des messages reçus si le protocole le prévoit.
SRV-API-EQP-004 — L’API équipement doit rejeter les messages invalides.
```
### 11.4 API IHM / serveur
Cette partie décrit les échanges entre l’interface utilisateur et le backend.
**Exemples :**
```text
- consultation état équipements ;
- consultation alarmes actives ;
- consultation historiques ;
- acquittement alarme ;
- gestion utilisateurs ;
- modification configuration ;
- export rapport ;
- consultation logs autorisés.
```
### 11.5 API systèmes tiers
Cette partie décrit les intégrations externes.
**Exemples :**
```text
- export vers supervision client ;
- synchronisation avec GMAO ;
- envoi notification ;
- import de référentiel équipements ;
- export CSV ou JSON ;
- connexion à annuaire utilisateur ;
- interface avec ERP.
```
### 11.6 Versionnement des API
Cette partie est essentielle pour éviter les incompatibilités.
**Exemples :**
```text
SRV-API-VER-001 — Les API exposées à des composants externes doivent être versionnées si elles peuvent évoluer.
SRV-API-VER-002 — Une évolution incompatible d’API doit être documentée.
SRV-API-VER-003 — La compatibilité entre version firmware et version API serveur doit être documentée.
```
### 11.7 Gestion des erreurs API
**Exemples :**
```text
- erreur format ;
- authentification échouée ;
- autorisation insuffisante ;
- ressource inconnue ;
- conflit ;
- erreur serveur ;
- timeout ;
- service indisponible.
```
### 11.8 Tests associés
**Exemples :**
```text
- appel API valide ;
- appel API sans authentification ;
- appel API utilisateur non autorisé ;
- format invalide ;
- version API incompatible ;
- erreur serveur simulée ;
- pagination ;
- filtre ;
- performance API ;
- compatibilité firmware/API.
```
---
## 12. Exigences d’interface utilisateur opérateur
### 12.1 Objet de l’IHM opérateur
Cette partie décrit l’interface destinée aux utilisateurs d’exploitation.
Elle doit permettre de comprendre l’état du système, visualiser les équipements, consulter les alarmes, suivre les événements, rechercher dans les historiques et effectuer les actions autorisées.
### 12.2 Tableau de bord
**Exemples d’exigences :**
```text
SRV-IHM-DASH-001 — L’IHM doit présenter un tableau de bord synthétique de l’état du système.
SRV-IHM-DASH-002 — Le tableau de bord doit afficher le nombre d’équipements actifs, non joignables, en défaut et en maintenance.
SRV-IHM-DASH-003 — Le tableau de bord doit afficher les alarmes critiques actives.
```
### 12.3 Liste des équipements
**Exemples :**
```text
SRV-IHM-EQP-001 — L’IHM doit permettre de consulter la liste des équipements.
SRV-IHM-EQP-002 — La liste des équipements doit afficher au minimum le nom, l’état, la dernière communication, les alarmes actives et le site ou la zone si applicable.
SRV-IHM-EQP-003 — L’utilisateur doit pouvoir filtrer les équipements selon leur statut.
```
### 12.4 Fiche équipement
Cette partie décrit l’écran de détail d’un équipement.
**Exemples d’informations affichées :**
```text
- identifiant ;
- nom ;
- site ;
- état courant ;
- mode courant ;
- dernière communication ;
- version firmware ;
- version hardware ;
- configuration active ;
- alarmes actives ;
- mesures récentes ;
- événements récents ;
- historique ;
- actions autorisées.
```
### 12.5 Écran alarmes
Cette partie décrit l’écran de gestion des alarmes.
**Exemples :**
```text
SRV-IHM-ALM-001 — L’IHM doit afficher les alarmes actives dans une liste dédiée.
SRV-IHM-ALM-002 — Les alarmes doivent être filtrables par criticité, équipement, statut et période.
SRV-IHM-ALM-003 — L’IHM doit permettre l’acquittement d’une alarme par un utilisateur habilité.
SRV-IHM-ALM-004 — L’IHM doit permettre d’accéder au détail d’une alarme.
```
### 12.6 Écran historiques
Cette partie décrit la consultation des données passées.
**Exemples :**
```text
- historiques de mesures ;
- historiques d’alarmes ;
- historiques d’événements ;
- historiques de commandes ;
- historiques de configuration ;
- historiques de connexion ;
- exports.
```
### 12.7 Ergonomie et lisibilité
Cette partie décrit les exigences de compréhension.
**Exemples :**
```text
SRV-IHM-ERG-001 — Les informations critiques doivent être visuellement distinguables.
SRV-IHM-ERG-002 — Les messages affichés doivent être compréhensibles par un opérateur non développeur.
SRV-IHM-ERG-003 — Les actions critiques doivent demander une confirmation explicite.
SRV-IHM-ERG-004 — L’IHM doit éviter les ambiguïtés entre alarme active, acquittée et clôturée.
```
### 12.8 Tests associés
**Exemples :**
```text
- affichage tableau de bord ;
- affichage liste équipements ;
- filtre équipement ;
- détail équipement ;
- affichage alarmes ;
- acquittement alarme ;
- consultation historique ;
- export ;
- action non autorisée masquée ou refusée ;
- lisibilité message erreur.
```
---
## 13. Exigences d’administration
### 13.1 Objet de l’administration
Cette partie décrit les fonctions réservées aux administrateurs.
L’administration peut concerner les utilisateurs, les rôles, les équipements, les configurations, les paramètres applicatifs, les imports/exports, les sauvegardes applicatives et certaines actions de maintenance.
### 13.2 Gestion des utilisateurs
**Exemples :**
```text
SRV-ADM-USER-001 — L’application doit permettre la création d’un utilisateur par un administrateur habilité.
SRV-ADM-USER-002 — L’application doit permettre la désactivation d’un utilisateur.
SRV-ADM-USER-003 — L’application doit conserver une trace des actions d’administration utilisateur.
SRV-ADM-USER-004 — La suppression d’un utilisateur ne doit pas supprimer l’historique des actions déjà réalisées par cet utilisateur.
```
### 13.3 Gestion des rôles et droits
**Exemples de rôles :**
```text
- opérateur ;
- maintenance ;
- administrateur ;
- superviseur ;
- lecture seule ;
- support technique.
```
**Exemples d’exigences :**
```text
SRV-ADM-RIGHT-001 — L’application doit associer chaque utilisateur à un ou plusieurs rôles.
SRV-ADM-RIGHT-002 — Les actions sensibles doivent être autorisées uniquement aux rôles habilités.
SRV-ADM-RIGHT-003 — Toute tentative d’action non autorisée doit être refusée et journalisée si nécessaire.
```
### 13.4 Gestion des équipements
Cette partie décrit les fonctions administratives sur les équipements.
**Exemples :**
```text
- création équipement ;
- modification nom ou localisation ;
- activation/désactivation ;
- rattachement à un site ;
- association configuration ;
- retrait du parc ;
- consultation version ;
- historique équipement.
```
### 13.5 Gestion des configurations
Cette partie décrit les actions sur les configurations applicatives ou équipements.
**Exemples :**
```text
SRV-ADM-CFG-001 — L’application doit permettre la consultation des configurations applicables aux équipements.
SRV-ADM-CFG-002 — La modification d’une configuration critique doit être réservée aux utilisateurs habilités.
SRV-ADM-CFG-003 — Toute modification de configuration doit être historisée.
SRV-ADM-CFG-004 — L’application doit empêcher l’application d’une configuration invalide.
```
### 13.6 Paramètres applicatifs
Cette partie décrit les paramètres généraux du serveur.
**Exemples :**
```text
- durée de conservation des données ;
- seuils applicatifs ;
- fréquence de supervision ;
- paramètres d’alerte ;
- paramètres d’export ;
- configuration des notifications ;
- paramètres de connexion à un système tiers ;
- paramètres de purge.
```
### 13.7 Tests associés
**Exemples :**
```text
- création utilisateur ;
- désactivation utilisateur ;
- action admin autorisée ;
- action admin refusée ;
- modification configuration ;
- configuration invalide refusée ;
- traçabilité action admin ;
- consultation historique utilisateur ;
- retrait équipement.
```
---
## 14. Exigences de gestion des utilisateurs, authentification et droits
### 14.1 Objet de l’authentification
Cette partie décrit comment l’application identifie les utilisateurs.
Selon le contexte, l’authentification peut être locale, déléguée à un annuaire, couplée à un SSO ou renforcée par un second facteur.
### 14.2 Authentification locale
**Exemples :**
```text
SRV-AUTH-001 — L’application doit authentifier les utilisateurs avant accès aux fonctions non publiques.
SRV-AUTH-002 — L’application doit refuser l’accès en cas d’identifiants invalides.
SRV-AUTH-003 — L’application doit journaliser les échecs répétés de connexion si cela est requis.
```
### 14.3 Authentification déléguée
Cette partie est à compléter si l’application utilise un annuaire client.
**Exemples :**
```text
- LDAP ;
- Active Directory ;
- SSO ;
- OAuth2 ;
- SAML ;
- OpenID Connect.
```
**Exemple d’exigence :**
```text
SRV-AUTH-EXT-001 — L’application doit pouvoir déléguer l’authentification au service d’identité défini dans le dossier infrastructure si cette option est retenue.
```
### 14.4 Sessions utilisateurs
**Exemples :**
```text
SRV-SESS-001 — L’application doit gérer une session utilisateur après authentification.
SRV-SESS-002 — La session doit expirer après une période d’inactivité définie.
SRV-SESS-003 — L’utilisateur doit pouvoir se déconnecter explicitement.
SRV-SESS-004 — Les actions réalisées après expiration de session doivent être refusées.
```
### 14.5 Droits par fonction
Cette partie décrit la matrice des droits.
**Exemple :**
```text
Fonction | Lecture seule | Opérateur | Maintenance | Administrateur
Consulter états | oui | oui | oui | oui
Acquitter alarme | non | oui | oui | oui
Exporter logs | non | non | oui | oui
Modifier configuration | non | non | limité | oui
Créer utilisateur | non | non | non | oui
Désactiver équipement | non | non | non | oui
```
### 14.6 Journalisation des actions utilisateurs
**Exemples :**
```text
SRV-USER-LOG-001 — L’application doit journaliser les actions sensibles réalisées par les utilisateurs.
SRV-USER-LOG-002 — Le journal doit contenir l’utilisateur, la date, l’action, la ressource concernée et le résultat.
SRV-USER-LOG-003 — Les journaux d’actions utilisateurs doivent être consultables par un profil habilité.
```
### 14.7 Tests associés
**Exemples :**
```text
- connexion valide ;
- connexion invalide ;
- expiration session ;
- déconnexion ;
- accès autorisé ;
- accès refusé ;
- action sensible journalisée ;
- rôle insuffisant ;
- utilisateur désactivé ;
- authentification externe indisponible.
```
---
## 15. Exigences de configuration applicative
### 15.1 Objet de la configuration applicative
Cette partie décrit les paramètres qui gouvernent le fonctionnement du serveur et de l’application.
### 15.2 Paramètres serveur
**Exemples :**
```text
- paramètres de connexion base de données ;
- paramètres réseau ;
- URL serveur ;
- paramètres TLS ;
- chemin des logs ;
- paramètres d’export ;
- paramètres de sauvegarde applicative ;
- paramètres de supervision ;
- configuration d’un système tiers ;
- niveau de log ;
- paramètres de purge.
```
### 15.3 Paramètres métier
**Exemples :**
```text
- seuils d’alarme centralisés ;
- criticité des alarmes ;
- règles de consolidation ;
- règles d’acquittement ;
- règles de clôture ;
- durée de conservation ;
- groupes d’équipements ;
- sites ;
- profils d’utilisateurs ;
- formats de rapport.
```
### 15.4 Validation des configurations
**Exemples :**
```text
SRV-CFG-001 — L’application doit vérifier la validité des paramètres modifiés avant application.
SRV-CFG-002 — Une configuration invalide doit être refusée avec un message explicite.
SRV-CFG-003 — Toute modification de configuration critique doit être journalisée.
SRV-CFG-004 — Les configurations doivent être exportables ou sauvegardables si elles sont nécessaires à la reprise.
```
### 15.5 Versionnement des configurations
Cette partie décrit la traçabilité.
**Exemples :**
```text
- version de configuration ;
- date de modification ;
- auteur ;
- commentaire ;
- ancienne valeur ;
- nouvelle valeur ;
- équipement concerné ;
- statut : brouillon, validée, appliquée, retirée.
```
### 15.6 Tests associés
**Exemples :**
```text
- modification paramètre valide ;
- modification paramètre invalide ;
- modification paramètre critique ;
- journalisation configuration ;
- export configuration ;
- restauration configuration ;
- application configuration à équipement ;
- divergence configuration attendue / déclarée.
```
---
## 16. Exigences de reporting et d’exports
### 16.1 Objet des rapports et exports
Cette partie décrit les fonctions permettant de produire des documents, fichiers ou extractions de données.
Les exports peuvent servir à l’exploitation, au diagnostic, à l’audit, à la maintenance, au partage client ou à l’intégration avec un autre système.
### 16.2 Types d’exports
**Exemples :**
```text
- export mesures ;
- export alarmes ;
- export événements ;
- export logs ;
- export configuration ;
- export rapport diagnostic ;
- export rapport mensuel ;
- export CSV ;
- export JSON ;
- export PDF ;
- export fichier compressé.
```
### 16.3 Filtres d’export
**Exemples :**
```text
- période ;
- équipement ;
- site ;
- type de donnée ;
- criticité ;
- statut ;
- utilisateur ;
- événement ;
- mode ;
- configuration.
```
### 16.4 Traçabilité des exports
**Exemples :**
```text
SRV-EXP-001 — Les exports contenant des données sensibles ou critiques doivent être journalisés.
SRV-EXP-002 — Le journal d’export doit indiquer l’utilisateur, la date, le type d’export, les filtres utilisés et le résultat.
SRV-EXP-003 — Les exports temporaires doivent être supprimés selon une durée définie si nécessaire.
```
### 16.5 Rapports automatiques
Cette partie décrit les rapports planifiés.
**Exemples :**
```text
- rapport journalier d’alarmes ;
- rapport hebdomadaire d’équipements non joignables ;
- rapport mensuel d’exploitation ;
- rapport de maintenance ;
- rapport de disponibilité ;
- rapport de sauvegarde ;
- rapport d’incident.
```
### 16.6 Tests associés
**Exemples :**
```text
- export CSV mesures ;
- export alarmes filtrées ;
- export période vide ;
- export volumineux ;
- génération rapport PDF ;
- journalisation export ;
- suppression export temporaire ;
- droits insuffisants pour export.
```
---
## 17. Exigences de supervision applicative
### 17.1 Objet de la supervision applicative
Cette partie décrit comment l’application surveille son propre état et rend visibles les problèmes applicatifs.
La supervision applicative complète la supervision infrastructure. Elle concerne les services applicatifs, les files de traitement, les erreurs de réception, les retards de données, les équipements non joignables, les erreurs d’API, les échecs d’intégration et les problèmes fonctionnels.
### 17.2 Indicateurs de santé applicative
**Exemples :**
```text
- service applicatif disponible ;
- API accessible ;
- base de données accessible ;
- nombre d’équipements connectés ;
- nombre d’équipements non joignables ;
- taux d’erreurs de messages ;
- taille des files d’attente ;
- âge du dernier message reçu ;
- nombre d’alarmes actives ;
- temps de réponse API ;
- erreur de sauvegarde applicative ;
- échec de notification ;
- erreur système tiers.
```
### 17.3 Healthcheck applicatif
**Exemples :**
```text
SRV-SUP-001 — L’application doit fournir un mécanisme permettant de vérifier son état de fonctionnement.
SRV-SUP-002 — Le healthcheck doit vérifier au minimum la disponibilité de l’application et de ses dépendances critiques.
SRV-SUP-003 — Le résultat du healthcheck doit être exploitable par la supervision infrastructure si cette intégration est prévue.
```
### 17.4 Alertes applicatives
**Exemples :**
```text
SRV-SUP-ALM-001 — L’application doit générer une alerte si un nombre anormal d’équipements devient non joignable.
SRV-SUP-ALM-002 — L’application doit générer une alerte si le taux de messages rejetés dépasse un seuil défini.
SRV-SUP-ALM-003 — L’application doit générer une alerte si une file de traitement dépasse un seuil défini.
```
### 17.5 Tableau de supervision
Cette partie décrit l’IHM ou la vue de supervision.
**Exemples :**
```text
- état services ;
- état base de données ;
- état équipements ;
- erreurs récentes ;
- files d’attente ;
- sauvegardes applicatives ;
- temps de réponse ;
- version applicative ;
- espace disque applicatif si remonté ;
- connectivité système tiers.
```
### 17.6 Tests associés
**Exemples :**
```text
- healthcheck nominal ;
- base indisponible ;
- API indisponible ;
- équipement non joignable ;
- message rejeté ;
- file saturée ;
- alerte supervision ;
- retour au nominal ;
- intégration supervision infrastructure.
```
---
## 18. Exigences de journalisation applicative
### 18.1 Objet des logs applicatifs
Cette partie décrit les logs produits par l’application.
Les journaux applicatifs servent à comprendre les traitements réalisés, diagnostiquer les erreurs, tracer les actions sensibles, analyser les incidents et fournir des éléments d’audit.
### 18.2 Types de logs
**Exemples :**
```text
- logs de réception ;
- logs de validation de messages ;
- logs d’erreur ;
- logs de sécurité ;
- logs d’authentification ;
- logs d’administration ;
- logs de configuration ;
- logs d’export ;
- logs d’alarme ;
- logs de sauvegarde applicative ;
- logs de communication système tiers.
```
### 18.3 Contenu minimal d’un log
**Exemple :**
```text
- date et heure ;
- niveau ;
- source ;
- utilisateur si applicable ;
- équipement si applicable ;
- action ;
- résultat ;
- message d’erreur ;
- identifiant de corrélation ;
- adresse IP si nécessaire ;
- version applicative si utile.
```
### 18.4 Niveaux de logs
**Exemples :**
```text
DEBUG :
détail technique utile au diagnostic avancé.
INFO :
événement normal significatif.
WARNING :
situation anormale non bloquante.
ERROR :
erreur applicative ou technique.
CRITICAL :
erreur grave affectant une fonction critique.
```
### 18.5 Protection des logs
**Exemples :**
```text
SRV-LOG-SEC-001 — Les logs ne doivent pas contenir de mots de passe, secrets ou jetons sensibles en clair.
SRV-LOG-SEC-002 — Les logs de sécurité doivent être consultables uniquement par des profils habilités.
SRV-LOG-SEC-003 — Les logs critiques doivent être conservés selon la politique définie.
```
### 18.6 Rotation et conservation
**Exemples :**
```text
SRV-LOG-ROT-001 — Les logs applicatifs doivent être soumis à une rotation afin d’éviter la saturation du stockage.
SRV-LOG-ROT-002 — Les durées de conservation des logs doivent être définies selon leur criticité.
SRV-LOG-ROT-003 — Les logs nécessaires à un incident ouvert doivent pouvoir être conservés jusqu’à clôture de l’analyse.
```
### 18.7 Tests associés
**Exemples :**
```text
- log réception message ;
- log erreur message ;
- log connexion utilisateur ;
- log action admin ;
- log export ;
- absence secret dans logs ;
- rotation logs ;
- consultation logs par profil autorisé ;
- refus consultation profil non autorisé.
```
---
## 19. Exigences de sécurité applicative et cybersécurité
### 19.1 Objet de la sécurité applicative
Cette partie décrit les exigences de protection de l’application contre les accès non autorisés, modifications non maîtrisées, erreurs d’usage, données invalides, fuite d’information ou compromission.
### 19.2 Contrôle d’accès
**Exemples :**
```text
SRV-SEC-ACC-001 — L’application doit contrôler l’accès aux fonctions selon le profil utilisateur.
SRV-SEC-ACC-002 — Une action non autorisée doit être refusée.
SRV-SEC-ACC-003 — Les actions sensibles doivent être journalisées.
SRV-SEC-ACC-004 — Les fonctions d’administration doivent être réservées aux administrateurs habilités.
```
### 19.3 Protection des données sensibles
Cette partie décrit les données nécessitant une protection particulière.
**Exemples :**
```text
- identifiants utilisateurs ;
- mots de passe ;
- jetons de session ;
- clés API ;
- configurations sensibles ;
- certificats ;
- logs de sécurité ;
- données personnelles ;
- exports contenant des données sensibles ;
- commandes critiques.
```
### 19.4 Validation des entrées utilisateur
Cette partie décrit les contrôles à appliquer aux saisies IHM ou API.
**Exemples :**
```text
SRV-SEC-IN-001 — L’application doit valider les données saisies par les utilisateurs avant traitement.
SRV-SEC-IN-002 — L’application doit refuser les valeurs incohérentes ou hors limites.
SRV-SEC-IN-003 — Une saisie invalide doit donner lieu à un message compréhensible sans exposer d’information sensible.
```
### 19.5 Protection contre les actions dangereuses
Cette partie décrit les confirmations ou verrous.
**Exemples :**
```text
- confirmation avant modification configuration critique ;
- confirmation avant désactivation équipement ;
- confirmation avant restauration ;
- confirmation avant commande distante ;
- interdiction si équipement en mode incompatible ;
- journalisation obligatoire.
```
### 19.6 Sécurité des API
**Exemples :**
```text
SRV-SEC-API-001 — Les API non publiques doivent exiger une authentification.
SRV-SEC-API-002 — Les API doivent vérifier les droits de l’utilisateur ou du composant appelant.
SRV-SEC-API-003 — Les erreurs API ne doivent pas exposer de détails internes sensibles.
SRV-SEC-API-004 — Les appels répétés anormaux doivent être journalisés ou limités si nécessaire.
```
### 19.7 Tests associés
**Exemples :**
```text
- accès sans authentification ;
- accès avec rôle insuffisant ;
- modification configuration interdite ;
- commande critique confirmée ;
- injection donnée invalide ;
- message API mal formé ;
- absence secret dans erreur ;
- session expirée ;
- export refusé utilisateur non habilité.
```
---
## 20. Exigences de sauvegarde et restauration applicative
### 20.1 Objet de la sauvegarde applicative
Cette partie précise les exigences applicatives relatives à la sauvegarde.
Le détail technique est dans le dossier infrastructure, mais la spécification serveur doit indiquer quelles données applicatives sont critiques et doivent être sauvegardables.
### 20.2 Données applicatives à sauvegarder
**Exemples :**
```text
- base de données ;
- configurations applicatives ;
- configurations équipements ;
- utilisateurs et rôles ;
- historiques critiques ;
- alarmes ;
- événements ;
- rapports nécessaires ;
- fichiers d’export conservés ;
- paramètres d’intégration ;
- modèles de rapports.
```
### 20.3 Cohérence applicative de la sauvegarde
**Exemples :**
```text
SRV-BKP-001 — Les sauvegardes applicatives doivent permettre de restaurer un état cohérent de l’application.
SRV-BKP-002 — Les configurations et données associées doivent être sauvegardées de manière cohérente.
SRV-BKP-003 — Une sauvegarde réalisée avant mise à jour doit permettre un retour arrière si cette exigence est retenue.
```
### 20.4 Restauration applicative
Cette partie décrit le comportement attendu après restauration.
**Exemples :**
```text
SRV-REST-001 — Après restauration, l’application doit pouvoir redémarrer sans erreur critique.
SRV-REST-002 — Après restauration, les utilisateurs autorisés doivent pouvoir se connecter.
SRV-REST-003 — Après restauration, les équipements doivent pouvoir reprendre la transmission des données.
SRV-REST-004 — Après restauration, la cohérence des alarmes actives et historiques doit être vérifiable.
```
### 20.5 Tests associés
**Exemples :**
```text
- sauvegarde base ;
- sauvegarde configuration ;
- restauration base sur environnement de test ;
- connexion après restauration ;
- réception message après restauration ;
- cohérence alarmes après restauration ;
- restauration avant/après mise à jour ;
- rapport de restauration.
```
---
## 21. Exigences de performance applicative
### 21.1 Objet des performances
Cette partie décrit les exigences de temps de réponse, capacité, volumétrie et montée en charge.
Les performances doivent être formulées de manière mesurable.
### 21.2 Nombre d’équipements supportés
**Exemples :**
```text
SRV-PERF-EQP-001 — L’application doit supporter le nombre d’équipements actifs défini dans les hypothèses de dimensionnement.
SRV-PERF-EQP-002 — L’application doit rester exploitable lorsque tous les équipements transmettent selon la fréquence nominale.
SRV-PERF-EQP-003 — Une marge de croissance doit être prévue si elle est définie dans le projet.
```
### 21.3 Volume de données
**Exemples :**
```text
- nombre de messages par minute ;
- taille moyenne des messages ;
- volume journalier ;
- volume annuel ;
- nombre d’alarmes ;
- nombre d’événements ;
- nombre d’utilisateurs simultanés ;
- nombre de requêtes IHM.
```
### 21.4 Temps de réponse IHM
**Exemples :**
```text
SRV-PERF-IHM-001 — L’affichage du tableau de bord doit être réalisé dans un délai compatible avec l’exploitation.
SRV-PERF-IHM-002 — La consultation des alarmes actives doit rester rapide même avec le volume d’alarmes prévu.
SRV-PERF-IHM-003 — Les requêtes historiques longues doivent être paginées ou limitées afin de préserver la disponibilité de l’application.
```
### 21.5 Temps de traitement serveur
**Exemples :**
```text
SRV-PERF-TRT-001 — Le serveur doit traiter les messages entrants sans accumulation durable dans les conditions nominales.
SRV-PERF-TRT-002 — En cas de pic de messages, le serveur doit appliquer une stratégie définie : mise en file, limitation, rejet contrôlé ou alerte.
SRV-PERF-TRT-003 — Le traitement des alarmes critiques doit rester prioritaire si cette exigence est retenue.
```
### 21.6 Tests associés
**Exemples :**
```text
- test charge équipements ;
- test messages simultanés ;
- test consultation alarmes volumineuses ;
- test historique longue période ;
- test utilisateurs simultanés ;
- test pic d’alarmes ;
- test export volumineux ;
- test saturation contrôlée.
```
---
## 22. Exigences de robustesse et disponibilité applicative
### 22.1 Objet de la robustesse applicative
Cette partie décrit le comportement de l’application face aux erreurs, indisponibilités, données invalides, dépendances perdues ou incidents.
### 22.2 Indisponibilité base de données
**Exemples :**
```text
SRV-ROB-DB-001 — Le serveur doit détecter une indisponibilité de la base de données.
SRV-ROB-DB-002 — Le serveur doit signaler une erreur applicative critique si la base de données devient indisponible.
SRV-ROB-DB-003 — Le serveur ne doit pas afficher des données comme valides si leur lecture ou écriture a échoué.
```
### 22.3 Indisponibilité partielle d’un service
**Exemples :**
```text
- service de notification indisponible ;
- service d’authentification indisponible ;
- service d’export indisponible ;
- service de supervision indisponible ;
- système tiers non joignable.
```
### 22.4 Gestion des erreurs applicatives
**Exemples :**
```text
SRV-ROB-ERR-001 — Une erreur applicative doit être journalisée avec un niveau adapté.
SRV-ROB-ERR-002 — Une erreur interne ne doit pas exposer d’information sensible à l’utilisateur.
SRV-ROB-ERR-003 — L’application doit fournir un message utilisateur compréhensible en cas d’échec d’une action.
```
### 22.5 Reprise après redémarrage
**Exemples :**
```text
SRV-ROB-START-001 — Après redémarrage du serveur applicatif, l’application doit retrouver un état cohérent.
SRV-ROB-START-002 — Les équipements doivent pouvoir reprendre la communication après redémarrage du serveur.
SRV-ROB-START-003 — Les alarmes actives doivent rester cohérentes après redémarrage.
```
### 22.6 Tests associés
**Exemples :**
```text
- base indisponible ;
- base restaurée ;
- service applicatif redémarré ;
- API en erreur ;
- système tiers indisponible ;
- message utilisateur après erreur ;
- logs erreur ;
- reprise équipements après redémarrage.
```
---
## 23. Exigences d’interfaces systèmes tiers
### 23.1 Objet des interfaces systèmes tiers
Cette partie décrit les échanges avec des systèmes externes éventuels.
Ces interfaces peuvent concerner une supervision client, une GMAO, un ERP, un annuaire utilisateur, un outil de reporting, une plateforme cloud, un système d’alerte ou un outil de ticketing.
### 23.2 Liste des systèmes tiers
**Exemple :**
```text
Système tiers | Usage | Sens échange | Criticité | Responsable
Annuaire client | authentification | serveur ↔ annuaire | élevée | client IT
Supervision client | remontée état | serveur → supervision | moyenne | client IT
GMAO | création incident | serveur → GMAO | moyenne | exploitation
ERP | référentiel site | ERP → serveur | faible/moyenne | client
```
### 23.3 Données échangées
**Exemples :**
```text
- états équipements ;
- alarmes critiques ;
- rapports ;
- tickets d’incident ;
- utilisateurs ;
- sites ;
- configurations ;
- exports historiques ;
- notifications.
```
### 23.4 Gestion des erreurs d’interface
**Exemples :**
```text
SRV-TIERS-ERR-001 — Le serveur doit détecter une indisponibilité du système tiers si cette indisponibilité impacte une fonction prévue.
SRV-TIERS-ERR-002 — Une erreur d’échange avec un système tiers doit être journalisée.
SRV-TIERS-ERR-003 — Une indisponibilité d’un système tiers non critique ne doit pas bloquer les fonctions principales du système.
```
### 23.5 Tests associés
**Exemples :**
```text
- échange nominal ;
- système tiers indisponible ;
- réponse invalide ;
- timeout ;
- authentification refusée ;
- message rejeté ;
- reprise après retour système tiers ;
- journalisation erreur interface.
```
---
## 24. Exigences de testabilité serveur / application
### 24.1 Objet de la testabilité
Cette partie décrit les exigences permettant de tester efficacement l’application.
La testabilité doit permettre les tests unitaires, tests API, tests IHM, tests base de données, tests d’intégration équipement/serveur, tests de performance, tests de sécurité et tests de non-régression.
### 24.2 Observabilité
**Exemples :**
```text
- logs ;
- healthcheck ;
- métriques ;
- compteurs messages ;
- compteurs erreurs ;
- état équipements ;
- état files d’attente ;
- état base de données ;
- version applicative ;
- état des dépendances ;
- traces de corrélation.
```
**Exemple d’exigence :**
```text
SRV-TEST-OBS-001 — L’application doit fournir les informations nécessaires au diagnostic des tests d’intégration.
```
### 24.3 Données de test
Cette partie décrit les données nécessaires.
**Exemples :**
```text
- équipements fictifs ;
- mesures nominales ;
- mesures hors plage ;
- alarmes critiques ;
- utilisateurs de test ;
- rôles de test ;
- configurations de test ;
- données historiques ;
- messages invalides ;
- exports attendus.
```
### 24.4 Simulateurs
Cette partie décrit les simulateurs utiles.
**Exemples :**
```text
- simulateur d’équipement ;
- simulateur de perte réseau ;
- simulateur de messages invalides ;
- simulateur de charge ;
- simulateur système tiers ;
- simulateur annuaire ;
- générateur d’alarmes.
```
### 24.5 Tests unitaires applicatifs
**Exemples :**
```text
- validation message ;
- traitement alarme ;
- filtrage historique ;
- droits utilisateur ;
- création équipement ;
- règle anti-doublon ;
- export ;
- pagination ;
- conversion de données ;
- calcul d’état global.
```
### 24.6 Tests d’intégration
**Exemples :**
```text
- équipement vers serveur ;
- serveur vers base ;
- serveur vers IHM ;
- serveur vers supervision ;
- serveur vers sauvegarde ;
- serveur vers système tiers ;
- authentification ;
- API ;
- resynchronisation après coupure.
```
### 24.7 Tests de non-régression
**Exemples :**
```text
SRV-TEST-NR-001 — Toute nouvelle version applicative doit permettre l’exécution d’un jeu de tests de non-régression.
SRV-TEST-NR-002 — Les fonctions critiques doivent faire partie du jeu de non-régression.
SRV-TEST-NR-003 — Les tests de non-régression doivent être associés à la version applicative testée.
```
### 24.8 Tests associés
**Exemples :**
```text
- tests API ;
- tests IHM ;
- tests base ;
- tests droits ;
- tests alarmes ;
- tests historique ;
- tests export ;
- tests performance ;
- tests sécurité ;
- tests supervision ;
- tests non-régression.
```
---
## 25. Exigences de configuration, versionnement et livraison applicative
### 25.1 Objet de la gestion de configuration applicative
Cette partie décrit comment identifier et livrer une version serveur.
### 25.2 Identification de version
**Exemples :**
```text
SRV-VER-001 — L’application doit exposer sa version applicative.
SRV-VER-002 — L’application doit permettre d’identifier la version de base de données ou de schéma utilisée.
SRV-VER-003 — L’application doit permettre d’identifier la version de configuration active.
SRV-VER-004 — Les versions doivent être visibles dans une interface d’administration ou un endpoint technique.
```
### 25.3 Compatibilité serveur / firmware
Cette partie est importante pour les systèmes avec équipements embarqués.
**Exemples :**
```text
SRV-VER-COMP-001 — La compatibilité entre version serveur et version firmware doit être documentée.
SRV-VER-COMP-002 — Le serveur doit gérer ou signaler les équipements utilisant une version firmware non supportée.
SRV-VER-COMP-003 — Une évolution incompatible du format de message doit être explicitement versionnée.
```
### 25.4 Livraison applicative
Cette partie décrit les éléments livrés.
**Exemples :**
```text
- paquet applicatif ;
- image conteneur si applicable ;
- scripts d’installation ;
- scripts de migration base ;
- fichiers de configuration ;
- documentation d’installation ;
- note de version ;
- liste des anomalies corrigées ;
- liste des anomalies connues ;
- résultats de tests ;
- procédure de retour arrière.
```
### 25.5 Note de version
**Modèle :**
```text
Version :
Date :
Compatibilité firmware :
Compatibilité base de données :
Nouvelles fonctions :
Corrections :
Évolutions API :
Évolutions base :
Anomalies connues :
Procédure de mise à jour :
Procédure de retour arrière :
Tests réalisés :
Restrictions :
```
### 25.6 Tests associés
**Exemples :**
```text
- affichage version ;
- compatibilité firmware ;
- migration base ;
- installation version ;
- rollback ;
- vérification note de version ;
- mise à jour configuration ;
- tests post-déploiement.
```
---
## 26. Traçabilité
### 26.1 Traçabilité avec la spécification globale
Cette partie relie les exigences serveur aux exigences système.
**Exemple :**
```text
Exigence système :
SYS-ALM-002 — Le système doit afficher les alarmes actives avec leur niveau de criticité.
Exigences serveur associées :
SRV-ALM-001 — Création et conservation des alarmes.
SRV-IHM-ALM-001 — Affichage des alarmes actives.
SRV-ALM-ACK-001 — Acquittement par utilisateur habilité.
SRV-HIST-EVT-001 — Historisation des événements associés.
```
### 26.2 Traçabilité avec l’architecture système
Cette partie relie les exigences aux blocs d’architecture.
**Exemple :**
```text
Bloc architecture :
SS-SRV-001 — serveur applicatif
SS-DB-001 — base de données
SS-IHM-001 — interface opérateur
Exigences associées :
SRV-REC-001, SRV-ALM-001, SRV-HIST-001, SRV-IHM-001, SRV-DB-001.
```
### 26.3 Traçabilité avec le firmware embarqué
Cette partie relie les exigences serveur aux exigences firmware.
**Exemple :**
```text
Firmware :
SW-COM-SYNC-001 — retransmettre les messages non acquittés.
Serveur :
SRV-REC-DUP-001 — détecter ou gérer les doublons.
SRV-REC-LATE-001 — accepter les données retransmises.
SRV-HIST-MES-003 — conserver l’horodatage d’origine.
```
### 26.4 Traçabilité vers les tests
Cette partie relie les exigences aux tests.
**Exemple :**
```text
SRV-REC-001 — Réception messages équipements
Tests associés :
TEST-SRV-REC-001 — réception mesure nominale.
TEST-INT-EQP-SRV-001 — transmission équipement réel vers serveur.
TEST-SYS-COM-001 — affichage donnée reçue dans IHM.
```
### 26.5 Matrice de traçabilité serveur
**Structure recommandée :**
```text
ID exigence serveur
Exigence système source
Interface concernée
Composant applicatif
Donnée concernée
Test unitaire
Test intégration
Test système
Statut
Commentaire
```
---
## 27. Contraintes, risques et points ouverts
### 27.1 Contraintes techniques
Cette partie liste les contraintes connues.
**Exemples :**
```text
- base de données imposée ;
- infrastructure client imposée ;
- absence d’accès Internet ;
- protocole équipement imposé ;
- nombre élevé d’équipements ;
- volume de données important ;
- compatibilité navigateur ;
- politique de sécurité client ;
- intégration annuaire obligatoire ;
- conservation longue des historiques ;
- interface système tiers non stabilisée.
```
### 27.2 Risques applicatifs
Cette partie identifie les risques.
**Exemples :**
```text
- saturation base de données ;
- lenteur historique ;
- perte de données à la réception ;
- doublons après resynchronisation ;
- mauvaise gestion des droits ;
- alarmes non visibles ;
- API incompatible avec firmware ;
- migration base échouée ;
- export trop volumineux ;
- logs insuffisants pour diagnostic ;
- dépendance système tiers instable.
```
### 27.3 Mesures de réduction des risques
**Exemples :**
```text
- tests de charge ;
- pagination des historiques ;
- indexation base ;
- tests de resynchronisation ;
- versionnement API ;
- tests de droits ;
- supervision applicative ;
- logs de corrélation ;
- tests de migration ;
- sauvegarde avant mise à jour ;
- simulateur d’équipement ;
- revue cybersécurité.
```
### 27.4 Points ouverts
Cette partie liste les décisions à confirmer.
**Exemple :**
```text
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-SRV-001 | Protocole équipement | Confirmer format final des messages | Système / firmware / serveur | avant conception API | intégration | ouvert
PO-SRV-002 | Conservation données | Durée de conservation des mesures à confirmer | Client | avant conception DB | stockage/performance | ouvert
PO-SRV-003 | Authentification | Local ou annuaire client à confirmer | Client IT | avant conception sécurité | utilisateurs | ouvert
PO-SRV-004 | Exports | Formats CSV/PDF/JSON à arbitrer | Client / exploitation | avant IHM | reporting | ouvert
PO-SRV-005 | Système tiers | Interface GMAO à confirmer | Client | avant spéc. interfaces | intégration externe | ouvert
```
---
## 28. Critères d’acceptation de la spécification serveur / application
### 28.1 Complétude
Cette partie définit les critères permettant de considérer la spécification comme complète.
**Exemples :**
```text
La spécification serveur / application est considérée comme complète si :
- les fonctions de réception sont décrites ;
- les règles de validation des messages sont décrites ;
- la gestion des équipements est décrite ;
- la gestion des alarmes est décrite ;
- l’historisation est décrite ;
- les exigences base de données sont décrites ;
- les API principales sont identifiées ;
- l’IHM opérateur est décrite ;
- les fonctions d’administration sont décrites ;
- les utilisateurs et droits sont décrits ;
- les exports et rapports sont décrits ;
- la supervision applicative est décrite ;
- la journalisation est décrite ;
- la sécurité applicative est décrite ;
- les exigences de sauvegarde/restauration applicative sont décrites ;
- les exigences de performance sont décrites ;
- les exigences de testabilité sont décrites ;
- les exigences critiques sont reliées à des tests.
```
### 28.2 Cohérence
Cette partie définit les critères de cohérence.
**Exemples :**
```text
Le document ne doit pas contenir :
- de fonction serveur sans source d’exigence ;
- d’alarme sans cycle de vie défini ;
- de donnée historisée sans durée de conservation ;
- d’action critique sans contrôle de droit ;
- d’API non versionnée alors qu’elle est exposée à un composant externe ;
- de message reçu sans règle de validation ;
- d’historique sans règle de purge ou archivage ;
- de sauvegarde sans restauration vérifiable ;
- d’IHM affichant des données non définies ;
- d’exigence non testable.
```
### 28.3 Testabilité
Cette partie vérifie que la spécification permet de construire les tests.
**Exemples :**
```text
La spécification est testable si :
- chaque API peut être testée ;
- chaque règle d’alarme peut être vérifiée ;
- chaque rôle utilisateur peut être testé ;
- les flux équipement / serveur peuvent être simulés ;
- les erreurs de message peuvent être injectées ;
- les données historiques peuvent être vérifiées ;
- les exports peuvent être contrôlés ;
- la restauration applicative peut être validée ;
- la supervision applicative peut être déclenchée.
```
### 28.4 Exploitabilité
Cette partie vérifie que l’application sera exploitable par les utilisateurs.
**Exemples :**
```text
La spécification prend correctement en compte l’exploitation si :
- les états équipements sont visibles ;
- les alarmes critiques sont visibles et compréhensibles ;
- les historiques sont consultables ;
- les exports utiles sont prévus ;
- les droits sont adaptés aux profils ;
- les erreurs sont compréhensibles ;
- les logs permettent le diagnostic ;
- les fonctions d’administration sont maîtrisées.
```
### 28.5 Validation du document
Cette partie précise les revues nécessaires.
**Exemple :**
```text
La spécification serveur / application doit être relue par :
- le responsable applicatif ;
- l’ingénieur système ;
- le responsable firmware ;
- le responsable infrastructure ;
- le responsable base de données ;
- le responsable IHM ;
- le responsable cybersécurité ;
- le responsable validation ;
- le responsable exploitation ;
- le représentant client si l’IHM ou les fonctions d’exploitation sont contractuelles.
```
---
## 29. Annexes
### 29.1 Liste complète des exigences serveur
Cette annexe peut contenir la liste complète des exigences.
**Exemple :**
```text
ID | Catégorie | Libellé | Criticité | Vérification | Statut
SRV-REC-001 | réception | identifier équipement émetteur | élevée | test API | à faire
SRV-ALM-001 | alarme | créer alarme | élevée | test fonctionnel | à faire
SRV-IHM-ALM-001 | IHM | afficher alarmes actives | élevée | test IHM | à faire
SRV-AUTH-001 | sécurité | authentifier utilisateur | critique | test sécurité | à faire
SRV-HIST-MES-001 | historique | enregistrer mesures | élevée | test DB | à faire
```
### 29.2 Liste des messages équipements
Cette annexe liste les messages reçus ou envoyés aux équipements.
**Exemple :**
```text
Message | Sens | Usage | Criticité | Acquittement
MEASURE | équipement → serveur | transmission mesure | élevée | oui
ALARM | équipement → serveur | transmission alarme | élevée | oui
STATE | équipement → serveur | état équipement | moyenne | oui
CONFIG | serveur → équipement | configuration | élevée | oui
COMMAND | serveur → équipement | commande distante | critique | oui
```
### 29.3 Liste des écrans IHM
Cette annexe reprend les écrans prévus.
**Exemples :**
```text
- tableau de bord ;
- liste équipements ;
- fiche équipement ;
- alarmes actives ;
- historique alarmes ;
- historique mesures ;
- configuration ;
- utilisateurs ;
- administration ;
- supervision ;
- exports ;
- diagnostic.
```
### 29.4 Liste des rôles et droits
Cette annexe reprend la matrice complète des droits.
### 29.5 Liste des API
Cette annexe reprend les API identifiées, sans nécessairement détailler encore chaque endpoint.
### 29.6 Liste des données historisées
Cette annexe reprend les données conservées, leur source, leur durée et leur criticité.
### 29.7 Liste des alarmes serveur
Cette annexe décrit les alarmes générées par le serveur.
**Exemple :**
```text
ID alarme | Source | Condition | Criticité | Action attendue
SRV-ALM-COM-LOSS | serveur | équipement non joignable | majeure | vérifier communication
SRV-ALM-DB-DOWN | serveur | base indisponible | critique | intervention admin
SRV-ALM-MSG-REJECT | serveur | taux messages rejetés élevé | majeure | analyse protocole
SRV-ALM-BKP-FAIL | serveur | sauvegarde échouée | majeure | vérifier sauvegarde
```
### 29.8 Matrice exigences / tests
Cette annexe reprend la matrice de vérification.
### 29.9 Glossaire applicatif
Cette annexe définit les termes propres à l’application.
### 29.10 Historique des décisions applicatives
Cette annexe conserve les décisions structurantes.
**Exemple :**
```text
DEC-SRV-001 :
Les alarmes actives sont consolidées côté serveur afin d’éviter la multiplication d’alarmes identiques.
Justification :
améliorer la lisibilité opérateur et éviter la saturation de l’IHM.
Impact :
nécessite une règle anti-doublon, un modèle de cycle de vie d’alarme et des tests de consolidation.
```