Scripts R reproductibles : la fin du bricolage de versions
Tout data scientist qui a déjà reçu un script R.R d'un collègue connaît la suite : erreurs de packages manquants, version de R incompatible, résultats qui diffèrent subtilement. En entreprise, ce problème coûte cher, surtout quand le script doit tourner en production, être rejoué six mois plus tard, ou partagé entre une équipe sous Windows et une autre sous Linux. Jusqu'ici, la réponse passait par renv, un fichier lockfile séparé, et une discipline d'équipe pas toujours tenue.
Deux évolutions récentes de l'écosystème Posit changent la donne. rig, le gestionnaire d'installations R multiplateforme, continue de s'étoffer : il gère désormais non seulement le changement de version de R, mais aussi les packages et les projets, avec une approche cohérente sur macOS, Windows et Linux. En parallèle, ir introduit une idée plus radicale : un script R ou un document Quarto peut désormais déclarer lui-même, dans ses propres métadonnées, la version de R et les packages dont il a besoin. Plus besoin de fichier séparé à maintenir à côté : l'information de reproductibilité voyage avec le code.
Techniquement, ir s'appuie sur l'outillage existant plutôt que de le remplacer : pak pour la résolution de dépendances, renv pour l'isolation d'environnement, rig pour le changement de version R, et reticulate avec uv côté Python pour les projets mixtes. L'intérêt pratique, c'est qu'un script devient autoportant : on le reçoit, on l'exécute avec l'outil adapté, et l'environnement correct se reconstruit à la demande, sans configuration manuelle préalable.
Concrètement, cela change la manière de partager du code en entreprise. Un data scientist peut envoyer un script d'analyse exploratoire à un collègue, ou le déposer dans un dépôt partagé, avec la certitude qu'il tournera tel quel ailleurs. Pour les formations, c'est aussi un gain : un support de cours peut embarquer ses propres prérequis et s'auto-installer chez le participant, sans script d'installation séparé à faire exécuter en amont.
La limite est claire : ir est jeune, et son adoption dépend de la discipline à déclarer correctement les métadonnées dans chaque script. Rien n'empêche un développeur pressé de laisser le champ dépendances incomplet, et l'outil ne corrige pas les mauvaises pratiques de code, seulement celles de packaging. Pour les projets Shiny complexes ou les pipelines de production, renv seul reste probablement plus mature et mieux outillé côté CI/CD pour l'instant.
L'un dans l'autre, rig et ir dessinent une direction claire : rendre la reproductibilité native au code R lui-même, plutôt qu'un sujet annexe géré par des fichiers de configuration que personne ne relit.
# Exemple de script R autoportant avec metadata en commentaire
# (format illustratif inspiré de l'approche ir)
# /// script
# r_version: "4.4"
# dependencies:
# - xgboost
# - DBI
# ///
charger_donnees <- function(chemin) {
if (!file.exists(chemin)) {
stop("Fichier introuvable : ", chemin)
}
read.csv(chemin, stringsAsFactors = FALSE)
}
donnees <- charger_donnees("ventes.csv")
resume <- aggregate(montant ~ region, data = donnees, FUN = sum)
print(resume)L'entête en commentaire structuré illustre le principe : un outil comme ir peut lire ces métadonnées pour reconstruire l'environnement avant d'exécuter le reste du script.
L'idée d'un script auto-descriptif est la bonne réponse à un vrai problème d'entreprise, mais ir est trop récent pour remplacer renv en production. À suivre de près, à tester sur des scripts d'exploration dès maintenant.
→ Pour qui : Data scientists et data analysts qui partagent des scripts R entre collègues, formateurs, et équipes qui maintiennent plusieurs versions de R en parallèle.
LES BRÈVES
Positron se dote d'un serveur MCP pour piloter l'IDE
La dernière version de Positron introduit un serveur MCP intégré, permettant à des agents de code externes de piloter l'IDE lui-même : lancer une app Shiny, ouvrir un fichier Parquet, déployer sur Posit Connect. Les Data Connections sont aussi activées par défaut, simplifiant l'accès aux bases de données depuis l'interface.
Source : opensource.posit.co ↗Posit Connect Cloud affiche enfin la facture de vos apps Shiny
Un nouveau tableau de bord dans Posit Connect Cloud détaille les crédits consommés, le CPU, la mémoire et le temps de calcul par application déployée. Pour les équipes qui hébergent plusieurs apps Shiny en production, c'est enfin un moyen objectif d'ajuster les ressources allouées plutôt que de deviner.
Source : posit.co ↗LE TIP R DU JOUR
Repérer les colonnes constantes d'un data frame
Une colonne qui ne contient qu'une seule valeur distincte n'apporte aucune information et peut fausser une modélisation. sapply avec length(unique(x)) permet de les repérer en une ligne, sans boucle explicite.
df <- data.frame(a = c(1, 1, 1), b = c(2, 3, 4), c = c("x", "x", "x"))
constantes <- sapply(df, function(x) length(unique(x)) == 1)
names(df)[constantes]SOURCES
- https://opensource.posit.co/
- https://opensource.posit.co/blog/2026-10-13_positron-2026-10-release/
- https://posit.co/blog/introducing-usage-and-performance-metrics-posit-connect-cloud
- https://opensource.posit.co/blog/2026-07-23_ir-0-1-0/
VOUS CODEZ EN R ?
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.