Project

General

Profile

Wiki » History » Version 72

Antoine K, 07/22/2026 03:00 PM

1 1 Redmine Admin
Spécification PAXWARE
2
Cahier des charges / Expression du besoin
3
4
5
6
PAXWARE a pour objectif de fournir aux exploitants offshore une vision locale, fiable et exploitable de la présence du personnel par installation, afin d’améliorer les opérations quotidiennes, les transferts, les exercices de sécurité et la gestion des situations d’urgence, tout en conservant une architecture autonome et adaptée aux environnements isolés.
7 2 Antoine K
#  1. Objet du document
8
## 1.1 Finalité du cahier des charges
9 1 Redmine Admin
Le présent document a pour objectif de formaliser l’expression du besoin opérationnel auquel doit répondre l’écosystème PAXWARE.
10
PAXWARE vise à répondre à une problématique critique rencontrée sur les installations offshore, les sites industriels isolés et les environnements multi-zones : disposer d’une information fiable, locale et exploitable permettant de savoir qui est où, à un instant donné, sans dépendre exclusivement de procédures manuelles, déclaratives ou de systèmes connectés à internet.
11
Ce cahier des charges exprime les besoins fonctionnels, opérationnels, techniques, humains et organisationnels attendus du système. Il ne constitue pas encore une spécification détaillée de conception. Il ne fige donc pas définitivement les choix technologiques, électroniques, logiciels ou industriels.
12
Les choix d’architecture, les spécifications système, les spécifications détaillées hardware, software, serveur et interfaces feront l’objet de documents complémentaires dans les phases suivantes du cycle en V.
13
Le document doit permettre de :
14 2 Antoine K
* •	décrire le contexte opérationnel du projet ;
15
* •	identifier les limites des méthodes actuelles ;
16
* •	préciser les objectifs attendus du système PAXWARE ;
17
* •	définir le périmètre fonctionnel initial ;
18
* •	identifier les utilisateurs et acteurs concernés ;
19
* •	exprimer les contraintes principales d’exploitation ;
20
* •	préparer les futures spécifications système ;
21
* •	servir de base aux critères de validation client et au cahier de recette.
22 21 Antoine K
23 2 Antoine K
## 1.2 Positionnement dans le cycle en V
24 1 Redmine Admin
Ce cahier des charges constitue le document d’entrée principal de la phase amont du projet PAXWARE.
25
Il se situe au sommet gauche du cycle en V et sert de référence pour construire les documents suivants :
26 21 Antoine K
```
27
•	spécification globale du système ;
28
•	spécifications détaillées hardware ;
29
•	spécifications détaillées software embarqué ;
30
•	spécifications détaillées serveur, application et supervision ;
31
•	spécifications détaillées des interfaces ;
32
•	architecture système ;
33
•	plan d’intégration ;
34
•	plan de tests ;
35
•	cahier de recette ;
36
•	dossier de validation client ;
37
•	dossier de mise en exploitation.
38
```
39 2 Antoine K
Son rôle est de garantir que les développements futurs restent reliés à un besoin opérationnel réel, mesurable et vérifiable.
40 1 Redmine Admin
Dans le cadre de PAXWARE, ce document permet également de tracer la continuité entre :
41
le problème terrain constaté → le besoin opérationnel → les fonctions attendues → la conception technique → les tests → la validation client.
42
Note de méthode : le présent document initie la traçabilité du projet. Les exigences numérotées seront créées à partir de la partie 5 — Fonctions attendues, puis reliées aux acteurs, aux spécifications, aux tests et aux critères de validation. Les seuils de performance ajoutés dans cette version sont des valeurs cibles de cadrage pour MVP/POC et devront être confirmés par essais terrain, analyses de risque et choix technologiques définitifs.
43 21 Antoine K
44 2 Antoine K
## 1.3 Responsabilité de rédaction et de validation
45 1 Redmine Admin
Dans cette phase initiale, le cahier des charges est rédigé par le porteur du projet PAXWARE, sur la base :
46 22 Antoine K
```
47 1 Redmine Admin
•	de l’expérience opérationnelle terrain acquise en environnement offshore ;
48
•	de l’analyse des méthodes actuellement utilisées pour le suivi du personnel ;
49
•	des échanges avec des acteurs du secteur offshore, maritime, industriel et sécurité ;
50
•	des besoins identifiés auprès de futurs utilisateurs potentiels ;
51
•	des contraintes spécifiques aux installations isolées, multi-zones ou à connectivité limitée.
52 22 Antoine K
```
53 1 Redmine Admin
La validation finale du document pourra être réalisée progressivement avec les parties prenantes concernées.
54 22 Antoine K
```
55 1 Redmine Admin
Rôle	Responsabilité
56
Porteur du projet PAXWARE	Rédaction initiale, expression du besoin, cohérence métier
57
Utilisateurs terrain / exploitation	Relecture des besoins opérationnels
58
Référents sécurité / HSE	Relecture des besoins liés au muster, à l’urgence et à la sûreté
59
Partenaires techniques	Vérification de la faisabilité générale
60
Client pilote éventuel	Validation du besoin et des critères de recette
61
Direction projet PAXWARE	Approbation de la version de référence
62 22 Antoine K
```
63 1 Redmine Admin
64
Ce document pourra évoluer au fil du projet. Chaque évolution significative devra être tracée afin de conserver une cohérence entre le besoin initial, les spécifications et les choix techniques réalisés ensuite.
65 22 Antoine K
66 2 Antoine K
# 2. Contexte général du projet
67 23 Antoine K
68 2 Antoine K
## 2.1 Présentation du contexte
69 1 Redmine Admin
Les installations offshore, les barges d’habitation, les plateformes pétrolières, les navires de support et les sites industriels isolés sont des environnements où la connaissance de la présence du personnel est un sujet essentiel.
70
Dans ces contextes, les équipes doivent pouvoir répondre rapidement à une question simple mais critique :
71 24 Antoine K
**Qui est où ?**
72
Cette information est nécessaire en exploitation normale, lors des transferts entre installations, pendant les exercices de sécurité, en cas d’incident, d’évacuation, d’alarme générale ou de situation dégradée.
73 1 Redmine Admin
Aujourd’hui, sur de nombreux sites offshore, cette connaissance repose encore sur des procédures manuelles ou semi-manuelles, telles que :
74
75
76 23 Antoine K
```
77 1 Redmine Admin
•	cartes papier de présence ;
78
•	Ti-cards ;
79
•	registres manuels ;
80
•	déclarations radio ;
81
•	appels téléphoniques ;
82
•	pointages ponctuels ;
83
•	fichiers Excel ;
84
•	échanges entre départements ;
85
•	contrôles visuels ou verbaux.
86 23 Antoine K
```
87 1 Redmine Admin
Ces méthodes peuvent fonctionner dans un cadre quotidien parfaitement maîtrisé, et de la bonne responsabilité de chacun,  mais elles présentent des limites dès que la situation devient complexe, rapide ou critique.
88
Les environnements offshore imposent en effet plusieurs contraintes fortes :
89 23 Antoine K
```
90 1 Redmine Admin
•	personnel nombreux et mouvant ;
91
•	installations multiples ;
92
•	transferts réguliers entre barge, plateformes, navires ou zones techniques ;
93
•	réseau internet parfois limité ou indisponible ;
94
•	perturbations électromagnétiques et effets de cage de Faraday ;
95
•	conditions météo contraignantes : pluie, orages, vent, embruns et fortes chaleurs pouvant atteindre 70 °C sur surfaces exposées ;
96
•	urgence potentielle ;
97
•	nécessité de décisions rapides ;
98
•	exigences HSE élevées ;
99
•	obligation de traçabilité ;
100
•	contraintes de sûreté, de confidentialité et de continuité d’exploitation.
101 23 Antoine K
```
102 1 Redmine Admin
Le projet PAXWARE s’inscrit dans ce contexte. Il vise à proposer un écosystème autonome, local, non intrusif et adapté au terrain, permettant d’améliorer la connaissance de présence du personnel par installation ou zone opérationnelle.
103
L’objectif n’est pas de mettre en place un système de surveillance individuelle permanente, mais de fournir une information opérationnelle fiable sur la présence, l’absence, le transfert et la validation de présence en situation normale ou critique.
104 23 Antoine K
105 2 Antoine K
## 2.2 Situation actuelle
106 1 Redmine Admin
Sur de nombreuses installations offshore, le suivi du personnel repose encore sur des systèmes déclaratifs ou manuels. Le principe est généralement simple : lorsqu’une personne se déplace d’une installation à une autre, elle doit déplacer une carte de type papier, signaler son mouvement ou être enregistrée par un opérateur.
107
Dans la pratique, ces procédures peuvent générer plusieurs difficultés.
108
Premièrement, le système dépend fortement de la discipline individuelle. Si une personne oublie de déplacer sa carte, ne signale pas son départ ou si l’information est mal transmise, la situation affichée peut ne plus correspondre à la réalité terrain.
109
Deuxièmement, les informations sont souvent dispersées. Une partie peut se trouver dans un tableau, une autre dans une salle de contrôle, une autre auprès du personnel de sécurité, du deck, du camp boss ou du responsable HSE.
110
Troisièmement, les transferts entre installations peuvent être difficiles à suivre avec précision, notamment lorsqu’il existe plusieurs plateformes, plusieurs accès, des mouvements simultanés ou des changements rapides liés aux opérations.
111
Quatrièmement, les exercices de sécurité ou les situations d’urgence peuvent révéler des écarts entre la liste théorique des personnes attendues et la réalité du terrain. Dans ces situations, chaque minute compte. Une incertitude sur la localisation d’une personne peut générer une perte de temps, une mobilisation inutile ou une prise de décision plus difficile.
112
Cinquièmement, les méthodes actuelles ne fournissent pas toujours une traçabilité exploitable après événement. Il peut être difficile de reconstituer précisément les mouvements, les écarts, les délais ou les anomalies observées.
113
Les limites principales de la situation actuelle peuvent donc être résumées ainsi :
114
Limite constatée	Conséquence opérationnelle
115
Dépendance aux procédures manuelles	Risque d’oubli, pertes, et confusion 
116
Données non mises à jour en temps réel	Vision terrain potentiellement fausse
117
Informations dispersées	Difficulté à consolider rapidement la situation
118
Absence de preuve automatique de passage	Incertitude sur les transferts réels
119
Gestion manuelle du muster	Perte de temps lors des exercices ou urgences
120
Faible traçabilité des événements	Analyse après incident plus difficile
121
Dépendance à certains moyens de communication	Fragilité en mode dégradé
122
Peu d’autonomie en cas de perte réseau	Risque de rupture d’information
123
PAXWARE est né de ce constat terrain : dans un environnement offshore, la capacité à connaître rapidement la présence réelle du personnel par installation ne doit pas dépendre uniquement d’un système papier ou d’une déclaration humaine.
124 25 Antoine K
125 2 Antoine K
## 2.3 Objectifs du projet
126 25 Antoine K
127 1 Redmine Admin
L’objectif général du projet PAXWARE est de concevoir et déployer un écosystème permettant d’améliorer la connaissance de présence du personnel sur des sites offshore ou industriels isolés.
128
Le système attendu devra permettre de répondre à la question :
129
Combien de personnes sont présentes sur chaque installation, le nombre de personnes doit être identique à celui attendu lors des exercices muster-point ou en cas d’urgence réelle ?
130 25 Antoine K
```
131 1 Redmine Admin
Objectif	Description
132
Améliorer la connaissance de présence	Fournir une vision claire du nombre de personnes présentes par installation, zone ou navire
133
Réduire la dépendance au papier	Limiter les erreurs liées aux Ti-cards, registres et déclarations manuelles
134
Fonctionner localement	Assurer le fonctionnement du système même sans connexion internet permanente
135
Faciliter les transferts	Détecter ou consolider les mouvements entre installations ou zones
136
Améliorer le muster	Accélérer et fiabiliser la confirmation de présence lors des exercices ou urgences
137
Fournir une information exploitable	Mettre à disposition des opérateurs une lecture claire, simple et rapide
138
Assurer la traçabilité	Enregistrer les événements utiles à l’analyse, au contrôle et à l’amélioration continue
139
Préserver la confidentialité	Limiter les données exposées et privilégier une architecture locale/pseudonymisée
140
Préparer la validation client	Définir des critères mesurables permettant de tester la solution sur site pilote
141
S’adapter aux contraintes offshore	Prendre en compte l’environnement sévère, les pertes réseau, les opérations 24/7 et les exigences HSE
142 25 Antoine K
```
143 1 Redmine Admin
144
Le projet ne vise pas à remplacer les responsabilités humaines ni les procédures de sécurité existantes. Il vise à les renforcer en apportant une information complémentaire, plus rapide, plus fiable et plus exploitable.
145
PAXWARE doit donc être considéré comme un outil d’aide à l’exploitation, à la sécurité et à la décision, en particulier dans les situations où l’information de présence doit être consolidée rapidement.
146 25 Antoine K
147 2 Antoine K
# 3. Périmètre du système attendu
148 1 Redmine Admin
Le périmètre initial de PAXWARE couvre un écosystème local de connaissance de présence par installation, composé d’identifiants portés par le personnel, d’équipements de détection terrain, d’une unité centrale locale, d’écrans d’affichage, d’outils de muster-point et d’une interface de supervision, avec une priorité donnée au fonctionnement autonome sans dépendance permanente au cloud.
149 26 Antoine K
150 2 Antoine K
## 3.1 Périmètre fonctionnel
151 1 Redmine Admin
Le système PAXWARE a pour objectif de fournir une vision locale, fiable et exploitable de la présence du personnel sur un site offshore, une barge, une plateforme, un navire ou un ensemble d’installations connectées entre elles.
152
Le périmètre fonctionnel couvre principalement les fonctions suivantes :
153 26 Antoine K
```
154 1 Redmine Admin
Fonction attendue	Description
155
Identification de présence	Permettre d’associer une personne à un identifiant PAXWARE porté sur elle
156
Détection de passage	Identifier un mouvement d’entrée ou de sortie entre deux zones ou installations
157
Comptage par installation	Consolider le nombre de personnes présentes sur chaque installation
158
Affichage local	Afficher le nombre de personnes présentes via un écran local type PAX-SCREEN
159
Supervision locale	Permettre à un opérateur de consulter l’état du site depuis PAX-MANAGER
160
Gestion du muster-point	Permettre la confirmation de présence lors d’un exercice ou d’une situation d’urgence
161
Fonctionnement offline	Maintenir les fonctions critiques même sans connexion internet
162
Enregistrement des événements	Conserver localement les événements utiles : passage, présence, anomalie, validation des exercices muster-point
163
Synchronisation différée	Transmettre certaines données vers le cloud lorsque la connexion est disponible
164
Gestion des anomalies	Détecter et signaler les incohérences ou pertes d’équipement
165
Administration du système	Gérer les personnes, zones, installations, droits utilisateurs et équipements
166 26 Antoine K
```
167 1 Redmine Admin
168
Le système devra permettre à l’exploitation de répondre rapidement à des questions opérationnelles simples :
169 26 Antoine K
```
170 1 Redmine Admin
•	Combien de personnes sont présentes sur chaque installation ?
171
•	Qui doit être confirmé lors d’un muster-point ?
172
•	Une personne a-t-elle changé de zone ou d’installation ?
173
•	Le système fonctionne-t-il correctement ?
174
•	Des équipements sont-ils hors ligne ou en anomalie ?
175 26 Antoine K
```
176 1 Redmine Admin
À ce stade du projet, le périmètre fonctionnel reste centré sur la connaissance de présence par zone ou installation. PAXWARE ne doit pas être présenté comme un système de géolocalisation fine ou de surveillance permanente individuelle.
177 26 Antoine K
178 2 Antoine K
## 3.2 Périmètre matériel
179 1 Redmine Admin
Le système PAXWARE comprendra plusieurs éléments matériels complémentaires. Ces éléments formeront un écosystème local capable de fonctionner de manière autonome sur site.
180
Les principaux équipements prévus dans le périmètre initial sont les suivants :
181 27 Antoine K
```
182 1 Redmine Admin
Équipement	Rôle attendu
183
PAX-TAG	Bracelet ou identifiant porté par le personnel
184
PAX-ANT	Antenne de détection installée sur une zone de passage, une passerelle ou un accès
185
PAX-BOX	Unité centrale locale permettant le traitement, le stockage et l’exploitation des données
186
PAX-SCREEN	Écran local affichant le nombre de personnes présentes sur une installation ou une zone
187
PAX-MUSTER	Tablette ou terminal de validation utilisé lors des exercices ou situations d’urgence
188
PAX-NAV / PAX-SCREEN NAVIRE	Configuration spécifique associée à un navire, surfer, support vessel ou zone mobile
189
PAX-WRITING	Poste ou fonction logicielle permettant de préparer, encoder, associer ou contrôler les PAX-TAG
190 27 Antoine K
```
191 1 Redmine Admin
192 27 Antoine K
**PAX-TAG**
193 1 Redmine Admin
Le PAX-TAG est l’identifiant porté par le personnel. Il devra prendre la forme d’un bracelet, badge ou dispositif équivalent selon les contraintes d’usage et d’industrialisation.
194
Il devra permettre :
195
•	l’identification d’un utilisateur dans l’écosystème PAXWARE ;
196
•	la détection par les antennes PAX-ANT ;
197
•	une éventuelle lecture volontaire ou contrôlée en mode muster-point ;
198
•	une utilisation compatible avec les contraintes terrain offshore ;
199
•	une autonomie adaptée à une exploitation longue durée ;
200
•	une résistance suffisante à l’environnement d’utilisation.
201
À ce stade, le PAX-TAG est défini par son rôle fonctionnel. Les choix définitifs de composants, de boîtier et de certification seront précisés dans les spécifications détaillées hardware.
202 27 Antoine K
**PAX-ANT**
203 1 Redmine Admin
La PAX-ANT est l’équipement de détection installé sur les points de passage stratégiques.
204
Elle pourra être positionnée notamment :
205
•	sur une passerelle entre barge et plateforme ;
206
•	à l’entrée ou sortie d’une installation ;(boat landing)
207
•	à proximité d’un point de transfert ;
208
•	dans une zone où le comptage de passage est nécessaire.
209
•	Sur un helideck
210
211
Son rôle attendu est de détecter le passage d’un PAX-TAG et de transmettre l’événement à la PAX-BOX.
212
La PAX-ANT devra permettre, selon les choix techniques retenus :
213
•	la détection d’un identifiant PAX-TAG ;
214
•	la distinction entre entrée et sortie lorsque cela est nécessaire ;
215
•	l’horodatage ou la transmission d’un événement de passage ;
216
•	le fonctionnement en environnement industriel ou offshore ;
217
•	une alimentation et une connectivité compatibles avec l’installation du site.
218
Les choix définitifs concernant la technologie de détection, la portée, la précision, le filtrage, le sens de passage, l’alimentation, la connectique et la protection environnementale seront traités dans les documents de spécification détaillée.
219 27 Antoine K
**PAX-BOX**
220 1 Redmine Admin
La PAX-BOX est l’unité centrale locale du système PAXWARE. Elle constitue le cœur de l’écosystème sur site. Elle doit permettre au système de fonctionner même lorsque la connexion internet ou cloud n’est pas disponible.
221
Elle devra assurer principalement :
222
•	la réception des événements transmis par les équipements terrain ;
223
•	le traitement local des données ;
224
•	le stockage local des informations nécessaires à l’exploitation ;
225
•	la consolidation du nombre de personnes par installation ou zone ;
226
•	l’alimentation des interfaces locales ;
227
•	la gestion des droits utilisateurs ;
228
•	la supervision de l’état des équipements ;
229
•	la conservation des journaux techniques et opérationnels ;
230
•	la synchronisation différée avec un serveur distant lorsque cela est autorisé et disponible.
231
La PAX-BOX devra être conçue comme un élément robuste, autonome et adapté à une exploitation sur site isolé.
232 27 Antoine K
**PAX-SCREEN**
233 1 Redmine Admin
Le PAX-SCREEN est l’écran destiné à afficher une information simple, rapide et exploitable par les équipes terrain.
234
Son rôle principal est d’afficher le nombre de personnes présentes sur une installation, une zone ou un point opérationnel.
235
Exemples d’affichage :
236
•	nombre de personnes présentes sur une plateforme ;
237
•	nombre de personnes présentes sur une barge ;
238
•	nombre de personnes associées à un navire ;
239
•	état synthétique d’une zone ;
240
•	information utile en exploitation ou en situation d’urgence.
241
Le PAX-SCREEN devra être lisible, simple, robuste et compréhensible rapidement. Il ne devra pas nécessiter une formation complexe pour être utilisé.
242
Les caractéristiques définitives de l’écran, de l’alimentation, de la connectivité, de la fixation, de la lisibilité et de la résistance environnementale seront précisées dans les spécifications matérielles.
243 27 Antoine K
**PAX-MUSTER**
244 1 Redmine Admin
Le PAX-MUSTER est l’équipement ou l’application utilisé lors des exercices de sécurité, appels au rassemblement ou situations d’urgence.
245
Il devra permettre :
246
•	de lancer ou suivre une opération de muster ;
247
•	de consulter les personnes attendues ;
248
•	de confirmer la présence d’une personne ;
249
•	de signaler les personnes non confirmées ;
250
•	de fonctionner localement ;
251
•	de conserver les preuves de validation ;
252
•	de transmettre les résultats à la PAX-BOX ;
253
•	de produire une trace exploitable après exercice ou événement réel.
254
Le PAX-MUSTER devra être pensé comme un outil d’aide aux équipes HSE, sécurité, marine ou exploitation. Il ne remplace pas les procédures officielles de sécurité du site, mais vise à les renforcer.
255 27 Antoine K
**PAX-NAV / PAX-SCREEN NAVIRE**
256 1 Redmine Admin
Le PAX-NAV désigne l’équipement ou la balise associée à un navire, une embarcation, un surfer, un support vessel ou un moyen mobile. Il ne doit pas être confondu avec le PAX-SCREEN NAVIRE, qui correspond à un dispositif d’affichage embarqué destiné à fournir une information synthétique au pilote ou à l’équipage.
257
Son objectif est de permettre à l’écosystème PAXWARE de reconnaître ou d’associer une présence à un élément mobile du site.
258
Il pourra être utilisé pour :
259
•	identifier un navire à proximité ;
260
•	permettre au pilote de savoir à chaque instant combien de personnes sont présentes sur chaque installation ;
261
•	contribuer au suivi des mouvements entre installations ;
262
•	améliorer la lecture opérationnelle entre plateformes, barge et moyens nautiques.
263
Le besoin exact du PAX-NAV et du PAX-SCREEN NAVIRE devra être précisé selon les scénarios terrain du site pilote : identification du moyen mobile, affichage embarqué, liaison avec PAX-BOX et règles de mise à jour.
264 27 Antoine K
**PAX-WRITING**
265 1 Redmine Admin
Le PAX-WRITING est une fonction logicielle utilisable sur PC ou Android, associée à un lecteur adapté, permettant de préparer, encoder, associer ou contrôler les PAX-TAG.
266
Il pourra être utilisé par l’administrateur, le personnel HSE ou le personnel autorisé pour :
267
•	créer une association entre une personne et un identifiant PAXWARE à partir d’un manifeste ;
268
•	préparer un bracelet avant affectation ;
269
•	vérifier ou remplacer un PAX-TAG ;
270
•	désactiver un identifiant perdu, endommagé ou associé à une personne débarquant du site ;
271
•	assurer une traçabilité minimale des opérations d’encodage.
272
Le PAX-WRITING fait partie du périmètre logiciel et peut s’appuyer sur du matériel associé, tel qu’un lecteur de badge ou un dispositif d’encodage. Sa forme définitive pourra évoluer selon les choix techniques retenus.
273 27 Antoine K
274 2 Antoine K
## 3.3 Périmètre logiciel
275 1 Redmine Admin
Le système PAXWARE comprendra également un ensemble logiciel permettant l’exploitation, la supervision, l’administration, la traçabilité et la synchronisation des données.
276
Le périmètre logiciel initial comprend :
277 28 Antoine K
```
278 1 Redmine Admin
Module logiciel	Rôle attendu
279
PAX-MANAGER	Interface principale de gestion, supervision locale, affectations, rotations et présences planifiées selon le besoin client.
280
PAX-WRITING	Préparation, encodage, association, contrôle, remplacement et désactivation des PAX-TAG.
281
PAX-ROOM	Gestion des cabines, chambres ou hébergements
282
PAX-MUSTER	Suivi des personnes attendues, présentes, manquantes ou confirmées
283
ÉVÉNEMENT	Consultation des événements, historiques et journaux
284
Module Administration	Gestion des utilisateurs, droits, sites, zones et équipements
285
Module Supervision	État des antennes, écrans, PAX-TAG, PAX-BOX et communications
286
Module Synchronisation	Synchronisation différée vers un serveur distant ou cloud
287
Base locale	Stockage local des données nécessaires au fonctionnement du site
288 28 Antoine K
```
289
290 1 Redmine Admin
Le logiciel devra permettre une exploitation simple, lisible et adaptée à des utilisateurs opérationnels. Il ne devra pas nécessiter une expertise informatique avancée pour les fonctions courantes.
291
Fonctionnement local prioritaire, cloud secondaire.
292
Cela signifie que les fonctions critiques de présence, de muster et de consultation locale ne doivent pas dépendre d’une connexion internet permanente.
293 28 Antoine K
294 2 Antoine K
## 3.4 Hors périmètre
295 1 Redmine Admin
Cette partie évite de promettre trop tôt des fonctions qui ne sont pas encore nécessaires au MVP ou au POC.
296
Dans la version initiale du projet, les éléments suivants sont considérés comme hors périmètre, sauf demande spécifique du client ou évolution ultérieure du projet :
297 29 Antoine K
```
298 1 Redmine Admin
Hors périmètre initial	Précision
299
Géolocalisation précise permanente	PAXWARE ne vise pas à suivre chaque personne au mètre près en continu
300
Surveillance comportementale individuelle	Le système ne doit pas être présenté comme un outil de contrôle permanent des personnes
301
Remplacement des procédures HSE officielles	PAXWARE vient en appui, mais ne remplace pas les procédures du site
302
Fourniture du réseau complet du client	Le réseau site, internet, fibre, satellite ou 4G reste sous responsabilité client sauf contrat spécifique
303
Certification ATEX / IECEx complète dès MVP	Non exigée pour un démonstrateur hors zone classée. En revanche, les contraintes ATEX / IECEx doivent être prises en compte dès l’architecture pour toute version industrielle destinée à une zone offshore classée.
304
Gestion complète RH	PAXWARE ne remplace pas un logiciel RH ou paie
305
Gestion médicale du personnel	Les données médicales ne sont pas incluses
306
Contrôle d’accès physique complet	PAXWARE peut interagir avec des accès, mais ne remplace pas un système de contrôle d’accès certifié
307
Vidéosurveillance	Aucune fonction vidéo n’est incluse dans le périmètre initial
308
Application mobile grand public	Non prévue dans le périmètre initial
309
Exploitation cloud obligatoire	Le système doit rester prioritairement local et autonome
310
Maintenance des équipements tiers	Les équipements non PAXWARE ne font pas partie du périmètre de maintenance initial
311 29 Antoine K
```
312 1 Redmine Admin
313
Le hors périmètre pourra être revu dans les phases suivantes, notamment après le POC, en fonction des retours client, des contraintes site et du niveau d’industrialisation visé.
314
Synthèse de la partie 3
315
Le périmètre initial de PAXWARE comprend donc :
316 29 Antoine K
```
317 1 Redmine Admin
Éléments matériels / terrain	Éléments logiciels / supervision
318
PAX-TAG	PAX-MANAGER
319
PAX-ANT	PAX-WRITING
320
PAX-BOX	PAX-ROOM
321
PAX-SCREEN	PAX-MUSTER
322
PAX-NAV / PAX-SCREEN NAVIRE	ÉVÉNEMENT
323
Lecteur ou matériel associé au PAX-WRITING	Base locale
324
	Supervision
325
	Synchronisation différée
326 30 Antoine K
```
327 29 Antoine K
328 2 Antoine K
# 4. Acteurs et utilisateurs
329 1 Redmine Admin
Cette partie identifie les personnes, services ou systèmes qui interagissent avec l’écosystème PAXWARE. Elle permet de préparer les futures exigences relatives aux droits d’accès, à l’ergonomie, à la sécurité, à l’exploitation et à la traçabilité des actions.
330
À ce stade du document, les acteurs sont identifiés par un code unique afin de préparer la traçabilité des exigences. Ces identifiants seront utilisés dans la partie 5 — Fonctions attendues, puis dans les documents de spécification et de validation.
331 4 Antoine K
332 2 Antoine K
## 4.1 Acteurs principaux
333 1 Redmine Admin
Les acteurs principaux de PAXWARE sont les profils humains, opérationnels et techniques amenés à porter un PAX-TAG, utiliser le système, consulter les informations, administrer les données ou assurer le support.
334
La nomenclature officielle retenue pour le projet PAXWARE est la suivante :
335 4 Antoine K
336
```
337 1 Redmine Admin
ID acteur	Nomination officielle	Rôle général
338
ACT-001	Personnel offshore	Personnes présentes sur site, équipées d’un PAX-TAG
339
ACT-002	Responsable HSE	Responsable sécurité, exercices, muster, analyse des écarts
340
ACT-003	Chef de site / Ingénieur production	Supervision opérationnelle, décision terrain, suivi production
341
ACT-004	Barge-Master	Gestion opérationnelle des mouvements, POB, transferts, suivi inter-installations
342
ACT-005	Administrateur PAXWARE	Gestion des utilisateurs, zones, droits, équipements et paramètres
343
ACT-006	Technicien maintenance	Diagnostic, contrôle, remplacement et maintenance des équipements
344
ACT-007	Logistique	Gestion des arrivées, départs, rotations, hébergements et affectations
345
ACT-008	Équipe PAXWARE support	Assistance technique, diagnostic avancé, support logiciel et matériel
346 4 Antoine K
```
347 1 Redmine Admin
348 2 Antoine K
### 4.1.1 ACT-001 — Personnel offshore
349 1 Redmine Admin
Le personnel offshore regroupe l’ensemble des personnes physiquement présentes sur le site ou susceptibles de se déplacer entre plusieurs installations. Il peut s’agir d’opérateurs de production, techniciens maintenance, personnel forage, personnel marine, catering, HSE, sous-traitants ou visiteurs.
350
Ce profil est principalement utilisateur indirect du système. Il porte un PAX-TAG et peut être détecté lors d’un passage ou confirmé lors d’un muster-point. Il n’a pas vocation à administrer le système ni à accéder aux informations globales d’exploitation.
351 2 Antoine K
### 4.1.2 ACT-002 — Responsable HSE
352 1 Redmine Admin
Le responsable HSE est un utilisateur clé du système PAXWARE pour les exercices de sécurité, les alarmes, les situations d’urgence, les musters et l’analyse des écarts après événement.
353
Il doit pouvoir consulter les personnes attendues, suivre les personnes confirmées ou non confirmées, exploiter les rapports et qualifier certaines anomalies liées à la sécurité des personnes.
354 2 Antoine K
### 4.1.3 ACT-003 — Chef de site / Ingénieur production
355 1 Redmine Admin
Le Chef de site ou l’Ingénieur production utilise PAXWARE comme outil d’aide à la décision opérationnelle. Il doit pouvoir disposer d’une vision claire de la présence par installation, notamment lorsque cette information peut influencer l’exploitation, les interventions, les transferts ou la gestion d’une situation dégradée.
356 2 Antoine K
### 4.1.4 ACT-004 — Barge-Master
357 1 Redmine Admin
Le Barge-Master est un acteur central pour le suivi des mouvements de personnel, des transferts, du POB et des passages entre installations. Il doit pouvoir exploiter PAXWARE pour consolider rapidement les informations liées aux présences et aux mouvements inter-installations.
358
Ce rôle est particulièrement important dans les environnements où plusieurs plateformes, passerelles, navires ou zones opérationnelles sont connectés à une barge ou à une unité centrale d’exploitation.
359 2 Antoine K
### 4.1.5 ACT-005 — Administrateur PAXWARE
360 1 Redmine Admin
L’administrateur PAXWARE est responsable de la configuration fonctionnelle du système. Il gère les utilisateurs, les droits, les zones, les installations, les équipements et l’association entre les personnes et les PAX-TAG.
361
Ses actions doivent être contrôlées et journalisées afin de garantir la sécurité, la traçabilité et la cohérence de la configuration du système.
362 2 Antoine K
### 4.1.6 ACT-006 — Technicien maintenance
363 1 Redmine Admin
Le technicien maintenance intervient sur les équipements physiques et les fonctions techniques du système. Il peut contrôler l’état des PAX-ANT, PAX-BOX, PAX-SCREEN, lecteurs, alimentations, connexions réseau et journaux techniques.
364
Il doit disposer des informations nécessaires au diagnostic et au retour au fonctionnement nominal, sans disposer nécessairement d’un accès complet aux données nominatives du personnel.
365 2 Antoine K
### 4.1.7 ACT-007 — Logistique
366 1 Redmine Admin
La logistique intervient dans la préparation et le suivi des arrivées, départs, rotations, hébergements, affectations et mouvements planifiés du personnel.
367
Ce profil peut utiliser PAXWARE pour préparer les affectations, vérifier la cohérence entre manifeste, présence attendue et présence réelle, et contribuer à la mise à jour des informations avant embarquement ou débarquement.
368 2 Antoine K
### 4.1.8 ACT-008 — Équipe PAXWARE support
369 1 Redmine Admin
L’équipe PAXWARE support intervient en assistance technique, diagnostic avancé, correction logicielle, accompagnement de mise à jour ou analyse d’anomalie.
370 2 Antoine K
Son accès doit être strictement encadré, autorisé par le client, limité selon le besoin et journalisé. Ce profil devra être traité avec attention dans les exigences de cybersécurité et de support.
371 1 Redmine Admin
### 4.1.9 Préparation de la traçabilité des exigences
372
Les identifiants ACT-001 à ACT-008 constituent le référentiel des acteurs pour la suite du projet. À partir de la partie 5, chaque exigence fonctionnelle pourra être reliée à un ou plusieurs acteurs concernés.
373 4 Antoine K
Exemple indicatif de future exigence	
374
375
```
376
Acteur concerné	Fonction associée
377 1 Redmine Admin
REQ-FONC-001	ACT-002, ACT-003, ACT-004	Consulter le nombre de personnes présentes par installation
378
REQ-FONC-002	ACT-004, ACT-007, ACT-002	Suivre les arrivées, départs et transferts
379
REQ-FONC-003	ACT-002, ACT-004	Suivre un muster et identifier les personnes non confirmées
380
REQ-FONC-004	ACT-005, ACT-007	Associer un PAX-TAG à une personne
381
REQ-MAINT-001	ACT-006, ACT-008	Diagnostiquer l’état d’une PAX-ANT ou d’un PAX-SCREEN
382
REQ-SEC-005 / REQ-SEC-006	ACT-005, ACT-008	Encadrer les droits d’accès et les interventions support
383 4 Antoine K
```
384 1 Redmine Admin
385 2 Antoine K
## 4.2 Profils utilisateurs
386
### 4.2.1 Principe général
387 1 Redmine Admin
Le système PAXWARE sera utilisé ou impactera plusieurs profils d’utilisateurs, chacun ayant un rôle différent dans l’exploitation, la sécurité, la logistique, la maintenance ou le support.
388
La définition des profils utilisateurs permet de préparer :
389
•	la gestion des droits d’accès ;
390
•	la séparation des responsabilités ;
391
•	la sécurité d’exploitation ;
392
•	la traçabilité des actions ;
393
•	l’ergonomie des interfaces ;
394
•	les futurs cas d’usage ;
395
•	les futures exigences fonctionnelles et cybersécurité.
396
397
PAXWARE devra rester simple d’utilisation pour les profils opérationnels, tout en réservant les fonctions sensibles aux profils autorisés.
398
Le système ne doit pas imposer une charge informatique excessive aux équipes terrain. Son objectif est d’apporter une information claire, fiable et exploitable, sans complexifier inutilement les procédures existantes.
399
400 2 Antoine K
### 4.2.2 Tableau des profils utilisateurs
401 5 Antoine K
```
402 1 Redmine Admin
ID acteur	Profil utilisateur	Rôle principal	Niveau d’accès attendu
403
ACT-001	Personnel offshore	Porte un PAX-TAG et participe aux procédures de présence ou de muster	Aucun accès logiciel ou accès très limité
404
ACT-002	Responsable HSE	Suit les exercices, alarmes, muster-points et rapports sécurité ; s’assure que les bracelets sont portés par toutes les personnes concernées.	Accès sécurité / muster / rapports
405
ACT-003	Chef de site / Ingénieur production	Dispose d’une vision opérationnelle du site et des installations sans modifier la configuration technique.	Accès supervision globale / exploitation / consultation avancée
406
ACT-004	Barge-Master	Suit les mouvements de personnel, les transferts, le POB et les passages entre installations	Accès exploitation / mouvements / POB
407
ACT-005	Administrateur PAXWARE	Configure le système, les utilisateurs, les zones, les droits et les équipements	Accès administration
408
ACT-006	Technicien maintenance	Diagnostique, contrôle et maintient les équipements	Accès maintenance / diagnostic
409
ACT-007	Logistique	Gère les arrivées, départs, rotations, hébergements et affectations	Accès logistique / consultation / préparation
410
ACT-008	Équipe PAXWARE support	Intervient en assistance technique selon autorisation client	Accès support contrôlé, limité et journalisé
411 5 Antoine K
```
412
413 2 Antoine K
### 4.2.3 Description des profils
414 1 Redmine Admin
Pour éviter les redondances avec la section 4.1, les descriptions détaillées des rôles ACT-001 à ACT-008 font foi dans la section 4.1. La présente section 4.2 consolide uniquement les profils utilisateurs, les niveaux d’accès attendus et la séparation des responsabilités. Les droits effectifs devront être précisés dans les exigences de cybersécurité et dans la matrice de droits PAXWARE.
415 6 Antoine K
416 2 Antoine K
### 4.2.4 Préparation de la traçabilité des exigences
417 1 Redmine Admin
Les profils utilisateurs définis dans cette section serviront de référence pour la traçabilité des exigences.
418
Chaque future exigence pourra être reliée à un ou plusieurs acteurs.
419 6 Antoine K
Exigence fonctionnelle de référence	
420
421
```
422
Acteur concerné	Fonction associée
423 1 Redmine Admin
REQ-FONC-001	ACT-002, ACT-003, ACT-004	Consulter le nombre de personnes présentes par installation
424
REQ-FONC-002	ACT-004, ACT-007, ACT-002	Suivre les arrivées, départs et transferts
425
REQ-FONC-003	ACT-002, ACT-004	Suivre un muster et identifier les personnes non confirmées
426
REQ-FONC-004	ACT-005, ACT-007	Associer un PAX-TAG à une personne
427
REQ-MAINT-001	ACT-006, ACT-008	Diagnostiquer l’état d’une PAX-ANT ou d’un PAX-SCREEN
428
REQ-SEC-005 / REQ-SEC-006	ACT-005, ACT-008	Encadrer les droits d’accès et les interventions support
429 6 Antoine K
```
430
431 1 Redmine Admin
À ce stade, les identifiants ACT-001 à ACT-008 constituent la base de référence des acteurs PAXWARE.
432 6 Antoine K
433 2 Antoine K
## 4.3 Cas d’usage principaux
434
### 4.3.1 Principe général
435 1 Redmine Admin
Les cas d’usage décrivent les principales situations dans lesquelles les acteurs interagissent avec PAXWARE.
436
Ils permettent de relier les besoins opérationnels aux futures exigences fonctionnelles.
437
Chaque cas d’usage pourra ensuite être transformé en exigences, scénarios de test et critères de validation client.
438 7 Antoine K
439 2 Antoine K
###  4.3.2 Tableau des cas d’usage principaux
440 7 Antoine K
```
441 1 Redmine Admin
ID cas d’usage	Cas d’usage	Acteurs principaux	Objectif
442
CU-001	Préparer l’arrivée d’une personne sur site	ACT-007, ACT-004	Créer ou préparer l’affectation d’une personne attendue
443
CU-002	Associer un PAX-TAG à une personne	ACT-004, ACT-007, ACT-005	Lier un identifiant PAXWARE à une personne autorisée
444
CU-003	Détecter un passage entre deux zones	ACT-001, PAX-ANT, PAX-BOX	Identifier un mouvement entre installations
445
CU-004	Consulter le nombre de personnes par installation	ACT-003, ACT-004, ACT-002	Obtenir une vision opérationnelle rapide
446
CU-005	Afficher localement le nombre de personnes	PAX-BOX, PAX-SCREEN, ACT-004, ACT-003, ACT-002	Fournir une lecture terrain simple via PAX-SCREEN ; ACT-001 reste bénéficiaire indirect de l’information affichée.
447
CU-006	Lancer ou suivre un muster	ACT-002, ACT-004, ACT-003	Confirmer les personnes présentes en exercice ou urgence
448
CU-007	Identifier les personnes non confirmées	ACT-002, ACT-004, ACT-007	Prioriser la recherche ou la levée de doute
449
CU-008	Consulter les événements et historiques	ACT-002, ACT-004, ACT-005	Reconstituer les mouvements ou anomalies
450
CU-009	Diagnostiquer un équipement	ACT-006, ACT-008	Vérifier l’état d’une antenne, box, écran ou terminal
451
CU-010	Fonctionner en perte réseau	ACT-003, ACT-004, ACT-005	Maintenir l’exploitation locale malgré l’absence de cloud
452
CU-011	Synchroniser les données différées	PAX-BOX, ACT-005, ACT-008	Transmettre les données autorisées lorsque le réseau revient
453
CU-012	Gérer une anomalie de présence ou d’équipement	ACT-002, ACT-004, ACT-006	Identifier, qualifier et traiter un écart ou défaut
454 7 Antoine K
```
455 3 Antoine K
456 2 Antoine K
### 4.3.3 Description courte des cas d’usage
457 1 Redmine Admin
CU-001 — Préparer l’arrivée d’une personne sur site
458
Avant l’arrivée d’une personne sur site, le profil Logistique ou Administrateur prépare les informations nécessaires à son intégration dans PAXWARE.
459
Cela peut inclure :
460
•	identité ou référence personnel ;
461
•	société ;
462
•	fonction ;
463
•	installation d’affectation ;
464
•	durée prévue de présence ;
465
•	cabine ou hébergement ;
466
•	statut visiteur, organique, permanent, visiteur ou sous-traitant.
467
Ce cas d’usage permet d’alimenter le système avec une présence attendue.
468
CU-002 — Associer un PAX-TAG à une personne
469
Un PAX-TAG est attribué à une personne autorisée.
470
L’association doit permettre au système de reconnaître le porteur du PAX-TAG dans le périmètre PAXWARE.
471
Cette opération peut être réalisée avant embarquement, à l’arrivée sur site ou lors d’un remplacement de bracelet.
472
Elle doit être tracée afin de savoir quel identifiant a été associé à quelle personne et à quel moment.
473
CU-003 — Détecter un passage entre deux zones
474
Lorsqu’une personne équipée d’un PAX-TAG passe par un point de transfert équipé d’une PAX-ANT, le système détecte un événement de passage.
475
476
477
Ce cas d’usage concerne notamment :
478
•	passage barge vers plateforme ;
479
•	passage plateforme vers barge ;
480
•	changement de zone ;
481
•	transfert vers un navire ou une zone mobile selon le scénario retenu.
482
Le système doit permettre de consolider ces événements afin d’actualiser la présence par installation.
483
CU-004 — Consulter le nombre de personnes par installation
484
Les profils autorisés doivent pouvoir consulter rapidement le nombre de personnes présentes par installation, zone ou navire.
485
Ce cas d’usage est central pour le Chef de site, l’Ingénieur production, le Barge-Master et le Responsable HSE.
486
L’information doit être claire, simple et exploitable sans analyse complexe.
487
CU-005 — Afficher localement le nombre de personnes
488
Le PAX-SCREEN permet d’afficher localement une information synthétique, visible et compréhensible.
489
Ce cas d’usage vise à fournir une lecture terrain rapide du nombre de personnes présentes sur une installation ou zone donnée.
490
L’objectif est que l’information soit disponible même sans consulter un poste informatique.
491
CU-006 — Lancer ou suivre un muster-point
492
En cas d’exercice de sécurité ou de situation d’urgence, le Responsable HSE, le Barge-Master ou un profil autorisé doit pouvoir lancer ou suivre une opération de muster.
493
Le système doit permettre de comparer :
494
•	les personnes attendues ;
495
•	les personnes détectées ;
496
•	les personnes confirmées ;
497
•	les personnes non confirmées.
498
Ce cas d’usage ne remplace pas les procédures HSE officielles, mais il doit les renforcer.
499
CU-007 — Identifier les personnes non confirmées
500
Lors d’un muster ou d’une situation d’urgence, le système doit aider à identifier les personnes dont la présence n’a pas encore été confirmée.
501
Ce cas d’usage permet de réduire les incertitudes et d’aider les équipes à prioriser les recherches, les vérifications radio ou les levées de doute.
502
CU-008 — Consulter les événements et historiques
503
Les profils autorisés doivent pouvoir consulter les événements utiles :
504
•	passages ;
505
•	validations muster ;
506
•	anomalies ;
507
•	pertes de communication ;
508
•	actions administrateur ;
509
•	changements d’affectation ;
510
•	événements techniques.
511
Ces informations doivent permettre l’analyse après exercice, incident ou anomalie.
512
CU-009 — Diagnostiquer un équipement
513
Le Technicien maintenance ou l’équipe PAXWARE support doit pouvoir consulter l’état des équipements.
514
Cela peut concerner :
515
•	PAX-ANT ;
516
•	PAX-BOX ;
517
•	PAX-SCREEN ;
518
•	PAX-MUSTER ;
519
•	PAX-TAG ;
520
•	réseau local ;
521
•	alimentation.
522
Ce cas d’usage permet de réduire le temps de diagnostic et d’améliorer la disponibilité du système.
523
CU-010 — Fonctionner en perte réseau
524
PAXWARE doit conserver ses fonctions critiques localement en cas de perte de connexion internet, cloud ou liaison distante.
525
Les fonctions minimales attendues sont :
526
•	consultation locale ;
527
•	comptage par installation ;
528
•	conservation des événements ;
529
•	muster local ;
530
•	affichage local ;
531
•	reprise de synchronisation au retour réseau.
532
Ce cas d’usage est essentiel dans les environnements offshore isolés.
533
CU-011 — Synchroniser les données différées
534
Lorsque la connexion distante redevient disponible, le système doit pouvoir synchroniser les données autorisées.
535
La synchronisation ne doit pas compromettre le fonctionnement local.
536
Elle doit respecter les règles de confidentialité, de sécurité et de disponibilité définies pour le projet.
537
CU-012 — Gérer une anomalie de présence ou d’équipement
538
PAXWARE doit permettre de signaler ou consulter certaines anomalies.
539
Exemples :
540
•	équipement hors ligne ;
541
•	PAX-TAG non détecté ;
542
•	incohérence entrée/sortie ;
543
•	personne attendue mais non confirmée ;
544
•	perte de communication ;
545
•	stockage local saturé ;
546
•	anomalie de synchronisation.
547
Ce cas d’usage permettra ensuite de préparer les exigences liées à la gestion des anomalies.
548
549
Transition vers la partie 5 — Fonctions attendues
550
À partir de la partie 5, le document commencera officiellement la traçabilité des exigences PAXWARE.
551
Les fonctions attendues seront transformées en exigences identifiées, par exemple :
552
•	REQ-FONC-001 — Le système doit permettre d’associer un PAX-TAG à une personne.
553
•	REQ-FONC-002 — Le système doit détecter un passage entre deux zones équipées.
554
•	REQ-FONC-003 — Le système doit consolider le nombre de personnes par installation.
555
•	REQ-FONC-004 — Le système doit afficher localement le nombre de personnes par installation.
556
•	REQ-FONC-005 — Le système doit permettre le suivi d’un muster.
557
Chaque exigence pourra être reliée à un acteur, un cas d’usage, un module PAXWARE, un scénario de test et un critère de validation client.
558 3 Antoine K
# 5. Fonctions attendues
559
## 5.1 Fonctions d’acquisition
560
### 5.1.1 Principe général
561 1 Redmine Admin
Les fonctions d’acquisition correspondent à l’ensemble des informations que le système PAXWARE doit être capable de collecter, recevoir ou enregistrer afin de produire une vision fiable de la présence du personnel par installation, zone ou moyen mobile.
562
Dans le cadre de PAXWARE, l’acquisition ne se limite pas à une simple lecture d’identifiant. Elle doit permettre de collecter des événements utiles à l’exploitation, à la sécurité, au suivi des mouvements, au muster-point, à la maintenance et à la traçabilité.
563
Les données acquises doivent principalement provenir :
564
•	des PAX-TAG portés par le personnel ;
565
•	des PAX-ANT installées sur les points de passage ;
566
•	des PAX-MUSTER utilisés lors des exercices ou situations d’urgence ;
567
•	des PAX-SCREEN / PAX-NAV associés aux installations ou moyens mobiles ;
568
•	de la PAX-BOX, qui centralise les événements locaux ;
569
•	des actions utilisateurs réalisées depuis les interfaces PAXWARE ;
570
•	des équipements techniques supervisés par le système.
571
L’objectif de cette partie est de transformer les besoins d’acquisition en premières exigences traçables.
572 8 Antoine K
573 3 Antoine K
### 5.1.2 Données de présence à acquérir
574 1 Redmine Admin
Le système doit permettre d’acquérir les informations nécessaires pour déterminer la présence d’une personne dans le périmètre PAXWARE.
575
Ces informations peuvent inclure :
576 8 Antoine K
```
577 1 Redmine Admin
•	l’identifiant du PAX-TAG ;
578
•	l’état d’association du PAX-TAG à une personne ;
579
•	la zone ou installation concernée ;
580
•	la date et l’heure de l’événement ;
581
•	l’équipement ayant détecté l’événement ;
582
•	le type d’événement : détection, passage, confirmation, anomalie ;
583
•	le statut de validité de l’événement.
584 8 Antoine K
```
585 1 Redmine Admin
586 8 Antoine K
```
587 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
588
REQ-ACQ-001	Le système doit pouvoir acquérir l’identifiant d’un PAX-TAG porté par une personne présente dans le périmètre PAXWARE.	ACT-001, PAX-TAG, PAX-ANT	CU-003
589
REQ-ACQ-002	Le système doit pouvoir associer un événement acquis à une zone, une installation ou un point de passage défini.	PAX-ANT, PAX-BOX	CU-003, CU-004
590
REQ-ACQ-003	Le système doit horodater les événements acquis afin de permettre leur exploitation et leur traçabilité.	PAX-BOX	CU-008
591
REQ-ACQ-004	Le système doit identifier l’équipement source ayant généré ou transmis l’événement.	PAX-ANT, PAX-MUSTER, PAX-BOX	CU-008, CU-009
592
REQ-ACQ-005	Le système doit distinguer les événements de présence, de passage, de validation muster-point et d’anomalie.	PAX-BOX, PAX-MANAGER	CU-003, CU-006, CU-012
593 8 Antoine K
```
594
595 3 Antoine K
### 5.1.3 Acquisition des passages entre zones ou installations
596 1 Redmine Admin
PAXWARE doit permettre d’acquérir les événements liés aux mouvements du personnel entre différentes zones ou installations.
597
Ces passages peuvent concerner notamment :
598 9 Antoine K
```
599 1 Redmine Admin
•	un passage entre une barge et une plateforme ;
600
•	un passage entre une plateforme et une barge ;
601
•	un passage entre deux zones opérationnelles ;
602
•	un passage vers un navire, un surfer ou une zone mobile ;
603
•	un passage par un accès surveillé.
604 9 Antoine K
```
605 1 Redmine Admin
L’objectif n’est pas de suivre une personne en continu au mètre près, mais de détecter les événements de passage utiles à la connaissance de présence.
606 9 Antoine K
```
607 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
608
REQ-ACQ-010	Le système doit pouvoir acquérir un événement de passage lorsqu’un PAX-TAG est détecté sur un point de transfert équipé.	ACT-001, PAX-TAG, PAX-ANT	CU-003
609
REQ-ACQ-011	Le système doit permettre, lorsque la configuration technique le permet, de distinguer le sens du passage entre entrée et sortie.	PAX-ANT, PAX-BOX	CU-003, CU-004
610
REQ-ACQ-012	Le système doit transmettre les événements de passage acquis vers la PAX-BOX pour traitement local.	PAX-ANT, PAX-BOX	CU-003, CU-010
611
REQ-ACQ-013	Le système doit conserver localement les événements de passage en cas d’indisponibilité de la connexion distante.	PAX-BOX	CU-010, CU-011
612
REQ-ACQ-014	Le système doit permettre de relier un événement de passage à une installation de départ et/ou une installation d’arrivée lorsque ces informations sont disponibles.	PAX-ANT, PAX-BOX, PAX-MANAGER	CU-003, CU-004
613 9 Antoine K
```
614
615 3 Antoine K
### 5.1.4 Acquisition des données de muster-point
616 1 Redmine Admin
Lors d’un exercice de sécurité, d’un appel au rassemblement ou d’une situation d’urgence, le système doit permettre d’acquérir les validations de présence.
617
Cette acquisition peut se faire par :
618 10 Antoine K
```
619 1 Redmine Admin
•	lecture volontaire d’un PAX-TAG ;
620
•	lecture volontaire courte portée du PAX-TAG, par NFC/RFID selon la technologie retenue ;
621
•	détection radio dans une zone de rassemblement lorsque cette option est retenue, avec rayon configurable et règles anti-faux positifs ;
622
•	confirmation manuelle par un profil autorisé ;
623
•	validation depuis un terminal PAX-MUSTER ;
624
•	synchronisation avec la PAX-BOX.
625 10 Antoine K
```
626 1 Redmine Admin
627
628
629
Les données de muster-point doivent permettre de distinguer les personnes attendues, détectées, confirmées, non confirmées, ainsi que les écarts ou anomalies.
630 10 Antoine K
```
631 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
632
REQ-ACQ-020	Le système doit permettre d’acquérir une confirmation de présence lors d’un muster-point par lecture courte portée, détection radio de zone si retenue, ou validation manuelle autorisée.	ACT-001, ACT-002, PAX-MUSTER	CU-006
633
REQ-ACQ-021	Le système doit pouvoir associer une confirmation muster-point à une personne attendue ou à un PAX-TAG connu.	PAX-MUSTER, PAX-BOX	CU-006, CU-007
634
REQ-ACQ-022	Le système doit horodater chaque confirmation de présence réalisée pendant un muster-point.	PAX-MUSTER, PAX-BOX	CU-006, CU-008
635
REQ-ACQ-023	Le système doit permettre l’acquisition d’une confirmation manuelle par un profil autorisé lorsque la procédure terrain le justifie.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-007
636
REQ-ACQ-024	Le système doit conserver une trace exploitable des validations réalisées pendant un exercice ou une situation d’urgence.	PAX-MUSTER, PAX-BOX	CU-006, CU-008
637 10 Antoine K
```
638
639 3 Antoine K
### 5.1.5 Acquisition des données logistiques
640 1 Redmine Admin
PAXWARE doit pouvoir acquérir ou recevoir certaines informations logistiques nécessaires à la préparation de la présence attendue.
641
Ces informations peuvent provenir d’un manifeste, d’une saisie manuelle, d’un import de fichier, d’une interface future avec un système client ou d’une préparation réalisée par la logistique ou l’administrateur PAXWARE.
642
Les données logistiques permettent notamment de préparer :
643 11 Antoine K
```
644 1 Redmine Admin
•	les personnes attendues sur site ;
645
•	les arrivées ;
646
•	les départs ;
647
•	les rotations ;
648
•	les affectations par installation ;
649
•	les cabines ou hébergements ;
650
•	les statuts temporaires ;
651
•	les sous-traitants ou visiteurs.
652 11 Antoine K
```
653
654
```
655 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
656
REQ-ACQ-030	Le système doit permettre l’acquisition des informations nécessaires à la préparation d’une personne attendue sur site.	ACT-007, ACT-005, PAX-WRITING	CU-001
657
REQ-ACQ-031	Le système doit permettre d’associer une personne attendue à une installation, une zone ou une affectation prévue.	ACT-007, ACT-005, PAX-MANAGER	CU-001, CU-002
658
REQ-ACQ-032	Le système doit permettre d’acquérir ou de saisir les informations nécessaires à l’association d’un PAX-TAG à une personne.	ACT-005, ACT-007, PAX-WRITING	CU-002
659
REQ-ACQ-033	Le système doit permettre d’identifier les personnes temporaires, visiteurs ou sous-traitants lorsque cette information est disponible.	ACT-007, ACT-005	CU-001
660
REQ-ACQ-034	Le système doit pouvoir recevoir une liste de personnes attendues afin de préparer les opérations de présence et de muster-point.	ACT-007, PAX-MANAGER	CU-001, CU-006
661 11 Antoine K
```
662
663 3 Antoine K
### 5.1.6 Acquisition des états équipements
664 1 Redmine Admin
PAXWARE doit pouvoir acquérir les informations nécessaires à la supervision technique de ses propres équipements.
665
Cette acquisition permet de vérifier que le système est opérationnel et que les données collectées peuvent être considérées comme fiables.
666
667
668
Les équipements concernés peuvent être :
669 12 Antoine K
```
670 1 Redmine Admin
•	PAX-ANT ;
671
•	PAX-BOX ;
672
•	PAX-SCREEN ;
673
•	PAX-MUSTER ;
674
•	PAX-TAG ;
675
•	PAX-NAV / PAX-SCREEN NAVIRE ;
676
•	réseau local ;
677
•	alimentation ;
678
•	stockage local.
679 12 Antoine K
```
680 1 Redmine Admin
681 12 Antoine K
```
682 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
683
REQ-ACQ-040	Le système doit pouvoir acquérir l’état de fonctionnement des équipements PAXWARE connectés.	ACT-006, PAX-BOX, PAX-MANAGER	CU-009
684
REQ-ACQ-041	Le système doit pouvoir signaler qu’un équipement attendu ne communique plus ou présente une anomalie.	ACT-006, ACT-008, PAX-BOX	CU-009, CU-012
685
REQ-ACQ-042	Le système doit acquérir les informations utiles au diagnostic technique des équipements.	ACT-006, ACT-008, PAX-MANAGER	CU-009
686
REQ-ACQ-043	Le système doit pouvoir acquérir l’état de synchronisation entre la PAX-BOX et les services distants autorisés.	ACT-005, ACT-008, PAX-BOX	CU-010, CU-011
687
REQ-ACQ-044	Le système doit acquérir l’état du stockage local, déclencher des seuils d’alerte et appliquer une stratégie anti-perte afin d’éviter la saturation des événements critiques.	ACT-006, PAX-BOX	CU-010, CU-012
688 12 Antoine K
```
689 1 Redmine Admin
690 3 Antoine K
### 5.1.7 Acquisition des actions utilisateurs
691 1 Redmine Admin
Certaines actions réalisées par les utilisateurs autorisés doivent être acquises et journalisées.
692
Ces actions peuvent concerner la création d’un utilisateur, la modification d’un droit, l’association d’un PAX-TAG, la modification d’une zone, la validation manuelle d’une présence, la qualification d’une anomalie, l’export d’un rapport, une opération de maintenance ou une intervention support.
693
Cette acquisition est nécessaire pour assurer la traçabilité, la sécurité et la gestion de configuration.
694
695 13 Antoine K
```
696 1 Redmine Admin
ID exigence	Exigence d’acquisition	Acteurs / éléments concernés	Cas d’usage liés
697
REQ-ACQ-050	Le système doit journaliser les actions significatives réalisées par les utilisateurs autorisés.	ACT-005, ACT-006, ACT-008	CU-008, CU-012
698
REQ-ACQ-051	Le système doit conserver une trace des associations et désassociations entre une personne et un PAX-TAG.	ACT-005, ACT-007, PAX-WRITING	CU-002, CU-008
699
REQ-ACQ-052	Le système doit conserver une trace des modifications de configuration ayant un impact sur l’exploitation.	ACT-005, PAX-MANAGER	CU-008, CU-012
700
REQ-ACQ-053	Le système doit conserver une trace des validations manuelles réalisées pendant un muster-point.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-008
701
REQ-ACQ-054	Le système doit journaliser les interventions support réalisées par l’équipe PAXWARE lorsque celles-ci sont autorisées par le client.	ACT-008, ACT-005	CU-009, CU-012
702 13 Antoine K
```
703 1 Redmine Admin
704 3 Antoine K
### 5.1.8 Synthèse des fonctions d’acquisition
705 1 Redmine Admin
Les fonctions d’acquisition constituent la première étape du traitement PAXWARE.
706
Elles permettent de collecter les informations nécessaires pour :
707 14 Antoine K
```
708 1 Redmine Admin
•	connaître la présence réelle ou attendue ;
709
•	détecter les passages ;
710
•	confirmer les personnes lors d’un muster-point ;
711
•	préparer les arrivées et départs ;
712
•	superviser l’état des équipements ;
713
•	conserver une trace des événements ;
714
•	assurer la continuité d’exploitation en mode local.
715 14 Antoine K
```
716 1 Redmine Admin
À ce stade du projet, les exigences d’acquisition sont volontairement formulées au niveau fonctionnel. Les choix définitifs concernant les technologies de détection, les protocoles, les formats de données, les fréquences d’émission, les performances attendues et les composants matériels seront précisés dans les documents de spécification détaillée.
717 14 Antoine K
718 3 Antoine K
### 5.1.9 Exigences d’acquisition 
719 15 Antoine K
720
```
721 1 Redmine Admin
Famille	Plage d’identifiants	Objet
722
Présence	REQ-ACQ-001 à REQ-ACQ-005	Acquisition des identifiants, événements et données de présence
723
Passage	REQ-ACQ-010 à REQ-ACQ-014	Acquisition des mouvements entre zones ou installations
724
Muster-point	REQ-ACQ-020 à REQ-ACQ-024	Acquisition des confirmations de présence
725
Logistique	REQ-ACQ-030 à REQ-ACQ-034	Acquisition des données de préparation et d’affectation manifeste
726
Équipements	REQ-ACQ-040 à REQ-ACQ-044	Acquisition des états techniques
727
Actions utilisateurs	REQ-ACQ-050 à REQ-ACQ-054	Journalisation des actions significatives
728
```
729 16 Antoine K
730
 Les fonctions d’acquisition de PAXWARE doivent permettre de collecter les identifiants, passages, confirmations, données logistiques, états équipements et actions utilisateurs nécessaires à la connaissance de présence, à la sécurité, au muster-point, à la supervision et à la traçabilité du système.
