CANEVAS DES DOCUMENTS DU PROJET

# Canevas 1 — Cahier des charges  Expression du besoin

## 1. Objet du document

### 1.1 Finalité du cahier des charges

Cette partie explique pourquoi le document existe.

Elle doit préciser que le cahier des charges exprime le besoin du client, sans nécessairement imposer la solution technique. Le fournisseur pourra ensuite traduire ce besoin en spécifications système, architecture et conception.

**Exemple :**

> Le présent document a pour objectif de décrire les besoins opérationnels, fonctionnels, techniques et contractuels auxquels devra répondre le système.

### 1.2 Positionnement dans le cycle en V

Cette partie situe le cahier des charges au sommet gauche du cycle en V.

Il constitue le document d’entrée principal du projet. Il sert de référence pour établir les spécifications système, les exigences de validation et les critères d’acceptation finale.

**Exemple :**

> Le cahier des charges constitue le document d’entrée principal de la phase de spécification. Il sert également de référence pour la validation finale du système.

### 1.3 Responsabilité de rédaction et de validation

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

En général, le cahier des charges est rédigé par le client, ou par la maîtrise d’ouvrage, avec l’appui éventuel des futurs utilisateurs, de l’exploitation, de la maintenance, de la sécurité et des responsables techniques.

**Exemple :**

```text

Rédaction : client / maître d’ouvrage

Contribution : utilisateurs, exploitation, maintenance, sécurité

Validation : client / responsable métier / direction projet

```

---

## 2. Contexte général du projet

### 2.1 Présentation du contexte

Cette partie décrit l’environnement dans lequel s’inscrit le projet : besoin industriel, opérationnel, réglementaire, commercial ou technique.

Elle doit répondre aux questions suivantes :

```text

Pourquoi lance-t-on ce projet ?

Quel problème cherche-t-on à résoudre ?

Quel système existant doit être remplacé, complété ou amélioré ?

```

### 2.2 Situation actuelle

Cette partie décrit l’existant : équipements actuels, logiciels utilisés, procédures manuelles, contraintes connues, limites du système en place.

Elle doit permettre de comprendre les raisons qui justifient le projet.

**Exemple :**

> L’installation actuelle repose sur une supervision locale sans remontée centralisée des alarmes. Les opérations de diagnostic nécessitent une intervention sur site.

### 2.3 Objectifs du projet

Cette partie énonce les objectifs principaux du système attendu.

Les objectifs doivent être formulés de manière claire, compréhensible et vérifiable.

**Exemples :**

```text

- automatiser la surveillance de l’équipement ;

- améliorer la détection des défauts ;

- réduire le temps d’intervention ;

- permettre une supervision distante ;

- sécuriser les données d’exploitation.

```

---

## 3. Périmètre du système attendu

### 3.1 Périmètre fonctionnel

Cette partie liste les grandes fonctions attendues du système.

Il ne s’agit pas encore de décrire en détail la conception, mais d’identifier ce que le système devra permettre de faire.

**Exemple :**

```text

Le système devra permettre :

- l’acquisition de mesures ;

- le pilotage d’actionneurs ;

- la détection d’anomalies ;

- l’enregistrement des événements ;

- la transmission des données vers un serveur ;

- la consultation des états par un opérateur.

```

### 3.2 Périmètre matériel

Cette partie précise les éléments matériels concernés : cartes électroniques, capteurs, actionneurs, alimentation, coffret, câblage, banc de test, PC opérateur, serveur, réseau.

**Exemple :**

> Le système comprendra un équipement embarqué installé sur site, un coffret d’alimentation, un module de communication, un serveur applicatif et un poste opérateur.

### 3.3 Périmètre logiciel

Cette partie décrit les logiciels attendus, sans entrer encore dans leur conception détaillée.

Elle peut inclure le logiciel embarqué, les applications serveur, les interfaces utilisateurs, les outils de configuration, les outils de diagnostic et les logiciels de supervision.

**Exemple :**

> Le projet comprend un logiciel embarqué, une application serveur, une interface web d’exploitation et des outils de configuration.

### 3.4 Hors périmètre

Cette partie est importante contractuellement.

