BIO500

# Séance 4

## Les outils pour la reproductibilité

---

# Les étapes du travail d'un biologiste

---

# Une situation courante

## le travail d'équipe

Ses difficultées techniques:

- Multi-utilisateurs
- Garder une trace de l'historique de modifications **d'un ensemble de fichiers**
- Revenir aux versions précédentes
- Comparer des versions d'un fichier
]

---

# Systèmes de versionnage existants

## Un exemple avec Dropbox

---

# Systèmes de versionnage existants

## Un exemple MS Word

---
class: inverse, center, middle

# Git: Un système de controle de version pour programmeur

---

# Qu'est ce que Git?

C'est un système qui permet de suivre l'**ajout** et les **modifications** pour un ensemble de fichiers.

**C'est le cahier de lab du programmeur.**

- Logiciel libre soutenu par une large communauté (12 millions d'utilisateurs dans le monde)
- Par défault, Git est installé sur les systèmes d'exploitation Linux et Mac.
- Il peut être installé sur Windows: [https://git-scm.com/download/win](https://git-scm.com/download/win)
]

.pull-right[
  .center[
    <img src="./assets/img/git.png" width="70%"></img>
    <img src="./assets/img/LinusTorvalds.jpg" width="50%"></img>

Linus Torvalds
  ]
]

---

# Qu'est ce que Git?

Il présente l'avantage d'être extrêmement versatile.

1. Racontez l'histoire de votre projet
2. Voyager dans le temps
3. Expérimentez avec les changements
4. Backup votre travail
5. **Collaborer sur des projets**

Mais le désavantage de fonctionner seulement avec les fichiers "plain text"...

**Question**: Qu'est ce qu'un fichier "plain text"?

---
# Les grandes étapes de git

0. Explorer l'interface web de github
1. Créer un compte
2. Créer un dépôt 
3. Installer git 
4. Associer un dépôt à RStudio
5. Bien structurer un projet 
6. Enregistrer les modifications 
7. Revenir en arrière 
8. Récupérer les modifications de co-équipiers

---
class: inverse, center, middle

# L'histoire d'un projet

---
# L'histoire d'un projet

---

# Quelques notions de base

- Une branche (`master` par défault): c'est un série de commentaires (`commit`)
- Le dernier commentaire (`commit`) est ce que l'on appelle la tête de la branche (`HEAD`), elle contient la version la plus à jour des fichiers.
- À chaque commentaire d'édition (`commit`) est attachée une version des fichiers.
]

---

# Le journal de Git

## L'historique des modifications

---

# Le journal de Git

![](./assets/img/rstudio_git_history.png)
]

---

# Se déplacer sur la branche `master`

![](./assets/img/rstudio_git_history.png)
]

---

# Se déplacer sur la branche `master`

```bash
git checkout master
```
ou

![](./assets/img/rstudio_git_history.png)
]

Permet de se déplacer vers le `commit` le plus récent.

---
# Revenir en arrière dans le temps

Les commandes de git sont très efficaces et puissantes, elles peuvent néanmoins être fastidieuses et difficiles pour les débutants.

RStudio facilite ce travail avec un simple onglet "history" et avec un navigateur qui vous permet de passer d'une version à l'autre et de mettre en valeur les modifications qui ont été enregistrées sous forme de commit.

---

# Exercice

1. Créer un dépôt sur GitHub
2. Associer le dépôt à RStudio
3. Ajouter un nouveau fichier (`add` *staged* et `commit`)
4. Téléverser les modifications sur le serveur (`push`)
5. Observerver les modifications sur le répertoire GitHub

---
# Travailler en équipe

