golem : applications Shiny de production en packages R

Q: Comment créer une application golem ?

Installez golem (install.packages("golem")), puis exécutez golem::create_golem("path/to/myapp", package_name = "myapp"). Cela génère tout le package. Ouvrez dev/01_start.R et exécutez-le une fois pour mettre en place l’identité et l’outillage de votre projet, puis travaillez au quotidien dans dev/02_dev.R — la commande centrale y est golem::add_module() pour ajouter des fonctionnalités. Lancez l’application avec golem::run_dev() pendant que vous construisez.

Q: golem contre les modules Shiny — quelle différence ?

Ce ne sont pas des concurrents : golem utilise les modules Shiny comme brique de base. Les modules sont le motif intégré NS()/moduleServer() pour des paires UI+serveur réutilisables et dotées d’un espace de noms ; golem est un framework entier qui structure votre application sous forme de package, génère ces modules pour vous (add_module()) et ajoute par-dessus un workflow et des générateurs de déploiement. Utilisez les modules seuls pour une petite application ; utilisez golem quand vous voulez toute la structure de package et le workflow autour d’eux.

Q: Comment déployer une application golem ?

golem génère les fichiers de déploiement — c’est avec eux que vous déployez. Dans dev/03_deploy.R, appelez le générateur pour votre cible : golem::add_dockerfile_with_renv() pour une image Docker, golem::add_shinyappsio_file() pour shinyapps.io, ou golem::add_positconnect_file() pour Posit Connect. Chaque fichier lance le run_app() exporté de votre application. Suivez ensuite les leçons de déploiement pour la construire et l’héberger : Docker, ShinyProxy, ou shinyapps.io.

Échafaudez votre application Shiny en package, obtenez un workflow de développement reproductible et générez vos fichiers de déploiement — le framework de production opinionné de ThinkR.

Programming

Shiny

Structurez une application Shiny en package R de qualité production avec golem. create_golem() génère le projet, les scripts dev/ 01→02→03 pilotent le développement quotidien, add_module() fait grandir l’application, golem-config.yml gère les réglages par environnement, et golem génère les fichiers Docker, shinyapps.io et Posit Connect avec lesquels vous déployez.

Date de publication

16 juillet 2026

Modifié

16 juillet 2026

Points clés

golem structure votre application Shiny comme un package R — une seule commande, golem::create_golem(), génère un package complet avec une disposition standard que tout développeur R reconnaît.
Les scripts dev/ sont tout le workflow. Trois fichiers numérotés pilotent l’ensemble : 01_start.R met le projet en place une fois pour toutes, 02_dev.R est votre boucle quotidienne (le geste central est add_module()), et 03_deploy.R génère les fichiers de déploiement.
Il s’appuie sur les modules Shiny. add_module("records") écrit une paire mod_records_ui() / mod_records_server() prête à l’emploi et la câble dans votre application — les modules sont l’unité sur laquelle golem grandit.
Une seule base de code, plusieurs environnements. inst/golem-config.yml et get_golem_config() permettent à la même application de se comporter différemment en développement et en production, selon une variable d’environnement.
The runtime is the judge. golem::run_dev() qui lance votre application en local, et myapp::run_app() après l’installation du package, prouvent que la structure tourne réellement — pas seulement que les fichiers existent.

Introduction

Votre application Shiny a commencé par un seul app.R. Elle a grandi, alors vous l’avez découpée en un dossier de fichiers que vous chargez avec source() en tête. Ça marche — jusqu’à ce que ça ne passe plus à l’échelle en tant que projet. Il n’existe aucune trace des packages dont elle dépend, aucun endroit où les tests sont branchés, aucune structure qu’un nouveau coéquipier reconnaît au premier coup d’œil, et son déploiement est un rituel assemblé à la main dont vous vous souvenez à moitié. Vous avez dépassé le stade du script, mais vous n’avez pas de système.

