diff --git a/module1/README.md b/module1/README.md
index e75b08cf91cb3c3d3d33e43a22f384634f7e676f..8cf16c137e3f0e2debd40ba4bffb087653e03e2b 100644
--- a/module1/README.md
+++ b/module1/README.md
@@ -139,3 +139,33 @@ Créer d'abord à distance, cloner, bosser.
 Ensuite, on push chaque fois qu'on est satisfait : c'est la sauvegarde.
 Les "petites erreurs" qui forment des branches alternatives ne sont a priori pas transmises.
 Mais si besoin, on peut.
+
+Now, avec plsrs users :imp:
+
+Les "branches masters" des différents users ne sont plus les mêmes.
+On push régulièrement, et on pull dès qu'on se remet à bosser, ça marche tant qu'on bosse en différé.
+
+Mais si on bosse simultanément, c'est le premier qui push qui a raison\*.
+L'autre ne pourra plus push sur la master :'(
+On doit pull d'abord, et là, soit la vie est belle, soit il y a des conflits.
+C'est l'humain qui règle le conflit.
+Ce conflit (réglé) restera visible dans l'historique (ce qui facilitera le pull de l'autre belligérant).
+\*Notons que c'est celui qui résout le conflit qui a finalement raison.
+
+Le serveur sert d'intermédiaire ici, mais on peut faire de l'échange direct à deux.
+
+Pour éviter les conflits... ne pas faire du micro-ménage pour rien :
+espaces, indentations... ça multiplie les conflits.
+Séparer les commits de fond et de forme, donc !
+Faire des petits commits logiques, bien regarder avec status diff et add. 
+(On **doit** souvent faire plusieurs commits de suite.)
+
+Aussi, on ne peut pas gérer les conflits sur les formats inconnus... il faut privilégier le format texte !
+
+`git log`pour voir l'historique des versions.
+(Il a pas expliqué `git merge` ! pour moi c'est synonyme de push...)
+
+-> il ne parle pas de la possibilité de maintenir lontemps plusieurs "branches", pour quand même les fusionner à la fin.
+C'est une façon de bosser à plsrs, manifestement.
+(Exemple intéressant : si je bosse dans le train, hors connexion.)
+