CANEVAS DES DOCUMENTS DU PROJET

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