golem est ce système. C’est un framework opinionné, issu du cabinet de conseil R ThinkR, pour construire des applications Shiny sous forme de packages R. Au lieu d’un dossier informe, vous obtenez un vrai package : un fichier DESCRIPTION (les métadonnées et la liste des dépendances du package), un NAMESPACE (les fonctions que le package exporte et importe), un dossier de tests et une fonction de lancement — le tout généré pour vous. Par-dessus cette structure, golem ajoute deux choses qu’un package nu n’a pas : un workflow de développement reproductible (les scripts dev/) et des générateurs de fichiers de déploiement (un Dockerfile, un manifeste shinyapps.io, un fichier Posit Connect — écrits pour vous). Le gain, c’est la rigueur d’un package sans faire l’empaquetage à la main.

golem, c’est la conception du framework lui-même ; il s’appuie sur le motif des modules Shiny (des paires UI + serveur réutilisables, isolées par un espace de noms pour que les instances n’entrent pas en collision) et sur l’idée générale d’une application sous forme de package R, deux sujets qui ont chacun leur propre leçon dans cette série. golem automatise cet empaquetage — vous n’avez pas besoin d’écrire à la main un DESCRIPTION ou un NAMESPACE ; golem et ses fonctions auxiliaires les tiennent à jour pour vous.

Quand ne pas y recourir. Une application jetable de 50 lignes, un tableau de bord exploratoire ponctuel pour vous seul, une démo rapide — tout cela n’a pas besoin d’un package, et la structure de golem est une surcharge que vous ne rentabiliserez pas. golem prend toute sa valeur sur les applications que vous allez maintenir dans la durée, à plusieurs, et envoyer en production. Si ce n’est pas votre cas, un simple app.R est le bon outil. C’est le même jugement que portent les auteurs mêmes du framework dans Engineering Production-Grade Shiny Apps, le livre à l’origine de golem.

Prérequis

Vous tirerez le meilleur de cette leçon si vous êtes à l’aise avec les modules Shiny — le motif NS() (espace de noms) / moduleServer() pour des paires UI+serveur réutilisables — et avec l’idée d’une application sous forme de package R (un DESCRIPTION, un NAMESPACE, un dossier de tests). golem automatise l’empaquetage, vous n’avez donc pas besoin d’être un expert ; les deux sujets ont chacun leur propre leçon dans cette série Architecture Shiny. Il vous faut aussi golem installé :

install.packages("golem")

Cette leçon utilise golem 1.0.1 (la version CRAN actuelle au moment de la rédaction — consultez le site de golem pour la dernière). Le workflow de développement appelle aussi usethis, attachment et devtools ; ceux-ci figurent dans les Suggests de golem, si bien que golem::install_dev_deps() (exécuté une fois dans 01_start.R, ci-dessous) les installe pour vous.

Copiez n’importe quel bloc et exécutez-le en local

create_golem() écrit un vrai projet sur le disque et les scripts dev/ pilotent une session R vivante, donc rien sur cette page n’est exécuté ici — une page web statique ne peut ni générer un package ni lancer un serveur. Copiez n’importe quel bloc sur votre machine et exécutez-le. La preuve, c’est l’application qui tourne : lorsque golem::run_dev() ouvre votre application en développement, et que myapp::run_app() la lance après l’installation du package, vous avez montré que la structure fonctionne de bout en bout. The runtime is the judge.

Créer le projet

Une seule commande génère tout le package. Pointez-la vers un chemin et donnez-lui un nom de package (un nom de package R valide — lettres, chiffres et points, commençant par une lettre) :

golem::create_golem("path/to/myapp", package_name = "myapp")

Cela écrit un package golem complet et prêt à tourner. Voici la structure qu’il produit (montrée avec fs::dir_tree(), qui affiche un répertoire sous forme d’arborescence textuelle) :

fs::dir_tree("path/to/myapp")

myapp
├── DESCRIPTION            # package metadata + dependency list
├── NAMESPACE              # what the package exports/imports (kept current for you)
├── R
│   ├── app_config.R       # get_golem_config(), app_sys() — config + file access
│   ├── app_server.R       # the top-level server (calls your module servers)
│   ├── app_ui.R           # the top-level UI (assembles your module UIs)
│   └── run_app.R          # run_app() — the exported launcher
├── dev
│   ├── 01_start.R         # one-time project setup (run once)
│   ├── 02_dev.R           # the day-to-day development loop
│   ├── 03_deploy.R        # deployment-file generators
│   └── run_dev.R          # launch the app while developing
├── inst
│   ├── app
│   │   └── www            # static assets (CSS, JS, favicon)
│   └── golem-config.yml   # per-environment configuration
└── man
    └── run_app.Rd         # generated documentation for run_app()

