CANEVAS DES DOCUMENTS DU PROJET

# Canevas 6 — Dossier infrastructure informatique  réseau  sauvegarde

# Canevas 6 — Dossier infrastructure informatique / réseau / sauvegarde

## 1. Objet du document

### 1.1 Finalité du dossier infrastructure

Cette partie précise l’objectif du document.

Le dossier infrastructure décrit l’environnement informatique nécessaire au fonctionnement, au déploiement, à l’exploitation, à la supervision, à la sauvegarde et à la restauration du système. Il couvre les serveurs, postes clients, environnements de test et de production, réseau, sécurité, accès distants, stockage, sauvegardes, supervision, journaux, procédures d’installation, procédures de reprise et contraintes d’exploitation.

Ce document est particulièrement important lorsque le système ne se limite pas à un équipement embarqué isolé, mais comporte également une infrastructure de type serveur, application, base de données, réseau local, accès distant, SAS d’échange, sauvegarde et supervision.

**Exemple :**

> Le présent document a pour objectif de décrire l’infrastructure informatique nécessaire au fonctionnement du système, incluant les serveurs, environnements, réseaux, postes utilisateurs, sauvegardes, mécanismes de restauration, accès administrateur, supervision et contraintes d’exploitation.

### 1.2 Positionnement dans le cycle en V

Cette partie situe le dossier infrastructure dans le cycle en V.

Le dossier infrastructure est produit à partir de la spécification globale et du document d’architecture système. Il permet de détailler les éléments techniques nécessaires au fonctionnement de la partie informatique du système. Il servira de base aux phases de déploiement, d’intégration, de tests d’infrastructure, de validation et d’exploitation.

Il alimente notamment :

```text id="m5bq09"

- la conception détaillée infrastructure ;

- les procédures d’installation ;

- les scripts de déploiement ;

- les procédures de sauvegarde ;

- les procédures de restauration ;

- le plan de supervision ;

- les tests d’intégration système ;

- les tests de validation infrastructure ;

- le manuel administrateur ;

- le manuel d’exploitation.

```

Dans le cycle en V, le dossier infrastructure est vérifié par les tests d’installation, les tests d’intégration infrastructure, les tests de sauvegarde/restauration, les tests réseau, les tests de supervision et les scénarios de validation associés.

```text id="7l1vwd"

Spécification globale

        ↓

Architecture système / conception globale

        ↓

Dossier infrastructure

        ↓

Conception détaillée infrastructure / scripts / configuration

        ↓

Installation / déploiement / paramétrage

        ↑

Tests unitaires infrastructure

        ↑

Tests d’intégration infrastructure

        ↑

Tests système

        ↑

Validation sauvegarde / réseau / exploitation

```

### 1.3 Différence avec l’architecture système

Cette partie précise la frontière entre l’architecture système et le dossier infrastructure.

L’architecture système décrit les grands blocs et les principes généraux : serveur applicatif, base de données, réseau, sauvegarde, poste opérateur, SAS, supervision.

Le dossier infrastructure détaille concrètement comment ces éléments sont installés, dimensionnés, connectés, sécurisés, sauvegardés, supervisés et exploités.

**Exemple :**

```text id="eqc9t9"

Architecture système :

Le système comporte un serveur applicatif, une base de données, un serveur de sauvegarde et une interface opérateur accessible via le réseau client.

Dossier infrastructure :

Le serveur applicatif est hébergé sur une machine virtuelle Ubuntu Server 24.04, avec 4 vCPU, 16 Go RAM et 200 Go de stockage. Il communique avec le serveur base de données via le VLAN applicatif. Les sauvegardes sont réalisées quotidiennement vers le serveur SRV-BKP via une tâche planifiée.

```

### 1.4 Différence avec la conception détaillée logicielle

Cette partie explique que le dossier infrastructure ne décrit pas le code applicatif.

Le dossier infrastructure décrit l’environnement d’exécution et d’exploitation du logiciel : serveurs, réseau, OS, services, sauvegarde, certificats, droits, supervision. La conception détaillée logicielle décrira l’organisation interne du logiciel : modules, API, base de données, algorithmes, classes, traitements, règles métier.

**Exemple :**

```text id="mayl01"

Dossier infrastructure :

Le service applicatif est exécuté comme un service système supervisé. Les logs applicatifs sont stockés dans /var/log/application et exportés vers le système de supervision.

Conception logicielle :

Le module AlarmService traite les événements d’alarme, applique les règles de criticité et expose les alarmes via l’API REST /api/alarms.

```

### 1.5 Responsabilités de rédaction et d’approbation

Cette partie précise qui rédige, relit et approuve le document.

Le dossier infrastructure doit être rédigé par l’architecte infrastructure, l’administrateur système ou le responsable technique, avec les contributions des équipes réseau, cybersécurité, logiciel, exploitation, sauvegarde, validation et éventuellement du client si l’infrastructure est fournie ou administrée par ce dernier.

