Exécuter une application Shiny dans le navigateur avec Shinylive (sans serveur)

Q: Comment convertir une application Shiny existante en shinylive ?

Placez votre app.R (et toutes les données qu’il lit) dans un dossier, puis exécutez shinylive::export("your-folder", "site"). Cela écrit un site statique dans site/. Prévisualisez-le avec httpuv::runStaticServer("site/") avant de déployer le dossier vers un hébergeur statique.

Transformez un app.R en site statique qui tourne sans aucun serveur R derrière lui — et hébergez-le n’importe où.

Programming

Shiny

Déployez une application Shiny sans serveur. Shinylive compile votre application pour qu’elle tourne entièrement dans le navigateur via WebAssembly : vous pouvez donc l’exporter vers un site statique, la prévisualiser en local et l’héberger sur GitHub Pages ou Netlify — et vous apprendrez aussi quand les compromis du sans-serveur imposent de garder plutôt un vrai serveur R.

Date de publication

14 juillet 2026

Modifié

14 juillet 2026

Points clés

Shinylive supprime le serveur. Il compile votre application Shiny pour qu’elle tourne entièrement dans le navigateur du visiteur via WebAssembly — aucun processus R hébergé, aucun compte shinyapps.io.
Une seule commande l’exporte : shinylive::export("myapp", "site") transforme le dossier de votre application en un dossier de fichiers statiques que vous pouvez héberger n’importe où.
Prévisualisez avant de publier avec httpuv::runStaticServer("site/"), puis poussez le dossier vers GitHub Pages, Netlify ou n’importe quel hébergeur statique.
Connaissez le compromis. Tout tourne côté client : pas de secrets ni de base de données côté serveur, uniquement les packages disponibles dans webR, et un premier chargement plus lourd. Pour ces besoins, gardez un vrai serveur.
Pour intégrer une application dans une page Quarto plutôt que d’exporter un site entier, utilisez l’extension Quarto shinylive (quarto add quarto-ext/shinylive).

Introduction

Vous avez construit une application Shiny et vous voulez la partager. La réponse habituelle est de la placer sur un serveur qui exécute R — shinyapps.io, Posit Connect ou ShinyProxy — parce qu’une application Shiny a normalement besoin d’un processus R actif pour répondre au navigateur. Cela suppose un compte, une étape de déploiement, et souvent une facture.

Shinylive prend un autre chemin : il compile votre application pour qu’elle tourne dans le navigateur lui-même, sans serveur derrière elle. L’application devient un ensemble de fichiers statiques, et R tourne à l’intérieur de l’onglet du visiteur via WebAssembly (WASM) — un format binaire portable que les navigateurs exécutent à une vitesse proche du natif — par l’intermédiaire de webR, une version de R compilée pour WebAssembly. Le résultat est un site web statique tout à fait normal que vous pouvez déposer gratuitement sur GitHub Pages ou Netlify.

Cette leçon prend un app.R fonctionnel et parcourt tout le trajet : installer shinylive, exporter l’application vers un site statique, la prévisualiser en local, la déployer et — surtout — décider quand le sans-serveur est le mauvais choix. Elle suppose que vous savez déjà construire une petite application ; sinon, commencez par votre première application Shiny.

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

Le code R de cette page n’est pas exécuté ici — une application Shiny a besoin d’une session R active, et l’étape d’export écrit des fichiers sur le disque, aucun des deux ne tourne donc dans une page web statique. Copiez n’importe quel bloc dans R et exécutez-le en local (ou dans un fichier app.R et lancez-le avec shiny::runApp()). Chaque exemple est autonome et n’utilise que des données intégrées, il tourne donc tel quel. Le vrai test, c’est l’application exportée : quand elle tourne dans votre navigateur, vous avez prouvé qu’elle fonctionne — the runtime is the judge.

Comment fonctionne shinylive

Une application Shiny classique est un couple client–serveur : le navigateur affiche la page, et un processus R distinct sur un serveur fait les calculs. Shinylive replie tout cela d’un seul côté. Il prend votre ui, votre server et chaque package qu’ils utilisent, et les empaquette en actifs statiques — HTML, CSS, JavaScript et WASM — que le navigateur télécharge et exécute lui-même. Il n’y a pas de R installé sur l’hôte ; l’hôte ne fait que servir des fichiers.

