diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md
index 19e0b4fa0..6be84be9c 100644
--- a/docs/GuideDeveloppeurs.md
+++ b/docs/GuideDeveloppeurs.md
@@ -86,8 +86,9 @@ basique:
 
 Vous travaillez dans votre branche `ma_branche`. Pour lui appliquer les mises à
 jour de `master` (remote):
-
+```bash
     git pull origin master
+```
 
 #### Commandes utiles, en vrac
 
@@ -97,143 +98,197 @@ jour de `master` (remote):
 #### Refactoring
 
 Lint tous les fichiers modifiés:
-    
+```bash 
     git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E
-
+```
 Restore les modes au besoin (SAMBA les changent parfois):    
-    
+```bash    
     git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
-
+```
 Affiche les variables non définies dans un fichier:
-
+```bash
    pylint --disable=all  -e E sco_parcours_dut.py | grep undefined-variable | awk '{print $4;}' | sort | uniq | tr -d \' 
-
+```
 Prépare un sed pour renommer les variables non définies:
-
+```bash
    for f in *.py
    do
    pylint --disable=all  -e E "$f" | grep undefined-variable | awk '{print "sed -i .bak s/"$4"/scu."$4"/ '$f'";}' | sort | uniq | tr -d \'
    done
+```
 
 Note pour travailler sur VirtualBox:
 
     addgroup scodoc vboxsf
 
-#### Préparation d'un PR
+### Préparation d'une PR (Pull Request)
 
-##### Principes généraux
+#### Principes généraux
 
-L'essentiel des remarques/procédures de cette section vise à obtenir une relecture facile des modifications:
+Les remarques de cette section visent à obtenir une relecture facile de votre
+demande d'ajout (*pull request*, dite "PR"):
 
-* Éviter les modifications de forme sans substance sémantique. L'utilisation de [`black`](https://black.readthedocs.io/) permet de normaliser la présentation du code.
+* Éviter les modifications de forme qui ne changent pas le sens du code. L'utilisation de
+  [`black`](https://black.readthedocs.io/) est obligatoire : elle permet de normaliser la présentation
+  du code. cela évite de générer des différences ne représentant que des
+  changements de mise en forme (indentation, passages à la ligne). Cela évite
+  aussi au développeur d'avoir à y réfléchir, autant de temps gagné !
 
-* Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour les PR courantes (peu volumineuses)
+* Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour
+  les PR courantes - peu volumineuses).
 
-* La PR doit toujours être énoncé par rapport au dernier commit de la branche master officielle
+* La PR doit toujours être énoncée par rapport au dernier commit de la branche
+  que vous visez (en général `master` du dépôt original).
 
-##### Manipulations
+#### Manipulations
 
-Les manipulations sont décrites selon 4 phases du développement: l'installation, la mise en place, le suivi, la livraison.
+Les manipulations sont décrites selon quatre phases du développement : l'installation,
+la mise en place, le suivi et la livraison.
 
-###### l'installation
-Il est pratique d'avoir en ligne les deux dépôt git distant que vous pouvez utiliser: votre dépôt personnel (`https://scodoc.org/git/<user>/<dépôt>.git`) 
-et le dépôt officiel (`https://scodoc.org/git/ScoDoc/ScoDoc.git`)
+##### l'installation
+Il est pratique d'avoir en ligne les deux dépôts git distants que vous pouvez
+utiliser : votre dépôt personnel (`https://scodoc.org/git/<user>/<dépôt>.git`) et
+le dépôt officiel (`https://scodoc.org/git/ScoDoc/ScoDoc.git`).
 
-pour ajouter une référence (et lui donner un nom) vers un dépôt distant, envoyez la commande:
+pour ajouter une référence (et lui donner un nom) vers un dépôt distant, entrez
+la commande:
 
-```git remote add nom_remote https://scodoc.org/git/ScoDoc/<dépôt>.git``` 
+```bash
+  git remote add nom_remote https://scodoc.org/git/ScoDoc/<dépôt>.git
+``` 
 
-Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`) et une référence vers le dépôt officiel (`officiel`). L'un des deux
-si vous avez initialement cloné l'un des deux dépôts, la référence vers celui-ci existe et a pour nom `origin`.
+Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`)
+et une référence vers le dépôt officiel (`officiel`). Si vous avez initialement
+cloné l'un des deux dépôts, la référence vers le dépot d'origine existe et a pour nom
+`origin`.
 
 La commande vous exposant tous les dépôts connus est :
-
-`git remote -v`
-
-##### Mise en place
-
-L'objectif de ce paragraphe est de créer une branche locale basée sur le master du dépôt officiel et bien sur de lui donner un nom.
-
-pour cela (attention cela va écraser les éventuels fichiers modifiés)
-
+```bash
+  git remote -v
 ```