Elle précise ce qui n’est pas inclus dans le projet afin d’éviter les ambiguïtés entre le client et le fournisseur.

**Exemples :**

```text

- fourniture du réseau Internet du site ;

- maintenance des équipements tiers ;

- hébergement hors infrastructure client ;

- développement d’une application mobile ;

- certification réglementaire non explicitement demandée.

```

---

## 4. Acteurs et utilisateurs

### 4.1 Acteurs principaux

Cette partie identifie les personnes, services ou systèmes qui interagissent avec l’équipement.

**Exemples :**

```text

- opérateur ;

- technicien de maintenance ;

- administrateur système ;

- responsable exploitation ;

- serveur central ;

- équipement tiers ;

- superviseur externe.

```

### 4.2 Profils utilisateurs

Cette partie décrit les droits, compétences et responsabilités de chaque profil utilisateur.

Elle permet de préparer les exigences relatives aux droits d’accès, à l’ergonomie, à la sécurité et à l’exploitation.

**Exemple :**

```text

L’opérateur consulte les états et acquitte les alarmes.

Le technicien réalise les opérations de diagnostic et de maintenance.

L’administrateur configure les comptes, les droits et les paramètres système.

```

### 4.3 Cas d’usage principaux

Cette partie liste les principales situations d’utilisation du système.

Les cas d’usage permettent de relier le besoin utilisateur aux futures spécifications fonctionnelles.

**Exemples :**

```text

- démarrer le système ;

- surveiller le fonctionnement nominal ;

- consulter une alarme ;

- diagnostiquer une panne ;

- passer en mode maintenance ;

- récupérer les journaux ;

- restaurer une configuration.

```

---

## 5. Fonctions attendues

### 5.1 Fonctions d’acquisition

Cette partie décrit les informations que le système doit acquérir : mesures, états, entrées numériques, données capteurs, données réseau, événements ou défauts.

**Exemple :**

> Le système doit acquérir la tension batterie, la température interne, l’état des contacteurs et les défauts remontés par les modules électroniques.

### 5.2 Fonctions de traitement

Cette partie décrit les traitements attendus : calculs, règles métier, filtrage, agrégation, surveillance de seuils, génération d’événements ou d’alarmes.

**Exemple :**

> Le système doit comparer les mesures acquises aux seuils configurés et générer une alarme lorsque les limites autorisées sont dépassées.

### 5.3 Fonctions de commande

Cette partie décrit les actions que le système doit être capable de déclencher.

Elle doit préciser les conditions de déclenchement, les interdictions éventuelles et les sécurités associées.

**Exemples :**

```text

- activation d’un relais ;

- arrêt d’un équipement ;

- redémarrage contrôlé ;

- bascule en mode secours ;

- verrouillage d’une fonction dangereuse.

```

### 5.4 Fonctions de communication

Cette partie décrit les échanges avec les autres systèmes : protocole attendu, périodicité, sens des flux, contraintes de disponibilité, comportement en cas de perte de communication.

**Exemples :**

```text

Le système doit transmettre les données d’état au serveur central toutes les 60 secondes.

En cas de perte réseau, les données doivent être conservées localement puis retransmises lors du retour de communication.

```

### 5.5 Fonctions de supervision

Cette partie décrit les besoins d’affichage, de consultation et d’exploitation.

Elle concerne généralement l’interface opérateur, l’interface administrateur ou les outils de supervision distante.

**Exemples :**

```text

- visualisation de l’état courant ;

- consultation des alarmes ;

- affichage des historiques ;

- export des données ;

- accès aux journaux techniques.

```

---

## 6. Modes de fonctionnement attendus

### 6.1 Mode arrêt

Cette partie décrit l’état du système lorsqu’il est hors fonctionnement, mais potentiellement alimenté.

Elle doit préciser :

```text

- les fonctions désactivées ;

- les sécurités maintenues ;

- les conditions de démarrage ;

- les informations conservées.

```

### 6.2 Mode démarrage

Cette partie décrit la séquence de démarrage attendue.

Elle doit préciser les contrôles réalisés, les conditions de passage au mode nominal et les anomalies empêchant le démarrage.

**Exemple :**

