diff --git a/documentation/06.perspectives.md b/documentation/06.perspectives.md
index c99ba6506581b55444b27c1743ea0333277aca09..6adb9f6db4e2d85e2af32638c17b97bf937cc7c7 100644
--- a/documentation/06.perspectives.md
+++ b/documentation/06.perspectives.md
@@ -10,7 +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 avancé pour les configurations de nginx.
+Le principal problème du reverse proxy interne que j'ai mis en place est qu'il ne permet pas une détection automatique des services déployés. Une autre de ses limitations est que si l'un des service exposés via mon proxy vient à ne plus répondre pour une raison ou pour une autre, c'est l'entièreté du proxy qui refusera de redémarrer. Cette situation peut se produire simplement si une pile applicative est arrêtée ou détruite et que le fichier de configuration du site correspondant n'a pas été supprimé du disque.
+
+Corriger ces quelques problèmes n'est pas impossible, mais requierait la mise en place de mécanismes qui existent déjà au sein d'autres solutions de reverse proxy.
+
+Les principales solutions de reverse proxy utilisées avec les conteneurs Docker sont les suivantes :
 
 - [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
@@ -18,7 +22,7 @@ Le principal problème du proxy interne que j'ai mis en place est qu'il requiert
 - [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
-- [nginx-proxy](https://github.com/nginx-proxy/nginx-proxy) : proxy basé sur nginx et intégrant une détection automatique des conteneurs exposés
+- [nginx-proxy](https://github.com/nginx-proxy/nginx-proxy) : reverse proxy basé sur nginx et intégrant une détection automatique des conteneurs exposés
 
 | Solution            | Détection auto. |
 | ------------------- | --------------- |
@@ -32,19 +36,21 @@ Le principal problème du proxy interne que j'ai mis en place est qu'il requiert
 
 *(\*) avec un module complémentaire*
 
-Les solutions les plus adaptées a Docker sont Caddy, Traefik et nginx-proxy. Parmi ces solutions, Traefik est la plus perfectionnée et offre des fonctionnalités adaptées à la mise à disposition de microservices sous forme d'API.
+Les solutions les plus adaptées a Docker sont Caddy, Traefik et nginx-proxy. 
+
+Parmi ces solutions, Traefik est la plus perfectionnée et offre des fonctionnalités adaptées à la mise à disposition de microservices sous forme d'API, mais nginx-proxy est de loin la plus simple à mettre en place. C'est à elles deux que je vais m'intéresser dans la suite, et plus spécifiquement à nginx-proxy.
 
 #### Solution n°1 : nginx-proxy
 
-Dans ce projet, j'ai décidé dans un premier temps de me baser sur [nginx-proxy](https://github.com/nginx-proxy/nginx-proxy). Il s'agit d'un reverse proxy basé sur Nginx et qui est capable de détecter les conteneurs automatiquement sans nécessiter ni rechargement du service ni génération de configuration. 
+Dans ce projet, j'ai décidé de me baser sur [nginx-proxy](https://github.com/nginx-proxy/nginx-proxy) afin de remplacer mon reverse proxy maison. Il s'agit d'un reverse proxy basé sur Nginx et qui est capable de détecter les conteneurs automatiquement sans nécessiter ni rechargement du service ni génération de configuration en interrogeant directement le daemon Docker. 
 
-Afin d'assurer la détection automatique des services exposés, il est nécessaire de leur ajoutes les variables d'environnement suivantes :
+Afin d'assurer la détection automatique des services exposés, nginx-proxy repose sur la déclaration de variables d'environnement :
 
-- `VIRTUAL_HOST` est le fqdn via lequel le conteneur est appelé
-- `VIRTUAL_PROTO` est le protocole avec lequel appeler service dans le Swarm (https ou http)
-- `VIRTUAL_PORT` est le port sur lequel est accessible le service
+- `VIRTUAL_HOST` est le fqdn via lequel le service est appelé depuis l'extérieur du Swarm
+- `VIRTUAL_PROTO` est le protocole avec lequel appeler service à l'intérieur du Swarm (https ou http), par défaut il est identique à celui utilisé depuis l'extérieur du Swarm
+- `VIRTUAL_PORT` est le port sur lequel est accessible le service dans le Swarm, par défaut il est identique à celui utilisé depuis l'extérieur du Swarm
 
-Afin que le proxy puisse les exposer, il faut encore les connecter sur un réseau partagé avec celui-ci. Le proxy détecte les services exposés via le socket Docker de la machine.
+Mais pour que nginx-roxy puisse joindre les services, il faut encore les connecter sur un réseau overlay partagé avec celui-ci. Le proxy détecte les services exposés via le socket Docker de la machine et sur base des variables d'environnement défines plus haut. Ensuite, un système de templates permet de générer les configurations de sites.
 
 > **Note**: Nginx proxy peut gérer le renouvellement automatique des certificats SSL soit via letsencrypt soit via ACME. Il peut aussi utiliser des certificats pré-générés fournit dans des fichiers locaux.
 
@@ -177,7 +183,9 @@ networks:
 
 #### Configuration du proxy pour les applications lourdes
 
-Nginx-proxy prévoit de pouvoir surcharger les configurations par défaut du reverse proxy, soit globalement, soit pour un vhost donné. Certaines applications plus lourdes, par exemple Drupal, demandent d'augmenter la taille des buffers de nginx. Il peut aussi être intéressant de modifier les options passées via le proxy.
+Nginx-proxy prévoit de pouvoir surcharger les configurations par défaut du reverse proxy, soit globalement, soit pour un vhost donné. 
+
+Certaines applications plus lourdes, par exemple Drupal, demandent d'augmenter la taille des buffers de nginx. Il peut aussi être intéressant de modifier les options passées via le proxy.
 
 ```conf
 # proxy.conf
@@ -244,22 +252,71 @@ networks:
     external: true
 ```
 
-Autre exemple, configurer la résolution d'adresse IP lorsque l'on est derrière un proxy-répartiteur de charge.
+> **Notes** : 
+> - Comme pour mon reverse proxy « maison », la récupération de l'IP réelle du client demande de modifier le fichier nginx.conf du service. La manière de procéder est totalement identique (récupérer le fichier original depuis le conteneur, par exemple avec `docker cp`), ajouter les lignes manquantes et monter le nouveau fichier à l'emplacement `/etc/nginx/nginx.conf`. Il est également possible de le faire directement dans un fichier Dockerfile qui construit l'image de nginx-proxy.
+> - nginx-proxy est en développement actif et des nouvelles fonctionnalités s'ajoutent régulièrement. L'état du projet peut être consulté via [son dépôt Github](https://github.com/nginx-proxy/nginx-proxy).
 
 #### Pour aller encore plus loin : Traefik
 
 La solution nginx-proxy est tout à fait satisfaisante pour la mise en place d'une infrastructure d'hébergement d'application web de type "single page", blog ou autre CMS. Elle est par contre moins adaptée s'il s'agit de mettre en place une infrastructure donnant accès à des web services via des API REST, GraphQL, SOAP... Dans ce cas de figure, Traefik est la solution la plus adaptée. 
 
-La solution la plus adaptée a Docker Swarm est Traefik. 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.
+La solution la plus adaptée a Docker Swarm est Traefik. 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 et la publication de services via des API.
 
 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 qui utilisait des variables d'environnement, 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 hébergement d'application web et des API.
+A titre d'exemple, voici le fichier permettant de déployer Portainer avec Traefik dans un Swarm :
 
-Le prix à payer est une plus grande complexité dans sa prise en main.
+```yaml
+version: '3.2'
+
+services:
+  agent:
+    image: portainer/agent:latest
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock
+      - /var/lib/docker/volumes:/var/lib/docker/volumes
+    networks:
+      - agent_network
+    deploy:
+      mode: global
+      placement:
+        constraints: [node.platform.os == linux]
 
+  portainer:
+    image: portainer/portainer-ce:latest
+    command: -H tcp://tasks.agent:9001 --tlsskipverify
+    ports:
+      - "9443:9443"
+      - "9000:9000"
+      - "8000:8000"
+    volumes:
+      - portainer_data:/data
+    networks:
+      - agent_network
+      - proxy_net
+    deploy:
+      mode: replicated
+      replicas: 1
+      placement:
+        constraints: [node.role == manager]
+      labels:
+        - "traefik.enable=true"
+        - "traefik.docker.network=proxy_net"
+        - "traefik.http.routers.portainer.rule=Host(`portainer.docker.localhost`)"
+        - "traefik.http.services.portainer.loadbalancer.server.port=9000"
+
+networks:
+  proxy_net:
+    external: true
+  agent_network:
+    driver: overlay
+    attachable: true
+
+volumes:
+  portainer_data:
+```
 
 ### Automatiser le renouvellement des certificats TLS avec Acme