Concrètement, shinylive repose sur trois composants (voir la documentation officielle de shinylive) :

webR — R lui-même, compilé en WebAssembly, pour que le navigateur puisse exécuter la logique de votre server.
Le package R {shinylive} — l’outil que vous exécutez en local pour convertir une application en site statique et pour gérer les actifs web dont elle a besoin.
Les actifs web de shinylive — le lot partagé de fichiers JavaScript et WASM qui démarrent webR et câblent la réactivité de l’application dans le navigateur. Le package les télécharge et les met en cache pour vous.

Comme l’application n’est que des fichiers, elle hérite de tous les avantages d’un site statique : elle est portable, peu coûteuse à héberger, et ne demande aucun runtime à maintenir. La contrepartie, c’est que tous les calculs se font désormais sur la machine du visiteur — ce qui est exactement le compromis dont parle la section suivante.

Quand utiliser shinylive — et quand ne pas le faire

Shinylive convient très bien au partage et à l’enseignement, et convient mal dès que l’application a besoin de quelque chose que seul un serveur peut lui offrir. Faites correspondre votre application à la bonne colonne :

Optez pour shinylive quand…	Gardez un vrai serveur R quand…
Vous voulez un hébergement statique gratuit (GitHub Pages, Netlify)	L’application a besoin de secrets côté serveur, d’une clé d’API ou d’une connexion à une base de données
L’application enseigne, fait une démo ou présente un projet de portfolio	Elle traite des données volumineuses ou sensibles qui ne doivent pas quitter le serveur
Tout le monde doit juste ouvrir une URL — sans connexion, sans coût	Elle repose sur un package qui n’est pas disponible dans webR
Le calcul est léger et tourne confortablement dans un navigateur	Le calcul est lourd, long ou gourmand en mémoire

Gardez à l’esprit les limites du sans-serveur avant de vous engager :

Pas de secrets côté serveur. Tout ce que l’application utilise est téléchargé vers le navigateur, donc une clé d’API ou un mot de passe inscrit dans l’application est visible par n’importe qui. Il n’y a pas de back-end privé pour le cacher.
Uniquement les packages disponibles dans webR. Votre application peut utiliser les packages qui ont été compilés pour WebAssembly. La plupart des plus courants (shiny, ggplot2, dplyr et des centaines d’autres) sont disponibles via le dépôt de webR, mais un package aux dépendances système lourdes peut ne pas l’être — consultez la documentation de webR si vous dépendez de quelque chose d’inhabituel.
Un premier chargement plus lourd (« démarrage à froid »). Le navigateur du visiteur télécharge webR et les packages de votre application avant que l’application apparaisse, donc la première visite est plus lente qu’une page web normale. Une fois en cache, les visites suivantes sont rapides.

Si aucun de ces points ne vous bloque, shinylive est le moyen le plus simple de mettre une application R interactive sur le web public.

Installer et configurer shinylive

Installez le package R {shinylive} depuis le CRAN :

install.packages("shinylive")

Pour la version de développement — parfois utile pour les tout derniers actifs de webR — installez-la depuis GitHub avec pak :

install.packages("pak")
pak::pak("posit-dev/r-shinylive")

La première fois que vous exportez une application, shinylive télécharge les actifs web dont il a besoin et les met en cache localement, vous n’avez donc pas à gérer cela à la main. Pour confirmer le package et voir quelle version d’actifs est en cache, exécutez :

shinylive::assets_info()

Cela affiche la version du package, la version des actifs web et le répertoire de cache local — un moyen rapide de vérifier que votre configuration est prête avant d’exporter.

Exporter votre application vers un site statique

Partez d’une application Shiny normale. En voici une petite qui dessine un histogramme du jeu de données intégré faithful (temps d’attente entre éruptions du Old Faithful) avec un curseur pour le nombre de barres — rien de spécifique à shinylive, juste une application ordinaire :

# myapp/app.R
library(shiny)