**Exemple :**

```text id="flpch0"

Rédaction : architecte infrastructure / administrateur système / responsable technique

Contribution : réseau, cybersécurité, logiciel serveur, base de données, exploitation, validation

Relecture : chef de projet, responsable sécurité, responsable système, client si infrastructure client

Approbation : responsable technique fournisseur et responsable infrastructure client

```

---

## 2. Références et documents applicables

### 2.1 Documents d’entrée

Cette partie liste les documents utilisés pour rédiger le dossier infrastructure.

**Exemples :**

```text id="082cy9"

- Cahier des charges / expression du besoin

- Spécification globale / spécification système

- Architecture système / conception globale

- Dossier des modes de fonctionnement

- Spécification détaillée serveur / application

- Spécification des interfaces

- Contraintes d’exploitation client

- Contraintes cybersécurité client

- Contraintes réseau client

- Contraintes d’hébergement

- Exigences de sauvegarde et restauration

- Exigences de disponibilité

```

### 2.2 Documents applicables

Cette partie liste les documents que l’infrastructure doit respecter.

Un document applicable peut être une norme, une procédure interne, un standard client, une politique de sécurité ou une contrainte contractuelle.

**Exemples :**

```text id="s1yefj"

- politique de sécurité informatique client ;

- politique de mots de passe ;

- politique de sauvegarde ;

- référentiel réseau ;

- règles d’administration système ;

- règles de nommage des serveurs ;

- procédure de gestion des comptes ;

- procédure de gestion des incidents ;

- politique de mise à jour ;

- règles d’hébergement ;

- exigences RGPD si des données personnelles sont traitées ;

- exigences de journalisation.

```

### 2.3 Documents produits à partir du dossier infrastructure

Cette partie liste les documents qui utiliseront le dossier infrastructure comme entrée.

**Exemples :**

```text id="7p7s7b"

- procédures d’installation ;

- procédures de déploiement ;

- procédures de sauvegarde ;

- procédures de restauration ;

- procédures d’exploitation ;

- procédures de supervision ;

- procédures de maintenance infrastructure ;

- dossier de configuration livrée ;

- plan de tests infrastructure ;

- rapport de tests de sauvegarde/restauration ;

- manuel administrateur ;

- manuel exploitant.

```

### 2.4 Gestion des versions et dépendances

Cette partie précise que l’infrastructure doit être versionnée.

Les versions des serveurs, OS, services, bases de données, composants applicatifs, scripts et configurations doivent être identifiées. Une modification d’infrastructure peut avoir un impact sur la sécurité, la compatibilité logicielle, les performances ou la validation.

**Exemple :**

> Toute modification de version d’un système d’exploitation, d’un moteur de base de données, d’un serveur web, d’un certificat, d’une règle pare-feu ou d’un script de sauvegarde doit être tracée et faire l’objet d’une analyse d’impact si elle affecte un environnement validé.

---

## 3. Définitions, acronymes et conventions

### 3.1 Définitions

Cette partie définit les termes techniques utilisés.

**Exemples :**

```text id="5gex0p"

Infrastructure :

Ensemble des ressources matérielles, logicielles, réseau et système nécessaires à l’exécution, l’exploitation, la supervision, la sauvegarde et la maintenance du système.

Environnement :

Ensemble cohérent de ressources utilisées pour un usage donné : développement, test, validation, préproduction, production ou maintenance.

SAS :

Zone ou serveur d’échange contrôlé permettant de transférer des fichiers, configurations, mises à jour ou rapports entre deux environnements.

Sauvegarde :

Copie contrôlée de données, configurations ou systèmes permettant une restauration ultérieure.

Restauration :

Action permettant de rétablir des données, configurations ou services à partir d’une sauvegarde.

Supervision :

Ensemble de mécanismes permettant de surveiller l’état des serveurs, services, applications, flux, sauvegardes et ressources.

```

### 3.2 Acronymes

**Exemples :**

```text id="s9b8m6"

API : Application Programming Interface

BKP : Backup / sauvegarde

CPU : Central Processing Unit

DB : Database / base de données

DNS : Domain Name System

HTTPS : HyperText Transfer Protocol Secure

LAN : Local Area Network

NTP : Network Time Protocol

OS : Operating System

SAS : Zone d’échange contrôlée

SSH : Secure Shell

TLS : Transport Layer Security

VM : Virtual Machine

VPN : Virtual Private Network

```

### 3.3 Convention de nommage des environnements

Cette partie définit comment les environnements sont nommés.

**Exemple :**

```text id="zxjn3s"

DEV : développement

INT : intégration

TST : test

VAL : validation

PREPROD : préproduction

PROD : production

MNT : maintenance

BKP : sauvegarde

```

### 3.4 Convention de nommage des serveurs

**Exemple :**

