Environnement reproductible en R avec renv : fixez les versions des packages pour une analyse clinique

Fixez chaque version de package dans une bibliothèque locale au projet et un fichier de verrouillage versionné, pour qu’une analyse clinique se reproduise exactement sur une autre machine et des années plus tard — l’environnement devient une partie de la piste d’audit, et non une réflexion après coup

Un guide pratique et exécutable des environnements reproductibles en R avec renv. Découvrez pourquoi les jeux de données dérivés d’une soumission doivent être régénérables dans un environnement qualifié et reproductible, puis fixez chaque version de package avec renv : lisez ce qu’enregistre un fichier de verrouillage renv.lock, analysez un script pour en trouver les dépendances, et exécutez le workflow init -> snapshot -> commit -> restore qui fait qu’une analyse se reproduit octet pour octet sur une autre machine et après une dérive de version. Les exemples d’analyse de fichier de verrouillage et de balayage des dépendances s’exécutent ici ; les commandes de projet renv s’exécutent dans votre propre projet.

Date de publication

1 juillet 2026

Modifié

7 juillet 2026

AstucePoints clés
  • La reproductibilité, c’est le même code plus le même environnement qui donnent le même résultat — à chaque fois. Dans une soumission, le code n’est que la moitié du dossier ; les versions de chaque package qui a produit les chiffres en sont l’autre moitié. Fixez-les, sinon le résultat n’est pas reproductible.
  • renv (abréviation de « reproducible environment », environnement reproductible) donne à chaque projet sa propre bibliothèque de packages privée et enregistre la version exacte de chaque package dans un fichier de verrouillage (lockfile) versionné, de sorte que les dépendances du projet sont isolées du système et de tous les autres projets.
  • Le fichier de verrouillage renv.lock est le contrat. C’est un petit fichier JSON qui liste la version de R, les dépôts et — pour chaque package — son nom, sa version exacte et une empreinte de contenu (hash). Versionné aux côtés de votre code, il est le dossier de l’environnement.
  • Trois commandes constituent tout le workflow. renv::init() crée une bibliothèque de projet et un fichier de verrouillage ; renv::snapshot() écrit les versions actuelles dans le fichier de verrouillage ; renv::restore() reconstruit la bibliothèque identique à partir du fichier de verrouillage sur n’importe quelle machine.
  • Pour une analyse réglementée, l’environnement fait partie de la piste d’audit. Un jeu de données dérivé qu’un évaluateur ne peut pas régénérer n’est pas validé ; un fichier de verrouillage versionné est ce qui permet à un collègue — ou à un inspecteur, des années plus tard — de reconstruire l’environnement exact et de reproduire les chiffres.

Introduction

L’analyse s’exécutait parfaitement en 2024. Les tableaux concordaient avec le rapport statistique, le QC (contrôle qualité) a donné son feu vert, l’étude a été verrouillée. Puis, en 2026, un évaluateur pose une question légitime : reproduisez la table d’efficacité principale. Vous récupérez le code, l’exécutez sur une machine neuve — et les chiffres ne concordent plus. Rien n’a changé dans le code. Ce qui a changé, c’est l’environnement : un package est passé à une nouvelle version majeure, une valeur par défaut a basculé, une fonction qui supprimait les NA les conserve désormais, et une valeur dérivée s’est décalée à la troisième décimale. Le code n’est pas faux. Il s’exécute simplement avec un jeu de packages différent de celui qui a produit le résultat validé.

C’est cet écart que la reproductibilité vous fait gagner : la garantie que le même code plus le même environnement donnent toujours le même résultat. Le code, vous le versionnez déjà avec git. L’environnement — la version exacte de chaque package que l’analyse charge — est la moitié que la plupart des équipes oublient. Cette leçon comble cet écart avec renv (abréviation de reproducible environment, environnement reproductible) : donnez à chaque projet sa propre bibliothèque de packages privée, fixez chaque version dans un fichier de verrouillage versionné, et transformez « ça marchait sur ma machine en 2024 » en « ça se reconstruit à l’identique sur n’importe quelle machine, n’importe quelle année ».