Trois parties comptent dès le premier jour. Les fichiers R/ sont votre application : app_ui.R et app_server.R sont l’UI et le serveur de haut niveau qui assemblent vos modules, et run_app.R contient le run_app() exporté qui lance l’application finie. Les scripts dev/ sont votre workflow — toute la section suivante leur est consacrée. Et inst/golem-config.yml est l’endroit où vivent les réglages propres à chaque environnement. Tout le reste (DESCRIPTION, NAMESPACE, man/) est de la mécanique de package standard que les fonctions auxiliaires de golem entretiennent, si bien que vous l’éditez rarement à la main.

Le workflow dev/

Le dossier dev/ est le cœur de golem. Plutôt que de mémoriser un workflow, vous en exécutez un : trois scripts numérotés que vous ouvrez et lancez (ou parcourez ligne à ligne) aux bons moments. Vous ne les chargez pas en bloc avec source() — vous ouvrez chacun et exécutez les lignes dont vous avez besoin.

flowchart TD
    S["dev/01_start.R<br/>exécuter une fois — mettre en place le projet"] --> D["dev/02_dev.R<br/>boucle quotidienne — add_module, add_fct,<br/>synchro deps, document, run_dev"]
    D -->|"continuer à construire"| D
    D --> P["dev/03_deploy.R<br/>générer les fichiers de déploiement"]

01_start.R — la mise en place, une seule fois

Exécutez ce script une seule fois, juste après create_golem(). Il renseigne l’identité de votre package et active l’outillage que vous voudrez pour toute la vie du projet :

# Fill the DESCRIPTION with your app's identity
golem::fill_desc(
  pkg_name = "myapp",
  pkg_title = "My Production Dashboard",
  pkg_description = "A team dashboard, built as a package.",
  author_first_name = "Jane",
  author_last_name  = "Doe",
  author_email      = "jane@example.com"
)

golem::set_golem_options()          # record project paths golem uses later
usethis::use_mit_license()          # add a LICENSE (pick the licence you want)
golem::use_recommended_tests()      # wire in the testthat test harness
golem::install_dev_deps()           # install the packages the dev workflow needs
golem::use_favicon()                # a default favicon in inst/app/www
golem::use_utils_ui(with_test = TRUE)   # helper UI functions + their tests
golem::use_utils_server(with_test = TRUE)   # helper server functions + tests

Chaque appel accomplit une tâche de mise en place : fill_desc() écrit vos métadonnées dans DESCRIPTION, use_recommended_tests() installe un squelette de tests fonctionnel, et les fonctions auxiliaires use_utils_*() ajoutent de petites fonctions utilitaires sur lesquelles golem s’appuie couramment. Vous exécutez ce bloc une fois, puis vous l’oubliez.

02_dev.R — la boucle quotidienne

C’est ici que vous vivez. Chaque fois que vous ajoutez une fonctionnalité, vous revenez à 02_dev.R et exécutez les lignes concernées. Le geste le plus important, de loin, est d’ajouter un module :

golem::add_module(name = "records")   # creates R/mod_records.R (a UI + server pair)

À côté des modules, vous ajoutez de simples fonctions de logique métier et des ressources d’application :

golem::add_fct("helpers")     # R/fct_helpers.R  — business-logic functions
golem::add_utils("ui")        # R/utils_ui.R     — small helper functions
golem::add_css_file("custom") # inst/app/www/custom.css
golem::add_js_file("custom")  # inst/app/www/custom.js

Ensuite, une fois le code écrit, trois commandes gardent le package honnête :

attachment::att_amend_desc()  # scan your code, update DESCRIPTION's dependencies
devtools::document()          # regenerate NAMESPACE + man/ from your roxygen comments
devtools::test()              # run the test suite
golem::run_dev()              # launch the app in development mode

att_amend_desc() est celle qui vous sauve : elle lit chaque appel package::function() dans votre code et inscrit les packages manquants dans DESCRIPTION, de sorte que votre liste de dépendances ne se désynchronise jamais de ce que l’application utilise réellement. run_dev() lance l’application de la manière que spécifie dev/run_dev.R — la boucle de rétroaction rapide pendant que vous construisez.

