diff --git a/journal/notes_module_4.md b/journal/notes_module_4.md
index 65027081ae9cd0360f892d55f17986afc8c64f82..4a6ca1b01f91e4fd301fb1634b40fb2d0eec0110 100644
--- a/journal/notes_module_4.md
+++ b/journal/notes_module_4.md
@@ -45,3 +45,34 @@ Les git- hub/lab ne sont pas adaptés.
 Voir dans son labo (~dropbox).
 
 Zenodo (~CERN) ou FigShare (privé, ~open science, mais trop peu souverain pour moi, patron anglais)
+
+
+# Enfer logiciel
+
+## Le code...
+L'enfer vient souvent de passages à l'échelle pas anticipés.
+Plus de 3/4 pages de notebook, c'est trop.
+
+Orgmode peut aider, mais on restera sur du linéaire.
+
+Utiliser un **workflow** ?
+Pour faire de l'encapsulation, pour connecter les fonctions 
+(le moteur d'execution se charge du côté opérationnel).
+
+Ça n'empêche pas le code de devenir complexe, hein, mais la vue en graphe reste vertueuse.
+(Ça va aussi aider si j'ai plusieurs langages !)
+
+Le notebook est un workflow séquentiel, en un sens 
+(avec des risques si éxécute pas dans l'ordre)...
+Mais il est plus riche sur la possibilité de narration.
+
+Un "makefile" est aussi une forme de workflow rudimentaire.
+
+Pour les trucs légers (pas conçu pour paralléliser), voir :
+[dask](https://examples.dask.org/applications/prefect-etl.html), drake, swift, snakemake...
+En plus lourd, voir VisTrail ou Collective Knowledge, par exemple.
+
+Gros calculs : fonctionner par checkpoints et par cache.
+(J'ai l'expérience...)
+
+