Project

General

Profile

Actions
History

Canevas 7C — Spécification détaillée serveur application supervision » History » Revision 4

« Previous | Revision 4/5 (diff) | Next »
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.

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 :

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 :

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 :

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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

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 :

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 :

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 :

- 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 :

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 :

- 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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

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 :

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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

- 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 :

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 :

- 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 :

- 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 :

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 :

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 :

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 :

- connecté ;
- non joignable ;
- jamais connecté ;
- en retard de communication ;
- en maintenance ;
- désactivé ;
- état inconnu.

Exemple d’exigence :

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 :

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 :

- 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 :

- é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 :

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 :

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 :

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 :

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 :

- 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 :

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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

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 :

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 :

- 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 :

- 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 :

- é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 :

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 :

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 :

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 :

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 :

- 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 :

- 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 :

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 :

- 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 :

- 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 :

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 :

- erreur format ;
- authentification échouée ;
- autorisation insuffisante ;
- ressource inconnue ;
- conflit ;
- erreur serveur ;
- timeout ;
- service indisponible.

11.8 Tests associés

Exemples :

- 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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

- 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 :

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 :

- opérateur ;
- maintenance ;
- administrateur ;
- superviseur ;
- lecture seule ;
- support technique.

Exemples d’exigences :

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 :

- 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 :

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 :

- 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 :

- 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 :

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 :

- LDAP ;
- Active Directory ;
- SSO ;
- OAuth2 ;
- SAML ;
- OpenID Connect.

Exemple d’exigence :

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 :

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 :

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 :

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 :

- 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 :

- 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 :

- 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 :

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 :

- 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 :

- 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 :

- 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 :

- période ;
- équipement ;
- site ;
- type de donnée ;
- criticité ;
- statut ;
- utilisateur ;
- événement ;
- mode ;
- configuration.

16.4 Traçabilité des exports

Exemples :

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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

- é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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

- 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 :

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 :

- 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 :

- 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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

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 :

- 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 :

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 :

- états équipements ;
- alarmes critiques ;
- rapports ;
- tickets d’incident ;
- utilisateurs ;
- sites ;
- configurations ;
- exports historiques ;
- notifications.

23.4 Gestion des erreurs d’interface

Exemples :

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 :

- é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 :

- 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 :

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 :

- é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 :

- 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 :

- 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 :

- é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 :

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 :

- 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 :

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 :

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 :

- 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 :

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 :

- 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 :

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 :

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 :

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 :

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 :

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 :

- 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 :

- 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 :

- 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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

- 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 :

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 :

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.

Updated by Redmine Admin 3 months ago · 5 revisions