diff --git a/atelier_secu.md b/atelier_secu.md
index c3f57d3b6385a015547d2b80f132628d39e4a812..769f79ac693c0bd10dd241ffd26554b11cafd142 100644
--- a/atelier_secu.md
+++ b/atelier_secu.md
@@ -1,57 +1,78 @@
-# Scénario de création d'une infrastructure à clef publique
+\begin{titlepage}
 
-## Glossaire
+\newcommand{\HRule}{\rule{\linewidth}{0.5mm}} 
 
-- **Certificat** : Dans le contexte de la sécurité informatique, un certificat est un document numérique permettant d’identifier et d'authentifier un utilisateur ou un service. Il contient aussi les informations nécessaires à l'établissement d'une communication sécurisée (clef publique, protocoles de chiffrements utilisés, etc).  
-- **Infrastructure à clef publique ou PKI (Public Key Infrastructure)** : Une PKI est un ensemble de processus basés sur l'utilisation de certificats qui permettent de chiffrer et d'authentifier les communications entre utilisateurs et services ou de service à service.
-- **Politique de certification** : Ensemble de décisions qui définissent les caractéristique des certificats émis. La politique de certification définit le temps de vie des certificats, la chaîne de confiance, les politiques de révocations, etc.
-- **Autorité de certification ou CA (Certificate Authority)** : Une autorité de certification est un organisme qui agit comme tiers de confiance. La CA est responsable de l'émission de certificats et de leur validation. Pour être considérée comme un tiers de confiance valide, l'autorité doit être reconnue par les principaux navigateurs et systèmes d'exploitation.
+\center 
+\textsc{\LARGE Haute école du paysage, d'ingénierie et d'architecture de Genève}\\[1.5cm] 
+\includegraphics[width=3cm]{images/logo.png} \\[1.5cm]
+\textsc{\Large Ateliers en sécurité}\\[0.5cm] 
+\textsc{\large Scénario d'infrastructure à clef publique}\\[0.5cm] 
+
+\HRule \\[0.4cm]
+{ \huge \bfseries Créer une autorité de certification avec Vault et Kubernetes}\\[0.4cm] 
+\HRule \\[1.5cm]
+
+\begin{minipage}{0.4\textwidth}
+\begin{flushleft} \large
+\emph{Auteurs:}\\
+Flavio \textsc{Morrone}\\ 
+Elio \textsc{Marconi}\\ 
+Léo \textsc{Muff}\\ 
+
+\end{flushleft}
+\end{minipage}\\[2cm]
+{\large \today}\\[2cm] 
+\vfill 
+\end{titlepage}
+
+\setcounter{secnumdepth}{3}
+\setcounter{tocdepth}{3}
+\tableofcontents
+\newpage
 
-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
-https://en.wikipedia.org/wiki/Key_management
-https://www.digicert.com/fr/what-is-pki
-https://www.ssldragon.com/blog/best-practices-to-store-the-private-key/
-https://www.thesslstore.com/blog/what-is-a-key-management-service-key-management-services-explained/
-https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html#storage
 
-## Introduction
+
+# Introduction
 
 Dans le cadre du cours "Ateliers en sécurité", il nous a été demandé de créer une entreprise fictive qui utilise une infrastructure à clef publique, ou PKI (Public Key Infrastructure), pour sécuriser ses services. Ce document décrit le scénario choisi, l'organisation de notre entreprise fictive et les différents composants physiques et logiciels utilisés pour mettre en place notre infrastructure. Il décrit aussi la politique de certification utilisée pour celle-ci.
 
-## Idée principale
+# Idée principale
 
-Nous avons choisi de concevoir une entreprise fournissant une version simplifiée des services proposés par une autorité de certification comme Let's Encrypt. Notre infrastructure comprendra donc sa propre autorité de certification qui permettra d'émettre des certificats pour nos services internes ainsi que pour les services publiques de nos clients. Ces derniers pourront utiliser les certificats émis par notre CA grâce à un outil similaire à [Certbot](https://certbot.eff.org/pages/about).
+Nous avons choisi de concevoir une entreprise fournissant une version simplifiée des services proposés par une autorité de certification comme Let's Encrypt. Notre infrastructure comprendra donc sa propre autorité de certification qui permettra d'émettre des certificats pour nos services ainsi que pour les services publiques de nos clients. La gestion de ces certificats pourra ensuite être automatisée grâce au protocole ACME (Automated Certificate Management Environment).
 
-## Points à traiter :
+\newpage
 
-- problème wildcards
-- vérifier l'identité du possesseur du mail → via a challenge-and-response email exchange with the address in the WHOIS entry, for example
-- expiration des certificats racines et intermédiaires → bridge CA
-- service de support
-- gestion des clefs privées
-- changement de protocoles sécurisés
-- delegation
-- stratégie de révocation (personnes physiques)
-- Trust sign ?
+# Description de l'infrastructure à clef publique
 
+La section ci-dessous décrit les composants et la logique interne de notre entreprise fictive, qui sera appelée **Chepia**.
 
-## Outils :
+## Chaîne de confiance
 
-- [**MicroK8s**](https://microk8s.io/) : Déploiement Kubernetes dans un seul package.
-- [**Vault**](https://www.vaultproject.io/) :  Outil de gestion de secrets qui propose de nombreuses fonctionnalité facilitant la mise en place d'une infrastructure à clé publique.
-- [**Cert-manager**](https://cert-manager.io/) : Outil de gestion de certificat pour Kubernetes
+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.  
 
-## Schéma de l'infrastructure à clef publique
 
-## Nom de l'entreprise :
+\center
+\hspace{1in}
+\includegraphics[width=6cm]{images/trust-chain.drawio.png} 
 
-- ChepiA
+\newpage
 
-## Mise en place de l'infrastructure :
 
-### Set up k8s cluster + install Vault
+## 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.
+- [**Vault**](https://www.vaultproject.io/) :  Outil de gestion de secrets qui propose de nombreuses fonctionnalité facilitant la mise en place d'une infrastructure à clé publique.
+- [**Cert-manager**](https://cert-manager.io/) : Outil de gestion de certificat pour Kubernetes. Son rôle sera de gérer le processus de certification pour nos services via notre gestionnaire de secrets Vault.
+- [**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.")
+
+# Mise en place de l'infrastructure :
+
+## Set up k8s cluster + install Vault
 
 ```
 sudo snap install microk8s --classic --channel=1.29
@@ -75,7 +96,7 @@ Initial Root Token: hvs.zWAYhaUkch0hfgfi18fduTvl
 
 ![Interface graphique de Vault vérouillée](images/vault-seal.png "Interface graphique de Vault vérouillée")
 
-### Install tools on pod
+## Install tools on pod
 
 - jq (json parsing)
 
@@ -87,11 +108,11 @@ chmod +x jq
 ```
 
 
-### Configurer le PKI :
+## Création de l'autorité de certification
 
 - https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine?variants=vault-deploy%3Aselfhosted
 
-#### 1. Création du CA racine:
+### 1. Création du CA racine:
 
 Commandes :
 
@@ -107,7 +128,7 @@ vault write pki/config/urls issuing_certificates="$VAULT_ADDR/v1/pki/ca" \ crl_d
 → TTL de 2 semaine ( pour tester le bridge CA )
 → Rôle permissif au niveau des noms (a changer ?)
     
-#### 2. Création du CA intermédiaire :
+### 2. Création du CA intermédiaire :
 
 Commandes :
 
@@ -129,7 +150,7 @@ vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
 → TTL 10 jours
 
 
-#### 3. Création du rôle :
+### 3. Création du rôle :
 
 - 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.
 
@@ -144,7 +165,7 @@ Commandes :
 ```
 
 
-#### 4. Demander un certificat :
+### 4. Demander un certificat :
 
 Commande :
 
@@ -154,15 +175,15 @@ vault write pki_int/issue/chepia-dot-ch common_name="test.chepia.ch" ttl="24h"
 
 → Crée un certificat valide 24 heures pour le nom de domaine "test.chepia.ch"
 
-### Configurer cert-manager
+## Configuration de cert-manager
 
 - https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
 
-#### 1. Activation de cert-manager :
+### 1. Activation de cert-manager :
     
 - `microk8s enable cert-manager`
 
-#### 2. Configurer l'accès entre Vault et Kubernetes
+### 2. Configurer l'accès entre Vault et Kubernetes
 
 ```bash
 kubectl exec --stdin=true --tty=true vault-0 -- /bin/sh
@@ -173,7 +194,7 @@ 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
+### 3. Configurer l'émetteur de certificats
 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 :
@@ -217,9 +238,9 @@ spec:
 
 
 
-### Mise en place de TLS sur un service
+## Mise en place de TLS sur un service
 
-#### 1. Création du service
+### 1. 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`.
 
@@ -287,7 +308,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 :
+### 2. Création du certificat du service :
 
 - Création du fichier `cert.yaml` :
 
@@ -308,7 +329,7 @@ spec:
 
 - Appliquer la config avec la commande `microk8s kubectl apply -f cert.yaml`
 
-#### 3. Configuration de l'accès au service
+### 3. Configuration de l'accès au service
 
 - Créer le fichier `nginx-service.yaml`:
 
@@ -350,7 +371,7 @@ spec:
 
 - Appliquer la config avec la commande `microk8s kubectl apply -f nginx-service.yaml`
 
-#### 4. Test de l'accès au service
+### 4. 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`:
 `127.0.0.1 www.chepia.ch`
@@ -382,15 +403,15 @@ 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.")
 
-### Mise à jour des certificats
+## Mise à jour des certificats
 
-#### 1. Suppression des certificats expirés
+### 1. Suppression des certificats expirés
 
 ```
 vault write pki_int/tidy tidy_cert_store=true tidy_revoked_certs=true
 ```
 
-#### 2. Rotation du certificat racine
+### 2. Rotation du certificat racine
 
 ```
     vault write pki/root/rotate/internal \
@@ -403,7 +424,7 @@ vault write pki/roles/chepia-servers allow_any_name=true
 ```
 
 
-#### 3. Création d'un pont entre le nouveau certificat racine et l'ancien
+### 3. 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.
 
@@ -427,13 +448,13 @@ Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis lon
           
 ```
 
-#### 4. Remplacer l'émetteur par défaut 
+### 4. 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
+### 5.  Signer l'autorité intermédiaire avec notre nouveau certificat racine
 
 ```bash
 cd vault
@@ -453,26 +474,26 @@ vault write -format=json pki/issuer/root-2/sign-intermediate \
 vault write pki_int/intermediate/set-signed certificate=@cross-signed-intermediate.crt
 ```
 
-### ACME setup
+## ACME setup
 
-#### terminal :
+### terminal :
 ```bash
 vault write /sys/mounts/pki_int/tune \
     passthrough_request_headers="If-Modified-Since" \
     allowed_response_headers="Last-Modified,Location,Replay-Nonce,Link"
 ```
 
-#### GUI :
+### GUI :
 - go to the intermediate certificate configuration page
 - add url `http://127.0.0.1:8200/v1/pki_int` to AIA path and Mount's API path 
 - Tick "Enable ACME"
 - save
 
-###  Add ACME to cert-manager
+##  Add ACME to cert-manager
 
 https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
 
-####  add issuer
+###  add issuer
 
 - Création du fichier de configuration acme.yaml
 
@@ -496,7 +517,7 @@ spec:
 
 - Activation de la config avec `microk8s kubectl apply -f acme.yaml `
 
-### Add ingress to the k8s cluster
+## Add ingress to the k8s cluster
 
 - Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes : 
 
@@ -504,7 +525,7 @@ spec:
 
 - On peut maintenant créer des règles pour exposer des services en https.
 
-### Create certificate
+## Create certificate
 
 ```
 apiVersion: cert-manager.io/v1 
@@ -534,4 +555,23 @@ spec:
 
 
 
-https://cert-manager.io/docs/usage/ingress/
\ No newline at end of file
+https://cert-manager.io/docs/usage/ingress/
+
+# Glossaire
+
+- **Kubernetes** : Système d'orchestration de conteneurs qui permet de créer facilement une infrastructure virtuelle en automatisant le déploiement d'applications, la configuration du réseau et des services, etc.
+- **Certificat** : Dans le contexte de la sécurité informatique, un certificat est un document numérique permettant d’identifier et d'authentifier un utilisateur ou un service. Il contient aussi les informations nécessaires à l'établissement d'une communication sécurisée (clef publique, protocoles de chiffrements utilisés, etc).  
+- **Infrastructure à clef publique ou PKI (Public Key Infrastructure)** : Une PKI est un ensemble de processus basés sur l'utilisation de certificats qui permettent de chiffrer et d'authentifier les communications entre utilisateurs et services ou de service à service.
+- **Politique de certification** : Ensemble de décisions qui définissent les caractéristique des certificats émis. La politique de certification définit le temps de vie des certificats, la chaîne de confiance, les politiques de révocations, etc.
+- **Autorité de certification ou CA (Certificate Authority)** : Une autorité de certification est un organisme qui agit comme tiers de confiance. La CA est responsable de l'émission de certificats et de leur validation. Pour être considérée comme un tiers de confiance valide, l'autorité doit être reconnue par les principaux navigateurs et systèmes d'exploitation.
+- **Chaîne de confiance**
+# Références
+
+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
+https://en.wikipedia.org/wiki/Key_management
+https://www.digicert.com/fr/what-is-pki
+https://www.ssldragon.com/blog/best-practices-to-store-the-private-key/
+https://www.thesslstore.com/blog/what-is-a-key-management-service-key-management-services-explained/
+https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html#storage
\ No newline at end of file
diff --git a/atelier_secu.pdf b/atelier_secu.pdf
index 6b7a729d869aaffc93ff2c3adea4d34ccd4e3510..55f578b7db55d44fd46154d082dfd497857a957c 100644
Binary files a/atelier_secu.pdf and b/atelier_secu.pdf differ
diff --git a/images/logo.png b/images/logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..0ecb6312d98dc0dcb96d0862303c3963ba9e7977
Binary files /dev/null and b/images/logo.png differ
diff --git a/images/soft.drawio.png b/images/soft.drawio.png
new file mode 100644
index 0000000000000000000000000000000000000000..72f14feba95ef6691970888dededd83e3c70d091
Binary files /dev/null and b/images/soft.drawio.png differ
diff --git a/images/trust-chain.drawio.png b/images/trust-chain.drawio.png
new file mode 100644
index 0000000000000000000000000000000000000000..64a69d4fc43c9d7d9fe81a1043916a759f3bb13d
Binary files /dev/null and b/images/trust-chain.drawio.png differ