ui <- fluidPage(
  titlePanel("Old Faithful eruptions"),
  sidebarLayout(
    sidebarPanel(
      sliderInput("bins", "Number of bins:",
                  min = 1, max = 50, value = 30)
    ),
    mainPanel(
      plotOutput("distPlot")
    )
  )
)

server <- function(input, output, session) {
  output$distPlot <- renderPlot({
    x    <- faithful$waiting
    bins <- seq(min(x), max(x), length.out = input$bins + 1)
    hist(x, breaks = bins, col = "#3a86d4", border = "white",
         xlab = "Waiting time to next eruption (min)", main = "")
  })
}

shinyApp(ui = ui, server = server)

Enregistrez ceci sous app.R dans un dossier — appelez-le myapp. Lancez-la d’abord en local avec shiny::runApp("myapp") et confirmez qu’elle fonctionne : exporter une application cassée ne vous donne qu’un site statique cassé.

Maintenant, exportez-la. shinylive::export() prend le dossier de l’application et un dossier de destination, et écrit le site statique dans la destination :

# First argument: your app directory. Second: where to write the static site.
shinylive::export("myapp", "site")

Cela crée un dossier site/ contenant les fichiers HTML, JavaScript, CSS et WASM qui exécutent votre application dans un navigateur — aucun R requis pour les servir.

Avant de déployer, prévisualisez le site exporté en local. Il doit être servi via HTTP (ouvrir directement le fichier index.html ne chargera pas les actifs WASM), utilisez donc httpuv pour servir le dossier :

library(httpuv)
runStaticServer("site/")

Ouvrez l’URL qu’il affiche. Vous verrez la même application — mais cette fois R tourne dans votre navigateur, pas dans votre session R. C’est tout l’intérêt : l’application dans cet onglet est désormais complètement autonome.

Déployer vers un hébergement statique

Une fois que le site exporté se prévisualise correctement, le déployer se résume à publier un dossier de fichiers statiques. N’importe quel hébergeur statique convient ; voici le chemin GitHub Pages :

Créez un dépôt et ajoutez-y le contenu de votre dossier site/.
Activez GitHub Pages dans les paramètres du dépôt, en le pointant vers la branche et le dossier qui contiennent les fichiers exportés (la racine du dépôt ou un dossier docs/).
Committez et poussez. Votre application devient accessible à l’URL de Pages, par ex. https://yourusername.github.io/your-repo/.

Netlify, Cloudflare Pages et les services similaires suivent la même idée : pointez le service vers le dossier site/ (ou glissez-déposez-le) et il sert l’application. Comme les fichiers sont purement statiques, il n’y a rien à configurer côté serveur.

Intégrer une application dans une page Quarto

L’export produit un site autonome complet. Si vous voulez plutôt une application vivante intégrée dans une page — une leçon, un article de blog, un jeu de diapositives — utilisez l’extension Quarto shinylive plutôt que export(). Ajoutez-la à un projet Quarto depuis le terminal :

quarto add quarto-ext/shinylive

Écrivez ensuite l’application directement dans le document sous forme de bloc de code shinylive-r, et Quarto la rend comme une application interactive et sans serveur dans la page (l’extension repose toujours sur le package R {shinylive} sous le capot — voir le dépôt de l’extension) :

```{shinylive-r}
#| standalone: true
#| viewerHeight: 500

library(shiny)

ui <- fluidPage(
  sliderInput("bins", "Number of bins:", min = 1, max = 50, value = 30),
  plotOutput("distPlot")
)

server <- function(input, output, session) {
  output$distPlot <- renderPlot({
    x <- faithful$waiting
    hist(x, breaks = input$bins, col = "#3a86d4", border = "white", main = "")
  })
}

shinyApp(ui, server)
```

Utilisez export() quand vous voulez un site autonome à héberger ; utilisez l’extension quand l’application doit vivre à l’intérieur d’un autre contenu. (Les pages de cette leçon sont statiques et ne chargent pas cette extension — le bloc ci-dessus est montré à titre d’exemple, il n’est pas exécuté ici.)

Empaqueter des données et gérer plusieurs applications

