diff --git a/tutorial/docker-orchestration/machine.md b/tutorial/docker-orchestration/machine.md
index e64d9e0..4a803d9 100644
--- a/tutorial/docker-orchestration/machine.md
+++ b/tutorial/docker-orchestration/machine.md
@@ -5,12 +5,24 @@ Création du cluster
## Le provisionnement de machine
-Pour travailler sur un cluster, il faut avoir plusieurs machines. Au moins plus
-d'une !
+Pour travailler sur un cluster, il faut avoir plusieurs machines ... au moins
+plus d'une !
-TODO parler du clustering et du provisionning
+Mais qui dit plusieurs machines, dit généralement de nombreuses installations à
+faire, de nombreuses configurations à partager, etc. Tout ce qu'un
+administrateur système redoute : du travail !
-TODO parler des concurrents
+Évidemment, de nombreuses solutions existent pour travailler moins, tout en
+déployant plus et de manière plus fiable ! On peut parler
+d'[`ansible`](https://www.ansible.com/), de
+[`chef`](https://docs.chef.io/provisioning.html), ou encore de
+[`puppet`](https://puppet.com/products/capabilities/automated-provisioning),
+... Toutes ces solutions permettent d'obtenir des configurations finement
+personnalisées, mais nécessitent une phase d'apprentissage plutôt lourde.
+
+Comme nous voulons lancer des conteneurs, les machines à provisionner n'ont pas
+besoin de configuration bien particulière et les seuls paquets importants sont
+une version récente de `docker` et ses dépendances.
## Provisionner des machines ...
diff --git a/tutorial/docker-orchestration/project.md b/tutorial/docker-orchestration/project.md
index b8962af..8186f19 100644
--- a/tutorial/docker-orchestration/project.md
+++ b/tutorial/docker-orchestration/project.md
@@ -8,6 +8,45 @@ Rendu
Écrivez le `docker-compose.yml` permettant de lancer facilement une
instance de serveur du FIC.
+### Stage 1 : `Dockerfile`
+
+* admin
+* backend
+* frontend
+
+
+### Stage 2 : `docker-compose.yml` simple
+
+* admin
+* backend
+* frontend
+* mysql
+
+
+### Stage 2 (bis) : `docker-compose.yml` avec autentification
+
+* admin
+* backend
+* frontend
+* mysql
+* nginx (auth)
+
+
+### Stage 3 : `fic-server.yml` sécurisé
+
+* admin
+* backend
+* frontend
+* mysql
+* nginx (auth)
+
+Utilisant `docker secrets` et `docker config`.
+
+
+### Stage 4 : `fic-server.yml` production ready
+
+ssh between back and front et sur deux machines distinctes
+
## Modalité de rendu
diff --git a/tutorial/docker-orchestration/swarm.md b/tutorial/docker-orchestration/swarm.md
index a27edd6..3fbead6 100644
--- a/tutorial/docker-orchestration/swarm.md
+++ b/tutorial/docker-orchestration/swarm.md
@@ -1,34 +1,158 @@
\newpage
-Cluster Swarm
-=============
+Déploiement de conteneurs
+=========================
+
+Historiquement, le passage d'une application en production ou simplement dans
+un environnement de qualification, n'est pas toujours aisé. Parfois d'ailleurs,
+on ne teste pas, on fait les modifications en production ... et à chaque
+déploiement, on prie pour ne pas écraser une modification qui faisait que notre
+projet tombait en marche dans cet environnement.
+
+Déployer des conteneurs sur sa propre machine, c'est extrêmement simple
+grâce. Et mieux encore, tout l'environnement étant contenu dans l'image, il
+suffit de suivre les bonnes pratiques pour que le déploiement en production se
+fasse de manière transparente.
+
## L'orchestration
-Déployer des conteneurs sur sa propre machine, c'est extrêmement simple grâce à
-Docker. Mais souvent, le passage d'une application en production ou simplement
-dans un environnement de qualification, n'est pas toujours aisé.
+Cependant, notons une différence de taille entre notre environnement de
+développement sur nos machines locales et la production : les clients ! Pour
+répondre de manière adéquate, il convient de dimensionner correctement les
+machines, le nombre de conteneurs que chacune peut exécuter, en fonction de
+caractéristiques (on privilégiera les machines avec des SSD pour les serveurs
+de base de données par exemple), ...
-Il n'est pas question pour un administrateur système de faire la répartition de
-la charge à la main : afin de ne pas trop charger un serveur qui pourrait
-recevoir des pics, alors que d'autres serveurs attendent des calculs.
+Il n'est pas question pour un administrateur système de faire cette répartition
+de la charge à la main : le nombre de critères à prendre en compte est beaucoup
+trop grand, évolue sans cesse ; cela serait trop long s'il y a beaucoup de
+conteneurs et de variété de machines.
Ce processus d'optimisation s'appelle l'*orchestration*. Il s'agit de réussir à
-répartir au mieux les conteneurs dans notre environnement de production
+répartir au mieux les conteneurs sur les différentes machines disponibles.
+
+Ce sujet fait l'objet de très nombreuses thèse depuis plusieurs années (avant
+les conteneurs, c'était pour répartir les machines virtuelles entre différents
+hôtes), et autant de projets disponibles. Citons par exemple
+[Apache Mesos](https://mesos.apache.org/),
+[Hashicorp Nomad](https://www.nomadproject.io/) ou encore
+[Google Kubernetes](https://kubernetes.io), ...
+
+Le point commun entre la plupart des orchestrateurs, c'est généralement leur
+extrême complexité de mise en œuvre. Dans le cadre de notre TP, nous allons
+plutôt utiliser l'orchestrateur intégré à Docker, dont la caractéristique
+principale est sa simplicité[^dockerconEU2017].
+
+[^dockerconEU2017]: À noter qu'une annonce faite à la Docker Con EU 2017 (mardi
+ dernier) indique le début du support de Kubernetes au sein de Docker,
+ pouvant être utilisé en symbiose avec Swarm.
+
+
+### Concepts clefs
+
+Regroupés au sein d'un cluster (on parle de *swarm* pour Docker), chaque
+*Docker engine* représente un nœud (*node*) dans lequel on va déployer des
+*services*.
+
+Certain nœud ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
+prendra les décisions d'orchestration. Les autres sont là pour prendre le
+relais en cas de dysfonctionnement sur le manager élu.
+
+Les services sont un groupe de tâches (typiquement une image avec sa ligne de
+commande à lancer) que le `manager` va conserver à l'état désiré. Le service va
+indiquer par exemple le nombre d'instances que l'on désire avoir dans le
+cluster. En cas de crash d'un manager ou d'un *worker*, le (nouveau) manager
+fera en sorte de redéployer les conteneurs perdus, afin de toujours maintenir
+le cluster dans l'état désiré.
+
+En terme de cluster, des tâches sont l'équivalent des conteneurs, hors de Swarm.
+
## Création du cluster Swarm
-`docker swarm`
+### Initialisation du cluster
-### Le maître
+La première chose à faire, est d'initialiser un cluster swarm. Pour se faire,
+ce n'est pas plus compliqué que de faire :
-#### Initialisation du cluster
+
+```shell
+docker swarm init
+```
+
-#### Présentation des mécanismes de sécurité
+Cela va créer un cluster mono-nœud, sur la machine courante (celle pointée par
+la variable `DOCKER_HOST`). Ce nœud est automatiquement passé *manager* du
+cluster, afin de pouvoir lancer des tâches ... au moins sur lui-même en
+attendant d'autres nœuds.
-### Les nodes
+### Rejoindre le cluster
-#### Enregistrement d'un esclave
+Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
+cluster.
-#### Multi-maître
+La commande pour rejoindre le cluster et contenant le jeton, est indiquée
+lorsque vous initialisez le cluster. Si vous avez raté la sortie de la
+commande, vous pouvez retrouver le jeton avec :
+
+
+```shell
+docker swarm join-token worker
+```
+
+
+Lançons maintenant la commande `join` indiquée, sur une autre machine, en
+utilisant `docker-machine`.
+
+**Pro tips:** envoyez votre commande `join` à votre voisin qui a réussi à
+ provisionner plusieurs machines Docker (via `docker-machine` ou manuellement,
+ peu importe du moment que les VMs ont bien accès au même réseau que votre
+ *Swarm*[^avertVM]). Et soyez fair-play, attendez un peu avant de lancer
+ l'image `embano1/cpuburn` ;)
+
+[^avertVM]: Si vous utilisez Docker dans une VM, il faut que celle-ci soit
+ configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
+ a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
+ primordial que les managers soient joignables. Vous pouvez tenter de faire
+ des redirections de ports, mais le résultat n'est pas garanti !
+
+
+```shell
+eval $(docker-machine env echinoidea)
+docker swarm join --token SWMTKN-1-...-... 10.10.10.42:2377
+```
+
+
+Une fois rejoint, vous devriez voir apparaître un nouveau nœud *worker* dans :
+
+
+```shell
+42sh$ eval $(docker-machine env -u)
+42sh$ docker node ls
+ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
+y9skzvuf989hjrkciu8mnsy echinoidea Ready Active
+ovgh6r32kgcbswb2we48br1 * wales Ready Active Leader
+```
+
+
+
+### Rejoindre en tant que manager
+
+Lorsqu'il est nécessaire d'avoir de la haute-disponibilité, on définit
+plusieurs managers. Cela permet qu'en cas de dysfonctionnement du manager, un
+nouveau manager soit élu.
+
+Nous n'allons pas faire rejoindre de manager supplémentaire durant ce TP, mais
+vous pouvez facilement expérimenter la chose en lançant 5 machines virtuelles
+et en définissant trois des cinq machines comme étant managers.
+
+Pour que l'algorithme de consensus fonctionne de manière optimale, il convient
+toujours un nombre impair de managers, Docker en recommande 3 ou 5. La pire
+configuration est avec deux managers, car si un tombe, il ne peut pas savoir si
+c'est lui qui est isolé (auquel cas il attendrait d'être à nouveau en ligne
+avant de se proclamer leader) ou si c'est l'autre manager qui est tombé. Avec
+trois managers, en cas de perte d'un manager, les deux restants peuvent
+considérer qu'ils ont perdu le troisième et peuvent élire le nouveau manager
+entre-eux et continuer à faire vivre le cluster.