Développement de packages R dans VS Code

Créez, documentez, testez et vérifiez des packages R avec devtools dans VS Code.

Développez des packages R dans VS Code — générez la structure avec usethis, documentez avec roxygen2, lancez load/test/check de devtools, et utilisez l’intégration Git et le terminal de l’éditeur pour une boucle complète de développement de packages, sans quitter VS Code.

Date de publication

8 juillet 2026

Modifié

9 juillet 2026

AstucePoints clés
  • Quatre packages font le travail ; VS Code est l’éditeur qui les entoure. usethis génère la structure, roxygen2 documente, testthat teste, et devtools pilote toute la boucle depuis le terminal R.
  • Générez la structure, ne la construisez pas à la main. usethis::create_package() met en place la structure standard ; use_r() et use_test() ajoutent les fichiers source et de test appariés au bon endroit.
  • Documentez dans le fichier source. Écrivez des commentaires roxygen2 au-dessus de chaque fonction, lancez devtools::document(), et les fichiers d’aide man/*.Rd ainsi que le NAMESPACE sont générés pour vous.
  • La boucle interne tient en trois appels. devtools::load_all() pour recharger, devtools::test() pour lancer les tests, devtools::check() pour exécuter le R CMD check complet — le tout depuis le terminal R, sans quitter l’éditeur.
  • Git et la navigation dans le code sont intégrés. Le panneau Source Control de VS Code indexe et valide votre package, et le « aller à la définition », les diagnostics et l’autocomplétion facilitent les déplacements dans une base de code qui grandit.

Introduction

Vous avez écrit une poignée de fonctions R que vous réutilisez sans cesse d’un projet à l’autre, et les copier-coller depuis un vieux script commence à lasser. La solution consiste à en faire un package — la façon standard de regrouper des fonctions, leur documentation et leurs tests pour que vous (et d’autres) puissiez les charger avec library() n’importe où. Si vous travaillez déjà dans Visual Studio Code, vous n’avez pas besoin de passer à RStudio pour le faire.

Cette leçon construit un petit package de bout en bout dans VS Code : générez sa structure avec usethis, écrivez et documentez une fonction avec roxygen2, testez-la avec testthat, et exécutez la boucle load / test / check avec devtools — le tout depuis le terminal R, l’intégration Git de l’éditeur et la navigation dans le code se chargeant du reste.

Elle suppose que vous avez déjà configuré R dans VS Code (R, l’extension vscode-R et, idéalement, radian) et que vous êtes à l’aise pour exécuter R de façon interactive. Si un terme ci-dessous vous est inconnu, la référence canonique est le livre gratuit R Packages de Hadley Wickham et Jennifer Bryan — cette leçon en est le flux de travail spécifique à VS Code.

La boîte à outils du développement de packages

Installez les quatre packages une fois pour toutes. Ils constituent la chaîne d’outils standard pour les packages R, maintenue par la même équipe que le reste de r-lib :

install.packages(c("devtools", "usethis", "roxygen2", "testthat"))

Vous appellerez surtout devtools et usethis — mais devtools réexporte les fonctions dont vous avez besoin des trois autres, si bien que charger devtools dans votre session suffit au quotidien.

Package Rôle dans le flux de travail
usethis Génère la structure du package et ajoute des fichiers — create_package(), use_r(), use_test(), use_mit_license()
roxygen2 Transforme les commentaires #' au-dessus d’une fonction en fichiers d’aide man/*.Rd et gère le NAMESPACE
testthat Le cadriciel de tests unitaires — test_that(), expect_equal(), et compagnie
devtools Pilote la boucle — load_all(), document(), test(), check(), install(), build()
Astuce

Utilisateurs de Windows : installez d’abord Rtools. Construire et vérifier un package compile du code, et Rtools fournit la chaîne d’outils dont cette étape a besoin.

Créer un package avec usethis

Partez d’une page blanche. Ouvrez un terminal R dans VS Code (Command Palette → R: Create R terminal) et générez la structure d’un package avec usethis::create_package() — indiquez-lui le chemin où le package doit se trouver :

usethis::create_package("~/projects/mytools")

Cela crée le squelette standard du package et l’ouvre. (devtools::create() est l’ancien nom de la même chose et ne fait désormais qu’appeler usethis::create_package() en coulisses, donc les deux fonctionnent.) Vous obtenez un package minimal mais complet :

mytools/
├── DESCRIPTION      # package metadata: name, version, author, dependencies
├── NAMESPACE        # what the package exports and imports (generated — don't edit by hand)
├── R/               # your function definitions live here
└── mytools.Rproj    # project file (optional)

Ouvrez ensuite le dossier comme espace de travail VS Code — File → Open Folder… et sélectionnez mytools. À partir de là, le terminal de l’éditeur, Source Control et la navigation opèrent tous sur le package.

Deux fonctions utilitaires de usethis terminent la configuration : ajouter une licence pour que le package soit légalement utilisable, et décrire ce qu’il fait. Modifiez les champs Title et Description du fichier DESCRIPTION dans l’éditeur, puis lancez :

usethis::use_mit_license()   # or use_gpl3_license(), etc.

Écrire et documenter une fonction

Ne créez jamais de fichiers dans R/ à la main — laissez usethis les nommer et les placer correctement. Ajoutez un fichier source avec use_r() ; le nom correspond à la fonction que vous êtes sur le point d’écrire :

usethis::use_r("summary_stats")

Cela crée et ouvre R/summary_stats.R. Écrivez-y la fonction. Au-dessus, ajoutez un bloc de documentation roxygen2 — les lignes de commentaire #' que roxygen2 lit pour générer la page d’aide :

#' Summary statistics for a numeric vector
#'
#' Computes the mean, standard deviation, and sample size of a numeric
#' vector, ignoring missing values.
#'
#' @param x A numeric vector.
#' @return A named list with elements `mean`, `sd`, and `n`.
#' @examples
#' summary_stats(c(1, 2, 3, NA, 5))
#' @export
summary_stats <- function(x) {
  x <- x[!is.na(x)]
  list(mean = mean(x), sd = sd(x), n = length(x))
}

Les balises méritent d’être connues : @param documente un argument, @return décrit le résultat, @examples fournit des exemples exécutables qui sont également vérifiés, et @export rend la fonction visible aux utilisateurs qui chargent votre package avec library() (elle ajoute une entrée au NAMESPACE). Retirez @export et la fonction reste interne.

Vous bénéficiez d’une véritable aide de l’éditeur pendant que vous écrivez. Le package languageserver (installé lors de la configuration) fournit des complétions au fur et à mesure que vous tapez — y compris les fonctions de votre propre package une fois qu’elles sont chargées :

Autocomplétion contextuelle dans VS Code suggérant des noms de fonctions et d’objets R au fur et à mesure que l’utilisateur tape dans un fichier source de package.

Une fois une fonction documentée, survoler son nom affiche la documentation roxygen en ligne, si bien que vous lisez l’aide sans quitter le fichier :

VS Code affichant la documentation d’une fonction dans une infobulle au survol, rendue à partir de son bloc de commentaires roxygen2, pendant l’édition d’un script R.

Générer la documentation

Les commentaires #' sont la source ; les fichiers d’aide réels sont générés. Lancez devtools::document() dans le terminal R :

devtools::document()

Elle fait deux choses : elle écrit un fichier .Rd dans man/ pour chaque fonction documentée (man/summary_stats.Rd ici), et elle met à jour le NAMESPACE à partir de vos balises @export. Relancez-la chaque fois que vous modifiez un bloc roxygen ou que vous ajoutez ou supprimez un @export. Une fois exécutée, ?summary_stats affiche votre page d’aide rendue, exactement comme celle de n’importe quel package installé.

Lorsque vous appellerez une fonction documentée plus tard, VS Code affiche sa signature au fur et à mesure que vous renseignez les arguments — la même aide en ligne que pour les packages CRAN, désormais pour les vôtres :

VS Code affichant la signature des arguments d’une fonction R définie par l’utilisateur dans une infobulle de paramètres au fur et à mesure que l’appel est tapé.

Recharger et essayer : load_all

Pendant le développement, vous ne réinstallez pas le package pour essayer une modification. devtools::load_all() simule l’installation et l’attachement du package, rendant chaque fonction — exportée ou non — disponible dans votre session comme si elle était installée :

devtools::load_all()
summary_stats(c(4, 8, 15, 16, 23, 42))
#> $mean
#> [1] 18
#>
#> $sd
#> [1] 13.49074
#>
#> $n
#> [1] 6

C’est la boucle interne la plus rapide du développement de packages : modifiez la fonction, load_all(), appelez-la, recommencez. Les fonctions que vous chargez apparaissent dans la visionneuse Workspace de la barre latérale R, aux côtés de vos autres objets, ce qui vous permet de confirmer ce qui est dans la portée :

La visionneuse Workspace de vscode-R dans la barre latérale, listant les objets de la session R en cours.

Pour un vrai bug, les outils intégrés de R fonctionnent exactement comme partout ailleurs : insérez un appel browser() dans la fonction et relancez load_all() pour y mettre l’exécution en pause, ou utilisez l’extension R Debugger pour poser des points d’arrêt dans la gouttière et avancer pas à pas avec F10 / F11 — abordé dans la leçon de programmation interactive.

Tester avec testthat

Un package sans tests est un package que vous avez peur de modifier. Mettez en place l’infrastructure testthat une fois, puis ajoutez un fichier de test apparié à votre fichier source avec use_test() :

usethis::use_testthat()          # one-time: creates tests/testthat/ and the runner
usethis::use_test("summary_stats")   # creates tests/testthat/test-summary_stats.R

use_test("summary_stats") reflète délibérément use_r("summary_stats") — la source et le test partagent un nom, si bien que l’appariement est évident. Écrivez des attentes à l’intérieur d’un bloc test_that() qui nomme le comportement que vous vérifiez :

test_that("summary_stats ignores missing values", {
  result <- summary_stats(c(1, 2, 3, NA, 5))
  expect_equal(result$mean, 2.75)
  expect_equal(result$n, 4)
})

Lancez toute la suite avec devtools::test() :

devtools::test()
#> ══ Testing summary_stats.R ═════════════════════════════════
#> [ FAIL 0 | WARN 0 | SKIP 0 | PASS 2 ]

PASS 2 sans échec signifie que les deux attentes ont été satisfaites. Si l’une échoue, testthat affiche le fichier, la ligne et les valeurs attendues par rapport aux valeurs réelles, de sorte que vous allez droit au problème. Gardez les tests à côté du code qu’ils couvrent et lancez test() après chaque modification.

Vérifier le package

devtools::test() exécute vos tests ; devtools::check() exécute le R CMD check complet — la même batterie d’environ 50 vérifications que celle utilisée par CRAN. Il reconstruit la documentation, lance les tests, vérifie que les exemples s’exécutent et confirme que le package s’installe proprement :

devtools::check()

Lisez le résultat de bas en haut — il se termine par un décompte de trois niveaux de gravité :

  • ERROR — le package est cassé (ne s’installe pas, un test a échoué, un exemple a produit une erreur). À corriger avant toute chose.
  • WARNING — un vrai problème que CRAN rejettera (arguments non documentés, un NAMESPACE désynchronisé). Corrigez-le.
  • NOTE — une simple remarque (un fichier anormalement volumineux, un signalement d’orthographe). Résolvez ceux qui comptent ; certains sont inévitables.

Visez 0 errors ✔ | 0 warnings ✔ | 0 notes ✔. Lancer check() régulièrement — et pas seulement avant une publication — évite que les petits problèmes s’accumulent.

Installer et partager

Lorsque la vérification est propre, installez votre propre package dans votre bibliothèque R afin de pouvoir faire library(mytools) dans n’importe quel projet avec devtools::install() :

devtools::install()

Pour remettre un fichier à quelqu’un, construisez une archive source (tarball) avec devtools::build() :

devtools::build()   # writes ../mytools_0.0.0.9000.tar.gz

Cette personne l’installe avec install.packages("mytools_0.0.0.9000.tar.gz", repos = NULL, type = "source"). En pratique, cependant, la manière habituelle de partager consiste à pousser le package sur GitHub — c’est là qu’intervient l’intégration Git de VS Code.

Gestion de versions avec Git

Un package est un dossier de fichiers en texte brut, il a donc sa place sous gestion de versions dès le premier jour. usethis::use_git() initialise un dépôt ; à partir de là, le panneau Source Control intégré de VS Code (l’icône de branche dans l’Activity Bar, Ctrl+Shift+G) est tout ce dont vous avez besoin. Il liste chaque fichier modifié, affiche un diff côte à côte lorsque vous cliquez dessus, et indexe et valide avec un message — aucun Git en terminal requis :

Le panneau Source Control de VS Code montrant des modifications de fichiers indexées et non indexées avec un diff côte à côte et la zone de message de commit.

Indexez les fichiers voulus (le + à côté de chacun, ou « Stage All Changes »), tapez un message de commit et validez. Pour publier, usethis::use_github() crée le dépôt distant et pousse en une seule étape, ou poussez un dépôt existant depuis le menu ⋯ → Push du panneau. Une fois sur GitHub, n’importe qui peut installer directement la version de développement :

# install.packages("remotes")
remotes::install_github("yourname/mytools")

Pour le flux de travail Git complet dans VS Code — branches, fusions et résolution de conflits — consultez le guide Git officiel de VS Code.

Problèmes fréquents

devtools::load_all() ne prend pas en compte ma modification. Vous n’êtes presque certainement pas dans le répertoire de travail du package, si bien que load_all() recharge un autre package (ou aucun). Vérifiez que getwd() pointe vers la racine du package, ou passez le chemin explicitement : devtools::load_all("."). Ouvrir le dossier du package comme espace de travail VS Code (File → Open Folder) définit automatiquement le répertoire de travail du terminal intégré.

check() signale des « undocumented arguments » ou une incohérence de NAMESPACE. Vous avez modifié un bloc roxygen ou une balise @export mais vous n’avez pas régénéré. Lancez devtools::document() puis relancez la vérification — les fichiers man/*.Rd et le NAMESPACE sont des artefacts générés et doivent être reconstruits après toute modification de la documentation.

Une nouvelle fonction est introuvable après load_all(). Deux causes habituelles : le fichier n’est pas dans R/ (seul ce dossier est chargé), ou la fonction n’a pas de @export et vous l’appelez comme mytools::fn() depuis l’extérieur. Les fonctions internes (non exportées) restent disponibles après load_all() par leur nom nu ; ajoutez @export et relancez document() uniquement lorsque les utilisateurs doivent l’appeler directement.

Questions fréquentes

Ouvrez un terminal R (Command Palette → R: Create R terminal) et lancez usethis::create_package("~/path/mypkg"). Cela génère la structure standard du package (DESCRIPTION, NAMESPACE, R/). Ouvrez ensuite ce dossier comme espace de travail VS Code avec File → Open Folder…, puis utilisez le terminal R pour le flux de travail devtools — document, test, check, install.

VS Code suffit. Le travail sur le package est effectué par les packages devtools, usethis, roxygen2 et testthat, que vous exécutez depuis n’importe quelle console R — les boutons de package de RStudio ne sont que des raccourcis vers ces mêmes fonctions. VS Code ajoute l’éditeur, un terminal R intégré, Git via le panneau Source Control et la navigation dans le code, qui couvrent ensemble toute la boucle de développement.

load_all() simule l’installation du package dans votre session actuelle — rapide, en mémoire, et il expose aussi les fonctions internes, c’est donc ce que vous utilisez pendant le développement. install() installe réellement le package construit dans votre bibliothèque R pour que vous puissiez le charger avec library() depuis n’importe quel projet. Utilisez load_all() dans la boucle édition-exécution ; install() lorsque le package est prêt à être utilisé pour de vrai.

Écrivez un bloc de commentaires roxygen2 au-dessus de la fonction à l’aide de lignes #' avec @param, @return, @examples et @export, puis lancez devtools::document(). Cela génère le fichier d’aide man/*.Rd et met à jour le NAMESPACE. Une fois exécuté, ?myfunction affiche votre page d’aide rendue. Relancez document() chaque fois que vous modifiez les commentaires.

test() n’exécute que vos tests unitaires testthat — un retour rapide pendant que vous codez. check() exécute le R CMD check complet : il reconstruit la documentation, lance vos tests, vérifie que chaque exemple s’exécute et confirme que le package s’installe proprement — les mêmes vérifications que celles appliquées par CRAN. Lancez test() souvent ; lancez check() avant de valider un jalon ou de publier.

Tâche. Vous ajoutez une nouvelle fonction exportée normalize() à R/normalize.R avec un bloc roxygen complet, puis vous lancez devtools::load_all() et l’appelez — cela fonctionne. Mais devtools::check() signale un WARNING à propos d’un objet « undocumented » et d’une incohérence de NAMESPACE, et ?normalize n’affiche aucune page d’aide. Les commentaires roxygen sont pourtant bien là. Quelle étape avez-vous oubliée, et comment la corriger ?

load_all() lit directement vos définitions de fonctions, donc la fonction s’exécute. Mais les fichiers d’aide man/*.Rd et le fichier NAMESPACE sont des artefacts générés — écrire les commentaires #' n’est que la source. Quelle commande transforme ces commentaires en documentation et en entrées de namespace réelles ?

Vous avez oublié devtools::document(). Les commentaires roxygen #' sont la source, mais le fichier d’aide man/normalize.Rd et l’entrée @export dans le NAMESPACE en sont générés. load_all() ne les génère pas, donc la fonction s’exécute alors que la documentation et le namespace manquent encore — c’est exactement ce que check() signale. Lancez devtools::document(), puis à nouveau devtools::check() ; l’avertissement disparaît et ?normalize affiche la page d’aide. Prenez l’habitude de lancer document() après toute modification d’un bloc roxygen ou d’une balise @export.

Vous avez modifié une fonction et voulez essayer la modification dans votre session le plus vite possible, sans installer le package. Quel appel utilisez-vous ?

A. devtools::install() B. devtools::build() C. devtools::load_all()

C. devtools::load_all() recharge le package en mémoire en quelques secondes et expose chaque fonction, c’est donc la boucle interne de développement. install() (A) installe dans votre bibliothèque — plus lent, et inutile juste pour tester une modification. build() (B) produit une archive .tar.gz partageable, pas une session active.

Conclusion

Développer des packages R dans VS Code, c’est la même boucle disciplinée que vous mèneriez n’importe où, pilotée depuis le terminal R intégré : usethis::create_package() pour générer la structure, use_r() et use_test() pour ajouter des fichiers source et de test appariés, les commentaires roxygen2 plus devtools::document() pour la documentation, et le cycle load_all() → test() → check() pour développer et valider. VS Code fournit l’éditeur, la navigation dans le code et un panneau Git intégré autour de cette boucle, si bien que vous construisez, documentez, testez et versionnez un package sans quitter la fenêtre que vous utilisez déjà pour tout le reste.

Leçons connexes

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
Note

Cette leçon est un guide reproductible de développement de packages : chaque commande usethis et devtools présentée ci-dessus est exactement ce que vous lancez dans votre propre terminal R au sein de VS Code — copiez n’importe quel bloc et lancez-le pour reproduire ce flux de travail sur votre machine. The runtime is the judge.

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Développement de packages R dans VS Code},
  date = {2026-07-08},
  url = {https://www.datanovia.com/learn/programming/r-in-vscode/r-package-development-in-vscode},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Développement de packages R dans VS Code.” 2026. July 8. https://www.datanovia.com/learn/programming/r-in-vscode/r-package-development-in-vscode.