```text id="6n9356"

SRV-APP-PROD-01 : serveur applicatif production n°1

SRV-DB-PROD-01 : serveur base de données production n°1

SRV-BKP-PROD-01 : serveur sauvegarde production n°1

SRV-APP-VAL-01 : serveur applicatif validation n°1

SRV-SAS-01 : serveur d’échange contrôlé

```

### 3.5 Convention de description des flux réseau

Cette partie précise le format utilisé pour décrire les flux.

**Exemple :**

```text id="mgwtpz"

ID flux :

Source :

Destination :

Protocole :

Port :

Sens :

Usage :

Criticité :

Chiffrement :

Authentification :

Journalisation :

Responsable :

```

---

## 4. Vue générale de l’infrastructure

### 4.1 Présentation synthétique

Cette partie donne une vue globale de l’infrastructure.

Elle doit permettre de comprendre quels environnements existent, où sont hébergés les serveurs, comment les équipements se connectent, comment les utilisateurs accèdent au système, comment les sauvegardes sont réalisées et comment l’ensemble est supervisé.

**Exemple :**

> L’infrastructure est organisée autour d’un environnement de validation et d’un environnement de production. Chaque environnement comprend un serveur applicatif, une base de données et un accès web pour les opérateurs. L’équipement embarqué communique avec le serveur applicatif via le réseau client. Les sauvegardes sont réalisées quotidiennement vers un serveur dédié. Les services critiques sont supervisés et les journaux techniques sont conservés pour diagnostic.

### 4.2 Synoptique général de l’infrastructure

Cette partie doit contenir un schéma d’ensemble.

**Exemple textuel :**

```text id="ltpn0o"

Équipements embarqués

        |

        | Réseau site / VPN / 4G

        v

+----------------------+

| Serveur applicatif   |

| SRV-APP-PROD-01      |

+----------+-----------+

           |

           | réseau applicatif

           v

+----------------------+

| Serveur base données |

| SRV-DB-PROD-01       |

+----------+-----------+

           |

           | sauvegarde planifiée

           v

+----------------------+

| Serveur sauvegarde   |

| SRV-BKP-PROD-01      |

+----------------------+

Postes opérateurs

        |

        | HTTPS

        v

Interface web applicative

```

### 4.3 Principes généraux retenus

Cette partie décrit les principes structurants de l’infrastructure.

**Exemples :**

```text id="dkcpnx"

- séparation des environnements test, validation et production ;

- séparation des rôles applicatif, base de données et sauvegarde ;

- accès utilisateur via interface web sécurisée ;

- accès administrateur réservé et journalisé ;

- sauvegarde automatisée des données critiques ;

- restauration testée selon une fréquence définie ;

- supervision des services critiques ;

- limitation des flux réseau aux seuls flux nécessaires ;

- conservation des logs pour diagnostic et audit ;

- déploiement versionné.

```

### 4.4 Périmètre couvert par le dossier

Cette partie précise ce qui est inclus dans le dossier.

**Exemples :**

```text id="k90cgz"

Inclus :

- serveurs ;

- machines virtuelles ;

- OS ;

- services applicatifs ;

- base de données ;

- réseau applicatif ;

- postes utilisateurs ;

- accès administrateur ;

- sauvegarde ;

- restauration ;

- supervision ;

- logs ;

- SAS ;

- procédures d’exploitation.

Non inclus :

- conception interne du logiciel ;

- schémas électroniques ;

- câblage interne de l’équipement embarqué ;

- maintenance du réseau Internet public ;

- administration générale du SI client hors périmètre projet.

```

### 4.5 Responsabilités client / fournisseur

Cette partie clarifie les responsabilités de chaque partie.

**Exemple :**

```text id="3m3qky"

Élément | Responsable fourniture | Responsable installation | Responsable exploitation | Responsable maintenance

Serveur applicatif | Client | Fournisseur | Client | Client / fournisseur selon contrat

Application serveur | Fournisseur | Fournisseur | Client | Fournisseur

Base de données | Fournisseur | Fournisseur | Client | Client / fournisseur

Réseau local | Client | Client | Client | Client

Sauvegarde | Client + fournisseur | Fournisseur | Client | Client

Supervision | Client | Client / fournisseur | Client | Client

Postes opérateurs | Client | Client | Client | Client

```

---

## 5. Environnements

### 5.1 Objet de la description des environnements

Cette partie décrit les différents environnements nécessaires au projet.

Un environnement est un ensemble cohérent de ressources permettant de développer, intégrer, tester, valider, exploiter ou maintenir le système. La séparation des environnements évite de tester directement en production et permet de maîtriser les risques.

### 5.2 Liste des environnements prévus

**Exemples :**

```text id="a9kz8u"

- environnement de développement ;

- environnement d’intégration ;

- environnement de test ;

- environnement de validation ;

- environnement de préproduction ;

- environnement de production ;

- environnement de maintenance ;

- environnement de formation ;

- environnement de sauvegarde / restauration.

```

### 5.3 Environnement de développement

Cette partie décrit l’environnement utilisé par les développeurs.

