diff --git a/atelier_secu.md b/atelier_secu.md
index 769f79ac693c0bd10dd241ffd26554b11cafd142..76d7756790e9230f996eb1380dded0e31e2f313c 100644
--- a/atelier_secu.md
+++ b/atelier_secu.md
@@ -25,8 +25,8 @@ Léo \textsc{Muff}\\
 \vfill 
 \end{titlepage}
 
-\setcounter{secnumdepth}{3}
-\setcounter{tocdepth}{3}
+\setcounter{secnumdepth}{4}
+\setcounter{tocdepth}{4}
 \tableofcontents
 \newpage
 
@@ -50,14 +50,15 @@ La section ci-dessous décrit les composants et la logique interne de notre entr
 
 Notre autorité racine émettra les certificats deux deux autorités intermédiaires : une pour émettre les certificats des services internes de notre entreprise, et une pour les certificats fourni avec ACME aux services externes de nos clients.  
 
-
+\begin{figure}
+\hspace{2in}
 \center
-\hspace{1in}
 \includegraphics[width=6cm]{images/trust-chain.drawio.png} 
+\caption{Chaîne de confiance de notre autorité de certification}
+\end{figure}
 
 \newpage
 
-
 ## Composants logiciels
 
 - [**MicroK8s**](https://microk8s.io/) : Déploiement Kubernetes dans un seul package. Conçu pour le développement de services conteneurisés sur une machine locale.
@@ -66,23 +67,45 @@ Notre autorité racine émettra les certificats deux deux autorités intermédia
 - [**Nginx**](https://docs.nginx.com/) : Serveur web. Utilisé pour tester le fonctionnement de notre autorité de certification.
 - [**ACME**](https://www.ssl.com/fr/faq/quel-est-le-protocole-acme/) (Automated Certificate Management Environment) : Protocole utilisé pour automatiser le processus de certification. Il nous permettra de créer un service similaire à celui de Let's Encrypt, et fournir des certificats aux services de nos clients.
 
-## Schéma des services
 
-![Image non trouvée : images/soft.drawio.png Pile des ](images/soft.drawio.png "Pile des éléments logiciels de l'infrastructure à clef publique.")
+\begin{figure}
+\hspace{2in}
+\center
+\includegraphics[width=10cm]{images/soft.drawio.png} 
+\caption{Pile logicielle de notre infrastructure}
+\end{figure}
+
+\newpage
 
 # Mise en place de l'infrastructure :
 
-## Set up k8s cluster + install Vault
+## Installation Vault sur MicroK8s
 
-```
+Les commandes suivantes permettent d'installer microk8s et d'y déployer une instance de Vault. Elles ont été testées sur un système Ubuntu 22.04, et peuvent varier selon le système utilisé.
+
+```bash
 sudo snap install microk8s --classic --channel=1.29
 microk8s enable dns hostpath-storage dashboard
 microk8s helm repo add hashicorp https://helm.releases.hashicorp.com
 microk8s helm install vault hashicorp/vault    
-microk8s  kubectl exec -ti vault-0 -- vault operator init
-microk8s kubectl port-forward vault-0 8200:8200
 ```
 
+Une fois Vault déployé, le gestionnaire de secret doit être initialisé. Cette opération va créer une clef privée qui sera utilisée pour chiffrer les données de Vault. Cette clef est ensuite chiffrée par une autre clé aussi appelée clé *root key* qui est elle-même chiffrée par une autre clef appelée *unseal key* . La clé *unseal* est ensuite partagée en plusieurs partie selon le partage de secret de Shamir. Les différentes parties devront ensuite être réunies pour déverrouiller Vault.
+
+![Secret partagé de Shamir](images/shamir.png "Secret partagé de Shamir")
+
+\newpage
+
+L'initialisation de Vault s'effectue avec la commande suivante : 
+
+```bash
+microk8s kubectl exec -ti vault-0 -- vault operator init
+```
+→ Le nom du container `vault-0` peut être différent sur votre système. La commande `microk8s kubectl get pods -A` permet de vérifier cela.
+
+Le résultat devrait ressembler à ceci :
+
+```
 tokens : 
 Unseal Key 1: 80pqLahtRotMHBFUVDlw4Ax3MU3aPfZAvFhRe7SFoWOl
 Unseal Key 2: dBShI3QRLLoEmu9bT5BV/mqOyxPC8HqmiETwxpeuD7qc
@@ -91,32 +114,52 @@ Unseal Key 4: 5/G/CndGOYuDR6X+/zMeMyK8BbswRuWpPexf0zswaNwt
 Unseal Key 5: Oesp4xJ3xTElpgJm+bRfQ9Ia0cYdxiQZa3h9o3hQxK3c
 
 Initial Root Token: hvs.zWAYhaUkch0hfgfi18fduTvl
+```
+
+Ces informations doivent être stockées de manière sécurisée, en utilisant un HSM (Hardware Security Module) par exemple. Une fois en possession de ces informations, on peut accéder aux fonctionnalité de Vault.
+
+Pour accéder à l'interface graphique de Vault, on utilise la commande suivante :
+
+```bash
+microk8s kubectl port-forward vault-0 8200:8200
+```
 
---> Pour déverrouiller Vault, il faut que 3 des 5 tokens créés soit renseignés. On doit ensuite se logger avec le token root 
+→ L'interface sera disponible à l'adresse 127.0.0.1:8200
 
 ![Interface graphique de Vault vérouillée](images/vault-seal.png "Interface graphique de Vault vérouillée")
 
-## Install tools on pod
+→ Pour déverrouiller Vault, il faut que 3 des 5 tokens créés soit renseignés (n'importe lesquels). On doit ensuite se logger avec un token utilisateur (root par défaut)
 
-- jq (json parsing)
+\newpage
 
-```
+## Installation d'un parser JSON
+
+Vault est aussi utilisable en ligne de commande. Pour cela, il faut se connecter au container avec la commande suivante :
+
+```bash
 microk8s kubectl exec -ti vault-0 -- sh
+```
+
+Une fois connectés au container, on peut utiliser l'outil `vault` en ligne de commande. Comme cet outil génère principalement du JSON en sortie, il est nécessaire d'installer le parser JQ pour pouvoir réutiliser la sortie facilement. 
+
+Commandes :
+
+```
 cd vault
 wget https://github.com/stedolan/jq/releases/download/jq-1.7.1/jq-linux64 -O jq
 chmod +x jq
 ```
 
-
 ## Création de l'autorité de certification
 
-- https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine?variants=vault-deploy%3Aselfhosted
+Une fois Vault prêt, on peut commencer à mettre en place notre PKI. Les étapes ci-dessous utilise la ligne de commande mais une correspondance en interface graphique est possible, voir la documentation de Vault pour cela.
+
+### Création du CA racine: \newline
 
-### 1. Création du CA racine:
 
 Commandes :
 
-```
+```bash
 microk8s kubectl exec -ti vault-0 -- sh 
 export VAULT_TOKEN=hvs.zWAYhaUkch0hfgfi18fduTvl
 vault secrets enable pki
@@ -125,14 +168,15 @@ vault write pki/roles/chepia-servers allow_any_name=true
 vault write pki/config/urls issuing_certificates="$VAULT_ADDR/v1/pki/ca" \ crl_distribution_points="$VAULT_ADDR/v1/pki/crl"
 ```
 
-→ TTL de 2 semaine ( pour tester le bridge CA )
-→ Rôle permissif au niveau des noms (a changer ?)
+→ TTL de 2 semaine pour tester la rotation de certificats et le bridge CA.
+
+→ Rôle permissif au niveau des noms pour faciliter la mise en place, peut être restreint ultérieurement.
     
-### 2. Création du CA intermédiaire :
+### Création du CA intermédiaire : \newline
 
 Commandes :
 
-```
+```bash
 vault secrets enable -path=pki_int pki
 vault secrets tune -max-lease-ttl=240h pki_int
 vault write -format=json pki_int/intermediate/generate/internal \
@@ -147,16 +191,16 @@ vault write -format=json pki/root/sign-intermediate \
 vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
 ```
 
-→ TTL 10 jours
+→ TTL 10 jours (doit être plus court que celui de la racine)
 
 
-### 3. Création du rôle :
+### Création du rôle : \newline
 
-- Un rôle définit une politique d'accès au certificats intermédiaire : Le domaine doit être `chepia.ch` ou un sous domaine comme `www.chepia.ch`, et le temps de vie maximum est de 120 heures.
+- Un rôle définit une politique d'accès au certificats intermédiaire : Le domaine doit être `chepia.ch` ou un sous-domaine comme `www.chepia.ch`, et le temps de vie maximum est de 120 heures.
 
 Commandes :
 
-```
+```bash
  vault write pki_int/roles/chepia-dot-ch \
      issuer_ref="$(vault read -field=default pki_int/config/issuers)" \
      allowed_domains="chepia.ch" \
@@ -165,11 +209,11 @@ Commandes :
 ```
 
 
-### 4. Demander un certificat :
+### Demander un certificat : \newline
 
 Commande :
 
-```
+```bash
 vault write pki_int/issue/chepia-dot-ch common_name="test.chepia.ch" ttl="24h"
 ```
 
@@ -177,13 +221,11 @@ vault write pki_int/issue/chepia-dot-ch common_name="test.chepia.ch" ttl="24h"
 
 ## Configuration de cert-manager
 
-- https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
-
-### 1. Activation de cert-manager :
+### Activation de cert-manager : \newline
     
 - `microk8s enable cert-manager`
 
-### 2. Configurer l'accès entre Vault et Kubernetes
+### Configurer l'accès entre Vault et Kubernetes \newline
 
 ```bash
 kubectl exec --stdin=true --tty=true vault-0 -- /bin/sh
@@ -194,14 +236,17 @@ write auth/kubernetes/config \
 
 → La variable globale `$KUBERNETES_PORT_443_TCP_ADDR`est à modifier selon votre configuration. L'adresse utilisée par le service principal de Kubernetes peut être consultée avec la commande `microk8s kubectl get services | grep kubernetes`. Dans mon cas, Kubernetes utilise l'adresse 10.152.183.1. 
 
-### 3. Configurer l'émetteur de certificats
+\newpage
+
+### Configurer l'émetteur de certificats \newline
+
 1. Créer une identité pour communiquer avec l'émetteur. C'est avec cette identité que cert-manager utilisera pour accéder au rôle créé à l'étape précédente : \newline
  `kubectl create serviceaccount issuer`
 2. Créer un secret que l'identité `issuer` utilisera pour s'authentifier :
 
-- On crée pour cela le fichier `issuer-secret.yaml`:
+→ On crée pour cela le fichier `issuer-secret.yaml`:
 
-``` 
+```yaml
 apiVersion: v1
 kind: Secret
 metadata:
@@ -211,7 +256,7 @@ metadata:
 type: kubernetes.io/service-account-token
 ```
 
-- Appliquer la config avec la commande `microk8s kubectl apply -f issuer-secret.yaml`.
+→ Appliquer la config avec la commande `microk8s kubectl apply -f issuer-secret.yaml`.
 
 3. Créer le ficher de configuration de l'émetteur `vault-issuer.yaml`:
 
@@ -234,13 +279,19 @@ spec:
           key: token
 ```
 
-- Appliquer la config avec la commande `microk8s kubectl apply -f vault-issuer.yaml`.
+→ Appliquer la config avec la commande `microk8s kubectl apply -f vault-issuer.yaml`.
 
+## Installer Nginx Ingress
 
+- Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes : 
+
+`microk8s enable ingress`
+
+- On peut maintenant créer des règles pour exposer des services hors de notre cluster Kubernetes.
 
 ## Mise en place de TLS sur un service
 
-### 1. Création du service
+### Création du service
 
 - Nous allons utiliser un simple serveur web Nginx pour représenter la page d'accueil  de notre entreprise. Les étapes suivantes montrent comment créer un stockage pour le code source de notre site et déployer une instance Nginx qui monte ce stockage dans le dossier `/usr/share/nginx/html`.
 
@@ -272,6 +323,7 @@ spec:
     requests:
       storage: 1Gi
 ```
+\newpage
 
 2. Créer le fichier de config du serveur (`nginx.yaml`) :
 
@@ -308,7 +360,7 @@ spec:
 3. Appliquer les configs :  `microk8s kubectl apply -f html-volumes.yaml`, `microk8s kubectl apply -f nginx.yaml`
 
 
-### 2. Création du certificat du service :
+### Création du certificat du service :
 
 - Création du fichier `cert.yaml` :
 
@@ -329,7 +381,7 @@ spec:
 
 - Appliquer la config avec la commande `microk8s kubectl apply -f cert.yaml`
 
-### 3. Configuration de l'accès au service
+### Configuration de l'accès au service
 
 - Créer le fichier `nginx-service.yaml`:
 
@@ -371,28 +423,45 @@ spec:
 
 - Appliquer la config avec la commande `microk8s kubectl apply -f nginx-service.yaml`
 
-### 4. Test de l'accès au service
+\newpage
+
+### Test de l'accès au service
 
-Pour pouvoir accéder à notre service de manière sécurisée, il faut le faire par son nom de domaine, car c'est à celui-ci qu'est relié le certificat créé précédemment. Pour cela, on va ajouter la ligne suivante au fichier `/etc/hosts`:
+Pour pouvoir accéder à notre service de manière sécurisée, il faut le faire par son nom de domaine, car c'est à celui-ci qu'est relié le certificat créé précédemment. Pour cela, on va ajouter la ligne suivante au fichier `/etc/hosts`: \newline
 `127.0.0.1 www.chepia.ch`
 
 Ensuite, on peut tester la connexion TLS avec la commande : 
 ` curl -kivL   'https://www.chepia.ch'`
 
-![Connexion à notre service en https avec curl. ](images/curl.png "Connexion à notre service en https avec curl. ")
+
+\begin{figure}
+\hspace{2in}
+\center
+\includegraphics[width=8cm]{images/curl.png} 
+\caption{Connection à notre service en https avec Curl}
+\end{figure}
 
 On peut voir que le certificat du serveur est bien émit par notre autorité de certification intermédiaire. Par contre 
-la ligne `SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.` indique que notre CA n'a pas été reconnu. C'est normal, car on a pas encore ajouté le certificat racine de notre autorité à la liste des CA reconnu par notre système d'exploitation. Si on essaye d'accéder à notre service avec un navigateur web, on va rencontrer l'avertissement suivant :
+la ligne `SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.` indique que notre CA n'a pas été reconnu. C'est normal, car on a pas encore ajouté le certificat racine de notre autorité à la liste des CA reconnu par notre système d'exploitation. Si on essaye d'accéder à notre service avec un navigateur web, on va rencontrer un avertissement similaire.
+
+\newpage
 
-![Notre CA n'est pas reconnu par le navigateur Firefox](images/auth_unknown.png "Notre CA n'est pas reconnu par le navigateur Firefox")
+
+\begin{figure}
+\hspace{2in}
+\center
+\includegraphics[width=8cm]{images/auth_unknown.png} 
+\caption{Avertissement de sécurité de Firefox. Notre CA n'est pas reconnu par le navigateur.}
+\end{figure}
 
 Pour remédier à cela, on va chercher le certificat de notre autorité intermédiaire dans l'interface graphique de Vault. 
 
-![On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch](images/cert_gui.png "On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority")
+![On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority](images/cert_gui.png "On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority")
+
+\newpage
 
-Ensuite, on crée un sous-répertoire `chepia.ch` dans le répertoire `/usr/local/share/ca-certificates`:
-`sudo mkdir /usr/local/share/ca-certificates/chepia.ch`
-On place le certificat dans le répertoire et on met à jour la liste des CAs reconnus avec `sudo update-ca-certificates`.
+Ensuite, on crée un sous-répertoire `chepia.ch` dans le répertoire `/usr/local/share/ca-certificates`.
+On y place le certificat et on met à jour la liste des CAs reconnus avec `sudo update-ca-certificates`.
 
 Il faut aussi ajouter le certificat à la liste des CAs de confiance de votre navigateur. Pour cela, allez dans *préférences*, *Vie privée et sécurité*, *Certificats* et cliquer sur *Afficher les certificats* puis *Importer*.
 Une fois le certificat importé, on retrouve notre autorité dans la liste des CAs de confiance.
@@ -403,15 +472,17 @@ Si on retourne sur *www.chepia.ch*, l'alerte a disparu.
 
 ![Le point d'exclamation a disparu du cadenas, on peut utiliser le service de manière sécurisée.](images/lock.png "Le point d'exclamation a disparu du cadenas, on peut utiliser le service de manière sécurisée.")
 
+\newpage
+
 ## Mise à jour des certificats
 
-### 1. Suppression des certificats expirés
+### Suppression des certificats expirés
 
 ```
 vault write pki_int/tidy tidy_cert_store=true tidy_revoked_certs=true
 ```
 
-### 2. Rotation du certificat racine
+### Rotation du certificat racine
 
 ```
     vault write pki/root/rotate/internal \
@@ -424,11 +495,11 @@ vault write pki/roles/chepia-servers allow_any_name=true
 ```
 
 
-### 3. Création d'un pont entre le nouveau certificat racine et l'ancien
+### Création d'un pont entre le nouveau certificat racine et l'ancien
 
 Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis longtemps et doivent mettre à jour leur certificat racine. Le pont permet à ses service de faire confiance à notre nouveau certificat racine.
 
-```
+```bash
     cd vault
     
     vault write -format=json pki_int/intermediate/cross-sign \
@@ -448,13 +519,15 @@ Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis lon
           
 ```
 
-### 4. Remplacer l'émetteur par défaut 
+\newpage
+
+### Remplacer l'émetteur par défaut 
 
 ```
 vault write pki/root/replace default=root-2
 ```
 
-### 5.  Signer l'autorité intermédiaire avec notre nouveau certificat racine
+### Signer l'autorité intermédiaire avec notre nouveau certificat racine
 
 ```bash
 cd vault
@@ -517,45 +590,7 @@ spec:
 
 - Activation de la config avec `microk8s kubectl apply -f acme.yaml `
 
-## Add ingress to the k8s cluster
-
-- Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes : 
-
-`microk8s enable ingress`
-
-- On peut maintenant créer des règles pour exposer des services en https.
 
-## Create certificate
-
-```
-apiVersion: cert-manager.io/v1 
-
-kind: Certificate 
-
-metadata:
-
- name: chepia-cert
-
- namespace: default 
-
-spec:
-
- issuerRef:
-
- name: chepia-ch 
-
- kind: ClusterIssuer 
-
- secretName: chepia-cert 
-
- dnsNames:
-
-\- www.chepia.ch
-```
-
-
-
-https://cert-manager.io/docs/usage/ingress/
 
 # Glossaire
 
@@ -567,6 +602,9 @@ https://cert-manager.io/docs/usage/ingress/
 - **Chaîne de confiance**
 # Références
 
+https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine?variants=vault-deploy%3Aselfhosted
+https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
+https://developer.hashicorp.com/vault/docs/concepts/seal
 https://fr.wikipedia.org/wiki/Autorit%C3%A9_de_certification
 https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique
 https://en.wikipedia.org/wiki/Certificate_policy
diff --git a/atelier_secu.pdf b/atelier_secu.pdf
index 55f578b7db55d44fd46154d082dfd497857a957c..ee8acbbba01024b61a6abbd9aa06e424ba9137cb 100644
Binary files a/atelier_secu.pdf and b/atelier_secu.pdf differ