- Git a été spécifiquement créé pour travailler en équipe.
- Plusieurs utilisateurs peuvent se connecter au même répertoire et y apporter des modifications.
- À chaque fois que l'on ouvre un projet il est approprié d'utiliser la commande `git pull` (un bouton sur l'interface git de Rstudio) afin de récupérer les modifications des autres membres de l'équipe.

![](./assets/img/rstudio_git_pull.png)

---
# Travailler en équipe

---
# La puissance de git

Les fonctionnalités de git sont immenses et RStudio permet de bien les utiliser.

Un tutoriel complet est disponible ici[https://happygitwithr.com/rstudio-git-github.html]

---

# En résumé

.pull-left[
## Enregistrer l'histoire du projet
  - `git add` ou `git stage`
  - `git commit`
  - `git status`

## Voyager dans le temps
  - `git checkout`
]
.pull-right[

## Verser sur le serveur 
  - `git push`

## Collaborer sur des projets
  - `git pull`
  - `git clone`
]

---

# Exercice

Cet exercice se fait en équipe de 2.

1. Ajouter votre partenaire à votre répertoire GitHub en tant que collaborateur : 
   - Aller sur votre répertoire GitHub.
   - Cliquer sur "Settings" > "Manage access" > "Invite a collaborator".
   - Entrer le nom d'utilisateur de votre partenaire et l'inviter à collaborer.
2. Un membre ajoute à son répertoire GitHub un fichier `README.md` avec `# Titre` pour entête et enregistre les modifications (`commit` puis `push`).
3. Associer le dépôt GitHub à RStudio sur l'ordinateur du partenaire.
4. Chacun modifie l'entête du fichier `README.md` et enregistre les modifications.
5. Git `commit` puis `push`.

Qu'est-ce qui arrive ?

## Un merge conflict (conflit de fusion) !!

Vous avez chacun fait des modifications sur un même fichier. Git ne sait pas quelle version prioriser.

---

# Gestion des conflits

Le conflit de de fusion est le résultat de deux modifications concurrentes sur un même fichier. C'est le conflit le plus fréquent et survient lorsqu'on oublie de `git pull` avant de `git push`

Il est possible de résoudre le conflit directement dans RStudio. Essayez-vous !

Marche à suivre : [Chapitre 7.3 *Git, Conflits*](https://econumuds.github.io/BIO500/git.html#conflits)

---

# Gestion des conflits

[Chapitre 7.3 *Git, Conflits*](https://econumuds.github.io/BIO500/git.html#conflits)

1. `pull` pour récupérer les modifications
2. Inspecter le fichier en conflit
3. Résoudre le conflit
4. Enregistrer les modifications : `add` (*staged*), `commit` et `push`

![](./assets/img/rstudio-merge-conflict.png)

---
class: inverse, center, middle

# Structurer un projet

<br>
- Organisation des fichiers
- Documentation

Un guide est disponible au [Chapitre Bonnes pratiques](https://econumuds.github.io/BIO500/bonnes_pratiques.html)

---

# Organisation des fichiers

.small[
```bash
monProjet/
│
├── .git/
│
├── data/
│   ├── raw/
│   └── processed/
│
├── scripts/
│   ├── data_cleaning.R
│   ├── data_analysis.R
│   └── data_visualisation.R
│
├── results/
│
├── reports/
│   ├── report.Rmd
│   └── report.pdf
│
├── .gitignore
│
└── README.md
```
]

---

# Documentation

- Le code : par des commentaires pour faciliter la compréhension.
- Le projet : le fichier `README.md` permet de documenter le projet avec une description, une structure, des instructions et des informations complémentaires.
---

# Documentation

## Le code

```r
#############################################
# Ce script permet de nettoyer les données
#
# Auteur: Victor Cameron
# Date: 2021-10-01
#############################################

# 1. Charger les données
data <- read.csv("data/raw/data.csv")

# 2. Nettoyer les données
clean_data <- clean_data(data)
```

---

# Documentation

## README.md

Quelques éléments à inclure dans un fichier `README.md` :

- Titre du projet : nom du projet.
- Description du projet : objectifs, contexte, données, méthodes, résultats. Ça peut être un résumé du projet.
- Structure du répertoire : organisation des fichiers, scripts et ressources.
- Description des fichiers : rôles et contenus des principaux fichiers.
- Instructions
    - Comment exécuter le projet.
    - Comment reproduire les résultats.
    - Comment accéder aux données et aux ressources.
- Auteurs et contributeurs : qui a travaillé sur le projet.

---

# .gitignore

## Ignorer certains fichiers de Git

Il existe des gabarits proposés pour [R](https://www.toptal.com/developers/gitignore/api/r).

```bash
# R
*.Rproj.user
*.Rhistory
.RData
```

---

# Exercice

## En équipe de projet de session

1. Chaque membre est ajouté à une équipe, ce qui donne accès à un répertoire GitHub pour le projet de session. 
   - Remplir le formulaire "Répertoire des équipes" sur *Moodle > Bloc2* pour être ajouté à une équipe.
2. Chaque membres de l'équipe clone le répertoire sur son ordinateur.
3. Créer la structure de projet selon les bonnes pratiques et y ajouter les fichiers nécessaires.
4. Ajouter un fichier README.md
5. Ajouter un fichier .gitignore

<br>

> Voir le [Chapitre *Bonnes pratiques*](https://econumuds.github.io/BIO500/bonnes_pratiques.html) pour les détails sur la structuration d'un projet et la documentation.

---

# Évaluation formative #2

## Structurer sa base de données

---

# Évaluation formative #2

**À remettre pour le 17 mars sur Moodle**

Vous avez à soumettre vos scripts qui servent à créer votre base de données. Vos scripts doivent contenir les commandes `R` et `SQL` pour créer la base de données, ses tables et injecter les données.

## La grille d'évaluation est diponible sur Moodle

[Grille d'évaluation](https://github.com/EcoNumUdS/BIO500/blob/master/ressources/bd_grille_de_correction.pdf)

---

# Évaluation formative #2

**Un membre par équipe** aura à remettre un dossier .zip contenant les scripts nécessaires pour créer la base de donnée et y injecter les données.

- Remise par un seul membre par équipe
- Spécifiez pour quel jeu de données la bd est conçue
- Commentez vos scripts pour que votre processus soit évident aux autres
- Diviser les tâches en fonctions distinctes
- Un script pour une fonction
- Un script principal qui décrit le processus et fait appel aux fonctions qui exécutent les tâches
- Vos scripts doivent produire une base de données avec les tables, le type de chacun des champs, les clés primaires et secondaires et les contraintes

---
class: inverse, center, middle

# Lectures et travaux à faire

---

# Lecture de la semaine

- [Biswas. 2023. ChatGPT for Research and Publication: A Step-by-Step Guide](https://www.doi.org/10.5863/1551-6776-28.6.576)
- [Nat. Mach. Intell. 2023. The AI writing on the wall.](https://github.com/EcoNumUdS/BIO500/blob/master/lectures/NatMaInt2023.pdf) 
- [Cooper. 2024. Harnessing language models for coding, teaching and inclusion to empoyer research in ecology and evolution.](https://doi.org/10.1111/2041-210X.14325)

---

# Séance 5

## Les outils pour la reproductibilité

---

# Aujourd'hui

1. Retour sur le dernier cours [[Chapitre 7 Git](https://econumuds.github.io/BIO500/git.html)].
2. Le cahier de laboratoire RMarkdown [[Chapitre 8 RMarkdown](https://econumuds.github.io/BIO500/markdown1.html#anatomie-du-rmarkdown)].
3. Principes clefs de la reproductibilité [[Chapitre 9 Principes clefs de la reproductibilité](https://econumuds.github.io/BIO500/principes_clefs.html)].
4. Discussion : Intelligence artificielle et écologie, opportunité ou menace pour la rigueur scientifique ?

---
# Retour sur le dernier cours

Il est recommandé de bien organiser ses fichiers afin de s'y retrouver plus facilement. On y retrouve habituellement les éléments suivants  :

- *README.md*: information sur le dépôt 
- *.Rproj*: informations sur le projet R
- *.git* : informations sur l'historique d'utilisation de git 
- *.gitignore*:  contient les extensions de fichier ignorés par git
- **data** : données du projet ainsi que la base de données
- **scripts**: tous les scripts R
- **figures**: résultats des analyses
- **rapport**: rapport final

---

# Retour sur le dernier cours

## .gitignore

Il arrive que certains scripts génèrent des fichiers temporaires qui ne doivent pas être conservés inutilement et être poussés sur github.

Le fichier `.gitignore` vous permet d'identifier les fichiers qui ne doivent pas être versés sur le serveur.

Il existe des gabarits proposés pour [R](https://www.toptal.com/developers/gitignore/api/r).

```bash
# R
.RData
.Rhistory

# R projets
.Rproj.user/

# Résultats intermédiaires
donnees_intermediaires/*
```

---

# Retour sur le dernier cours

## Processus ETL

- **Extract** : Collecte des données brutes de diverses sources.
- **Transform** : Nettoyage et mise en forme pour assurer cohérence et qualité.
- **Load** : Stockage des données prêtes à l’usage dans un système cible.

---
class: inverse, center, middle

# Le cahier de laboratoire RMarkdown

---

# C'est quoi le RMarkdown

- Un outil pour intégrer du texte, du code et des résultats
- Un format de fichier (`.Rmd`) pour créer des documents dynamiques avec R
- Une libraire R

---
# Pourquoi RMarkdown?

- Documentation (dynamique) des analyses
- Facilite le partage/communication des résultats
- Utilisable sur les systèmes de controle de version (Git)
- Reproductible!

---
# L'anatomie du RMarkdown

<br>
.center[
![:scale 90%](assets/img/Rmarkdown_anatomie.png)
]

---
# L'anatomie du RMarkdown

---
# L'anatomie du RMarkdown

<span style="color:rgb(101, 136, 71);">Metadata</span> + <span style="color:rgb(255, 199, 65);">Texte</span> + <span style="color:rgb(100, 164, 213);">Code chunk</span> = RMarkdown

---
# Exercice

1. Ouvrir Rstudio
2. Installer la libraire RMarkdown si necessaire (`install.packages('Rmarkdown')`)
3. Creer nouveau document RMarkdown (New File > RMarkdown)
4. Identifier le YAML, texte, et code chunk du document `.Rmd`
5. Compiler le document en html (bouton 🧶 `knit`)

---
# Le fichier RMarkdown

Vous pouvez suivre à l'aide du livre [Chapitre 8 RMarkdown](https://econumuds.github.io/BIO500/markdown1.html#anatomie-du-rmarkdown).

---
# Le YAML (metadata)

- Les métadonnées et les options du document sont définies ici
- La syntaxe est `cle: valeur`
- Commence et se termine avec trois tirets `---`
- Toujours au début du document

```r
---
title: "Mon titre"
author: "Victor Cameron"
date: "29/03/2022"
output: html_document
    toc: true
---
```

Les options d'`output` définissent le type de document produit.

Voir `?html_document`, `?pdf_document`, `?word_document`

---
# Markdown (contenu)

Du "plain text" avec une syntaxe minimaliste pour la mise en forme du texte

Ce mot est en *italique* et celui-ci
en **gras**.
Ici nous avons du `code`.
```
<br><br><br><br><br><br>
]

# Titre 1
## Titre 2
### Titre 3

Ce mot est en *italique* et celui-ci
en **gras**.
Ici nous avons du `code`.
]
]

---
# Markdown - listes

.font90[
.pull-left[
```md
Le texte qui suit est une liste :
- Premier item
- Second item
- Troisième item

Pour faire une énumération : 
1. Item 1
2. Item 2
3. Item 3
```
]

Pour faire une énumération : 
1. Item 1
2. Item 2
3. Item 3
]
]

---
# Markdown - images

```md
![Schéma d'un projet de recherche](assets/img/flow_full_repro.png)
```

![Schéma d'un projet de recherche](assets/img/flow_full_repro.png)

---
# Markdown - liens

```md
Voici le [lien](https://github.com/EcoNumUdS/BIO500) pour le GitHub du cours BIO500.
```

Voici le [lien](https://github.com/EcoNumUdS/BIO500) pour le GitHub du cours BIO500.

---
# Markdown - tables

.font90[
.pull-left[
```md
| Time          | Session | Topic    |
|:--------------|:-------:|---------:|
| _left_        | _center_| _right_  |
| 01:00 - 01:50 | 1       | Anatomy  |
| 01:50 - 02:00 |         | *Break*  |
| 02:00 - 02:45 | 2       | Tables   |
| 02:45 - 03:00 |         | *Break*  |
```
]

| Time          | Session | Topic    |
|:--------------|:-------:|---------:|
| _left_        | _center_| _right_  |
| 01:00 - 01:50 | 1       | Anatomy  |
| 01:50 - 02:00 |         | *Break*  |
| 02:00 - 02:45 | 2       | Tables   |
| 02:45 - 03:00 |         | *Break*  |

]]

<br><br><br><br><br><br><br><br><br>
- Le `:` spécifie l'alignement
- Possibilité d'utiliser des packages R spécialisés pour imprimer des tableaux automatiquement à partir de R (nous les verrons au dernier cours)

---
# Code chunk (script R)

L'utilité de Rmarkdown est de combiner du texte, du code et des images dans le même document

### Code dans le document Rmarkdown :

```{r}
data(iris)
iris_setosa <- subset(iris, Species == 'setosa')
head(iris_setosa)
```
````
]

---
# Code chunk (script R)

### Sortie Rmarkdown une fois compilé :

``` r
data(iris)
iris_setosa <- subset(iris, Species == 'setosa')
head(iris_setosa)
```

```
##   Sepal.Length Sepal.Width Petal.Length Petal.Width Species
## 1          5.1         3.5          1.4         0.2  setosa
## 2          4.9         3.0          1.4         0.2  setosa
## 3          4.7         3.2          1.3         0.2  setosa
## 4          4.6         3.1          1.5         0.2  setosa
## 5          5.0         3.6          1.4         0.2  setosa
## 6          5.4         3.9          1.7         0.4  setosa
```
]

---
# Code chunk (script R)

``` r
data(iris)
plot(iris$Sepal.Length, iris$Sepal.Width)
```

![](index_files/figure-html/unnamed-chunk-9-1.png)
]]

---

# Inclure du code directement dans le texte

### Code Rmarkdown:

``` r
le jeu de données *iris* comprend `r length(unique(iris$Species))` espèces
avec un total de `r nrow(iris)` fleurs mesurées.
```

### Sortie:

le jeu de données *iris* comprend 3 espèces avec un total de 150 fleurs mesurées.

---

# Configuration des code chunk

.font80[
Nommer le bloc de code (utile pour débogage)
````md
```{r plot_iris}
plot(iris$Sepal.Length, iris$Sepal.Width)
```
````
`echo=FALSE`:  afficher les résultats, mais pas le code
````md
```{r plot_iris, echo=FALSE}
plot(iris$Sepal.Length, iris$Sepal.Width)
```
````
`eval=FALSE`:  afficher le code, mais le code n'est pas évalué
````md
```{r plot_iris, eval=FALSE}
plot(iris$Sepal.Length, iris$Sepal.Width)
```
````
`include=FALSE`: évaluer le code, mais rien n'est affiché
````md
```{r plot_iris, include=FALSE}
plot(iris$Sepal.Length, iris$Sepal.Width)
```
````
]

---
# Ajuster la taille de la figure

````md
```{r plot_iris, fig.height = 3, fig.width = 5, fig.align = "center"}
plot(iris$Sepal.Length, iris$Sepal.Width)
```
````

---
# Configuration des code chunk

``` r
str(knitr::opts_chunk$get())
```

```
## List of 53
##  $ eval         : logi TRUE
##  $ echo         : logi TRUE
##  $ results      : chr "markup"
##  $ tidy         : logi FALSE
##  $ tidy.opts    : NULL
##  $ collapse     : logi FALSE
##  $ prompt       : logi FALSE
##  $ comment      : chr "##"
##  $ highlight    : logi TRUE
##  $ size         : chr "normalsize"
##  $ background   : chr "#F7F7F7"
##  $ strip.white  : 'AsIs' logi TRUE
##  $ cache        : logi FALSE
##  $ cache.path   : chr "01_head_cache/html/"
##  $ cache.vars   : NULL
##  $ cache.lazy   : logi TRUE
##  $ dependson    : NULL
##  $ autodep      : logi FALSE
##  $ cache.rebuild: logi FALSE
##  $ fig.keep     : chr "high"
##  $ fig.show     : chr "asis"
##  $ fig.align    : chr "default"
##  $ fig.path     : chr "index_files/figure-html/"
##  $ dev          : chr "png"
##  $ dev.args     : NULL
##  $ dpi          : num 72
##  $ fig.ext      : NULL
##  $ fig.width    : num 7
##  $ fig.height   : num 7
##  $ fig.env      : chr "figure"
##  $ fig.cap      : NULL
##  $ fig.scap     : NULL
##  $ fig.lp       : chr "fig:"
##  $ fig.subcap   : NULL
##  $ fig.pos      : chr ""
##  $ out.width    : NULL
##  $ out.height   : NULL
##  $ out.extra    : NULL
##  $ fig.retina   : num 1
##  $ external     : logi TRUE
##  $ sanitize     : logi FALSE
##  $ interval     : num 1
##  $ aniopts      : chr "controls,loop"
##  $ warning      : logi TRUE
##  $ error        : logi FALSE
##  $ message      : logi TRUE
##  $ render       : NULL
##  $ ref.label    : NULL
##  $ child        : NULL
##  $ engine       : chr "R"
##  $ split        : logi FALSE
##  $ include      : logi TRUE
##  $ purl         : logi TRUE
```
]

---

# Exercice : Reproduire le document suivant

---
# L'univers RMarkdown

![Tutoriel](https://ulyngs.github.io/rmarkdown-workshop/slides/figures/rmarkdown_universe.jpg)

---

# Autres ressources disponibles en ligne :

- R Markdown: The Definitive Guide [https://bookdown.org/yihui/rmarkdown/](https://bookdown.org/yihui/rmarkdown/)
- Cheat sheet [https://raw.githubusercontent.com/rstudio/cheatsheets/main/rmarkdown.pdf](https://raw.githubusercontent.com/rstudio/cheatsheets/main/rmarkdown.pdf)
- RMarkdown gallery [https://rmarkdown.rstudio.com/gallery.html](https://rmarkdown.rstudio.com/gallery.html)
- ResearchDown [https://insileco.github.io/ResearchDown/](https://insileco.github.io/ResearchDown/)

---

# Principes clefs de la reproductibilité

---

# Principes clefs de la reproductibilité

1. Séparation des responsabilités
2. Flux de données
3. Scalabilité avant performance
4. Traçabilité et maintenance
5. Principes FAIR

---

# 1. Séparation des responsabilités

Le concept de *Separation of Concerns* a été introduit par Edsger W. Dijkstra (1974) dans son article *On the Role of Scientific Thought*. Il s'agit d'une approche pour gérer la complexité des systèmes informatiques : **chaque partie du programme devrait s’occuper d’un seul aspect du problème**. En séparant les responsabilités, il devient plus facile de : comprendre le code, maintenir le programme et faire évoluer le système.

> Une fonction = une responsabilité

Une fonction devrait pouvoir être résumée en une seule phrase. Si la phrase contient “et”, la fonction fait probablement trop de choses.

❌ load_and_clean_data()

✔ load_data()

✔ clean_data()

---

# 2. Flux de données ETL

## *Extract – Transform – Load*

Un flux ETL décrit les étapes qui permettent de déplacer et préparer des données entre différentes sources et systèmes. Le concept a été popularisé dans les systèmes de gestion de données et constitue aujourd’hui une pratique centrale en ingénierie des données.

---

# 2. Flux de données ETL

## *Extract – Transform – Load*

**Extract**
Extraire les données depuis leur source
(ex. fichiers CSV, API, base de données, capteurs)

**Transform**
Nettoyer, filtrer, restructurer ou enrichir les données
(ex. corriger les valeurs manquantes, changer les formats, agréger)

**Load**
Charger les données dans le système cible
(ex. base de données, entrepôt de données, application)

---

# 3. Scalabilité avant performance

> “Premature optimization is the root of all evil.”
> — Donald Knuth

Ordre des priorités :
1. Le code **fonctionne**
2. Le code est **clair**
3. Le code est **rapide** (si nécessaire)

Un programme bien structuré est plus facile à faire évoluer et à adapter lorsque les données ou les besoins augmentent.

---

# 4. Traçabilité et maintenance

Objectif : **un programme reproductible et maintenable**

- **Paramètres explicites** : éviter les valeurs cachées dans le code. On peut expliciter les valeurs par défaut, les *paramètres*, en haut du script ou dans un fichier de configuration pour les rendre facilement modifiables
- **Logs** : garder une trace et suivre l'exécution du programme
- **Automatisation** : limiter les interventions manuelles : un fichier qui contient un ensemble de directives qui sont exécutées par l'ordinateur. Les instructions et leurs dépendances sont spécifiées
- **Tests** : vérifier que le code fonctionne toujours après des modifications

> Ces principes sont explorés dans un l'atelier qui suivra.

---

# 5. Principes FAIR

S'applique aux données, algorithmes et pipelines. Représentent un standard que tous peuvent suivre pour favoriser la reproductibilité et la transparence de leurs travaux.

---

# 5. Principes FAIR

## Findable

- (Trouvable) : Les données et scripts doivent être bien documentées et indexées pour être facilement retrouvées.
- DOI, métadonnées, catalogues de données.

---

# 5. Principes FAIR

## Findable

## Accessible
- (Accessible) : Les données doivent être accessibles avec des protocoles ouverts et, si elles sont restreintes, clairement expliquées.
- Dépôts de données ouverts, licences claires, accès via des API.

---

# 5. Principes FAIR

## Findable

## Accessible

## Interoperable

- (Interopérable) : Les données doivent être lisibles et utilisables par différents outils et logiciels.
- Formats ouverts, vocabulaire standardisé.

---

# 5. Principes FAIR

## Findable

## Accessible

## Interoperable

## Reusable

- (Réutilisable) : Les données et scripts doivent être suffisamment bien décrits et structurés pour être réutilisés dans d’autres contextes.
- Documentation détaillée, traçabilité des versions, attribution claire des auteurs.

---

# 5. Principes FAIR

Alors que l'adoption des principes FAIR sont centraux à la résolution de la crise de reproductibilité et sont à connaitre de tous les chercheurs, ils sont *de facto* appliqués à votre projet et ne requierent pas de travail supplémentaire :

- Utilisation d'un README et de commentaires pour documenter votre projet
- Utilisation de GitHub pour partager votre code et vos données
- Utilisation d'une base de données relationnelle pour stocker vos données
- Utilisation de R et RMarkdown pour concevoir et partager votre code et votre rapport

<!-- # Discussion

## Quels sont les liens concrets entre les principes FAIR et les étapes d'une étude scientifique ?

<!-- 
### **1. Contexte et importance des principes FAIR (5 min)**  
- **Problème actuel en science** : Difficulté à reproduire des études, accès limité aux données, méthodes peu documentées.  
- **Pourquoi les principes FAIR ?** : Créés pour améliorer la gestion, le partage et la réutilisation des données scientifiques.  
- **Objectif** : Assurer que les données soient facilement retrouvables, accessibles, compatibles avec différents systèmes et réutilisables par d’autres chercheurs.

### **2. Présentation des quatre principes FAIR (10 min)**

1. **Findable (Trouvable)**  
   - Définition : Les données doivent être bien documentées et indexées pour être facilement retrouvées.  
   - Exemples : Utilisation d’identifiants uniques (DOI), métadonnées complètes, catalogues de données.

2. **Accessible (Accessible)**  
   - Définition : Les données doivent être accessibles avec des protocoles ouverts et, si elles sont restreintes, clairement expliquées.  
   - Exemples : Dépôts de données ouverts, licences claires (ex. Creative Commons), accès via des API.

3. **Interoperable (Interopérable)**  
   - Définition : Les données doivent être lisibles et utilisables par différents outils et logiciels.  
   - Exemples : Formats ouverts (CSV, JSON), vocabulaire standardisé (ex. Darwin Core pour la biodiversité).

4. **Reusable (Réutilisable)**  
   - Définition : Les données doivent être suffisamment bien décrites et structurées pour être réutilisées dans d’autres contextes.  
   - Exemples : Documentation détaillée, traçabilité des versions, attribution claire des auteurs.

### **3. Lien avec la reproductibilité (5 min)**  
- Une étude reproductible nécessite que ses données soient bien organisées et accessibles.  
- Les principes FAIR réduisent les obstacles à la reproduction des résultats en rendant les données plus compréhensibles et exploitables.  
- **Question de transition pour la discussion** : Quels sont les liens concrets entre ces principes et les étapes d’une étude scientifique ?  
-->

---

# Mise en pratique

Complétez l'atelier `Séance 5 — Principes de reproductibilité` accessible sur Moodle > Bloc 2.

---

# Travail pour la semaine

---

# Consignes

- Identifiez clairement vos questions de recherche
- Planifiez les requêtes à réaliser pour traiter les données
- Créez un dépôt github pour votre projet 
- Créez un cahier de laboratoire où sont notées toutes vos étapes
- Versez votre travail sur le dépôt en ligne
- Construire le `_targets.R` au fur et à mesure de vos progrès

---

# Fiche de lecture

Vous avez à lire "The FAIR Guiding Principles for scientific data management and stewardship" de Wilkinson (2016) et répondre aux questions suivante en une page maximum à remettre en PDF avant le cours du 31 mars :

- Quel est l'importance des données, des métadonnées et du code dans crise actuelle de la reproductibilité ?
- Pourquoi les principes FAIR ? Quelle est leur pertinence ?
- Quel est le lien entre les principes FAIR et la reproductibilité ?

[Wilkinson et al. 2016. The FAIR Guiding Principles for scientific data management and stewardship.](https://github.com/EcoNumUdS/BIO500/blob/master/lectures/wilkinson2016.pdf)

---

# Débat : Intelligence artificielle et écologie, opportunité ou menace pour la rigueur scientifique ?

<br>
## 15 minutes pour préparer ses arguments
## 2 minutes pour présenter ses arguments
## 20 minutes de discussion dirigée
## 5 minutes vote et conclusion

<!-- 
Points de réflexion :

-  Fiabilité et biais : Les LLM peuvent-ils introduire des biais dans l'analyse des données écologiques ?
  -  Automatisation et créativité scientifique : Les LLM peuvent-ils renforcer la créativité ou risquent-ils de réduire l’esprit critique ?
  -  Accès aux données et reproductibilité : Les LLM facilitent-ils l’accès à des connaissances dispersées ou compliquent-ils la transparence des méthodes ?
  -  Éthique et impacts environnementaux : L'empreinte carbone des LLM est-elle compatible avec les objectifs de durabilité écologique ?

Retour sur règles de l'université de Sherbrooke : 
- Responsabilité étudiants : https://www.usherbrooke.ca/intranet-education/fileadmin/sites/intranet-education/documents/Intranet/Reglements_facultaires/Informations_facultaires_VF_en_vigueur.pdf
- Lignes directrices : https://www.usherbrooke.ca/decouvrir/a-propos/priorites-institutionnelles/intelligence-artificielle/lignes-directrices-iag
- Biblio : https://libguides.biblio.usherbrooke.ca/IA
-->

---

# Essai sur la reproductibilité

---

# Objectifs

L'objectif d'un essai est de présenter une perspective sur un enjeu scientifique, appuyé par une argumentation logique et une lecture critique de la littérature. L'objectif spécifique de ce travail est de formuler et défendre une opinion sur les enjeux de reproductibilité en écologie.

---

# Mise en situation

Le journal Québec Science vous a invité à titre de chercheur à écrire l'éditorial du mois sur cet enjeu. Plus spécifiquement, on vous demande de vous exprimer sur l'importance de la *transparence* et des standards de *reproductibilité* dans un contexte où il y a une accélération de la recherche par l'utilisation de l'intelligence artificielle. Cette invitation fait suite à la publication d'un article paru dans le dernier numéro du journal :

[ChatGPT en science : alerte à l’imposteur!](https://www.quebecscience.qc.ca/edito/chatgpt-science-alerte-imposteur/)

Vous êtes invités à faire une lecture critique de la situation actuelle, à identifier là où les agents conversationnels utilisant l'intelligence artificielle peuvent aider et à proposer des mesures qui permettront de répondre aux enjeux actuels.

---

# Attentes

Québec Science est un journal destiné à un grand public, alors je vous invite à personnaliser votre argumentation et à rendre original sa présentation. Vous pouvez utiliser des tableaux, des figures ou encore des encadrés pour étayer vos propos. Essayez de faire plus que de rapporter les arguments présentés en classe, n'hésitez pas à **personnaliser** votre essai.

---

# Consignes

- Le texte doit faire au maximum 1200 mots et doit être accompagné d'un résumé court, provocateur de 100 mots. Le document peut être supporté par une figure et/ou un tableau.
- L'argumentaire doit être supporté de littérature scientifique appropriée. Vous pouvez utiliser les références discutées en classe, celles disponible sur le dépôt git et vous devez également trouver de **nouvelles références** pour appuyer vos propos.
- Pour chaque argument (positif ou negatif) amené, vous devez en **donner un exemple personnel et concret** prenant place dans le cadre d'un travail scolaire.
- Le texte peut être structuré en sections afin de permettre au lecteur de suivre le développement de l'argumentaire.
- La section finale doit résumer les principaux points.

---

# Évaluation

- Respect des consignes
- Titre et résumé
- Formulation de la proposition 
- Qualité de l'argumentation
    + Identification de l'apport de l'intelligence artificielle
    + Identification des problèmes
    + Proposition de solutions
    + Qualité de la mise en contexte personnelle (exemples)
- Originalité
- Mise en page
- Bibliographie
- Qualité de la langue