731 1 Redmine Admin
732 3 Antoine K
## 5.2 Fonctions de traitement
733 17 Antoine K
734 3 Antoine K
### 5.2.1 Principe général
735 1 Redmine Admin
Les fonctions de traitement correspondent à l’ensemble des opérations réalisées par PAXWARE après l’acquisition des données.
736
Elles permettent de transformer les événements collectés en informations exploitables par les utilisateurs autorisés.
737
Dans le cadre de PAXWARE, le traitement doit permettre notamment de :
738 17 Antoine K
```
739 1 Redmine Admin
•	interpréter les événements acquis par les équipements ;
740
•	consolider la présence par installation, zone ou moyen mobile ;
741
•	déterminer les mouvements entre zones ;
742
•	comparer la présence attendue avec la présence observée ;
743
•	identifier les écarts, incohérences ou anomalies ;
744
•	produire les informations nécessaires au muster-point ;
745
•	préparer les informations à afficher sur PAX-SCREEN ;
746
•	alimenter PAX-MANAGER avec une situation lisible ;
747
•	conserver une trace exploitable des traitements réalisés.
748 17 Antoine K
```
749 1 Redmine Admin
Le traitement des données doit rester prioritairement local, au niveau de la PAX-BOX, afin de garantir le fonctionnement du système même en cas de perte de connexion internet ou cloud.
750
Les exigences de traitement sont identifiées avec le préfixe :
751 17 Antoine K
```
752 1 Redmine Admin
REQ-TRT : Exigence de traitement
753 17 Antoine K
```
754
755 3 Antoine K
### 5.2.2 Traitement des événements de présence
756 1 Redmine Admin
Les événements de présence acquis par PAXWARE doivent être analysés afin de déterminer si une personne est considérée comme présente, absente, transférée, attendue ou non confirmée.
757 18 Antoine K
758 1 Redmine Admin
Le système ne doit pas simplement collecter des événements bruts. Il doit les transformer en information opérationnelle compréhensible.
759 18 Antoine K
```
760 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
761
REQ-TRT-001	Le système doit traiter les événements acquis afin de déterminer la présence courante d’une personne dans le périmètre PAXWARE.	PAX-BOX, PAX-MANAGER	CU-003, CU-004
762
REQ-TRT-002	Le système doit associer chaque événement exploitable à une personne connue, un PAX-TAG ou un identifiant autorisé.	PAX-TAG, PAX-BOX, PAX-MANAGER	CU-002, CU-003
763
REQ-TRT-003	Le système doit pouvoir distinguer une présence observée, une présence attendue et une présence confirmée.	PAX-BOX, PAX-MUSTER	CU-004, CU-006
764
REQ-TRT-004	Le système doit ignorer ou qualifier les événements non exploitables, incomplets ou incohérents.	PAX-BOX	CU-008, CU-012
765
REQ-TRT-005	Le système doit conserver l’état courant de présence même en cas de perte temporaire de connexion distante.	PAX-BOX	CU-010
766 18 Antoine K
```
767 1 Redmine Admin
768 3 Antoine K
### 5.2.3 Traitement des passages entre zones ou installations
769 1 Redmine Admin
Les événements de passage constituent une fonction centrale de PAXWARE.
770
Lorsqu’un PAX-TAG est détecté sur un point de transfert, le système doit pouvoir interpréter cet événement afin de mettre à jour la situation de présence.
771
Les passages peuvent concerner :
772 19 Antoine K
```
773 1 Redmine Admin
•	une barge vers une plateforme ;
774
•	une plateforme vers une barge ;
775
•	une plateforme vers une autre plateforme ;
776
•	une installation vers un navire ;
777
•	un accès vers une zone opérationnelle ;
778
•	un retour depuis un moyen mobile.
779 19 Antoine K
```
780 1 Redmine Admin
781 19 Antoine K
```
782 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
783
REQ-TRT-010	Le système doit traiter les événements de passage afin de mettre à jour la présence par zone ou installation.	PAX-ANT, PAX-BOX	CU-003, CU-004
784
REQ-TRT-011	Le système doit pouvoir interpréter le sens de passage lorsqu’une information entrée/sortie est disponible.	PAX-ANT, PAX-BOX	CU-003
785
REQ-TRT-012	Le système doit pouvoir traiter un passage comme un transfert entre une installation de départ et une installation d’arrivée lorsque ces informations sont disponibles.	PAX-BOX, PAX-MANAGER	CU-003, CU-004
786
REQ-TRT-013	Le système doit éviter de compter deux fois une même personne lors d’un passage ou d’un événement répété.	PAX-BOX	CU-003, CU-004
787
REQ-TRT-014	Le système doit pouvoir qualifier un événement de passage ambigu lorsque le sens ou la zone d’arrivée ne peut pas être déterminé avec certitude.	PAX-BOX, PAX-MANAGER	CU-012
788 19 Antoine K
```
789 1 Redmine Admin
790 3 Antoine K
### 5.2.4 Consolidation du nombre de personnes par installation
791 1 Redmine Admin
Le système doit consolider les événements traités afin de produire une information synthétique : le nombre de personnes présentes par installation, zone ou moyen mobile.
792 20 Antoine K
793 1 Redmine Admin
Cette fonction est essentielle pour :
794 20 Antoine K
```
795 1 Redmine Admin
•	le Chef de site ;
796
•	l’Ingénieur production ;
797
•	le Barge-Master ;
798
•	le Responsable HSE ;
799
•	la Logistique ;
800
•	la supervision locale.
801 20 Antoine K
```
802 1 Redmine Admin
803
L’information consolidée doit être simple, lisible et rapidement exploitable.
804 20 Antoine K
```
805 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
806
REQ-TRT-020	Le système doit consolider le nombre de personnes présentes par installation ou zone opérationnelle.	ACT-003, ACT-004, PAX-BOX, PAX-MANAGER	CU-004
807
REQ-TRT-021	Le système doit produire une information de présence exploitable par PAX-MANAGER.	ACT-003, ACT-004, ACT-002, PAX-MANAGER	CU-004
808
REQ-TRT-022	Le système doit produire une information synthétique exploitable par PAX-SCREEN.	ACT-002, ACT-003, ACT-004, PAX-SCREEN	CU-005
809
REQ-TRT-023	Le système doit mettre à jour le nombre de personnes par installation à partir des événements validés ou considérés exploitables.	PAX-BOX, PAX-MANAGER	CU-003, CU-004
810
REQ-TRT-024	Le système doit permettre de distinguer les personnes présentes, attendues, absentes ou non confirmées selon le contexte d’exploitation.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-007
811 20 Antoine K
```
812 1 Redmine Admin
813 3 Antoine K
### 5.2.5 Traitement des données de muster-point
814 1 Redmine Admin
Lors d’un exercice de sécurité, d’un appel au rassemblement ou d’une situation d’urgence, PAXWARE doit traiter les informations acquises afin d’aider les équipes à suivre la confirmation des personnes.
815
Le traitement muster-point doit permettre de comparer plusieurs états :
816 31 Antoine K
```
817 1 Redmine Admin
•	personnes attendues ;
818
•	personnes détectées ;
819
•	personnes confirmées ;
820
•	personnes non confirmées ;
821
•	personnes confirmées manuellement ;
822
•	personnes en anomalie ou à vérifier.
823 31 Antoine K
```
824
```
825 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
826
REQ-TRT-030	Le système doit traiter les confirmations de présence réalisées pendant un muster-point.	ACT-002, ACT-004, PAX-MUSTER	CU-006
827
REQ-TRT-031	Le système doit comparer les personnes attendues avec les personnes confirmées pendant un muster-point.	ACT-002, PAX-MUSTER, PAX-BOX	CU-006, CU-007
828
REQ-TRT-032	Le système doit identifier les personnes non confirmées pendant un muster-point.	ACT-002, ACT-004, PAX-MUSTER	CU-007
829
REQ-TRT-033	Le système doit distinguer une confirmation automatique, une lecture volontaire et une confirmation manuelle lorsque ces modes sont utilisés.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-008
830
REQ-TRT-034	Le système doit produire un état de synthèse du muster-point exploitable par les profils autorisés.	ACT-002, ACT-003, ACT-004, PAX-MANAGER	CU-006, CU-007
831 31 Antoine K
```
832 1 Redmine Admin
833 3 Antoine K
### 5.2.6 Traitement des anomalies et incohérences
834 1 Redmine Admin
PAXWARE doit pouvoir traiter certaines situations anormales afin d’alerter les utilisateurs autorisés ou de qualifier un événement.
835
Les anomalies peuvent concerner :
836 32 Antoine K
```
837 1 Redmine Admin
•	un passage incohérent ;
838
•	une personne attendue non détectée ;
839
•	une personne non confirmée au muster-point ;
840
•	un équipement hors ligne ;
841
•	une perte de communication ;
842
•	un événement incomplet ;
843
•	une tentative d’action non autorisée ;
844
•	une absence de synchronisation ;
845
•	un stockage local saturé.
846 32 Antoine K
```
847 1 Redmine Admin
848 32 Antoine K
```
849 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
850
REQ-TRT-040	Le système doit détecter les incohérences de présence ou de passage selon les règles définies.	PAX-BOX, PAX-MANAGER	CU-012
851
REQ-TRT-041	Le système doit qualifier une anomalie selon son origine : présence, passage, muster-point, équipement, réseau ou configuration.	PAX-BOX, PAX-MANAGER	CU-008, CU-012
852
REQ-TRT-042	Le système doit signaler les anomalies critiques aux profils autorisés.	ACT-002, ACT-004, ACT-006	CU-012
853
REQ-TRT-043	Le système doit conserver une trace des anomalies traitées afin de permettre une analyse ultérieure.	PAX-BOX, PAX-MANAGER	CU-008, CU-012
854
REQ-TRT-044	Le système doit permettre de différencier une anomalie bloquante d’une anomalie non bloquante.	ACT-005, ACT-006, PAX-MANAGER	CU-009, CU-012
855 32 Antoine K
```
856 1 Redmine Admin
857 3 Antoine K
### 5.2.7 Traitement des données logistiques
858 1 Redmine Admin
Les données logistiques permettent de préparer la situation attendue sur site.
859
Elles peuvent concerner :
860 33 Antoine K
```
861 1 Redmine Admin
•	les personnes prévues à l’embarquement ;
862
•	les personnes présentes sur manifeste ;
863
•	les arrivées ;
864
•	les départs ;
865
•	les rotations ;
866
•	les affectations ;
867
•	les cabines ;
868
•	les sous-traitants ;
869
•	les visiteurs ;
870 33 Antoine K
```
871
```
872 1 Redmine Admin
Ces données doivent être traitées afin de fournir une référence de comparaison avec la présence observée.
873
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
874
REQ-TRT-050	Le système doit traiter les données logistiques afin d’établir une liste des personnes attendues sur site.	ACT-007, ACT-005, PAX-MANAGER	CU-001
875
REQ-TRT-051	Le système doit permettre de relier une personne attendue à une installation, une zone, un navire ou une affectation prévue.	ACT-007, PAX-MANAGER	CU-001, CU-004
876
REQ-TRT-052	Le système doit pouvoir traiter les informations d’arrivée et de départ afin d’actualiser la présence attendue.	ACT-007, ACT-004, PAX-MANAGER	CU-001
877
REQ-TRT-053	Le système doit permettre de distinguer les personnes permanentes, temporaires, visiteurs ou sous-traitants lorsque cette information est disponible.	ACT-007, ACT-005	CU-001
878
REQ-TRT-054	Le système doit permettre de comparer la présence attendue avec la présence observée ou confirmée.	ACT-002, ACT-004, ACT-007, PAX-BOX	CU-004, CU-006, CU-007
879 33 Antoine K
```
880 1 Redmine Admin
881 3 Antoine K
### 5.2.8 Traitement des données techniques équipements
882 1 Redmine Admin
Le système doit traiter les données techniques des équipements afin de fournir une information utile à la maintenance et à la supervision.
883
Ces traitements permettent d’identifier :
884 34 Antoine K
```
885 1 Redmine Admin
•	un équipement opérationnel ;
886
•	un équipement hors ligne ;
887
•	une perte de communication ;
888
•	une anomalie d’alimentation ;
889
•	une saturation du stockage ;
890
•	un défaut de synchronisation ;
891
•	un besoin d’intervention maintenance.
892 34 Antoine K
```
893
```
894 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
895
REQ-TRT-060	Le système doit traiter les états techniques des équipements PAXWARE afin de déterminer leur disponibilité.	ACT-006, PAX-BOX, PAX-MANAGER	CU-009
896
REQ-TRT-061	Le système doit identifier les équipements hors ligne ou ne répondant plus dans les délais attendus.	ACT-006, ACT-008, PAX-BOX	CU-009, CU-012
897
REQ-TRT-062	Le système doit produire une information de diagnostic exploitable par le Technicien maintenance.	ACT-006, PAX-MANAGER	CU-009
898
REQ-TRT-063	Le système doit traiter les informations de synchronisation afin d’identifier les données en attente de transmission.	ACT-005, ACT-008, PAX-BOX	CU-010, CU-011
899
REQ-TRT-064	Le système doit traiter l’état du stockage local afin de prévenir un risque de perte d’événements.	ACT-006, PAX-BOX	CU-010, CU-012
900 34 Antoine K
```
901 1 Redmine Admin
902 3 Antoine K
### 5.2.9 Traitement avant synchronisation différée
903 1 Redmine Admin
PAXWARE doit rester prioritairement local. La synchronisation vers un service distant ou cloud ne doit pas être indispensable au fonctionnement critique.
904
Cependant, lorsque la connexion est disponible, certaines données autorisées peuvent être préparées pour une synchronisation différée.
905
Le traitement avant synchronisation doit tenir compte :
906 35 Antoine K
```
907 1 Redmine Admin
•	des règles de confidentialité ;
908
•	des données autorisées à sortir du site ;
909
•	de la pseudonymisation éventuelle ;
910
•	de l’état de la connexion ;
911
•	des événements déjà synchronisés ;
912
•	des événements en attente ;
913
•	de la priorité des données ;
914
•	du risque de doublon.
915 35 Antoine K
```
916
```
917 1 Redmine Admin
ID exigence	Exigence de traitement	Acteurs / éléments concernés	Cas d’usage liés
918
REQ-TRT-070	Le système doit préparer les données autorisées pour une synchronisation différée lorsque la connexion distante est disponible.	PAX-BOX, Cloud PAXWARE	CU-011
919
REQ-TRT-071	Le système doit éviter la synchronisation en double d’un même événement.	PAX-BOX	CU-011
920
REQ-TRT-072	Le système doit conserver localement les données non synchronisées jusqu’à confirmation de transmission, résolution de conflit ou application d’une règle de purge définie.	PAX-BOX	CU-010, CU-011
921
REQ-TRT-073	Le système doit pouvoir distinguer les données locales critiques des données destinées à une synchronisation distante.	ACT-005, PAX-BOX	CU-010, CU-011
922
REQ-TRT-074	Le système doit respecter les règles de confidentialité définies avant toute synchronisation de données hors site.	ACT-005, ACT-008, PAX-BOX	CU-011
923 35 Antoine K
```
924 1 Redmine Admin
925 3 Antoine K
### 5.2.10 Synthèse des fonctions de traitement
926 1 Redmine Admin
Les fonctions de traitement permettent à PAXWARE de transformer des événements acquis en information fiable, lisible et exploitable.
927
Elles constituent une étape essentielle entre :
928
l’acquisition des événements terrain et l’affichage, la supervision, le muster-point, les alertes et la validation client.
929
930
Les traitements doivent permettre de :
931 36 Antoine K
```
932 1 Redmine Admin
•	déterminer la présence courante ;
933
•	interpréter les passages ;
934
•	consolider le nombre de personnes par installation ;
935
•	identifier les personnes attendues, présentes, absentes ou non confirmées ;
936
•	traiter les événements de muster-point ;
937
•	détecter les anomalies ;
938
•	préparer les informations de supervision ;
939
•	gérer les données logistiques ;
940
•	traiter l’état des équipements ;
941
•	préparer la synchronisation différée.
942 36 Antoine K
```
943 1 Redmine Admin
À ce stade du projet, les exigences sont formulées au niveau fonctionnel. Les règles détaillées de calcul, de filtrage, de seuils, de temps de latence, de priorisation, de tolérance aux erreurs et de traitement des cas limites seront précisées dans les documents de spécification globale et détaillée.
944 36 Antoine K
945 3 Antoine K
### 5.2.11 Exigences de traitement créées dans cette section
946 37 Antoine K
```
947 1 Redmine Admin
Famille	Plage d’identifiants	Objet
948
Présence	REQ-TRT-001 à REQ-TRT-005	Traitement des événements de présence
949
Passage	REQ-TRT-010 à REQ-TRT-014	Traitement des mouvements entre zones ou installations
950
Consolidation	REQ-TRT-020 à REQ-TRT-024	Consolidation du nombre de personnes par installation
951
Muster-point	REQ-TRT-030 à REQ-TRT-034	Traitement des validations de présence
952
Anomalies	REQ-TRT-040 à REQ-TRT-044	Traitement des incohérences et anomalies
953
Logistique	REQ-TRT-050 à REQ-TRT-054	Traitement des données de préparation et d’affectation
954
Équipements	REQ-TRT-060 à REQ-TRT-064	Traitement des états techniques
955
Synchronisation	REQ-TRT-070 à REQ-TRT-074	Préparation des données à synchroniser
956 37 Antoine K
```
957 1 Redmine Admin
958
Les fonctions de traitement de PAXWARE doivent transformer les événements acquis en informations opérationnelles fiables, permettant de connaître la présence par installation, de suivre les mouvements, de gérer le muster-point, d’identifier les anomalies, d’exploiter les données logistiques et de maintenir une supervision locale autonome.
959 37 Antoine K
960 3 Antoine K
## 5.3 Fonctions de commande
961 38 Antoine K
962 3 Antoine K
### 5.3.1 Principe général
963 1 Redmine Admin
Les fonctions de commande correspondent aux actions que le système PAXWARE doit pouvoir déclencher, appliquer ou transmettre à la suite d’un traitement, d’une action utilisateur ou d’un événement opérationnel.
964
Dans le cadre de PAXWARE, les fonctions de commande ne visent pas à piloter directement des équipements industriels dangereux, des machines de production ou des systèmes de sécurité critiques du client. Elles concernent principalement :
965 38 Antoine K
```
966 1 Redmine Admin
• la mise à jour des états de présence ;
967
• l’affichage d’informations sur PAX-SCREEN ;
968
• le lancement ou le suivi d’un muster-point ;
969
• la qualification d’une anomalie ;
970
• la génération d’alertes ou de notifications locales ;
971
• l’activation de certains modes de fonctionnement ;
972
• la gestion des droits et accès utilisateurs ;
973
• la demande de synchronisation différée ;
974
• certaines actions de maintenance ou de diagnostic.
975 38 Antoine K
```
976 1 Redmine Admin
Les commandes PAXWARE doivent rester encadrées par des droits utilisateurs, des règles de sécurité et une traçabilité adaptée.
977
Les exigences de commande sont identifiées avec le préfixe : REQ-CMD : Exigence de commande
978 38 Antoine K
### 5.3.2 Commandes liées à la présence et aux affectations
979 1 Redmine Admin
PAXWARE doit permettre aux profils autorisés de réaliser certaines actions sur les états de présence, les affectations ou les associations entre personnes et équipements.
980
Ces commandes doivent être réservées aux profils habilités, notamment l’Administrateur PAXWARE, la Logistique ou certains responsables opérationnels selon les règles du client.
981 38 Antoine K
```
982 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
983
REQ-CMD-001	Le système doit permettre à un profil autorisé d’associer un PAX-TAG à une personne.	ACT-005, ACT-007, PAX-WRITING	CU-002
984
REQ-CMD-002	Le système doit permettre à un profil autorisé de désassocier un PAX-TAG d’une personne.	ACT-005, ACT-007, PAX-WRITING	CU-002
985
REQ-CMD-003	Le système doit permettre à un profil autorisé de modifier l’affectation prévue d’une personne vers une installation, zone ou moyen mobile.	ACT-005, ACT-007, PAX-MANAGER	CU-001
986
REQ-CMD-004	Le système doit permettre à un profil autorisé de déclarer une personne comme embarquée, débarquée, attendue ou non attendue selon les règles d’exploitation définies.	ACT-007, ACT-004, ACT-005	CU-001, CU-004
987
REQ-CMD-005	Le système doit journaliser toute commande ayant un impact sur l’état de présence ou l’affectation d’une personne.	ACT-005, ACT-007, PAX-BOX	CU-008
988 38 Antoine K
```
989
### 5.3.3 Commandes liées au muster-point
990 1 Redmine Admin
Lors d’un exercice de sécurité ou d’une situation d’urgence, PAXWARE doit permettre aux profils autorisés de lancer, suivre, actualiser ou clôturer une opération de muster-point.
991
Ces commandes doivent rester cohérentes avec les procédures HSE officielles du site.
992
PAXWARE ne remplace pas la décision humaine ni les procédures de sécurité du client. Il fournit un support opérationnel permettant de fiabiliser et d’accélérer la consolidation des informations.
993 38 Antoine K
994
```
995 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
996
REQ-CMD-010	Le système doit permettre à un profil autorisé de lancer une opération de muster-point.	ACT-002, ACT-004, PAX-MUSTER	CU-006
997
REQ-CMD-011	Le système doit permettre à un profil autorisé de confirmer manuellement la présence d’une personne lorsque la procédure terrain le justifie.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-007
998
REQ-CMD-012	Le système doit permettre à un profil autorisé de qualifier une personne comme non confirmée, à vérifier ou confirmée selon l’état du muster-point.	ACT-002, ACT-004, PAX-MUSTER	CU-006, CU-007
999
REQ-CMD-013	Le système doit permettre à un profil autorisé de clôturer une opération de muster-point.	ACT-002, ACT-004, ACT-003	CU-006
1000
REQ-CMD-014	Le système doit conserver une trace des commandes réalisées pendant une opération de muster-point.	ACT-002, ACT-004, PAX-BOX	CU-006, CU-008
1001 38 Antoine K
```
1002 1 Redmine Admin
1003 38 Antoine K
### 5.3.4 Commandes liées à l’affichage local
1004 1 Redmine Admin
PAXWARE doit pouvoir transmettre des informations synthétiques aux dispositifs d’affichage local, notamment les PAX-SCREEN ou les configurations PAX-NAV / PAX-SCREEN NAVIRE.
1005
Ces commandes d’affichage ne doivent pas être considérées comme des commandes de sécurité critiques, mais comme des commandes d’information opérationnelle.
1006
Elles doivent permettre une lecture rapide et compréhensible par les équipes terrain.
1007 38 Antoine K
```
1008 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
1009
REQ-CMD-020	Le système doit pouvoir commander l’affichage du nombre de personnes présentes sur un PAX-SCREEN.	PAX-BOX, PAX-SCREEN	CU-005
1010
REQ-CMD-021	Le système doit pouvoir mettre à jour l’affichage local lorsque le nombre de personnes par installation évolue.	PAX-BOX, PAX-SCREEN	CU-004, CU-005
1011
REQ-CMD-022	Le système doit pouvoir afficher un état synthétique lié à une zone, une installation ou un moyen mobile.	PAX-BOX, PAX-SCREEN, PAX-NAV	CU-005
1012
REQ-CMD-023	Le système doit pouvoir signaler visuellement une information d’anomalie ou d’état dégradé lorsque cette fonction est prévue dans le périmètre retenu.	PAX-BOX, PAX-SCREEN	CU-012
1013
REQ-CMD-024	Le système doit éviter l’affichage d’une information considérée comme invalide, obsolète ou non confirmée sans indication appropriée.	PAX-BOX, PAX-SCREEN	CU-005, CU-012
1014 38 Antoine K
```
1015 1 Redmine Admin
1016 38 Antoine K
### 5.3.5 Commandes liées aux anomalies
1017 1 Redmine Admin
PAXWARE doit permettre aux profils autorisés de traiter, qualifier ou acquitter certaines anomalies.
1018
L’objectif n’est pas de masquer les défauts, mais de permettre une gestion claire et tracée des écarts observés.
1019
Les anomalies peuvent concerner :
1020 38 Antoine K
```
1021 1 Redmine Admin
• une incohérence de présence ;
1022
• une personne attendue mais non confirmée ;
1023
• un PAX-TAG non reconnu ;
1024
• une PAX-ANT hors ligne ;
1025
• une PAX-SCREEN non joignable ;
1026
• une perte de communication ;
1027
• une anomalie de synchronisation ;
1028
• une saturation de stockage ;
1029
• une action utilisateur non autorisée.
1030 38 Antoine K
```
1031
```
1032 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
1033
REQ-CMD-030	Le système doit permettre à un profil autorisé de qualifier une anomalie selon les catégories définies.	ACT-002, ACT-004, ACT-006, PAX-MANAGER	CU-012
1034
REQ-CMD-031	Le système doit permettre à un profil autorisé d’acquitter une anomalie lorsque celle-ci a été traitée ou prise en compte.	ACT-002, ACT-004, ACT-006	CU-012
1035
REQ-CMD-032	Le système doit conserver une trace de l’acquittement ou de la qualification d’une anomalie.	PAX-BOX, PAX-MANAGER	CU-008, CU-012
1036
REQ-CMD-033	Le système doit empêcher l’acquittement non autorisé d’une anomalie critique.	ACT-005, PAX-MANAGER	CU-012
1037
REQ-CMD-034	Le système doit permettre de distinguer les anomalies opérationnelles des anomalies techniques.	ACT-002, ACT-004, ACT-006	CU-009, CU-012
1038 38 Antoine K
```
1039 1 Redmine Admin
1040 38 Antoine K
### 5.3.6 Commandes liées à la maintenance et au diagnostic
1041 1 Redmine Admin
Le système doit permettre certaines commandes de maintenance ou de diagnostic, réservées aux profils autorisés.
1042
Ces commandes doivent être limitées aux besoins d’exploitation et de support, afin d’éviter toute action involontaire pouvant perturber le fonctionnement du système.
1043
Elles peuvent concerner :
1044 38 Antoine K
```
1045 1 Redmine Admin
• le lancement d’un diagnostic ;
1046
• la demande d’état d’un équipement ;
1047
• le redémarrage contrôlé d’un module non critique ;
1048
• la vérification de communication ;
1049
• l’export de journaux techniques ;
1050
• le test d’un PAX-SCREEN ;
1051
• le contrôle d’une PAX-ANT.
1052 38 Antoine K
```
1053
```
1054 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
1055
REQ-CMD-040	Le système doit permettre à un profil maintenance autorisé de lancer un diagnostic sur un équipement PAXWARE.	ACT-006, ACT-008, PAX-MANAGER	CU-009
1056
REQ-CMD-041	Le système doit permettre à un profil autorisé de demander l’état courant d’un équipement connecté.	ACT-006, PAX-BOX, PAX-MANAGER	CU-009
1057
REQ-CMD-042	Le système doit permettre à un profil autorisé d’exporter des journaux techniques pour analyse.	ACT-006, ACT-008, PAX-MANAGER	CU-009, CU-008
1058
REQ-CMD-043	Le système doit encadrer toute commande de redémarrage ou de réinitialisation afin d’éviter une perte d’information critique.	ACT-006, ACT-008, PAX-BOX	CU-009, CU-010
1059
REQ-CMD-044	Le système doit journaliser les commandes de maintenance ou de diagnostic réalisées par un profil autorisé.	ACT-006, ACT-008, PAX-BOX	CU-009, CU-008
1060 38 Antoine K
```
1061 1 Redmine Admin
1062 38 Antoine K
### 5.3.7 Commandes liées à la synchronisation différée
1063 1 Redmine Admin
La synchronisation différée permet de transmettre certaines données autorisées vers un serveur distant ou cloud lorsque la connexion est disponible.
1064
Cette commande ne doit pas remettre en cause le fonctionnement local du système.
1065
La PAX-BOX doit rester prioritaire pour les fonctions critiques.
1066 38 Antoine K
```
1067 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
1068
REQ-CMD-050	Le système doit pouvoir déclencher une synchronisation différée lorsque la connexion distante est disponible.	PAX-BOX, Cloud PAXWARE	CU-011
1069
REQ-CMD-051	Le système doit permettre à un profil autorisé de consulter l’état de synchronisation.	ACT-005, ACT-008, PAX-MANAGER	CU-011
1070
REQ-CMD-052	Le système doit empêcher l’envoi de données non autorisées vers un service distant.	ACT-005, ACT-008, PAX-BOX	CU-011
1071
REQ-CMD-053	Le système doit conserver localement les données tant que leur synchronisation n’est pas confirmée, traitée selon une règle définie ou placée en file de conflit à résoudre.	PAX-BOX	CU-010, CU-011
1072
REQ-CMD-054	Le système doit journaliser les opérations de synchronisation réalisées ou échouées.	PAX-BOX, Cloud PAXWARE	CU-011, CU-008
1073 38 Antoine K
```
1074 1 Redmine Admin
1075
5.3.8 Commandes liées aux droits utilisateurs
1076
Certaines commandes PAXWARE concernent la gestion des droits et profils utilisateurs.
1077
Ces commandes doivent être strictement contrôlées, car elles peuvent avoir un impact sur la sécurité, la confidentialité et l’exploitation du système.
1078 38 Antoine K
```
1079 1 Redmine Admin
ID exigence	Exigence de commande	Acteurs / éléments concernés	Cas d’usage liés
1080
REQ-CMD-060	Le système doit permettre à un profil autorisé de créer, modifier ou désactiver un compte utilisateur.	ACT-005, PAX-MANAGER	CU-008
1081
REQ-CMD-061	Le système doit permettre à un profil autorisé d’attribuer ou modifier les droits d’accès d’un utilisateur.	ACT-005, PAX-MANAGER	CU-008
1082
REQ-CMD-062	Le système doit empêcher un utilisateur non autorisé d’accéder aux commandes sensibles.	ACT-005, PAX-MANAGER	CU-008
1083
REQ-CMD-063	Le système doit journaliser les modifications de droits et de profils utilisateurs.	ACT-005, PAX-BOX	CU-008
1084
REQ-CMD-064	Le système doit permettre de désactiver rapidement un accès utilisateur en cas de départ, changement de rôle ou incident de sécurité.	ACT-005, PAX-MANAGER	CU-008
1085 38 Antoine K
```
1086 1 Redmine Admin
1087 38 Antoine K
### 5.3.9 Synthèse des fonctions de commande
1088 1 Redmine Admin
Les fonctions de commande permettent à PAXWARE de déclencher, appliquer ou transmettre des actions contrôlées à partir des données traitées ou des interventions utilisateurs.
1089
Elles concernent principalement :
1090 38 Antoine K
```
1091 1 Redmine Admin
• les associations entre personnes et PAX-TAG ;
1092
• les affectations ;
1093
• le lancement et le suivi des muster-points ;
1094
• les affichages locaux ;
1095
• la qualification des anomalies ;
1096
• les diagnostics maintenance ;
1097
• la synchronisation différée ;
1098
• la gestion des droits utilisateurs.
1099 38 Antoine K
```
1100 1 Redmine Admin
Les fonctions de commande doivent rester compatibles avec les principes fondamentaux du projet :
1101 38 Antoine K
```
1102 1 Redmine Admin
• fonctionnement local prioritaire ;
1103
• cloud secondaire ;
1104
• traçabilité des actions ;
1105
• droits utilisateurs maîtrisés ;
1106
• confidentialité des données ;
1107
• non-remplacement des procédures HSE officielles ;
1108
• absence de commande directe sur des équipements industriels dangereux dans le périmètre initial.
1109 38 Antoine K
```
1110 1 Redmine Admin
5.3.10 Exigences de commande créées dans cette section
1111 38 Antoine K
```
1112 1 Redmine Admin
Famille	Plage d’identifiants	Objet
1113
Présence et affectations	REQ-CMD-001 à REQ-CMD-005	Commandes liées aux associations, états et affectations
1114
Muster-point	REQ-CMD-010 à REQ-CMD-014	Commandes liées au lancement, suivi et clôture muster-point
1115
Affichage local	REQ-CMD-020 à REQ-CMD-024	Commandes vers PAX-SCREEN et affichage synthétique
1116
Anomalies	REQ-CMD-030 à REQ-CMD-034	Qualification, acquittement et traçabilité des anomalies
1117
Maintenance	REQ-CMD-040 à REQ-CMD-044	Diagnostic, état équipements et commandes maintenance
1118
Synchronisation	REQ-CMD-050 à REQ-CMD-054	Commandes liées à la synchronisation différée
1119
Droits utilisateurs	REQ-CMD-060 à REQ-CMD-064	Création, modification, désactivation et traçabilité des droits
1120 38 Antoine K
```
1121 1 Redmine Admin
1122
Les fonctions de commande de PAXWARE doivent permettre aux profils autorisés de déclencher des actions contrôlées sur les affectations, le muster-point, l’affichage local, les anomalies, la maintenance, la synchronisation et les droits utilisateurs, sans piloter directement d’équipements industriels dangereux dans le périmètre initial.
1123
1124 38 Antoine K
## 5.4 Exigences de performance et levée d’ambiguïté technologique
1125 1 Redmine Admin
Cette section intègre les corrections issues de l’analyse du prompt d’amélioration. Elle transforme les ambiguïtés technologiques en exigences mesurables, tout en conservant le principe du cycle en V : les valeurs ci-dessous sont des valeurs cibles MVP/POC, à confirmer par essais terrain, choix de composants et analyse de risque client.
1126
1127 38 Antoine K
```
1128 1 Redmine Admin
ID exigence	Exigence de performance	Valeur cible MVP / POC	Critère de validation associé
1129
REQ-PERF-001	Le système doit distinguer clairement la lecture volontaire courte portée du muster-point et la détection radio de zone.	NFC/RFID : contact ou très courte portée. Détection radio de zone : rayon configurable selon site.	Essai comparatif démontrant que les deux modes ne produisent pas le même statut sans règle de validation.
1130
REQ-PERF-002	La PAX-ANT installée sur un point de passage doit couvrir une zone de passage contrôlée et limiter les détections parasites hors zone utile.	Zone utile cible : 1 à 3 m autour du point de passage selon installation ; portée réglable ou filtrable.	Essai de passage avec tags proches mais hors zone utile, sans comptage erroné.
1131
REQ-PERF-003	La PAX-ANT doit pouvoir recevoir plusieurs PAX-TAG présents dans son environnement radio sans collision bloquante de données.	Cible POC : au moins 50 PAX-TAG en visibilité radio, sans perte critique d’événements exploitables.	Test de charge radio avec tags multiples et contrôle des événements réellement enregistrés.
1132
REQ-PERF-004	Le traitement directionnel d’un passage doit rester fondé sur une séquence validée et non sur une simple présence radio.	Comptage directionnel qualifié seulement si la séquence de passage est cohérente.	Essai entrée/sortie, demi-tour, stationnement proche antenne, passage ambigu.
1133
REQ-PERF-005	Le PAX-SCREEN doit être mis à jour après un événement de passage validé dans un délai compatible avec l’exploitation terrain.	Cible normale : moins de 5 s. Cible en transfert massif : moins de 15 s après traitement local.	Mesure de latence entre événement validé PAX-BOX et affichage PAX-SCREEN.
1134
REQ-PERF-006	Le système doit maintenir la cohérence de comptage lors d’un flux important de personnel.	Cible POC : 50 personnes transférées en 10 minutes sans écart non qualifié.	Test scénario transfert massif avec comparaison liste attendue / événements / affichage.
1135
REQ-PERF-007	Les événements ambigus doivent être qualifiés plutôt que transformés automatiquement en présence certaine.	Statuts minimaux : validé, ambigu, non exploitable, à lever.	Contrôle dans PAX-MANAGER des cas volontairement ambigus.
1136
REQ-PERF-008	Les seuils de performance doivent être révisables à l’issue du POC sans casser la traçabilité des exigences.	Versionnage des seuils et justification de modification.	Journal de modification des exigences et matrice de traçabilité mise à jour.
1137 38 Antoine K
```
1138
## 5.5 Exigences matérielles, environnementales et industrielles
1139 1 Redmine Admin
Les exigences matérielles suivantes complètent le périmètre existant. Elles préparent les futures spécifications détaillées hardware, les essais environnementaux et les arbitrages ATEX / IECEx. Elles ne figent pas encore le fournisseur ni le composant, mais définissent des cibles minimales de conception industrielle.
1140 38 Antoine K
```
1141 1 Redmine Admin
ID exigence	Exigence matérielle / environnementale	Cible minimale	Équipements concernés
1142
REQ-MAT-001	Les PAX-ANT destinées à une installation extérieure offshore doivent présenter une protection contre poussière, embruns et projections d’eau.	IP66 minimum ; IP67 cible pour zones exposées.	PAX-ANT
1143
REQ-MAT-002	Les PAX-SCREEN destinés à l’affichage terrain doivent présenter une protection environnementale compatible avec embruns, pluie et nettoyage courant.	IP66 minimum ; IP67 cible selon implantation.	PAX-SCREEN, PAX-SCREEN NAVIRE
1144
REQ-MAT-003	Le PAX-TAG doit être conçu pour une utilisation prolongée en environnement humide, salin et contraignant.	IP67 cible, boîtier fermé ou scellé, résistance à l’usage quotidien.	PAX-TAG
1145
REQ-MAT-004	Le PAX-TAG doit disposer d’une autonomie compatible avec l’exploitation offshore et les rotations longues.	36 mois cible en conditions nominales ; 24 mois minimum en conditions sévères à confirmer par essais.	PAX-TAG
1146
REQ-MAT-005	Les équipements exposés doivent être dimensionnés pour fonctionner malgré fortes chaleurs et variations de température.	Plage cible : -20 °C à +70 °C pour surfaces ou zones exposées, à confirmer par implantation.	PAX-ANT, PAX-SCREEN, PAX-TAG
1147
REQ-MAT-006	Les communications terrain doivent intégrer des mécanismes de tolérance aux interférences et aux structures métalliques massives.	Filtrage signal, répétition contrôlée, accusé de réception lorsque disponible, diagnostic qualité liaison.	PAX-ANT, PAX-BOX, PAX-NAV
1148
REQ-MAT-007	La perte temporaire d’une liaison terrain ne doit pas entraîner la perte immédiate des événements critiques.	Tampon local ou reprise contrôlée selon équipement.	PAX-ANT, PAX-BOX
1149
REQ-MAT-008	La conception industrielle doit anticiper les contraintes ATEX / IECEx lorsque l’installation cible se trouve en zone classée.	Analyse de zone et stratégie de certification avant installation en zone à risque.	Tous équipements terrain
1150 38 Antoine K
```
1151
## 5.6 Gestion du facteur humain et des cas dégradés
1152 1 Redmine Admin
PAXWARE ne doit pas seulement remplacer une carte papier par un identifiant numérique. Le système doit aider les équipes à lever les doutes créés par les oublis, les bracelets non portés, les tags non associés, les anomalies de passage ou les incohérences entre présence attendue et présence observée.
1153 38 Antoine K
```
1154 1 Redmine Admin
ID exigence	Exigence cas dégradé / facteur humain	Traitement attendu	Cas d’usage liés
1155
REQ-DEG-001	Le système doit détecter qu’une personne attendue sur site ne possède pas de PAX-TAG associé.	Anomalie “personne attendue sans tag associé” visible par Logistique, HSE ou Administrateur.	CU-001, CU-002, CU-012
1156
REQ-DEG-002	Si une présence non associée est signalée par un profil autorisé, le système doit permettre de créer une anomalie de présence non identifiée.	Création d’un événement manuel tracé, avec levée de doute obligatoire.	CU-007, CU-012
1157
REQ-DEG-003	Le système ne doit pas prétendre identifier automatiquement une personne sans PAX-TAG en l’absence de capteur indépendant prévu au périmètre.	Statut “non identifiable automatiquement” ; procédure humaine de contrôle.	CU-012
1158
REQ-DEG-004	Le système doit détecter les PAX-TAG immobiles ou non actifs sur une durée anormale lorsque cette information est exploitable.	Alerte “tag immobile suspect” ou “tag potentiellement laissé en cabine” selon règle client.	CU-006, CU-007, CU-012
1159
REQ-DEG-005	Lors d’un muster-point, un PAX-TAG détecté en zone vie ou cabine ne doit pas suffire à confirmer automatiquement la personne au point de rassemblement.	Confirmation distincte par lecture muster, présence radio zone muster qualifiée ou validation manuelle autorisée.	CU-006, CU-007
1160
REQ-DEG-006	Le système doit permettre la levée de doute d’une incohérence entrée/sortie, d’un demi-tour ou d’un passage ambigu.	Statut anomalie + action de qualification par Barge-Master, HSE ou profil autorisé.	CU-003, CU-012
1161
REQ-DEG-007	Le système doit conserver une trace des corrections manuelles réalisées par les utilisateurs autorisés.	Journal horodaté : auteur, motif, ancienne valeur, nouvelle valeur.	CU-008, CU-012
1162
REQ-DEG-008	Le système doit fournir au Barge-Master et au Responsable HSE une liste priorisée des personnes à lever de doute.	Tri par criticité : non confirmée muster, passage ambigu, tag non associé, tag immobile suspect.	CU-006, CU-007, CU-012
1163 38 Antoine K
```
1164 39 Antoine K
1165 38 Antoine K
## 5.7 Cybersécurité, confidentialité et protection des données
1166 1 Redmine Admin
Cette section complète les principes déjà indiqués dans le document : fonctionnement local prioritaire, cloud secondaire, pseudonymisation et accès support encadré. Les exigences ci-dessous devront être alignées avec l’architecture finale, le RGPD, la politique du client et les contraintes de cybersécurité du site.
1167 39 Antoine K
1168
```
1169 1 Redmine Admin
ID exigence	Exigence cybersécurité / confidentialité	Règle attendue	Acteurs / éléments concernés
1170
REQ-SEC-001	Les communications entre équipements terrain et PAX-BOX doivent être protégées contre l’écoute, l’injection et la modification non autorisée.	Chiffrement ou protection cryptographique adaptée au protocole retenu ; authentification des équipements.	PAX-ANT, PAX-BOX, PAX-NAV
1171
REQ-SEC-002	Les échanges IP entre PAX-BOX, PAX-MANAGER et services distants doivent utiliser un canal sécurisé.	TLS ou VPN selon architecture client.	PAX-BOX, PAX-MANAGER, Cloud
1172
REQ-SEC-003	Les données nominatives doivent rester prioritairement stockées sur la PAX-BOX ou dans le périmètre client.	Cloud limité aux données autorisées, pseudonymisées ou agrégées selon règle client.	PAX-BOX, Cloud
1173
REQ-SEC-004	Le système doit permettre une purge locale contrôlée des données après synchronisation ou après expiration de durée de conservation.	Purge paramétrable, traçable, sans suppression des journaux nécessaires à l’audit avant délai autorisé.	PAX-BOX, ACT-005
1174
REQ-SEC-005	L’accès de l’équipe PAXWARE support doit être autorisé explicitement par le client.	Accès temporaire, limité, journalisé, révocable et justifié.	ACT-008, ACT-005
1175
REQ-SEC-006	Les interventions support distantes doivent être sécurisées.	Authentification forte, compte nominatif, périmètre d’accès limité, journal d’intervention.	ACT-008
1176
REQ-SEC-007	Les actions sensibles doivent être journalisées.	Connexion, modification droits, export, purge, association tag, validation manuelle, intervention support.	ACT-005, ACT-008, PAX-MANAGER
1177
REQ-SEC-008	Le système doit séparer les droits selon les rôles utilisateurs.	Principe du moindre privilège : HSE, Barge-Master, Logistique, Maintenance, Administrateur, Support.	ACT-002 à ACT-008
1178
REQ-SEC-009	Les exports de rapports doivent être contrôlés.	Droits dédiés, traçabilité, limitation des données personnelles selon besoin.	ACT-002, ACT-003, ACT-005
1179 40 Antoine K
```
1180
## 5.8 Synchronisation différée et gestion des conflits
1181 1 Redmine Admin
Le mode offline étant prioritaire, la synchronisation différée doit être pensée comme un mécanisme de continuité, non comme une dépendance. La PAX-BOX locale constitue la référence opérationnelle pour les événements terrain produits pendant une période d’isolement réseau.
1182 40 Antoine K
```
1183 1 Redmine Admin
ID exigence	Exigence synchronisation / conflit	Règle de gestion proposée	Cas d’usage liés
1184
REQ-SYNC-001	La PAX-BOX doit rester source de vérité pour les événements opérationnels générés localement pendant une perte réseau.	Les passages, confirmations muster et anomalies terrain ne doivent pas être écrasés par le cloud.	CU-010, CU-011
1185
REQ-SYNC-002	Les événements terrain doivent être synchronisés selon un modèle append-only.	Ajout horodaté, pas de suppression silencieuse, identifiant unique événement.	CU-008, CU-011
1186
REQ-SYNC-003	En cas de modification simultanée locale et distante d’une donnée d’administration, le système doit détecter un conflit.	Comparaison version / horodatage / auteur ; mise en file de conflit.	CU-011, CU-012
1187
REQ-SYNC-004	Les conflits sur données critiques ne doivent pas être résolus automatiquement sans règle validée.	Résolution par administrateur autorisé ou règle client documentée.	CU-011, CU-012
1188
REQ-SYNC-005	La synchronisation doit être priorisée pour ne pas saturer la bande passante limitée du site.	Priorité : sécurité/anomalies, états courants, événements récents, historiques, journaux techniques lourds.	CU-010, CU-011
1189
REQ-SYNC-006	Le système doit utiliser une file d’attente de synchronisation locale.	Files par priorité, reprise après coupure, limitation de débit configurable.	CU-011
1190
REQ-SYNC-007	La synchronisation doit éviter les doublons.	Identifiant unique événement + accusé de réception + statut synchronisé/non synchronisé.	CU-011
1191
REQ-SYNC-008	Le système doit afficher l’état de synchronisation aux profils autorisés.	Connecté, déconnecté, en attente, en erreur, conflit, dernière synchronisation réussie.	CU-010, CU-011
1192
REQ-SYNC-009	En cas de stockage local proche de la saturation, le système doit alerter et préserver les événements critiques.	Seuils recommandés : alerte à 80 %, critique à 90 %, blocage ou purge contrôlée des données non critiques selon règle validée.	CU-010, CU-012
1193
REQ-SYNC-010	La purge des données synchronisées doit être contrôlée par une règle de conservation.	Purge uniquement après confirmation, délai minimum, journalisation et compatibilité audit.	CU-008, CU-011
1194
```
1195 40 Antoine K
1196 39 Antoine K
## 5.9 Synthèse des exigences complémentaires intégrées
1197
1198
```
1199 1 Redmine Admin
Famille	Plage d’identifiants	Objet
1200
Performance	REQ-PERF-001 à REQ-PERF-008	Seuils de portée, capacité, latence, ambiguïté et validation POC
1201
Matériel / environnement	REQ-MAT-001 à REQ-MAT-008	IP, autonomie, température, interférences, ATEX / IECEx
1202
Cas dégradés / humain	REQ-DEG-001 à REQ-DEG-008	Oublis, tags non associés, tags immobiles, levée de doute
1203
Cybersécurité	REQ-SEC-001 à REQ-SEC-010	Chiffrement, droits, support ACT-008, purge, confidentialité
1204
Synchronisation	REQ-SYNC-001 à REQ-SYNC-010	Mode offline, conflits, file d’attente, bande passante, saturation stockage
1205
Ces exigences complémentaires devront être reprises dans la matrice de traçabilité du cycle en V. Chaque exigence devra être reliée à un cas d’usage, un module PAXWARE, un scénario de test, un critère d’acceptation et un responsable de validation.
1206 39 Antoine K
```
1207 1 Redmine Admin
1208
1209
1210
1211
1212
1213
1214
1215 41 Antoine K
# 6. Exigences non fonctionnelles et contraintes globales
1216 1 Redmine Admin
Cette section regroupe les exigences transversales que le système PAXWARE doit respecter pour être exploitable, robuste, maintenable et acceptable en environnement offshore. Ces exigences ne décrivent pas directement une fonction utilisateur, mais les conditions de performance, de disponibilité, de sécurité, d’ergonomie et de conformité que l’ensemble de l’écosystème doit satisfaire.
1217
Les exigences de cette section complètent les fonctions attendues de la partie 5. Elles serviront de base aux futures spécifications détaillées, au plan d’intégration, au plan de tests et au cahier de recette client.
1218
Les exigences non fonctionnelles sont identifiées avec le préfixe :
1219
REQ-NF : Exigence non fonctionnelle ou contrainte globale
1220 41 Antoine K
## 6.1 Principe général
1221 1 Redmine Admin
PAXWARE doit être conçu comme un système industriel local, autonome et compréhensible par des équipes opérationnelles. Le système doit rester utilisable dans des conditions offshore réelles : connectivité limitée, environnement métallique, météo contraignante, disponibilité 24/7, contraintes de sécurité, rotation du personnel et besoin de décision rapide.
1222
Les exigences non fonctionnelles ont pour objectif de garantir que les fonctions de présence, de passage, de muster-point, d’affichage, de supervision et de synchronisation restent fiables dans la durée.
1223
•	la disponibilité du système sur site ;
1224
•	le fonctionnement local même sans internet ;
1225
•	la robustesse environnementale et industrielle ;
1226
•	la sécurité des données et des accès ;
1227
•	l’ergonomie pour les utilisateurs terrain ;
1228
•	la maintenance et le diagnostic ;
1229
•	l’installation sur site client ;
1230
•	la conformité réglementaire et la préparation ATEX / IECEx ;
1231
•	la délimitation claire du MVP / POC.
1232 41 Antoine K
## 6.2 Disponibilité et continuité de service
1233 1 Redmine Admin
Le système PAXWARE doit être disponible pour les usages critiques d’exploitation, de transfert et de muster-point. Les fonctions locales doivent rester prioritaires sur les services distants afin d’éviter toute rupture d’information en cas de perte réseau.
1234 41 Antoine K
1235
```
1236 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1237
REQ-NF-001	Le système doit être conçu pour une exploitation locale continue en environnement offshore, avec une disponibilité cible compatible avec un fonctionnement 24/7.	PAX-BOX, PAX-MANAGER, PAX-SCREEN, PAX-MUSTER	Démontrer la continuité des fonctions critiques pendant une période d’essai définie en POC.
1238
REQ-NF-002	Les fonctions critiques de présence, comptage, affichage local et muster-point ne doivent pas dépendre d’une connexion internet permanente.	PAX-BOX, PAX-SCREEN, PAX-MUSTER	Tester les fonctions critiques avec connexion distante coupée.
1239
REQ-NF-003	Une perte temporaire de communication avec un équipement doit être signalée sans bloquer l’ensemble du système.	PAX-ANT, PAX-SCREEN, PAX-MUSTER, PAX-BOX	Simuler une perte équipement et vérifier la remontée d’anomalie.
1240
REQ-NF-004	Le système doit conserver localement les événements nécessaires à la continuité d’exploitation en cas de perte de connexion distante.	PAX-BOX, base locale	Vérifier la conservation des événements pendant une période offline.
1241
REQ-NF-005	La reprise après coupure d’alimentation ou redémarrage contrôlé doit préserver les derniers états exploitables et les journaux utiles.	PAX-BOX, base locale	Effectuer un redémarrage contrôlé et vérifier l’intégrité des données.
1242
REQ-NF-006	Le système doit distinguer une indisponibilité technique d’un équipement d’une absence réelle de personnel.	PAX-BOX, PAX-MANAGER	Générer une anomalie technique et vérifier que le comptage n’est pas interprété comme un départ terrain.
1243 41 Antoine K
```
1244
## 6.3 Fonctionnement local et mode offline
1245 1 Redmine Admin
Le mode local est un principe structurant de PAXWARE. La PAX-BOX doit être considérée comme la référence opérationnelle du site lorsque la connectivité distante est absente, instable ou volontairement limitée par le client.
1246 41 Antoine K
```
1247 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1248
REQ-NF-010	En mode offline, la PAX-BOX doit rester la source de référence pour les données de présence du site.	PAX-BOX, PAX-MANAGER	Comparer les données locales et distantes lors d’un scénario de coupure réseau.
1249
REQ-NF-011	Le système doit permettre la consultation locale des présences, événements et états équipements sans accès cloud.	PAX-BOX, PAX-MANAGER	Vérifier l’accès aux vues locales sans internet.
1250
REQ-NF-012	Le système doit mettre en file d’attente les événements à synchroniser sans perturber le traitement local.	PAX-BOX, module synchronisation	Créer des événements offline et vérifier la file d’attente après reconnexion.
1251
REQ-NF-013	Le système doit gérer une saturation progressive du stockage local par alerte, priorisation et conservation minimale des événements critiques.	PAX-BOX, stockage local	Simuler un seuil de stockage et vérifier les alertes et règles de conservation.
1252
REQ-NF-014	Le système doit documenter les règles de priorité entre données locales et données distantes lors de la reconnexion.	PAX-BOX, Cloud, PAX-MANAGER	Vérifier les règles sur un scénario de conflit volontaire.
1253
REQ-NF-015	La synchronisation différée ne doit pas saturer la bande passante du site et doit pouvoir être limitée, planifiée ou priorisée.	PAX-BOX, Cloud, réseau client	Limiter le débit ou simuler une connexion lente et vérifier la continuité locale.
1254 41 Antoine K
```
1255
## 6.4 Robustesse environnementale et industrielle
1256 1 Redmine Admin
Les équipements PAXWARE doivent être conçus pour des environnements sévères : structures métalliques, embruns, humidité, chaleur, vibrations, poussières, pluie, chocs opérationnels et contraintes d’installation sur passerelles, boat landing, zones de vie ou locaux techniques.
1257 41 Antoine K
```
1258 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1259
REQ-NF-020	Les équipements installés en extérieur doivent viser un niveau de protection compatible avec les projections d’eau, poussières, embruns et nettoyage courant.	PAX-ANT, PAX-SCREEN, PAX-NAV	Vérifier la conformité de l’indice IP retenu dans les spécifications matérielles.
1260
REQ-NF-021	Les équipements terrain doivent être conçus pour limiter les effets de corrosion liés à l’environnement marin.	Boîtiers, fixations, connectique	Contrôler les matériaux, traitements et choix de connectique dans le dossier hardware.
1261
REQ-NF-022	Le système doit tolérer les perturbations radio liées aux masses métalliques et aux effets de cage de Faraday par choix d’implantation, filtrage et redondance de détection lorsque nécessaire.	PAX-ANT, PAX-TAG, PAX-BOX	Réaliser des essais de détection en zone métallique représentative.
1262
REQ-NF-023	Les équipements doivent être adaptés à une exploitation en température élevée selon le profil environnemental du site pilote.	PAX-TAG, PAX-ANT, PAX-SCREEN, PAX-BOX	Définir une plage de température cible dans la spécification matérielle et la vérifier en essai.
1263
REQ-NF-024	Les fixations doivent permettre une installation stable, inspectable et compatible avec les supports offshore courants.	PAX-ANT, PAX-SCREEN, PAX-NAV	Vérifier la tenue mécanique et la facilité d’inspection sur support représentatif.
1264
REQ-NF-025	La conception doit éviter les câbles, pièces ou modes de montage exposant inutilement le personnel à un risque d’accrochage, de chute ou d’arrachement.	Tous équipements terrain	Revue HSE d’installation avant POC.
1265 41 Antoine K
```
1266
## 6.5 Performance globale et capacité d’évolution
1267 1 Redmine Admin
Les performances cibles doivent rester mesurables sans figer prématurément tous les choix technologiques. Les valeurs définitives seront confirmées par les essais terrain, mais le cahier des charges doit poser des seuils vérifiables pour préparer la recette client.
1268 41 Antoine K
1269
```
1270 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1271
REQ-NF-030	Le système doit permettre une mise à jour exploitable du nombre de personnes par installation dans un délai compatible avec la prise de décision terrain.	PAX-BOX, PAX-SCREEN, PAX-MANAGER	Mesurer le délai entre événement terrain et affichage.
1272
REQ-NF-031	Le système doit pouvoir traiter des mouvements groupés de personnel sans perte manifeste d’événements exploitables.	PAX-ANT, PAX-BOX	Réaliser un scénario de transfert massif contrôlé.
1273
REQ-NF-032	Le dimensionnement initial doit couvrir un site pilote multi-installations avec plusieurs points de passage et un volume de personnel représentatif.	Architecture système	Valider le dimensionnement POC avec le client pilote.
1274
REQ-NF-033	L’architecture doit permettre l’ajout progressif de zones, installations, écrans et antennes sans remise en cause complète du système.	PAX-BOX, réseau local, PAX-MANAGER	Tester l’ajout d’un équipement ou d’une zone dans un environnement de recette.
1275
REQ-NF-034	Les performances doivent être suivies par des indicateurs exploitables : latence, taux d’événements ambigus, équipements hors ligne, saturation stockage, échecs de synchronisation.	PAX-MANAGER, PAX-BOX	Vérifier la présence des indicateurs dans la supervision.
1276 41 Antoine K
```
1277
## 6.6 Cybersécurité, confidentialité et accès
1278 1 Redmine Admin
La cybersécurité doit être intégrée dès l’architecture. PAXWARE manipule des données de présence opérationnelles et peut traiter des associations entre identifiants et personnes. Les principes de minimisation, séparation des droits, journalisation et chiffrement doivent être appliqués selon le niveau de risque et le périmètre client.
1279 41 Antoine K
```
1280 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1281
REQ-NF-040	Les échanges entre équipements PAXWARE et PAX-BOX doivent être protégés contre les interceptions ou modifications non autorisées selon le protocole retenu.	PAX-ANT, PAX-MUSTER, PAX-BOX	Revue cybersécurité de l’architecture de communication.
1282
REQ-NF-041	Les accès utilisateurs doivent être attribués selon le principe du moindre privilège.	PAX-MANAGER, comptes utilisateurs	Vérifier les profils ACT-002 à ACT-008 et leurs droits.
1283
REQ-NF-042	Les actions sensibles doivent être journalisées : association tag/personne, modification droits, validation manuelle muster, changement configuration, accès support.	PAX-MANAGER, PAX-BOX	Contrôler les journaux après actions sensibles.
1284
REQ-NF-043	L’accès de l’équipe PAXWARE support doit être autorisé par le client, limité dans le temps, sécurisé et journalisé.	ACT-008, PAX-BOX, PAX-MANAGER	Tester un scénario d’accès support avec trace d’autorisation.
1285
REQ-NF-044	Les données nominatives doivent être limitées au besoin opérationnel et protégées contre les consultations non autorisées.	Base locale, PAX-MANAGER	Vérifier la séparation des droits entre exploitation, maintenance et support.
1286
REQ-NF-045	Les règles de purge, archivage ou conservation locale doivent être définies avec le client selon les besoins de traçabilité, RGPD et audit.	PAX-BOX, Cloud, rapports	Valider une politique de conservation dans le dossier de recette.
1287
1288 41 Antoine K
```
1289 1 Redmine Admin
1290 41 Antoine K
## 6.7 Ergonomie et facteur humain
1291 1 Redmine Admin
PAXWARE doit rester un outil d’aide à l’exploitation, non un système complexe réservé à des informaticiens. Les informations critiques doivent être lisibles rapidement et les anomalies doivent aider les utilisateurs à lever le doute plutôt qu’à créer une charge supplémentaire.
1292
1293 41 Antoine K
```
1294 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1295
REQ-NF-050	Les écrans et interfaces doivent présenter une information simple, priorisée et compréhensible par les profils opérationnels.	PAX-SCREEN, PAX-MANAGER, PAX-MUSTER	Revue utilisateur avec HSE, Barge-Master ou exploitation.
1296
REQ-NF-051	Les anomalies doivent être formulées en langage opérationnel et proposer une action de levée de doute lorsque cela est possible.	PAX-MANAGER	Vérifier les messages d’anomalie sur scénarios de test.
1297
REQ-NF-052	Les fonctions critiques du muster-point doivent rester utilisables sous stress, avec un nombre limité d’actions utilisateur.	PAX-MUSTER, PAX-MANAGER	Réaliser un test de scénario muster avec utilisateur terrain.
1298
REQ-NF-053	Le système doit permettre de distinguer une confirmation automatique, une confirmation volontaire et une confirmation manuelle.	PAX-MUSTER, PAX-BOX	Vérifier l’historique des confirmations en exercice.
1299
REQ-NF-054	Le système doit aider à détecter les écarts liés au facteur humain : tag non associé, tag oublié, tag immobile, personne attendue non confirmée.	PAX-TAG, PAX-BOX, PAX-MANAGER	Tester des cas d’oubli ou d’incohérence volontaire.
1300 41 Antoine K
```
1301 1 Redmine Admin
1302
1303 41 Antoine K
## 6.8 Maintenance, diagnostic et support
1304 1 Redmine Admin
La maintenance doit être prévue dès la conception pour limiter les immobilisations, faciliter le diagnostic et permettre aux équipes client ou PAXWARE d’identifier rapidement l’origine d’un défaut.
1305
1306 41 Antoine K
```
1307 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1308
REQ-NF-060	Le système doit fournir une vue d’état des équipements : connecté, hors ligne, anomalie, maintenance, dernière communication connue.	PAX-MANAGER, PAX-BOX	Débrancher un équipement et vérifier le changement d’état.
1309
REQ-NF-061	Les équipements doivent être identifiables de manière unique dans la configuration du site.	PAX-ANT, PAX-SCREEN, PAX-MUSTER, PAX-NAV	Contrôler la correspondance entre équipement physique et configuration logicielle.
1310
REQ-NF-062	Le remplacement d’un équipement doit pouvoir être réalisé selon une procédure maîtrisée, sans perte de cohérence du site.	ACT-006, ACT-008, PAX-MANAGER	Simuler le remplacement d’une PAX-ANT ou d’un PAX-SCREEN.
1311
REQ-NF-063	Les journaux techniques doivent permettre d’analyser une panne ou une anomalie après événement.	PAX-BOX, PAX-MANAGER	Exporter ou consulter les logs d’un scénario d’anomalie.
1312
REQ-NF-064	Les mises à jour logicielles doivent être préparées pour ne pas interrompre les fonctions critiques sans procédure validée.	PAX-BOX, PAX-MANAGER	Définir une procédure de mise à jour et de retour arrière.
1313 41 Antoine K
```
1314 1 Redmine Admin
1315
1316
1317
1318
1319 41 Antoine K
## 6.9 Installation, déploiement et exploitation site
1320 1 Redmine Admin
Le déploiement sur site doit être anticipé pour limiter l’impact sur les opérations client. Les équipements doivent être installés sur des emplacements cohérents avec les flux réels de personnel, les contraintes réseau, les alimentations disponibles et les règles HSE du site.
1321 41 Antoine K
```
1322 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1323
REQ-NF-070	Un dossier d’implantation doit décrire les zones, points de passage, équipements installés, câblage ou alimentation et responsabilités client/PAXWARE.	Architecture site, PAX-ANT, PAX-SCREEN, PAX-BOX	Valider le dossier d’implantation avant installation POC.
1324
REQ-NF-071	Chaque point de passage instrumenté doit être associé à une zone de départ, une zone d’arrivée et une règle de comptage.	PAX-ANT, PAX-MANAGER	Vérifier la configuration d’un passage barge/platforme.
1325
REQ-NF-072	L’installation doit prendre en compte les contraintes d’alimentation, réseau local, protection mécanique et accès maintenance.	PAX-ANT, PAX-SCREEN, PAX-BOX	Revue terrain ou maquette d’installation.
1326
REQ-NF-073	La mise en service doit inclure une phase de vérification des équipements, des flux de données et des premiers scénarios opérationnels.	Tous sous-systèmes	Réaliser une check-list de commissioning.
1327
REQ-NF-074	Le système doit pouvoir fonctionner en parallèle des procédures existantes pendant la phase POC.	Organisation client, PAXWARE	Comparer PAXWARE avec les procédures actuelles pendant l’essai.
1328 41 Antoine K
```
1329
## 6.10 Conformité, réglementation et préparation industrielle
1330 1 Redmine Admin
La conformité complète dépendra du périmètre industriel retenu et des zones d’installation. Le MVP ou POC peut être limité à des zones non classées, mais la conception doit anticiper les exigences applicables aux environnements offshore.
1331 41 Antoine K
```
1332 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1333
REQ-NF-080	Le périmètre MVP / POC doit préciser si les équipements sont installés en zone classée ou hors zone classée.	PAXWARE, client pilote	Faire valider le périmètre HSE avant installation.
1334
REQ-NF-081	Les contraintes ATEX / IECEx doivent être anticipées dès l’architecture pour toute version destinée à une zone offshore classée.	PAX-TAG, PAX-ANT, PAX-SCREEN, PAX-NAV	Identifier les équipements potentiellement concernés par certification.
1335
REQ-NF-082	Le système doit respecter les principes de minimisation et protection des données personnelles applicables au contexte client.	PAX-BOX, PAX-MANAGER, Cloud	Revue RGPD ou équivalent avec le client.
1336
REQ-NF-083	Les exigences de cybersécurité industrielles applicables au site client doivent être identifiées avant déploiement.	Architecture réseau, PAX-BOX, support	Collecter les exigences IT/OT client.
1337
REQ-NF-084	Les choix industriels doivent tenir compte de la maintenance, de la disponibilité des composants et de la reproductibilité de fabrication.	Tous équipements matériels	Revue d’industrialisation avant version série.
1338
1339 41 Antoine K
```
1340 1 Redmine Admin
1341
1342
1343 41 Antoine K
## 6.11 Limites du MVP / POC et points à confirmer
1344 1 Redmine Admin
La section 6 doit aussi clarifier ce qui peut être vérifié pendant le POC et ce qui devra être confirmé dans les spécifications détaillées ou lors d’une phase d’industrialisation ultérieure. Cette clarification évite de promettre trop tôt des performances ou certifications non encore validées.
1345 41 Antoine K
```
1346 1 Redmine Admin
ID exigence	Exigence non fonctionnelle	Éléments concernés	Critère de validation initial
1347
REQ-NF-090	Les performances chiffrées retenues pour le MVP / POC doivent être identifiées comme valeurs cibles à confirmer par essais terrain.	Spécifications, plan de tests	Associer chaque valeur cible à un test mesurable.
1348
REQ-NF-091	Les technologies définitives de détection, radio, NFC/RFID, alimentation et connectique doivent être confirmées dans les spécifications détaillées.	PAX-TAG, PAX-ANT, PAX-MUSTER	Produire une décision technique ou un dossier de choix.
1349
REQ-NF-092	Les limites de responsabilité entre PAXWARE et les équipements ou réseaux du client doivent être définies avant POC.	Client, PAXWARE, réseau site	Inclure la répartition des responsabilités dans le dossier POC.
1350
REQ-NF-093	Le POC doit permettre d’identifier les écarts entre hypothèses de conception et réalité terrain.	Tous sous-systèmes	Rédiger un rapport de retour d’expérience après POC.
1351 41 Antoine K
```
1352
## 6.12 Synthèse des exigences non fonctionnelles
1353 1 Redmine Admin
Les exigences non fonctionnelles constituent le cadre global de robustesse, de sécurité et d’exploitabilité de PAXWARE. Elles devront être reliées aux futures spécifications système, aux tests d’intégration et au cahier de recette client.
1354 41 Antoine K
1355
```
1356 1 Redmine Admin
Famille	Plage d’identifiants	Objet
1357
Disponibilité / continuité	REQ-NF-001 à REQ-NF-006	Disponibilité locale, continuité, gestion coupure et indisponibilité équipement
1358
Offline / synchronisation	REQ-NF-010 à REQ-NF-015	Référence locale, file d’attente, conflit, bande passante et stockage
1359
Environnement industriel	REQ-NF-020 à REQ-NF-025	Robustesse offshore, corrosion, températures, structures métalliques et installation terrain
1360
Performance / évolutivité	REQ-NF-030 à REQ-NF-034	Latence, mouvements groupés, dimensionnement et indicateurs
1361
Cybersécurité / confidentialité	REQ-NF-040 à REQ-NF-045	Protection des échanges, droits, support, journaux et conservation des données
1362
Ergonomie / facteur humain	REQ-NF-050 à REQ-NF-054	Lisibilité, levée de doute, muster sous stress et écarts humains
1363
Maintenance / diagnostic	REQ-NF-060 à REQ-NF-064	Supervision technique, remplacement, logs et mises à jour
1364
Installation / déploiement	REQ-NF-070 à REQ-NF-074	Dossier d’implantation, points de passage, commissioning et coexistence procédures client
1365
Conformité / industrialisation	REQ-NF-080 à REQ-NF-084	ATEX / IECEx, RGPD, cybersécurité industrielle et reproductibilité
1366
Limites MVP / POC	REQ-NF-090 à REQ-NF-093	Valeurs cibles, choix techniques, responsabilités et retour d’expérience
1367 41 Antoine K
```
1368 1 Redmine Admin
1369
Transition vers la section 7 — Scénarios opérationnels de référence
1370
La section 6 fixe les contraintes globales que PAXWARE devra respecter. La section 7 devra maintenant transformer ces exigences en scénarios opérationnels représentatifs : arrivée sur site, association d’un PAX-TAG, passage entre installations, transfert massif, muster-point, perte réseau, reconnexion, équipement hors ligne, tag oublié ou anomalie de comptage.
1371
Ces scénarios permettront de préparer les futurs tests système et les critères de validation client du cycle en V.
1372 41 Antoine K
# 7. Scénarios opérationnels de référence
1373 1 Redmine Admin
Cette section décrit les scénarios opérationnels de référence qui devront être utilisés pour relier les besoins terrain, les exigences PAXWARE, les futurs tests système et le cahier de recette client.
1374
Les scénarios ne remplacent pas les exigences. Ils permettent de vérifier que les exigences sont compréhensibles dans une situation réelle d’exploitation offshore : arrivée personnel, attribution d’un PAX-TAG, transfert entre installations, affichage local, muster-point, fonctionnement offline, anomalies et synchronisation différée.
1375
Les scénarios opérationnels sont identifiés avec le préfixe :
1376
SCN : Scénario opérationnel de référence
1377 41 Antoine K
# 7.1 Principe général
1378 1 Redmine Admin
Dans le cycle en V, les scénarios opérationnels constituent un pont entre le cahier des charges et les futures phases de validation. Chaque scénario décrit une situation terrain représentative, les acteurs concernés, les préconditions, le déroulé attendu et les points de contrôle à vérifier.
1379
Ces scénarios serviront de base pour rédiger ultérieurement les plans de tests, les essais d’intégration, les procédures de recette client et les démonstrations POC.
1380
•	vérifier que le système répond aux usages terrain réels ;
1381
•	préparer les critères de validation client ;
1382
•	identifier les modes dégradés dès la phase amont ;
1383
•	relier les cas d’usage CU aux exigences REQ ;
1384
•	éviter les ambiguïtés entre fonctionnement nominal, anomalie et décision humaine ;
1385
•	préparer une démonstration POC compréhensible par un client offshore.
1386 41 Antoine K
## 7.2 Règles de rédaction des scénarios
1387 1 Redmine Admin
Chaque scénario doit rester suffisamment concret pour être rejoué lors d’un test, tout en restant indépendant des choix techniques définitifs. Les valeurs de performance et seuils détaillés seront confirmés dans les spécifications détaillées et dans le plan de tests.
1388 41 Antoine K
```
1389 1 Redmine Admin
Élément	Règle retenue
1390
Identifiant	Chaque scénario reçoit un identifiant unique de type SCN-001, SCN-002, etc.
1391
Acteurs	Les acteurs sont repris depuis le référentiel ACT-001 à ACT-008.
1392
Préconditions	Les conditions nécessaires au démarrage du scénario doivent être clairement indiquées.
1393
Déroulé nominal	Le déroulé décrit la situation attendue lorsque tout fonctionne normalement.
1394
Cas dégradé	Les variantes de panne, doute ou incohérence sont traitées dans les scénarios dédiés.
1395
Résultat attendu	Le résultat doit être observable dans PAX-MANAGER, PAX-SCREEN, PAX-MUSTER ou les journaux locaux.
1396
Traçabilité	Chaque scénario doit être relié aux cas d’usage et exigences qui seront testés.
1397
1398 41 Antoine K
```
1399 1 Redmine Admin
1400
1401
1402
1403
1404
1405 41 Antoine K
## 7.3 Synthèse des scénarios retenus
1406 1 Redmine Admin
Le tableau ci-dessous constitue le référentiel initial des scénarios opérationnels de PAXWARE. Il pourra être complété après retour du site pilote et validation des contraintes réelles d’installation.
1407
1408 41 Antoine K
```
1409 1 Redmine Admin
ID scénario	Scénario	Acteurs principaux	Objectif de validation
1410
SCN-001	Préparer l’arrivée d’une personne sur site	ACT-007, ACT-005	Vérifier la création d’une présence attendue et son affectation initiale.
1411
SCN-002	Associer un PAX-TAG à une personne	ACT-005, ACT-007, ACT-004	Vérifier l’attribution, la traçabilité et la cohérence entre personne et identifiant.
1412
SCN-003	Détecter un passage barge, via surfer vers plateforme	ACT-001, ACT-004, PAX-ANT, PAX-BOX	Vérifier le changement de présence entre deux installations.
1413
SCN-004	Détecter un passage plateforme vers barge via surfer.	ACT-001, ACT-004, PAX-ANT, PAX-BOX	Vérifier le sens inverse et la mise à jour de la présence.
1414
SCN-005	Gérer un transfert massif de personnel (surfer)	ACT-004, ACT-003, ACT-002	Vérifier la capacité de traitement, la latence et la stabilité d’affichage.
1415
SCN-006	Afficher localement le nombre de personnes	ACT-004, ACT-003, ACT-002, PAX-SCREEN	Vérifier la cohérence entre PAX-BOX, PAX-MANAGER et PAX-SCREEN.
1416
SCN-007	Lancer et suivre un muster-point exercice	ACT-002, ACT-004, ACT-003	Vérifier la comparaison attendu / confirmé / non confirmé.
1417
SCN-008	Suivre un muster-point en situation d’urgence	ACT-002, ACT-004, ACT-003	Vérifier la priorisation des personnes non confirmées et la continuité locale.
1418
SCN-009	Lever un doute sur une personne non confirmée	ACT-002, ACT-004, ACT-007	Vérifier les informations disponibles pour la recherche et la qualification d’écart.
1419
SCN-010	Fonctionner en perte de connexion distante	ACT-003, ACT-004, ACT-005	Vérifier que les fonctions critiques restent disponibles sans cloud.
1420
SCN-011	Reconnexion et synchronisation différée	ACT-005, ACT-008	Vérifier la reprise de synchronisation, les conflits et la file d’attente.
1421
SCN-012	Diagnostiquer un équipement hors ligne	ACT-006, ACT-008	Vérifier la détection d’anomalie et l’aide au diagnostic.
1422
SCN-013	Gérer un PAX-TAG immobile ou oublié	ACT-002, ACT-004, PAX-BOX	Réduire les faux positifs lors d’un muster ou d’un contrôle de présence.
1423
SCN-014	Gérer un PAX-TAG non associé ou inconnu	ACT-005, ACT-007, ACT-004	Empêcher l’exploitation d’un identifiant non attribué sans qualification.
1424
SCN-015	Intervention support contrôlée	ACT-005, ACT-008	Vérifier l’autorisation, la limitation et la journalisation de l’accès support.
1425
1426 41 Antoine K
```
1427 1 Redmine Admin
1428 41 Antoine K
## 7.4 Scénarios nominaux détaillés
1429 1 Redmine Admin
Les scénarios nominaux décrivent les situations où le système fonctionne conformément au comportement attendu. Ils doivent être utilisés pour construire les premiers tests de fonctionnement global.
1430
1431 45 Antoine K
### **SCN-001 - Préparer l’arrivée d’une personne sur site**
1432 46 Antoine K
1433 42 Antoine K
**Acteurs principaux**	ACT-007 Logistique, ACT-005 Administrateur PAXWARE
1434
**Déclencheur**	Une personne est planifiée pour embarquer ou rejoindre le site.
1435 1 Redmine Admin
**Préconditions**	Le manifeste, la rotation ou les informations d’arrivée sont disponibles. Le profil utilisateur est autorisé à créer ou préparer la fiche.
1436 42 Antoine K
**Déroulé nominal** 
1437 44 Antoine K
1438 42 Antoine K
1. La logistique saisit ou importe les informations utiles. 
1439
2. La personne est associée à une société, une fonction, une installation prévue et éventuellement un hébergement. 
1440
3. Le système crée une présence attendue. 
1441
4. L’information devient disponible pour l’association future du PAX-TAG et le muster.
1442 1 Redmine Admin
1443 42 Antoine K
**Résultat attendu**	La personne apparaît comme attendue dans PAX-MANAGER et peut être utilisée dans les scénarios d’attribution, de présence et de muster-point.
1444
**Points de contrôle**	Cohérence des champs obligatoires ; traçabilité de création ; visibilité pour les profils autorisés ; absence d’accès aux profils non autorisés.
1445
**Exigences liées**	CU-001 ; REQ-ACQ-030 à REQ-ACQ-034 ; REQ-NF-050 ; REQ-SEC associées.
1446 41 Antoine K
1447 45 Antoine K
### **SCN-002 - Associer un PAX-TAG à une personne**
1448 1 Redmine Admin
**Acteurs principaux**	ACT-005 Administrateur PAXWARE, ACT-007 Logistique, ACT-004 Barge-Master
1449 42 Antoine K
**Déclencheur**	Une personne attendue reçoit un PAX-TAG avant embarquement, à l’arrivée ou lors d’un remplacement.
1450
**Préconditions**	Le PAX-TAG est disponible, actif et reconnu par le système. La personne est connue ou créée dans la base locale.
1451 44 Antoine K
**Déroulé nominal**
1452
	