Il peut être local ou partagé. Il n’est généralement pas soumis au même niveau de disponibilité ou de sécurité que la production, mais il doit rester maîtrisé pour éviter des écarts trop importants avec les environnements cibles.

**Exemples d’éléments à décrire :**

```text id="b757q1"

- postes développeurs ;

- dépôt de code ;

- outils de compilation ;

- simulateurs ;

- environnement de test local ;

- accès aux dépendances ;

- jeux de données de développement ;

- restrictions sur les données réelles ;

- règles de sécurité minimales.

```

### 5.4 Environnement d’intégration

Cette partie décrit l’environnement où les composants sont assemblés pour la première fois.

**Exemple :**

> L’environnement d’intégration permet de connecter le logiciel embarqué, le serveur applicatif, la base de données et l’interface opérateur avant exécution des tests système. Il peut contenir des simulateurs de capteurs ou d’équipements pour faciliter les essais.

**Éléments à préciser :**

```text id="1lv11h"

- serveur d’intégration ;

- équipement réel ou simulateur ;

- base de données dédiée ;

- réseau isolé ;

- jeux de données d’intégration ;

- accès des équipes techniques ;

- fréquence de réinitialisation ;

- stratégie de gestion des versions.

```

### 5.5 Environnement de test

Cette partie décrit l’environnement utilisé pour les tests techniques.

Il peut être utilisé pour les tests fonctionnels, tests de performance, tests d’installation, tests de non-régression ou tests de robustesse.

**Exemples :**

```text id="m83ziv"

- tests unitaires serveur ;

- tests API ;

- tests base de données ;

- tests de communication ;

- tests de charge ;

- tests de sauvegarde ;

- tests de restauration ;

- tests d’accès utilisateur ;

- tests d’erreur réseau.

```

### 5.6 Environnement de validation

Cette partie décrit l’environnement utilisé pour la validation fournisseur ou client.

Il doit être représentatif de la production, ou les écarts doivent être explicitement indiqués.

**Exemple :**

> L’environnement de validation est représentatif de l’environnement de production en termes de versions logicielles, configuration serveur, base de données, réseau applicatif et procédures d’exploitation. Les écarts éventuels sont documentés et pris en compte dans le rapport de validation.

### 5.7 Environnement de préproduction

Cette partie est utile lorsqu’un environnement proche de la production est nécessaire avant mise en service.

**Exemples d’usage :**

```text id="o1ah3s"

- validation finale avant déploiement ;

- répétition de migration ;

- test de sauvegarde/restauration ;

- test de montée de version ;

- test de configuration réelle ;

- formation utilisateur avancée ;

- vérification de performance.

```

### 5.8 Environnement de production

Cette partie décrit l’environnement réel d’exploitation.

**Éléments à préciser :**

```text id="8jvcvx"

- serveurs utilisés ;

- réseau utilisé ;

- base de données ;

- sauvegardes actives ;

- supervision active ;

- utilisateurs autorisés ;

- procédures d’exploitation ;

- contraintes de disponibilité ;

- plages de maintenance ;

- responsabilités d’administration.

```

### 5.9 Environnement de maintenance

Cette partie décrit les moyens utilisés pour diagnostiquer, reproduire ou corriger une anomalie.

**Exemples :**

```text id="3ivwbs"

- copie partielle de production anonymisée ;

- serveur de reproduction d’incident ;

- outils de diagnostic ;

- accès aux logs ;

- accès aux configurations ;

- simulateur d’équipement ;

- procédure de reproduction ;

- limitation d’accès aux données sensibles.

```

### 5.10 Tableau comparatif des environnements

**Exemple :**

```text id="ngvw7i"

Environnement | Usage | Données réelles | Accès client | Niveau sécurité | Sauvegarde | Représentativité production

DEV | développement | non | non | faible/moyen | non obligatoire | faible

INT | intégration | non | limité | moyen | optionnelle | moyenne

VAL | validation | données test | oui | élevé | oui | élevée

PREPROD | répétition prod | données anonymisées ou réelles contrôlées | oui | élevé | oui | très élevée

PROD | exploitation | oui | oui | très élevé | oui | totale

MNT | diagnostic | contrôlé | limité | élevé | selon usage | variable

```

---

## 6. Serveurs et machines

### 6.1 Objet de la section serveurs

Cette partie décrit les machines physiques ou virtuelles nécessaires au fonctionnement du système.

Il faut préciser pour chaque serveur son rôle, son environnement, ses caractéristiques, son OS, ses services, ses dépendances, ses accès et ses responsabilités d’administration.

### 6.2 Liste des serveurs

**Exemple :**

```text id="bmxdkn"

SRV-APP-PROD-01 : serveur applicatif production

SRV-DB-PROD-01 : serveur base de données production

SRV-BKP-PROD-01 : serveur sauvegarde production

SRV-MON-PROD-01 : serveur supervision

SRV-SAS-01 : serveur d’échange contrôlé

SRV-APP-VAL-01 : serveur applicatif validation

SRV-DB-VAL-01 : serveur base de données validation

```