03_deploy.R — générer les fichiers de déploiement

golem ne déploie pas votre application, mais il écrit les fichiers avec lesquels vous la déployez. Quand l’application est prête, ouvrez 03_deploy.R et générez la cible dont vous avez besoin :

golem::add_dockerfile_with_renv()            # a Dockerfile (+ renv for reproducibility)
golem::add_shinyappsio_file()                # a shinyapps.io deployment script
golem::add_positconnect_file()               # a Posit Connect manifest
golem::add_dockerfile_with_renv_shinyproxy() # a Dockerfile tuned for ShinyProxy

Chaque générateur dépose dans votre projet un fichier prêt à l’emploi et conscient de golem — un Dockerfile qui installe vos dépendances exactes, un script shinyapps.io qui pousse le package, et ainsi de suite. Ce que vous faites de ces fichiers est le sujet des leçons de déploiement — golem leur passe le relais proprement (voir la section Déployer ci-dessous).

Ajouter un module

add_module() est la commande que vous lancerez le plus, il vaut donc la peine de voir exactement ce qu’elle produit. Exécuter golem::add_module(name = "records") écrit R/mod_records.R, contenant une paire UI + serveur dotée d’un espace de noms :

# R/mod_records.R  (generated by add_module)

#' records UI Function
#' @noRd
#' @importFrom shiny NS tagList
mod_records_ui <- function(id) {
  ns <- NS(id)
  tagList(
    # your UI here
  )
}

#' records Server Functions
#' @noRd
mod_records_server <- function(id) {
  moduleServer(id, function(input, output, session) {
    ns <- session$ns
    # your server logic here
  })
}

golem vous indique aussi les deux lignes à coller dans vos fichiers de haut niveau pour câbler le module — son UI dans app_ui.R et son serveur dans app_server.R :

# in R/app_ui.R, inside the top-level UI:
mod_records_ui("records")

# in R/app_server.R, inside app_server():
mod_records_server("records")

L’échafaudage NS(id) / moduleServer(id, ...) est le motif standard des modules Shiny — golem se contente de le générer, de nommer les fichiers de façon cohérente (mod_<name>.R) et de vous rappeler où les brancher. Les modules sont l’unité sur laquelle golem s’appuie ; le fonctionnement de l’espace de noms en profondeur est traité dans la leçon sur les modules Shiny de cette série.

Configuration par environnement

Une application de production a généralement besoin de se comporter différemment de la même application sur votre portable — une autre base de données, une autre URL d’API, la journalisation verbeuse désactivée. golem gère cela avec inst/golem-config.yml, qui comporte des blocs nommés pour chaque environnement :

default:
  golem_name: myapp
  app_prod: false
  data_source: "dev-data.csv"

production:
  app_prod: true
  data_source: "/srv/data/live.csv"

Le bloc production: hérite de tout ce qui vient de default: et ne surcharge que ce qui change. Dans le code de votre application, vous lisez la configuration active avec get_golem_config() :

src <- get_golem_config("data_source")         # "dev-data.csv" or the prod path (from app_config.R)

Le bloc actif est déterminé par la variable d’environnement GOLEM_CONFIG_ACTIVE (golem se rabat sur la variable standard R_CONFIG_ACTIVE de R si elle n’est pas définie) ; si aucune des deux n’est définie, vous obtenez default. Ainsi, le même package, inchangé, lit les réglages de développement sur votre machine et les réglages de production sur le serveur :

Sys.setenv(GOLEM_CONFIG_ACTIVE = "production")  # set on the server / in the container

golem vous donne aussi golem::app_prod(), qui renvoie TRUE lorsque le drapeau app_prod de la configuration active est activé — pratique pour brancher selon l’environnement (par exemple, désactiver un panneau de débogage en production). Une seule base de code, un comportement conscient de l’environnement, sans la prolifération de if (Sys.getenv(...)).

Déployer

