🧐 correction des fautes du dossier guide 🦺

docs/guide/best-practices.md

@@ -4,33 +4,33 @@
 
 Une application Cloud π Native doit respecter les [Twelve-Factor](https://12factor.net/fr/)
 
-D'autres bonnes pratiques à réspecter impérantivement:
+D'autres bonnes pratiques à respecter impérativement :
 
 1. Base de code
 
-    Le code de l'application et de déploiement doit etre **versionné** dans un dépôt de source de type **Git** (Public/Privée) **accessible depuis internet**.
+    Le code de l'application et de l'infrastructure doit être **versionné** dans un dépôt de source de type **Git** (Public/Privée) **accessible depuis internet**.
 
 2. Dépendances
 
-    __TOUTES__ dépendances necessaires à la constuction de l'application (Libraries,Images, ...) doivent provenir des dépôts de librairies connus tels que Maven, Composer et Node. Il est aussi possible de construire les dépendences par l'offre Cloud π Native et les déposer dans son gestionnaire d'artefact.
+    __TOUTES__ dépendances nécessaires à la construction de l'application (Libraries,Images, ...) doivent provenir des dépôts de librairies connues tels que Maven, Composer et Node. Il est aussi possible de construire les dépendances par l'offre Cloud π Native et les déposer dans son gestionnaire d'artefact.
 
 3. Configuration / Service Externe
 
-    __TOUTES__ la configuration applicative pouvant être amenée a être modifié, par exemple la configuration entre deux environnements applicatifs est la plus part du temps différente. Elle doit donc être injectée par des variables d'environnement au runtime ou via un fichier de configuration dynamique via une ConfigMap
+    __TOUTES__ la configuration applicative pouvant être amenée à être modifié, par exemple la configuration entre deux environnements applicatifs la plupart du temps différente. Elle doit donc être injectée par des variables d'environnement au runtime ou via un fichier de configuration dynamique via une ConfigMap
 
 4. Port
 
-    Afin de respecter les préconisation de sécurité, les applications déployées doivent écouter sur des ports > 1024.
+    Afin de respecter les préconisations de sécurité, les applications déployées doivent écouter sur des ports > 1024.
 
 6. Logs
 
-    L'application __NE DOIT PAS__ écrire dans un fichier de logs spécifique mais écrire l'ensemble de ces logs dans la sortie standards (stdout) au format GELF ou à defaut JSON.
+    L'application __NE DOIT PAS__ écrire dans un fichier de logs spécifique, mais écrire l'ensemble de ces logs dans la sortie standards (stdout) au format GELF ou à défaut JSON.
 
     Les logs seront accessibles plus facilement de cette manière depuis les outils de supervisions.
 
 7. Processus
 
-    Les applications doivent être __STATELESS__, si des données de session/cache doivent être utilisé et partagé par l'application alors elles doivent faire l'objet d'un service externe prévus à cet effet telsque Redis.
+    Les applications doivent être __STATELESS__, si des données de session/cache doivent être utilisés et partagé par l'application alors elles doivent faire l'objet d'un service externe prévus à cet effet tel que Redis.
 
 8. Processus d’administration
 
@@ -42,22 +42,22 @@ L'ensemble de ces bonnes pratiques sont détaillés dans la documentation OpenSh
 
 L'application déployée doit être conteneurisée (sous la forme d'un ou plusieurs conteneurs).
   - Les __Dockerfiles__ doivent être dans le dépôt pour permettre à la chaine de reconstruire l'application.
-  - Les images de bases des __Dockerfiles__ doivent être accessibles publiquement ou reconstuire par l'offre Cloud π Native .
+  - Les images de bases des __Dockerfiles__ doivent être accessibles publiquement ou reconstuite par l'offre Cloud π Native .
   - Les images doivent être __rootless__, l'utilisateur qui lance le processus au sein du conteneur ne doit pas être `root`.
   - L'utilisateur lançant le processus dans le conteneur doit avoir les droits adéquats en lecture / écriture sur le système de fichiers si l'application doit manipuler ce dernier.
-  - Des sondes de "Readiness"/"Liveness" doivent être implémenté.
+  - Des sondes de "Readiness"/"Liveness" doivent être implémentées.
   - Des limits/requests doivent etre mise en place.
 
 ## Déploiement
 