-git reset --hard officiel/master
-git checkout -b ma_modif 
+
+#### Mise en place
+
+L'objectif de ce paragraphe est de créer une branche locale basée sur le master
+du dépôt officiel et bien sur de lui donner un nom.
+
+pour cela (**attention cela va écraser les éventuels fichiers modifiés**. Si vous souhaitez conserver les 
+modifications en cours, encadrez les lignes suivantes par `git stash` (avant) et `git stash apply` (après) :
+
+```bash
+  git reset --hard officiel/master
+  git checkout -b ma_modif 
 ```
-À partir de la vous pouvez modifier, tester, développer, commit.
+À partir de là, vous pouvez modifier, tester, développer et commit votre travail.
 
-##### Suivi
+#### Suivi
 
-Si votre développement prend plusieurs jours, il est probable que la branche principale évolue pendant ce temps.
+Si votre développement prend plusieurs jours, il est probable que la branche
+principale évolue pendant ce temps.
 
-Pour garder la cohérence, il est nécessaire de réintégrer en local les modifications de la branche principale. Ceci peut se faire de deux façons.
+Pour garder la cohérence, il est nécessaire de réintégrer en local les
+modifications de la branche principale. Ceci peut se faire de deux façons.
 
- - Une fusion (`merge`) applique toutes les modifications en une seul commit). C'est la méthode couramment utilisée
+ - Une fusion (`merge`) applique toutes les modifications en un seul commit).
+   C'est la méthode couramment utilisée.
 
- - Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état le plus à jour de la branche principal (il en résulte un historique plus linéaire)
+ - Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état
+   le plus à jour de la branche principale (il en résulte un historique plus
+   linéaire).
 
-Les commandes git correspondantes:
+Les commandes git correspondantes :
 
-```
-git fetch officiel
-git merge officiel/master
+```bash
+  git fetch officiel
+  git merge officiel/master
 ```
 ou
-```
-git fetch officiel
-git rebase officiel/merge
+```bash
+  git fetch officiel
+  git rebase officiel/merge
 ```
 
-##### La livraison
+#### La livraison
 
-Ça y est. vous avez terminé le développement. IL n'y a plus qu'à demander l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur la branche locale `ma_modif`).
+Ça y est. Vous avez terminé le développement. IL n'y a plus qu'à demander
+l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur
+la branche locale `ma_modif` et toutes vos modifications ont été commitées).
 
-###### Étape 1 : faire l'inventaire des fichiers impliqués
+##### Étape 1 : faire l'inventaire des fichiers impliqués
 
-```
-git fetch officiel/master
-git diff --name-only officiel/master
+```bash
+  git fetch officiel/master
+  git diff --name-only officiel/master
 ```
 
-###### Étape 2 : passer black sur les fichiers modifiés
+##### Étape 2 : passer black sur les fichiers modifiés
 
-Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé l'équivalent sous *pyCharm*)
+Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé
+l'équivalent sous *pyCharm*).
 
-À défaut les lignes suivantes réalisent le même travail:
+À défaut les lignes suivantes réalisent le même travail :
 
-```
-for fn in $(git diff --name-only officiel/master)
-do
-  python3 -m black $fn
-done 
-```
-faire une première lecture rapide pour vérifier qu'il n'y ait pas de fichiers modifiés accidentellement.
-
-pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple)
-```
-git diff officiel/master app/fichier.py
+```bash
+  for fn in $(git diff --name-only officiel/master)
+  do
+    python3 -m black $fn
+  done 
 ```
 
-Utilisateurs Windows:
-Vérifiez bien que les réglages de fin de ligne suivant bien les règles Linux (pas de CR ou `\r` en fin de ligne juste les LF  `\n`). 
-Le cas échéant réglez votre IDE pour cela
+Faire une première lecture rapide pour vérifier qu'il ne reste pas de fichiers
+modifiés accidentellement.
 
-À ce niveau là vous n'avez dans votre branche locales que les différences nécessaires à votre correctif.
+Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple)
+```bash
+  git diff officiel/master app/fichier.py
+```
 
