diff --git a/README.md b/README.md
index 3f9c8dc9d5468944474bf59cd4264fc70c47efff..2861de7d3662bcb50bf5c2fef6bfc6cba68924c3 100644
--- a/README.md
+++ b/README.md
@@ -110,289 +110,141 @@ On préfère souvent utiliser une image alpine à une image debian en production
 Utilise une image alpine (python:3.8-alpine) comme base pour ton image.  
 Ne cherchez pas de solution j'ai eu la flemme d'en faire une.
 
-## 5. Deploy you app on Kubernetes: the Pod
+## Déployer l'application sur kubernetes 
 
-> If you are here, ask for a quick formation on Kubernetes. We will make a quick overview for everyone!
+Kubernetes c'est un orchestrateur de conteneur. Ca permet de gérer pleins de conteneurs et de faire des trucs inteligents avec comme créer des réplicat et de recréer dynamiquement les conteneurs qui crashent. 
 
-### Why
-
-Now that we can run our application locally, we want to deploy it to Kubernetes, which is a container orchestrator.
-
-### What
-
-We will start with the basics: a Pod. It is the basic unit to run something on Kubernetes. It is composed of one or several containers, running together.
-
-Here an example of a Pod manifest:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: my-pod
-  namespace: my-namespace
-  labels:
-    foo: bar
-spec:
-  containers:
-    - name: my-container
-      image: myapp:v1.0.0
-      command: ['/bin/my-app']
-      args: ['--migrate-db', '--db-host=12.34.56.78']
+Kubernetes fonctionne sur un mode de déclaration des ressources. On écrit ce qu'on veux dans des fichiers yaml et il suffit de lancer la commande 
 ```
-
-You can save this kind of _manifest_ into a file, for example `manifests/pod.yaml`, and then _deploy it_ to Kubernetes with `kubectl apply -f manifests/pod.yaml`. If you have several files, you can also apply the whole folder.
-
-You also have some basic Kubernetes commands to get informations about your pod.
-
-```bash
-kubectl get pods
-kubectl describe pod <my-pod>
-kubectl logs <my-pod>
+kubectl apply -f <myfile.yaml>
 ```
+Pour deployer sur le cluster l'objet décrit. 
 
-Take some time to [learn a bit about pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/).
-
-### How
-
-1. Write a `pod.yaml` file (the VSCode extension can help you with that)
-2. At minimum, you need a name and a first container definition, with its name and image. **For the image, you can push the image to a public registry, or for kind add it to the cluster with `kind load docker-image "${IMAGE}" --name padok-training`. You can also use the following: `dixneuf19/guestbook:v0.1.0`.
-3. Try to deploy it, and launch the previous command
-4. If you need to delete it, use `kubectl delete -f manifests/`
-5. Take some time to play around with this object: what happens if you give a non existing image?
-6. Try to access your application with `kubectl port-forward <my-pod> 3000:3000`
-
-### Checks
-
-- [ ] My pod is running: I can see its state and follow its logs
-- [ ] I have access to the Web UI with the port-forward
-
-<details>
-<summary>Compare your work to the solution before moving on. Are there differences? Is your approach better or worse? Why?</summary>
-
-You should have something like:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: guestbook
-  labels:
-    app: guestbook
-    project: dojo
-spec:
-  containers:
-  - name: guestbook
-    image: dixneuf19/guestbook:v0.1.0
-    ports:
-    - containerPort: 3000
-      name: http
+Une fois l'objet déployé on peux obtenir la liste de ces objets avec la commande: 
+```
+kubectl get <objet>
+```
+On peux aussi obtenir des détails sur l'objet: 
+```
+kubectl describe <objet> <nom de l'objet>
 ```
-</details>
-
-
-## 6. Manage replications and rolling update: Deployments
-
-### Why
-
-One pod is cool, but what if you want to deploy several instances of the same app, to avoid any downtime if a node fails?
-
-That is the function of deployments: you declare a _template of a Pod_, with also a replication. It also helps you manage updates of your applications without any downtime.
 
-### What
+### Pousser les images sur le registry
+La première étape du déploiement sur kubernetes va être de pousser les images sur le registry afin que le cluster kube puisse les récupérer. Le registry c'est un serveur qui stocke les images docker. 
+Pour cela il faut d'abord renomer nos images docker afin d'indiquer a docker ou les pousser. La forme du tag du docker doit être :
+```
+registry/project/nom_de_l'image:version
+```
 
-Same as before, everything in Kubernetes is declarative. You can create a file, write a manifest into it and apply!
+Dans notre cas on souhaite pousser sur le registry de viarezo (registry.viarezo.fr) dans le projet "formation-kube".
 
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: my-deployment
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      foo: bar
-  template:
-    metadata:
-      labels:
-        foo: bar
-    spec:
-      containers:
-        - name: my-container
-          image: myapp:v1.0.0
-          ports:
-            - containerPort: 3000
+Il suffit ensuite de pousser l'image avec 
+```
+docker push
 ```
-As for all kubernetes resources, here are generic useful commands:
 
+Note: 
+Dans notre cas le projet formation-kube est en public est donc accessible à tous. Si ça n'est pas le cas il peut etre nécessaire de faire un 
 ```bash
