#Écosystème et reproductibilitéCopier le lien

Un projet d'analyse de données doit être reproductible : un camarade qui clone le dossier doit retrouver les mêmes chiffres et les mêmes graphiques. R dispose pour cela d'un écosystème mature — figer les dépendances, mélanger texte et code, tester, distribuer. Cette section parcourt les briques et les assemble dans un atelier de synthèse.

#Prérequis et objectifsCopier le lien

• Prérequis : la section Prise en main (projet RStudio, renv::init, premier document Quarto).
• Figer les dépendances d'un projet avec renv et les restaurer ailleurs.
• Produire un rapport Quarto versionné et rendu en local comme en CI.
• Structurer des fonctions réutilisables dans un package testé.

#1. Gestion des dépendances : renvCopier le lien

renv fige les packages utilisés dans un projet. Après renv::init(), chaque installation est enregistrée dans renv.lock : nom du package, version exacte, source, hash. Sur une autre machine, renv::restore() reproduit l'environnement à l'identique.

1install.packages("renv")2renv::init()      # bibliothèque privée du projet + renv.lock3renv::install("dplyr")4renv::snapshot()  # met à jour renv.lock après une nouvelle installation5renv::restore()   # sur une autre machine : restaure les versions figées

Cette discipline évite les surprises lorsqu'un package change de comportement entre deux versions : l'analyse d'il y a six mois se rejoue avec les packages d'il y a six mois. Versionnez renv.lock avec le code (git) ; ignorez en revanche la bibliothèque privée renv/, régénérable.

#2. Reporting reproductible : QuartoCopier le lien

Les documents Quarto (.qmd) fusionnent texte, code et résultats : le rapport et l'analyse vivent dans le même fichier, et le rendu régénère figures et chiffres à chaque export.

1---2title: "Analyse des notes"3format: html4---5 6## Moyennes7 8```{r}9notes |>10  dplyr::group_by(filiere) |>11  dplyr::summarise(moyenne = mean(note))12```

Pour automatiser la génération, quarto render s'appelle depuis un script ou une tâche GitHub Actions ; le rapport devient un artefact versionné au même titre que le code. En local, le bouton Render de RStudio produit le même fichier : ce qui est versionné, c'est le .qmd, jamais seulement le HTML final.

#3. Packaging et testsCopier le lien

Dès que des fonctions se stabilisent, regroupez-les dans un package : documentation, tests et contrôles de qualité deviennent mécaniques au lieu d'être décrétés.

• usethis::create_package("palmaresR") : squelette (DESCRIPTION, NAMESPACE, R/).
• devtools::document() : génère la documentation à partir des commentaires roxygen2 (#' @title, #' @param, #' @export).
• testthat (usethis::use_testthat()) : tests unitaires dans tests/testthat/, lancés par devtools::test().
• lintr : vérification du style ; une erreur de syntaxe ou un library() oublié dans un package se voit avant la relecture.
• usethis::use_github_action_check_standard() : un workflow GitHub Actions qui exécute R CMD check à chaque push.

Un test unitaire type, sur une fonction de nettoyage des notes :

1test_that("bornage des notes", {2  expect_equal(borne_notes(c(25, -3, 12)), c(20, 0, 12))3})

#Atelier : le package palmaresRCopier le lien

1. Créez un package palmaresR contenant un jeu de données d'exemple, deux fonctions de nettoyage (borne_notes, mention de la section Manipulation) et une vignette Quarto qui raconte l'analyse de bout en bout.
2. Configurez une pipeline GitHub Actions qui exécute R CMD check, testthat et quarto render à chaque push.
3. Publiez la documentation avec pkgdown (usethis::use_pkgdown()) : le site statique décrit fonctions et vignettes.

Critère de réussite : un camarade clône le dépôt, lance renv::restore() puis devtools::check(), et tout passe sans intervention manuelle.