A conceptual line chart contrasting a pinned and an unpinned R environment reproducing one derived result over three years. The pinned line (renv.lock, azure) stays exactly on the 2024 validated value of 2.31 in 2024, 2025 and 2026. The unpinned line (system library, orange) starts on the same 2024 value but drifts upward as packages silently update, reaching 2.58 by 2026 — the same code, different numbers. A dashed grey line marks the validated 2024 baseline.

La ligne orange, c’est la reproduction ratée de l’évaluateur : le même code, exécuté avec des packages qui ont discrètement évolué. La ligne azur, c’est ce que garantit un fichier de verrouillage versionné — l’environnement est gelé avec le code, si bien que le résultat ne dérive jamais. (La figure est une illustration conceptuelle, pas une analyse spécifique.)

Pourquoi l’environnement fait partie de la piste d’audit

Dans une analyse réglementée, la norme n’est pas « le code s’est exécuté » — c’est « le jeu de données dérivé peut être régénéré dans un environnement contrôlé ». Un résultat qu’un évaluateur ne peut pas reproduire n’est, du point de vue de la validation, pas validé du tout. Cela fait de l’environnement logiciel un élément de premier plan du dossier, au même titre que le code et les données.

C’est précisément pour cela que l’industrie traite la gestion des packages R comme un enjeu de validation. Le R Validation Hub — une initiative inter-pharma — présente la sélection des packages comme une activité fondée sur le risque dans son livre blanc sur la validation des packages R, et considère un environnement reproductible et traçable comme une responsabilité que chaque organisation doit assumer. Les pilotes FDA menés par le R Consortium Submissions Working Group le mettent en pratique : la soumission Pilot 1 a livré un renv.lock dans le cadre du dossier de soumission, précisément pour que l’agence puisse reconstruire l’environnement d’analyse.

Un environnement qualifié — un environnement dont le logiciel a été documenté et démontré apte à l’usage prévu — commence par un environnement reproductible : on ne peut pas qualifier ce qu’on ne peut pas reconstruire. renv ne qualifie pas, à lui seul, votre environnement ; il vous donne le socle reproductible sur lequel repose la qualification. Le reste de cette leçon explique comment le construire.

Ce que renv enregistre : le fichier de verrouillage

Avant d’exécuter la moindre commande renv, comprenez l’artefact autour duquel tout gravite : le fichier de verrouillage (lockfile), renv.lock. Un fichier de verrouillage est un fichier en texte brut qui enregistre la version exacte de chaque dépendance, afin que l’ensemble puisse être reconstruit précisément plus tard. Celui de renv est au format JSON — lisible, comparable (diff) et versionné dans git avec votre code.

Vous n’avez pas besoin que renv soit installé pour voir ce qu’il enregistre. Voici un renv.lock petit mais réaliste ; nous l’écrivons dans un fichier temporaire et le relisons avec R de base et jsonlite, exactement comme le ferait n’importe quel outil (ou évaluateur).

library(jsonlite)

# A realistic (abridged) renv.lock — normally generated by renv::snapshot()
lock_json <- '{
  "R": {
    "Version": "4.4.1",
    "Repositories": [
      { "Name": "CRAN", "URL": "https://packagemanager.posit.co/cran/2024-06-03" }
    ]
  },
  "Packages": {
    "ggplot2": {
      "Package": "ggplot2", "Version": "3.5.1", "Source": "Repository",
      "Repository": "CRAN", "Hash": "44c6a2f8202d5b7e878ea274b1092426"
    },
    "admiral": {
      "Package": "admiral", "Version": "1.1.1", "Source": "Repository",
      "Repository": "CRAN", "Hash": "9c7a2f8b1e4d6a0c3f5e7b9d2a4c6e80"
    }
  }
}'

lock_file <- tempfile(fileext = ".lock")
writeLines(lock_json, lock_file)

lock <- fromJSON(lock_file)

