---
puppeteer:
  format: A4
---

# Application de surveillance de ressources - Cahier des charges

## Contexte et problématique

L'entreprise **PixelVault** est une jeune PME qui gère une solution cloud de partage de photos familiales ou entre amis. 

Elle met en avant le respect de la vie privée de ses utilisateurices, la sécurité et la fiabilité de sa solution. 

Actuellement, ses serveurs rencontrent des problèmes de saturation disque et de surcharge processeur ou réseau, perturbant la qualité de service.

La société décide donc de mettre en place un système de surveillance des ressources pour pouvoir anticiper ces problèmes
et les diagnostiquer plus rapidement.

Elle envisage la création d'une solution sur mesure qu'elle souhaite pouvoir déployer sur ses serveurs.

La société souhaite procéder par étapes, la première d'entre elles étant la réalisation d'un prototype
qui sera mis en oeuvre sur une petite partie de son infrastructure. C'est cette première 
étape qui est l'objet du présent cahier des charges.

## Objectifs

Les objectifs de cette première étape sont les suivants :
- Prouver la **faisabilité technique** d’un système interne de supervision
- Définir et valider les **besoins fonctionnels et techniques** des équipes d’exploitation
- Concevoir une **interface visuelle simple et claire** adaptée à un usage quotidien

## Périmètre

Le prototype sera testé sur une seule machine de développement interne.
Le système ne devra pas impacter les performances de cette machine.

## Description fonctionnelle

### Cas d'usage

L'objectif du projet est que les équipes d'exploitation soient en mesure de :
- **UC1** Visualiser l'état actuel des ressources du serveur
- **UC2** Visualiser l'historique d'utilisation des ressources du serveur

![usecase](images/uc.svg)


### Exigences

```mermaid
requirementDiagram
requirement SysMon_R1 {
  id: R1
  text: "Surveiller les ressources système principales"
}
requirement SysMon_R2 {
  id: R2
  text: "Afficher l’état en temps réel via un tableau de bord"
}
requirement SysMon_R3 {
  id: R3
  text: "Afficher l’historique via un 
  tableau de bord"
}
requirement SysMon_R4 {
  id: R4
  text: "Utiliser Python 3 (Flask) pour le 
  backend et HTML/CSS/JS pour le frontend"
}
requirement SysMon_R5 {
  id: R5
  text: "Les données d'utilisation devront être persistées"
}
requirement SysMon_R6 {
  id: R6
  text: "Les données d'utilisation devront 
  stockées dans le SGBD PostgresSQL"
}

SysMon_R1 - derives -> SysMon_R2
SysMon_R1 - derives -> SysMon_R3
SysMon_R3 - refines -> SysMon_R4
SysMon_R2 - refines -> SysMon_R4
SysMon_R3 - derives -> SysMon_R5
SysMon_R5 - refines -> SysMon_R6

```

- **R1** - Surveiller les ressources système principales
  - Utilisation CPU
  - Utilisation mémoire
  - Espace disque occupé
  - Taux d'usage du disque (entrées/sorties)
  - Entrées Sorties Réseau

- **R2** - Afficher l’état en temps réel via un tableau de bord

- **R3** - Afficher l’historique via un tableau de bord

- **R5** - Utiliser Python 3 (Flask) pour le backend et HTML/CSS/JS pour le frontend
  - Le système devra être multiplateforme. Par conséquent, le chef de projet impose Python 3 comme langage de programmation Back-end. En front, il faudra utiliser le tryptique HTML, CSS, JavaScript. Pour que l'ensemble fonctionnne, le framework Flask sera utilisé

- **R6** - Versionnement du projet
  - Le projet devra être versionné avec Git

## Architecture technique

![Architecture](images/Architecture.svg)

L'architecture du projet sera organisée comme dans le schéma ci-dessus.

Il y aura 4 conteneurs, dont un optionnel.
- PostgreSQL : pour la persistance des données
- Un service d'observation des données système qui écrira les données en base
- Un service d'interface utilisateur
- (optionnel) Un reverse proxy Traefik pour écouter sur le port 80 et rediriger les flux

### PostgreSQL

PostgreSQL devra avoir un volume persistant pour conserver les données sur le disque et éviter de les perdre à chaque redémarrage du conteneur

Il devra être relié à deux réseaux différents afin d'isoler les usages :
- Un pour le conteneur d'interface utilisateur
- Un pour le conteneur de surveillance système

La base de données devra également être accessible, outre le super utilisateur `postgres`, par deux utilisateurs : un pour chaque service, avec les droits minimaux nécessaires à leurs fonctionnalités.
- L'UI n'aura que le droit de lire les tables dont elle a besoin
- Le service de surveillance pourra lire et écrire uniquement dans les tables nécessaires

### Service d'observation

Le service de surveillance sera un programme développé en Python et utilisant la librairie `psutils` afin d'observer les données d'utilisation de la machine et les écrire en base de données.

Le conteneur sera en mesure d'accéder aux données de son hôte. Il est probable qu'à l'avenir, il ait accès à des données sensibles et qu'il ait des privilèges. Il faut donc l'isoler du réseau dès la conception pour limiter le risque d'accès mal intentionnés depuis l'extérieur. Le conteneur ne devra donc avoir aucun accès au réseau extérieur, pour des raisons de sécurité.

Il ne devra pas non plus pouvoir être directement joignable par un conteneur relié au réseau extérieur. C'est pourquoi il aura son propre réseau, distinct de celui de l'interface utilisateur.


### Le service d'interface utilisateur

Ce service sera un programme Python utilisant le framework Flask pour proposer une interface web servant de tableau de bord à l'utilisateur. Il proposera également les points d'entrée API nécessaires pour que l'interface puisse récupérer les données d'historique des données système depuis la base de données. 

Ce service sera soit relié au port 80 de la machine hôte (développement), soit préférablement (en production) relié à un reverse proxy (Traefik) qui gèrera les flux réseaux qui lui sont destinés afin de rajouter une couche supplémentaire de sécurité.

### Le reverse proxy

Ce service ne sera pas nécessaire dans un premier temps mais devra être utilisé en production. Il permettra d'intercepter les flux réseau sur les ports 443 et 80 de l'hôte, de façon à forcer les connexions sécurisées (HTTPS) et rediriger ensuite les flux autorisés vers le service d'interface utilisateur. Tous les conteneurs reliés au reverse proxy le seront sur un réseau dédié.

### Hôte

L'hôte sera une machine virtuelle sous Ubuntu Server 24.04. Il s'agit d'une version LTS garantissant donc un support de long terme et des mises à jour de sécurité sur 5 ans.

## Livrables attendus

- Code du projet versionné
- Document de conception
