update bp modeler

Author: nriss

input/pagecontent/bonnes_pratiques_modeler.md

@@ -151,13 +151,3 @@ La conclusion actuelle (octobre 2023) est de privilégier R4 pour ne pas être "
 
 FHIR R6, dont la première concertation est prévue mi-2024, apportera beaucoup de contenu normatif, et sera peut-être l'objectif de transition.
 
-### Règles d'utilisation de GitHub
-
-Règles d'utilisation de GitHub :
-
-* Toutes modifications d'une spécification sur GitHub doit se faire au niveau d'une branche.
-* Le nom de la branche doit être préfixé par les initiales de l'auteur (ex : "sb-" pour Sébastien Brunelle) suivi de la description des travaux (ex : "sb-ajout-bonnespratiques-github)
-* Lorsque les travaux de modifications sont effectués, il est nécessaire de créer une Pull Request (PR) qui doit être validée par au moins un autre membre de l'ANS.
-* Une fois la Pull Request validée, c'est à l'auteur des modifications de fusionner (=merge) la pull request avec la branche principale "main".
-
-A noter qu'aucune modification doit être faite directement dans main.

input/pagecontent/github.md

@@ -4,6 +4,15 @@ GitHub est l'équivalent d'un sharepoint, un répertoire (=repository) versionn
 
 Pour créer un compte GitHub et être enrôlé dans l'organisation ansforge, il suffit de suivre [cette documentation](https://ansforge.github.io/Documentation/)
 
+#### Règles d'utilisation de GitHub
+
+* Toutes modifications d'une spécification sur GitHub doit se faire au niveau d'une branche.
+* Le nom de la branche doit être préfixé par les initiales de l'auteur (ex : "sb-" pour Sébastien Brunelle) suivi de la description des travaux (ex : "sb-ajout-bonnespratiques-github)
+* Lorsque les travaux de modifications sont effectués, il est nécessaire de créer une Pull Request (PR) qui doit être validée par au moins un autre membre de l'ANS.
+* Une fois la Pull Request validée, c'est à l'auteur des modifications de fusionner (=merge) la pull request avec la branche principale "main".
+
+A noter qu'aucune modification doit être faite directement dans main.
+
 ### Création d'un nouveau projet
 
 #### les règles de nommage
@@ -102,7 +111,7 @@ Cf. documentation officielle : https://docs.github.com/fr/pull-requests/collabor
 
 ### Mettre en place un workflow de validation/génération/publication
 
-Afin de faciliter les actions au regards des IG, l'ANS  met à disposition un [GitHub Action](https://github.com/ansforge/IG-workflows)  avec les fonctionnalités suivantes : 
+Afin de faciliter les actions au regards des IG, l'ANS  met à disposition un [GitHub Action](https://github.com/ansforge/IG-workflows)  avec les fonctionnalités suivantes :
 
 * Lancement de sushi
 * Tests avec le validateur_cli
@@ -113,4 +122,5 @@ Afin de faciliter les actions au regards des IG, l'ANS  met à disposition un [G
 * Génération des testscripts avec le projet testscript-generator
 * Publication sur les pages github :
   * Diagramme de class plantuml généré à partir des données de l'IG
-  * Rapport de validation du validator_cli
+  * Rapport de validation du validator_cli
+  

input/pagecontent/index.md

@@ -7,11 +7,9 @@ L’objectif est d’encourager la participation de l’ensemble des parties pre
 
 ### Les guides d'implémentation
 
-Selon la documentation FHIR, un Implementation Guide contient un ensemble cohérent de ressources de conformité pour répondre à une problématique particulière.
+Un guide d'implémentation se présente sous forme d'un site web contenant un ensemble cohérent de ressources de conformité pour répondre à une problématique particulière. Le guide d'implémentation est versionné (l'ensemble des versions reste accessible) et packagé.
 
-Un implementation guide se présente sous forme d'un site web et d'un package contenant l'ensemble des ressources de conformité. Les implementation guides (site web, ressources de conformité et package) sont versionnés. L'ensemble des versions historiques seront toujours accessibles.
-
-La meilleure pratique consiste à créer un Implementation Guide par projet bien spécifique, cela permet :
+La meilleure pratique consiste à créer un guide d'implémentation par projet bien spécifique, cela permet :
 
 * De versionner séparément, on peut ainsi mettre à jour chacune des specs séparément sans avoir à mettre à jour celles qui ne sont pas concernées
 * Chacune des specs gère ses dépendances indépendamment des autres (aux ressources du ci-sis, aux profils interopsanté), chacune de ces dépendances peuvent être mises à jour séparément