Deux choses sont fixées en tête : la version de R sous laquelle l’analyse s’est exécutée, et le dépôt d’où les packages proviennent — ici un instantané daté d’un dépôt de packages, de sorte que même « installer la dernière version » se résout à un point fixe dans le temps.

cat("R version pinned:", lock$R$Version, "\n")
R version pinned: 4.4.1 
cat("Repository:      ", lock$R$Repositories$URL, "\n")
Repository:       https://packagemanager.posit.co/cran/2024-06-03

Le cœur du fichier, c’est Packages : une entrée par dépendance, chacune portant sa Version exacte et un Hash de contenu. La version, c’est ce qui est fixé ; le hash permet à restore() de vérifier qu’il a reconstruit le même package octet pour octet, et non simplement un package arborant le même numéro de version.

pkgs <- lock$Packages
info <- data.frame(
  Package = vapply(pkgs, `[[`, "", "Package"),
  Version = vapply(pkgs, `[[`, "", "Version"),
  Hash    = vapply(pkgs, `[[`, "", "Hash"),
  row.names = NULL
)
info
  Package Version                             Hash
1 ggplot2   3.5.1 44c6a2f8202d5b7e878ea274b1092426
2 admiral   1.1.1 9c7a2f8b1e4d6a0c3f5e7b9d2a4c6e80

Voilà toute l’idée d’un fichier de verrouillage : un manifeste versionné et lisible par machine de l’environnement exact. Recréez la bibliothèque décrite ici et vous recréez l’environnement qui a produit les chiffres.

Ce dont renv prend l’instantané : vos dépendances

Comment renv sait-il quels packages fixer ? Il ne devine pas et il ne verrouille pas l’intégralité de votre bibliothèque système — il analyse votre code à la recherche des packages qu’il utilise réellement, via renv::dependencies(). C’est cette analyse statique que renv::snapshot() appelle en coulisses pour décider de ce qui a sa place dans le fichier de verrouillage.

Écrivez un petit script d’analyse, puis analysez-le. Ceci s’exécute ici et renvoie un vrai résultat :

library(renv)

script <- tempfile(fileext = ".R")
writeLines(c(
  'library(ggplot2)',
  'library(survival)',
  'cfg <- jsonlite::fromJSON("config.json")',   # detected via :: too
  'fit <- survfit(Surv(time, status) ~ sex, data = lung)'
), script)

deps <- dependencies(script, quiet = TRUE)
unique(deps$Package)
[1] "ggplot2"  "jsonlite" "survival"

renv a trouvé ggplot2 et survival à partir de leurs appels library() et jsonlite à partir d’une simple référence :: — l’analyse capture les deux. C’est important pour un instantané : un package que votre code utilise réellement est capturé, que vous l’attachiez avec library() ou que vous l’appeliez avec ::. (Elle ne capture pas un package chargé dynamiquement à partir d’une chaîne de caractères — une lacune que nous abordons dans les problèmes courants ci-dessous.)

Votre environnement actuel

Un dernier coup d’œil avant le workflow — où vivent les packages sans renv. R de base expose la version de R et le chemin de recherche des bibliothèques, qui sont par défaut partagés, à l’échelle du système entre tous les projets.

cat(R.version.string, "\n\n")
R version 4.5.1 (2025-06-13) 
.libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"

Ces chemins sont globaux : installez ou mettez à jour un package pour un projet et vous l’avez modifié pour tous les projets — c’est précisément ainsi que le résultat de 2024 dérive lorsqu’un projet ultérieur fait monter la version d’un package partagé. La solution de renv consiste à placer une bibliothèque locale au projet en tête de cette liste, afin que chaque projet résolve les packages à partir de son propre ensemble privé. Tout ce qui suit met cela en place.

Le workflow renv

Voici la discipline de bout en bout. Tout ce qui figure dans cette section modifie un projet — cela crée une bibliothèque, écrit un fichier de verrouillage, installe des packages — donc, contrairement aux blocs ci-dessus, ces commandes ne peuvent pas s’exécuter sur cette page. Exécutez-les dans votre propre projet ; les étapes et leur effet sont exacts.