### 6.3 Fiche descriptive d’un serveur

Cette partie définit la structure à utiliser pour décrire chaque serveur.

**Modèle de fiche :**

```text id="9mwj2s"

Nom du serveur :

Environnement :

Rôle :

Type : physique / virtuel / conteneur / appliance

Système d’exploitation :

CPU :

RAM :

Stockage :

Réseau :

Adresse IP :

Nom DNS :

Services hébergés :

Dépendances :

Sauvegarde :

Supervision :

Administrateurs autorisés :

Criticité :

Procédure de redémarrage :

Commentaires :

```

### 6.4 Serveur applicatif

Cette partie décrit le serveur applicatif.

**Exemple :**

```text id="2yfsfa"

Nom : SRV-APP-PROD-01

Rôle : héberger les services applicatifs et l’interface web

OS : Linux Server

Services :

- service applicatif principal ;

- API ;

- serveur web ou reverse proxy ;

- service de traitement des alarmes ;

- service de réception des données.

Dépendances :

- serveur base de données ;

- réseau applicatif ;

- certificat TLS ;

- service d’authentification si applicable.

Contraintes :

- accès HTTPS depuis postes opérateurs ;

- accès limité à la base de données ;

- logs applicatifs conservés ;

- redémarrage contrôlé documenté.

```

### 6.5 Serveur base de données

Cette partie décrit le serveur ou service de base de données.

**Exemple :**

```text id="q8ld5f"

Nom : SRV-DB-PROD-01

Rôle : stocker les mesures, alarmes, événements, utilisateurs, configurations et historiques.

Services :

- moteur de base de données ;

- outils d’administration ;

- tâche de sauvegarde ;

- monitoring base de données.

Contraintes :

- accès direct limité au serveur applicatif ;

- sauvegarde quotidienne ;

- restauration testée ;

- journalisation des erreurs ;

- supervision de l’espace disque ;

- contrôle des accès administrateur.

```

### 6.6 Serveur de sauvegarde

Cette partie décrit le serveur de sauvegarde.

**Exemple :**

```text id="4c4kca"

Nom : SRV-BKP-PROD-01

Rôle : conserver les sauvegardes de la base de données, des configurations et des fichiers critiques.

Contraintes :

- stockage séparé du serveur applicatif ;

- accès restreint ;

- capacité dimensionnée selon la rétention ;

- supervision des échecs de sauvegarde ;

- tests de restauration réguliers ;

- protection contre suppression accidentelle si applicable.

```

### 6.7 Serveur de supervision

Cette partie décrit le serveur ou service de supervision.

**Exemples de fonctions :**

```text id="eug05i"

- vérifier la disponibilité des serveurs ;

- surveiller l’espace disque ;

- surveiller les services applicatifs ;

- surveiller les sauvegardes ;

- surveiller les certificats ;

- surveiller les erreurs applicatives ;

- générer des alertes techniques ;

- conserver des historiques de supervision.

```

### 6.8 Serveur SAS ou zone d’échange contrôlée

Cette partie décrit le rôle du SAS.

Un SAS est utile lorsqu’il faut maîtriser les échanges entre environnements, par exemple entre test et production, entre fournisseur et client, ou entre un réseau interne et une zone isolée.

**Exemples d’usage :**

```text id="s4of8h"

- dépôt de fichiers de mise à jour ;

- transfert de rapports ;

- transfert de sauvegardes ;

- validation manuelle avant import en production ;

- échange de fichiers entre zones réseau ;

- dépôt de logs pour support technique ;

- passage de configurations validées.

```

**Exemple de description :**

```text id="o9wp7l"

Le SAS permet de déposer des fichiers validés avant transfert vers l’environnement de production. Les fichiers déposés sont identifiés, horodatés, contrôlés et journalisés. Aucun fichier ne doit être exécuté ou importé en production sans validation préalable.

```

### 6.9 Dimensionnement des serveurs

Cette partie décrit les hypothèses de dimensionnement.

**Exemples de critères :**

```text id="fr14hl"

- nombre d’équipements connectés ;

- fréquence d’envoi des données ;

- volume de données par message ;

- nombre d’utilisateurs simultanés ;

- durée de conservation des historiques ;

- fréquence des sauvegardes ;

- marge de stockage ;

- charge CPU attendue ;

- besoins mémoire ;

- croissance prévue.

```

**Exemple :**

```text id="3bl5au"

Hypothèse :

100 équipements transmettent 1 message toutes les 60 secondes.

Chaque message représente environ 2 Ko.

Volume brut journalier approximatif :

100 × 1440 × 2 Ko = 288 Mo/jour hors index, logs et métadonnées.

```

### 6.10 Tableau récapitulatif des serveurs

**Exemple :**