1453 42 Antoine K
1. L’utilisateur autorisé sélectionne la personne. 
1454
2. Il lit ou saisit l’identifiant du PAX-TAG via PAX-WRITING ou l’interface prévue. 
1455
3. Le système vérifie que le tag n’est pas déjà attribué. 
1456
4. L’association est confirmée et journalisée.
1457 44 Antoine K
1458 42 Antoine K
**Résultat attendu**	Le PAX-TAG devient exploitable par le système. Toute détection future peut être reliée à la personne, selon les droits d’accès et règles de confidentialité.
1459
**Points de contrôle**	Vérification d’unicité ; horodatage ; historisation de l’association ; gestion du remplacement et de la désactivation.
1460
**Exigences liées**	CU-002 ; REQ-ACQ-032 ; REQ-ACQ-051 ; REQ-TRT-002 ; REQ-SEC ; REQ-NF-060.
1461 1 Redmine Admin
1462 45 Antoine K
### **SCN-003 - Détecter un passage barge vers plateforme**
1463 42 Antoine K
**Acteurs principaux**	ACT-001 Personnel offshore, ACT-004 Barge-Master, PAX-ANT, PAX-BOX
1464
**Déclencheur**	Une personne équipée d’un PAX-TAG emprunte un point de passage équipé entre la barge et une plateforme.
1465
**Préconditions**	Le PAX-TAG est associé. La PAX-ANT du point de passage communique avec la PAX-BOX. Les zones de départ et d’arrivée sont configurées.
1466 43 Antoine K
**Déroulé nominal** 
1467
1468 42 Antoine K
1. La personne traverse la zone équipée. 
1469
2. La PAX-ANT acquiert l’événement. 
1470
3. La PAX-BOX reçoit et traite l’événement. 
1471 1 Redmine Admin
4. Le système met à jour la présence de la personne et le nombre de personnes par installation. 5. PAX-MANAGER et PAX-SCREEN sont mis à jour.
1472
1473
**Résultat attendu**	La personne est retirée de la zone de départ et comptabilisée sur la zone d’arrivée, selon le sens de passage validé.
1474
**Points de contrôle**	Sens de passage ; absence de double comptage ; latence d’affichage ; journalisation de l’événement ; gestion des événements répétés.
1475
**Exigences liées**	CU-003, CU-004, CU-005 ; REQ-ACQ-010 à REQ-ACQ-014 ; REQ-TRT-010 à REQ-TRT-014 ; REQ-PERF ; REQ-NF-020.
1476
1477 45 Antoine K
### **SCN-004 - Détecter un passage plateforme vers barge**
1478 44 Antoine K
**Acteurs principaux**	ACT-001 Personnel offshore, ACT-004 Barge-Master, PAX-ANT, PAX-BOX
1479
**Déclencheur**	Une personne équipée d’un PAX-TAG revient d’une plateforme vers la barge ou l’installation principale.
1480
**Préconditions**	Les équipements de passage sont opérationnels. La personne est connue du système et sa présence courante est cohérente.
1481
**Déroulé nominal**	
1482 1 Redmine Admin
1483 44 Antoine K
1. La personne traverse le point de passage dans le sens retour. 
1484
2. Le système acquiert l’événement. 
1485
3. La PAX-BOX interprète le sens de passage. 
1486
4. La présence par installation est recalculée. 
1487
5. Les vues locales sont mises à jour.
1488
1489
**Résultat attendu**	La présence de la personne et les totaux d’installation sont mis à jour dans le sens retour.
1490
**Points de contrôle**	Détection du sens inverse ; cohérence avec l’état précédent ; absence d’inversion de zone ; visibilité dans les historiques.
1491
**Exigences liées**	CU-003, CU-004 ; REQ-ACQ-011 ; REQ-TRT-011 ; REQ-TRT-020 à REQ-TRT-024.
1492
1493 45 Antoine K
### **SCN-005 - Gérer un transfert massif de personnel**
1494 44 Antoine K
**Acteurs principaux**	ACT-004 Barge-Master, ACT-003 Chef de site / Ingénieur production, ACT-002 Responsable HSE
1495
**Déclencheur**	Un groupe important de personnes transite sur une courte période, par exemple lors d’une opération hélicoptère, navire ou changement d’équipe cas le plus probable (jours de relève) environ deux fois par semaine.
1496
**Préconditions**	Les PAX-TAG sont associés. Les équipements de passage et la PAX-BOX sont opérationnels. Les seuils de performance cibles sont définis pour le POC.
1497
**Déroulé nominal**	
1498 41 Antoine K
1499 44 Antoine K
1. Plusieurs personnes passent successivement ou dans une fenêtre courte. 
1500
2. Les événements sont acquis et mis en file de traitement. 
1501
3. La PAX-BOX consolide les changements de présence. 
1502
4. Les affichages et vues d’exploitation sont rafraîchis sans blocage. 5. Les événements restent consultables après l’opération.
1503
1504
**Résultat attendu**	Le système maintient une information exploitable, évite le double comptage et respecte les objectifs de latence définis pour le POC.
1505
**Points de contrôle**	Nombre d’événements traités ; collisions ou pertes ; délai de mise à jour PAX-SCREEN ; stabilité PAX-MANAGER ; charge PAX-BOX.
1506
**Exigences liées**	CU-003, CU-004, CU-005 ; REQ-PERF-001 à REQ-PERF-006 ; REQ-TRT-013 ; REQ-NF-001.
1507
1508 45 Antoine K
### **SCN-006 - Afficher localement le nombre de personnes**
1509 44 Antoine K
**Acteurs principaux**	ACT-004 Barge-Master, ACT-003 Chef de site / Ingénieur production, ACT-002 Responsable HSE, PAX-SCREEN
1510
**Déclencheur**	Le nombre de personnes par installation change à la suite d’un passage, d’une affectation ou d’un événement validé.
1511
**Préconditions**	Le PAX-SCREEN est associé à une installation ou une zone. La PAX-BOX dispose d’un état courant de présence.
1512
**Déroulé nominal**	
1513
1514
1. La PAX-BOX met à jour le nombre de personnes. 
1515
2. L’information est transmise au PAX-SCREEN. 
1516
3. Le PAX-SCREEN affiche le nombre à jour. 
1517
4. PAX-MANAGER affiche une valeur cohérente avec l’écran local.
1518
1519
**Résultat attendu**	L’affichage local permet une lecture rapide et cohérente de la situation terrain.
1520
**Points de contrôle**	Cohérence PAX-BOX / PAX-MANAGER / PAX-SCREEN ; lisibilité ; latence ; réaction en cas de perte communication écran.
1521
**Exigences liées**	CU-005 ; REQ-TRT-020 à REQ-TRT-024 ; REQ-CMD affichage ; REQ-NF-002 ; REQ-MAT PAX-SCREEN.
1522 1 Redmine Admin
1523
## 7.5 Scénarios muster, urgence et levée de doute
1524
Les scénarios de muster-point doivent permettre de vérifier que PAXWARE renforce les procédures HSE sans les remplacer. La décision finale reste sous responsabilité des acteurs autorisés du site.
1525
1526 52 Antoine K
1527
### SCN-007 - Lancer et suivre un muster-point exercice
1528
**Acteurs principaux**	ACT-002 Responsable HSE, ACT-004 Barge-Master, ACT-003 Chef de site / Ingénieur production
1529
**Déclencheur**	Un exercice de sécurité est déclenché selon la procédure du site. 
1530
**Préconditions**	La liste des personnes attendues est disponible. Les PAX-TAG sont associés. Le terminal ou l’application PAX-MUSTER est opérationnel en local.
1531
**Déroulé nominal**	
1532
1533
1. Le Responsable HSE lance ou suit l’exercice. 
1534
2. Le système affiche les personnes attendues. 
1535
3. Les présences sont confirmées par lecture volontaire, détection prévue ou validation autorisée. 
1536
4. Le système distingue confirmé, non confirmé et anomalie. 5. Un historique d’exercice est conservé.
1537
1538
**Résultat attendu**	Le Responsable HSE dispose d’une vision claire des personnes confirmées et non confirmées pendant l’exercice.
1539
**Points de contrôle**	Temps de consolidation ; preuve de validation ; cas de confirmation manuelle ; export rapport ; fonctionnement sans cloud.
1540
**Exigences liées**	CU-006, CU-007, CU-008 ; REQ-ACQ-020 à REQ-ACQ-024 ; REQ-TRT muster ; REQ-NF-010 à REQ-NF-015.
1541
1542
1543
### SCN-008 - Suivre un muster-point en situation d’urgence
1544
1545
**Acteurs principaux**	ACT-002 Responsable HSE, ACT-004 Barge-Master, ACT-003 Chef de site / Ingénieur production
1546
**Déclencheur**	Une alarme générale, un incident ou une situation d’urgence nécessite une consolidation rapide des présences.
1547
**Préconditions**	La PAX-BOX est opérationnelle localement. Les informations de présence les plus récentes sont disponibles. Les procédures HSE du site restent prioritaires.
1548
**Déroulé nominal**	
1549
1550
1. Le mode muster / urgence est activé. 
1551
2. Le système présente la liste attendue et l’état connu des présences. 
1552
3. Les confirmations sont acquises et horodatées. 
1553
4. Les personnes non confirmées sont mises en évidence. 
1554
5. Les écarts sont qualifiés par les acteurs autorisés. 
1555
6. Les résultats restent disponibles après l’événement.
1556
1557
**Résultat attendu**	Le système aide à prioriser les vérifications et recherches sans bloquer la procédure d’urgence officielle.
1558
**Points de contrôle**	Priorisation des non confirmés ; disponibilité locale ; lisibilité sous stress ; traçabilité ; export ou conservation après événement.
1559
**Exigences liées**	CU-006, CU-007, CU-010 ; REQ-ACQ-020 à REQ-ACQ-024 ; REQ-DEG ; REQ-NF-001 à REQ-NF-006.
1560
1561
### SCN-009 - Lever un doute sur une personne non confirmée
1562
1563
**Acteurs principaux**	ACT-002 Responsable HSE, ACT-004 Barge-Master, ACT-007 Logistique
1564
**Déclencheur**	Une personne attendue n’est pas confirmée pendant un muster ou une vérification de présence.
1565
**Préconditions**	La personne est connue du système. Des événements de passage, affectation ou présence peuvent être disponibles dans l’historique local.
1566
**Déroulé nominal**	
1567
1568
1. Le système signale la personne comme non confirmée. 
1569
2. L’acteur autorisé consulte la dernière information utile : affectation, dernier passage, statut, hébergement ou anomalie. 
1570
3. Une vérification terrain, radio ou procédure HSE est engagée. 
1571
4. Le résultat est qualifié : confirmé, erreur, absence connue, anomalie ou recherche en cours.
1572
1573
**Résultat attendu**	Le système fournit des éléments de levée de doute sans prétendre remplacer la décision humaine.
1574
**Points de contrôle**	Dernier événement connu ; cohérence manifeste / présence ; journalisation de la qualification ; séparation entre donnée brute et décision utilisateur.
1575
**Exigences liées**	CU-007, CU-008, CU-012 ; REQ-TRT-004 ; REQ-DEG-001 à REQ-DEG-006 ; REQ-ACQ-050 à REQ-ACQ-054.
1576
1577 1 Redmine Admin
## 7.6 Scénarios de mode dégradé et anomalies
1578
Les scénarios de mode dégradé permettent de vérifier que PAXWARE reste exploitable même lorsque les conditions terrain ne sont pas idéales : perte réseau, équipement hors ligne, PAX-TAG oublié, identifiant non associé, stockage local proche de saturation ou accès support nécessaire.
1579
1580 53 Antoine K
### SCN-010 - Fonctionner en perte de connexion distante
1581
**Acteurs principaux**	ACT-003 Chef de site / Ingénieur production, ACT-004 Barge-Master, ACT-005 Administrateur PAXWARE
1582
**Déclencheur**	La connexion internet, cloud ou liaison distante devient indisponible.
1583
**Préconditions**	La PAX-BOX est en service. Les équipements locaux communiquent sur le réseau site ou liaison locale prévue.
1584
**Déroulé nominal**	
1585 1 Redmine Admin
1586 53 Antoine K
1. La connexion distante est coupée. 
1587
2. Les fonctions locales restent disponibles. 
1588
3. Les événements continuent d’être acquis, traités et conservés. 
1589
4. PAX-MANAGER et PAX-SCREEN restent exploitables localement. 
1590
5. Les données à synchroniser sont placées en file d’attente.
1591 1 Redmine Admin
1592 53 Antoine K
**Résultat attendu**	Le site conserve une vision locale exploitable de la présence et du muster malgré l’absence de cloud.
1593
**Points de contrôle**	Consultation locale ; acquisition de nouveaux événements ; conservation ; indication de statut offline ; absence de blocage utilisateur.
1594
**Exigences liées**	CU-010 ; REQ-NF-010 à REQ-NF-015 ; REQ-SYNC-001 à REQ-SYNC-006 ; REQ-TRT-005.
1595 1 Redmine Admin
1596 53 Antoine K
### SCN-011 - Reconnexion et synchronisation différée
1597 1 Redmine Admin
Champ	Description
1598 53 Antoine K
**Acteurs principaux**	ACT-005 Administrateur PAXWARE, ACT-008 Équipe PAXWARE support
1599
**Déclencheur**	La connexion distante revient après une période offline.
1600
**Préconditions**	Des événements ont été créés localement pendant la coupure. Des règles de priorité et de conflit sont définies.
1601
**Déroulé nominal**	
1602 1 Redmine Admin
1603 53 Antoine K
1. La PAX-BOX détecte le retour réseau. 
1604
2. Les événements en attente sont synchronisés selon les priorités. 
1605
3. Les conflits éventuels sont identifiés. 
1606
4. La donnée locale opérationnelle reste prioritaire pour la situation terrain du site. 
1607
5. Les anomalies de synchronisation sont journalisées.
1608
1609
**Résultat attendu**	La synchronisation reprend sans perte d’événement critique ni saturation de la bande passante.
1610
**Points de contrôle**	Ordre de synchronisation ; gestion des conflits ; limitation de débit ; journalisation ; non-régression de l’état local.
1611
**Exigences liées**	CU-011 ; REQ-SYNC ; REQ-NF-012 à REQ-NF-015 ; REQ-SEC ; REQ-ACQ-043.
1612
1613
### SCN-012 - Diagnostiquer un équipement hors ligne
1614 1 Redmine Admin
Champ	Description
1615 53 Antoine K
**Acteurs principaux**	ACT-006 Technicien maintenance, ACT-008 Équipe PAXWARE support
1616
**Déclencheur**	Une PAX-ANT, un PAX-SCREEN, un terminal PAX-MUSTER ou un autre équipement attendu ne communique plus.
1617
**Préconditions**	L’équipement est déclaré dans la configuration du site. Le système connaît son rôle et son installation de rattachement.
1618
**Déroulé nominal**	
1619 1 Redmine Admin
1620 53 Antoine K
1. La PAX-BOX détecte l’absence de communication ou une anomalie. 
1621
2. PAX-MANAGER affiche l’état dégradé. 
1622
3. Le technicien consulte les informations de diagnostic. 
1623
4. Une action de maintenance est réalisée. 
1624
5. Le retour au nominal est horodaté et journalisé.
1625 1 Redmine Admin
1626 53 Antoine K
**Résultat attendu**	L’anomalie technique est visible et ne doit pas être confondue avec une absence de personnel.
1627
**Points de contrôle**	Délai de détection ; message compréhensible ; état équipement ; impact fonctionnel ; trace de maintenance.
1628
**Exigences liées**	CU-009, CU-012 ; REQ-ACQ-040 à REQ-ACQ-044 ; REQ-NF-003 ; REQ-NF-006 ; REQ-MAINT futures.
1629 1 Redmine Admin
1630 53 Antoine K
### SCN-013 - Gérer un PAX-TAG immobile ou oublié
1631 1 Redmine Admin
1632 53 Antoine K
**Acteurs principaux**	ACT-002 Responsable HSE, ACT-004 Barge-Master, PAX-BOX
1633
**Déclencheur**	Un PAX-TAG reste détecté ou associé à une zone alors que son porteur pourrait ne pas l’avoir avec lui, par exemple bracelet laissé en cabine.
1634
**Préconditions**	Le système dispose d’événements récents, d’un état courant et de règles de qualification d’anomalie ou de suspicion.
1635
**Déroulé nominal**	
1636 1 Redmine Admin
1637 53 Antoine K
1. Le système détecte une incohérence possible : tag immobile, absence de passage attendu, confirmation muster non réalisée ou dernier événement trop ancien. 
1638
2. Le statut est qualifié comme doute ou anomalie, pas comme présence certaine. 
1639
3. Les acteurs autorisés reçoivent une information de levée de doute. 
1640
4. Une confirmation humaine ou lecture volontaire peut être demandée.
1641 1 Redmine Admin
1642 53 Antoine K
**Résultat attendu**	Le système réduit les faux positifs et évite de considérer automatiquement un tag immobile comme une présence humaine confirmée.
1643
**Points de contrôle**	Seuil d’immobilité ; différence entre présence observée et présence confirmée ; affichage de doute ; journalisation de la décision.
1644
**Exigences liées**	CU-006, CU-007, CU-012 ; REQ-DEG tags immobiles ; REQ-TRT-003 ; REQ-TRT-004 ; REQ-NF-060.
1645
1646
### SCN-014 - Gérer un PAX-TAG non associé ou inconnu
1647
1648
**Acteurs principaux**	ACT-005 Administrateur PAXWARE, ACT-007 Logistique, ACT-004 Barge-Master
1649
**Déclencheur**	Un identifiant PAX-TAG est détecté par le système mais n’est pas associé à une personne connue ou active.
1650
**Préconditions**	La PAX-ANT ou le lecteur détecte un identifiant valide techniquement, mais la base locale ne trouve pas d’association active.
1651
**Déroulé nominal**	
1652
1653
1. L’événement est acquis. 
1654
2. La PAX-BOX le classe comme tag non associé, inconnu ou désactivé. 
1655
3. Le système empêche son intégration directe dans le comptage nominatif. 
1656
4. Une alerte ou tâche de qualification est proposée à un profil autorisé. 
1657
5. La correction éventuelle est journalisée.
1658
1659
**Résultat attendu**	Un tag inconnu ne doit pas modifier silencieusement la situation opérationnelle sans qualification.
1660
**Points de contrôle**	Classification de l’événement ; absence de faux comptage ; notification ; traçabilité de correction ; confidentialité.
1661
**Exigences liées**	CU-002, CU-003, CU-012 ; REQ-ACQ-001 ; REQ-TRT-002 ; REQ-TRT-004 ; REQ-DEG ; REQ-SEC.
1662
1663
### SCN-015 - Intervention support contrôlée
1664
1665
**Acteurs principaux**	ACT-005 Administrateur PAXWARE, ACT-008 Équipe PAXWARE support
1666
**Déclencheur**	Le client autorise une intervention de support pour diagnostic, mise à jour ou analyse d’anomalie.
1667
**Préconditions**	L’intervention est justifiée, autorisée par le client et limitée au besoin. Les règles d’accès support sont définies.
1668
**Déroulé nominal**	
1669
1670
1. L’administrateur autorise l’accès support. 
1671
2. L’équipe support intervient avec des droits limités. 
1672
3. Les actions réalisées sont journalisées. 
1673
4. L’accès est révoqué après intervention. 
1674
5. Un compte rendu ou historique technique reste disponible.
1675
1676
**Résultat attendu**	Le support peut aider sans disposer d’un accès permanent ou excessif aux données du client.
1677
**Points de contrôle**	Autorisation préalable ; limitation des droits ; journalisation ; révocation ; séparation entre données techniques et données nominatives.
1678
**Exigences liées**	CU-009, CU-011, CU-012 ; REQ-SEC support ; REQ-ACQ-054 ; REQ-NF cybersécurité ; REQ-SYNC si applicable.
1679
1680
## 7.7 Tableau de préparation des futurs tests
1681 1 Redmine Admin
Le tableau ci-dessous prépare la transition vers le futur plan de tests. Les identifiants TEST sont indicatifs à ce stade et seront confirmés dans le document de test correspondant.
1682
Scénario	Fonction vérifiée	Modules concernés	Futur test associé
1683
SCN-001	Préparation d’une présence attendue	PAX-MANAGER, PAX-WRITING, base locale	TEST-LOG-001
1684
SCN-002	Association personne / PAX-TAG	PAX-WRITING, PAX-BOX, PAX-MANAGER	TEST-TAG-001
1685
SCN-003 / SCN-004	Détection de passage et sens entrée / sortie	PAX-TAG, PAX-ANT, PAX-BOX	TEST-PASS-001
1686
SCN-005	Transfert massif et performance	PAX-ANT, PAX-BOX, PAX-SCREEN	TEST-PERF-001
1687
SCN-006	Affichage local de présence	PAX-BOX, PAX-SCREEN, PAX-MANAGER	TEST-AFF-001
1688
SCN-007 / SCN-008	Muster-point exercice et urgence	PAX-MUSTER, PAX-BOX, PAX-MANAGER	TEST-MUSTER-001
1689
SCN-009	Levée de doute personne non confirmée	PAX-MANAGER, historiques, PAX-MUSTER	TEST-DEG-001
1690
SCN-010	Fonctionnement sans cloud	PAX-BOX, PAX-MANAGER, base locale	TEST-OFFLINE-001
1691
SCN-011	Synchronisation différée et conflits	PAX-BOX, Cloud, module synchronisation	TEST-SYNC-001
1692
SCN-012	Diagnostic équipement	PAX-ANT, PAX-SCREEN, PAX-BOX, PAX-MANAGER	TEST-MAINT-001
1693
SCN-013	Tag immobile ou oublié	PAX-TAG, PAX-BOX, PAX-MANAGER	TEST-DEG-002
1694
SCN-014	Tag non associé ou inconnu	PAX-TAG, PAX-BOX, PAX-MANAGER	TEST-SEC-001
1695
SCN-015	Support contrôlé	PAX-MANAGER, PAX-BOX, accès support	TEST-SEC-002
1696
1697 54 Antoine K
## 7.8 Synthèse de la section 7
1698 1 Redmine Admin
Les scénarios opérationnels de référence permettent de vérifier que PAXWARE n’est pas seulement une liste de fonctions, mais un système capable de répondre à des situations terrain concrètes. Ils préparent les prochaines étapes du cycle en V : critères de validation client, matrice de traçabilité, plan d’intégration et plan de tests.
1699
1700
1701
1702
1703
1704 54 Antoine K
# 8. Critères de validation client
1705 1 Redmine Admin
Cette section définit les critères de validation client applicables à la première version PAXWARE issue du cahier des charges. Elle prépare le futur cahier de recette, le plan de tests et la démonstration POC.
1706
Les critères ci-dessous doivent permettre de vérifier que les fonctions décrites précédemment sont observables, mesurables et exploitables dans un contexte terrain offshore. Ils ne remplacent pas les plans de tests détaillés, mais servent de base de référence pour les rédiger.
1707
Les critères de validation sont identifiés avec le préfixe :
1708
VAL : Critère de validation client
1709 54 Antoine K
## 8.1 Principe général
1710 1 Redmine Admin
Dans le cycle en V, la validation client vérifie que le système livré répond bien au besoin exprimé en amont. Elle ne se limite pas à vérifier que les équipements fonctionnent techniquement. Elle doit démontrer que PAXWARE apporte une information fiable, utile et compréhensible aux acteurs terrain.
1711
Un critère de validation client doit donc être :
1712
•	observable par un utilisateur autorisé ou par un journal système ;
1713
•	mesurable ou vérifiable dans un scénario opérationnel ;
1714
•	relié à une exigence fonctionnelle, non fonctionnelle ou de sécurité ;
1715
•	rejouable lors d’un test, d’un POC ou d’une recette client ;
1716
•	compréhensible par un client offshore sans entrer dans les détails de conception interne.
1717
Les valeurs de performance indiquées dans cette section sont des cibles de validation POC. Elles devront être confirmées ou ajustées lors des spécifications détaillées, des essais laboratoire, puis des essais terrain.
1718 54 Antoine K
## 8.2 Règles de formulation des critères de validation
1719 1 Redmine Admin
Élément	Règle retenue
1720
Identifiant	Chaque critère reçoit un identifiant unique de type VAL-001, VAL-002, etc.
1721
Traçabilité	Chaque critère doit pouvoir être relié à un cas d’usage, une exigence et un scénario opérationnel.
1722
Preuve attendue	La preuve peut être une capture PAX-MANAGER, un affichage PAX-SCREEN, un journal local, un export de rapport ou un procès-verbal de test.
1723
Seuil d’acceptation	Le seuil indique la condition minimale attendue pour considérer le critère comme validé.
1724
Écart	Tout écart doit être qualifié comme bloquant, majeur ou mineur selon son impact opérationnel.
1725
Décision client	La validation finale appartient au client pilote ou au représentant habilité, sur la base des preuves collectées.
1726
1727 54 Antoine K
## 8.3 Synthèse des critères de validation retenus
1728 1 Redmine Admin
Le tableau ci-dessous constitue le référentiel initial des critères de validation client. Il pourra être complété lors de la préparation du POC, notamment en fonction du site, du nombre d’installations, du nombre de personnes et des contraintes réelles de communication.
1729 54 Antoine K
1730 1 Redmine Admin
1731 59 Antoine K
|ID|Famille de validation|Objectif de validation|Scénarios liés|
1732
|-----------|----------------------|------------------------|----------------|
1733
|VAL-001|Préparation / association|Vérifier qu’une personne attendue peut être créée, associée à un PAX-TAG et rendue exploitable dans le système.|SCN-001, SCN-002|
1734
|VAL-002|Passage / transfert|Vérifier qu’un passage entre zones est acquis, traité et traduit en présence par installation.|SCN-003, SCN-004, SCN-005|
1735
|VAL-003|Comptage|Vérifier que le nombre de personnes par installation correspond à la situation terrain observée.|SCN-003 à SCN-005|
1736
|VAL-004|Affichage local|Vérifier que le PAX-SCREEN affiche une information simple, lisible et mise à jour dans le délai cible.|SCN-006|
1737
|VAL-005|Muster-point|Vérifier que le système aide à identifier les personnes confirmées, attendues et non confirmées.|SCN-007, SCN-008|
1738
|VAL-006|Mode offline|Vérifier que les fonctions critiques restent disponibles sans connexion distante.|SCN-009|
1739
|VAL-007|Synchronisation différée|Vérifier que les événements locaux sont synchronisés sans perte ni saturation au retour réseau.|SCN-010|
1740
|VAL-008|Anomalies / cas dégradés|Vérifier que les anomalies humaines, techniques ou de comptage sont visibles, qualifiables et traçables.|SCN-011 à SCN-014|
1741
|VAL-009|Supervision / maintenance|Vérifier que les équipements PAXWARE sont supervisés et que les défauts sont remontés.|SCN-015|
1742
|VAL-010|Cybersécurité / confidentialité|Vérifier que les accès, journaux et données sensibles respectent les principes de sécurité définis.|Transversal|
1743 1 Redmine Admin
1744 59 Antoine K
1745 54 Antoine K
## 8.4 Critères détaillés de validation
1746 60 Antoine K
1747 54 Antoine K
### 8.4.1 Validation de la préparation et de l’association PAX-TAG
1748 1 Redmine Admin
Cette famille vérifie que le système peut préparer la présence attendue et associer correctement un identifiant PAXWARE à une personne autorisée.
1749 60 Antoine K
1750
|ID CRITERE|Critère de validation|Condition d’acceptation|Preuve attendue|
1751
|-----------|----------------------|------------------------|----------------|
1752
|VAL-PREP-001|Une personne attendue peut être créée ou importée dans PAXWARE.|La personne apparaît dans PAX-MANAGER avec les informations nécessaires au POC.|Fiche personne / liste attendue / journal d’import.|
1753
|VAL-PREP-002|Un PAX-TAG peut être associé à une personne.|L’association est visible, datée, et ne génère pas de doublon actif.|Journal d’association PAX-WRITING ou PAX-MANAGER.|
1754
|VAL-PREP-003|Un PAX-TAG peut être désactivé, remplacé ou dissocié.|L’ancien identifiant ne doit plus être utilisé pour consolider une présence active.|Journal de désassociation et nouvel état du tag.|
1755
|VAL-PREP-004|Une personne peut être associée à une installation, zone ou affectation prévue.|L’information est exploitable pour le comptage et le muster.|Écran PAX-MANAGER / export logistique.|
1756
|VAL-PREP-005|Les actions de préparation significatives sont journalisées.|Les créations, modifications et suppressions sont datées et rattachées à un utilisateur autorisé.|Journal d’administration.|
1757
1758 1 Redmine Admin
1759 54 Antoine K
### 8.4.2 Validation des passages, transferts et comptage
1760 1 Redmine Admin
Cette famille vérifie que les événements de passage sont transformés en informations de présence fiables par installation, zone ou moyen mobile.
1761
1762 55 Antoine K
| ID critère| Critère de validation| Condition d’acceptation| Preuve attendue|
1763
|-----------|----------------------|------------------------|----------------|
1764
| VAL-PRES-001| Un passage équipé PAX-ANT génère un événement exploitable.|L’événement contient au minimum : identifiant, équipement source, zone, date et heure.|Journal événement PAX-BOX.|
1765
| VAL-PRES-002| Le sens du passage est interprété lorsque la configuration le permet.|Le mouvement est qualifié entrée, sortie ou ambigu sans double comptage.|Historique des passages.|
1766
| VAL-PRES-003| Le nombre de personnes par installation est consolidé.|En régime stabilisé de test contrôlé, le comptage affiché doit correspondre à la situation terrain validée.|Comparaison observation terrain / PAX-MANAGER.|
1767
| VAL-PRES-004| Le système limite les doubles comptages lors d’un passage répété ou hésitant.|Un aller-retour ou une détection multiple ne doit pas créer plusieurs présences incohérentes.|Journal de traitement et statut du passage.|
1768
| VAL-PRES-005| Un passage ambigu est qualifié et visible.|Le système ne doit pas masquer un doute ; il doit le présenter comme anomalie ou événement à lever.|Liste anomalies PAX-MANAGER.|
1769
| VAL-PRES-006| Le délai de mise à jour de la présence locale reste compatible avec l’exploitation.|Cible POC : PAX-MANAGER mis à jour en moins de 5 s après traitement local, hors perte réseau interne.|Mesure horodatée événement / affichage.|
1770
| VAL-PRES-007| Un transfert massif de personnel reste exploitable.|Cible POC : absence de perte critique d’événements sur un scénario représentatif validé avec le client.|PV d’essai transfert massif et journaux.|
1771 1 Redmine Admin
1772
### 8.4.3 Validation de l’affichage local PAX-SCREEN / PAX-NAV
1773
Cette famille vérifie que l’information terrain peut être lue rapidement sans dépendre d’un poste informatique.
1774 56 Antoine K
1775
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1776
|----------|---------|----------------|----------|
1777
|VAL-AFF-001|Le PAX-SCREEN affiche le nombre de personnes associé à chaque installation ou sa zone.|L’affichage correspond à la donnée consolidée locale.|Photo écran / capture PAX-MANAGER.|
1778
|VAL-AFF-002|Le délai de mise à jour du PAX-SCREEN est compatible avec un usage terrain.|Cible POC : mise à jour en moins de 10 s après |validation du changement par la PAX-BOX.|Mesure horodatée transfert / affichage.|
1779
|VAL-AFF-003|L’information affichée reste simple et compréhensible.|Un utilisateur terrain doit identifier la zone et le nombre affiché sans formation complexe.|Observation recette / validation client.|
1780
|VAL-AFF-004|Une perte de communication PAX-SCREEN est visible côté supervision.|L’écran ou la communication associée apparaît en défaut ou en statut non confirmé.|Supervision PAX-MANAGER / journal technique.|
1781
|VAL-AFF-005|La configuration PAX-NAV ou navire est cohérente avec le scénario pilote.|Le moyen mobile est identifiable ou associé selon le besoin retenu pour le POC.|PV de configuration site.|
1782
1783 54 Antoine K
### 8.4.4 Validation du muster-point
1784 1 Redmine Admin
Cette famille vérifie que PAXWARE renforce les procédures de rassemblement sans les remplacer.
1785 54 Antoine K
1786 57 Antoine K
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1787
|-----------|----------------------|------------------------|----------------|
1788
|VAL-MUS-001|Un exercice muster-point peut être lancé ou suivi par un profil autorisé.|Le scénario muster affiche les personnes attendues, détectées, confirmées et non confirmées.|Écran PAX-MUSTER / PAX-MANAGER.|
1789
|VAL-MUS-002|Une confirmation de présence peut être acquise.|La confirmation est rattachée à une personne ou à un PAX-TAG connu et horodatée.|Journal validation muster.|
1790
|VAL-MUS-003|Une confirmation manuelle est possible mais encadrée.|Toute validation manuelle indique l’utilisateur, l’heure et le motif ou commentaire si requis.|Journal d’action utilisateur.|
1791
|VAL-MUS-004|Les personnes non confirmées sont identifiables.|La liste des personnes non confirmées est consultable pendant et après l’exercice.|Liste non confirmés / rapport muster.|
1792
|VAL-MUS-005|Le système distingue présence détectée et présence confirmée.|Une personne détectée dans une zone ne doit pas être automatiquement considérée confirmée si la procédure exige une validation.|Rapport muster / statut détaillé.|
1793
|VAL-MUS-006|Le rapport de muster est exploitable après exercice.|Le rapport doit contenir les écarts, délais, validations et anomalies utiles à l’analyse.|Export ou rapport PAX-MUSTER.|
1794 1 Redmine Admin
1795
### 8.4.5 Validation du mode offline et de la synchronisation différée
1796
Cette famille vérifie le principe prioritaire de PAXWARE : fonctionnement local d’abord, cloud secondaire.
1797 58 Antoine K
1798
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1799
|-----------|----------------------|------------------------|----------------|
1800
|VAL-OFF-001|La perte de connexion distante ne bloque pas les fonctions critiques locales.|Le comptage, la consultation locale, le muster et la journalisation restent disponibles.|Test coupure réseau / PV offline.|
1801
|VAL-OFF-002|Les événements acquis en mode offline sont conservés localement.|Aucune perte critique d’événement sur la durée de test retenue pour le POC.|Journal PAX-BOX avant/après reconnexion.|
1802
|VAL-OFF-003|Le retour réseau déclenche une synchronisation différée contrôlée.|Les données autorisées sont synchronisées sans bloquer l’exploitation locale.|Journal de synchronisation.|
1803
|VAL-OFF-004|Les conflits de données sont gérés selon une règle explicite.|La donnée opérationnelle locale est prioritaire pour l’état terrain ; les conflits administratifs sont signalés ou arbitrés.|Rapport conflit / journal sync.|
1804
|VAL-OFF-005|La synchronisation ne sature pas la bande passante limitée.|La file d’attente et la priorisation permettent de reprendre progressivement les échanges.|Journal file d’attente / débit observé.|
1805
|VAL-OFF-006|La saturation du stockage local est anticipée.|Des seuils d’alerte apparaissent avant saturation ; aucune purge non maîtrisée des données critiques.|État stockage / alertes PAX-MANAGER.|
1806
1807 54 Antoine K
### 8.4.6 Validation des anomalies et cas dégradés
1808 1 Redmine Admin
Cette famille vérifie que PAXWARE ne masque pas les incertitudes. Une anomalie visible et qualifiée est préférable à une information faussement certaine.
1809
1810 61 Antoine K
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1811
|-----------|----------------------|------------------------|----------------|
1812
|VAL-DEG-001|Un PAX-TAG inconnu ou non associé est détecté comme anomalie.|Le système signale un identifiant non associé sans créer de présence nominative non maîtrisée.|Liste anomalies / journal PAX-BOX.|
1813
|VAL-DEG-002|Un personnel sans PAX-TAG associé peut être traité par procédure encadrée.|Le système permet une levée de doute ou une saisie autorisée sans casser la traçabilité.|Journal action HSE / Barge-Master.|
1814
|VAL-DEG-003|Un PAX-TAG immobile est détectable ou qualifiable selon les données disponibles.|Un tag suspecté immobile en cabine ou zone de vie ne doit pas suffire à confirmer un muster si la procédure exige une validation active.|Anomalie tag immobile / rapport muster.|
1815
|VAL-DEG-004|Une incohérence entrée/sortie est visible.|Une personne détectée dans une séquence impossible ou incomplète apparaît en statut à vérifier.|Liste incohérences PAX-MANAGER.|
1816
|VAL-DEG-005|Une perte d’équipement terrain est signalée.|La perte de communication d’une PAX-ANT, PAX-SCREEN ou PAX-MUSTER remonte en supervision.|État équipement / alerte.|
1817
|VAL-DEG-006|Une anomalie peut être qualifiée par un profil autorisé.|La qualification est datée, attribuée et conservée.|Journal qualification anomalie.|
1818
|VAL-DEG-007|Les anomalies critiques restent visibles jusqu’à traitement.|Une anomalie bloquante ne doit pas disparaître sans action ou événement de résolution.|Historique anomalie.|
1819 1 Redmine Admin
1820 54 Antoine K
### 8.4.7 Validation maintenance et supervision
1821 1 Redmine Admin
Cette famille vérifie que les équipes techniques peuvent diagnostiquer l’état du système sans accès inutile aux données nominatives.
1822
1823 62 Antoine K
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1824
|-----------|----------------------|------------------------|----------------|
1825
|VAL-MAINT-001|L’état des équipements PAXWARE est consultable.|PAX-ANT, PAX-BOX, PAX-SCREEN, PAX-MUSTER et moyens connectés sont visibles selon le périmètre installé.|Écran supervision.|
1826
|VAL-MAINT-002|Un équipement hors ligne est détecté.|Le statut hors ligne remonte dans un délai compatible avec la période de supervision définie.|Journal heartbeat / supervision.|
1827
|VAL-MAINT-003|Les journaux techniques sont exploitables.|Les événements techniques utiles au diagnostic sont consultables ou exportables.|Export logs techniques.|
1828
|VAL-MAINT-004|Le technicien maintenance dispose d’un accès limité au nécessaire.|Le profil maintenance ne doit pas accéder aux données nominatives complètes si ce n’est pas requis.|Test droits utilisateur.|
1829
|VAL-MAINT-005|Une procédure de retour au fonctionnement nominal peut être suivie.|Le redémarrage ou remplacement d’un équipement ne doit pas corrompre les données locales.|PV maintenance / journal système.|
1830 1 Redmine Admin
1831 54 Antoine K
### 8.4.8 Validation cybersécurité et confidentialité
1832 1 Redmine Admin
Cette famille vérifie que la solution reste compatible avec les exigences de confidentialité, de sûreté et de contrôle des accès propres aux environnements industriels.
1833 63 Antoine K
1834
|ID critère|Critère de validation|Condition d’acceptation|Preuve attendue|
1835
|-----------|----------------------|------------------------|----------------|
1836
|VAL-SEC-001|Les accès utilisateurs sont contrôlés par profil.|Chaque acteur accède uniquement aux fonctions correspondant à son rôle.|Test matrice droits / captures.|
1837
|VAL-SEC-002|Les actions sensibles sont journalisées.|Connexion, administration, association tag, validation manuelle, support et export sont tracés.|Journal sécurité.|
1838
|VAL-SEC-003|L’accès support ACT-008 est encadré.|L’accès support doit être autorisé, limité, journalisé et réversible.|Journal support / preuve autorisation.|
1839
|VAL-SEC-004|Les données nominatives restent prioritairement locales.|La synchronisation distante ne doit pas exposer inutilement les identités complètes si la pseudonymisation est retenue.|Contrôle export / architecture données.|
1840
|VAL-SEC-005|Les communications critiques sont protégées selon le niveau retenu.|Le chiffrement ou mécanisme de protection défini dans les spécifications détaillées est vérifié en recette.|Rapport technique / configuration.|
1841
|VAL-SEC-006|La purge ou conservation des données suit une règle définie.|Aucune suppression automatique de données critiques sans règle de conservation validée.|Politique de conservation / journal purge.|
1842
1843 54 Antoine K
## 8.5 Matrice initiale de traçabilité validation
1844 1 Redmine Admin
Cette matrice relie les critères de validation aux scénarios opérationnels et aux familles d’exigences. Elle sera complétée dans le plan de tests détaillé avec les procédures, jeux de données, responsabilités et résultats attendus.
1845 64 Antoine K
1846
|Besoin validé|Scénarios|Familles d’exigences concernées|Critères associés|
1847
|-----------|----------------------|------------------------|----------------|
1848
|Préparer une personne attendue et lui attribuer un PAX-TAG.|SCN-001, SCN-002|REQ-ACQ-030 à 034, REQ-ACQ-050 à 054|VAL-PREP-001 à 005|
1849
|Détecter un passage et consolider la présence par installation.|SCN-003, SCN-004, SCN-005|REQ-ACQ-010 à 014, REQ-TRT-010 à 020|VAL-PRES-001 à 007|
1850
|Afficher localement une information claire.|SCN-006|REQ-TRT-021, exigences PAX-SCREEN|VAL-AFF-001 à 005|
1851
|Renforcer un exercice muster-point.|SCN-007, SCN-008|REQ-ACQ-020 à 024, REQ-TRT muster|VAL-MUS-001 à 006|
1852
|Fonctionner sans connexion distante.|SCN-009|REQ-TRT-005, REQ-SYNC, exigences non fonctionnelles|VAL-OFF-001 à 002|
1853
|Synchroniser au retour réseau.|SCN-010|REQ-SYNC, REQ-ACQ-043, REQ-ACQ-044|VAL-OFF-003 à 006|
1854
|Gérer les anomalies et cas dégradés.|SCN-011 à SCN-014|REQ-DEG, REQ-ACQ-041, REQ-TRT-014|VAL-DEG-001 à 007|
1855
|Maintenir et superviser les équipements.|SCN-015|REQ-MAINT, REQ-ACQ-040 à 044|VAL-MAINT-001 à 005|
1856
|Protéger les données et contrôler les accès.|Transversal|REQ-SEC, exigences RGPD et cybersécurité|VAL-SEC-001 à 006|
1857
1858 54 Antoine K
## 8.6 Conditions d’acceptation du POC ou de la recette client
1859 1 Redmine Admin
Pour une première recette client ou un POC, il est recommandé de distinguer trois niveaux d’écarts. Cette classification permet d’éviter qu’un défaut mineur de présentation bloque une démonstration utile, tout en protégeant les fonctions critiques liées à la sécurité et à la fiabilité des informations de présence.
1860
1861 65 Antoine K
1862
|Niveau d’écart|Définition|Impact sur l’acceptation|
1863
|-----------|----------------------|---------------|
1864
|Bloquant|Empêche la démonstration d’une fonction critique : comptage, muster, fonctionnement local, perte de données critique ou accès non autorisé majeur.|Le POC ou la recette ne peut pas être accepté sans correction ou dérogation formelle.|
1865
|Majeur|Dégrade fortement l’exploitation, crée une incertitude importante ou nécessite une procédure manuelle lourde.|Acceptation possible uniquement avec plan d’action, délai de correction et accord client.|
1866
|Mineur|Défaut de présentation, ergonomie, libellé, lenteur ponctuelle ou anomalie sans impact significatif sur la sécurité ni la traçabilité.|Acceptation possible avec inscription dans la liste des corrections ultérieures.|
1867
1868 1 Redmine Admin
L’acceptation globale d’un POC PAXWARE devrait être fondée sur les principes suivants :
1869
•	les critères critiques de présence, passage, muster, mode offline et traçabilité doivent être validés ;
1870
•	aucun écart bloquant ne doit rester ouvert sans dérogation client ;
1871
•	les écarts majeurs doivent être associés à un plan d’action daté ;
1872
•	les performances mesurées doivent être comparées aux cibles POC et non à des promesses industrielles définitives ;
1873
•	les limites observées doivent être documentées pour alimenter les spécifications détaillées et l’industrialisation.
1874
1875 54 Antoine K
## 8.7 Livrables de validation attendus
1876 1 Redmine Admin
À l’issue des essais de validation, les éléments suivants devront être produits ou conservés afin de constituer une preuve exploitable.
1877 54 Antoine K
1878 66 Antoine K
|Livrable|Contenu attendu|Utilité|
1879
|-----------|----------------------|----------|
1880
|Procès-verbal de recette|Liste des scénarios joués, critères validés, écarts et décisions.|Formaliser l’acceptation ou les réserves client.|
1881
|Rapport de tests|Résultats détaillés, mesures de temps, captures, observations terrain.|Préparer la qualification et les corrections.|
1882
|Exports PAXWARE|Journaux de passage, muster, anomalies, synchronisation et administration.|Fournir des preuves objectives.|
1883
|Liste des écarts|Défauts bloquants, majeurs, mineurs, actions correctives, responsables et échéances.|Piloter la suite du projet.|
1884
|Retour d’expérience client|Commentaires des utilisateurs HSE, Barge-Master, logistique, production et maintenance.|Améliorer l’ergonomie et la pertinence terrain.|
1885
1886 1 Redmine Admin
1887 54 Antoine K
## 8.8 Synthèse de la section 8
1888 1 Redmine Admin
La section 8 transforme les fonctions, exigences et scénarios opérationnels en critères de validation client. Elle constitue la première base du futur cahier de recette PAXWARE.
1889
À ce stade, les critères sont volontairement formulés au niveau système et POC. Les seuils définitifs, procédures détaillées, jeux d’essai, responsabilités et moyens de mesure seront précisés dans le plan de tests et le cahier de recette.
1890
Les familles de validation prioritaires pour PAXWARE sont :
1891
•	préparation des personnes attendues et association PAX-TAG ;
1892
•	détection des passages et consolidation du nombre de personnes par installation ;
1893
•	affichage local exploitable via PAX-SCREEN ;
1894
•	muster-point et identification des personnes non confirmées ;
1895
•	fonctionnement local en perte réseau ;
1896
•	synchronisation différée sans perte critique ;
1897
•	gestion des anomalies et cas dégradés ;
1898
•	supervision maintenance ;
1899
•	cybersécurité, confidentialité et journalisation.
1900
Cette section prépare directement la section suivante : la matrice de traçabilité initiale, qui reliera besoin, cas d’usage, exigences, scénarios et critères de validation.
1901
1902
1903
1904
1905
1906
1907
1908 54 Antoine K
# 9. Matrice de traçabilité initiale
1909 1 Redmine Admin
Cette section établit la matrice de traçabilité initiale du cahier des charges PAXWARE. Elle relie les besoins opérationnels, les acteurs, les cas d’usage, les exigences, les scénarios opérationnels et les critères de validation client.
1910
La matrice présentée ici n’est pas encore un plan de tests détaillé. Elle constitue une base de continuité pour la phase suivante du cycle en V : la spécification globale du système, puis les spécifications détaillées hardware, software, interfaces, cybersécurité et intégration.
1911
Les éléments de traçabilité sont identifiés avec le préfixe :
1912
TRC : Ligne de traçabilité initiale
1913 54 Antoine K
## 9.1 Principe général
1914 1 Redmine Admin
Dans une logique de cycle en V, chaque besoin important doit pouvoir être suivi depuis son expression opérationnelle jusqu’à sa validation terrain. La traçabilité évite qu’une fonction soit développée sans besoin associé, ou qu’un besoin client reste sans exigence, sans scénario et sans critère de validation.
1915
Pour PAXWARE, la traçabilité doit notamment permettre de vérifier que les fonctions critiques suivantes restent reliées à un besoin terrain réel :
1916
•	connaissance fiable du nombre de personnes par installation ;
1917
•	détection et consolidation des transferts entre zones ;
1918
•	confirmation des personnes lors d’un muster-point ;
1919
•	fonctionnement local prioritaire sans dépendance permanente au cloud ;
1920
•	gestion des anomalies, cas dégradés et écarts de présence ;
1921
•	protection des données, limitation des accès et traçabilité des actions ;
1922
•	préparation des futurs tests système et du cahier de recette client.
1923 54 Antoine K
## 9.2 Règles de lecture de la matrice
1924 1 Redmine Admin
Élément	Rôle dans la traçabilité	Exemple d’identifiant
1925
Besoin	Besoin opérationnel issu du cahier des charges ou du contexte terrain.	BES-001
1926
Acteur	Profil humain ou technique concerné par le besoin ou l’exigence.	ACT-001 à ACT-008
1927
Cas d’usage	Situation fonctionnelle dans laquelle le besoin est rencontré.	CU-001 à CU-012
1928
Exigence	Exigence fonctionnelle, technique, sécurité, synchronisation ou non fonctionnelle.	REQ-ACQ, REQ-TRT, REQ-CMD, REQ-PERF, REQ-MAT, REQ-DEG, REQ-SEC, REQ-SYNC, REQ-NF
1929
Scénario	Scénario opérationnel de référence utilisé pour préparer la validation.	SCN-001 à SCN-015
1930
Validation	Critère de validation client permettant d’accepter ou non le résultat.	VAL-001 à VAL-010 / VAL-PREP, VAL-PRES, VAL-MUS, etc.
1931
Test futur	Référence provisoire du test qui sera rédigé dans le futur plan de tests.	TEST-XXX
1932
Statut	État de maturité de la ligne de traçabilité.	À confirmer / À détailler / Référence POC
1933
1934 67 Antoine K
## 9.3 Référentiel initial des besoins tracés
1935
Les besoins ci-dessous servent de points d’ancrage à la matrice. Ils synthétisent les objectifs principaux déjà exprimés dans le cahier des charges.
1936 1 Redmine Admin
1937 67 Antoine K
|ID besoin|Besoin opérationnel tracé|Domaine principal|
1938
|-----------|----------------------|----------|
1939
|BES-001|Connaître le nombre de personnes présentes par installation, zone ou moyen mobile.|Exploitation / HSE / Barge-Master|
1940
|BES-002|Réduire la dépendance aux procédures papier, Ti-cards, registres et déclarations manuelles.|Exploitation / Logistique|
1941
|BES-003|Détecter et consolider les mouvements entre barge, plateformes, navires ou zones opérationnelles.|Transfert personnel|
1942
|BES-004|Accélérer et fiabiliser le muster-point en exercice ou en situation d’urgence.|HSE / Urgence|
1943
|BES-005|Garantir le fonctionnement local prioritaire même sans connexion internet ou cloud.|Continuité d’exploitation|
1944
|BES-006|Conserver une traçabilité exploitable des passages, validations, anomalies et actions utilisateurs.|Audit / retour d’expérience|
1945
|BES-007|Préserver la confidentialité, limiter les données exposées et sécuriser les accès.|RGPD / cybersécurité|
1946
|BES-008|Superviser l’état technique des équipements PAXWARE et réduire le temps de diagnostic.|Maintenance|
1947
|BES-009|Gérer les cas dégradés : tag oublié, tag inconnu, tag immobile, incohérence entrée/sortie ou équipement hors ligne.|Exploitation dégradée|
1948
|BES-010|Synchroniser les données de manière différée sans compromettre le fonctionnement local ni saturer la bande passante.|Synchronisation / cloud secondaire|
1949 1 Redmine Admin
1950 54 Antoine K
## 9.4 Matrice de traçabilité amont : besoin -> cas d’usage -> exigences
1951 1 Redmine Admin
Cette première matrice relie les besoins aux cas d’usage et aux exigences déjà exprimées dans le cahier des charges. Elle permet de vérifier qu’un besoin important dispose bien d’exigences associées.
1952 68 Antoine K
1953
1954
|ID trace|Besoin|Cas d’usage|Exigences associées|Modules concernés|Statut|
1955
|-----------|----------------------|------|--|--|-|
1956
|TRC-001|BES-001|CU-004, CU-005|REQ-TRT-020, REQ-TRT-021, REQ-PERF-003|PAX-BOX, PAX-MANAGER, PAX-SCREEN|Référence POC|
1957
|TRC-002|BES-002|CU-001, CU-002|REQ-ACQ-030, REQ-ACQ-032, REQ-ACQ-051|PAX-WRITING, PAX-MANAGER|À détailler|
1958
|TRC-003|BES-003|CU-003, CU-004|REQ-ACQ-010, REQ-ACQ-011, REQ-TRT-010, REQ-TRT-011, REQ-TRT-013|PAX-TAG, PAX-ANT, PAX-BOX|Référence POC|
1959
|TRC-004|BES-004|CU-006, CU-007|REQ-ACQ-020 à REQ-ACQ-024, REQ-DEG-002|PAX-MUSTER, PAX-BOX, PAX-MANAGER|Référence POC|
1960
|TRC-005|BES-005|CU-010, CU-011|REQ-ACQ-013, REQ-TRT-005, REQ-SYNC-001, REQ-NF-DISP|PAX-BOX, base locale|Référence POC|
1961
|TRC-006|BES-006|CU-008, CU-012|REQ-ACQ-003, REQ-ACQ-050 à REQ-ACQ-054, REQ-SEC-004|PAX-BOX, PAX-MANAGER|À détailler|
1962
|TRC-007|BES-007|CU-011, CU-012|REQ-SEC-001 à REQ-SEC-006, REQ-SYNC-004|PAX-BOX, PAX-ANT, Cloud, support ACT-008|À détailler|
1963
|TRC-008|BES-008|CU-009, CU-012|REQ-ACQ-040 à REQ-ACQ-044, REQ-NF-MAINT|PAX-ANT, PAX-SCREEN, PAX-BOX, PAX-MANAGER|Référence POC|
1964
|TRC-009|BES-009|CU-012|REQ-DEG-001 à REQ-DEG-004, REQ-TRT-014, REQ-ACQ-041|PAX-MANAGER, PAX-BOX, PAX-MUSTER|À confirmer terrain|
1965
|TRC-010|BES-010|CU-011|REQ-SYNC-001 à REQ-SYNC-006, REQ-ACQ-043|PAX-BOX, Cloud, file d’attente locale|À détailler|
1966
1967 54 Antoine K
## 9.5 Matrice de traçabilité aval : exigence -> scénario -> validation -> test futur
1968 1 Redmine Admin
Cette seconde matrice prépare la partie droite du cycle en V. Elle ne remplace pas le plan de tests, mais elle indique déjà quelles familles de tests devront être rédigées pour vérifier les exigences principales.
1969 69 Antoine K
1970
|ID trace|Exigences à vérifier|Scénarios liés|Critères validation|Test futur|Objectif de vérification|
1971
|---|----------------|------|-|-|-|
1972
|TRC-VAL-001|REQ-TRT-020 / REQ-PERF-003|SCN-004, SCN-005|VAL-PRES-001, VAL-AFF-001|TEST-SYS-004|Vérifier la cohérence entre présence terrain, PAX-MANAGER et PAX-SCREEN.|
1973
|TRC-VAL-002|REQ-ACQ-030 / REQ-ACQ-032 / REQ-ACQ-051|SCN-001, SCN-002|VAL-PREP-001, VAL-PREP-002|TEST-ADM-001|Vérifier la préparation d’une personne et l’association d’un PAX-TAG.|
1974
|TRC-VAL-003|REQ-ACQ-010 / REQ-TRT-010 / REQ-TRT-013|SCN-003, SCN-004|VAL-PRES-002, VAL-TRF-001|TEST-TRF-001|Vérifier le comptage d’un passage et l’absence de double comptage.|
1975
|TRC-VAL-004|REQ-ACQ-020 à REQ-ACQ-024|SCN-006, SCN-007|VAL-MUS-001, VAL-MUS-002|TEST-MUS-001|Vérifier la confirmation des personnes, les non-confirmés et les preuves muster.|
1976
|TRC-VAL-005|REQ-SYNC-001 / REQ-TRT-005 / REQ-ACQ-013|SCN-009, SCN-010|VAL-OFF-001, VAL-SYNC-001|TEST-OFF-001|Vérifier la continuité locale et la reprise de synchronisation.|
1977
|TRC-VAL-006|REQ-DEG-001 / REQ-DEG-002 / REQ-DEG-003|SCN-011, SCN-012, SCN-013|VAL-DEG-001, VAL-DEG-002|TEST-DEG-001|Vérifier les alertes tag oublié, tag immobile et tag inconnu.|
1978
|TRC-VAL-007|REQ-ACQ-040 à REQ-ACQ-044|SCN-014|VAL-MAINT-001|TEST-MAINT-001|Vérifier la détection d’un équipement hors ligne ou d’une saturation locale.|
1979
|TRC-VAL-008|REQ-SEC-001 à REQ-SEC-006|SCN-015|VAL-SEC-001, VAL-SEC-002|TEST-SEC-001|Vérifier chiffrement, droits, journalisation support et purge contrôlée.|
1980
|TRC-VAL-009|REQ-MAT-001 à REQ-MAT-004|SCN-014, essais site|VAL-ENV-001|TEST-ENV-001|Vérifier robustesse environnementale, IP, température, corrosion et perturbations métalliques.|
1981
|TRC-VAL-010|REQ-SYNC-002 à REQ-SYNC-006|SCN-010|VAL-SYNC-002|TEST-SYNC-002|Vérifier priorité des données locales, file d’attente et limitation bande passante.|
1982
1983 54 Antoine K
## 9.6 Matrice par sous-système PAXWARE
1984 1 Redmine Admin
Cette matrice permet d’identifier les responsabilités principales de chaque sous-système. Elle préparera la future spécification globale du système et la répartition des exigences entre hardware, software et interfaces.
1985 70 Antoine K
1986
|Sous-système|Responsabilité principale|Exigences rattachées|Points à vérifier ensuite|
1987
|---|--|--|-|
1988
|PAX-TAG|Identifier la personne ou le porteur autorisé ; permettre la détection ou la confirmation selon technologie retenue.|REQ-ACQ-001, REQ-DEG-002, REQ-MAT-TAG, REQ-PERF-001|Autonomie, port réel, tag oublié, tag immobile, robustesse bracelet.|
1989
|PAX-ANT|Détecter les passages et transmettre les événements vers la PAX-BOX.|REQ-ACQ-010 à REQ-ACQ-012, REQ-PERF-001, REQ-PERF-002, REQ-MAT-ANT, REQ-SEC-001|Portée, anti-collision, interférences, sens de passage, IP et alimentation.|
1990
|PAX-BOX|Traiter, stocker et consolider localement les événements ; maintenir le fonctionnement offline.|REQ-TRT-001 à REQ-TRT-021, REQ-SYNC-001 à REQ-SYNC-006, REQ-ACQ-044|Priorité locale, stockage, file d’attente, conflit, saturation, redémarrage.|
1991
|PAX-SCREEN|Afficher localement une information simple de présence par installation ou moyen mobile.|REQ-PERF-003, REQ-MAT-SCREEN, REQ-AFF|Latence, lisibilité, alimentation, mode dégradé, cohérence avec PAX-BOX.|
1992
|PAX-MUSTER|Confirmer les présences lors des exercices ou urgences et identifier les non-confirmés.|REQ-ACQ-020 à REQ-ACQ-024, REQ-DEG-002, REQ-SEC-004|Lecture volontaire, confirmation manuelle, preuve d’horodatage, mode offline.|
1993
|PAX-MANAGER|Superviser, consulter, administrer et exploiter les données PAXWARE.|REQ-TRT-020, REQ-ACQ-050 à REQ-ACQ-054, REQ-DEG-001 à REQ-DEG-004|Ergonomie, droits, anomalies, rapports, historique, levée de doute.|
1994
|PAX-WRITING|Préparer, encoder, associer, contrôler, remplacer ou désactiver les PAX-TAG.|REQ-ACQ-030 à REQ-ACQ-034, REQ-ACQ-051|Traçabilité d’association, remplacement bracelet, désactivation, cohérence manifeste.|
1995
|PAX-NAV / navire|Associer un moyen mobile ou navire à une présence ou une information opérationnelle.|REQ-ACQ-014, REQ-TRT-012, exigences à préciser|Identification moyen mobile, lecture pilote, liaison avec installations.|
1996
|Cloud / service distant|Recevoir les données autorisées en synchronisation différée sans devenir critique pour l’exploitation locale.|REQ-SYNC-001 à REQ-SYNC-006, REQ-SEC-005|Données pseudonymisées, purge, bande passante, conflits, accès support.|
1997
1998 54 Antoine K
## 9.7 Préparation du futur plan de tests
1999 1 Redmine Admin
Les références de tests ci-dessous sont provisoires. Elles servent à préparer le futur plan de tests sans encore détailler les procédures, les jeux d’essai, les outils de mesure ou les seuils définitifs.
2000 71 Antoine K
2001
|ID test futur|Famille de test|Cas d’usage liés|Objectif provisoire|
2002
|-|-|-|-|
2003
|TEST-ADM-001|Préparation personnel et association PAX-TAG|CU-001, CU-002|Vérifier qu’une personne peut être préparée, affectée et associée à un PAX-TAG avec journalisation.|
2004
|TEST-TRF-001|Passage simple entre deux zones|CU-003|Vérifier la détection d’un passage, le sens lorsqu’il est disponible et la mise à jour de présence.|
2005
|TEST-TRF-002|Transfert massif de personnel|CU-003, CU-004|Vérifier capacité de lecture simultanée, anti-collision et latence d’affichage.|
2006
|TEST-SYS-004|Consolidation du nombre par installation|CU-004, CU-005|Vérifier cohérence entre PAX-BOX, PAX-MANAGER et PAX-SCREEN.|
2007
|TEST-MUS-001|Muster-point exercice|CU-006, CU-007|Vérifier personnes attendues, confirmées, non confirmées et preuve de validation.|
2008
|TEST-OFF-001|Perte réseau / mode local|CU-010|Vérifier maintien des fonctions critiques sans connexion distante.|
2009
|TEST-SYNC-001|Reconnexion et synchronisation différée|CU-011|Vérifier file d’attente, priorité locale, résolution des conflits et limitation bande passante.|
2010
|TEST-DEG-001|Cas dégradés de présence|CU-012|Vérifier tag inconnu, tag immobile, tag oublié, entrée sans sortie et anomalie de cohérence.|
2011
|TEST-MAINT-001|Diagnostic équipement|CU-009|Vérifier détection d’un équipement hors ligne, logs techniques et remontée d’anomalie.|
2012
|TEST-SEC-001|Cybersécurité et accès support|CU-011, CU-012|Vérifier chiffrement, droits, journalisation, accès ACT-008 et purge contrôlée.|
2013
|TEST-ENV-001|Contraintes environnementales|Essais site / laboratoire|Vérifier IP, température, humidité, corrosion, interférences métalliques et robustesse mécanique.|
2014
2015
2016 1 Redmine Admin
2017 54 Antoine K
## 9.8 Points de vigilance de traçabilité
2018
2019 1 Redmine Admin
La matrice de traçabilité doit rester un document vivant. Elle devra être mise à jour à chaque évolution importante du cahier des charges, de l’architecture, des choix techniques ou du périmètre POC.
2020
•	aucune exigence critique ne doit rester sans scénario de validation ;
2021
•	aucun scénario de test ne doit être créé sans exigence associée ;
2022
•	les exigences liées au muster, au mode offline, à la synchronisation et à la cybersécurité doivent rester prioritaires ;
2023
•	les valeurs de performance doivent rester identifiées comme cibles MVP/POC tant qu’elles ne sont pas confirmées par essais terrain ;
2024
•	les exigences ATEX / IECEx doivent être suivies dès l’architecture, même si la certification complète n’est pas exigée pour un démonstrateur hors zone classée ;
2025
•	les accès support ACT-008 doivent toujours être reliés à des exigences de sécurité, de journalisation et d’autorisation client.
2026 54 Antoine K
## 9.9 Synthèse de la section 9
2027 1 Redmine Admin
La matrice de traçabilité initiale permet de relier les besoins PAXWARE aux cas d’usage, exigences, sous-systèmes, scénarios, critères de validation et futurs tests. Elle constitue une passerelle essentielle entre le cahier des charges et les prochaines phases du cycle en V.
2028
À ce stade, elle doit être considérée comme une base de travail structurante. Elle devra être complétée dans les documents suivants : spécification globale du système, architecture système, spécifications détaillées et plan de tests.
2029
2030
2031 54 Antoine K
# 10. Conclusion et passage vers la spécification globale du système
2032 1 Redmine Admin
Cette section clôture le cahier des charges / expression du besoin PAXWARE et prépare le passage vers la phase suivante du cycle en V : la spécification globale du système.
2033
Le document amont a permis de transformer une problématique terrain - savoir qui est où, sur un site offshore multi-installations - en besoins opérationnels, fonctions attendues, exigences initiales, scénarios de référence, critères de validation client et matrice de traçabilité.
2034
La présente conclusion ne valide pas encore une conception technique détaillée. Elle confirme la cohérence du besoin, fixe le périmètre de référence et précise les éléments qui devront être repris dans les documents suivants.
2035
2036 54 Antoine K
## 10.1 Synthèse du travail réalisé
2037 1 Redmine Admin
Le cahier des charges PAXWARE constitue le socle de la phase amont du cycle en V. Il formalise les éléments nécessaires pour engager ensuite une spécification système structurée.
2038
Partie du document	Apport principal	Statut
2039
1. Objet du document	Définition du rôle du cahier des charges et de son positionnement dans le cycle en V.	Établi
2040
2. Contexte général	Description du problème terrain, des limites des Ti-cards, registres, déclarations et procédures manuelles.	Établi
2041
3. Périmètre du système attendu	Définition du périmètre fonctionnel, matériel, logiciel et hors périmètre initial.	Établi
2042
4. Acteurs et utilisateurs	Identification des profils ACT-001 à ACT-008 et préparation des droits d’accès.	Établi
2043
5. Fonctions attendues	Transformation des besoins en exigences d’acquisition, traitement, commande, performances, cybersécurité et synchronisation.	Établi
2044
6. Exigences non fonctionnelles	Expression des contraintes globales de disponibilité, sûreté, environnement, ergonomie, maintenance et exploitation.	Établi
2045
7. Scénarios opérationnels	Définition des scénarios terrain de référence pour préparer les essais et la validation.	Établi
2046
8. Critères de validation client	Définition des critères d’acceptation POC et des futures bases de recette.	Établi
2047
9. Matrice de traçabilité initiale	Mise en relation des besoins, cas d’usage, exigences, scénarios, validations et tests futurs.	Établi
2048
2049 72 Antoine K
## 10.2 Niveau de maturité atteint
2050 1 Redmine Admin
À l’issue de cette première phase, PAXWARE dispose d’une base documentaire exploitable pour dialoguer avec un client pilote, un partenaire technique, un bureau d’études, un industriel, un investisseur ou un accompagnateur projet.
2051
Le niveau atteint peut être qualifié de cahier des charges fonctionnel structuré. Il ne s’agit pas encore d’un dossier de conception détaillée, ni d’un dossier d’industrialisation complet.
2052
Domaine	Niveau atteint	Commentaire
2053
Besoin opérationnel	Fort	Le besoin terrain est clairement exprimé et relié aux contraintes offshore.
2054
Périmètre fonctionnel	Bon	Les fonctions principales sont définies et structurées autour de la présence, des passages, du muster et de la supervision.
2055
Acteurs et usages	Bon	Les acteurs principaux sont identifiés et reliés aux cas d’usage.
2056
Exigences initiales	Bon	Les premières familles d’exigences sont posées avec une logique de traçabilité.
2057
Critères de validation	Initial	Les critères client sont établis mais devront être transformés en protocole de tests mesurable.
2058
Architecture système	À démarrer	La prochaine étape devra définir les sous-systèmes, flux, interfaces et modes système.
2059
Conception détaillée	Non démarrée	Les choix hardware, software, firmware, réseau et cybersécurité détaillée restent à produire.
2060
Industrialisation	À préparer	Les contraintes ATEX, environnement, fabrication, maintenance et qualification devront être approfondies.
2061
2062 72 Antoine K
## 10.3 Points de vigilance avant la suite
2063 1 Redmine Admin
Certains points devront être conservés comme vigilances majeures dans les prochaines phases. Ils ne bloquent pas la suite du cycle en V, mais ils devront être traités sans ambiguïté dans les spécifications détaillées.
2064
Point de vigilance	Risque associé	Traitement attendu dans la suite
2065
Technologie de détection	Ambiguïté entre détection radio, lecture courte portée, confirmation muster et sens de passage.	Définir clairement les technologies retenues, les performances attendues et les limites d’usage.
2066
Muster-point	Confusion possible entre présence détectée et présence confirmée.	Distinguer présence observée, présence attendue, présence confirmée et validation manuelle autorisée.
2067
Mode offline	Risque de perte d’information ou de conflit au retour réseau.	Définir précisément les règles de file d’attente, horodatage, conflit, priorité locale et synchronisation différée.
2068
Facteur humain	Oubli de port du PAX-TAG, tag immobile, tag non associé ou utilisation incorrecte.	Prévoir des anomalies explicites, alertes, procédures de levée de doute et droits de correction.
2069
Cybersécurité	Accès support non maîtrisé, données exposées, actions non tracées.	Définir les droits, journaux, chiffrement, accès ACT-008 et politiques de purge.
2070
ATEX / IECEx	Risque d’incompatibilité future avec les zones classées offshore.	Anticiper les contraintes dès l’architecture, même si le démonstrateur n’est pas certifié complet.
2071
Environnement offshore	Corrosion, chaleur, humidité, interférences métalliques, réseau instable.	Transformer les contraintes en exigences matérielles et procédures de qualification.
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081 72 Antoine K
## 10.4 Décision de passage vers la spécification globale
2082 1 Redmine Admin
Le cahier des charges peut être considéré comme suffisamment structuré pour engager la rédaction de la spécification globale du système PAXWARE.
2083
Cette décision ne signifie pas que toutes les valeurs techniques sont définitivement figées. Elle signifie que le besoin, le périmètre, les acteurs, les fonctions attendues, les scénarios et les critères de validation sont suffisamment clairs pour commencer à définir l’architecture globale du système.
2084
•	les fonctions critiques sont identifiées ;
2085
•	les acteurs et responsabilités principales sont définis ;
2086
•	les cas d’usage opérationnels sont décrits ;
2087
•	les familles d’exigences sont initialisées ;
2088
•	les critères de validation client sont préparés ;
2089
•	la traçabilité entre besoin, scénario, exigence et validation est engagée.
2090 72 Antoine K
## 10.5 Document suivant à produire
2091 1 Redmine Admin
Le document suivant du cycle en V sera :
2092
Spécification globale du système PAXWARE - Version 0.1
2093
Ce document aura pour objectif de décrire le fonctionnement du système PAXWARE dans son ensemble, sans encore descendre dans le détail complet de chaque carte électronique, composant logiciel ou procédure industrielle.
2094 72 Antoine K
2095
|Élément à définir|Objectif dans la spécification globale|
2096
|-|-|
2097
|Architecture fonctionnelle globale|Décrire comment PAX-TAG, PAX-ANT, PAX-BOX, PAX-SCREEN, PAX-MUSTER, PAX-MANAGER, PAX-WRITING, PAX-NAV et cloud différé travaillent ensemble.|
2098
|Sous-systèmes|Créer une nomenclature SS-XXX pour chaque bloc matériel, logiciel ou service.|
2099
|Interfaces principales|Définir les échanges entre PAX-TAG, PAX-ANT, PAX-BOX, interfaces locales, PAX-SCREEN, PAX-MUSTER et cloud.|
2100
|Modes de fonctionnement|Décrire le mode normal, transfert, muster, urgence, offline, reconnexion, maintenance et support contrôlé.|
2101
|Flux de données|Décrire les événements acquis, traités, affichés, journalisés et synchronisés.|
2102
|Exigences système globales|Créer les exigences REQ-SYS-XXX à partir des exigences fonctionnelles et non fonctionnelles.|
2103
|Contraintes d’architecture|Préparer les exigences futures hardware, software, réseau, cybersécurité, ATEX et maintenance.|
2104
|Préparation des tests système|Relier chaque fonction globale à un futur scénario de test et de recette.|
2105
2106 1 Redmine Admin
2107
2108
2109
2110
2111
10.6 Nomenclature recommandée pour la suite
2112
Pour éviter les confusions lors du passage en spécification globale, la suite du cycle en V devra utiliser une nomenclature stable. Les identifiants déjà créés devront être conservés et complétés progressivement.
2113
Préfixe	Signification	Exemple
2114
ACT	Acteur humain, opérationnel, technique ou support.	ACT-004 Barge-Master
2115
CU	Cas d’usage issu du cahier des charges.	CU-006 Lancer ou suivre un muster-point
2116
SCN	Scénario opérationnel de référence.	SCN-007 Muster-point urgence
2117
VAL	Critère de validation client ou POC.	VAL-MUS-001
2118
TRC	Ligne de traçabilité entre besoin, exigence, scénario et validation.	TRC-004
2119
SS	Sous-système de la spécification globale.	SS-003 PAX-BOX
2120
IF	Interface entre deux sous-systèmes.	IF-002 PAX-ANT vers PAX-BOX
2121
MODE	Mode de fonctionnement système.	MODE-004 Offline local
2122
REQ-SYS	Exigence système globale.	REQ-SYS-001
2123
TEST	Test futur du plan de vérification.	TEST-SYS-004
2124
2125
 10.7 Critères de sortie du cahier des charges