Étape Commande Ce qu’elle fait
1. Initialiser renv::init() Crée une bibliothèque locale au projet et un renv.lock initial ; analyse votre code et installe ses dépendances dans la bibliothèque privée.
2. Travailler renv::install("pkg") / install.packages() Ajoute ou met à niveau des packages dans la seule bibliothèque du projet — jamais dans la bibliothèque système partagée.
3. Instantané renv::snapshot() Écrit les versions exactes actuellement utilisées dans renv.lock.
4. Versionner git add renv.lock Place le fichier de verrouillage sous contrôle de version avec votre code — le fichier de verrouillage est le dossier de l’environnement.
5. Restaurer renv::restore() Sur une autre machine, reconstruit la bibliothèque identique à partir de renv.lock.
6. Vérifier renv::status() Signale la dérive entre votre bibliothèque, votre code et le fichier de verrouillage.

Initialiser le projet

À exécuter une seule fois, dans le répertoire racine du projet. renv::init() met en place la bibliothèque privée, génère le premier fichier de verrouillage et — c’est important — fait en sorte que les nouvelles installations de packages atterrissent dans le projet, pas dans le système.

# In your project's root directory, run:
renv::init()

Après cela, votre projet dispose d’un dossier de bibliothèque renv/, d’un renv.lock et d’un .Rprofile qui active renv chaque fois que le projet s’ouvre. Un collaborateur qui ouvre le projet se trouve désormais sur la bibliothèque propre au projet, isolé de tout le reste présent sur sa machine.

Prendre l’instantané des versions exactes

Faites votre travail — installez les packages dont l’analyse a besoin, écrivez le code. Lorsque l’environnement est celui qui a produit vos résultats validés, gelez-le avec renv::snapshot(). Il réanalyse votre code, résout les versions actuellement installées et les écrit dans renv.lock.

# In your project, after installing the packages your analysis uses:
renv::snapshot()
# renv then writes/updates renv.lock with the exact versions in use.

Ensuite, versionnez le fichier de verrouillage. C’est l’étape qui fait de l’environnement une partie du dossier : renv.lock voyage avec votre code dans git, de sorte que l’état de l’environnement au moment de la validation est capturé pour toujours.

git add renv.lock
git commit -m "Snapshot analysis environment"

Restaurer l’environnement ailleurs

C’est là que se trouve la récompense. Sur une machine neuve — l’ordinateur portable d’un collègue, un serveur de validation, un runner CI, ou l’environnement d’un évaluateur des années plus tard — clonez le projet et exécutez renv::restore(). renv lit renv.lock et reconstruit la bibliothèque aux versions exactes qu’il enregistre, en vérifiant chacune par rapport à son hash.

# On any other machine, after cloning the project:
renv::restore()
# renv reads renv.lock and installs the exact versions it records.

L’évaluateur qui ne parvenait pas à reproduire la table de 2024 le peut désormais : renv::restore() rétablit les packages précis qui l’ont produite, et les chiffres concordent.

Vérifier la dérive

À mesure que le projet évolue, renv::status() vous indique si votre bibliothèque installée, votre code et votre fichier de verrouillage concordent toujours — par exemple, si vous avez installé un nouveau package sans en avoir pris l’instantané, ou si le fichier de verrouillage liste quelque chose que votre code n’utilise plus.

# In your project, to see whether the library and lockfile are in sync:
renv::status()

Si status() signale que le fichier de verrouillage n’est plus à jour, snapshot() le remet en phase — et vous le versionnez à nouveau.

Fixer et mettre à jour des versions précises

Parce que renv installe dans la bibliothèque du projet, contrôler une version revient simplement à installer celle que vous voulez et à en prendre l’instantané. Pour fixer une version précise, installez-la explicitement et gelez-la :

# In your project — install an exact version, then record it:
renv::install("ggplot2@3.5.1")
renv::snapshot()