-L'application doit se déployer à l'aide de fichiers d'__Infrastructure As Code__:
+L'application doit se déployer à l'aide de fichiers d'__Infrastructure As Code__ :
  - Utiliser des manifestes [kubernetes](https://kubernetes.io/) avec Kustomize pour variabliser vos manifestes (cf. [tutoriels](/guide/tutorials))
  - Utiliser des charts [helm](https://helm.sh/) (cf. [tutoriels](/guide/tutorials) pour avoir des exemples de fichiers).
  - Utiliser [Kustomize](https://kustomize.io/)
 
 ## Labels
 
-Les ressources doivent comporter des labels permettant de les identifier. les labels pourraient etre decomposés de la facon suivante :
+Les ressources doivent comporter des labels permettant de les identifier. Ils peuvent être décomposés de la façon suivante :
 
 ``` Yaml
 App : " "
@@ -71,7 +71,7 @@ Tous les labels disponibles [ici](/agreement/labels-list).
 
 ## Tag d'images
 
-Les images poussées dans le registry devront etre unique et identifiés via un Sha ou Short-Sha qui pourrait etre lié au commit Git. Grace a cela une gestion des releases et un rollback seront possibles.
+Les images poussées dans le registry devront être unique et identifiés via un Sha ou Short-Sha qui pourrait être lié au commit Git. Grace à cela une gestion des releases et un rollback seront possibles.
 
 Exemple de valeur pour le Tag de l'image :
 
@@ -84,9 +84,9 @@ CI_JOB_ID
 
 ## Politiques de nommage
 
-Les noms de toutes les ressources Openshift ne doivent jamais etre trop longs, il est donc conseillé de choisir des noms courts.
-il se pourrait que des ressources ne soient pas déployées si le nom est trop long.
-Coté exploitation, cela facilite grandement la gestion.
+Les noms de toutes les ressources Openshift ne doivent jamais être trop longs, il est donc conseillé de choisir des noms courts.
+Il se pourrait que des ressources ne soient pas déployées si le nom est trop long.
+Côté exploitation, cela facilite grandement la gestion.
 
 Exemple :
 
@@ -103,19 +103,19 @@ PVC : env-name-pvc
 
 ## Secrets
 
-Les secrets comportent toutes les informations sensibles. Les différents types de secrets peuvent etre :
+Les secrets comportent toutes les informations sensibles. Les différents types de secrets peuvent être :
 
 - Passwords
 - Certificats
 - Usernames
 - Tokens
 
-Toutes les secrets devront etre contenus dans un Vault qui sera mis a disposition pour l'ensemble des projets. Les objets contenus dans le Vault sont séparés par projets (NS).
+Tous les secrets devront être contenus dans un Vault qui sera mis a disposition pour l'ensemble des projets. Les objets contenus dans le Vault sont séparés par projets (NS).
 
 ## Liveness et Readiness
 
-Il est très important de mettre en place ces checks afin de vérifier l'etat de vos applications. Ceci est nécessaire pour assurer la haute disponibilité et la résilience de vos applications.
-Cela peut-etre une fonctionnalité de l'application, une page d'un site web, une entrée en base de donnée, etc.
+Il est très important de mettre en place ces checks afin de vérifier l'état de vos applications. Ceci est nécessaire pour assurer la haute disponibilité et la résilience de vos applications.
+Cela peut-être une fonctionnalité de l'application, une page d'un site web, une entrée en base de données, etc.
 
 ``` Yaml
 livenessProbe:
@@ -135,22 +135,22 @@ readinessProbe:
 
 ## SSL
 
-Afin d'optimiser un flux sécurisé,il est préférable que cela soit de bout en bout.
+Afin d'optimiser un flux sécurisé, il est préférable que cela soit de bout en bout.
 
-Exemple du schéma de distribution de la requete.
+Exemple du schéma de distribution de la requête.
 
 Users --HTTPS-> ReverseProxy --HTTPS-> Ingress Kubernetes --HTTPS-> Container   (Best Case)
 
 Users --HTTPS-> ReverseProxy --HTTPS-> Ingress Kubernetes --HTTP-> Container   (Usual Case)
 
 ## HPA (Horizontal Pod Autoscaling)
 
-Le scaling est très important afin de répondre aux besoins en termes d'affluence. il est aujourd'hui un atout majeur pour avoir une application qui soit le plus disponible possible avec des performances élevées. Pour cela il est donc possible de définir des triggers afin d'upscale l'applicatif (CPU, RAM, Métriques Applicatives).
+Le scaling est très important afin de répondre aux besoins en termes d'affluence. Il est aujourd'hui un atout majeur pour avoir une application qui soit le plus disponible possible avec des performances élevées. Pour cela il est donc possible de définir des triggers afin d'upscale l'applicatif (CPU, RAM, Métriques Applicatives).
 
 ## QOS
 
-Il est important de définir les consommations de chaque POD (prévisionnelles), Savoir si il serait intéressant que certains disposent d’une "request" égal a la "limit" afin d’assurer une réservation des ressources. (Guaranteed Class)
-L'utilisation du "Burstable" n'est pas pas une bonne pratique. il est vraiment necessaire d'avoir une "limit" même si celle-ci n'est pas équivalente a la "request".
+Il est important de définir les consommations de chaque POD (prévisionnelles), savoir si il serait intéressant que certains disposent d’une "request" égal a la "limit" afin d’assurer une réservation des ressources. (Guaranteed Class)
+L'utilisation du "Burstable" n'est pas pas une bonne pratique. Ll est vraiment nécessaire d'avoir une "limit" même si celle-ci n'est pas équivalente a la "request".
 
 Exemple :
 
@@ -165,14 +165,14 @@ requests:
 
 ## Taille des images
 
-Il est très important de construire des images les plus légères possibles, c'est a dire utiliser uniquement les paquets nécéssaires au bon fonctionnement de l'application ainsi que la meilleure image de base.
+Il est très important de construire des images les plus légères possibles, c'est à dire utiliser uniquement les paquets nécessaires au bon fonctionnement de l'application ainsi que la meilleure image de base.
 C'est un gros vecteur de sécurité, de charge stockage et réseau.
 
 Exemple d'image base Lightway : Alpine
 
 ## Politiques réseau
 
-Les "Network policies" sont par défaut en "Deny ALL". Il est donc à vous de déifnir les flux entrants et sortants sur les namespaces de vos projets.
+Les "Network policies" sont par défaut en "Deny ALL". Il est donc à vous de définir les flux entrants et sortants sur les namespaces de vos projets.
 
 ReverseProxy-->Networkpolicies-->Pods (Ingress)
 

docs/guide/deployment-with-argo.md

@@ -3,28 +3,28 @@
 Une fois qu'un dépôt d'infrastructure est synchronisé, il convient de se rendre sur le service ArgoCD depuis la liste des services :
 ![argocd](/img/tuto/4argocd.png)
 
-Cliquez sur le projet nouvellement créé afin de finaliser son configuration: modification du dépôt d'infrastructure par défaut, ou le cluster de déploiement applicative.
+Cliquez sur l'application nouvellement créé afin de finaliser sa configuration :
 
-Allez dans le menu en haut et cliquez sur App detail :
+Allez dans le menu en haut et cliquez sur details :
 ![ArgoCD-menus](/img/tuto/4argocd-menus-bouton.png)
 
-Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par defaut par la console et selectionner le cluster de déployement.
+Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par défaut par la console.
 ![ArgoCD-app-details](/img/tuto/4argocd-app-details.png)
 
-Notamment:
+Notamment :
 
-- **CLUSTER**: correspond au cluster sur lequel l'application doit être déployée, cela dépends des informations saisie lors de l'étape de [gérer les environnements](/guide/environments-management).
-- **TARGET REVISION**: correspond à la branche du repo d'infra à déployer, par defaut il point sur HEAD (master). A adapter si le repo utilise une branche
-- **PATH** qui est positionné à base par defaut et qui correspond à un déploiement de type fichiers de manifests ou kustmize. Dans le cas d'un déploiement de type HELM, modifier le PATH point pointer vers la racine en mettant un point dans le champs : . ou préciser le répertoire correspondant à la racine du chart
+- **CLUSTER** : correspond au cluster sur lequel l'application doit être déployée, celà dépends des informations renseignées lors de l'étape de [gérer les environnements](/guide/environments-management).
+- **TARGET REVISION** : correspond à la branche du dépôt d'infra à déployer, par défaut il point sur HEAD (master).
+- **PATH** qui est positionné sur "helm/" par défaut. Vous devez indiquer le bon chemin vers vos fichiers de déploiement de type manifests, kustomize ou helm.
 - Dans l'onglet **PARAMETERS**, il est possible de surcharger certaines valeurs du fichier values (mais il est préférable de modifier le fichier values directement)
 
 Finir la saisie en cliquant sur le bouton *SAVE*
 
-Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le repo sur gitlab Cloud π Native en cliquant sur les boutons:
+Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le dépôt sur gitlab Cloud π Native en cliquant sur les boutons:
 
-- *REFRESH* pour forcer la synchronisation depuis le repo gitlab de la plateforme Cloud π Native
+- *REFRESH* pour forcer la synchronisation depuis le dépôt gitlab de la plateforme Cloud π Native
 - *SYNC* pour forcer le rafraichissement entre l'état défini par git et l'état réel des objets créés par ArgoCD.
 
-Une fois le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à :
+Une fois que le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à :
 
 ![ArgoCD-menus](/img/tuto/4argocd-menus.png)

docs/guide/environments-management.md

@@ -8,15 +8,15 @@ La console crée automatiquement :
  - un namespace applicatif par environnement sur le cluster correspondant.
  - le pullsecret associé au projet.
  - les quotas correspondant à l'environnement sur le namespace
- - une application ArgoCD par environnement et par repo de code infrastructure.
+ - une application ArgoCD par environnement et par dépôt de code infrastructure.
 
  ## Création d'un environnement
 
  Depuis la console aller dans le menu ![environnement](/img/environnement/menu.png)
 
  Donner :
   - Un nom à l'environnement, par exemple integration
-  - Un type (dev / staging / integration / prod) le type d'environnement donne accès à des quotas différents
+  - Un type environnement (dev / staging / integration / prod), celui-ci donne accès à des quotas différents
   ![type](/img/environnement/type-env.png)
   - Un dimensionnement (quota)
   ![quota](/img/environnement/quota-env.png)

docs/guide/get-started.md

@@ -19,26 +19,24 @@ Créer un projet sur la console (un détail des opérations à mener est trouvab
 
 Ajouter vos collaborateurs sur le projet, un guide est disponible [ici](/guide/team)
 
-Les collaborateurs devant accéder à Argo CD devront être ajoutés à chaque environnement concernés, voir le guide [ici](/guide/team#attribution-de-droits-a-un-membre)
 
 ## Etape 4 - Ajouter un dépôt synchronisé
 
-Ajouter vos dépôts (qui devront par la suite être synchronisé - manuellement ou via un automatisation), un guide est disponible [ici](/guide/repositories-management).
+Ajouter vos dépôts (qui peuvent être synchronisés - manuellement ou via un automatisation), un guide est disponible [ici](/guide/repositories-management).
 
 Il existe deux types de dépôts:
 
-- dépôt avec du code applicatif: génère une image docker utilisée plus tard dans vos déploiements (doit contenir un Dockerfile et un fichier gitlab-ci nommé `.gitlab-ci-dso.yaml`)
-- dépôt avec du code d'infrastructure: manifest / template kuztomize / chart helm générant votre infrastructure via ArgoCD
+- dépôt avec du code applicatif : génère une image docker utilisée plus tard dans vos déploiements (doit contenir un Dockerfile et un fichier gitlab-ci nommé `.gitlab-ci-dso.yaml`)
+- dépôt avec du code d'infrastructure : manifest / template kuztomize / chart helm générant votre infrastructure via ArgoCD
 
-> Note: il est possible d'avoir un seul dépôt avec les 2 fonctionnalités
+> Note: il est possible d'avoir un seul dépôt avec les deux fonctionnalités
 
 ## Etape 5 - Ajouter un environnement
 
-Un environnement est un namespace cloisonné au sens kubernetes permettant de déployer le code d'infrastructure du dépôt idoine.
+Un environnement est un namespace cloisonné au sens kubernetes permettant de déployer le code d'infrastructure.
 
 Pour déployer un environnement un guide est disponible [ici](/guide/environments-management).
 
-> Note: les collaborateurs du projet devant intervenir sur ArgoCD concernant l'infrastructure doivent être rajouté sur chaque environnement, un guide disponible [ici](/guide/team#attribution-de-droits-a-un-membre).
 
 ## Divers