# Module 1 : Cahier de notes, cahier de laboratoire

**Objectifs**
- Comprendre l’importance de la traçabilité dans un travail de recherche
- Comprendre le fonctionnement d’un cahier de laboratoire
- Maîtriser la gestion d’un cahier de laboratoire électronique
- Maîtriser le fonctionnement d’un outil de suivi de gestion

## Sous-partie 1 : Idées intéressantes – Cahier de notes
-	Créer une table des matières
-	Noter des mots clés à chaque page puis se référer au classement de John Locke (classement par ordre alphabétique des mots clés + lettres les plus répandues : a, e, i/y, o, u)
-	Décrire en détail les expériences réalisées avec les objectifs des manips + que juste noter les conditions opératoires -> permet un suivi plus détaillé et des présentations claires
-	Eviter le surplus de feuilles volantes

## Sous-partie 2 : Les étiquettes et les logiciels d'indexation pour s'y retrouver
Doc Fetcher -> moteur de recherche de bureau

Mardown -> ajouter des étiquettes aux fichiers textes

ExifTool -> logiciel d’affichage et de modificateur de métadonnées

-	Les moteurs de recherche de bureau peuvent lire des métadonnées
-	Les fichiers images contiennent des métadonnées

L’OBJECTIF DE CES OUTILS EST D’EVITER LE CAUCHEMAR DE LEIBNIZ, A SAVOIR DE STOCKER DE MANIERE DESORDONNEE UNE TROP GRANDE QUANTITE D’INFORMATIONS ET DE REFERENCES, AMENANT AINSI A UNE DIMINUTION DE LEUR UTILITE RESPECTIVE.

# Module 2 : La vitrine et l'envers du décor

**Objectifs**
- Extension de la traçabilité aux calculs et à ses résultats
- Intégration du code et des résultats dans un document du type rapport technique / article scientifique
- Présentation de 3 outils pour écrire un document computationnel : Jupyter, RStudio, Emacs/Org-mode

## Sous-partie 1 :Exemples récents d’études dicutées
-	1er exemple : crise des subprimes avec 2 auteurs, Reinhart et Rogoff, article utilisé pour la politique d’austérité malgré des calculs qui diffèrent par les co-auteurs
-	2e exemple : IRM fonctionnelle
-	3e exemple : cristallographie, fausses structures de protéines, geoffrey chang

## Sous-partie 2 : Pourquoi est-ce difficile ?
La plupart des problèmes rencontrés sont liés au calcul, qu'il s'agisse d'erreurs de programmations, de transformations de données peu rigoureuses, ou bien de procédures statistiques discutables.

**Raison 1, le manque d’information**

Expliciter :
-	Données non disponibles = résultats difficiles à vérifier
-	Choix non expliqués = choix suspicieux

**Raison 2, ordinateur source d’erreurs**
-	Point and click, perte de compréhension de ce qui est fait par le logiciel
-	Les tableurs : engendrent des erreurs de programmation par le sur usage des macros et induit des manipulations de données
-   Pile logicielle complexe

**Raison 3, manque de rigueur et d'organisation**
- Pas de backup
- Pas d'historique
- Pas de contrôle qualité

**Outils à éviter et alternatives**

*Outils, formats, et services propriétaires*

-	Eviter excel, word, evernote -> Remplacer par markdown, orgmode, csv, hdf5
-	Eviter SAS, Minitab, matlab, mathematica -> Remplacer par scilab, R, python
-	Eviter dropbox, cahiers de labo en ligne propriétaires -> Remplacer par framadrop, gitlab/github

*Outils « intuitifs »*

-	Eviter tableurs, interfaces graphiques, exploration interactives -> apprendre à se contrôler, basculer sur des langages comme R, python

## Sous-partie 3 : Le document computationnel, principe

Le document computationnel permet :

-	Inspecter les calculs
-	Réexécuter facilement les calculs si l'environnement d'origine est disponible
-	Documenter le code
-	Expliquer pourquoi tel ou tel calcul est effectué en fonction des données analysées 
-	Utiliser plusieurs langages pour faire des calculs (même si cela peut demander un peu de travail)

## Sous-partie 4 : Travailler avec les autres

**Publier / Partager un document**

-	Rpubs : parfait pour un partage rapide, pas pérenne
-	Dropbox et autres : posent des problèmes d'accès
-	Gitlab/Github : rendre publique (tout l'historique, attention aux commentaires problématiques), faire le ménage et archiver l'état courant dans des sites compagnons
-	Sites compagnons : Rummycode, éditeurs ; pour les articles HAL ; pour le code et les données : Figshare et Zenodo

# Module 3 : La main à la pâte : une analyse réplicable

**Objectifs**
- Apprendre à réaliser une analyse de données de façon reproductible et traçable
- Maîtriser quelques bonnes pratiques pour la préparation de documents computationnels

## Sous-partie 1 : Une analyse réplicable c'est quoi ?
- A la différence des analyses classiques, une analyse réplicable se focalise sur la discussion de la méthode, fournie le code en entier et explicite toutes les étapes plutôt que de se focaliser sur les résultats
- Pourquoi faire réplicable ? : facile à refaire si les données changent, facile à modifier, facile à inspecter et modifier

## Sous-partie 2 : Etude de cas : l'incidence de syndromes grippaux
- aucune modification des données à la main
- du code pour tout !

## Sous-partie 3 : Importation de données dans RStudio
- La lecture de données doit se faire directement à la source
- Attention aux données manquantes (ne pas les supprimer "à la main")

## Sous-partie 4 : Vérification et Inspection avec RStudio
- Effectuer un prétraitement des données : pour adapter le code aux conventions du logiciel et facilité l'analyse
- Vérifier autant que possible : inspection visuelle + code de validation

## Sous-partie 5 : Question et Réponses
- Une analyse réplicable doit contenir toutes les étapes de traitement de données sous une forme exécutable
- Expliquer tous les choix qui peuvent influencer les résultats (préciser tous les détails techniques)

# Module 4 : Vers une étude reproductible, la réalité du terrain

**Objectifs**
- Repliquer le travail de quelqu'un d'autre
- Comprendre les difficultés techniques qui se présentent lors du passage de l'exercice à la vraie vie
- Etudier quelques pistes de solutions