release: v1.3 - New version

Makefile

@@ -44,7 +44,7 @@ public/${NAME}.html: public ${CONTENT_LIST}
 
 public/${NAME}.pdf: public ${CONTENT_LIST}
 	$Qecho "[PREPA] PDF       : contenu"
-	# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
+	$Q# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
 	$Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown+implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST}
 
 # END

README.md

@@ -8,7 +8,7 @@ Document's content is available under **content** directory.
 
 Only `*.md` files would be read ([Markdown format](https://daringfireball.net/projects/markdown/)).
 
-# Depenencies
+# Dependencies
 
 ## ArchLinux
 

content/00_meta.md

@@ -4,7 +4,7 @@ subtitle: Dossier de projet - API Utilisateurs
 author: Olivier \textsc{Dossmann} 
 mail: <emploi@dossmann.net>
 date: 05 mars 2025
-version: 1.0
+version: 1.3
 mentor: Jérémie \textsc{Tarot}
 qrcode: https://odtre.gitlab.io/diapos/
 geometry:

content/05_intro.md

@@ -1,35 +0,0 @@
-\newpage
-
-# Introduction {#introduction}
-
-La **méthodologie Agile** étant de plus en plus adoptée, les **équipes de 
-développement** publient de nouvelles versions de leur application avec une 
-fréquence bien plus élevée. Les **équipes d'opération** ont désormais besoin d'un
-outillage plus conséquent pour déployer ces versions. C'est pour cette raison 
-que l'**automatisation**, entre autre, est nécessaire pour soulager les équipes
-d'opération. Ainsi **le DevOps entre en jeu** : une culture et un 
-ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes 
-de développement et celles d'opérations. Mais également de favoriser un **flux
-continu** entre ces équipes.
-
-Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et 
-Développement d’Environnements Distribués** ou **Responsable d'Applications**, j'ai 
-été sensibilisé aux besoin incessants de l'automatisation et de l'amélioration
- des processus de création logiciel. J'ai participé à la mise en place 
-progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde 
-professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout
- naturellement que je me suis tourné vers ce domaine passionnant qu'est le 
-DevOps. Et ce à travers la **formation DevOps en BootCamp** au sein de l'organisme
- de formation DataScientest.
-
-Le présent document présentera principalement le projet étudié lors de cette 
-formation. Nous commencerons par faire la corrélation entre les compétences 
-attendues pour le *Titre Professionnel Administrateur Système DevOps* et le(s) 
-projet(s) présenté(s) dans ce dossier. Après quoi nous continuerons avec le 
-cahier des charges et les spécifications techniques de ce(s) dernier(s). \
-Nous continuerons par expliquer la démarche suivie pour accomplir le projet, 
-quelques réalisations effectuées et d'une situation de travail qui mérite 
-d'être relevée.
-
-Mais avant tout, nous tenons à présenter nos remerciements à quelques personnes.
-

content/08_remerciements.md

@@ -1,105 +0,0 @@
-\newpage
-
-# Remerciements
-
-Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été 
-possible : **Agnès \textsc{Schweitzer}**. Elle a été l'**immense 
-soutien** derrière les petites mains qui écrivent ces lignes. Présente quand 
-les choses n'allaient pas, quand la voie semblait sans issue et que l'iceberg 
-s'approchait du bateau ! En sa précense l'**humilité** n'a qu'à bien se 
-tenir !
-
-À **Madame \textsc{Schweitzer}** pour ses **conseils**, son aide 
-**précieuse**, sa **présence d'esprit** et son **exceptionnelle 
-intelligence** : MERCI !
-
-## À l'organisme de formation DataScientest
-
-Nous avons parfois besoin d'un coup de pouce pour rejoindre les rails d'une 
-autre ligne. C'est ce que permet l'organisme de formation **DataScientest** 
-au travers de ses nombreux parcours proposés aux personnes qui, comme moi, 
-souhaitent **changer de métier**.
-
-Je remercie Sarah \textsc{Bouras} d'avoir été mon premier contact avec cet 
-organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision 
-et parcimonie** à toutes mes questions et de me rassurer sur les sujets qui 
-m'inquiétaient.
-
-C'est ensuite Benjamin \textsc{Fiche}, **chef de cohorte**, qui a pris le pas 
-en répondant **consciencieusement** à toutes mes questions ; même les plus 
-triviales/simplettes/absurdes. Il a toujours fait preuve d'**un 
-professionnalisme hors pair** et je me devais de le souligner.
-
-Nous avons également Jérémie \textsc{Tarot}, notre **passionnant - et 
-passionné** - Mentor qui détient une **connaissance infinie** des outils 
-et des pratiques du monde du DevOps. Son savoir nous a donné de **multiples 
-pistes** quand nous étions bloqués. Ses conseils ont été spécifiquement utiles 
-lorsque les ressources venaient à manquer dans le projet, que ce soit en terme 
-de ressources humaines ou de ressources temporelles. Il a **cru en nous** ; et 
-ceci représente une aide précieuse.
-
-Je remercie également **l'ensemble de l'équipe DataScientest** pour leur 
-patience et leur savoir-vivre au regard de mes nombreux retours sur les cours, 
-les examens et les machines virtuelles fournies.
-
-## À l'équipe DevU42
-
-Chaque membre de l'équipe a ses **difficultés**, une **vie sociale et 
-familiale** prenante, des **obligations** et des **responsabilités** à côté de 
-la formation.
-
-Pris à part, nous avons **chacun nos particularités**. Ensemble ces problèmes 
-étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons 
-faits. Et rien que pour cela je remercie l'équipe d'y être parvenu.
-
-À Eliel \textsc{Moncada} pour ses **trouvailles** Web et sa **patience** sur 
-les schémas visuels qui prennent un temps considérable !
-
-À Hrubech \textsc{Hombessa} pour sa **qualité d'échange** sur des **sujets 
-pointus** et la **pertinence** de ses questions.
-
-À Julien \textsc{Sabiols} pour sa **détermination**, son **travail acharné**, 
-son **intelligence** et son énorme **humilité**. Il a su être un partenaire 
-de pair-programming **brillant** avec un **esprit affûté**. C'est rare. Et 
-très appréciable !
-
-J'imagine que derrière chaque personne il y a également **un ou une partenaire 
-de vie** qui a facilité l'organisation et la disponibilité autour de la 
-formation. Pour ces personnes **cachées dans l'ombre** : MERCI ! 
-Vous méritez de figurer dans ces lignes.
-
-## Aux membres de la « cohorte »
-
-Je tiens à remercier également **l'ensemble des membres de la cohorte**. À 
-ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger, 
-à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé 
-des difficultés ou encore des solutions, à ceux qui étaient eux-même.
-
-Une mention particulière aux personnes suivantes (ordre alphabétique - 
-prénom) :
-
-* à Dorian \textsc{Roly} pour nos **échanges intéressants** sur de multiples 
-technologies et sur les archétypes des personnes dans l'informatique,
-* à Maxime \textsc{Boulanghien} pour sa **sérénité**, son **implication** et 
-son efficacité sur des sujets dûments travaillés ; notamment la promotion 
-logicielle au sein d'une automatisation complète de déploiement d'une 
-infrastructure,
-* à Michael \textsc{Lachand} pour nos discussions sur **l'importance de 
-l'individu** au sein du domaine professionnel plutôt que des chiffres et des 
-compétences seules ; mais aussi des difficultés apportés par notre Société 
-moderne à ce sujet,
-* et enfin à Philippe \textsc{Risser-Maroix} avec qui j'ai pu discuter de 
-**notions informatiques poussées** et de Logiciel Libre sans me sentir seul à 
-ce sujet ; sa sensibilité au sujet de la **sécurité informatique** est un 
-point fort !
-
-## Et les autres
-
-D'autres personnes n'ayant aucun lien avec cette formation ont pourtant 
-participé à leur façon. Je tiens à remercier notamment Grégoire 
-\textsc{Stein}, en sa qualité de **DevSecOps**, pour ses **précieux 
-conseils** tout au long de cette aventure !
-
-Si d'aventures j'avais oublié des personnes, je m'en excuse. Il y a pourtant 
-ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à 
-toutes celles et ceux dont j'aurais omis le nom/prénom.

content/10_intro.md

@@ -0,0 +1,53 @@
+\newpage
+
+# Introduction {#introduction}
+
+La **méthodologie Agile** étant de plus en plus adoptée, les **équipes de 
+développement** publient de nouvelles versions de leur application avec une 
+fréquence bien plus élevée. Les **équipes d'opération** ont désormais besoin d'un
+outillage plus conséquent pour déployer ces versions. C'est pour cette raison 
+que l'**automatisation**, entre autres, est nécessaire pour soulager les équipes
+d'opération. Ainsi **le DevOps entre en jeu** : une culture et un 
+ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes 
+de développement et celles d'opération. Mais également de favoriser un **flux
+continu** entre ces équipes.
+
+Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et 
+Développement d'Environnements Distribués** ou **Responsable d'Applications**, j'ai 
+été sensibilisé aux besoins incessants de l'automatisation et de l'amélioration
+ des processus de création logicielle. J'ai participé à la mise en place 
+progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde 
+professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout
+ naturellement que je me suis tourné vers ce domaine passionnant qu'est le 
+DevOps. Et ce à travers la **formation DevOps en BootCamp** au sein de l'organisme
+ de formation DataScientest.
+
+Le présent document abordera principalement le projet étudié lors de cette 
+formation. Nous commencerons par faire la corrélation entre les compétences 
+attendues pour le *Titre Professionnel Administrateur Système DevOps* et le(s) 
+projet(s) présenté(s) dans ce dossier. Après quoi nous continuerons avec le 
+cahier des charges et les spécifications techniques de ce(s) dernier(s). \
+Nous continuerons en expliquant la démarche suivie pour accomplir le projet, 
+quelques réalisations effectuées ainsi qu'une situation de travail qui mérite 
+d'être relevée.
+
+**Conventions typographiques**
+
+Ce document suit certaines conventions de mise en forme pour faciliter la 
+lecture :
+
+* Les liens hypertextes apparaissent sous la forme suivante : [Titre du lien](
+https://perdu.com),
+* Les références vers d'autres sections sont indiquées comme suit : [référence 
+vers un paragraphe spécifique, exemple avec DataScientest](#datascientest),
+* Les mots-clés essentiels d'une section sont en **gras**,
+* Les termes particuliers sont en *italique*,
+* Les noms de famille apparaissent avec de petites majuscules : Prénom \textsc{Nom},
+* Les extraits de code sont affichés dans un format distinct :
+
+```bash {.numberLines}
+#!/usr/bin/env bash
+
+echo "Bonjour tout le monde !"
+```
+

content/20_remerciements.md

@@ -0,0 +1,54 @@
+\newpage
+
+# Remerciements
+
+À **Madame Agnès \textsc{Schweitzer}** pour ses **conseils**, son aide 
+**précieuse**, sa **présence d'esprit** et son **exceptionnelle 
+intelligence** : MERCI !
+
+## Via l'organisme de formation DataScientest
+
+Je remercie **l'ensemble de l'équipe DataScientest** pour leur patience et 
+leur savoir-vivre au regard de mes nombreux retours sur les cours, les examens 
+et les machines virtuelles fournies.
+
+Une mention toute particulière aux personnes suivantes pour leur **écoute**, 
+leur **professionnalisme** et leur souci de réponses claires : 
+
+* Sarah \textsc{Bouras},
+* Benjamin \textsc{Fiche},
+* et Jérémie \textsc{Tarot}.
+
+Aux **membres de l'équipe DevU42** qui, malgré les **difficultés**, une **vie 
+sociale et familiale** prenante, des **obligations** et des 
+**responsabilités** ont donné ce qu'ils pouvaient : 
+
+* Hrubech \textsc{Hombessa},
+* Eliel \textsc{Moncada},
+* et Julien \textsc{Sabiols}.
+
+J'imagine que derrière chacune de ces personnes il y a également **un ou une 
+partenaire de vie**. Vous méritez de figurer dans ces lignes et d'avoir un 
+grand MERCI !
+
+Aux **membres de la « cohorte »** que je tiens à remercier. À 
+ceux qui ont participé aux discussions, qui ont voulu échanger, qui ont 
+accepté de répondre à des questions, qui ont partagé des difficultés ou encore 
+des solutions et qui étaient eux-mêmes finalement.
+
+Une mention aux personnes suivantes :
+
+* à Maxime \textsc{Boulanghien},
+* à Michael \textsc{Lachand},
+* à Philippe \textsc{Risser-Maroix},
+* et à Dorian \textsc{Roly}.
+
+## Et d'autres encore !
+
+D'autres personnes n'ayant aucun lien avec cette formation ont pourtant 
+participé à leur façon. Je tiens à remercier notamment Grégoire 
+\textsc{Stein}, en sa qualité de **DevSecOps**, pour ses **précieux 
+conseils** tout au long de cette aventure !
+
+À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et 
+fautes d'orthographes découvertes dans ce document.

content/30_liste_competences.md

@@ -2,21 +2,23 @@
 
 # Liste de compétences couvertes par le projet
 
+## Introduction
+
 Le référentiel de compétences du *Titre Professionnel Administrateur Système 
 DevOps* liste 11 compétences réparties en 3 catégories : 
 
-* Automatiser le déploiement d’une infrastructure dans le cloud
-  * Compétence **n°1 : Automatiser la création de serveurs à l’aide de 
+* Automatiser le déploiement d'une infrastructure dans le cloud
+  * Compétence **n°1 : Automatiser la création de serveurs à l'aide de 
   scripts**
   * Compétence **n°2 : Automatiser le déploiement d'une infrastructure**
-  * Compétence **n°3 : Sécuriser l’infrastructure**
-  * Compétence **n°4 : Mettre l’infrastructure en production dans le 
+  * Compétence **n°3 : Sécuriser l'infrastructure**
+  * Compétence **n°4 : Mettre l'infrastructure en production dans le 
   cloud**
 * Déployer en continu une application
   * Compétence **n°5 : Préparer un environnement de test**
   * Compétence **n°6 : Gérer le stockage des données**
   * Compétence **n°7 : Gérer des containers**
-  * Compétence **n°8 : Automatiser la mise en production d’une 
+  * Compétence **n°8 : Automatiser la mise en production d'une 
   application avec une plateforme**
 * Superviser les services déployés
   * Compétence **n°9 : Définir et mettre en place des statistiques de 
@@ -25,8 +27,11 @@ DevOps* liste 11 compétences réparties en 3 catégories :
   * Compétence **n°11 : Échanger sur des réseaux professionnels 
   éventuellement en anglais**
 
+## Couverture
+
 En utilisant les critères de performance fournis par chaque fiche de 
-compétence, j'ai pu établir le tableau suivant : 
+compétence, j'ai pu établir le tableau suivant permettant de voir les points à 
+améliorer : 
 
 : Couverture de compétences du projet
 
@@ -35,7 +40,7 @@ Compétence | Nbre critères perf. | Couverte ? | Note
 Compétence n°1 | 3/3 | Oui | EC2 / Terraform
 Compétence n°2 | 3/3 | Oui | Terraform
 Compétence n°3 | 2/2 | Oui | Staging, Vaultwarden, Let's Encrypt
-Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
+Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
 Compétence n°5 | 4/4 | Oui | Gitlab CI
 Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero
 Compétence n°7 | 4/4 | Oui | Docker
@@ -49,10 +54,16 @@ tests concernant le système de sauvegarde qui a été développé mais pas
 déployé, **faute de tests et de temps**.
 
 La **compétence n°9** (Définir et mettre en place des statistiques de 
-services) ne semble pas pertinente dans un projet où nous n'avons eu **aucun 
-autre interlocuteur que le « mentor »**.
+services) n'a pu être clairement établie **faute d'interlocuteur autre que le 
+« mentor »**.
 
 La **compétence n°10** (Exploiter une solution de supervision) est **en lien 
 avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs 
-mis en place dans la solution. Ce qui, à mon sens, ne résoud pas totalement 
-cette compétence.
+mis en place dans la solution.
+
+## Conclusion
+
+Le projet décrit dans le présent document couvre de manière complète une 
+énorme partie des compétences attendues. Au final 2 type de compétences 
+sont partiellement couvertes : celle concernant la supervision et celle 
+concernant le stockage de données.

content/40_cahier_des_charges.md

@@ -1,5 +1,3 @@
-\newpage
-
 # Cahier des charges
 
 Dans le cadre d'une **formation, dans l'école DataScientest**, il a été 
@@ -16,57 +14,58 @@ contraintes attenantes.
 
 ### Dans le cadre d'une formation
 
-**[Datascientest]{#datascientest}** est une **école de formation** créée en 
+**[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 
+Plusieurs formats de formation existent parmi **Bootcamp**, continue et en 
 alternance. **Ce projet est un exercice de fin de formation** proposé à tous 
-les élèves de la « cohorte » (équivalent d'une classe).
+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**.
+Plusieurs élèves se regroupent autour d'un projet pour lequel 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).
+DevOps** de l'organisme de formation [DataScientest](#datascientest).
 
-Ses membres sont, par ordre alphabétique (prénom) : 
+Ses membres sont, par ordre alphabétique : 
 
-* **Eliel MONCADA**
-* **Hrubech HOMBESSA**
-* **Julien SABIOLS**
-* Olivier DOSSMANN
+* **Hrubech \textsc{Hombessa}**,
+* **Eliel \textsc{Moncada}**,
+* **Julien \textsc{Sabiols}**,
+* et Olivier \textsc{Dossmann}.
 
-Ils interviennent sur le projet en qualité d’**Administrateur Système DevOps**.
+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.
+L'équipe a été supervisée et suivie par [**Jérémie \textsc{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.
+Pour s'organiser, l'équipe s'est dotée de plusieurs outils et suivi certaines 
+méthodologies particulières.
 
 #### Rapports hiérarchiques
 
-L’équipe s'articule autour de membres ayant le **même degré de 
+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).
+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 : 
+de communication **en ligne** ont été nécessaires, parmi lesquels : 
 
 * Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis 
-initialement par [Datascientest](#datascientest) : 
+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**, 
@@ -96,7 +95,7 @@ la formation :
 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 
+C'est une limite configurée par [DataScientest](#datascientest) sur l'espace 
 Amazon qu'ils nous partagent.
 
 #### Temps
@@ -108,7 +107,7 @@ 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 
+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).
 
@@ -126,14 +125,14 @@ puisse **apprendre par la pratique**.
 
 On imagine facilement le cadre : 
 
-> Une entreprise ayant une application de gestion d’utilisateur souhaite 
+> Une entreprise ayant une application de gestion d'utilisateurs 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** : 
 
-* **Reprise d’activité** lente, coûteuse et avec pertes d’informations,
+* **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 
@@ -143,20 +142,20 @@ service,
 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 
+* Lenteurs d'implémentation de **nouvelles fonctionnalités** avec 
 interruptions de service.
 
+### Application existante
+
 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 : 
+L'**application API Utilisateurs** (nom de code FastAPI-Træfik) est fournie 
+avec les éléments principaux suivants : 
 
 * Backend utilisant le framework **FastAPI** (en Python),
 * Frontend statique (en **React**, **Vite.js** et **Chakra UI**) : 
-Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du 
+Interface de gestion et d'enregistrement d'utilisateurs utilisant l'API du 
 backend,
 * Base de données **postgreSQL**,
 * et **Traefik** (Proxy inverse).
@@ -170,26 +169,23 @@ 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 à : 
+Le projet **va plus loin** ; en dehors des objectifs à atteindre, il vise 
+à : 
 
-* répondre aux problématiques de l’entreprise sur l'application existante par 
+* 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 
+* 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 
+* 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 : 
+C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques : 
 
 * balayer l'ensemble des **sujets liés à la culture DevOps et ses méthodes**,
 * porter, puis **déployer** une application **sur le cloud**,
@@ -198,7 +194,7 @@ 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**,
+* penser à la **gestion des données**,
 * **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 
@@ -208,7 +204,7 @@ 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,
+développement et les équipes d'opération,
 * et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments 
 du système.
 
@@ -216,19 +212,20 @@ 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
+## Planification {#plan}
 
-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.
+Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan 
+d'action pour les 7 semaines de travail à venir ainsi qu'une liste de 
+livrables attendus.
 
 ### Étapes de travail
 
-Commençons par le détail de chaque étape. Pour les 7 semaines à venir.
+Le plan s'articule en étapes bien définies.
 
 #### Semaine 1 : Cadrage
 
-Sous le signe de l'**encadrement**, cette première semaine est dite « douce » : 
+Sous le signe de l'**encadrement**, cette première semaine est dite 
+« douce » : 
 
 * **réunion** de prise de contact, présentation et cadrage,
 * introduction de chaque membre du projet,
@@ -257,7 +254,7 @@ Nous prévoyons aussi :
 * une **configuration de Gitlab**, des principaux dépôts, des branches, etc.,
 * de s'organiser en équipe : définir des **méthodologies** à suivre.
 
-#### Semaine 3 : Automatisation de la chaine d’intégration et de livraison
+#### Semaine 3 : 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 : 
@@ -276,7 +273,7 @@ pas encore clairement définie).
 
 L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue.
 
-#### Semaine 4 : Conception de l’infrastructure
+#### Semaine 4 : Conception de l'infrastructure
 
 Vient ensuite la création de la **couche basse de l'infrastructure** : 
 
@@ -303,8 +300,8 @@ alertes](#semaine6), la gestion des données est importante et passe par :
 * 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.
+C'est un sujet bien à part. D'où la possibilité de **faire cette étape en 
+parallèle** d'une autre.
 
 #### Semaine 6 : Observabilité et alertes {#semaine6}
 
@@ -316,7 +313,7 @@ gérer :
 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,
+* **définition des niveaux d'alertes** pour les métriques choisies,
 * mise en place des **alertes**,
 * et envoi des alertes sur **les canaux choisis**.
 
@@ -335,7 +332,7 @@ de l'application**. Il faudra donc :
 * 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**.
+proviennent d'horizons et de formations variés**.
 
 ### Livrables {#livrables}
 
@@ -358,9 +355,13 @@ déploiement de l'application et de la génération des différents éléments
 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.
+dernière tout en gérant une **base de données**, le **stockage** et la 
+**sauvegarde**.
 
-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 
+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.
+
+Cela demande de suivre [le plan](#plan) à la lettre dans les **limites de 
+temps et de budget** définies : c'est un projet ambitieux.

content/50_specifications_techniques.md

@@ -11,8 +11,8 @@ outils utilisés.
 ## Étude de l'application
 
 Le dépôt Git contenant l'application **existait déjà**. Une étude des 
-composants fournis par le projet a donc été nécessaire. Ce qui a été fournis 
-aux développeurs également. Ce qui a permis d'en mesurer les implications.
+composants fournis a donc été nécessaire, ce qui a permis d'en mesurer les 
+implications.
 
 ### Composants de l'application
 
@@ -52,23 +52,28 @@ locale du **proxy Traefik** configuré pour utiliser Docker.
 Ces éléments sont un **bon point de départ pour l'équipe de DevOps** qui 
 prendra connaissance des particularités de cette application.
 
-### Points d'attentions
+### Points d'attention
 
-La **partie Frontend** permet de générer des fichiers dits « statiques », du 
-**serverless** est envisageable. L'application, bien que faisant des appels à 
-une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la 
-préparation pour un déploiement. Cependant **un nom de domaine est inscrit en 
-dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur 
-plusieurs domaines et environnements.
+La **partie Frontend** permet de générer des fichiers dits 
+« statiques », du **serverless** est envisageable. L'application, 
+bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce 
+qui, a priori, facilite la préparation pour un déploiement. Cependant les 
+développeurs de l'application utilisent **un nom de domaine inscrit en dur 
+dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur 
+plusieurs domaines et environnements. En effet, une fois l'image Docker 
+compilée, il sera impossible de changer le nom de domaine. Déployer une telle 
+image limite donc l'usage à un seul domaine. Si on souhaite déployer sur 
+plusieurs domaines (pour un environnement de pré-production et un 
+environnement de production par exemple), il faudra faire une image Docker par domaine !
 
 La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle 
 est donc **dépendante de la BDD**.
 
-La **partie proxy** utilise actuellement **Traefik comme outil**. Ce qui n'est 
-pas une obligation d'usage pour un déploiement en production.
+La **partie proxy** utilise actuellement **Traefik comme outil**.
 
 Ces trois parties ont une influence sur le choix de l'infrastructure à mettre 
-en place. Il reste cependant une **marge de manœuvre sur la partie proxy**.
+en place. Il reste cependant une **marge de manœuvre sur la partie proxy**. En 
+effet il n'est pas obligatoire d'utiliser Træfik en production.
 
 ## Infrastructure
 
@@ -104,12 +109,13 @@ Le schéma de la couche basse de l'infrastructure ressemble donc à :
 ![Schéma de la couche basse de 
 l'infrastructure](./media/schema_couche_basse.png){width=100%}
 
-C'est sur cette base qu'il est possible d'intégrer un environnement capable de 
-déployer, automatiser et gérer des applications conteneurisées.
-
 ### Environnement Kubernetes
 
-**Kubernetes** est un système capable de faire tourner des **applications 
+C'est sur la couche basse qu'il est possible d'ajouter un environnement 
+permettant d'intégrer, déployer, automatiser et gérer des applications 
+conteneurisées. Pour cela nous choisissons **Kubernetes**.
+
+Kubernetes est un système capable de faire tourner des **applications 
 conteneurisées**, d'**automatiser le déploiement** et de gérer la mise à 
 l'échelle (**auto-scaling**).
 
@@ -147,10 +153,10 @@ EKS](./media/schema_contenu_eks.png){width=100%}
 * le **backend** de l'application (FastAPI),
 * et le **frontend** de l'application (en fichiers statiques).
 
-Afin de permettre une livraison régulière de l'application, il va falloir 
-automatiser au maximum les étapes entre la publication d'une nouvelle version 
-de l'application et sa livraison. Puis son déploiement en production via une 
-intervention humaine.
+Afin de permettre une **livraison régulière** de l'application, il va falloir 
+**automatiser au maximum** les étapes entre la publication d'une nouvelle 
+version de l'application et son déploiement en production en passant par la 
+livraison en environnement de pré-production par une intervention humaine.
 
 ### Environnements
 
@@ -165,9 +171,10 @@ sur **chaque machine des développeurs** à l'aide des outils fournis
 (Dockerfile, docker-compose du projet applicatif),
 * l'environnement de **test** : il est composé de l'**ensemble des Runner 
 Gitlab** utilisés à l'intérieur de la chaîne d'intégration continue,
-* l'environnement de **pré-production** (appelé « **staging** ») : c'est 
-l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration 
-dite *plus légère* (moins de machines virtuelles EC2 par exemple),
+* l'environnement de **pré-production** (appelé « **staging** »
+) : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec 
+une configuration dite *plus légère* (moins de machines virtuelles EC2 par 
+exemple),
 * et l'environnement de **production** : c'est l'**infrastructure 
 finale** ; celle qui est disponible aux utilisateurs finaux (les usagers).
 
@@ -232,21 +239,23 @@ non-exhaustive :
 * les données brutes de l'application, stockées dans la **base de données 
 postgreSQL**,
 * les **données sensibles** (mots de passe, clés d'accès),
-* les **copies de sauvegardes** des données elle-même,
+* les **copies de sauvegardes** des données elles-mêmes,
 * et les **fichiers de journalisation** des services en production.
 
 Regardons pour chacun des points de cette liste où se situe le stockage.
 
 #### Stockage
 
-En reprenant les éléments précédent, nous avons : 
+Les éléments précédents donnent lieu au tableau suivant : 
 
-* des **dépôts Gitlab** pour notre code applicatif ET les dépôts de 
-l'infrastructure, gérés par Gitlab,
-* un **stockage AWS EBS** (Elastic Block Store) pour la base de données 
-postgreSQL,
-* et un **stockage AWS S3** (Simple Storage Service) pour les copies de 
-sauvegardes.
+: Données présentes et leur lieu de stockage
+
+Données | Stockage
+-----|-----
+Code applicatif | **dépôt Gitlab**
+Code de l'infrastructure | **dépôt Gitlab**
+Base de données postgreSQL | **stockage AWS EBS** (Elastic Block Store)
+Sauvegardes | **stockage AWS S3** (Simple Storage Service)
 
 Cela devrait être suffisant pour stocker les diverses données disponibles.
 
@@ -267,17 +276,17 @@ postgreSQL-HA](./media/postgresql-ha.png){height=50%}
 Les dépôts de version utilisés étant sur Gitlab, [service qui se targue d'être 
 entre 99% et 100% disponible](
 https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-availability)
-, une **sauvegarde dite « préventive » mensuelle** suffit.
+, une **sauvegarde dite « préventive » mensuelle** suffit.
 
 En revanche **la production**, même en **étant un service en haute 
 disponibilité**, doit fournir au moins **une sauvegarde 1 fois par jour**. 
 L'outil de sauvegarde choisi est **Velero**. Compatible avec l'environnement 
-Kubernetes et permettant aussi de sauver l'état du cluster à un moment donné. 
-Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les 
-restaurations de ces dernières.
+Kubernetes et permettant aussi de **sauver l'état du cluster** à un instant 
+*T*. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi 
+les restaurations de ces dernières.
 
 Comme énoncé précédemment, les sauvegardes du cluster seront mises **sur un 
-stockage AWS S3** (dit « bucket S3 »).
+stockage AWS S3** (dit « bucket S3 »).
 
 \newpage
 
@@ -291,8 +300,9 @@ Le fonctionnement de Velero dans ce projet est visible sur le schéma suivant.
 
 ### Supervision
 
-Le choix se porte sur **Datadog** pour sa **souplesse** et sa capacité à 
-proposer des **services supplémentaires de manière progressive**.
+Le choix de l'outil de supervision se porte sur **Datadog** pour sa 
+**souplesse** et sa capacité à proposer des **services supplémentaires de 
+manière progressive**.
 
 Le fonctionnement semble simple : installation d'agents Datadog dans le 
 système Kubernetes pour receuillir de nombreuses informations. Comme peut le 
@@ -303,18 +313,29 @@ montrer le schéma suivant.
 ![Schéma des agents Datadog dans notre système 
 Kubernetes](./media/schema_datadog.png){height=70%}
 
+Une fois installé, l'agent Datadog recueille et envoie les informations sur 
+les serveurs officiels de l'entreprise Datadog qui en gère le stockage et 
+l'accès.
+
 #### Surveillance (monitoring)
 
-Pour le monitoring, on veillera à suivre des **indicateurs simples** comme 
-l'**utilisation CPU** et la **mémoire vive** des instances AWS EC2 (Elastic 
-Compute Cloud) utilisées.
+L'utilisation de Datadog donne accès à de nombreux moniteurs pré-configurés.
+
+On veillera à utiliser des **indicateurs simples** comme l'**utilisation CPU** 
+et la **mémoire vive** des instances AWS EC2 (Elastic Compute Cloud) utilisées.
 
 Il y a également : 
 
 * le **nombre de pods utilisés** par l'instance EC2,
-* et la **disponibilité du service** de l'application API-Utilisateurs.
+* et la **disponibilité du service** de l'application *API Utilisateurs*.
 
-Cependant ces moniteurs doivent s'agrémenter d'**alertes**.
+Cependant ces moniteurs sont insuffisants. On pourrait ajouter : 
+
+* le temps de réponse de l'API,
+* le nombre de requêtes par seconde sur l'API,
+* même chose pour le nombre de requêtes sur la base de données,
+* le nombre d'erreurs 500 retournées par le frontend et le backend,
+* etc.
 
 #### Alertes
 
@@ -328,21 +349,36 @@ utilisons donc le [**Gitlab ChatOps**](https://docs.gitlab.com/ci/chatops/).
 
 En suivant toutes ces indications, nous devrions avoir une base stable et 
 saine pour constuire une supervision correcte de l'application 
-API-Utilisateurs.
+*API Utilisateurs*.
 
 ### Sécurité
 
-Au niveau de la sécurité, **vaste sujet**, nous partirons de peu 
-d'éléments : 
+Au niveau de la sécurité, **vaste sujet**, nous partirons de ces 
+éléments : 
 
 * lancement de **tests** sur le **code applicatif**,
-* lancement de **tests SAST** (Static application security testing), sur Terraform notamment,
-* et utilisation d'un **coffre fort numérique** pour les mots de passes et clés d'accès en tous genres.
+* lancement de **tests SAST** (Static application security testing), sur 
+Terraform notamment,
+* et utilisation d'un **coffre fort numérique** pour les mots de passes et 
+clés d'accès en tous genres.
 
 Le coffre-fort choisi est **Vaultwarden**.
 
-Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un **processus continu** à faire tout au long du **suivi et la maintenance du projet**.
+Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un 
+**processus continu** à faire tout au long du **suivi et la maintenance du 
+projet**.
 
 ## Conclusion
 
-Les spécifications techniques étant établies, nous allons pouvoir nous concentrer sur la démarche suivie pour mettre en place le projet. C'est à dire comment nous allons atteindre les objectifs du cahier des charges à l'aide des solutions choisies ici-même.
+Les spécifications techniques décrivent bien l'application, composée de 3 
+éléments (backend, frontend et base de données) qui s'intégreront bien dans 
+l'environnement Kubernetes installé sur l'infrastructure posée dans le cloud 
+AWS.
+
+On retient ainsi un déploiement automatique dans le Cloud d'une infrastructure 
+prête à accueillir à la fois l'application et d'autres services tierces comme 
+la supervision avec Datadog et les sauvegardes à l'aide de Velero.
+
+La sécurité aura cette spécificité de devoir être régulièrement vérifiée, 
+maintenue et améliorée au fil du temps. C'est donc un processus continu dont 
+la réussite dépend beaucoup de la discipline et la régularité.

content/60_demarche.md

@@ -1,5 +1,3 @@
-\newpage
-
 # Démarche suivie {#demarche}
 
 La réalisation de ce projet va plus loin que la simple mise en place d'une 
@@ -7,7 +5,7 @@ application dans le Cloud. C'est une **nouvelle équipe**, dans un **nouvel
 environnement** avec une application inconnue et **des savoirs à acquérir**.
 
 En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre
-en place. Nous allons donc avant tout parler de **méthodologie utilisées** 
+en place. Nous allons donc avant tout parler des **méthodologies utilisées** 
 pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de 
 **collaborations** avec d'autres équipes.
 
@@ -15,14 +13,14 @@ pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
 
 ### Agile
 
-Le choix d'une **méthodologie agile** « basique » s'est offerte à nous, 
+Le choix d'une **méthodologie agile** « basique » s'est offerte à nous, 
 notamment par : 
 
 * des **comptes-rendus journaliers rapides de 10mn** en respectant les points 
 suivants : 
-  * ce que j'ai fais hier,
-  * ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
-  * ce que je compte faire aujourd'hui,
+  * « *ce que j'ai fait hier* »,
+  * « *ai-je rencontré un/des problème(s) qui vaut(valent) d'être cité(s)* »,
+  * « *ce que je compte faire aujourd'hui* »,
 * la **création de jalons** avec un ensemble de tâches sur une période d'une 
 semaine,
 * des échanges réguliers en **pair-programming** sur des sujets difficiles 
@@ -30,9 +28,6 @@ semaine,
 * et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de 
 production en flux tendus).
 
-C'est ainsi que les **jalons** ont parsemés la durée du projet en **objectifs à 
-atteindre**.
-
 ### Jalons
 
 Les **jalons** (milestones en anglais) permettent de savoir si le projet 
@@ -46,13 +41,12 @@ wiki, etc.), **cahier des charges**,
 * Étape 5 (avec 4) : **Supervision** (observabilité, alertes),
 * Étape 6 : **extras** (s'il reste du temps).
 
-Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en 
-compte.
-
 ### Choix de standards et normes
 
-Plusieurs standards/normes ont été choisies pour **rassembler plutôt que 
-diviser le groupe** : SemVer, Git OneFlow et Conventional commit.
+Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en 
+compte ; des standards/normes ont été choisies pour **rassembler plutôt 
+que diviser le groupe** : c'est là que SemVer, Git OneFlow et 
+Conventional commit entrent en jeu.
 
 #### SemVer
 
@@ -142,7 +136,7 @@ l'exemple montre une référence vers le ticket #18 du dépôt nommé *projet*.
 
 ## Outils
 
-Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés 
+Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisé 
 des outils afférents.
 
 ### Nom de domaine
@@ -153,8 +147,8 @@ location d'un nom de domaine : **devu42.fr**.
 
 Ce domaine fait référence à notre cursus de DevOps dans un centre de formation 
 nommé **DevU**niversity. Le **nombre 42** est un chiffre connu lié aux 
-ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du 
-Voyageur Galactique ».
+ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide
+du Voyageur Galactique ».
 
 Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour : 
 
@@ -197,7 +191,7 @@ fait donc un outil de choix pour notre projet.
 
 \newpage
 
-#### Base de connaissance
+#### Base de connaissances
 
 Une des premières choses qui a été faite sur cette plateforme a été la **mise 
 en place d'une base de connaissances** sous la forme d'un Wiki.
@@ -233,8 +227,8 @@ d'appliquer à nouveau le même workflow.
 ## Cas d'une collaboration inter-équipe {#collab}
 
 Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec 
-l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement 
-de serveurs Matrix en haute disponibilité.
+l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le 
+déploiement de serveurs Matrix en haute disponibilité.
 
 Nous avons échangé sur le **sujet de la promotion des versions entre 
 environnements**. Maxime, de la Team Matrix, et moi avons principalement 
@@ -248,8 +242,9 @@ https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-rele
 L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un 
 dossier par environnement** plutôt qu'utiliser une branche Git pour chaque 
 environnement. Il conseille également de faire la promotion des versions entre 
-ces différents environnements/dossiers. Avec un protocole à suivre par les « 
-humains » pour limiter de trop nombreuses promotions logicielles en même temps.
+ces différents environnements/dossiers. Avec un protocole à suivre par les 
+« humains » pour limiter de trop nombreuses promotions logicielles 
+en même temps.
 
 Pour reprendre le schéma de l'article : 
 
@@ -257,7 +252,7 @@ Pour reprendre le schéma de l'article :
 versions](./media/article_schema_promotion.png){width=100%}
 
 Après moultes discussions, **nous sommes tombés d'accord** sur quelques 
-points, parmi : 
+points, notamment : 
 
 * **ne pas utiliser une branche par environnement**,
 * essayer au maximum d'**avoir des dépôts indépendants** (favoriser la 
@@ -279,9 +274,9 @@ de sécurité**, des **tests du code**, vérification de la **couverture de
 code** et **tests sur la compilation** - éventuelle - de l'outil et/ou des 
 **images Docker** puis **publication sur un registre**,
 * avoir une gestion de chacun de ces dépôts d'**un système de versionnement** 
-(les fameuses « releases »),
+(les fameuses « releases »),
 * avoir la **même chose pour chaque module Terraform** que nous avons fabriqué 
-(par exemple notre module « networking »),
+(par exemple notre module « networking »),
 * puis utiliser, dans un dépôt **infra** par exemple, seulement les versions 
 de nos modules (situés indépendamment sur des registres),
 * de là on peut imaginer : 
@@ -293,12 +288,11 @@ de nos modules (situés indépendamment sur des registres),
 * ajouter des **tests de sécurité des images** (comme la somme de contrôle) avant 
 utilisation dans d'autres dépôts.
 
-À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà 
-2 types de promotions dans tout cela : 
+Maxime et moi avons également relevé que lorsqu'on parle de promotions dans 
+l'infrastructure on peut imaginer 2 types de promotions : 
 
-* la promotion des versions des logiciels/modules/charts utilisés,
-* et la promotion des configurations de ces derniers au sein de nos 
-infrastructures.
+* la promotion de versions concernant les logiciels/modules/charts utilisés,
+* et la promotion de configurations pour différentes infrastructures.
 
 C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
 

content/70_realisations.md

@@ -79,12 +79,11 @@ pourquoi ne pas **utiliser Git lui-même à l'aide d'un commit sur le dépôt
 suivant** ? Ainsi, sans outils supplémentaires, nous pouvons lier les 
 dépôts entre eux.
 
+En suivant cette logique, nous obtenons le schéma représentant la pipeline de 
+chaque dépôt : 
+
 ```{=latex}
 \begin{sidewaysfigure}
-
-En suivant cette logique, nous obtenons le schéma représentant la pipeline de 
-chaque dépôt~: 
-
    \includegraphics{./media/schema_3_pipelines.png}
 \caption{Schéma des 3 pipelines}
 \end{sidewaysfigure}
@@ -137,7 +136,7 @@ inform-charts:
 **Le code a dû être modifié (raccourcissement des lignes) pour les fins de 
 rédaction du présent document**.
 
-La **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant 
+Les **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant 
 simplement à jour les versions utilisées du backend et du frontend dans les 
 charts Helm sur le registre Gitlab.
 
@@ -190,8 +189,6 @@ dépôt initial (celui de l'application par exemple). Et cela **laisse la
 responsabilité aux personnes suivantes** (qui utilisent le dépôt initial) plutôt 
 qu'aux personnes qui s'occupent du code dans le dépôt initial.
 
-\newpage
-
 ## Réalisation 2 : États Terraform
 
 ### Contexte
@@ -275,8 +272,6 @@ commandes make et qu'ils vérifient l'existence et le contenu du fichier
 
 S'ajoute à cela une **documentation dans le fichier README.md**.
 
-\newpage
-
 Exemple de script avec **make init** pour bien comprendre de quoi il est 
 question : 
 
@@ -307,6 +302,8 @@ terraform init \
   -backend-config=${BACKEND_HTTP_FILE} $@
 ```
 
+\newpage
+
 Et le contenu du fichier **env.example**, partagé aux développeurs comme d'un 
 template pour fabriquer le fichier **.env** : 
 
@@ -376,6 +373,13 @@ Deux expériences variées et différentes qui s'imbriquent pourtant dans le
 processus de production logicielle et de livraison continue. Il y a beaucoup 
 de choses à dire sur chacun des sujets, tellement ils sont passionnants. Ils 
 amènent également à prendre des initiatives et tester localement des outils. 
-Nous parlerons d'ailleurs dans le prochain chapitre d'une situation de travail 
-ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détail le 
-processus de travail suivi afin d'aboutir à ce résultat.
+
+Ces expériences ont aussi permi d'acquérir de nouvelles compétences 
+primordiales dans le domaine du DevOps. La prise de recul sur ces éléments 
+met en évidence des failles dans le schéma de pensée. Il y a donc des points 
+à améliorer et une évolution possible dans les tâches présentées.
+
+Je pense aussi que de nouvelles expériences seraient enrichissantes pour 
+comparaison avec celles présentées ici afin d'estimer les pour et les contre 
+de différentes solutions. Cela permettrait de s'adapter aux situations avec 
+des outils adéquats.

content/80_conclusion.md

@@ -1,23 +0,0 @@
-\newpage
-
-# Conclusion
-
-Ma **passion anticipée pour l'automatisation** et l'**amélioration des 
-processus** de **création logiciel** m'ont amené à ce moment, aujourd'hui, où 
-j'écris ces lignes pour **embrasser le métier d'Administrateur Système 
-DevOps**. La formation, puis **le projet de fin de formation** ont été 
-**bénéfique à la prise d'expérience**, mais pas que.
-
-En effet, **il est question de nouvelles compétences**, que le projet, à 
-travers la rédaction d'un cahier des charges, de spécifications 
-fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et 
-de situations diverses, a permis d'**acquérir tout au long de ces derniers 
-mois**.
-
-Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**, 
-de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans 
-cesse grandissant qu'est **le monde du DevOps**.
-
-Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur 
-la voie du DevOps et de l'enrichissement par de nouvelles connaissances et 
-perspéctives professionnelles d'avenir !

content/80_situation_de_travail.md

@@ -3,14 +3,14 @@
 # Situation de travail
 
 L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé, 
-je cite, « **une description d'une situation de travail ayant nécessité une 
-recherche effectuée par le candidat durant le projet** ».
+je cite, « **une description d'une situation de travail ayant nécessité 
+une recherche effectuée par le candidat durant le projet** ».
 
-Pour bien saisir **ma façon de travailler**, je pense qu'il est nécessaire de 
+Pour saisir **la méthodologie choisie**, je pense qu'il est nécessaire de 
 décrire une situation complète. Nous allons poser le contexte, faire l'état 
-des lieux puis suivre le cheminement parcouru pour atteindre l'objectif.
+des lieux puis suivre la démarche pour atteindre l'objectif.
 
-## Contexte
+## Contexte et état des lieux
 
 Du projet émane un besoin d'**avoir du temps de calcul pour les pipelines**.
 
@@ -22,8 +22,6 @@ utilisons Gitlab**, ce sont donc des Gitlab Runner que nous visons.
 Où les installer ? Comment ? **De quelles ressources 
 disposons-nous ?**
 
-## État des lieux
-
 **Nous utilisons Gitlab** qui propose, dans sa version gratuite, une **limite 
 de temps de calcul**. Une fois le seuil atteint : il faut trouver une 
 solution alternative aux **machines de Gitlab, payantes**.
@@ -41,7 +39,7 @@ et un **environnement Kubernetes** pour **déployer des Gitlab Runner**.
 
 Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulièrement.
 
-## Cheminement
+## Démarche
 
 ### Retranscription préalable
 
@@ -77,14 +75,14 @@ Et c'est ce que j'ai fait :
 
 * **demande à un ami DevSecOps** si je pouvais l'interpeller de temps en temps 
 sur l'un ou l'autre sujet,
-* achat du **livre « Kubernetes - Guide pratique »** aux éditions 
+* achat du **livre « Kubernetes - Guide pratique »** aux éditions 
 \textsc{O'Reilly},
 * recherche, infructueuse, **à la médiathèque** : le rayon informatique 
 est maigre,
 * recherche sur le domaine du DevOps **sur Internet** avec une **grande 
-lecture initiale** de [**Stéphane Robert** (Devenez expert DevOps et maîtrisez 
-ses outils)](https://blog.stephane-robert.info/){#stephane-robert} (j'ai 
-repris le titre du site tel quel).
+lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et 
+maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert} 
+(j'ai repris le titre du site tel quel).
 
 ![Première de couverture du livre O'Reilly, Kubernetes - Guide 
 pratique](./media/livre-oreilly.jpg){height=35%}
@@ -94,9 +92,10 @@ pratique](./media/livre-oreilly.jpg){height=35%}
 ### Point de départ
 
 Grâce à la lecture de quantité d'articles sur le blog de [Stéphane 
-Robert](#stephane-robert), notamment la [série d'article sur « Mon nouveau 
-Homelab DevOps](https://blog.stephane-robert.info/docs/homelab/introduction/) 
-(Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la 
+\textsc{Robert}](#stephane-robert), notamment la [série d'article sur 
+« Mon nouveau Homelab DevOps »](
+https://blog.stephane-robert.info/docs/homelab/introduction/) (Cf. 
+https://blog.stephane-robert.info/docs/homelab/introduction/) et la 
 **Roadmap de son parcours de formation DevSecOps** (Cf. 
 https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des 
 **objectifs à court terme** et des étapes de sujets à aborder comme : 
@@ -104,8 +103,8 @@ https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
 * le **sujet de la virtualisation**,
 * **le GitOps avec** un outil tel que **FluxCD**.
 
-![Apparence de la page d'accueil du blog de Stéphane 
-Robert](./media/screenshot_stephane-robert.png){width=100%}
+![Copie d'écran de la page d'accueil du blog de Stéphane 
+\textsc{Robert}](./media/screenshot_stephane-robert.png){width=100%}
 
 ### Recherches
 
@@ -115,9 +114,11 @@ Je pars souvent de **sites de référence ou de sites que j'ai déjà utilisé**
 plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu 
 à **quelques recherches sur des sites déjà connus** : 
 
-* Le **wiki d'ArchLinux** et sa catégorie « **Virtualization** » : 
+* Le **wiki d'ArchLinux** et sa catégorie 
+« **Virtualization** » : \
 https://wiki.archlinux.org/title/Category:Virtualization,
-* Le blog précédemment cité de [**Stéphane Robert**](#stephane-robert).
+* Le blog précédemment cité de [**Stéphane 
+\textsc{Robert}**](#stephane-robert).
 
 Je me suis concentré sur l'outil conseillé par **mon contact DevSecOps** qui 
 utilise QEMU/KVM/Libvirt pour l'émulation d'une machine complète. J'ai lu et 
@@ -143,8 +144,9 @@ https://odtre.gitlab.io/doc/virtualisation/.
 plusieurs systèmes d'exploitation** avant de les adopter et les déployer sur 
 notre infrastructure.
 
-![Section « Documentation » du site statique odtre.gitlab.io généré sur 
-Gitlab](./media/screenshot_odtre_doc.png){width=100%}
+![Copie d'écran de la section « Documentation » du site statique 
+odtre.gitlab.io généré sur Gitlab](
+./media/screenshot_odtre_doc_shadow.png){width=100%}
 
 \newpage
 
@@ -158,8 +160,9 @@ nécessaires** pour déployer et utiliser **FluxCD** :
 
 * la **page d'installation officielle**, Cf. 
 https://fluxcd.io/flux/installation/,
-* les différents « **bootstrap** » possibles en fonction d'un **fournisseur de 
-dépôt Git** choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
+* les différents « **bootstrap** » possibles en fonction d'un 
+**fournisseur de dépôt Git** choisi, Cf. 
+https://fluxcd.io/flux/installation/bootstrap/,
 * et des **explications sur le contrôleur de sources**, \
 Cf. https://fluxcd.io/flux/installation/bootstrap/ pour se mettre à jour 
 «  tout seul ».
@@ -167,7 +170,7 @@ Cf. https://fluxcd.io/flux/installation/bootstrap/ pour se mettre à jour
 Comme auparavant, ceci a donné lieu à **la rédaction d'un article sur notre 
 outil de retranscription**, Cf. https://odtre.gitlab.io/doc/fluxcd/.
 
-![Documentation de FluxCD sur le site 
+![Copie d'écran de la documentation de FluxCD sur le site 
 officiel](./media/screenshot_fluxcd-doc.png){width=100%}
 
 ## Conclusion
@@ -178,3 +181,15 @@ Bien que pour la plupart des outils, une fois choisis, la documentation
 officielle de ces outils semble suffire pour leur installation et leur 
 utilisation. Les **bonnes pratiques** restent **dans les articles des 
 blogueurs** et autres joyeux rédacteurs en tous genres.
+
+Le blog de [Stéphane \textsc{Robert}](#stephane-robert) est un bon point de 
+départ qui ne dispense absolument pas de recherches supplémentaires. Des 
+outils tels que QEMU/KVM/libvirt pour la virtualisation sont de bonnes idées 
+pour tester les outils de DevOps dans un environnement isolé. Tout comme 
+FluxCD qui permet d'automatiser, à l'intérieur d'un environnement Kubernetes, 
+la recherche de nouvelles versions de ses applications.
+
+La méthodologie ayant été fructueuse, elle sera dans mes priorités pour les 
+années à venir. Il faudra cependant être attentif au temps passé à la 
+publication de ses recherches qui, bien qu'il soit un investissement sur long 
+terme, consomme un temps certain à la rédaction et la mise en page.

content/90_conclusion.md

@@ -0,0 +1,33 @@
+# Conclusion
+
+Ma **passion anticipée pour l'automatisation** et l'**amélioration des 
+processus** de **création logiciel** m'ont amené à ce moment où j'écris ces 
+lignes pour **embrasser le métier d'Administrateur Système DevOps**. La 
+formation, puis **le projet de fin de formation** ont été 
+**bénéfiques à la prise d'expérience**, mais pas que.
+
+En effet, **il est question de nouvelles compétences**, que le projet, à 
+travers la rédaction d'un cahier des charges, de spécifications 
+fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et 
+de situations diverses, a permis d'**acquérir tout au long de ces derniers 
+mois**.
+
+La découverte de nombreux outils comme Kubernetes, Terraform, FluxCD, Datadog, 
+externaldns, cert-manager, QEMU/KVM, libvirt, etc. a été riche et variée. Il 
+est possible **d'approfondir plus encore** sur ces derniers et de les essayer 
+dans **d'autres environnements de cloud** comme *Microsoft Azure* ou *Google 
+Cloud Platform*.
+
+Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**, 
+de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans 
+cesse grandissant qu'est **le monde du DevOps**. C'est aussi et surtout une 
+culture qui amène à de **bonnes pratiques**, une **amélioration constante** et 
+la découverte infinie de projets en tous genres.
+
+Ce projet, bien qu'ambitieux au départ, semble désormais une approche basique 
+à reprendre lors de futurs projets. Il faudra alors améliorer la gestion 
+d'équipe, une planification plus réactive et la prise en compte de plus de 
+facteurs comme l'apprentissage de nouvelles technologies, les retards et le 
+temps accordé à chaque étape. D'autres outils, plus adaptés, pourront 
+également mieux se greffer à de nouveaux projets pour en faciliter la 
+finalisation.