diff --git a/documentation/06.perspectives.md b/documentation/06.perspectives.md
index d8c163e5c743d6f5f6b77a9ff53ddb60d7227671..ef34c49ddeba54dca9301c4eda669310846e9f3d 100644
--- a/documentation/06.perspectives.md
+++ b/documentation/06.perspectives.md
@@ -10,11 +10,11 @@ Dans ce chapitre, je donne des pistes et des propositions pour de telles amélio
 
 ### Le proxy interne du cluster
 
-Le principal problème du proxy interne que j'ai mis en place est qu'il requiert une configuration des services "à la main". On y gagne beaucoup de souplesse, mais on perd l'automatisation des déploiements à moins de lui adjoindre une détection automatique des services et une forme de moteur de templating pour les configurations de nginx.
+Le principal problème du proxy interne que j'ai mis en place est qu'il requiert une configuration des services "à la main". On y gagne beaucoup de souplesse, mais on perd l'automatisation des déploiements à moins de lui adjoindre une détection automatique des services et une forme de moteur de templating avancé pour les configurations de nginx.
 
 - [Nginx](https://nginx.org) : solution de serveur web, reverse proxy et répartiteur de charge open source très légère et très performante
 - [Caddy](https://caddyserver.com/) : un serveur web open source très léger utilisant HTTPS par défaut
-- [Traefik](https://traefik.io/traefik/) : un reverse proxy / répartiteur de charge open source conçu pour faciliter le déploiement d’application en microservices via des API
+- [Traefik](https://traefik.io/traefik/) : un reverse proxy / répartiteur de charge open source conçu pour faciliter le déploiement d’application en micro services via des API
 - [HAProxy](https://www.haproxy.org/) : une solution de proxy et répartiteur de charge performante
 - [Nginx Proxy Manager](https://nginxproxymanager.com/) : proxy nginx avec une interface web de gestion des sites et configurations
 - [Nginx Unit](https://unit.nginx.org/) : version de nginx spécialisée pour les applications web et fournissant une API REST de contrôle et de configuration
@@ -256,25 +256,29 @@ Le prix à payer est une plus grande complexité dans sa prise en main.
 
 Contrairement à nginx-proxy, Traefik se base sur les labels associés à un service lors de son déploiement. Cela signifie que Traefik ne peut pas être utilisé de manière transparente en mode Compose ou en mode Swarm puisque la déclaration des labels est différente entre ces deux situations.
 
-Contrairement à nginx-proxy, Traefik offre une grande souplesse dans la définition des règles de proxy pour les différents services.  En particulier, il permet la publication d'un même service sur plusieurs fqdn ou sur des paths différents d'un même fqdn, la publication de plusieurs ports d'un même service sur des endpoints (paths ou fqdn) différents, la gestion fine des droits d'accès... Bref tout ce qui est nécessaire pour fournir à la fois un un hébergement d'application web et des API.
+Contrairement à nginx-proxy, Traefik offre une grande souplesse dans la définition des règles de proxy pour les différents services.  En particulier, il permet la publication d'un même service sur plusieurs fqdn ou sur des paths différents d'un même fqdn, la publication de plusieurs ports d'un même service sur des endpoints (paths ou fqdn) différents, la gestion fine des droits d'accès... Bref tout ce qui est nécessaire pour fournir à la fois un hébergement d'application web et des API.
 
 Le prix à payer est une plus grande complexité dans sa prise en main.
 
 
 ### Automatiser le renouvellement des certificats TLS avec Acme
 
-Il est aujourd'hui possible de renouveler les certificats des serveurs automatiquement avec ACME. Toutefois cette solution demande des adaptations au niveau du load-balancer SIPR. En effet, dans l'implémentation actuelle, le proxy HTTP et la gestion du certificat SSL se font au niveau du load-balancer. Hors, le renouvellement du certificat via ACME se fera au niveau des conteneurs. 
+Il est aujourd'hui possible de renouveler les certificats des serveurs automatiquement avec ACME. Toutefois cette solution demande des adaptations au niveau du load balancer SIPR. En effet, dans l'implémentation actuelle, le proxy HTTP et la gestion du certificat SSL se font au niveau du load balancer. Or, le renouvellement du certificat via ACME se fera au niveau des conteneurs. 
 
-Une solution est de passer à un répartition de charge TCP et laisser le proxy de l'infrastructure gérer les connexions sécurisées.
+Une solution est de passer à une répartition de charge TCP et laisser le proxy de l'infrastructure gérer les connexions sécurisées.
 
-Une autre, beaucoup plus intéressante, est de déplacer le renouvellement automatique des certificats sur le load balancer de SIPR. Les connexions sécurisées entre ce dernier et les machines du data center pourrait se faire avec des certificats internes. Les avantages de cette méthode sont multiples :
+Une autre, beaucoup plus intéressante, est de déplacer le renouvellement automatique des certificats sur le load balancer de SIPR. Les connexions sécurisées entre ce dernier et les machines du Data Center pourrait se faire avec des certificats internes certifié par une CA interne aux Data Centers. 
 
-- **Éviter la duplication** des clés privées et certificats entre le load balancer et les machines du data center, et les erreurs que cela peut entraîner
+Les avantages de cette seconde solution sont multiples :
+
+- **Éviter la duplication** des clés privées et certificats entre le load balancer et les machines du Data Center, et les erreurs que cela peut entraîner
 - Permettre le **renouvellement automatique** des certificats sur le load balancer lui-même, ce qui devrait éliminer les erreurs dues aux certificats expirés
 - Permettre un **inventaire** des différents FQDN utilisant des certificats puisque tous se trouvent sur le load balancer
 - **Augmenter la sécurité** en facilitant la révocation des certificats ou la suppression d'une clé privée
 - **Déplacer la responsabilité de la gestion** des clés et certificats aux équipes applicatives, qui n'ont pas toujours la maîtrise de ces outils et technologies, vers l'équipe système ou sécurité qui les maîtrise
 
+De plus, la CA interne pourrait être utilisée pour générer des certificats pour d’autres usages, par exemple sécurisé les connexions entre les nœuds de notre cluster Docker Swarm.
+
 > **Note** : la tendance actuelle, poussée par les GAFAM, est de réduire la durée de vie de certificats TLS. Passée de 3 ans à 1 an il y a quelques années, il est aujourd'hui question de réduire encore celle-ci à 90 jours. La gestion manuelle du renouvellement des certificats deviendra dès lors quasiment impossible, et l'automatisation du renouvellement sera obligatoire.
 
 ## Monitoring, alertes et logs
@@ -457,7 +461,7 @@ Son intégration à l'infrastructure mise en place par USSI ne devrait donc pose
 
 Actuellement, le partage des données de runtime entre les noeuds du swarm se fait grâce au partage NFS d'un volume depuis le manager1 du cluster. Cela permet de très bonnes performances lors des builds, mais l'indisponibilité du manager1 provoquera l'indisponibilité de tous le swarm. Cette solution bien que fonctionnelle n'est pas tellement désirable en production. Ce problème peut être mitigé par la mise en place de mesures en concertation avec l'équipe système : 
 
-- le déplacement du manager 1 vers un autre data center lors des interventions planifiées
+- le déplacement du manager 1 vers un autre Data Center lors des interventions planifiées
 - une procédure pour réinstancier rapidement le manager 1 en cas de crash
 - un monitoring méticuleux de l'infrastructure afin de détecter rapidement une indisponibilité
 
@@ -695,15 +699,15 @@ L'infrastructure décrite dans mon brevet pourrait toutefois être facilement in
 
 Une infrastructure de ce type devrait avoir
 
-- plusieurs nœuds managers : 3 semble un bon compromis entre redondance et performance, mais l'idéal est d'avoir un manager au moins dans chaque data center
+- plusieurs nœuds managers : 3 semble un bon compromis entre redondance et performance, mais l'idéal est d'avoir un manager au moins dans chaque Data Center
 - un plus grand nombre de nœuds workers
 
 ### Un registry centralisé
 
-Pourquoi ?
+Pourquoi ? Un registry centralisé pourrait avoir de nombreux avantages :
 
 - éviter de devoir construire les images sur chaque infrastructure
-- avoir les images à jour
+- avoir des images à jour
 - permettre de forcer la mise à jour des images des services afin de garantir la sécurité
 
 Une solution simple est d'utiliser le registry intégré à Gitlab afin d'assurer la centralisation des images et l'interopérabilité avec Gitlab.
@@ -737,10 +741,6 @@ Une manière de résoudre cela est d’automatiser le build des images en utilis
 
 Source : https://blog.nimbleci.com/2016/08/31/how-to-build-docker-images-automatically-with-jenkins-pipeline/
 
-### Des pistes pour automatiser la mise à jour des machines
-
-
-
 ## Vers une infrastructure basée sur Kubernetes et Rancher
 
 ### De « Docker Swarm is dead ? » à « Kubernetes will drop Docker support ! » : (r)évolutions et troubles dans le petit monde des conteneurs
@@ -749,9 +749,10 @@ Plusieurs annonces récentes posent question quant à l’avenir de la solution
 
 - Fin 2019, la maintenance de l’orchestrateur Docker Swarm annoncée jusque fin 2022 qui laissait penser à un abandon de cette solution suite au rachat de Docker Enterprise par Mirantis et de nombreuses rumeur annoncaient même la mort de Docker Swarm[^docker-swarm-is-dead][^mirantis][^swarmend]
 - Début 2020, toutefois, l’annonce de la continuation du développement et du support de Docker Swarm par Mirantis[^dockerswarmlives] est venue contredire les rumeurs de fin 2019
-- Fin 2020, l’annonce de l’abandon du support du moteur Docker par Kubernetes au profit d’autres solutions respectant la spécification CRI (Container Runtime Interface)[^ k8snodkcr][^k8sdropdocker][^k8sdropdocker2] est venue semer le trouble dans le petit monde des conteneurs. De son côté, la société Mirantis a annoncé dans les semaines suivantes qu'elle continuerait le développement d'une version compatible avec la CRI de l'interface Docker pour Kubernetes.
+- Fin 2020, l’annonce de l’abandon du support du moteur Docker par Kubernetes au profit d’autres solutions respectant la spécification CRI (Container Runtime Interface)[^ k8snodkcr][^k8sdropdocker][^k8sdropdocker2] est venue semer le trouble dans le petit monde des conteneurs. De son côté, la société Mirantis a annoncé dans les semaines suivantes qu'elle continuerait le développement d'une version compatible avec la spécification CRI de l'interface Docker pour Kubernetes.
+- Depuis 2022, l'abandon de Docker au profit de containerd dans Kubernetes est effectif.
 
-À ce stade, l’infrastructure mise en place dans le présent projet n’est donc pas directement menacée par ces bouleversements, et elle reste parfaitement indiquée tant pour l’infrastructure webpps que pour son utilisation pressentie pour le futur portail web de l'UCLouvain.
+À ce stade, l’infrastructure mise en place dans le présent projet n’est pas directement menacée par ces bouleversements, et elle reste parfaitement indiquée tant pour l’infrastructure webpps que pour son utilisation pressentie pour le futur portail web de l'UCLouvain.
 
 Toutefois, Docker Swarm présente quelques limitations par rapport à Kubernetes pour une utilisation sur des infrastructures à plus grande échelle. En particulier, il n’est pas compatible avec autant de solution d’hébergement cloud que Kubernetes et ses dérivés.
 
@@ -767,9 +768,9 @@ Il a l'avantage de reposer et de proposer une série d’API et de spécificatio
 
 Kubernetes est un système extrêmement personnalisable, en particulier via ses 3 définitions d’interface :
 
-- Container Network Interface (CNI) : définit les interfaces réseaux utilisables par Kubernetes (p. ex. Calico, Flannel ou Canal)
-- Container Runtime Interface (CRI) : définit l'interaction avec l’environnement d’exécution des conteneurs et intègre complètement les standards Open Container Initiative (OCI) (par exemple cri-conbtainerd, cri-o ou encore frakti)
-- Container Storage Interface (CSI) : définit les volumes utilisables comme stockage de Kubernetes
+- Container Network Interface (CNI) : spécifie les interfaces réseaux utilisables par Kubernetes (p. ex. Calico, Flannel ou Canal)
+- Container Runtime Interface (CRI) : spécifie l'interaction avec l’environnement d’exécution des conteneurs et intègre complètement les standards Open Container Initiative (OCI) (par exemple cri-conbtainerd, cri-o ou encore frakti)
+- Container Storage Interface (CSI) : spécifie les volumes utilisables comme stockage de Kubernetes
 
 ### Kubernetes et Docker
 
@@ -781,7 +782,7 @@ Plusieurs implémentations de cette API ont vu le jour dont les 2 principales so
 
 De son côté, Docker n’est pas compatible directement avec la spécification CRI et est connecté à Kubernetes via une couche supplémentaire appelée `dockershim`. Mais, depuis la mise en place de CRI-Containerd, Docker (lui-même construit au-dessus de `containerd`) constitue aujourd’hui une surcouche inutile entre Kubernetes et `containerd`.
 
-Tout cela a amené Kubernetes à abandonner le support de `dockershim` et, par extension, de Docker lui-même.
+Tout cela a amené Kubernetes à abandonner le support de `dockershim` et, par extension, de Docker lui-même auprofit de `containerd`.
 
 ### Kubernetes versus Docker Swarm