Voici la répartition nette des rôles : golem génère les fichiers de déploiement ; les leçons de déploiement prennent le relais. 03_deploy.R écrit un Dockerfile, un script shinyapps.io, un manifeste Posit Connect — chacun appelant le run_app() exporté de votre application pour la lancer. Ce qui l’exécute, c’est run_app(), le lanceur dans R/run_app.R qui renvoie un shiny.appobj ; après l’installation du package, myapp::run_app() démarre l’application de production, et c’est exactement ce qu’invoque le Dockerfile ou le script shinyapps.io généré.

Pour la livrer réellement, suivez les leçons de production — cette leçon ne les réenseigne délibérément pas :

Conteneurisez votre application prend le Dockerfile généré par golem et construit une image exécutable.
ShinyProxy auto-héberge cette image pour de nombreux utilisateurs, un conteneur chacun, derrière une connexion.
shinyapps.io est la voie managée — poussez le package avec le script écrit par golem, sans serveur à administrer.

Le travail de golem s’arrête à générer un fichier correct et complet en dépendances ; les leçons de production couvrent la construction, l’hébergement, l’authentification et le HTTPS.

golem : quand l’utiliser, quand s’en passer

golem n’est pas la seule façon de structurer une application Shiny. Adaptez l’outil à l’application :

	golem	Modules Shiny bruts	Rhino (Appsilon)
Ce que c’est	Un framework qui structure votre application sous forme de package R + un workflow + des générateurs de déploiement	Le motif intégré `NS()`/`moduleServer()` pour des paires UI+serveur réutilisables	Un framework plus lourd et plus opinionné, avec un outillage front-end (JavaScript) intégré
Échafaudage	Complet : `create_golem()` + les scripts `dev/`	Aucun — vous organisez les fichiers vous-même	Complet : `rhino::init()` génère une structure opinionnée
S’appuie sur	Utilise les modules Shiny comme unité	Est l’unité sur laquelle golem s’appuie	Ses propres conventions de modules (`box`)
Idéal pour	Applications maintenues, en équipe, de production, que vous voulez sous forme de package	N’importe quelle application, à toute échelle — la compétence de base	Les équipes voulant des conventions strictes + une chaîne d’outils JS/build moderne

Les modules bruts ne sont pas tant une alternative à golem que son fondement — golem génère les modules pour vous. Utilisez les modules seuls quand votre application est assez petite pour qu’un package soit exagéré, mais que vous voulez tout de même des composants réutilisables et dotés d’un espace de noms. Rhino, d’Appsilon, est l’autre framework de ce domaine : il est plus prescriptif que golem et mise sur l’outillage front-end (Sass, bundling JavaScript, linting) prêt à l’emploi — un bon choix pour les équipes qui veulent une structure plus stricte, à la saveur du développement web. golem est le choix quand vous voulez la rigueur d’un package R, un workflow guidé et des générateurs de déploiement sans adopter une chaîne de build JavaScript. Les trois sont légitimes ; golem trouve le juste équilibre pour les équipes R qui livrent des applications de production.

Problèmes fréquents

Dépendances manquantes au moment du déploiement — vous avez oublié att_amend_desc(). Votre application tourne en local (les packages sont installés sur votre machine) mais échoue dans le conteneur ou sur shinyapps.io avec « there is no package called ‘…’ ». La cause est un DESCRIPTION qui ne liste pas tous les packages utilisés par votre code. Exécutez attachment::att_amend_desc() avant de générer les fichiers de déploiement — il analyse votre code et écrit la vraie liste de dépendances. Faites-en la dernière chose que vous faites dans 02_dev.R avant de déployer.

Vous avez édité app_ui.R mais le changement n’apparaît pas — vous n’avez pas re-documenté. Après avoir ajouté un module ou modifié des exports, lancer l’application sans devtools::document() (ou devtools::load_all()) peut vous laisser devant un NAMESPACE périmé. Dans un package, vos modifications prennent effet après le rechargement du package, pas à l’instant où vous enregistrez le fichier. Exécutez devtools::document() puis golem::run_dev() après des changements structurels.

Vous avez lancé l’application avec shiny::runApp() et elle a planté. Une application golem est un package — son UI et son serveur vivent dans des fonctions exportées, pas dans un app.R informe qu’attend runApp(). En développement, lancez-la avec golem::run_dev() ; en production (après avoir installé le package), lancez-la avec myapp::run_app(). Recourir à runApp() sur le dossier du projet contourne la mécanique de package dont golem dépend.