```text id="sddm5e"

Serveur | Rôle | Environnement | CPU | RAM | Stockage | OS | Criticité

SRV-APP-PROD-01 | Application | PROD | 4 vCPU | 16 Go | 200 Go | Linux | élevée

SRV-DB-PROD-01 | Base données | PROD | 4 vCPU | 32 Go | 1 To | Linux | élevée

SRV-BKP-PROD-01 | Sauvegarde | PROD | 2 vCPU | 8 Go | 4 To | Linux | élevée

SRV-APP-VAL-01 | Validation | VAL | 2 vCPU | 8 Go | 100 Go | Linux | moyenne

```

---

## 7. Postes clients, opérateurs et maintenance

### 7.1 Objet de la section postes clients

Cette partie décrit les postes à partir desquels les utilisateurs accèdent au système.

Il peut s’agir de postes opérateurs, postes administrateurs, PC de maintenance, tablettes industrielles, terminaux locaux ou postes de supervision.

### 7.2 Types de postes

**Exemples :**

```text id="5vrfsq"

- poste opérateur ;

- poste administrateur ;

- poste maintenance ;

- PC portable de diagnostic ;

- poste de supervision ;

- poste client en salle de contrôle ;

- terminal local industriel ;

- tablette de terrain.

```

### 7.3 Prérequis matériels

Cette partie indique les caractéristiques minimales nécessaires.

**Exemples :**

```text id="ut6gwq"

- CPU minimum ;

- mémoire RAM ;

- résolution écran ;

- carte réseau ;

- ports nécessaires ;

- autonomie batterie pour PC terrain ;

- niveau de robustesse si poste industriel ;

- compatibilité avec environnement terrain.

```

### 7.4 Prérequis logiciels

**Exemples :**

```text id="lnk0hp"

- système d’exploitation compatible ;

- navigateur web supporté ;

- certificat installé si nécessaire ;

- client VPN ;

- outil de diagnostic ;

- outil de capture logs ;

- outil de transfert de fichiers ;

- lecteur PDF pour documentation.

```

### 7.5 Accès utilisateur

Cette partie décrit comment les utilisateurs accèdent à l’application.

**Exemple :**

```text id="inyy1q"

Les opérateurs accèdent à l’interface via un navigateur web en HTTPS. L’accès nécessite un compte utilisateur nominatif. Les droits disponibles dépendent du profil associé : opérateur, maintenance, administrateur ou lecture seule.

```

### 7.6 Postes de maintenance

Cette partie décrit les postes utilisés pour les interventions techniques.

**Exemples de fonctions nécessaires :**

```text id="ac7uix"

- connexion locale à l’équipement ;

- consultation des logs embarqués ;

- chargement d’une configuration ;

- diagnostic réseau ;

- test des interfaces ;

- mise à jour firmware si autorisée ;

- export d’un rapport de maintenance.

```

### 7.7 Contraintes de sécurité sur les postes

**Exemples :**

```text id="f388ys"

- verrouillage de session ;

- antivirus ou EDR si applicable ;

- interdiction de stockage local de mots de passe ;

- accès VPN nominatif ;

- droits administrateur limités ;

- chiffrement disque si données sensibles ;

- mises à jour système ;

- journalisation des accès si applicable.

```

---

## 8. Réseau et connectivité

### 8.1 Objet de la section réseau

Cette partie décrit l’organisation réseau nécessaire au fonctionnement du système.

Elle doit identifier les flux entre équipements embarqués, serveurs, bases de données, postes opérateurs, sauvegardes, supervision, systèmes tiers et accès administrateur.

### 8.2 Architecture réseau générale

Cette partie doit contenir un schéma ou une description textuelle du réseau.

**Exemple :**

```text id="5txoas"

Réseau terrain

   |

   | équipement embarqué

   v

Réseau site / VLAN industriel

   |

   | pare-feu interne

   v

Réseau applicatif

   |

   +--> serveur applicatif

   |

   +--> serveur base de données

   |

   +--> serveur supervision

   |

   +--> serveur sauvegarde

```

### 8.3 Segmentation réseau

Cette partie décrit les zones réseau.

**Exemples :**

```text id="f7ms82"

- réseau terrain ;

- réseau équipements ;

- réseau applicatif ;

- réseau base de données ;

- réseau administration ;

- réseau sauvegarde ;

- réseau supervision ;

- DMZ ;

- zone SAS ;

- réseau invité ou externe non autorisé.

```

**Exemple explicatif :**

> La base de données ne doit pas être accessible directement depuis le réseau opérateur. Les postes utilisateurs accèdent uniquement au serveur applicatif, qui est le seul composant autorisé à interroger la base.

### 8.4 Plan d’adressage

Cette partie décrit les adresses IP ou les règles d’adressage.

**Exemple :**

```text id="js8vf0"

Élément | Adresse IP | Nom DNS | VLAN | Commentaire

Équipement 001 | 192.168.10.21 | eqp-001.local | VLAN 10 | équipement terrain

Serveur applicatif | 192.168.20.10 | app-prod.local | VLAN 20 | application

Serveur DB | 192.168.30.10 | db-prod.local | VLAN 30 | base données

Serveur sauvegarde | 192.168.40.10 | bkp-prod.local | VLAN 40 | sauvegarde

Poste opérateur | DHCP | - | VLAN 50 | accès IHM

```