Empaqueter des données. Tout fichier que vous placez dans le dossier de l’application aux côtés de app.R est inclus dans l’export, donc une application qui lit un CSV local fonctionne après export tant que vous le chargez avec un chemin relatif (read.csv("data.csv"), pas un chemin absolu). Gardez les données empaquetées légères — rappelez-vous que le visiteur télécharge tout.

Plusieurs applications, actifs partagés. Si vous avez plus d’une application, exportez-les dans des sous-dossiers du même site pour qu’elles partagent une seule copie des actifs web au lieu de les dupliquer :

shinylive::export("myapp1", "site", subdir = "app1")
shinylive::export("myapp2", "site", subdir = "app2")

Cela produit site/app1 et site/app2 sous un seul site statique — pratique pour un portfolio ou une série de démos.

Gérer les actifs en cache. Le package {shinylive} met en cache les actifs web qu’il télécharge ; vous y touchez rarement, mais les outils sont là quand une version devient obsolète :

Tâche	Fonction
Afficher la version du package, la version des actifs et le chemin du cache	`shinylive::assets_info()`
Télécharger une version d’actifs précise	`shinylive::assets_download("<version>")`
Supprimer tous les actifs en cache pour libérer de l’espace	`shinylive::assets_cleanup()`
Supprimer une version d’actifs précise	`shinylive::assets_remove("<version>")`

Problèmes fréquents

L’application fonctionne en local mais affiche une page blanche une fois déployée. Presque toujours un problème de chemin. Servez le site exporté via HTTP (n’ouvrez jamais index.html depuis le système de fichiers — les actifs WASM ne chargeront pas), et assurez-vous que les fichiers de données sont lus avec des chemins relatifs pour qu’ils se résolvent après export. Ouvrez la console développeur du navigateur pour voir quel fichier n’a pas pu se charger.

Un package n’est pas disponible et l’application ne démarre pas. shinylive ne peut empaqueter que les packages que webR fournit. Si votre application dépend d’un package qui n’a pas été compilé pour WebAssembly, l’export s’exécute mais l’application échoue au chargement. Vérifiez la disponibilité dans la documentation de webR, et remplacez-le par une alternative disponible ou déplacez cette application vers un vrai serveur.

L’export réussit mais le dossier semble incomplet. Confirmez que l’application elle-même tourne d’abord en local (shiny::runApp("myapp")), et revérifiez les deux arguments de export() — le premier est le dossier de votre application, le second est la destination. Une faute de frappe dans l’un ou l’autre chemin en est la cause habituelle.

Questions fréquentes

Ai-je besoin d’un serveur pour héberger une application Shiny avec shinylive ?

Non. C’est tout l’intérêt de shinylive — il exporte votre application vers des fichiers statiques qui tournent dans le navigateur du visiteur via WebAssembly, vous pouvez donc les héberger sur n’importe quel service statique (GitHub Pages, Netlify) sans aucun serveur R tournant derrière eux.

Comment convertir une application Shiny existante en shinylive ?

Placez votre app.R (et toutes les données qu’il lit) dans un dossier, puis exécutez shinylive::export("your-folder", "site"). Cela écrit un site statique dans site/. Prévisualisez-le avec httpuv::runStaticServer("site/") avant de déployer le dossier vers un hébergeur statique.

Quels packages R fonctionnent avec shinylive ?

Tout package qui a été compilé pour webR (R compilé en WebAssembly). La plupart des packages courants — shiny, ggplot2, dplyr et bien d’autres — sont disponibles, mais un package aux dépendances système lourdes peut ne pas l’être. Vérifiez la documentation de webR avant de compter sur un package inhabituel.

Shinylive ou shinyapps.io — lequel choisir ?

Utilisez shinylive quand vous voulez un hébergement statique gratuit et sans serveur et que le calcul de l’application est léger. Utilisez shinyapps.io (ou Posit Connect / ShinyProxy) quand l’application a besoin de secrets côté serveur, d’une base de données, d’un package qui n’est pas dans webR, ou d’un calcul lourd — tout ce qui exige un processus R actif sur le serveur.