Lorsque vous voulez délibérément des packages plus récents, renv::update() les met à niveau dans la bibliothèque du projet ; vous réexécutez ensuite votre analyse, confirmez que les résultats tiennent toujours, et faites snapshot() pour enregistrer le nouvel état. L’essentiel, c’est que les mises à niveau soient intentionnelles et enregistrées, jamais la dérive silencieuse et ambiante qui a cassé la reproduction de l’évaluateur.

🟢 Avec un agent IA

Demandez à Prova « guide-moi dans la mise en place de renv pour une analyse clinique en R — init, snapshot, versionner le renv.lock, et le restaurer sur un serveur de validation — et explique ce que le fichier de verrouillage enregistre et pourquoi un évaluateur en a besoin » — elle répond en s’appuyant sur les leçons de ce pilier, avec le workflow exact renv::init()/snapshot()/restore() et du code exécutable d’analyse de fichier de verrouillage que vous pouvez essayer. The runtime is the judge. Demandez à Prova →

Problèmes fréquents

Le fichier de verrouillage n’est pas versionné, donc personne d’autre ne peut le restaurer. renv.lock n’enregistre l’environnement que s’il voyage avec le code. S’il reste ignoré ou non versionné, un collègue qui clone le projet a le code mais pas les versions fixées, et la dérive revient. Traitez renv.lock comme du code source : git add renv.lock à chaque instantané, et ne l’ajoutez jamais au .gitignore.

Un package que l’analyse utilise réellement est absent de l’instantané. renv::snapshot() fixe ce que son analyse statique trouve — les appels library() et les références pkg::fun(). Il ne peut pas voir un package chargé dynamiquement, par exemple library(pkg, character.only = TRUE) où pkg est une variable, ou un nom construit à l’exécution. Soit référencez le package avec un simple library(pkg)/pkg::fun() quelque part pour que l’analyse le détecte, soit prenez l’instantané de tout ce qui est installé avec renv::snapshot(type = "all"). Exécutez renv::status() pour repérer la lacune avant la livraison.

renv::restore() avertit d’une version de R différente. Le fichier de verrouillage enregistre la version de R, mais renv restaure les packages, pas R lui-même. Si le fichier de verrouillage indique R 4.4.1 et que vous êtes sur 4.5, renv poursuit mais avertit — et un package compilé pour une autre version de R peut se comporter différemment. Pour un environnement pleinement reproductible, fixez aussi R : installez la version de R enregistrée (ou exécutez dans une image de conteneur construite dessus), puis restore(). La version de R dans renv.lock vous indique exactement laquelle faire correspondre.

Questions fréquentes

renv (abréviation de reproducible environment, environnement reproductible) est un package R qui donne à chaque projet sa propre bibliothèque de packages privée et enregistre la version exacte de chaque dépendance dans un fichier de verrouillage (renv.lock). Ses trois commandes principales sont renv::init() (créer la bibliothèque de projet et le fichier de verrouillage), renv::snapshot() (écrire les versions actuelles dans le fichier de verrouillage) et renv::restore() (reconstruire la bibliothèque identique à partir du fichier de verrouillage sur une autre machine). Il isole les packages de chaque projet du système et de tous les autres projets, de sorte qu’une analyse se reproduit exactement.

renv.lock est un petit fichier de verrouillage JSON qui enregistre l’environnement exact : la version de R, les dépôts de packages et — pour chaque package — son nom, sa version exacte et une empreinte de contenu (hash) (référence du format). Vous le versionnez dans git aux côtés de votre code. À partir du fichier de verrouillage, renv::restore() peut reconstruire la bibliothèque précise qu’il décrit sur n’importe quelle machine, ce qui rend l’analyse reproductible.

Utilisez renv. Installez la version exacte que vous voulez dans la bibliothèque du projet — renv::install("ggplot2@3.5.1") — puis renv::snapshot() pour l’enregistrer dans renv.lock, et versionnez le fichier de verrouillage. Parce que renv installe dans une bibliothèque locale au projet plutôt que dans la bibliothèque système partagée, la version fixée n’affecte que ce projet. Pour reproduire l’ensemble fixé ailleurs, renv::restore() reconstruit la bibliothèque aux versions que le fichier de verrouillage enregistre.