### 8.5 Flux réseau autorisés

Cette partie liste tous les flux nécessaires.

**Modèle de tableau :**

```text id="2t701i"

ID flux :

Source :

Destination :

Protocole :

Port :

Sens :

Usage :

Criticité :

Chiffrement :

Authentification :

Journalisation :

```

**Exemple :**

```text id="hvgvrp"

F-NET-001

Source : équipement embarqué

Destination : serveur applicatif

Protocole : HTTPS ou MQTT/TLS

Port : 443 ou 8883

Sens : équipement vers serveur

Usage : transmission des mesures et alarmes

Criticité : élevée

Chiffrement : oui

Authentification : certificat ou jeton

Journalisation : côté serveur et équipement

```

### 8.6 Flux interdits ou bloqués

Cette partie précise les flux explicitement interdits.

**Exemples :**

```text id="axcx27"

- accès direct poste opérateur vers base de données ;

- accès Internet direct depuis serveur base de données ;

- accès administrateur non VPN ;

- accès SSH depuis un poste non autorisé ;

- flux équipement vers réseau non identifié ;

- transfert de fichier non contrôlé vers production.

```

### 8.7 Accès distant

Cette partie décrit les conditions d’accès distant.

**Exemples :**

```text id="qqudqa"

- VPN obligatoire ;

- accès nominatif ;

- authentification forte si applicable ;

- plage horaire autorisée ;

- journalisation des connexions ;

- autorisation préalable ;

- interdiction des comptes partagés ;

- limitation aux serveurs nécessaires.

```

### 8.8 Perte réseau et fonctionnement dégradé

Cette partie décrit le comportement réseau en cas de perte de communication.

**Exemple :**

```text id="n2l7u4"

En cas de perte de communication entre l’équipement et le serveur :

- l’équipement détecte l’absence d’acquittement ;

- les données sont conservées localement ;

- une alarme de communication est générée ;

- le serveur marque l’équipement comme non joignable ;

- la resynchronisation est déclenchée au retour réseau.

```

### 8.9 Supervision réseau

Cette partie décrit les éléments réseau à superviser.

**Exemples :**

```text id="xtdo43"

- disponibilité des serveurs ;

- disponibilité des équipements ;

- latence ;

- perte de paquets ;

- état VPN ;

- état des interfaces réseau ;

- saturation bande passante ;

- expiration certificats ;

- échecs de connexion.

```

---

## 9. Services logiciels et composants techniques

### 9.1 Objet de la section services

Cette partie décrit les services techniques nécessaires au fonctionnement de l’application.

Elle ne décrit pas le code métier, mais les services installés et exécutés sur les serveurs.

### 9.2 Liste des services

**Exemples :**

```text id="5zezpn"

- service applicatif principal ;

- serveur web / reverse proxy ;

- service API ;

- service de réception des messages ;

- broker de messages si applicable ;

- moteur de base de données ;

- service de sauvegarde ;

- service de supervision ;

- service de logs ;

- service d’authentification ;

- service de planification de tâches ;

- service de notification.

```

### 9.3 Fiche descriptive d’un service

**Modèle :**

```text id="wo4lbi"

Nom du service :

Serveur hébergeant le service :

Rôle :

Port d’écoute :

Dépendances :

Compte d’exécution :

Répertoire d’installation :

Répertoire de configuration :

Répertoire de logs :

Mode de démarrage :

Supervision :

Procédure de redémarrage :

Criticité :

```

### 9.4 Services critiques

Cette partie identifie les services dont l’arrêt impacte le fonctionnement.

**Exemples :**

```text id="6cc24n"

- application principale ;

- API de réception des équipements ;

- base de données ;

- service d’authentification ;

- service de communication ;

- service de sauvegarde ;

- service de supervision.

```

### 9.5 Dépendances entre services

Cette partie décrit l’ordre de démarrage et les dépendances.

**Exemple :**

```text id="mc2c4u"

Le service applicatif dépend de la disponibilité de la base de données.

L’IHM dépend de la disponibilité du serveur applicatif.

Le service de sauvegarde dépend de la disponibilité de la base de données et de l’espace de stockage sauvegarde.

Le service de supervision doit être capable de détecter l’arrêt des autres services.

```

### 9.6 Démarrage automatique

Cette partie décrit les services qui doivent démarrer automatiquement après redémarrage serveur.

**Exemples :**

```text id="dq69le"

- serveur web ;

- service applicatif ;

- moteur de base de données ;

- agent de supervision ;

- service de logs ;

- tâche de sauvegarde planifiée.

```

### 9.7 Procédures de redémarrage

Cette partie décrit ou référence les procédures de redémarrage contrôlé.

**Exemple :**

