Canevas 6 — Dossier infrastructure informatique réseau sauvegarde » History » Revision 4
Revision 3 (Redmine Admin, 06/19/2026 03:11 AM) → Revision 4/6 (Redmine Admin, 06/19/2026 03:13 AM)
# 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 ;
- images système reconstructibles ;
- dépendances téléchargeables ;
- données anonymisées de test.
```
### 11.4 Fréquence des sauvegardes
Cette partie décrit la fréquence de sauvegarde.
**Exemple :**
```text id="q8bxqy"
Base de données :
- sauvegarde complète quotidienne ;
- sauvegarde incrémentale ou journalisation transactionnelle si nécessaire.
Configurations :
- sauvegarde après chaque modification ;
- sauvegarde quotidienne par sécurité.
Logs critiques :
- export quotidien ;
- conservation selon politique.
Fichiers applicatifs :
- sauvegarde à chaque livraison ou déploiement.
```
### 11.5 Types de sauvegarde
Cette partie décrit les types utilisés.
**Exemples :**
```text id="a59atm"
Sauvegarde complète :
copie complète des données à un instant donné.
Sauvegarde incrémentale :
copie uniquement les données modifiées depuis la dernière sauvegarde.
Sauvegarde différentielle :
copie les données modifiées depuis la dernière sauvegarde complète.
Snapshot :
image d’un volume ou d’une machine à un instant donné.
Export applicatif :
sauvegarde produite par l’application elle-même dans un format contrôlé.
```
### 11.6 Rétention des sauvegardes
Cette partie définit combien de temps les sauvegardes sont conservées.
**Exemple :**
```text id="34wd07"
Sauvegardes quotidiennes : conservées 14 jours
Sauvegardes hebdomadaires : conservées 8 semaines
Sauvegardes mensuelles : conservées 12 mois
Sauvegardes avant mise à jour : conservées jusqu’à validation de la version déployée
```
### 11.7 Stockage des sauvegardes
Cette partie précise où sont stockées les sauvegardes.
**Exemples :**
```text id="xgl9g1"
- serveur de sauvegarde local ;
- stockage réseau ;
- stockage externe ;
- support hors ligne ;
- stockage distant ;
- coffre-fort numérique ;
- stockage immuable si nécessaire.
```
### 11.8 Sécurité des sauvegardes
Cette partie décrit les mesures de protection.
**Exemples :**
```text id="h0plpo"
- accès restreint ;
- chiffrement si données sensibles ;
- séparation des droits entre production et sauvegarde ;
- journalisation des accès ;
- protection contre suppression accidentelle ;
- contrôle d’intégrité ;
- conservation hors serveur applicatif ;
- test de lisibilité.
```
### 11.9 Supervision des sauvegardes
Cette partie décrit comment vérifier que les sauvegardes sont bien réalisées.
**Exemples :**
```text id="92vfi4"
- alerte en cas d’échec ;
- vérification de présence du fichier ;
- vérification de taille minimale ;
- vérification de code retour ;
- journalisation ;
- tableau de bord sauvegarde ;
- revue périodique des sauvegardes ;
- test automatique ou manuel de restauration.
```
### 11.10 Tableau de synthèse des sauvegardes
**Exemple :**
```text id="zizs8i"
Élément | Type sauvegarde | Fréquence | Rétention | Emplacement | Test restauration
Base données | complète + incrémentale | quotidien | 14j/8sem/12mois | SRV-BKP | mensuel
Configuration | fichier versionné | après changement | durée projet | SRV-BKP | trimestriel
Logs critiques | export compressé | quotidien | 90 jours | SRV-BKP | sur demande
Scripts déploiement | dépôt versionné | à chaque version | durée projet | dépôt + backup | à chaque release
```
---
## 12. Restauration et reprise
### 12.1 Objet de la restauration
Cette partie décrit l’objectif des procédures de restauration.
Une sauvegarde n’a de valeur que si la restauration a été testée et documentée. Le dossier doit préciser comment restaurer les données, la configuration, les services, voire l’ensemble de l’environnement.
**Exemple :**
> Les procédures de restauration permettent de remettre le système dans un état exploitable après perte de données, corruption, erreur humaine, échec de mise à jour, panne serveur ou incident d’infrastructure.
### 12.2 Scénarios de restauration
Cette partie liste les scénarios de restauration prévus.
**Exemples :**
```text id="gr92k0"
- restauration d’une base de données ;
- restauration d’une configuration ;
- restauration après échec de mise à jour ;
- restauration d’un serveur applicatif ;
- restauration d’un serveur base de données ;
- restauration après suppression accidentelle ;
- restauration sur environnement de test ;
- restauration complète après sinistre.
```
### 12.3 Restauration de base de données
**Exemple de procédure :**
```text id="xfr5e9"
1. Identifier la sauvegarde à restaurer.
2. Vérifier son intégrité.
3. Arrêter les services applicatifs si nécessaire.
4. Sauvegarder l’état courant avant restauration si possible.
5. Restaurer la base de données.
6. Vérifier les logs de restauration.
7. Redémarrer les services applicatifs.
8. Vérifier l’accès application.
9. Vérifier la cohérence des données restaurées.
10. Documenter l’opération.
```
### 12.4 Restauration de configuration
**Exemples de configurations concernées :**
```text id="1rvspp"
- configuration application ;
- configuration équipement ;
- configuration serveur web ;
- configuration base de données ;
- configuration sauvegarde ;
- configuration supervision ;
- configuration réseau ;
- certificats si applicable.
```
### 12.5 Restauration après mise à jour échouée
Cette partie décrit le retour arrière.
**Exemple :**
```text id="tidlvp"
Si une mise à jour applicative échoue :
1. interrompre le déploiement ;
2. conserver les logs d’échec ;
3. restaurer la version applicative précédente ;
4. restaurer la configuration précédente si elle a été modifiée ;
5. vérifier la compatibilité avec la base de données ;
6. redémarrer les services ;
7. exécuter les tests de bon fonctionnement ;
8. déclarer l’incident et les actions réalisées.
```
### 12.6 Objectifs de reprise
Cette partie définit les objectifs de reprise.
**Exemples :**
```text id="d2z6a2"
RTO :
durée maximale acceptable d’indisponibilité du service.
RPO :
quantité maximale de données pouvant être perdue, exprimée en durée.
Exemple :
RTO = 4 heures.
RPO = 24 heures.
```
### 12.7 Tests de restauration
Cette partie précise les tests à réaliser.
**Exemples :**
```text id="v9lysi"
- restauration complète sur environnement de test ;
- restauration partielle de configuration ;
- restauration d’une base à une date donnée ;
- vérification de l’intégrité ;
- comparaison avant/après ;
- test de démarrage applicatif après restauration ;
- test d’accès utilisateur ;
- test de reprise des flux équipements.
```
### 12.8 Critères de succès d’une restauration
**Exemple :**
```text id="a419sw"
Une restauration est considérée comme réussie si :
- la sauvegarde est lisible ;
- les données attendues sont présentes ;
- l’application redémarre ;
- les utilisateurs autorisés peuvent se connecter ;
- les équipements peuvent transmettre les données ;
- les journaux ne signalent pas d’erreur critique ;
- la procédure a été suivie et documentée.
```
---
## 13. Supervision et alerting
### 13.1 Objet de la supervision
Cette partie décrit l’objectif de la supervision.
La supervision permet de détecter les incidents avant qu’ils n’impactent gravement l’exploitation : serveur indisponible, service arrêté, disque plein, sauvegarde échouée, base de données inaccessible, certificat expirant, flux interrompu, erreur applicative répétée.
### 13.2 Éléments supervisés
**Exemples :**
```text id="2x4voz"
- disponibilité serveur ;
- charge CPU ;
- mémoire ;
- espace disque ;
- services applicatifs ;
- base de données ;
- files d’attente ;
- flux équipement / serveur ;
- sauvegardes ;
- certificats ;
- logs d’erreur ;
- réseau ;
- VPN ;
- synchronisation horaire ;
- nombre d’équipements non joignables.
```
### 13.3 Seuils de supervision
**Exemples :**
```text id="f70wbu"
CPU > 80 % pendant 15 minutes : alerte majeure
RAM > 85 % : alerte majeure
Disque > 85 % : alerte majeure
Disque > 95 % : alerte critique
Service applicatif arrêté : alerte critique
Sauvegarde échouée : alerte majeure ou critique selon contexte
Certificat expirant dans moins de 30 jours : alerte majeure
Équipement non joignable > 10 minutes : alerte exploitation
```
### 13.4 Destinataires des alertes
Cette partie précise qui reçoit les alertes.
**Exemples :**
```text id="ia2k1q"
- administrateur système ;
- équipe exploitation ;
- responsable maintenance ;
- support fournisseur ;
- responsable client ;
- astreinte si applicable.
```
### 13.5 Canaux d’alerte
**Exemples :**
```text id="xzfpqf"
- email ;
- SMS ;
- tableau de bord ;
- outil ITSM ;
- webhook ;
- supervision centralisée ;
- notification applicative ;
- appel astreinte si critique.
```
### 13.6 Journalisation des alertes
Cette partie décrit la traçabilité des alertes.
**Exemples :**
```text id="yytl6b"
- date de déclenchement ;
- source ;
- niveau de criticité ;
- message ;
- destinataire ;
- acquittement ;
- action réalisée ;
- date de retour à la normale ;
- commentaire d’exploitation.
```
### 13.7 Tests de supervision
Cette partie précise comment vérifier que la supervision fonctionne.
**Exemples :**
```text id="m5b4cs"
- arrêter volontairement un service en environnement de test ;
- saturer un disque de test ;
- simuler un échec de sauvegarde ;
- simuler l’expiration d’un certificat ;
- couper la communication avec un équipement ;
- vérifier la réception de l’alerte ;
- vérifier la clôture de l’alerte après retour nominal.
```
---
## 14. Journalisation et traces
### 14.1 Objet de la journalisation
Cette partie décrit les objectifs de journalisation.
Les logs servent à l’exploitation, au diagnostic, à l’audit, à la sécurité, à la maintenance et à l’analyse des incidents. Ils doivent être suffisants pour comprendre ce qui s’est passé, sans devenir inutilisables par excès de volume ou par manque de structure.
### 14.2 Types de logs
**Exemples :**
```text id="22xjnk"
- logs applicatifs ;
- logs système ;
- logs base de données ;
- logs de sécurité ;
- logs d’authentification ;
- logs d’administration ;
- logs de sauvegarde ;
- logs réseau ;
- logs équipement ;
- logs de mise à jour ;
- logs de restauration.
```
### 14.3 Contenu minimal d’un log
**Exemple :**
```text id="pt5k23"
- date et heure ;
- source ;
- niveau ;
- identifiant événement ;
- message ;
- utilisateur si applicable ;
- équipement concerné si applicable ;
- adresse IP si pertinent ;
- action réalisée ;
- résultat ;
- code erreur si applicable.
```
### 14.4 Niveaux de logs
**Exemples :**
```text id="l3kq40"
DEBUG :
information détaillée utile au développement ou diagnostic approfondi.
INFO :
événement normal significatif.
WARNING :
événement anormal non bloquant.
ERROR :
erreur affectant une fonction.
CRITICAL :
erreur grave ou situation nécessitant intervention rapide.
```
### 14.5 Conservation des logs
Cette partie définit les durées de conservation.
**Exemple :**
```text id="bet5ln"
Logs applicatifs : 90 jours
Logs sécurité : 12 mois
Logs sauvegarde : 12 mois
Logs debug : 15 jours
Logs critiques incident : conservation jusqu’à clôture incident
```
### 14.6 Accès aux logs
Cette partie précise qui peut consulter ou exporter les logs.
**Exemples :**
```text id="g09v26"
- opérateur : logs fonctionnels limités ;
- maintenance : logs diagnostic ;
- administrateur : logs système et applicatifs ;
- sécurité : logs authentification et actions sensibles ;
- fournisseur : accès temporaire sous autorisation client.
```
### 14.7 Protection des logs
**Exemples :**
```text id="kkyu3x"
- accès restreint ;
- protection contre modification ;
- horodatage fiable ;
- rotation maîtrisée ;
- sauvegarde des logs critiques ;
- anonymisation si données personnelles ;
- interdiction d’inscrire des secrets en clair ;
- journalisation des accès aux logs sensibles.
```
---
## 15. Sécurité et cybersécurité infrastructure
### 15.1 Objet de la section sécurité
Cette partie décrit les mesures de sécurité appliquées à l’infrastructure.
Elle couvre les accès, comptes, droits, réseau, chiffrement, certificats, mises à jour, durcissement, journalisation, sauvegardes et protection des données.
### 15.2 Gestion des comptes
**Exemples :**
```text id="atz5mb"
- comptes nominatifs ;
- interdiction des comptes partagés sauf justification ;
- séparation comptes opérateur / administrateur ;
- désactivation des comptes inutilisés ;
- suppression ou blocage des comptes au départ d’un utilisateur ;
- revue périodique des comptes ;
- mots de passe conformes à la politique client.
```
### 15.3 Gestion des droits
**Exemples :**
```text id="wikz50"
- principe du moindre privilège ;
- droits administrateur limités ;
- accès base de données réservé ;
- accès sauvegarde restreint ;
- accès logs sécurité restreint ;
- séparation des rôles exploitation / administration / support ;
- traçabilité des actions sensibles.
```
### 15.4 Authentification
**Exemples :**
```text id="dmjhd5"
- authentification locale ;
- authentification via annuaire client ;
- double authentification si exigée ;
- certificats ;
- clés SSH ;
- jetons applicatifs ;
- expiration de session ;
- verrouillage après tentatives échouées.
```
### 15.5 Chiffrement
Cette partie décrit ce qui doit être chiffré.
**Exemples :**
```text id="k9t9po"
- flux web en HTTPS ;
- flux équipement / serveur si sensible ;
- sauvegardes si données sensibles ;
- secrets techniques ;
- mots de passe ;
- clés privées ;
- export de données sensibles.
```
### 15.6 Certificats et secrets
**Exemples :**
```text id="vwr78u"
- certificat serveur HTTPS ;
- certificat client équipement ;
- clés API ;
- mots de passe base de données ;
- secrets de sauvegarde ;
- clés SSH ;
- certificats VPN.
```
**Informations à décrire :**
```text id="kip63l"
- emplacement ;
- responsable ;
- durée de validité ;
- procédure de renouvellement ;
- procédure de révocation ;
- accès autorisés ;
- sauvegarde éventuelle ;
- alerte avant expiration.
```
### 15.7 Durcissement des serveurs
**Exemples :**
```text id="2s8jo9"
- suppression des services inutiles ;
- fermeture des ports non utilisés ;
- mise à jour de sécurité ;
- désactivation des comptes par défaut ;
- configuration SSH sécurisée ;
- pare-feu local ;
- droits fichiers restreints ;
- logs de connexion ;
- bannissement ou temporisation après échecs si applicable.
```
### 15.8 Mises à jour de sécurité
Cette partie décrit la politique de patching.
**Exemples :**
```text id="0l82j0"
- mises à jour critiques appliquées sous délai défini ;
- test préalable en environnement de validation ;
- fenêtre de maintenance ;
- sauvegarde avant mise à jour ;
- plan de retour arrière ;
- journalisation de la mise à jour ;
- vérification post-mise à jour.
```
### 15.9 Tests de sécurité infrastructure
**Exemples :**
```text id="90vox2"
- vérification des ports ouverts ;
- test des droits utilisateurs ;
- test d’accès non autorisé ;
- test d’expiration de session ;
- test de restauration d’un certificat ;
- revue de configuration ;
- contrôle absence secrets en clair dans les fichiers accessibles ;
- vérification des règles pare-feu.
```
---
## 16. Déploiement et installation
### 16.1 Objet de la section déploiement
Cette partie décrit comment l’infrastructure et l’application sont installées ou mises à jour.
Elle ne remplace pas la procédure détaillée d’installation, mais elle en fixe les principes et les prérequis.
### 16.2 Prérequis d’installation
**Exemples :**
```text id="x3ft8q"
- serveurs disponibles ;
- OS installé ;
- accès administrateur ;
- réseau configuré ;
- DNS configuré ;
- certificats disponibles ;
- base de données créée ;
- comptes techniques créés ;
- espace disque suffisant ;
- sauvegarde initiale prévue ;
- accès au dépôt de livraison ;
- environnement validé.
```
### 16.3 Éléments à installer
**Exemples :**
```text id="q0xe2y"
- application serveur ;
- base de données ;
- scripts de migration ;
- reverse proxy ;
- certificats ;
- agent de supervision ;
- scripts de sauvegarde ;
- tâches planifiées ;
- fichiers de configuration ;
- service système ;
- interface web ;
- outils de diagnostic.
```
### 16.4 Procédure de déploiement type
**Exemple :**
```text id="icazd5"
1. Vérifier les prérequis.
2. Identifier la version à installer.
3. Sauvegarder l’état existant si mise à jour.
4. Déployer les fichiers applicatifs.
5. Appliquer les migrations base de données.
6. Installer ou mettre à jour les fichiers de configuration.
7. Installer les certificats si nécessaire.
8. Redémarrer les services.
9. Vérifier les logs.
10. Exécuter les tests de bon fonctionnement.
11. Documenter la version déployée.
```
### 16.5 Vérifications post-déploiement
**Exemples :**
```text id="h4cpfp"
- service applicatif démarré ;
- base de données accessible ;
- interface web accessible ;
- utilisateur test connecté ;
- équipement test connecté ;
- sauvegarde déclenchable ;
- logs sans erreur critique ;
- supervision active ;
- version affichée correcte.
```
### 16.6 Retour arrière
Cette partie décrit le principe de rollback.
**Exemples :**
```text id="8gfdlg"
- restauration de la version applicative précédente ;
- restauration de la base avant migration ;
- restauration de la configuration précédente ;
- redémarrage des services ;
- validation des fonctions critiques ;
- journalisation de l’incident ;
- information des utilisateurs.
```
### 16.7 Livraison et dossier de configuration livrée
Cette partie précise les informations à conserver après installation.
**Exemples :**
```text id="qipm4p"
- version application ;
- version base de données ;
- version OS ;
- configuration déployée ;
- certificats installés ;
- date de déploiement ;
- responsable du déploiement ;
- anomalies rencontrées ;
- tests post-déploiement exécutés ;
- résultat du déploiement.
```
---
## 17. Exploitation courante
### 17.1 Objet de l’exploitation
Cette partie décrit les opérations régulières nécessaires au maintien en condition opérationnelle.
### 17.2 Tâches quotidiennes
**Exemples :**
```text id="l0ybf0"
- vérifier l’état des services ;
- vérifier les alertes supervision ;
- vérifier les sauvegardes ;
- vérifier l’espace disque ;
- vérifier les équipements non joignables ;
- consulter les logs d’erreur ;
- traiter les incidents ouverts.
```
### 17.3 Tâches hebdomadaires
**Exemples :**
```text id="rwyv05"
- revue des sauvegardes ;
- revue des alertes récurrentes ;
- vérification des performances ;
- vérification des logs volumineux ;
- purge ou archivage si nécessaire ;
- revue des comptes temporaires.
```
### 17.4 Tâches mensuelles
**Exemples :**
```text id="swjcp9"
- test de restauration ;
- revue des comptes utilisateurs ;
- contrôle des certificats expirants ;
- revue de capacité disque ;
- revue des versions installées ;
- revue des incidents ;
- vérification des mises à jour disponibles.
```
### 17.5 Exploitation en période de maintenance
Cette partie décrit les règles applicables pendant une maintenance.
**Exemples :**
```text id="gyxmwv"
- informer les utilisateurs ;
- sauvegarder avant intervention ;
- bloquer ou limiter certains accès ;
- exécuter les opérations prévues ;
- vérifier le retour au nominal ;
- documenter l’intervention ;
- clôturer la fenêtre de maintenance.
```
### 17.6 Gestion des incidents infrastructure
Cette partie décrit les incidents typiques et le premier niveau de traitement.
**Exemples :**
```text id="6rhc12"
Incident : service applicatif arrêté
Actions :
- vérifier supervision ;
- consulter les logs ;
- redémarrer le service selon procédure ;
- vérifier l’accès utilisateur ;
- ouvrir une anomalie si récurrence.
Incident : sauvegarde échouée
Actions :
- vérifier espace disque ;
- consulter logs sauvegarde ;
- relancer si possible ;
- signaler si échec persistant ;
- vérifier la dernière sauvegarde valide.
```
---
## 18. Continuité, reprise et disponibilité
### 18.1 Objet de la continuité
Cette partie décrit les mesures prévues pour maintenir ou rétablir le service.
Selon la criticité du projet, il peut s’agir d’un simple plan de restauration ou d’un véritable plan de continuité / reprise d’activité.
### 18.2 Exigences de disponibilité
**Exemples :**
```text id="a4pzuc"
- disponibilité pendant les heures ouvrées ;
- fonctionnement 24 h / 24 ;
- arrêt planifié autorisé ;
- temps maximal d’indisponibilité ;
- nombre maximal d’interruptions ;
- délai de rétablissement attendu.
```
### 18.3 Scénarios d’incident
**Exemples :**
```text id="gu3ip2"
- panne serveur applicatif ;
- panne base de données ;
- perte réseau ;
- corruption base ;
- échec sauvegarde ;
- saturation disque ;
- certificat expiré ;
- erreur de mise à jour ;
- perte d’un équipement embarqué ;
- indisponibilité du poste opérateur.
```
### 18.4 Mesures de continuité
**Exemples :**
```text id="zj3nfq"
- sauvegarde régulière ;
- restauration testée ;
- monitoring ;
- documentation de redémarrage ;
- stockage local embarqué ;
- mode dégradé communication ;
- serveur de remplacement ;
- procédure manuelle temporaire ;
- support astreinte si prévu.
```
### 18.5 Plan de reprise minimal
**Exemple :**
```text id="7iyfrm"
1. Identifier l’incident.
2. Classer la criticité.
3. Informer les responsables.
4. Isoler le composant défaillant.
5. Restaurer ou redémarrer selon procédure.
6. Vérifier les fonctions critiques.
7. Reconnecter les équipements.
8. Vérifier les données manquantes.
9. Documenter l’incident.
10. Mettre en place une action corrective si nécessaire.
```
### 18.6 Validation de la reprise
**Exemples :**
```text id="20l657"
- accès IHM rétabli ;
- base de données cohérente ;
- équipements reconnectés ;
- données resynchronisées ;
- sauvegarde relancée ;
- supervision sans alerte critique ;
- utilisateurs informés du retour au service.
```
---
## 19. Tests infrastructure
### 19.1 Objet des tests infrastructure
Cette partie décrit les tests permettant de vérifier que l’infrastructure est correctement installée, configurée, sécurisée, sauvegardée, restaurable et exploitable.
### 19.2 Tests d’installation
**Exemples :**
```text id="h8zuyg"
- installation serveur applicatif ;
- installation base de données ;
- installation reverse proxy ;
- installation certificat ;
- installation supervision ;
- création comptes techniques ;
- déploiement configuration ;
- vérification démarrage automatique.
```
### 19.3 Tests réseau
**Exemples :**
```text id="tiw6tw"
- connectivité équipement vers serveur ;
- connectivité poste opérateur vers IHM ;
- absence d’accès direct poste vers base ;
- accès administrateur via VPN ;
- blocage des flux interdits ;
- test de perte réseau ;
- test de retour réseau ;
- mesure de latence si nécessaire.
```
### 19.4 Tests sauvegarde
**Exemples :**
```text id="86ll0r"
- déclenchement manuel d’une sauvegarde ;
- vérification sauvegarde planifiée ;
- vérification présence fichier ;
- vérification taille ;
- vérification logs ;
- simulation d’échec ;
- alerte en cas d’échec.
```
### 19.5 Tests restauration
**Exemples :**
```text id="7x8p3k"
- restauration base de données sur environnement de test ;
- restauration configuration ;
- restauration après mise à jour échouée ;
- vérification intégrité ;
- vérification accès application ;
- vérification données restaurées.
```
### 19.6 Tests supervision
**Exemples :**
```text id="5j2a8d"
- arrêt service applicatif ;
- saturation disque simulée ;
- échec sauvegarde simulé ;
- indisponibilité base de données ;
- certificat proche expiration ;
- perte communication équipement ;
- vérification réception alerte.
```
### 19.7 Tests sécurité infrastructure
**Exemples :**
```text id="slgzf4"
- accès utilisateur non autorisé ;
- accès admin sans VPN ;
- port interdit fermé ;
- compte désactivé refusé ;
- mot de passe incorrect ;
- vérification des droits fichiers ;
- vérification absence secrets en clair ;
- test expiration session.
```
### 19.8 Critères d’acceptation des tests infrastructure
**Exemple :**
```text id="00rf20"
Les tests infrastructure sont considérés comme réussis si :
- les services nécessaires sont installés et démarrés ;
- les flux autorisés fonctionnent ;
- les flux interdits sont bloqués ;
- les sauvegardes sont exécutées ;
- au moins une restauration est réussie ;
- les alertes de supervision sont reçues ;
- les accès utilisateurs respectent les droits ;
- aucune anomalie bloquante n’est ouverte.
```
---
## 20. Traçabilité
### 20.1 Traçabilité avec les exigences système
Cette partie relie les éléments d’infrastructure aux exigences de la spécification globale.
**Exemple :**
```text id="gjjc23"
SYS-INF-030 — Les données critiques doivent être sauvegardables.
Éléments infrastructure associés :
- serveur de sauvegarde ;
- script de sauvegarde ;
- tâche planifiée ;
- stockage dédié ;
- procédure de restauration ;
- test de restauration.
Tests associés :
- TEST-INF-SAV-001 : sauvegarde manuelle ;
- TEST-INF-SAV-002 : sauvegarde planifiée ;
- TEST-INF-REST-001 : restauration base de données.
```
### 20.2 Traçabilité avec l’architecture système
Cette partie relie les composants infrastructure aux blocs architecturaux.
**Exemple :**
```text id="c6ssmb"
Bloc architecture :
SS-INF-001 — Infrastructure informatique
Déclinaison infrastructure :
- SRV-APP-PROD-01 ;
- SRV-DB-PROD-01 ;
- SRV-BKP-PROD-01 ;
- NET-VLAN-APP ;
- procédure sauvegarde ;
- supervision applicative.
```
### 20.3 Traçabilité vers les tests
Cette partie relie chaque composant ou fonction infrastructure à un test.
**Exemple :**
```text id="n1v29j"
Élément | Test associé | Critère
Serveur applicatif | TEST-INF-APP-001 | service démarré et IHM accessible
Base de données | TEST-INF-DB-001 | connexion applicative OK
Sauvegarde | TEST-INF-SAV-001 | sauvegarde générée et vérifiée
Restauration | TEST-INF-REST-001 | restauration réussie sur VAL
Supervision | TEST-INF-MON-001 | alerte reçue après arrêt service
```
### 20.4 Matrice infrastructure / exigences / tests
**Structure recommandée :**
```text id="2xvakx"
ID exigence
Composant infrastructure
Configuration associée
Procédure associée
Test associé
Résultat
Commentaire
```
---
## 21. Contraintes, risques et points ouverts
### 21.1 Contraintes techniques
**Exemples :**
```text id="n0069v"
- serveur imposé par le client ;
- réseau client non modifiable ;
- absence d’accès Internet ;
- contraintes de port ouvert ;
- politique de sécurité stricte ;
- limitation espace disque ;
- sauvegarde centralisée imposée ;
- OS imposé ;
- accès distant interdit ou limité.
```
### 21.2 Contraintes organisationnelles
**Exemples :**
```text id="axjpr3"
- administration réalisée par le client ;
- installation réalisée par le fournisseur ;
- sauvegarde exploitée par une équipe tierce ;
- accès fournisseur uniquement sur autorisation ;
- fenêtre de maintenance limitée ;
- validation client obligatoire avant production.
```
### 21.3 Risques infrastructure
**Exemples :**
```text id="49pjn4"
- dimensionnement insuffisant ;
- sauvegarde non restaurable ;
- règle pare-feu bloquant un flux critique ;
- certificat expiré ;
- espace disque saturé ;
- service non supervisé ;
- dépendance à un serveur unique ;
- confusion entre test et production ;
- compte administrateur partagé ;
- procédure de restauration non testée.
```
### 21.4 Mesures de réduction des risques
**Exemples :**
```text id="js3cxn"
- test de charge ;
- test de restauration ;
- supervision des certificats ;
- alerte disque ;
- revue des règles pare-feu ;
- séparation claire des environnements ;
- documentation de déploiement ;
- comptes nominatifs ;
- sauvegarde avant mise à jour ;
- revue périodique des accès.
```
### 21.5 Points ouverts
**Exemple de tableau :**
```text id="dqd5f7"
ID | Sujet | Description | Responsable | Échéance | Impact | Statut
PO-INF-001 | Hébergement | Confirmer serveur client ou fournisseur | Client | Avant déploiement VAL | architecture | ouvert
PO-INF-002 | Politique sauvegarde | Confirmer durée de rétention | Client | Avant PROD | stockage | ouvert
PO-INF-003 | Accès VPN | Confirmer modalités d’accès fournisseur | Client IT | Avant recette | support | ouvert
PO-INF-004 | Certificats | Définir autorité de certification | Client IT | Avant installation | sécurité | ouvert
```
---
## 22. Critères d’acceptation du dossier infrastructure
### 22.1 Complétude
Cette partie définit les critères permettant de considérer le dossier comme complet.
**Exemples :**
```text id="yllwjn"
Le dossier infrastructure est considéré comme complet si :
- tous les environnements sont décrits ;
- tous les serveurs sont identifiés ;
- les flux réseau nécessaires sont listés ;
- les rôles et responsabilités sont clairs ;
- les sauvegardes sont définies ;
- les procédures de restauration sont définies ;
- les accès utilisateurs et administrateurs sont décrits ;
- les mesures de sécurité sont décrites ;
- la supervision est définie ;
- les tests infrastructure sont identifiés ;
- les points ouverts sont listés.
```
### 22.2 Cohérence
**Exemples :**
```text id="so2wm2"
Le dossier ne doit pas contenir :
- serveur sans rôle défini ;
- flux réseau non justifié ;
- sauvegarde sans restauration prévue ;
- environnement de validation trop différent de la production sans justification ;
- accès administrateur non maîtrisé ;
- données critiques sans sauvegarde ;
- service critique non supervisé ;
- composant en production sans procédure de redémarrage.
```
### 22.3 Testabilité
**Exemples :**
```text id="m8x667"
Le dossier est testable si :
- les flux peuvent être vérifiés ;
- les sauvegardes peuvent être déclenchées ;
- les restaurations peuvent être répétées ;
- les services peuvent être arrêtés/redémarrés en test ;
- les alertes de supervision peuvent être simulées ;
- les accès utilisateurs peuvent être vérifiés ;
- les environnements sont identifiables.
```
### 22.4 Exploitabilité
**Exemples :**
```text id="avyrf2"
Le dossier est exploitable si :
- un administrateur peut installer le système ;
- un exploitant peut vérifier l’état du système ;
- un incident courant peut être diagnostiqué ;
- une sauvegarde peut être contrôlée ;
- une restauration peut être exécutée ;
- une mise à jour peut être préparée ;
- les responsabilités sont claires.
```
### 22.5 Validation du document
Cette partie précise les revues nécessaires.
**Exemple :**
```text id="gc4he5"
Le dossier infrastructure doit être relu par :
- l’architecte système ;
- l’administrateur système ;
- le responsable réseau ;
- le responsable cybersécurité ;
- le responsable application serveur ;
- le responsable base de données ;
- le responsable sauvegarde ;
- le responsable exploitation ;
- le responsable validation ;
- le représentant client si l’infrastructure appartient au client.
```
---
## 23. Annexes
### 23.1 Schémas d’infrastructure
Cette annexe contient les schémas graphiques.
**Exemples :**
```text id="zz8n3q"
- schéma général infrastructure ;
- schéma réseau ;
- schéma des environnements ;
- schéma sauvegarde / restauration ;
- schéma des flux ;
- schéma d’accès administrateur ;
- schéma supervision.
```
### 23.2 Inventaire des serveurs
Cette annexe reprend la liste complète des serveurs.
**Exemple :**
```text id="v9r18f"
Nom | Rôle | Environnement | IP | OS | Responsable | Criticité
SRV-APP-PROD-01 | Application | PROD | 192.168.20.10 | Linux | Client IT | élevée
SRV-DB-PROD-01 | Base données | PROD | 192.168.30.10 | Linux | Client IT | élevée
SRV-BKP-PROD-01 | Sauvegarde | PROD | 192.168.40.10 | Linux | Client IT | élevée
```
### 23.3 Inventaire des flux réseau
Cette annexe reprend tous les flux autorisés.
### 23.4 Inventaire des comptes et rôles techniques
Cette annexe peut lister les comptes techniques, sans exposer les mots de passe.
**Exemple :**
```text id="22gyx4"
Compte | Usage | Serveur | Droits | Responsable | Rotation secret
svc-app | exécution application | SRV-APP | droits limités | Admin système | oui
svc-backup | sauvegarde | SRV-BKP | lecture DB / écriture backup | Admin système | oui
admin-db | administration DB | SRV-DB | admin DB | DBA | nominatif recommandé
```
### 23.5 Plan de sauvegarde détaillé
Cette annexe contient les règles de sauvegarde détaillées.
### 23.6 Plan de restauration détaillé
Cette annexe contient les procédures détaillées de restauration.
### 23.7 Liste des tests infrastructure
Cette annexe liste les tests infrastructure.
**Exemple :**
```text id="6fsykn"
TEST-INF-001 : installation serveur applicatif
TEST-INF-002 : accès IHM HTTPS
TEST-INF-003 : connexion application/base de données
TEST-INF-004 : sauvegarde manuelle
TEST-INF-005 : sauvegarde planifiée
TEST-INF-006 : restauration base sur VAL
TEST-INF-007 : arrêt service et alerte supervision
TEST-INF-008 : blocage flux interdit
TEST-INF-009 : accès VPN administrateur
```
### 23.8 Procédures d’exploitation
Cette annexe peut contenir ou référencer les procédures suivantes :
```text id="4x0rlz"
- démarrage système ;
- arrêt contrôlé ;
- redémarrage serveur ;
- sauvegarde manuelle ;
- restauration ;
- mise à jour ;
- consultation logs ;
- traitement alerte supervision ;
- ajout utilisateur ;
- retrait utilisateur ;
- vérification certificats.
```
### 23.9 Glossaire
Cette annexe définit les termes spécifiques à l’infrastructure.
### 23.10 Historique des décisions infrastructure
Cette annexe conserve les décisions structurantes.
**Exemple :**
```text id="ot25gt"
DEC-INF-001 :
Les environnements validation et production seront séparés physiquement ou logiquement.
Justification :
éviter qu’un test ou une anomalie de validation impacte la production.
Impact :
nécessite deux configurations serveur distinctes et une procédure de transfert contrôlé des versions.
```