2126
Avant d’utiliser ce cahier des charges comme référence d’entrée pour la spécification globale, les critères suivants devront être vérifiés.
2127
Critère de sortie	Condition attendue	Statut recommandé
2128
Cohérence du besoin	Le besoin principal est clairement exprimé et relié au contexte offshore.	Acceptable
2129
Périmètre initial	Le périmètre fonctionnel, matériel, logiciel et hors périmètre est défini.	Acceptable
2130
Acteurs	Les acteurs ACT-001 à ACT-008 sont identifiés et non contradictoires.	Acceptable
2131
Exigences	Les exigences initiales sont numérotées et rattachables aux fonctions attendues.	Acceptable
2132
Cas d’usage	Les cas d’usage principaux couvrent l’exploitation normale, le muster et les cas dégradés.	Acceptable
2133
Validation client	Les critères de validation sont suffisamment définis pour préparer le futur cahier de recette.	Acceptable
2134
Traçabilité	Une première matrice relie besoins, cas d’usage, exigences, scénarios, validations et tests futurs.	Acceptable
2135
Valeurs techniques	Les valeurs cibles restent à confirmer par essais, dimensionnement et arbitrage technique.	À détailler en phase suivante
2136
2137
10.8 Conclusion générale
2138
Le cahier des charges PAXWARE formalise une première base cohérente pour un système autonome de connaissance de présence en environnement offshore et industriel isolé.
2139
Il démontre que le projet ne se limite pas à un objet connecté ou à un simple outil de pointage. PAXWARE est un écosystème local destiné à consolider la présence par installation, améliorer la gestion des transferts, renforcer les exercices muster-point, faciliter la levée de doute et maintenir une information exploitable même en cas de perte de réseau.
2140
La prochaine étape doit transformer cette expression du besoin en architecture système globale. Cette architecture devra préciser les sous-systèmes, les interfaces, les flux de données, les modes de fonctionnement et les exigences système qui serviront ensuite de base aux spécifications détaillées hardware, software, cybersécurité, intégration et tests.
2141
Le présent document peut donc être utilisé comme document d’entrée de référence pour la rédaction de la Spécification globale du système PAXWARE.