diff --git a/gitlab/applications_vitis/applications_vitis.md b/gitlab/applications_vitis/applications_vitis.md
new file mode 100644
index 0000000000000000000000000000000000000000..78cd0cd8aa0114a96ae158b216c94bc532569349
--- /dev/null
+++ b/gitlab/applications_vitis/applications_vitis.md
@@ -0,0 +1,148 @@
+# [Procédure] Applications Vitis
+
+## 1. Submodules
+
+### 1.1. Definition
+
+Les applications Vitis sont des ensemble de modules composés potentiellement eux mêmes de SQL, Backend et Frontend, chaque application ainsi que chaque module doivent être versionnés, tagués et mis à jour en permanence, comme vous pouvez l’imaginer tout ceci rend l’opération particulièrement difficile à versionner.
+
+Pour faire ceci le plus simplement possible, nous utiliserons des submodules, un submodule est clairement un dépôt contenu dans un dépôt mais en gardant un certain lien.
+
+
+
+L'image ci-dessus est l'exemple du dossier src/ de vMap, on retrouve dans ce dossier l'ensemble des modules et autres dépendances utilisées par l'application :
+
+* closure : utilisé pour la compilation
+* module_anc : module anc
+* module_cadastre : module cadastre
+* module_cadastreV2 : module cadastreV2
+* module_vm4ms : module vm4ms
+* module_vmap : module vMap
+* vitis : framework Vitis
+
+Vous remarquerez sur cette image que chaque submodule inscrit après son nom une référence :
+
+
+
+Cette référence correspont à un commit, il est très important de comprendre que **un submodule contient un depôt non sur sa version en cours mais sur un commit précis**.
+
+Gitkraken gère parfaitement les submodules, en ouvrant le projet il va directement détecter l'ensemble des submodules utiliés, puis il permettra de les administrer facilement.
+
+Sur l'image ci-dessous on voit le projet vMap contenant les différents submodules.
+
+
+
+
+
+### 2.1. Effectuer une correction / évolution
+
+#### 2.1.1. GitLab
+
+Chaque issue est répertoriée dans un premier lieu au niveau de l'application, lorsqu'elle sera identifiée l'administrateur la copiera dans le(s) module(s) impacté.
+
+Lors de la copie il mentionnera l'URL de l'issue de l'application, ainsi un lien sera crée entre les deux.
+
+|  |  |
+|:----------------------------:|:----------------------------:|
+| Application | Module |
+
+Pour commencer le correctif, le développeur créera **depuis l'issue de la branche** une merge request ce qui aura pour effet de créer également la branche associée.
+
+#### 2.2.1. GitKraken
+
+#### Avant correction / évolution
+
+Pour faire une correction ou une évolution il va falloir modifier le contenu d'un des modules, dans notre exemple il s'agit du module_vmap.
+
+En doublecliquant sur le submodule GitKraken me propose de l'ouvrir.
+
+|  |  |
+|:----------------------------:|:----------------------------:|
+| Application | Module |
+
+
+Une fois dedans deux détails sont importants à remarquer.
+
+* Sur le bandeau du haut on voit bien qu'on se situe sur le submodule, plus précisément sur une branche **HEAD**.
+* Parmis les branches disponibles, on me propose la branche correspondant à l'issue que je veux corriger.
+
+Pour commencer le correctif, double-cliquer sur la branche en question pour se placer dessus.
+
+**Vous pouvez désormais effectuer vos correctifs directement dans le répertoire src/ de l'application.**
+
+#### Après correction / évolution
+
+Une fois les développements effectués vous pourrez commiter sur la branche impliquée, faire le push, puis assigner le responsable de projet à la merge request pour qu'il l'accepte et que les changements se retrouvent sur master/next_version.
+
+Une fois la merge request acceptée, GitKraken nous indique que nous devons faire un pull sur next_version (car sur l'exemple il s'agit d'une évolution).
+
+
+
+Il ne restara qu'à re-passer master/next_version puis faire un pull pour rapatrier les modifications précédament effectuées pour que le module soit à jour.
+
+
+L'application quand à elle pointe toujours sur le même commit qui lui sert de référence.
+
+Quand on remote d'un cran sur GitKraken on remarque donc qu'il y a eut des modifications sur module_vmap.
+
+En faisant un clic droit et en cliquant sur **Commit changes** on modifie le commit de référence par le nouveau, désormais lorsque quelqu'un fera un clone il disposera de la nouvelle feature.
+
+
+
+
+
+
+
+## 2. Publier une version
+
+On peut facilement publier une version en 4 étapes à l'aide d'outils automatisés, on distinguera deux types de versions, les **versions mineures** correspondant à des corrections de bugs qui seront taguées en changeant uniquement le dernier nombre (ex: 2018.01.**xx**), les **versions majeures** correspondent à des évolutions apportées au produit, elles seront taguées en changeant le nombre du milieu (ex: 2018.**xx**.00).
+
+### 3.1. Versionner les modules impactés
+
+La première chose à faire c'est de versionner les modules modifiés, pour cela on va aller sur la branche impactée pour créer une branche qui portera comme nom le nom **pre-2018.xx.xx**.
+
+Dans notre exemple on veut créer une version mineure, la version en cours est la 2018.03.01 on créera donc une branche pre-2018.03.02
+
+La deuxième chose à faire c'est de versionner l'application, pour cela on créera une branche portant le nom de la version à générer, puis on modifiera le fichier **conf/\_install/dependency.xml** pour utiliser les branches de pre-production et enfin on utilisera GitKraken pour rapatrier les nouvelles branches sur l'application.
+
+
+
+### 3.2. Générer une version pre-prod et effectuer les tests
+
+Maintenant que la structure est versionnée il faudra générer un setup et effectuer les tests, pour cela il suffit de ce rendre sur http://jenkins.veremes.net/ et lancer un job de type **Generate un and test app**.
+Ce dernier va générer un setup, le poser sur S3, démarrer une machine AWS, installer la version dessus et lancer les tests API-REST.
+
+Pour lancer le job il faudra saisir les paramètres suivants:
+
+* **APP_NAME** : nom de l’application à générer
+* **OS** : le ou les OS sur lesquels installer
+* **VERSION** : numéro de version à générer
+* **RUN TEST** : cocher la case pour lancer les tests API-REST (en cours de développement)
+
+
+
+Une fois le job terminé vous pouvez récupérer l'url de l'application générée en cliquant sur l'étape "*Run app on ...*" puis aller tester manuellement l'application.
+
+
+
+**Il est important d'effectuer également des tests en mise à jour**, aucun job n'a été développé pour l'instant donc il faudra effectuer le test manuellement.
+
+
+### 3.3. Créer les tags associés
+
+Une fois que les tests sont concluants on pourra créer les tags associés pour ceci il faudra sur chacune des branches modifiées appliquer la procédure suivante :
+
+1. Faire un merge vers master
+1. Créer un tag à partir de la branche pre-prod
+
+Pour l'application la procédure est légèrement différente :
+
+1. Modifier dependency.xml pour utiliser les tags créés précédemment
+1. Utiliser GitKraken pour tester localement la configuration
+1. Créer un tag à partir de la branche pre-prod
+
+### 3.4. Générer une version de production
+
+La dernière étape consiste à rejouer l'étape 2.2 puis récupérer le setup généré sur https://s3.console.aws.amazon.com/s3/buckets/veremes-dev-ressources/builds/
+
+Une fois que tout est ok, on peut supprimer les branches de pré-production
diff --git a/gitlab/images/publier_version_1.jpg b/gitlab/applications_vitis/images/publier_version_1.jpg
similarity index 100%
rename from gitlab/images/publier_version_1.jpg
rename to gitlab/applications_vitis/images/publier_version_1.jpg
diff --git a/gitlab/images/publier_version_2.jpg b/gitlab/applications_vitis/images/publier_version_2.jpg
similarity index 100%
rename from gitlab/images/publier_version_2.jpg
rename to gitlab/applications_vitis/images/publier_version_2.jpg
diff --git a/gitlab/images/publier_version_3.jpg b/gitlab/applications_vitis/images/publier_version_3.jpg
similarity index 100%
rename from gitlab/images/publier_version_3.jpg
rename to gitlab/applications_vitis/images/publier_version_3.jpg
diff --git a/gitlab/applications_vitis/images/submodules-1.jpg b/gitlab/applications_vitis/images/submodules-1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..37167d3da393b8f789690af86004011ce7e57eaf
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-1.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-10.jpg b/gitlab/applications_vitis/images/submodules-10.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..e1514c5f5cc7ef07602e50b3901c84ab05e3d566
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-10.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-2.jpg b/gitlab/applications_vitis/images/submodules-2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..c6b6bb14ba54e4c38663c62e67b3a1f27d7e3a27
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-2.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-3.jpg b/gitlab/applications_vitis/images/submodules-3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..d1d79c290054ebcb5e87400ae1e2a552bc039c2e
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-3.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-4.jpg b/gitlab/applications_vitis/images/submodules-4.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..448ee733224910f09d3e74d59dfe39fd4e0a57bd
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-4.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-5.jpg b/gitlab/applications_vitis/images/submodules-5.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..5487b967eddcc303653b17a4e067477d2e71ece5
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-5.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-6.jpg b/gitlab/applications_vitis/images/submodules-6.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..918b7a9d8b1f37e7a602509679804ed9ed02fe7c
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-6.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-7.jpg b/gitlab/applications_vitis/images/submodules-7.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..75406e343ef6802e594ce2b2697c997aa302fa5e
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-7.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-8.jpg b/gitlab/applications_vitis/images/submodules-8.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..96caa8a1c1b0f7ed6dd3d7ed7fa9c8775d1b1199
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-8.jpg differ
diff --git a/gitlab/applications_vitis/images/submodules-9.jpg b/gitlab/applications_vitis/images/submodules-9.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..5cefa0b7d93c9d759e15bfdbd580f89dc4898409
Binary files /dev/null and b/gitlab/applications_vitis/images/submodules-9.jpg differ
diff --git a/gitlab/applications_vitis.md b/gitlab/applications_vitis/publier_application.md
similarity index 75%
rename from gitlab/applications_vitis.md
rename to gitlab/applications_vitis/publier_application.md
index 9a27292654f2dccd2b5bf45477408abe57f8e532..9fc8c6e118124a01e42cf126a53e0c5166c9f602 100644
--- a/gitlab/applications_vitis.md
+++ b/gitlab/applications_vitis/publier_application.md
@@ -1,59 +1,3 @@
-# [Procédure] Applications Vitis
-
-## 1. Structure
-
-### 1.1. Subtrees
-
-#### 1.1.1. Définition
-
-Les applications Vitis sont des ensemble de modules composés potentiellement eux mêmes de SQL, Backend et Frontend, chaque application ainsi que chaque module doivent être versionnés, tagués et mis à jour en permanence, comme vous pouvez l'imaginer tout ceci rend l'opération particulièrement difficile à versionner.
-
-Pour faire ceci le plus simplement possible, nous utiliserons des [subtrees](https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree), un subtree est clairement un dépôt contenu dans un dépôt mais en gardant un certain lien :
-
-* Quand dans Repo1 on crée le subtree de Repo2 une copie des fichiers de Repo2 est effectuée dans Repo1
-* Si on commite sur Repo2 les modifications ne sont pas impliquées directement dans Repo1, il faudra utiliser pull_subtrees.sh sur Repo1 pour se faire.
-* Si on comite sur Repo1 les modifications ne sont pas impliquées directement dans Repo2, il faudra utiliser push_subtrees.sh sur Repo1 pour se faire.
-
-
-
-#### 1.1.2. Subtrees dans les applications
-
-Plusieurs fichiers utilitaires sont disponibles sur les applications pour agir sur les subtrees :
-- **pull_subtrees.sh** : permet de mettre à jour l'ensemble des subtrees
-- **push_subtrees.sh** : fait un push sur chacun des subtrees pour affecter les modifications sur les dépôts de modules correspondants
-- **utils/init_subtrees.sh** : permet de créer l'ensemble des subtrees dans le dossier src/ de l'application
-
-L'ensemble des dépendances sont définies sur le fichier **conf/\_install/dependency.xml**.
-
-
-
-Pour éviter les conflits il est préférable de câbler les applications sur des branches, ainsi l'application vMap qui contient vitis utilisera les branches **app_vmap** et **next_app_vmap** utilisées respectivement sur les branches master et next_version de l'application.
-
-
-
-Quand on crée une branche pour effectuer un correctif ou une évolution pas besoin de s'inquiéter à propos des subtrees : comme il s'agit d'une copie des fichiers les modifications feront partie du merge et seront rapatriés sur master ou next_version.
-
-L'utilisation de **pull_subtrees.sh** et **push_subtrees.sh** se fera uniquement depuis les branches **master** et **next_version**.
-
-### 1.2. Installation locale
-
-Pour utiliser une application versionnée localement, il faudra l'installer car l'architecture proposée avec les dépendances dans le dossier src/ ne convient pas, pour ce faire nous utiliserons des liens symboliques sur linux et des copies de fichiers sous windows.
-
-Pour créer ces liens de manière automatique on peut utiliser la procédure suivante :
-
-1. Installer l'application avec un installeur VAI de manière à mettre en place properties et autres services en fonction des paramètres de votre machine.
-2. Cloner l'application puis lancer insall.sh, ce dernier vous demandera le chemin vers une application déjà installée sur la machine de manière à copier properties et autres services paramétrés précédemment.
-3. Placer l'application clonée au même endroit que l'application précédement installée avec VAI.
-
-Une fois ceci fait les dossiers client/ et vas/ seront créés et vous pourrez modifier directement les fichiers dans le dossier src/ ou directement dans client/ et vas/.
-
-Sur **windows** les liens symboliques ne permettent pas leur utilisation dans ce contexte, il faudra donc éditer dans **src/** puis lancer **update.bat** pour appliquer les modifications.
-
-
-
-
-
-
## 2. Publier une application
@@ -699,62 +643,4 @@ call utils/update_tree.bat
cd client/conf
call grunt
-pause
-```
-
-
-
-## 3. Publier une version
-
-On peut facilement publier une version en 4 étapes à l'aide d'outils automatisés, on distinguera deux types de versions, les **versions mineures** correspondant à des corrections de bugs qui seront taguées en changeant uniquement le dernier nombre (ex: 2018.01.**xx**), les **versions majeures** correspondent à des évolutions apportées au produit, elles seront taguées en changeant le nombre du milieu (ex: 2018.**xx**.00).
-
-### 3.1. Versionner les modules impactés
-
-La première chose à faire c'est de versionner les modules modifiés, pour cela on va envoyer les modifications au module en utilisant **push_subtrees.sh**, puis aller sur la branche impactée pour créer une branche qui portera comme nom le nom **pre-2018.xx.xx**.
-
-Dans notre exemple on veut créer une version mineure, la version en cours est la 2018.03.01 on créera donc une branche pre-2018.03.02
-
-
-
-La deuxième chose à faire c'est de versionner l'application, pour cela on créera une branche portant le nom de la version à générer, puis on modifiera le fichier **conf/\_install/dependency.xml** pour utiliser les branches de pre-production et enfin on utilisera **pull_subtrees.sh** pour rapatrier les nouvelles branches sur l'application.
-
-
-### 3.2. Générer une version pre-prod et effectuer les tests
-
-Maintenant que la structure est versionnée il faudra générer un setup et effectuer les tests, pour cela il suffit de ce rendre sur http://jenkins.veremes.net/ et lancer un job de type **Generate un and test app**.
-Ce dernier va générer un setup, le poser sur S3, démarrer une machine AWS, installer la version dessus et lancer les tests API-REST.
-
-Pour lancer le job il faudra saisir les paramètres suivants:
-
-* **APP_NAME** : nom de l’application à générer
-* **OS** : le ou les OS sur lesquels installer
-* **VERSION** : numéro de version à générer
-* **RUN TEST** : cocher la case pour lancer les tests API-REST (en cours de développement)
-
-
-
-Une fois le job terminé vous pouvez récupérer l'url de l'application générée en cliquant sur l'étape "*Run app on ...*" puis aller tester manuellement l'application.
-
-
-
-**Il est important d'effectuer également des tests en mise à jour**, aucun job n'a été développé pour l'instant donc il faudra effectuer le test manuellement.
-
-
-### 3.3. Créer les tags associés
-
-Une fois que les tests sont concluants on pourra créer les tags associés pour ceci il faudra sur chacune des branches modifiées appliquer la procédure suivante :
-
-1. Faire un merge vers master
-1. Créer un tag à partir de la branche pre-prod
-
-Pour l'application la procédure est légèrement différente :
-
-1. Modifier dependency.xml pour utiliser les tags créés précédemment
-1. Utiliser pull_subtrees.sh pour être sur d'avoir intégré toutes les modifications
-1. Créer un tag à partir de la branche pre-prod
-
-### 3.4. Générer une version de production
-
-La dernière étape consiste à rejouer l'étape 2.2 puis récupérer le setup généré sur https://s3.console.aws.amazon.com/s3/buckets/veremes-dev-ressources/builds/
-
-Une fois que tout est ok, on peut supprimer les branches de pré-production
+pause
\ No newline at end of file
diff --git a/gitlab/index.rst b/gitlab/index.rst
index bfac8a5052a43aaf9a4750682386c20f43dd64f4..23b52415e01af06c7c14f9dbe0c36e5b2834adf7 100644
--- a/gitlab/index.rst
+++ b/gitlab/index.rst
@@ -7,4 +7,4 @@ GitLab
notions_git/index.rst
architecture_projets
correctifs_evolutions
- applications_vitis
+ applications_vitis/applications_vitis