Puis-je garder mes données ou mes clés d’API privées dans une application shinylive ?

Non. Tout ce qu’une application shinylive utilise est téléchargé vers le navigateur du visiteur, donc toute donnée ou clé empaquetée est lisible par le visiteur. Si des données doivent rester privées ou un secret rester caché, hébergez l’application sur un vrai serveur au lieu de l’exporter avec shinylive.

Testez vos connaissances

À vous de jouer : exportez et prévisualisez une application

Reprenez l’application histogramme faithful de cette leçon et faites-la tourner comme un site statique sur votre propre machine, de bout en bout. Écrivez les trois étapes de R que vous exécuteriez, en supposant que l’application est enregistrée dans un dossier nommé myapp.

Indice

Vous avez besoin d’un appel pour exporter l’application vers un dossier, et d’un autre pour servir ce dossier via HTTP pour une prévisualisation. La fonction d’export prend d’abord le dossier de l’application puis la destination ; la prévisualisation a besoin de httpuv.

Solution

# 1. (optional but wise) run the app locally first to confirm it works
shiny::runApp("myapp")

# 2. export the app directory to a static site
shinylive::export("myapp", "site")

# 3. serve the exported folder over HTTP and open the printed URL
httpuv::runStaticServer("site/")

Après l’étape 3, R tourne à l’intérieur de l’onglet de votre navigateur, pas dans votre session R — l’application dans site/ est totalement autonome et prête à être poussée vers GitHub Pages.

Vérification rapide

Pourquoi une application shinylive peut-elle tourner sur GitHub Pages, qui n’a aucun R installé ?

A. GitHub Pages exécute R en secret pour vous au chargement de la page. B. L’application a été exportée en fichiers statiques, et R tourne dans le navigateur du visiteur via WebAssembly — l’hôte ne fait que servir des fichiers. C. shinylive convertit le code R en JavaScript, donc aucun R n’est impliqué du tout. D. L’application ne fonctionne que si le visiteur a R installé en local.

Afficher la réponse

B. shinylive::export() produit du HTML/JS/CSS/WASM statique ; le navigateur du visiteur démarre webR (R compilé en WebAssembly) et exécute la logique de votre server côté client, donc l’hôte n’a jamais besoin de R. A est faux — GitHub Pages ne fait que servir des fichiers statiques. C est faux — votre code R tourne comme du R dans webR, il n’est pas transpilé en JavaScript. D est faux — rien n’est installé sur la machine du visiteur ; webR tourne à l’intérieur du navigateur.

Conclusion

Shinylive retourne le problème du déploiement : au lieu de mettre R sur un serveur, il met R dans le navigateur. Vous écrivez une application Shiny normale, exécutez un seul appel export(), prévisualisez le résultat et poussez un dossier de fichiers statiques vers n’importe quel hébergeur gratuit. Cela rend le partage d’une démo, d’une application d’enseignement ou d’un projet de portfolio presque gratuit — tant que le calcul de l’application est léger et qu’elle n’a besoin d’aucun secret ni base de données côté serveur.

Quand elle en a besoin, le modèle sans-serveur est le mauvais outil, et un serveur R hébergé est la réponse. Savoir de quel côté de cette ligne se trouve votre application, c’est la vraie compétence ; l’export lui-même tient en une seule commande.

Leçons connexes

Construisez d’abord l’application : votre première application Shiny vous donne le app.R à exporter, et qu’est-ce que Shiny ? explique où une application Shiny peut tourner — les serveurs hébergés et auto-gérés que shinylive remplace pour les applications légères. Vous configurez vos outils ? Installation et configuration de Shiny.
Allez plus loin : Déploiement de Shiny — la série complète. · Applications web Shiny — le cursus Shiny complet. · 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 Déploiement de 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 = {Exécuter une application Shiny dans le navigateur avec
    Shinylive (sans serveur)},
  date = {2026-07-14},
  url = {https://www.datanovia.com/learn/programming/shiny/deployment/shinylive},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Exécuter une application Shiny dans le navigateur avec Shinylive (sans serveur).” 2026. July 14. https://www.datanovia.com/learn/programming/shiny/deployment/shinylive.