-###### Étape 3: résumez tous les commits depuis le point de divergence en un seul commit
+Utilisateurs Windows : Vérifiez bien que les réglages de fin de ligne suivent
+bien les règles Linux (pas de retour chariot (noté CR ou `\r`) en fin de ligne mais un seul caractère line feed 
+(noté LF  ou `\n`). 
+Le cas échéant, réglez votre IDE pour cela.
+
+À ce niveau là de la procèdure, vous n'avez plus dans votre branche locale que les différences strictement
+nécessaires à votre correctif.
+
+##### Étape 3 : résumez tous les commits depuis le point de divergence en un seul commit
 
 Repérez le point de divergence de votre branche locale avec officiel/master
-(normalement `git merge-base ma_branche officiel/master`)
+(normalement `git merge-base HEAD officiel/master`)
 
-Demander un `rebase` interactif depuis ce point:
+Demander un `rebase` interactif depuis ce point :
 
+```bash
+  git rebase -i $(git merge-base HEAD officiel/master)
 ```
+
+*Explications*:
+_Le rebase interactif permet d'enregistrer un suite de manipulation de commit dans un seul fichier texte._ 
+_Le fichier texte qui reprend tels quels tous les commits concernés (et donc qui ne fait rien)_ 
+_est préparé par la commande `-i` de la commande_ `git rebase`
+
+_Vous pouvez ensuite modifier ce fichier dans votre editeur favori (ou pas) (à régler par `git config`) pour décrire_
+_votre intention (réordonner, changer le message, fusionner, ...) sur l'ensemble des commits_
+
+_Quand votre édition est terminée, git reprend la main est exécute chacune de vos opérations. Il est possible_
+_(bien que très rare) que des conflits apparaissent à ce moment-là. Les_
+_commandes habituelles de correction accompagnées des commandes :_
+```bash
+git rebase --continue # pour poursuivre le processus
+git rebase --abort # pour tout abandonner
+```
+_vous permettront de résoudre ces problèmes exceptionnels_.
+
+Application:
+
+```bash
 git rebase -i $(git merge-base HEAD officiel/master)
 ```
+Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le
+début du développement sous cette forme (c'est un exemple : le nombre de lignes
+peut varier) :
 
-Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le début du développement sous cette forme (c'est un exemple le nombre de lignes peut varier)
-
-```
+```bash
 pick eb8cbec modif 1
 pick 83eb79e modif 2
 
@@ -264,47 +319,54 @@ pick 83eb79e modif 2
 #
 # However, if you remove everything, the rebase will be aborted.
 #
-~
 ```
 
-vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en changeant la commande pick au début de chaque ligne
-l idée ici est de fusionner toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne 2 par `fixup`.
-optionnellement, vous pouvez reformuler le message de commit (commande `reword` sur la première ligne).
+Vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en
+changeant la commande pick au début de chaque ligne. L'idée ici est de fusionner
+toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne
+2 par `fixup`. Optionnellement, vous pouvez reformuler le message de commit
+(commande `reword` sur la première ligne).
 
-Vous construirez par exemple:
-```
+Vous construirez par exemple :
+```bash
 reword eb8cbec Correctif: Api - gestion des formation
 fixup 83eb79e modif 2
 ...
 ```
 
-Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées
+Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées.
 
-À ce niveau là de la procédure:
+À ce niveau-là de la procédure :
 
-* vous avez un seul commit pour l'ensemble du correctif proposé
+* vous avez un seul commit pour l'ensemble du correctif proposé ;
 
-* toutes les différences entre officiel/master et votre branche locale sont signifiantes
+* toutes les différences entre officiel/master et votre branche locale sont
+  signifiantes.
 
-###### Étape 4:
-Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel (vers une branche de même nom):
+##### Étape 4 :
+Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel
+(vers une branche de même nom):
 
-```
-git push --set-upstream perso ma_branche
+```bash
+  git push --set-upstream perso ma_branche
 ```
 
-Si vous avez déjà fait cette opération auparavant il est possible que le push soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
-Dans ce cas l'option `--force` du push vous permette de passer outre, mais assurez-vous avant d'être le seul à travailler sur cette branche.
+Si vous avez déjà fait cette opération auparavant il est possible que le push
+soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
+Dans ce cas l'option `--force` du push vous permette de passer outre, mais
+assurez-vous avant d'être le seul à travailler sur cette branche.
 
-###### Etape 5: La dernière étape se passe sur le site scodoc.org/git
+##### Etape 5 : La dernière étape se passe sur le site [scodoc.org/git](https://scodoc.org/git/)
 
 * Identifiez-vous
 
 * Placez-vous sur la branche nouvellement créée
 
-* À l'aide de l'interface du serveur vous pouvez comparer l'état de votre branche par rapport au master officiel, et si cela vous convient de formuler une demande d'intégration (pull request)
+* À l'aide de l'interface du serveur, vous pouvez comparer l'état de votre
+  branche par rapport au master officiel, et si cela vous convient, il vous reste à formuler
+  une demande d'intégration (*pull request*). En remplissant les informations demandées.
 
-### Tests
+## Tests et tests unitaires
 
 Voir [TestsScoDoc](TestsScoDoc.md)