> Au démarrage, le système doit initialiser les entrées/sorties, vérifier la configuration, contrôler l’état des capteurs, établir la communication réseau et passer en mode nominal si aucune anomalie bloquante n’est détectée.

### 6.3 Mode nominal

Cette partie décrit le fonctionnement normal du système.

Elle doit préciser :

```text

- les fonctions actives ;

- les périodicités d’acquisition ;

- les échanges réseau ;

- les règles de surveillance ;

- les alarmes possibles ;

- les performances attendues.

```

### 6.4 Mode maintenance

Cette partie décrit les conditions dans lesquelles un technicien peut intervenir.

Elle doit préciser les fonctions accessibles, les sécurités maintenues, les éventuelles inhibitions d’alarmes et les conditions de retour au fonctionnement normal.

**Exemple :**

> En mode maintenance, certaines alarmes peuvent être inhibées temporairement, les commandes automatiques peuvent être désactivées et les fonctions de diagnostic peuvent être rendues accessibles.

### 6.5 Modes dégradés

Cette partie décrit les comportements attendus lorsque certaines fonctions ne sont plus disponibles.

Elle doit préciser, pour chaque mode dégradé, l’événement déclencheur, le comportement attendu, les fonctions maintenues, les fonctions suspendues, les alarmes générées et les conditions de retour au mode nominal.

**Exemples :**

```text

- perte de communication serveur ;

- capteur indisponible ;

- alimentation secondaire absente ;

- stockage local saturé ;

- perte de synchronisation horaire.

```

### 6.6 Retour au mode nominal

Cette partie décrit les conditions de retour à un fonctionnement normal après un mode dégradé, une opération de maintenance ou une perte de communication.

**Exemple :**

> Après rétablissement de la communication, le système doit transmettre les données stockées localement, fermer l’alarme de perte réseau et reprendre le cycle nominal.

---

## 7. Contraintes techniques

### 7.1 Contraintes matérielles

Cette partie précise les contraintes imposées au matériel.

**Exemples :**

```text

- alimentation disponible ;

- encombrement ;

- température ;

- humidité ;

- vibrations ;

- connectique ;

- protection IP ;

- contraintes CEM.

```

### 7.2 Contraintes logicielles

Cette partie précise les contraintes applicables au logiciel.

**Exemples :**

```text

- langage imposé ;

- système d’exploitation ;

- contraintes temps réel ;

- mémoire disponible ;

- politique de mise à jour ;

- journalisation ;

- cybersécurité.

```

### 7.3 Contraintes réseau

Cette partie décrit les conditions de communication attendues.

Elle doit préciser les réseaux disponibles, les protocoles envisagés, les restrictions de sécurité et le comportement attendu en cas de perte réseau.

**Exemples :**

```text

- réseau local Ethernet ;

- accès Internet ;

- VPN ;

- liaison 4G ;

- protocole MQTT, Modbus TCP, HTTPS ou autre ;

- fonctionnement en cas de perte réseau.

```

### 7.4 Contraintes serveur et infrastructure

Cette partie décrit les attentes concernant l’environnement informatique.

**Exemples :**

```text

- serveur de test ;

- serveur de production ;

- base de données ;

- sauvegarde ;

- supervision ;

- restauration ;

- stockage des journaux ;

- disponibilité attendue.

```

---

## 8. Contraintes de sécurité, sûreté et cybersécurité

### 8.1 Sécurité des personnes et des biens

Cette partie précise si le système peut présenter un risque physique pour les personnes, les équipements ou l’environnement.

**Exemples :**

```text

- risque électrique ;

- risque thermique ;

- risque mécanique ;

- risque lié aux batteries ;

- risque lié à une commande intempestive.

```

### 8.2 Sûreté de fonctionnement

Cette partie décrit les exigences de disponibilité, fiabilité, tolérance aux pannes et comportement sûr en cas de défaut.

**Exemple :**

> En cas d’erreur interne non récupérable, le système doit se placer dans un état sûr et générer une alarme.

### 8.3 Cybersécurité

Cette partie précise les exigences d’accès, d’authentification, de chiffrement, de journalisation, de mise à jour et de protection contre les accès non autorisés.