-kubectl get deployment
-kubectl describe deployment <my-dep>
+docker login
 ```
+pour s'identifier auprès du registry.
 
-### How
-
-1. Transform your current pod into a deployment. You just need to put everything from `Pod.spec` to the `Deployment.spec.template.spec`.
-2. What are these "selector"? Can you modify them?
-3. Play along with replicas. Try to delete some pods.
-4. Modify something in you template, and watch closely the way your pods are replaced. Is there any _downtime_?
-
-### Checks
+### Déploiement ### 
 
-- [ ] I can still access one of my replica with port-forward
-- [ ] I have listed or described my deployment 
+L'unité de base de kubernetes c'est le pod. Un pod correspond à une ou plusieurs conteneurs gérés comme un tout. 
+Il est possible de créer un pod directement mais en pratique personne le fait. Habituellement on créer les pods au travers de déploiement. Le déploiement est un objet qui permet de créer un pod et gère ses réplications. Il s'assure qu'il y ait toujours le bon nombre de répicalt disponible sur le cluster en récréant/supprimant des pods si besoin. 
 
-<details>
-<summary>Compare your work to the solution before moving on. Are there differences? Is your approach better or worse? Why?</summary>
+Le déploiement de base se décrit grace au template suivant (N'hésitez pas a installer l'extension kubernetes de vscode qui écrit les templates toute seule): 
 
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: guestbook
+  name: myapp
 spec:
-  replicas: 3
   selector:
     matchLabels:
-      app: guestbook
-      project: dojo
+      app: myapp
   template:
     metadata:
       labels:
-        app: guestbook
-        project: dojo
+        app: myapp
     spec:
       containers:
-      - name: guestbook
-        image: dixneuf19/guestbook:v0.1.0
+      - name: myapp
+        image: <Image>
+        resources:
+          limits:
+            memory: "128Mi"
+            cpu: "500m"
         ports:
-        - containerPort: 3000
-          name: http
+        - containerPort: <Port>
 ```
-</details>
+Ecrivez donc un déploiement pour le back et un pour le front.
+Vérifiez ensuite que vos pods sont bien marqués en ready.
 
+```
+kubectl port-forward <nom_du_pod> <port_du_pod>:<port_où_exposer>
+```
 
-
-## 7. Expose your app internally
-
-### Why
-
-While you can access your app with port-forwarding, it is not very practical. Moreover, since the app is _stateless_, we want to access any pod.
-
-For a start, a internal access would be good enough. That is the job of *Services*, they provide an internal load balancing inside the cluster.
-
-### What
-
-You start to know the drill: create a manifest and apply it.
-
-Not that for services, you need to _select_ your pods using their **labels**. The easy thing to do: just use the same labels used in your deployment to find its pods.
-
-```yaml
+### Service
+Un service est une entitée qui permet aux pods de communiquer entre eux au sein du cluster. Il s'occupe aussi du load balancing entre les réplicats des pods.
+Le template d'un service est le suivant :
+``` yaml
 apiVersion: v1
 kind: Service
 metadata:
-  name: my-service
+  name: myapp
 spec:
   selector:
-    foo: bar
+    app: myapp
   ports:
-    - protocol: TCP
-      port: 80
-      targetPort: 8080
-```
-
-In the cluster, other pods will be able to call one the pod behind the service, just with
-
-```bash
-curl http://my-service # request one of the pods selected by the service
-# if your pod run in a different namespace, you need to specify it
-curl http://my-service.my-ns
-```
-
-Here is the [official documentation](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service) and some useful commands.
-
-```bash
-kubectl get services
-kubectl describe service <my-svc>
-kubectl port forward svc/<my-svc> 3000:80
-# lets see on http://localhost:3000
+  - port: <Port>
+    targetPort: <Target Port>
 ```
 
-### How
-
-1. Create the service manifest, set the correct labels and port and apply it!
-2. You are free to use the external port you want
-3. You can test if the service is functional with `kubectl port-forward svc/<my-svc> <local-port>:<svc-port>` 
-4. Try to break your service: what happen if you set wrong labels ? Can you have a service pointing on multiple deployments?
-
-### Checks
-
-- [ ] I can access the UI using port-forwarding on the service
-
-<details>
-<summary><em>Compare your work to the solution before moving on. Are there differences? Is your approach better or worse? Why?</em></summary>
+### Exposer un service vers l'exterieur
+Avec notre service nous avons exposés notre app au sein du cluster. Maintenant nous allons l'exposer vers le moooooooonde. Pour cela nous alons mettre en place des ingress. Un ingress est un proxy qui en fonction du nom de domaine de la requête redirige vers le service adapté. Ici, à Viarezo, nous utilisons des IngressRoutes gérés par traefik. Traefik est un logiciel qui s'occupe de gérer toutes les routes décrites dans des ingress et ingressroutes (c'est sensiblement la même chose).
 
-You can find the complete solution [here](https://github.com/padok-team/dojo-guestbook/blob/feat/solution/manifests/service.yaml). Don't spoil yourself too much!
-
-</details>
-
-## 8. Show it to the world: Ingress
-
-### Why
-
-Now that you have an internal load balancer, you want to expose your app to your friends. Thankfully, an **Ingress Controller** and its DNS are already setup for you, all traffic for `*.vcap.me` goes to your cluster
-
-However, you need to tell the Ingress Controller where to route the request it receives, depending on its _hostname_ or _path_. That is the job of the **Ingress**: it defines a route to the service you deployed before.
-
-### What
-
-Create the manifest for an ingress and deploy it! 
+Pour les noms de domaine, il faut créer une entrée A sur le DNS qui redirige vers traefik. Cette partie a déja été fait pour vous, prenez juste un nom de domaine en ``.kube.test.viarezo.fr`` 
 
 ```yaml
-apiVersion: networking.k8s.io/v1
-kind: Ingress
+apiVersion: traefik.containo.us/v1alpha1
+kind: IngressRoute
 metadata:
-  name: my-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
+  name: <nom>
 spec:
-  rules:
-    - host: www.padok.fr
-      http:
-        paths:
-          - path: /blog
-            pathType: Prefix
-            backend:
-              service:
-                name: my-service
-                port:
-                  number: 80
+  entryPoints:
+    - websecure
+  routes:
+  - kind: Rule
+    match: Host(`<nom de domaine>`)
+    priority: 30
+    services:
+      - kind: Service
+        name: <nom du service>
+        port: <port>
+  tls:
+    secretName: <secrte du certificat>
 ```
-
-Here is the [usual documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) and commands:
-
-```bash
-kubectl get ingress
-kubectl describe ingress <my-ingress>
-# visit https://guestbook.vcap.me/
+Afin d'avoir du https il faut créer un certificat: 
+```yaml
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: <nom du certificat>
+spec:
+  secretName: <nom du secret du certificat>
+  dnsNames:
+    - <nom de domaine>
+  issuerRef:
+    name: letsencrypt
+    kind: ClusterIssuer
 ```
-
-### How
-
-1. Write a manifest and apply it. Choose a specific hostname for your app and your namespace if you share the cluster
-2. Try to access your app, do you have HTTPs ?
-3. Try to deploy your app on a _subpath_ using the `nginx.ingress.kubernetes.io/rewrite-target: /` annotation, or on a subdomain by modifying the `path` and host.
-
-### Checks
-
-- [ ] I can access the app from my navigator without a port forwarding
-
-<details>
-<summary><em>Compare your work to the solution before moving on. Are there differences? Is your approach better or worse? Why?</em></summary>
-
-You can find the complete solution [here](https://github.com/padok-team/dojo-guestbook/blob/feat/solution/manifests/ingress.yaml). Don't spoil yourself too much!
-
-</details>
+Ce certificat va être autaumatiquement être signé par Letsencrypt grace à certmanager un utilitaire installé sur les clusters. 
+A l'issue de cette étape vous devriez pouvoir acccéder à votre application en HTTPS sur votre nom de domaine !!
+Si c'est le cas bravo ! Sinon vous pouvez vérifier que votre ingress apparaaisse bien sur ``https://traefik.test.viarezo.fr``
 
 ## 9. Make it fail: probes