```text id="cdyhks"

Ordre recommandé :

1. Vérifier l’absence d’opération critique.

2. Prévenir les utilisateurs si nécessaire.

3. Arrêter le service applicatif.

4. Vérifier l’état de la base de données.

5. Redémarrer le service applicatif.

6. Vérifier les logs.

7. Vérifier l’accès IHM.

8. Vérifier la réception des données équipement.

```

---

## 10. Stockage, données et volumes

### 10.1 Objet de la section stockage

Cette partie décrit les besoins de stockage des données, logs, configurations, sauvegardes et fichiers d’échange.

Le stockage doit être dimensionné en fonction des volumes prévus, de la durée de conservation, du nombre d’équipements, des fréquences de mesure et des exigences d’archivage.

### 10.2 Types de données stockées

**Exemples :**

```text id="ge8b6o"

- mesures ;

- alarmes ;

- événements ;

- logs applicatifs ;

- logs système ;

- configurations ;

- utilisateurs et droits ;

- fichiers de sauvegarde ;

- rapports ;

- exports ;

- fichiers de diagnostic ;

- paquets de mise à jour.

```

### 10.3 Localisation des données

Cette partie précise où chaque type de donnée est stocké.

**Exemple :**

```text id="0jfj02"

Type donnée | Emplacement | Durée conservation | Sauvegarde | Commentaire

Mesures | base de données | 12 mois | oui | purge ou archivage ensuite

Alarmes | base de données | 24 mois | oui | données critiques

Logs applicatifs | serveur applicatif | 90 jours | selon criticité | rotation activée

Configurations | serveur + sauvegarde | durée vie système | oui | versionnées

Exports | répertoire exports | 30 jours | non ou optionnel | suppression automatique

Sauvegardes | serveur sauvegarde | selon politique | oui si sauvegarde secondaire | accès restreint

```

### 10.4 Estimation des volumes

Cette partie explique comment les volumes sont estimés.

**Exemple :**

```text id="juw0sa"

Hypothèses :

- 100 équipements ;

- 1 message par équipement toutes les 60 secondes ;

- 2 Ko par message ;

- conservation brute 12 mois.

Volume journalier :

100 × 1440 × 2 Ko = 288 Mo/jour.

Volume annuel brut :

288 Mo × 365 = environ 105 Go/an.

Marge recommandée :

prévoir index, logs, alarmes, métadonnées et croissance, par exemple × 2 à × 4 selon l’application.

```

### 10.5 Seuils d’alerte stockage

Cette partie définit les seuils de surveillance.

**Exemple :**

```text id="7gk2ns"

Alerte information : espace disque utilisé > 70 %

Alerte majeure : espace disque utilisé > 85 %

Alerte critique : espace disque utilisé > 95 %

Action critique : blocage des écritures non essentielles ou intervention immédiate

```

### 10.6 Rotation des logs

Cette partie décrit la gestion des journaux.

**Exemples :**

```text id="wlyqik"

- rotation quotidienne ;

- compression des anciens logs ;

- suppression après durée définie ;

- conservation plus longue des logs critiques ;

- séparation logs applicatifs / logs système / logs sécurité ;

- interdiction de suppression manuelle non tracée.

```

### 10.7 Archivage

Cette partie décrit la stratégie d’archivage.

**Exemples :**

```text id="g2sixg"

- archivage mensuel des données anciennes ;

- conservation sur stockage moins coûteux ;

- possibilité de restauration pour consultation ;

- traçabilité des archives ;

- contrôle d’intégrité ;

- purge après durée réglementaire ou contractuelle.

```

---

## 11. Sauvegarde

### 11.1 Objet de la sauvegarde

Cette partie décrit l’objectif des sauvegardes.

La sauvegarde doit permettre de récupérer les données et configurations nécessaires après incident, erreur humaine, panne matérielle, corruption de données, échec de mise à jour ou sinistre partiel.

**Exemple :**

> La stratégie de sauvegarde vise à garantir la récupération des données critiques, des configurations et des éléments nécessaires à la remise en service du système dans un délai compatible avec les exigences d’exploitation.

### 11.2 Éléments à sauvegarder

Cette partie liste précisément ce qui doit être sauvegardé.

**Exemples :**

```text id="t1d2qy"

- base de données ;

- fichiers de configuration ;

- certificats et clés selon politique de sécurité ;

- fichiers applicatifs versionnés si non reconstructibles ;

- scripts de déploiement ;

- logs critiques ;

- rapports importants ;

- fichiers d’import/export ;

- documentation d’exploitation ;

- paramètres serveur ;

- configuration reverse proxy ;

- configuration sauvegarde elle-même.

```

### 11.3 Éléments non sauvegardés

Cette partie précise ce qui n’est pas sauvegardé et pourquoi.

**Exemples :**

```text id="x40bvn"

- fichiers temporaires ;

- caches applicatifs ;

- exports régénérables ;

- logs de debug à faible valeur ;