packrat était le prédécesseur de renv — l’ancien outil Posit (RStudio) pour la gestion de packages locale au projet. renv l’a remplacé par une conception plus rapide et plus simple : un cache de packages global partagé entre les projets (donc des restaurations rapides et peu gourmandes en disque), un fichier de verrouillage plus propre et un meilleur outillage. packrat n’est plus activement développé ; les nouveaux projets devraient utiliser renv. Le concept est le même — une bibliothèque de projet plus un fichier de verrouillage versionné — mais renv est l’outil actuel et maintenu.

renv rend votre analyse reproductible, ce qui est un prérequis pour un environnement qualifié — mais ce n’est pas, par lui seul, l’ensemble de la validation. Il capture les versions exactes des packages pour qu’un évaluateur puisse reconstruire l’environnement et régénérer vos jeux de données dérivés ; les pilotes FDA menés par le R Consortium Submissions Working Group ont inclus un renv.lock dans le dossier de soumission précisément pour cette raison. La qualification complète couvre également l’évaluation du risque des packages (voir le R Validation Hub), la documentation et souvent le fait de fixer R lui-même via un conteneur. renv est le socle reproductible sur lequel repose le reste.

Testez vos connaissances

On vous remet un projet avec un renv.lock versionné mais sans dossier de bibliothèque renv/ (un collègue a versionné le fichier de verrouillage mais pas la bibliothèque — correctement ignorée par git). Deux tâches :

  1. À l’aide de R de base et de jsonlite, lisez le renv.lock ci-dessous (écrivez-le d’abord dans un tempfile()) et affichez la version de R qu’il fixe ainsi qu’un data frame du nom et de la version de chaque package.
  2. En prose, indiquez l’unique commande que votre collègue doit exécuter pour reconstruire l’environnement, et une raison pour laquelle renv::restore() pourrait tout de même avertir même après avoir réussi.
{
  "R": { "Version": "4.4.2", "Repositories": [{ "Name": "CRAN", "URL": "https://packagemanager.posit.co/cran/2024-10-01" }] },
  "Packages": {
    "dplyr":  { "Package": "dplyr",  "Version": "1.1.4", "Hash": "aaa" },
    "rlang":  { "Package": "rlang",  "Version": "1.1.4", "Hash": "bbb" }
  }
}

