fix(content): syntax, language, etc. after comments

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

content/05_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,29 @@ 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/08_remerciements.md

@@ -2,14 +2,7 @@
 
 # Remerciements
 
-Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été 
+À **Madame Agnès \textsc{Schweitzer}** pour ses **conseils**, son aide 
-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ésence 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 !
 
@@ -20,23 +13,12 @@ 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 
+Je remercie particulièrement les personnes suivantes pour leur **écoute**, 
-organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision 
+leur **professionnalisme** et leur souci de réponses claires : 
-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 
+* Sarah \textsc{Bouras},
-en répondant **consciencieusement** à toutes mes questions ; même les plus 
+* Benjamin \textsc{Fiche},
-triviales/simplettes/absurdes. Il a toujours fait preuve d'**un 
+* et Jérémie \textsc{Tarot}.
-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, 
@@ -46,52 +28,31 @@ les examens et les machines virtuelles fournies.
 
 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.
+la formation. Et pourtant ils ont donné ce qu'ils pouvaient.
 
-Pris à part, nous avons **chacun nos particularités**. Ensemble ces problèmes 
+Merci à : 
-étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons 
-fait. Et rien que pour cela je remercie l'équipe d'y être parvenu.
 
-À Eliel \textsc{Moncada} pour ses **trouvailles** Web et sa **patience** sur 
+* Hrubech \textsc{Hombessa},
-les schémas visuels qui prennent un temps considérable !
+* Eliel \textsc{Moncada},
-
+* et Julien \textsc{Sabiols}.
-À 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 
+de vie**. Vous méritez de figurer dans ces lignes et d'avoir un grand 
-formation. Pour ces personnes **cachées dans l'ombre** : MERCI ! 
+MERCI !
-Vous méritez de figurer dans ces lignes.
 
-## Aux membres de la « cohorte »
+## 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.
+des difficultés ou encore des solutions, à ceux qui étaient eux-mêmes.
 
-Une mention particulière aux personnes suivantes (ordre alphabétique - 
+Une mention particulière aux personnes suivantes :
-prénom) :
 
-* à Dorian \textsc{Roly} pour nos **échanges intéressants** sur de multiples 
+* à Maxime \textsc{Boulanghien},
-technologies et sur les archétypes des personnes dans l'informatique,
+* à Michael \textsc{Lachand},
-* à Maxime \textsc{Boulanghien} pour sa **sérénité**, son **implication** et 
+* à Philippe \textsc{Risser-Maroix},
-son efficacité sur des sujets dûments travaillés ; notamment la promotion 
+* et à Dorian \textsc{Roly}.
-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
 
@@ -100,6 +61,5 @@ 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 
+À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et 
-ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à 
+fautes d'orthographes découvertes dans ce document.
-toutes celles et ceux dont j'aurais omis le nom/prénom.

content/10_liste_competences.md

@@ -1,22 +1,20 @@
-\newpage
-
 # Liste de compétences couvertes par le projet
 
 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 
@@ -26,7 +24,8 @@ DevOps* liste 11 compétences réparties en 3 catégories :
   éventuellement en anglais**
 
 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 +34,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 +48,9 @@ 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.

content/20_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,7 +142,7 @@ 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.
 
 Pour bien saisir l'état des lieux de ladite application, regardons de plus 
@@ -156,7 +155,7 @@ 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).
@@ -176,20 +175,20 @@ Mais **le projet voit plus loin**.
 
 En dehors des objectifs à atteindre, le projet 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 : 
+Ce projet à plusieurs objectifs : 
 
 * 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 +197,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 +207,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.
 
@@ -218,17 +217,18 @@ primordiaux.
 
 ## Planification
 
-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 +257,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 +276,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 +303,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 +316,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 +335,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}
 
@@ -360,7 +360,7 @@ Le projet **couvre beaucoup de situations** et **domaines** autour de
 application avec une **supervision** et une **mise à l'échelle** de cette 
 dernière.
 
-En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la 
+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.

content/30_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 
@@ -165,9 +166,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 +234,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,7 +271,7 @@ 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**. 
@@ -277,7 +281,7 @@ 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
 

content/40_demarche.md

@@ -7,7 +7,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 +15,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,
@@ -142,7 +142,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 +153,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 +233,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 +248,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 +258,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 +280,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 +294,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/50_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.
 
@@ -377,5 +376,5 @@ 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 
+ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détails le 
 processus de travail suivi afin d'aboutir à ce résultat.

content/60_situation_de_travail.md

@@ -3,8 +3,8 @@
 # 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é une 
-recherche effectuée par le candidat durant le projet** ».
+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 
 décrire une situation complète. Nous allons poser le contexte, faire l'état 
@@ -77,14 +77,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 +94,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 : 
@@ -105,7 +106,7 @@ https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
 * **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%}
+\textsc{Robert}](./media/screenshot_stephane-robert.png){width=100%}
 
 ### Recherches
 
@@ -115,9 +116,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,7 +146,7 @@ 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 
+![Section « Documentation » du site statique odtre.gitlab.io généré sur 
 Gitlab](./media/screenshot_odtre_doc.png){width=100%}
 
 \newpage
@@ -158,7 +161,7 @@ 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 **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 

content/80_conclusion.md

@@ -6,7 +6,7 @@ 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.
+**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