Questions fréquentes

Qu’est-ce que golem en R ?

golem est un framework R opinionné, issu de ThinkR, pour construire des applications Shiny de qualité production sous forme de packages R. golem::create_golem() génère un package complet, les scripts dev/ vous donnent un workflow de développement reproductible, et golem génère vos fichiers de déploiement (Docker, shinyapps.io, Posit Connect). Il apporte la rigueur d’un package — suivi des dépendances, tests, structure standard — à Shiny sans que vous fassiez l’empaquetage à la main.

Comment créer une application golem ?

Installez golem (install.packages("golem")), puis exécutez golem::create_golem("path/to/myapp", package_name = "myapp"). Cela génère tout le package. Ouvrez dev/01_start.R et exécutez-le une fois pour mettre en place l’identité et l’outillage de votre projet, puis travaillez au quotidien dans dev/02_dev.R — la commande centrale y est golem::add_module() pour ajouter des fonctionnalités. Lancez l’application avec golem::run_dev() pendant que vous construisez.

golem contre les modules Shiny — quelle différence ?

Ce ne sont pas des concurrents : golem utilise les modules Shiny comme brique de base. Les modules sont le motif intégré NS()/moduleServer() pour des paires UI+serveur réutilisables et dotées d’un espace de noms ; golem est un framework entier qui structure votre application sous forme de package, génère ces modules pour vous (add_module()) et ajoute par-dessus un workflow et des générateurs de déploiement. Utilisez les modules seuls pour une petite application ; utilisez golem quand vous voulez toute la structure de package et le workflow autour d’eux.

Ai-je besoin de golem pour une petite application Shiny ?

Non. La structure de golem est une surcharge qui ne se rentabilise que sur les applications que vous allez maintenir dans la durée, à plusieurs, et envoyer en production. Une petite application jetable, un tableau de bord exploratoire personnel ou une démo rapide sont mieux servis par un simple app.R — y recourir à un framework d’empaquetage est de la sur-ingénierie. golem prend toute sa valeur lorsque l’application dépasse le stade du script et a besoin de suivi des dépendances, de tests et d’un déploiement reproductible.

Comment déployer une application golem ?

golem génère les fichiers de déploiement — c’est avec eux que vous déployez. Dans dev/03_deploy.R, appelez le générateur pour votre cible : golem::add_dockerfile_with_renv() pour une image Docker, golem::add_shinyappsio_file() pour shinyapps.io, ou golem::add_positconnect_file() pour Posit Connect. Chaque fichier lance le run_app() exporté de votre application. Suivez ensuite les leçons de déploiement pour la construire et l’héberger : Docker, ShinyProxy, ou shinyapps.io.

Qu’est-ce que golemverse ?

golemverse est le petit écosystème de packages autour de golem pour construire des applications Shiny de production. Il comprend fakir (des données factices pour le prototypage), shinipsum (des sorties de remplissage pour construire l’UI avant la logique) et dockerfiler (des Dockerfiles programmatiques). golem est le pivot ; vous recourez aux autres selon les besoins. (Le package attachment derrière att_amend_desc() dans votre boucle de développement est un outil de gestion des dépendances distinct de ThinkR, ne faisant pas partie de golemverse.)

Testez vos connaissances

À vous de jouer : générez une application et ajoutez un module

Vous démarrez un nouveau tableau de bord de production nommé salesapp. Écrivez les deux commandes golem qui (1) génèrent le package dans ~/projects/salesapp, et (2) ajoutent un module nommé filters. Nommez ensuite le fichier créé par la seconde commande et les deux lignes que vous colleriez dans vos fichiers de haut niveau pour câbler le module.

Indice

La commande d’échafaudage est create_golem() et prend un chemin plus un package_name. Ajouter un module se fait avec add_module() et un name. Un module nommé filters devient R/mod_filters.R, et son UI/serveur se câblent avec mod_filters_ui("filters") et mod_filters_server("filters").

Solution

# 1. Scaffold the package
golem::create_golem("~/projects/salesapp", package_name = "salesapp")

