diff --git a/gitlab/correctifs_evolutions.md b/gitlab/correctifs_evolutions.md
new file mode 100644
index 0000000000000000000000000000000000000000..af40099058813cc037beedfe952663a7aa72a89f
--- /dev/null
+++ b/gitlab/correctifs_evolutions.md
@@ -0,0 +1,103 @@
+# Correctifs et évolutions
+
+## Branches principales
+
+### Pour les projets FME
+
+Quand les projet abritent des fichiers non textuels (audio, fmw, zip etc..) des conflits non résolvables vont apparaître régulièrement lors des étapes de merge, dans ce cas il est préférable de créer une branche de travail ouverte à tous les contributeurs, de protéger la branche master pour y faire des merge quand les développements ont étés validés.
+
+### Pour les projets de développement
+
+Dans ce cas il est possible d'utiliser 100% des capacités de Git et c'est ce que nous allons faire en appliquant la procédure suivante.
+
+Sur la branche **master** nous appliquerons uniquement les correctifs, cette branche **doit absolument être stable** à tout moment car elle permettra de générer un correctif quand on le souhaite.
+
+Une deuxième branche **next_version** permettra quand à elle à appliquer les évolutions, quand des correctifs sont appliqués à master, il faudra les merger sur cette branche de manière à avoir les dernières évolutions ainsi que les derniers correctifs.
+
+Une fois les développements d'une version terminés il est important de tester dans un environnement de pré-production notre application, à ce moment nous créerons à partir de next_version une branche **20xx.xx.xx** contenant le numéro de build à générer (on utilise parfois **pre_prod** si il n'y a pas de numéro associé).
+Les correctifs à effectuer se feront sur master puis seront mergés sur next_version et sur la branche de pré-production.
+
+Quand l'environnement de pré-production est validé, il est alors mergé sur next_version puis sur master à partir duquel on créera le tag correspondant.
+
+
+
+## Faire un correctif
+
+*Cette section est réservée aux projet de développement*
+
+Un correctif est un bug remonté sur l'application en cours de production qui doit être corrigé pour publier une nouvelle version mineure, pour ce faire on créera une branche **à partir de master** qui se nommera bug/[intitulé du bug].
+
+Une fois le bug corrigé nous le rapatrierons sur master à l'aide d'une merge request puis nous effectuerons une deuxième merge request de master vers next_version
+
+
+
+Chaque correctif doit être fait à travers une issue (documenté plus bas)
+
+## Faire une évolution
+
+*Cette section est réservée aux projet de développement*
+
+Les évolutions ne sont pas intégrées sur master qu'après la phase de pré-production, c'est pour cela qu'elles seront faites **à partir de next_version** et se nommeront evolution/[intidulé de l'évolution].
+
+Une fois terminée, la branche sera rapatriée sur next_version.
+
+
+
+Chaque évolution doit être fait à travers une issue (documenté plus bas)
+
+## Créer un correctif/évolution dans GitLab
+
+Dans GitLab la notion de correctif ou d'évolution est lié à une issue, une issue est une demande aux développeurs de résoudre un problème sur l'application actuellement en production ou alors de déveloper une nouvelle fonctionnalité.
+
+Le titre de l'issue doit contenir sur quelques mots le but de la demande, puis dans la description il est possible de détailler.
+
+En cas de bug, il vaut mieux associer la demande au responsable produit de telle sorte à ce qu'il reçoive par mail et dans l'interface une notification.
+
+Pas besoin de fournir de milestone car ce dernier sera décidé par le responsable produit.
+
+Parmi les labels disponibles il faudra spécifier si il s'agit d'un bug ou d'une évolution.
+
+
+
+Lorsqu'un responsable produit va accepter une issue il voudra si c'est un bug créer une branche ainsi qu'une merge request, pour cela plusieurs étapes sont nécessaires.
+
+
+#### Assigner la demande
+
+En assignant la branche à quelqu'un il recevra une notification par mail ainsi que sur l'interface.
+
+
+
+Le milestone permettra de connaître l'avancement du projet dans sa globalité, il est important de le spécifier pour savoir à quelle version de l'application correspond cette issue.
+
+
+
+Les labels permettront de filtrer les issues, les deux labels bug et evolution sont toujours présents car ils appartiennent au groupe, sur les applications vitis on retrouve autant de labels que de modules pour savoir rapidement à quel module correspond cette issue.
+
+
+
+#### Effectuer la demande
+
+**Quand l'issue vous est attribuée** et que vous commencez à la résoudre il faudra créer une branche ainsi qu'une merge request.
+
+**Ne cliquez pas directement sur le bouton Create merge request**, en revanche cliquez sur le bouton déroulant situé à sa droite pour définir le nom de la branche à créer ainsi que la source.
+
+Si il s'agit d'un bug on créera une branche bug/.... et on choisira comme source master.
+
+Si il s'agit d'une évolution on créera une branche evolution/... et on choisira comme source next_version
+
+
+
+Désormais une branche portant le nom de l'issue a été créée. Vous remarquerez que le nom de la merge request commence par **WIP** (Work In Process) ce qui nous permet de savoir si la travail du développeur est terminé ou non.
+
+
+
+**Une fois les développements terminés** sur la branche il est temps de terminer la merge request pour demander au responsable projet d'intégrer les développements sur la banche source. Pour cela il faudra lui assigner la merge request puis enlever le status WIP en cliquant sur **Resolve WIP status**.
+
+#### Valider la demande
+
+Une fois que le développeur a terminé et vous a assigné la demande de merge vous pouvez visualiser les modifications effectuées et valider la demande.
+
+Si la demande ne correspond pas à vos attentes il faudra l'éditer pour ajouter à nouveau WIP: au début du titre, puis décrire dans la fenềtre de discussion pourquoi la demande n'est pas valide.
+
+Une fois la demande de merge effectuée l'issue se met à jour automatiquement en état terminé.
diff --git a/gitlab/depot_gitlab.md b/gitlab/depot_gitlab.md
index 4a6e5ec5a3888388e26571202306701b4bdde170..97ce7dc28f521ddb51efb69dd5858ea1bee29be3 100644
--- a/gitlab/depot_gitlab.md
+++ b/gitlab/depot_gitlab.md
@@ -16,110 +16,6 @@ Chaque dépôt doit contenir un fichier README.md contenant une description du p
Une fois le dépôt crée il faudra éditer les paramètres comme détaillé ci-arpès dans la section [paramètres depot](depot_gitlab.html#)
-## Branches principales
-
-### Pour les projets FME
-
-Quand les projet abritent des fichiers non textuels (audio, fmw, zip etc..) des conflits non résolvables vont apparaître régulièrement lors des étapes de merge, dans ce cas il est préférable de créer une branche de travail ouverte à tous les contributeurs, de protéger la branche master pour y faire des merge quand les développements ont étés validés.
-
-### Pour les projets de développement
-
-Dans ce cas il est possible d'utiliser 100% des capacités de Git et c'est ce que nous allons faire en appliquant la procédure suivante.
-
-Sur la branche **master** nous appliquerons uniquement les correctifs, cette branche **doit absolument être stable** à tout moment car elle permettra de générer un correctif quand on le souhaite.
-
-Une deuxième branche **next_version** permettra quand à elle à appliquer les évolutions, quand des correctifs sont appliqués à master, il faudra les merger sur cette branche de manière à avoir les dernières évolutions ainsi que les derniers correctifs.
-
-Une fois les développements d'une version terminés il est important de tester dans un environnement de pré-production notre application, à ce moment nous créerons à partir de next_version une branche **20xx.xx.xx** contenant le numéro de build à générer (on utilise parfois **pre_prod** si il n'y a pas de numéro associé).
-Les correctifs à effectuer se feront sur master puis seront mergés sur next_version et sur la branche de pré-production.
-
-Quand l'environnement de pré-production est validé, il est alors mergé sur next_version puis sur master à partir duquel on créera le tag correspondant.
-
-
-
-## Créer un tag
-
-## Faire un correctif
-
-*Cette section est réservée aux projet de développement*
-
-Un correctif est un bug remonté sur l'application en cours de production qui doit être corrigé pour publier une nouvelle version mineure, pour ce faire on créera une branche **à partir de master** qui se nommera bug/[intitulé du bug].
-
-Une fois le bug corrigé nous le rapatrierons sur master à l'aide d'une merge request puis nous effectuerons une deuxième merge request de master vers next_version
-
-
-
-Chaque correctif doit être fait à travers une issue (documenté plus bas)
-
-## Faire une évolution
-
-*Cette section est réservée aux projet de développement*
-
-Les évolutions ne sont pas intégrées sur master qu'après la phase de pré-production, c'est pour cela qu'elles seront faites **à partir de next_version** et se nommeront evolution/[intidulé de l'évolution].
-
-Une fois terminée, la branche sera rapatriée sur next_version.
-
-
-
-Chaque évolution doit être fait à travers une issue (documenté plus bas)
-
-## Créer une issue (demande)
-
-Une issue est une demande aux développeurs de résoudre un problème sur l'application actuellement en production ou alors de déveloper une nouvelle fonctionnalité.
-
-Le titre de l'issue dois contenir sur quelques mots le but de la demande, puis dans la description il est possible de détailler.
-
-En cas de bug, il vaut mieux associer la demande au responsable produit de telle sorte à ce qu'il reçoive par mail et dans l'interface une notification.
-
-Pas besoin de fournir de milestone car ce dernier sera décidé par le responsable produit.
-
-Parmi les labels disponibles il faudra spécifier si il s'agit d'un bug ou d'une évolution.
-
-
-
-Lorsqu'un responsable produit va accepter une issue il voudra si c'est un bug créer une branche ainsi qu'une merge request, pour cela plusieurs étapes sont nécessaires.
-
-
-#### Assigner la demande
-
-En assignant la branche à quelqu'un il recevra une notification par mail ainsi que sur l'interface.
-
-
-
-Le milestone permettra de connaître l'avancement du projet dans sa globalité, il est important de le spécifier pour savoir à quelle version de l'application correspond cette issue.
-
-
-
-Les labels permettront de filtrer les issues, les deux labels bug et evolution sont toujours présents car ils appartiennent au groupe, sur les applications vitis on retrouve autant de labels que de modules pour savoir rapidement à quel module correspond cette issue.
-
-
-
-#### Effectuer la demande
-
-**Quand l'issue vous est attribuée** et que vous commencez à la résoudre il faudra créer une branche ainsi qu'une merge request.
-
-**Ne cliquez pas directement sur le bouton Create merge request**, en revanche cliquez sur le bouton déroulant situé à sa droite pour définir le nom de la branche à créer ainsi que la source.
-
-Si il s'agit d'un bug on créera une branche bug/.... et on choisira comme source master.
-
-Si il s'agit d'une évolution on créera une branche evolution/... et on choisira comme source next_version
-
-
-
-Désormais une branche portant le nom de l'issue a été créée. Vous remarquerez que le nom de la merge request commence par **WIP** (Work In Process) ce qui nous permet de savoir si la travail du développeur est terminé ou non.
-
-
-
-**Une fois les développements terminés** sur la branche il est temps de terminer la merge request pour demander au responsable projet d'intégrer les développements sur la banche source. Pour cela il faudra lui assigner la merge request puis enlever le status WIP en cliquant sur **Resolve WIP status**.
-
-#### Valider la demande
-
-Une fois que le développeur a terminé et vous a assigné la demande de merge vous pouvez visualiser les modifications effectuées et valider la demande.
-
-Si la demande ne correspond pas à vos attentes il faudra l'éditer pour ajouter à nouveau WIP: au début du titre, puis décrire dans la fenềtre de discussion pourquoi la demande n'est pas valide.
-
-Une fois la demande de merge effectuée l'issue se met à jour automatiquement en état terminé.
-
## Paramétrer le dépôt
Une fois le dépôt crée on accède à la page suivante, on peut déjà le cloner pour alimenter ses fichiers mais nous allons tout d'abord le paramétrer. Pour cela il suffit de se rendre dans la section **Settings**
diff --git a/gitlab/index.rst b/gitlab/index.rst
index 469f30ae31e319a6c3118cb7348e136c7e38caa2..1312f76ea2087dd6f4ea5be688cd52d4b16c3245 100644
--- a/gitlab/index.rst
+++ b/gitlab/index.rst
@@ -8,4 +8,5 @@ GitLab
compte_gitlab
depot_gitlab
architecture_projets
+ correctifs_evolutions
applications_vitis