chore(content): Write on 'Cahier des charges'

TODO

@@ -0,0 +1,10 @@
+# TODO list
+
+## Orga
+
+* faire des "liens" {mot-clé} pour CHAQUE titre
+
+## Remerciements
+
+* Trouver adjectifs pour chacun
+* Faire un beau paragraphe pour la plupart

content/10_liste_competences.md

@@ -3,3 +3,17 @@
 # Liste de compétences couvertes par le projet
 
 TODO: Lister compétences du référentiel
+
+* Automatiser la création de serveurs à l'aide de scripts
+* Automatiser le déploiement d'une infrastructure
+* Mettre l'infrastructure en production dans le cloud
+* Préparer un environnement de test
+* Gérer des containers
+* Automatiser la mise en production d'une application avec une plateforme
+
+Ne couvre pas - pour le moment : 
+
+* Sécuriser l'infrastructure
+* Gérer le stockage des données
+* Définir et mettre en place des statistiques de services
+* Exploiter une solution de supervision

content/20_cahier_des_charges.md

@@ -3,3 +3,216 @@
 # Cahier des charges
 
 TODO: cahier des charges
+
+## Contexte
+
+TODO : présenter Datascientest succinctement (dans un sous titre ?)
+
+### Dans le cadre d'une formation
+
+[Datascientest]{#datascientest}
+
+TODO: compléter ici ce que Datascientest fait
+
+### 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**.
+
+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
+
+#### 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éccisifs 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,
+* [**Gitlab**, DevU42](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](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**.
+
+Après livraison, l’amélioration du projet en continu se fera sur **6 semaines supplémentaires** durant lesquelles un dossier professionnel et un support de présentation est demandé à chacun des [membres de l'équipe](#devu42).
+
+## Le projet
+
+### Justification du projet
+
+Le projet s’inscrit dans le cadre suivant&nbsp;: 
+
+Une entreprise a besoin que son application de gestion d’utilisateur soit portée par les pratiques DevOps, pour faire évoluer son service.
+
+De nombreux problèmes sont constatés avec la façon de fonctionner actuelle&nbsp;: 
+
+* Reprise d’activité lente, coûteuse et avec des pertes d’informations importantes
+* Stabilité et disponibilité du service vulnérable
+* Capacité limitée à encaisser les charges soudaines de trafic
+* Absence de supervision efficace, et de capacité à prévoir les problèmes
+* Manque de contrôle sur la qualité du code, et les procédures de développement
+* Grande perte de temps lié aux nombreuses actions manuelles et aux erreurs humaines
+* Possibilité d’évolution limité par le manque de portabilité
+* Lenteur de l’implémentation de nouvelles fonctionnalité, et interruptions de service
+
+### Application existante
+
+L’application FastAPI-Træfik est fournie avec les éléments principaux suivants : 
+
+* BackEnd FastAPI (en Python)
+* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.)
+* Base de données
+* Traefik (Proxy inverse)
+
+### Ambitions
+
+* Répondre aux problématiques de l’application existante par la méthode DevOps.
+* Répondre aux attentes de l’examen en matière de compétences attendues.
+* Démontrer un savoir-faire technique sur les sujets principaux du Cloud dont AWS.
+* Appliquer une méthode de travail qui optimise l’efficacité de la production des livrables.
+
+### Objectifs
+
+* Porter l’application sur le cloud, avec une architecture réseau dans le respect du budget.
+* Assurer une reprise d’activité en un minimum de temps.
+* Déployer automatiquement et en continu avec des fichiers modularisés.
+* Sauvegarder les données pour garantir leur conservation en cas de sinistre.
+* Etablir une sécurité multi-niveau qui garantisse l’intégrité de l’application et de l’architecture, sans
+  handicaper les travailleurs dans leur travail au quotidien.
+* Rendre le système résilient, en assurant son auto-scalabilité et sa haute disponibilité.
+* Automatiser l’essentiel des actions pour limiter les erreurs humaines et gagner du temps.
+* Rendre le contrôle du code et des versions, systématique.
+* Mettre en place des solutions de supervisions et des tableaux de bord efficaces.
+* Mettre en place un système d’alertes pour détecter les problèmes au plus tôt.
+
+## Planification
+
+### Étapes de travail
+
+Semaine 1 : Choix du projet
+
+* Constitution des groupes par l’organisme de formation
+* Choix du projet par le groupe nouvellement formé
+* Découverte de l’application en détail
+* organisation de l’équipe
+* choix des outils principaux et prise en main de ces derniers
+
+Semaine 2 : Planification
+
+* Etablissement du présent cahier des charges 
+* Prise en main de l’application
+* Conception des schémas
+* Choix des différents outils qui seront explorés les semaines suivantes
+* Mise en place de l’organisation sur GitLab, et des procédures de travail
+* Attribution de tâches par individu
+* Exploration de projets similaires
+* Décider d’une première approche pour l’automatisation gitlab-ci
+* Décider des futurs repo/registry pour les images et les charts.
+
+Semaine 3 : Automatisation de la chaine d’intégration et de livraison
+
+* Adoption de la méthode GitOneFlow
+* Mise en œuvre des deux environnements séparés Stagging et Prod
+* Développement des processus d’automatisation des :
+  - Tests
+  - Constructions/Compilations
+  - Livraison
+  - Déploiement
+* Mise en place de la promotion de version (basé sur Sem Ver)
+* Produire un schéma clair résumant nos dépôts et nos pipelines sur Gitlab.
+
+Semaine 4 : Conception de l’Infrastructure
+
+* Définir la couche réseau de l’infrastructure sur AWS en haute disponibilité
+* Assurer la sécurité des éléments de la couche réseau
+* Prévoir une future solution de stockage
+* Adopter une solution de backup
+* Définir la distribution de Kubernetes à employer, et la déployer.
+* Gestion des secrets
+* Générer la redirection vers notre propre nom de domaine
+* Objectif : Infrastructure As Code
+
+Semaine 5 : Gestion des données
+
+* Appliquer la méthode de stockage de données choisie
+* Définir les politiques d’authentification, d’autorisation et de contrôle d’accès
+* Assurer une journalisation
+* Garantir la sauvegarde des données, et leur restauration en cas de sinistre
+* Mettre en place la scalabilité de la solution choisie.
+* Tester l’accessibilité des données par l’application
+
+Semaine 6 : Observabilité et Alertes
+
+* Choisir une solution de monitoring 
+* Définir les données d’analyse du système dans sa globalité, et multi-environnement
+* Créer des tableaux de bord pratiques et simples d’interprétation
+* Attribuer des alertes à certaines métriques
+* Tester des situations anormales pour constater si les alarmes se déclenchent correctement
+
+Semaine 7 : Préparer la communication
+
+* Mettre à jour les schémas as code (Mermaid et Draw.io)
+* Création du support de diapositives as code
+* Rédaction de la présentation, et entrainement individuel
+* Tests de fonctionnement de l’implémentation d’une nouvelle fonctionnalité
+* Mise en commun des compétences et des connaissances en vue de la présentation
+* Fabrication d’un logo d’équipe
+* Résolution des dernières améliorations
+
+### Livrables attendus
+
+Documents informatifs&nbsp;: 
+
+* Cahier des charges
+* Support de communication diapositive
+* Schéma pour chaque préoccupation majeure
+* Dossier de projet 
+
+Gitlab&nbsp;: 
+
+* Registre d’images docker
+* Dépôt pour les charts
+* Dépôt de l’application initiale
+* Ensemble des fichiers de déploiement de l’architecture et des environnement modularisés
+* Pipelines (Gitlab-ci)
+* Le dépôt du projet
+
+L’application&nbsp;: 
+
+* L’accès au backend
+* L’accès sécurisé https à notre Frontend
+* Le tout via notre propre nom de domaine
+