# 2. Add the module (run from dev/02_dev.R)
golem::add_module(name = "filters")

add_module("filters") crée R/mod_filters.R, contenant une paire mod_filters_ui(id) / mod_filters_server(id). Câblez-le en ajoutant son UI à R/app_ui.R et son serveur à R/app_server.R :

# in app_ui.R (inside the top-level UI):
mod_filters_ui("filters")

# in app_server.R (inside app_server()):
mod_filters_server("filters")

Exécutez ensuite golem::run_dev() pour la voir. La chaîne "filters" est l’identifiant d’espace de noms du module, et elle doit correspondre entre les appels UI et serveur.

Vérification rapide

Dans un projet golem, quel est le rôle des trois scripts numérotés du dossier dev/ ?

A. Ce sont l’UI, le serveur et la configuration de l’application.
B. C’est un workflow que vous exécutez : 01_start.R met le projet en place une fois, 02_dev.R est la boucle de développement quotidienne, et 03_deploy.R génère les fichiers de déploiement.
C. Ils sont exécutés automatiquement à chaque lancement de l’application.
D. Ils stockent les données de test de l’application.

Afficher la réponse

B. Les scripts dev/ sont le workflow de développement de golem, pas une partie de l’application en cours d’exécution. Vous ouvrez et exécutez 01_start.R une seule fois pour mettre en place le package, travaillez au quotidien dans 02_dev.R (où vivent add_module() et att_amend_desc()), et exécutez 03_deploy.R pour générer les fichiers de déploiement quand vous êtes prêt à livrer. Ils ne sont jamais exécutés automatiquement au lancement de l’application (C est faux) — l’application elle-même, ce sont les fichiers R/, lancés par run_app(). A décrit R/ et inst/golem-config.yml, pas dev/ ; D est inventé.

Conclusion

golem transforme une application Shiny qui a débordé de son app.R en un package R maintenable, avec un workflow assorti. create_golem() génère la structure ; les scripts dev/ la pilotent — 01_start.R une fois, 02_dev.R chaque jour (avec add_module() comme geste central et att_amend_desc() qui garde les dépendances honnêtes), 03_deploy.R pour générer les fichiers de déploiement. inst/golem-config.yml et get_golem_config() font que la même base de code se comporte correctement dans chaque environnement, et golem::run_dev() (développement) plus myapp::run_app() (production) sont la preuve à l’exécution que l’ensemble fonctionne. Recourez-y pour les applications que vous maintiendrez en équipe et livrerez en production ; passez votre chemin pour les jetables. Quand votre application golem est prête, son Dockerfile ou son script shinyapps.io généré passe le relais proprement aux leçons de déploiement — et vous avez une application Shiny bâtie comme un vrai logiciel.

Leçons connexes

Bâtissez sur les briques qu’utilise golem : la leçon modules Shiny de cette série Architecture enseigne le motif NS()/moduleServer() que golem génère avec add_module(), et les leçons application-sous-forme-de-package et organisation du code couvrent la structure DESCRIPTION/NAMESPACE/tests que golem automatise — lisez-les pour comprendre ce que golem fait pour vous. Puis conteneurisez votre application pour construire l’image que décrit le Dockerfile de golem, et auto-hébergez-la avec ShinyProxy ou déployez sur shinyapps.io pour une URL managée.
Aller plus loin : Applications web Shiny — tout le cursus Shiny. · Science computationnelle et IA — le pilier.

Cette page vous a-t-elle été utile ?

Prouvez que vous savez le faire. Maîtrisez toute la série Architecture Shiny — suivez votre parcours, construisez des projets et obtenez un certificat.

Commencer gratuitement →

Passez à Pro — Prova illimité sur vos propres données et un certificat vérifiable qui atteste la compétence.

dès 15 $/mois facturé annuellement

Passer à Pro →

✓ Vous êtes Pro — continuez. The runtime is the judge.

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {golem : applications Shiny de production en packages R},
  date = {2026-07-16},
  url = {https://www.datanovia.com/learn/programming/shiny/architecture/golem-framework},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“golem : applications Shiny de production en packages R.” 2026. July 16. https://www.datanovia.com/learn/programming/shiny/architecture/golem-framework.