**Exemples :**

```text

- authentification obligatoire ;

- mots de passe robustes ;

- accès distant sécurisé ;

- chiffrement des communications ;

- journalisation des actions administrateur ;

- procédure de mise à jour contrôlée.

```

---

## 9. Exigences de testabilité et validation

### 9.1 Moyens de test attendus

Cette partie précise si le système doit être livré avec des outils ou équipements permettant de le tester.

**Exemples :**

```text

- banc de test ;

- simulateur de capteurs ;

- générateur de défauts ;

- interface de diagnostic ;

- outil de lecture des journaux ;

- jeux de données de test.

```

### 9.2 Exigences de test unitaire

Cette partie indique si certaines fonctions devront être testables séparément.

**Exemple :**

> Le logiciel embarqué devra permettre de tester séparément les fonctions d’acquisition, de communication, de stockage local et de gestion des alarmes.

### 9.3 Exigences de test d’intégration

Cette partie précise les conditions d’essais entre hardware, software, serveur et réseau.

**Exemple :**

> Les tests d’intégration devront vérifier les échanges entre l’équipement embarqué, le serveur applicatif et l’interface opérateur.

### 9.4 Critères de validation

Cette partie liste les critères permettant au client d’accepter la solution.

Ces critères doivent être vérifiables et reliés au dossier de validation ou au cahier de recette.

**Exemple :**

> La solution sera considérée comme acceptable si l’ensemble des fonctions critiques est validé, si aucune anomalie bloquante n’est ouverte et si les scénarios nominaux et dégradés définis dans le dossier de validation sont réussis.

---

## 10. Livrables attendus

### 10.1 Livrables matériels

Cette partie liste les éléments physiques à livrer.

**Exemples :**

```text

- équipement assemblé ;

- coffret ;

- câbles ;

- alimentation ;

- banc de test ;

- pièces de rechange.

```

### 10.2 Livrables logiciels

Cette partie liste les logiciels à livrer.

**Exemples :**

```text

- firmware ;

- application serveur ;

- interface web ;

- scripts d’installation ;

- outils de configuration ;

- images système.

```

### 10.3 Livrables documentaires

Cette partie liste les documents attendus.

**Exemples :**

```text

- spécification système ;

- architecture système ;

- dossier de conception ;

- plan de tests ;

- rapports de tests ;

- dossier de validation ;

- manuel utilisateur ;

- manuel maintenance ;

- dossier d’installation.

```

---

## 11. Contraintes de maintenance et exploitation

### 11.1 Maintenance préventive

Cette partie décrit les opérations régulières attendues.

**Exemples :**

```text

- vérification des connexions ;

- contrôle des journaux ;

- test de sauvegarde ;

- contrôle des batteries ;

- mise à jour logicielle.

```

### 11.2 Maintenance corrective

Cette partie précise les informations nécessaires au diagnostic et à la réparation.

**Exemples :**

```text

- codes défauts ;

- procédure de diagnostic ;

- accès aux logs ;

- remplacement de module ;

- redémarrage contrôlé.

```

### 11.3 Exploitation courante

Cette partie décrit les actions quotidiennes ou périodiques de l’exploitant.

**Exemples :**

```text

- consulter les états ;

- traiter les alarmes ;

- exporter les données ;

- vérifier les sauvegardes ;

- gérer les utilisateurs.

```

---

## 12. Annexes

### 12.1 Glossaire

Cette partie définit les termes techniques, métier et acronymes utilisés dans le document.

Elle permet d’éviter les ambiguïtés entre le client, le fournisseur, les utilisateurs, les exploitants et les équipes de maintenance.

### 12.2 Références

Cette partie liste les documents applicables ou utiles.

**Exemples :**

```text

- normes ;

- documents client ;

- plans d’installation ;

- procédures existantes ;

- documents d’exploitation ;

- documents réglementaires.

```

### 12.3 Schémas préliminaires

Cette partie peut contenir des schémas d’architecture, synoptiques, diagrammes de flux ou plans d’implantation.

Ces schémas n’ont pas vocation à figer la conception détaillée, mais à clarifier le besoin et les interfaces principales.