soutenance/content/20_cahier_des_charges.md

\newpage

# Cahier des charges

Dans le cadre d'une **formation, dans l'école DataScientest**, il a été 
demandé à des équipes composées de 3 à 5 personnes de travailler sur un 
**projet défini, cadré** et suivant un certain nombre de contraintes dont nous 
allons parler ici.

Le cahier des charges a été la première réflexion sur le projet.

## Contexte

Commençons par le contexte du projet avec l'ensemble des intervenants et des 
contraintes attenantes.

### Dans le cadre d'une formation

**[Datascientest]{#datascientest}** est une **école de formation** créée en 
2017, située sur Paris et proposant **plus de 18 formations différentes**, 
dont *Administrateur Système DevOps*.

Plusieurs formats de formation existent parmi **Bootcamp**, continu et en 
alternance. **Ce projet est un exercice de fin de formation** proposé à tous 
les élèves de la « cohorte » (équivalent d'une classe).

Plusieurs élèves se regroupent autour d'un projet auquel ils ont un **intérêt 
commun**.

### L'équipe DevU42 {#devu42}

Le **groupe DevU42** s'est formé le **17 octobre 2024**. Il est composé de 
**quatre étudiants** participant à la formation **Administrateur Système 
DevOps** de l’organisme de formation [DataScientest](#datascientest).

Ses membres sont, par ordre alphabétique (prénom) : 

* **Eliel MONCADA**
* **Hrubech HOMBESSA**
* **Julien SABIOLS**
* Olivier DOSSMANN

Ils interviennent sur le projet en qualité d’**Administrateur Système DevOps**.

L'équipe a été supervisée et suivie par [**Jérémie Tarot** sous la 
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il dans le 
présent document.

### Organisation d'équipe

Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies.

#### Rapports hiérarchiques

L’équipe s'articule autour de membres ayant le **même degré de 
responsabilités** et d'objectifs. Leur périmètre et leur champ d'action est 
similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les 
axes de travail à rajouter au projet ou bien de nouveaux objectifs.

En cas de désaccord sur un sujet, une décision est prise à la majorité 
votante, avec pour ultime recours l’avis du [Mentor](#mentor).

#### Moyens de communication

La géolocalisation des membres de l'**équipe étant éparse**, plusieurs moyens 
de communication **en ligne** ont été nécessaires, parmi : 

* Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis 
initialement par [Datascientest](#datascientest) : 
  * canal du projet - **sep24_bootcamp_devops** : favorise l'échange 
  entre [DevU42](#devu42) et le [Mentor](#mentor),
  * canal d'équipe - **devu42** : pour les **discussions techniques**, 
  les choix décisifs et de la bonne humeur !
* Un nom de domaine, **devu42.fr**,
* Une boîte courriel, **<team@devu42.fr>** partagée pour la **gestion des 
services**,
* [**Groupe DevU42 sur Gitlab**](https://gitlab.com/devu42/), un outil intégré 
avec gestion d'équipe, gestion de projet, gestion de tickets, gestion de 
tableau de bord (kanban), gestion de dépôts, gestion de paquets, etc.
* Un [**wiki**, DevU42 sur 
Gitlab](https://gitlab.com/devu42/projet/-/wikis/home) (fourni par Gitlab) 
permettant de rassembler les **connaissances de l'équipe** en un seul endroit,
* [**Framapad**](https://framapad.org/abc/fr/), un éditeur de **texte 
collaboratif** pour les divers travaux de rédaction.

### Contraintes initiales

Deux principales contraintes initiales avaient été imposées dans le cadre de 
la formation&nbsp;: 

* le **budget**,
* le **temps**.

#### Budget

Le budget alloué au projet est de **150€ mensuel** pour couvrir l'intégralité 
des frais issus de l'utilisation de **services Amazon** (AWS).

C'est une limite configurée par [Datascientest](#datascientest) sur l'espace 
Amazon qu'ils nous partagent.

#### Temps

Le temps alloué pour réaliser ce projet avant un premier lancement officiel 
est fixé à **7 semaines**.

Au terme des 7 semaines, un support visuel de présentation du projet pour son 
lancement est attendu (Cf. [Section du présent chapitre sur les 
Livrables](#livrables)).

Après livraison, l’amélioration du projet est possible, bien qu'un dossier 
professionnel, un dossier de projet (ci-présent) et un support de présentation 
est demandé à chacun des [membres de l'équipe DevU42](#devu42).

## Le projet

Le point de départ du projet est un dépôt de version contenant une application 
à mettre en ligne. Justification du projet, l'application elle-même, ambitions 
et objectifs sont des points à soulever.

### Justification du projet

L'école de formation [DataScientest](#datascientest) s'évertue à proposer une 
**situation proche de la réalité** afin que l'équipe nouvellement formée 
puisse **apprendre par la pratique**.

On imagine facilement le cadre&nbsp;: 

> Une entreprise ayant une application de gestion d’utilisateur souhaite 
> déployer et faire évoluer son service en favorisant les bonnes pratiques 
> suivies dans la culture DevOps.

De la même manière, l'entreprise pourrait rencontrer de nombreux 
**problèmes**&nbsp;: 

* **Reprise d’activité** lente, coûteuse et avec pertes d’informations,
* Service instable, **disponibilité** non garantie, **vulnérabilité** du 
service,
* Capacité limitée pour encaisser des **augmentations** ponctuelles de la 
**charge** et du **trafic**,
* Absence de **supervision** et faible capacité à prévoir les problèmes,
* Manque de contrôle sur la **qualité du code**&nbsp;; procédures de 
développement pouvant être améliorées par l'**automatisation**,
* Perte de temps et erreurs humaines liées aux actions manuelles,
* Manque de **portabilité de l'application** d'un système à l'autre,
* Lenteurs d’implémentation de **nouvelles fonctionnalités** avec 
interruptions de service.

Pour bien saisir l'état des lieux de ladite application, regardons de plus 
près.

### Application existante

L'**application FastAPI-Træfik** est fournie avec les éléments principaux 
suivants&nbsp;: 

* Backend utilisant le framework **FastAPI** (en Python),
* Frontend statique (en **React**, **Vite.js** et **Chakra UI**)&nbsp;: 
Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du 
backend,
* Base de données **postgreSQL**,
* et **Traefik** (Proxy inverse).

Tout ceci est déposé dans un **dépôt de version** avec de la **documentation** 
en fichier *Markdown* (*.md) bruts.

De simples fichiers **Docker** et **docker-compose.yml** permettent aux 
développeurs de **lancer l'application localement**.

**Une procédure manuelle existe** pour expliquer comment mettre l'application 
en production sur une machine serveur dédiée.

Mais **le projet voit plus loin**.

### Ambitions

En dehors des objectifs à atteindre, le projet vise à&nbsp;: 

* répondre aux problématiques de l’entreprise sur l'application existante par 
**la méthode DevOps**,
* répondre aux attentes de l’examen en matière de compétences attendues 
(méthode d'**apprentissage par la pratique**),
* démontrer un **savoir-faire technique** sur les sujets principaux du DevOps, 
notamment vis à vis du Cloud **en utilisant AWS** (Amazon Web Services),
* appliquer une méthode de travail qui optimise l’efficacité de la production 
des livrables.

C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques.

### Objectifs

D'après moi, ce projet à plusieurs objectifs&nbsp;: 

* balayer l'ensemble des **sujets liés à la culture DevOps et ses méthodes**,
* porter, puis **déployer** une application **sur le cloud**,
* préparer une **architecture complète** pour accueillir une à plusieurs 
applications,
* respecter un **budget** et des **limites de temps**,
* **déployer en continu** un projet en passant par une phase de test, de 
pré-production puis de production,
* penser à la **gestion de la donnée**,
* **superviser** un système déployé en production avec des tableaux de bord 
efficaces,
* rendre un système **résilient** en prenant en compte les augmentations ET 
les diminution de **charges** et par une **haute disponibilité**,
* **automatiser** la plupart des actions afin de **limiter les erreurs 
humaines**,
* procéder, de manière automatique, à des vérifications sur **la sécurité** 
des éléments produits et déployés,
* favoriser une **collaboration** plus fluide entre les équipes de 
développements et les équipes d'opérations,
* et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments 
du système.

Ce sont des **objectifs plutôt ambitieux pour un temps aussi court**. Un 
travail d'équipe et une organisation de cette dernière sont totalement 
primordiaux.

## Planification

C'est par le [mentor](#mentor) que nous avons reçu le plan d'action pour les 7 
semaines de travail à venir et une liste de livrables attendus. Nous avons 
adapté ce plan d'action pour nous correspondre.

### Étapes de travail

Commençons par le détail de chaque étape. Pour les 7 semaines à venir.

#### Semaine 1&nbsp;: Cadrage

Sous le signe de l'**encadrement**, cette première semaine est dite « douce »&nbsp;: 

* **réunion** de prise de contact, présentation et cadrage,
* introduction de chaque membre du projet,
* **découverte** de l'application,
* **analyse** du sujet,
* évaluation du contexte, des objectifs et du **périmètre** du projet,
* et **rédaction** du premier jet du présent **cahier des charges**.

Il faut ce temps pour découvrir de quoi il retourne.

#### Semaine 2&nbsp;: Planification

Vient ensuite une **phase d'organisation** avec&nbsp;: 

* définition du contexte, des objectifs et du périmètre du projet,
* **organisation** des exigences,
* **identification des composants** d'architecture,
* choix de **solutions à implémenter**,
* et **définition de l'architecture** et les **spécifications** du système 
cible.

Ce qui amène à **compléter le cahier des charges**.

Nous prévoyons aussi&nbsp;: 

* une **configuration de Gitlab**, des principaux dépôts, des branches, etc.,
* de s'organiser en équipe&nbsp;: définir des **méthodologies** à suivre.

#### Semaine 3&nbsp;: Automatisation de la chaine d’intégration et de livraison

Une fois les outils principaux mis en place, il s'agit d'**automatiser** 
plusieurs parties&nbsp;: 

* automatisation des **tests pour le backend et le frontend**,
* création d'**image Docker pour le backend**,
* création d'**image Docker pour le frontend**,
* automatisation des images Docker et de leur **publication sur des 
registres d'images**,
* création de **chart Helm pour le backend**,
* création de **chart Helm pour le frontend**,
* automatisation de la création des chart Helm et de leur **publication sur 
des registres d'images**,
* et **automatisation de la création de l'infrastructure** (même si elle n'est 
pas encore clairement définie).

L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue.

#### Semaine 4&nbsp;: Conception de l’infrastructure

Vient ensuite la création de la **couche basse de l'infrastructure**&nbsp;: 

* **création d'un schéma** de la couche basse de l'infrastructure,
* description de cette infrastructure via des modules adaptés et en adoptant 
l'**Infrastructure as Code (IaC)**,
* premiers **choix de solutions** pour le **stockage**, les **sauvegardes**, 
la **supervision** et l'**environnement d'accueil** de l'application,
* activation des **certificats** Let's Encrypt,
* liaison avec le **nom de domaine**,
* et **mise à l'échelle automatique**.

Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche 
cela permet de les aborder et d'échanger sur ces derniers.

#### Semaine 5&nbsp;: Gestion des données

Possiblement en parallèle du [sujet de la semaine 6 sur l'Observabilité et des 
alertes](#semaine6), la gestion des données est importante et passe par&nbsp;: 

* créer et configurer des **ressources de stockage de données**,
* mise en place de **politique d'authentification** et d'autorisation,
* **import des données**,
* et installer/configurer une solution de **sauvegarde** et de **restauration 
de données**.

C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle** 
d'un autre.

#### Semaine 6&nbsp;: Observabilité et alertes {#semaine6}

Quant à la semaine 6, nous avons **principalement la supervision** à 
gérer&nbsp;: 

* configuration du **système de supervision centralisé**,
* mise en place d'une **collecte** de surveillance **pertinente** pour 
l'application,
* **choix des métriques** à utiliser pour la création de tableaux de bords,
* création des **tableaux de bords**,
* **définition des niveaux d'alertes** pour les métriques choisis,
* mise en place des **alertes**,
* et envoi des alertes sur **les canaux choisis**.

Ces éléments pourront être complétés et étendus une fois la solution 
principale de supervision configurée.

#### Semaine 7&nbsp;: Présentation de la solution finale

Cette dernière semaine ciblera la **présentation et** le **lancement officiel 
de l'application**. Il faudra donc&nbsp;: 

* compléter les **documentations**,
* **mettre à jour les schémas** en fonction d'éventuels changements,
* préparer un **support visuel de présentation du projet**,
* veiller à ce que l'**application tourne sans accrocs** pour la présentation,
* et résoudre les derniers problèmes majeurs connus - s'ils existent.

C'est un **plan ambitieux** quand on considère que **les membres de l'équipe 
proviennent d'horizons et de formations variées**.

### Livrables {#livrables}

Sont attendus les **livrables** suivants&nbsp;: 

* un **cahier des charges**,
* une **présentation par diapositives** pour le lancement de l'application,
* une application **déployée en production**, sans bugs,
* un **système de supervision** de la production,
* une **gestion des données** avec un **système de sauvegarde**,
* un **schéma de la couche basse de l'infrastructure** utilisée dans le Cloud 
pour la production,
* un **accès aux dépôts et scripts** permettant l'automatisation du 
déploiement de l'application et de la génération des différents éléments 
(images Docker, Chart Helm, registres, etc.),
* et un **fonctionnement en haute disponibilité** de l'application.

## Conclusion

Le projet **couvre beaucoup de situations** et **domaines** autour de 
**l'automatisation** et la **mise en production**, dans le Cloud, d'une 
application avec une **supervision** et une **mise à l'échelle** de cette 
dernière.

En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la 
pratique** » proposé par [DataScientest](#datascientest) et couvrir un maximum 
de compétences demandées pour le *Titre Professionnel d'Administrateur 
Système* DevOps.