diff --git a/journal/Research_and_Reproductibility_mooc_notes.md b/journal/Research_and_Reproductibility_mooc_notes.md
index 3d0591d11aac6179cfd644b5d93ace94bfb76a03..b735b637ce8ac092dd1803ae9836e54aad2bb0e5 100644
--- a/journal/Research_and_Reproductibility_mooc_notes.md
+++ b/journal/Research_and_Reproductibility_mooc_notes.md
@@ -39,6 +39,9 @@ Outils :
 
 # 2) La vitrine et l'envers du décor: le document computationnel
 
+[Retranscription des vidéos du module 2](https://lms.fun-mooc.fr/asset-v1:inria+41016+self-paced+type@asset+block/Module2_Transcription_VF.pdf)
+[Supports des vidéos du module 2](https://lms.fun-mooc.fr/asset-v1:inria+41016+self-paced+type@asset+block/C028AL_slides_module2-fr-gz.pdf)
+
 ## 2.1) Exemples d'études récentes "discutées"
 
 RAS
@@ -285,8 +288,83 @@ Points clés à retenir:
 
 ## 3.5 Questions et réponses
 
+Une analyse réplicable doit contenir **toutes** les étapes de traitement des données sous une forme **exécutable**.
+
+Il est important d'**expliquer _tous_** les choix qui peuvent influencer les résultats.
+
+Ceci nécessite d'exposer beaucoup de **détails techniques**, car c'est à ce niveau que l'on commet le plus d'**erreurs**.
+
 ### a) Avec Jupyter
 
 
+# 4) Vers une étude reproductible : la réalité du terrain
+
+[Retranscription des vidéos du module 4](https://lms.fun-mooc.fr/asset-v1:inria+41016+self-paced+type@asset+block/Module4_Transcription_VF.pdf)
+[Supports des vidéos du module 4](https://lms.fun-mooc.fr/asset-v1:inria+41016+self-paced+type@asset+block/C028AL_slides_module4-fr-gz.pdf)
+
+## 4.1) L'enfer des données
+
+Les problèmes classiques:
+- les données sont de natures diverses, elles sont non homogènes
+  - souvent la forme de table doit être abandonnée:
+    - les colonnes n'ont pas la même longueur
+    - les données peuvent être des suites chronologiques, des images, etc
+- les données peuvent occuper un grand espace mémoire
+  - les données numériques ne peuvent être représentées sous format texte que jusqu'à un certain point
+  - deux considérations poussent à adopter un format binaire:
+    - les nombres stockés en format binaire occupent moins de place mémoire que sous format texte
+    - les nombres stockés en format texte doivent obligatoirement être convertis en format binaire afin 
+    de pouvoir réaliser des calculs et analyses
+
+Deux formats binaires intéressants pour manipuler des données de nature différente et volumineuses.
+--> FITS et HDF5
+
+Pour l'archivage de données (GitLab et GitHub non adaptés):
+--> plateformes Zenodo et Figshare
+
+## 4.2) L'enfer du logiciel
+
+### 4.2.1) Le passage à l'échelle : les codes complexes
+
+Code utilisé pour de petits exemples devient vite inadéquat dès lors que le code devient plus complexe ou\
+que le volume de données grandit.
+
+L'utilisation d'un workflow est une solution.
+
+Un notebook est une version à la fois appauvrie et plus riche d'un workflow.
+
+Exemples de workflows:
+- Galaxy, Kepler, Taverna, Pegasus, Collective Knowledge, Vis Trails...
+- Légers: dask, drake, swift, snakemake, ...
+- Hybrides: SOS-notebook, ...
+
+Traitement de données volumineuses:
+
+Utilisation de checkpoints dans les calculs (mécanismes éventuels de cache) afin d'éviter de repasser par\
+des étapes coûteuses de calcul.
+
+### 4.2.2) Le passage à l'échelle : les environnements complexes
+
+Derrière un simple import de matplotlib, un réseau complexe de dépendances se cache.
+
+Pas de standard :
+- Linux (apt, rpm, yum), MacOS X (brew, McPorts, Fink), Windows ( ?)
+- Ni pour l'installation ni pour récupérer les informations. . .
+
+Outils de capture des bibliothèques utilisées et des fichiers ouverts lors d'une exécution, pour ensuite les packager,\
+par exemple, dans un conteneur Docker:
+- CDE, ReproZip, CARE, ...
+
+### 4.2.3) Le passage à l'échelle : l'épreuve du temps
+
+Utilisation de plateformes pérennes telles que les plateformes étatiques.
+
+## 4.3) L'enfer du calcul : la réalité du terrain
+
+Attention aux calculs en flottants (opérations d'arrondi cachées, accumulation d'erreurs)
+
+
+
+