Écrivez le JSON dans tempfile(fileext = ".lock") avec writeLines(), lisez-le avec jsonlite::fromJSON(), puis extrayez lock$R$Version et construisez un data frame à partir de lock$Packages avec vapply(pkgs, \[[`, ““,”Version”). Pour la tâche 2, la commande de reconstruction est un unique appelrenv::, et l'avertissement se rapporte au champR$Version`.

library(jsonlite)

lock_json <- '{
  "R": { "Version": "4.4.2", "Repositories": [{ "Name": "CRAN", "URL": "https://packagemanager.posit.co/cran/2024-10-01" }] },
  "Packages": {
    "dplyr":  { "Package": "dplyr",  "Version": "1.1.4", "Hash": "aaa" },
    "rlang":  { "Package": "rlang",  "Version": "1.1.4", "Hash": "bbb" }
  }
}'
f <- tempfile(fileext = ".lock")
writeLines(lock_json, f)
lock <- fromJSON(f)

cat("R version:", lock$R$Version, "\n")   # 4.4.2

pkgs <- lock$Packages
data.frame(
  Package = vapply(pkgs, `[[`, "", "Package"),
  Version = vapply(pkgs, `[[`, "", "Version"),
  row.names = NULL
)
#>   Package Version
#> 1   dplyr   1.1.4
#> 2   rlang   1.1.4

Tâche 2. Le collègue exécute renv::restore() dans le projet — il lit renv.lock et reconstruit la bibliothèque aux versions dplyr 1.1.4 et rlang 1.1.4. Il peut tout de même avertir au sujet de la version de R : le fichier de verrouillage fixe R 4.4.2, mais restore() installe des packages, pas R, donc sur une version de R différente il poursuit avec un avertissement. Faire correspondre R (via la version enregistrée ou une image de conteneur construite dessus) supprime l’avertissement et rend l’environnement pleinement reproductible.

A. renv::restore() B. renv::snapshot() C. renv::init()

B. renv::snapshot() analyse votre code, résout les versions actuellement installées et les écrit dans renv.lock — c’est ainsi que vous enregistrez l’environnement. renv::restore() fait l’inverse, en reconstruisant la bibliothèque à partir d’un fichier de verrouillage existant. renv::init() met le projet en place au départ (créant à la fois la bibliothèque et un fichier de verrouillage initial), mais c’est snapshot() que vous réexécutez pour capturer les changements ultérieurs.

Conclusion

La reproductibilité n’est pas une aspiration que l’on greffe au moment de la soumission — c’est une propriété que l’on intègre dès le premier renv::init(). Donnez au projet sa propre bibliothèque, faites snapshot() des versions exactes qui ont produit vos résultats validés, versionnez le renv.lock, et n’importe quelle machine — celle d’un collègue, un serveur de validation, celle d’un évaluateur, des années plus tard — peut faire renv::restore() de l’environnement identique et reproduire les chiffres. Le fichier de verrouillage enregistre la version de R, les dépôts et la version exacte et le hash de chaque package ; ce fichier versionné est la moitié « environnement » de la piste d’audit, la moitié que le code brut seul ne peut jamais porter. Le résultat de 2024 qu’un évaluateur ne pouvait pas reproduire en 2026 devient, avec un seul fichier de verrouillage versionné, un résultat qui se reproduit à la demande — ce qui est tout l’intérêt d’un environnement reproductible et qualifiable.

Note

Cette leçon est reproductible : les blocs d’analyse de fichier de verrouillage et de balayage des dépendances se reproduisent ici — copiez n’importe lequel d’entre eux et exécutez-le pour reproduire sa sortie. Les commandes de projet renv (init/snapshot/restore/status) s’exécutent dans votre propre projet, puisqu’elles créent une bibliothèque et écrivent un fichier de verrouillage ; copiez-les là-bas. The runtime is the judge.

Leçons connexes

  • Double programmation en R avec diffdf — valider les sorties d’une analyse par re-dérivation indépendante ; la reproductibilité garantit que cette re-dérivation s’exécute dans le même environnement. · Programmation défensive en R avec checkmate et assertthat — protéger les entrées d’un script par des assertions ; la discipline de QC complémentaire du contrôle de l’environnement. · Créer ADSL en R avec admiral — le type de dérivation dont un fichier de verrouillage fixe les versions exactes des packages. · Le passage de SAS à R pour la programmation clinique — là où le modèle de bibliothèque de projet de R remplace les conventions d’environnement SAS.
  • Où cela s’inscrit : construire des jeux de données ADaM (Analysis Data Model) avec admiral → valider ses sorties (double programmation avec diffdf) → défendre ses entrées (assertions avec checkmate) → geler l’environnement qui les a produits (reproductibilité avec renv — vous êtes ici). Un fichier de verrouillage est l’assurance la moins chère que vous possédez : il transforme « ça a marché sur ma machine » en « ça se reconstruit sur n’importe quelle machine, n’importe quelle année ».
Cette page vous a-t-elle été utile ?

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Environnement reproductible en R avec renv : fixez les
    versions des packages pour une analyse clinique},
  date = {2026-07-01},
  url = {https://www.datanovia.com/learn/pharma-clinical/05-validation-qc/reproducibility-renv},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Environnement reproductible en R avec renv : fixez les versions des packages pour une analyse clinique.” 2026. July 1. https://www.datanovia.com/learn/pharma-clinical/05-validation-qc/reproducibility-renv.