diff --git a/gitlab/applications_vitis/applications_vitis.md b/gitlab/applications_vitis/applications_vitis.md
deleted file mode 100644
index 78cd0cd8aa0114a96ae158b216c94bc532569349..0000000000000000000000000000000000000000
--- a/gitlab/applications_vitis/applications_vitis.md
+++ /dev/null
@@ -1,148 +0,0 @@
-# [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/applications_vitis/publier_application.md b/gitlab/applications_vitis/creer_application.md
similarity index 84%
rename from gitlab/applications_vitis/publier_application.md
rename to gitlab/applications_vitis/creer_application.md
index 9fc8c6e118124a01e42cf126a53e0c5166c9f602..1121ed7310b95a619b49a31b258e8c2449bafcf8 100644
--- a/gitlab/applications_vitis/publier_application.md
+++ b/gitlab/applications_vitis/creer_application.md
@@ -1,9 +1,8 @@
-
-## 2. Publier une application
+# [Procédure] Applications Vitis - Créer application
La première étape est de créer un dépôt dans Development/vitis_apps/application/[nom de votre application] il sera utile de d'initialiser avec ce dépôt les fichiers traditionnels README.md et .gitignore
-### 2.1. Dossier conf
+## 2. Dossier conf
Une fois le dépôt en place nous allons mettre en place les seuls fichiers de code qui seront relatifs à l'application (les autres seront liés à des modules), pour cela créer un dossier conf contenant la structure ci-dessous :
@@ -527,120 +526,4 @@ Properties client à intégrer
```
-Désormais notre application est viable et VAI saura la générer.
-
-### 2.2. Subtrees
-
-Quand on développe sur une application on a souvent à jongler entre les différents modules pour les mêmes fonctionnalités, pour animer cela le développeur peut faire usage de subtrees.
-
-Les subtrees sont une copie à un instant connu d'un dépot à l'intérieur d'un autre, grace à cette fonctionnalité nous pourrons sur notre application inclure les différents modules et les modifier directement depuis le dossier source.
-
-La première des choses à faire c'est d'inclure le subtree **utils** qui permettra d'automatiser les opérations de maintenance sur les autres subtrees, pour cela exécuter la commande ci-après.
-
-`git subtree add --prefix utils "git@gitlab.veremes.net:Development/vitis_apps/sources/utils.git" master`
-
-Une fois ceci fait un répertoire **utils** apparaît à la racine du projet.
-
-Pour initialiser les subtrees correspondant aux modules déclarés dans dependency.xml il suffira de se rentre dans le dossier utils et de lancer init_subtrees.sh
-
-Vos subtrees sont maintenant initialisés, vous pourrez les mettre à jour en utilisant utils/pull_subtrees.sh écrire dedans en utilisant utils/push_subtrees.sh
-
-Régulièrement j'utilise les fichiers ci-après que je place à la racine pour automatiser les différentes actions de maintenance
-
-**install.bat** : permet d'installer l'application suivant une installation faite précédemment avec VAI
-```
-@echo off
-title Install Vitis App
-echo Install Vitis App
-
-cd utils
-call init_tree.bat
-call copy_hooks.bat
-
-cd ../client/conf
-call npm install grunt --save
-call npm install grunt-cli
-call npm install grunt-closure-tools --save
-call npm install google-closure-compiler@20160911.0.0 --save
-call npm install google-closure-library@20160911.0.0 --save
-call grunt
-
-cd ..
-pause
-```
-
-**install.sh** : permet d'installer l'application suivant une installation faite précédemment avec VAI
-```
-#!/bin/bash
-#
-#
-# Script d'initialisation d'un dépot vMap versionné sous git
-# Initislise l'ensemble des dépendances sous forme de subtrees
-# Crée des symlinks pour re-créer l'arborescence de l'application
-#
-#
-
-if [ `whoami` == "root" ]; then
- echo "Please, do not run this script as sudo"
-else
- cd utils/
- ./init_symlinks.sh
- ./pull_subtrees.sh
- ./copy_hooks.sh
-
- cd ../conf
- npm install grunt --save
- npm install grunt-cli
- npm install grunt-closure-tools --save
- npm install google-closure-compiler@20160911.0.0 --save
- npm install google-closure-library@20160911.0.0 --save
- grunt -dev
-fi
-```
-
-**pull_subtrees.sh** : met à jour les subtrees des différents modules
-```
-#!/bin/bash
-#
-#
-# Récupère les modifications des modules sur l'application
-#
-#
-
-if [ `whoami` == "root" ]; then
- echo "Please, do not run this script as sudo"
-else
- cd utils/
- ./pull_subtrees.sh
-fi
-```
-
-**push_subtrees.sh** : push sur les différents modules
-```
-#!/bin/bash
-#
-#
-# Envoie les modifications de l'application sur les modules
-#
-#
-
-if [ `whoami` == "root" ]; then
- echo "Please, do not run this script as sudo"
-else
- cd utils/
- ./push_subtrees.sh
-fi
-```
-
-**update.bat** : cript de mise à jour pour Windows
-```
-@echo off
-title Update Vitis App
-echo Update Vitis App
-
-call utils/update_tree.bat
-
-cd client/conf
-call grunt
-
-pause
\ No newline at end of file
+Désormais notre application est viable et VAI saura la générer.
\ No newline at end of file
diff --git a/gitlab/applications_vitis/publier_version.md b/gitlab/applications_vitis/publier_version.md
new file mode 100644
index 0000000000000000000000000000000000000000..0a0758c672b5ab5b7480f34143d7133cdfb6df1c
--- /dev/null
+++ b/gitlab/applications_vitis/publier_version.md
@@ -0,0 +1,55 @@
+# [Procédure] Applications Vitis - Publier 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).
+
+
+
+## 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.
+
+
+
+## 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. 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
+
+## 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/applications_vitis/submodules.md b/gitlab/applications_vitis/submodules.md
new file mode 100644
index 0000000000000000000000000000000000000000..5b2ff33a2c580acd34911e5cb5206c2e86ec1887
--- /dev/null
+++ b/gitlab/applications_vitis/submodules.md
@@ -0,0 +1,90 @@
+# [Procédure] Applications Vitis - Submodules
+
+
+
+## 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. Effectuer une correction / évolution
+
+### 2.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 du module** une merge request ce qui aura pour effet de créer également la branche associée.
+
+### 2.2. GitKraken
+
+#### 2.2.1. Avant développement
+
+Pour faire une correction ou une évolution il va falloir modifier le contenu d'un des modules, dans notre exemple il s'agit d'une évolution au niveau 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 developpement, 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.**
+
+#### 2.2.2. Après développement
+
+Une fois les développements effectués vous pourrez commiter sur la branche impliquée, faire le push, puis assigner le responsable de projet.
+
+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 sur 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.
+
+En remontant au niveau de l'application 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.
\ No newline at end of file
diff --git a/gitlab/index.rst b/gitlab/index.rst
index caa51f3b9ce7f9e883eb97d068f46a5d0f11ea9d..d58ac65c36fef622de89f9668fe81ca0b648329c 100644
--- a/gitlab/index.rst
+++ b/gitlab/index.rst
@@ -7,4 +7,6 @@ GitLab
notions_git/index.rst
architecture_projets
correctifs_evolutions
- applications_vitis/applications_vitis.md
+ applications_vitis/submodules.md
+ applications_vitis/publier_version.md
+ applications_vitis/creer_application.md