release: v1.2 - 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.2
 mentor: Jérémie \textsc{Tarot}
 qrcode: https://odtre.gitlab.io/diapos/
 geometry:

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

@@ -6,16 +6,16 @@ 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
+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érations. Mais également de favoriser un **flux
+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 
+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
+été sensibilisé aux besoins incessants de l'automatisation et de l'amélioration
- des processus de création logiciel. J'ai participé à la mise en place 
+ 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 
@@ -27,9 +27,27 @@ 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, 
+Nous continuerons en expliquant 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.
+**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
+* Automatiser le déploiement d'une infrastructure dans le cloud
-  * Compétence **n°1 : Automatiser la création de serveurs à l’aide de 
+  * 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°3 : Sécuriser l'infrastructure**
-  * Compétence **n°4 : Mettre l’infrastructure en production dans le 
+  * 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 
+services) n'a pu être clairement établie **faute d'interlocuteur autre que le 
-autre interlocuteur que le « mentor »**.
+« 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 
+mis en place dans la solution.
-cette compétence.
+
+## 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 
 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 
+Plusieurs élèves se regroupent autour d'un projet pour lequel ils ont un 
-commun**.
+**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 \textsc{Hombessa}**,
-* **Hrubech HOMBESSA**
+* **Eliel \textsc{Moncada}**,
-* **Julien SABIOLS**
+* **Julien \textsc{Sabiols}**,
-* Olivier DOSSMANN
+* 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 
+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 
+dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il 
-présent document.
+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'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** : 
 
-* **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 API Utilisateurs** (nom de code FastAPI-Træfik) est fournie 
-
+avec les éléments principaux suivants : 
-L'**application 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 
+Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan 
-semaines de travail à venir et une liste de livrables attendus. Nous avons 
+d'action pour les 7 semaines de travail à venir ainsi qu'une liste de 
-adapté ce plan d'action pour nous correspondre.
+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** 
+C'est un sujet bien à part. D'où la possibilité de **faire cette étape en 
-d'un autre.
+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 
+En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la 
-pratique** » proposé par [DataScientest](#datascientest) et couvrir un maximum 
+pratique** » proposé par [DataScientest](#datascientest) et couvrir un 
-de compétences demandées pour le *Titre Professionnel d'Administrateur 
+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 
+composants fournis a donc été nécessaire, ce qui a permis d'en mesurer les 
-aux développeurs également. Ce qui a permis d'en mesurer les implications.
+implications.
 
 ### Composants de l'application
 
@@ -54,11 +54,12 @@ prendra connaissance des particularités de cette application.
 
 ### Points d'attentions
 
-La **partie Frontend** permet de générer des fichiers dits « statiques », du 
+La **partie Frontend** permet de générer des fichiers dits 
-**serverless** est envisageable. L'application, bien que faisant des appels à 
+« statiques », du **serverless** est envisageable. L'application, 
-une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la 
+bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce 
-préparation pour un déploiement. Cependant **un nom de domaine est inscrit en 
+qui, a priori, facilite la préparation pour un déploiement. Cependant les 
-dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur 
+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.
 
 La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle 
@@ -68,7 +69,8 @@ La **partie proxy** utilise actuellement **Traefik comme outil**. Ce qui n'est
 pas une obligation d'usage pour un déploiement en production.
 
 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 +106,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 +150,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 
+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 
+**automatiser au maximum** les étapes entre la publication d'une nouvelle 
-de l'application et sa livraison. Puis son déploiement en production via une 
+version de l'application et son déploiement en production en passant par la 
-intervention humaine.
+livraison en environnement de pré-production par une intervention humaine.
 
 ### Environnements
 
@@ -165,9 +168,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'environnement de **pré-production** (appelé « **staging** »
-l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration 
+) : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec 
-dite *plus légère* (moins de machines virtuelles EC2 par exemple),
+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 +236,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 
+: Données présentes et leur lieu de stockage
-l'infrastructure, gérés par Gitlab,
+
-* un **stockage AWS EBS** (Elastic Block Store) pour la base de données 
+Données | Stockage
-postgreSQL,
+-----|-----
-* et un **stockage AWS S3** (Simple Storage Service) pour les copies de 
+Code applicatif | **dépôt Gitlab**
-sauvegardes.
+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 +273,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é. 
+Kubernetes et permettant aussi de **sauver l'état du cluster** à un instant 
-Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les 
+*T*. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi 
-restaurations de ces dernières.
+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 +297,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é à 
+Le choix de l'outil de supervision se porte sur **Datadog** pour sa 
-proposer des **services supplémentaires de manière progressive**.
+**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 +310,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 de Datadog donne accès à de nombreux moniteurs pré-configurés.
-l'**utilisation CPU** et la **mémoire vive** des instances AWS EC2 (Elastic 
+
-Compute Cloud) utilisées.
+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 +346,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 
+Au niveau de la sécurité, **vaste sujet**, nous partirons de ces 
-d'éléments : 
+éléments : 
 
 * lancement de **tests** sur le **code applicatif**,
-* lancement de **tests SAST** (Static application security testing), sur Terraform notamment,
+* lancement de **tests SAST** (Static application security testing), sur 
-* et utilisation d'un **coffre fort numérique** pour les mots de passes et clés d'accès en tous genres.
+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,13 +13,13 @@ 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,
+  * ce que j'ai fait hier,
-  * ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
+  * 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,
@@ -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 
+Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en 
-diviser le groupe** : SemVer, Git OneFlow et Conventional commit.
+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 
+ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide
-Voyageur Galactique ».
+du Voyageur Galactique ».
 
 Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour : 
 
@@ -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 
+l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le 
-de serveurs Matrix en haute disponibilité.
+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 « 
+ces différents environnements/dossiers. Avec un protocole à suivre par les 
-humains » pour limiter de trop nombreuses promotions logicielles en même temps.
+« 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à 
+Maxime et moi avons également relevé que lorsqu'on parle de promotions dans 
-2 types de promotions dans tout cela : 
+l'infrastructure on peut imaginer 2 types de promotions : 
 
-* la promotion des versions des logiciels/modules/charts utilisés,
+* la promotion de versions concernant les logiciels/modules/charts utilisés,
-* et la promotion des configurations de ces derniers au sein de nos 
+* et la promotion de configurations pour différentes infrastructures.
-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 
+Ces expériences ont aussi permi d'acquérir de nouvelles compétences 
-processus de travail suivi afin d'aboutir à ce résultat.
+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 
+je cite, « **une description d'une situation de travail ayant nécessité 
-recherche effectuée par le candidat durant le projet** ».
+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 
+lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et 
-ses outils)](https://blog.stephane-robert.info/){#stephane-robert} (j'ai 
+maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert} 
-repris le titre du site tel quel).
+(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 
+\textsc{Robert}](#stephane-robert), notamment la [série d'article sur 
-Homelab DevOps](https://blog.stephane-robert.info/docs/homelab/introduction/) 
+« Mon nouveau Homelab DevOps »](
-(Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la 
+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 
+![Copie d'écran de la page d'accueil du blog de Stéphane 
-Robert](./media/screenshot_stephane-robert.png){width=100%}
+\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 
+![Copie d'écran de la section « Documentation » du site statique 
-Gitlab](./media/screenshot_odtre_doc.png){width=100%}
+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 
+* les différents « **bootstrap** » possibles en fonction d'un 
-dépôt Git** choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
+**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.