Intégrer et incorporer des applications Shiny dans Quarto, R Markdown et des sites web

Q: Comment incorporer une application Shiny dans un document Quarto ?

Deux façons. Pour une application vivante, ajoutez server: shiny au YAML du document et placez la logique réactive dans un bloc #| context: server — le document devient une application Shiny qui tourne sur un serveur Shiny. Pour une incorporation sans serveur, ajoutez l’extension shinylive (quarto add quarto-ext/shinylive) et écrivez l’application dans un bloc {shinylive-r}, qui tourne dans le navigateur sans serveur. Choisissez server: shiny quand l’application a besoin d’un back-end, l’extension quand ce n’est pas le cas.

Q: Comment rendre un document R Markdown interactif avec Shiny ?

Ajoutez runtime: shiny à l’en-tête YAML du document et utilisez un format de sortie HTML (comme html_document). Vous pouvez alors placer des entrées Shiny (sliderInput(), selectInput(), …) et des fonctions de rendu (renderPlot(), renderTable(), …) directement dans des blocs de code. Le bouton « Knit » devient Run Document, et le rapport tourne comme une application vivante sur un serveur Shiny.

Placez une application vivante dans une autre page — les choix de runtime, les routes de la page hôte, et l’iframe qui fonctionne partout.

Programming

Shiny

Incorporez une application Shiny dans une page hôte. Cette leçon sépare les deux questions qui décident du comment — où l’application tourne (un serveur R vivant ou shinylive sans serveur) et comment elle apparaît dans la page (Quarto natif server:shiny, R Markdown runtime:shiny, l’extension Quarto shinylive, ou une iframe universelle) — plus la carte des hébergements et quand incorporer une application vivante plutôt qu’un export sans serveur.

Date de publication

14 juillet 2026

Modifié

14 juillet 2026

Points clés

Deux questions distinctes. Où l’application tourne (un serveur R vivant, ou sans serveur dans le navigateur) et comment elle apparaît dans la page hôte (nativement, ou à travers une iframe) sont des décisions indépendantes — tranchez chacune de son côté.
Une application vivante a besoin d’un processus R actif sur un serveur : shinyapps.io, Posit Connect, Shiny Server, ou ShinyProxy. L’alternative sans serveur, c’est shinylive, qui exécute l’application dans le navigateur du visiteur sans aucun serveur.
Dans Quarto : ajoutez server: shiny et un bloc context: server pour faire du document lui-même une application interactive, ou déposez l’extension Quarto shinylive pour une incorporation sans serveur.
Dans R Markdown : ajoutez runtime: shiny au YAML et le rapport devient une application vivante.
Partout ailleurs — un blog, un LMS, des diapositives — utilisez une <iframe> pointant vers l’URL de votre application hébergée. C’est la route universelle et elle ne demande aucun support particulier de la page hôte.

Introduction

Vous avez une application Shiny fonctionnelle (votre première application en est le point de départ) et vous voulez maintenant qu’elle vive à l’intérieur d’autre chose — un tutoriel Quarto, un rapport R Markdown, un article de blog, une page de cours. « Incorporer une application Shiny » a tout l’air d’une seule tâche, mais ce sont en réalité deux questions que l’on a tendance à mélanger :

Où l’application tourne-t-elle ? Une application Shiny normale a besoin d’un processus R vivant — une copie de R en cours d’exécution qui répond au navigateur quand l’utilisateur clique. Ce processus vit sur un serveur. Le seul moyen de l’éviter, c’est shinylive, qui compile l’application pour qu’elle tourne dans le navigateur lui-même sans serveur.
Comment l’application apparaît-elle dans la page hôte ? Certains hôtes (Quarto, R Markdown) savent tisser une application Shiny nativement ; tous les autres hôtes la font passer par une iframe — une petite fenêtre dans la page qui charge l’application depuis sa propre URL.

Cette leçon parcourt les deux. Nous cartographions les endroits où une application vivante peut tourner, puis nous montrons les trois routes natives (Quarto server: shiny, R Markdown runtime: shiny, l’extension Quarto shinylive) et l’iframe universelle, et nous concluons par une règle claire pour décider quand incorporer une application vivante, adossée à un serveur plutôt qu’un export shinylive sans serveur. Si votre application est légère et n’a besoin d’aucun back-end, la voie sans serveur est de loin la plus simple — tout ce workflow (exporter, prévisualiser, héberger) est détaillé dans la leçon shinylive ; ici nous nous concentrons sur la décision d’intégration.

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

Le code et la configuration de cette page ne sont pas exécutés ici — une application Shiny a besoin d’une session R active, elle ne peut donc pas tourner dans une page web statique. Copiez n’importe quel bloc dans R, dans un fichier app.R ou dans le YAML d’un document, et exécutez-le en local pour reproduire le comportement décrit. Chaque exemple est autonome et n’utilise que le jeu de données intégré faithful de R, il tourne donc tel quel. Le vrai test, c’est d’ouvrir l’application incorporée dans un navigateur et de la regarder réagir — the runtime is the judge.

Runtime et incorporation : le modèle mental

Gardez les deux questions séparées et tout problème « comment incorporer Shiny ? » devient plus simple.

Le runtime, c’est où R tourne. Soit un processus R vivant sur un serveur, soit — avec shinylive — aucun serveur, parce que l’application est compilée en WebAssembly (un format binaire portable que les navigateurs exécutent à une vitesse proche du natif) et tourne dans l’onglet du visiteur.
L’incorporation, c’est comment l’application apparaît dans la page hôte. Les routes natives (Quarto, R Markdown) rendent l’application comme une partie du document ; la route iframe dépose l’application dans n’importe quelle page sous forme de fenêtre autonome.

Les deux sont presque indépendants. Une application vivante peut être incorporée nativement (un document Quarto server: shiny) ou par iframe (une URL shinyapps.io dans un article de blog). Une application shinylive sans serveur peut être incorporée nativement (l’extension Quarto) ou par iframe (un site exporté chargé dans un <iframe>). Décidez du runtime d’après ce dont l’application a besoin (des secrets ? une base de données ? un calcul lourd ?), puis choisissez la route d’incorporation d’après où elle doit apparaître.

Où une application vivante peut tourner

Si votre application a besoin d’un vrai processus R — une connexion à une base de données, une clé d’API privée, un package qui n’est pas dans webR (R compilé en WebAssembly, qui tourne dans le navigateur), ou un calcul lourd — elle doit tourner sur un serveur. Voici les hébergements standard d’une application Shiny hébergée (voir l’aperçu du déploiement Shiny de Posit) :

Où elle tourne	Ce que c’est	Idéal pour
shinyapps.io	Le cloud hébergé de Posit — vous déployez avec `rsconnect::deployApp()` et obtenez une URL publique	Le moyen le plus rapide d’obtenir un lien partageable ; une offre gratuite couvre les petites applications
Shiny Server (open source)	Un logiciel que vous installez sur votre propre serveur Linux	L’auto-hébergement sur une infrastructure que vous contrôlez
Posit Connect	Plateforme de publication commerciale	Les équipes : authentification, planification et de nombreux types de produits au même endroit
ShinyProxy (open source)	Déploiement à base de conteneurs, un conteneur par utilisateur	L’auto-hébergement en entreprise avec isolation et montée en charge
shinylive (sans serveur)	Application compilée en WebAssembly, tournant dans le navigateur — aucun serveur	Les applications légères que vous voulez sur un hébergement statique gratuit

Les quatre premiers vous donnent une URL vers une application en cours d’exécution ; vous incorporez ensuite cette URL (généralement avec une iframe). Le dernier, shinylive, vous donne plutôt des fichiers statiques — traité en détail dans la leçon shinylive. Le reste de cette page montre comment faire apparaître l’un ou l’autre type dans une page hôte.

Incorporer dans un document Quarto

Quarto propose deux façons distinctes de porter une application Shiny, et elles correspondent exactement aux deux runtimes.

Natif : `server: shiny` (une application vivante)

Ajoutez server: shiny au YAML du document et Quarto transforme le document entier en une application Shiny vivante. Les entrées interactives vont dans des blocs ordinaires ; la logique réactive va dans un bloc marqué #| context: server, qui tourne sur le serveur R plutôt qu’au moment du rendu. C’est l’approche officielle documentée dans la documentation Shiny de Quarto :

---
title: "Old Faithful eruptions"
server: shiny
---

```{r}
sliderInput("bins", "Number of bins:", min = 1, max = 50, value = 30)
plotOutput("distPlot")
```

```{r}
#| context: server
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 = "")
})
```

Le schéma est le même découpage ui/server que vous connaissez déjà d’après la structure d’une application : le premier bloc est l’UI (les entrées et les emplacements de sortie), le bloc context: server est la logique serveur qui lit input$bins et remplit output$distPlot. Parce que ce document est une application vivante, il ne peut pas être servi comme un fichier HTML statique — il doit tourner sur un serveur compatible Shiny (shinyapps.io, Posit Connect, ou votre propre Shiny Server). C’est le compromis pour tisser l’application nativement dans la page.

Sans serveur : l’extension Quarto shinylive

Si l’application est assez légère pour tourner dans le navigateur, vous pouvez l’incorporer avec aucun serveur grâce à l’extension Quarto shinylive. Ajoutez-la à votre projet une seule fois :

quarto add quarto-ext/shinylive

Activez ensuite le filtre dans le YAML du document et écrivez l’application dans un bloc shinylive-r, que Quarto rend comme une application interactive et sans serveur directement dans la page :

---
title: "Old Faithful eruptions"
filters:
  - shinylive
---

```{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)
```

Cela garde la page statique — elle peut être hébergée sur GitHub Pages sans aucun serveur R derrière elle — parce que l’application tourne dans le navigateur du visiteur. Le workflow sans-serveur complet (installer {shinylive}, exporter un site entier, prévisualiser, héberger, empaqueter des données) fait l’objet de la leçon shinylive ; utilisez server: shiny ci-dessus quand l’application a besoin d’un vrai back-end, et l’extension ici quand elle n’en a pas besoin.

Note

Les pages de cette plateforme sont statiques et ne chargent pas l’extension shinylive, le bloc ci-dessus est donc montré à titre d’exemple, il n’est pas exécuté ici. Ajoutez l’extension à votre projet pour la voir se rendre en direct.

Incorporer dans un document R Markdown

R Markdown reprend la même idée que le server: shiny de Quarto, avec un seul mot-clé : ajoutez runtime: shiny au YAML et le rapport cesse d’être un knit statique pour se mettre à tourner comme une application vivante. Vous écrivez ensuite les entrées Shiny et les fonctions de rendu directement dans des blocs ordinaires — le guide des documents interactifs de Posit est la référence principale :

---
title: "Old Faithful eruptions"
output: html_document
runtime: shiny
---

```{r}
sliderInput("bins", "Number of bins:", min = 1, max = 50, value = 30)
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 = "")
})
```

Avec runtime: shiny, le bouton « Knit » devient Run Document, et — comme un document Quarto server: shiny — la sortie doit être un format HTML servi par un serveur Shiny ; les sorties PDF et Word ne peuvent pas héberger une application vivante. C’est la voie pour un rapport .Rmd existant que vous voulez rendre interactif sans le réécrire comme un app.R autonome.

Incorporer une application hébergée n’importe où avec une iframe

Les routes natives ci-dessus ne fonctionnent que dans Quarto et R Markdown. Pour mettre une application Shiny dans n’importe quelle page — un blog WordPress, un site statique, un système de gestion de l’apprentissage, une diapositive reveal.js — utilisez une <iframe> : une fenêtre qui charge l’application en cours d’exécution depuis sa propre URL. Déployez d’abord l’application sur un serveur (shinyapps.io est le plus rapide), puis incorporez son URL :

<iframe
  src="https://youraccount.shinyapps.io/old-faithful/"
  width="100%"
  height="600"
  loading="lazy"
  title="Old Faithful eruptions Shiny app"
  style="border: 1px solid #ddd; border-radius: 8px;">
</iframe>

Quelques notes pratiques :

Rendez-la responsive. width="100%" laisse le cadre remplir sa colonne ; définissez une height explicite (les applications Shiny n’ajustent pas automatiquement un cadre à leur contenu, choisissez donc une hauteur qui convient à la mise en page de l’application).
Définissez toujours un title. Un title descriptif sur l’iframe est requis pour l’accessibilité — les lecteurs d’écran l’annoncent comme l’étiquette du cadre.
loading="lazy" diffère le chargement de l’application jusqu’à ce que le cadre entre dans le champ de vision, ce qui garde la page hôte rapide si l’application est loin en bas.
L’application doit autoriser l’affichage en cadre. Une application servie avec un en-tête X-Frame-Options ou Content-Security-Policy restrictif refusera de se charger dans une iframe ; shinyapps.io autorise l’affichage en cadre par défaut, mais une application auto-hébergée derrière un proxy peut nécessiter un ajustement de ses en-têtes.

La même iframe fonctionne pour un export shinylive sans serveur : hébergez le dossier site/ exporté (par ex. sur GitHub Pages) et pointez le src de l’iframe vers son URL. Dans les deux cas, la page hôte n’a besoin que de connaître l’adresse de l’application.

Application vivante ou export sans serveur — laquelle incorporer

Une application vivante adossée à un serveur comme un export shinylive sans serveur peuvent tous deux être incorporés par iframe ou, dans Quarto, nativement. Ce qui tranche entre les deux, c’est ce dont l’application a besoin à l’exécution — pas où elle apparaîtra :

Incorporez une application vivante (vrai serveur R) quand…	Incorporez une application shinylive sans serveur quand…
Elle a besoin de secrets côté serveur, d’une base de données ou d’une clé d’API privée	Elle est légère et n’a besoin d’aucun secret côté back-end
Elle utilise un package qui n’est pas disponible dans webR	Chaque package qu’elle utilise est disponible dans webR
Le calcul est lourd, long ou gourmand en mémoire	Le calcul est léger et tourne bien dans un navigateur
Vous l’hébergez déjà sur shinyapps.io / Connect	Vous voulez un hébergement statique gratuit sans serveur à maintenir

En bref : sans serveur quand vous le pouvez, vivant quand vous le devez. Une démo pédagogique ou une pièce de portfolio est presque toujours mieux servie sans serveur (pas de compte, pas de facture, pas de serveur à maintenir en vie) ; une application qui touche à des données privées ou à une vraie base de données doit rester sur un serveur. Quand c’est le cas, déployez-la et incorporez l’URL avec une iframe.

Problèmes fréquents

L’iframe est vide ou affiche une erreur « refused to connect ». L’application refuse d’être affichée en cadre. Vérifiez les en-têtes de réponse de l’application — un X-Frame-Options: DENY/SAMEORIGIN ou un Content-Security-Policy frame-ancestors restrictif bloquera l’incorporation. shinyapps.io autorise l’affichage en cadre par défaut ; une application auto-hébergée ou derrière un reverse proxy peut nécessiter un assouplissement de ces en-têtes pour le domaine hôte. Confirmez aussi d’abord que l’URL src ouvre bien l’application directement dans son propre onglet.

L’application incorporée est tronquée ou défile bizarrement. Une iframe ne se redimensionne pas selon son contenu. Donnez à l’<iframe> une height explicite qui correspond à la mise en page de l’application (et width="100%" pour qu’elle remplisse la colonne). Pour un document Quarto server: shiny, définissez les dimensions de l’emplacement de sortie dans l’application elle-même plutôt que d’attendre que la page s’étire.

server: shiny (ou runtime: shiny) rend une page statique aux contrôles inertes. Le document a été rendu comme un simple fichier HTML au lieu d’être exécuté. Ces formats produisent une application vivante, pas un export statique — servez le document depuis un hôte compatible Shiny (shinyapps.io, Posit Connect, ou Shiny Server), ou exécutez-le en local avec Run Document / rmarkdown::run(). Si vous avez besoin d’une page vraiment statique avec des contrôles fonctionnels, utilisez plutôt la route sans serveur shinylive.

Questions fréquentes

Comment incorporer une application Shiny dans un document Quarto ?

Deux façons. Pour une application vivante, ajoutez server: shiny au YAML du document et placez la logique réactive dans un bloc #| context: server — le document devient une application Shiny qui tourne sur un serveur Shiny. Pour une incorporation sans serveur, ajoutez l’extension shinylive (quarto add quarto-ext/shinylive) et écrivez l’application dans un bloc {shinylive-r}, qui tourne dans le navigateur sans serveur. Choisissez server: shiny quand l’application a besoin d’un back-end, l’extension quand ce n’est pas le cas.

Comment incorporer une application Shiny dans un site web ou un blog ?

Déployez l’application sur un serveur (shinyapps.io est le plus rapide), puis ajoutez une <iframe> dont le src est l’URL de l’application : <iframe src="https://youraccount.shinyapps.io/app/" width="100%" height="600" title="My app"></iframe>. L’iframe fonctionne dans n’importe quelle page HTML — WordPress, un site statique, un LMS, ou des diapositives — parce qu’elle ne fait que charger l’application en cours d’exécution depuis sa propre adresse.

Comment rendre un document R Markdown interactif avec Shiny ?

Ajoutez runtime: shiny à l’en-tête YAML du document et utilisez un format de sortie HTML (comme html_document). Vous pouvez alors placer des entrées Shiny (sliderInput(), selectInput(), …) et des fonctions de rendu (renderPlot(), renderTable(), …) directement dans des blocs de code. Le bouton « Knit » devient Run Document, et le rapport tourne comme une application vivante sur un serveur Shiny.

Où puis-je héberger une application Shiny pour pouvoir l’incorporer ?

Une application vivante a besoin d’un serveur qui exécute R : shinyapps.io (le cloud hébergé de Posit), Posit Connect (commercial), Shiny Server (open source, auto-hébergé), ou ShinyProxy (à base de conteneurs). Si l’application est légère et n’a besoin d’aucun back-end, vous pouvez vous passer complètement du serveur avec shinylive et héberger des fichiers statiques n’importe où.

Dois-je incorporer une application Shiny vivante ou une application shinylive sans serveur ?

Décidez d’après ce dont l’application a besoin. Incorporez une application vivante quand elle utilise des secrets côté serveur, une base de données, un package qui n’est pas dans webR, ou un calcul lourd. Incorporez une application shinylive sans serveur quand elle est légère, sans back-end, et que vous voulez un hébergement statique gratuit sans rien à maintenir. Les deux peuvent être déposées dans une page par iframe (ou nativement dans Quarto) — le runtime est la seule vraie différence.

Testez vos connaissances

À vous de jouer : incorporez une application hébergée dans une page web

Vous avez déployé l’application Old Faithful sur https://youraccount.shinyapps.io/old-faithful/. Écrivez le HTML qui l’incorpore dans un article de blog pour qu’elle remplisse la colonne de contenu, ait une hauteur confortable et soit accessible.

Indice

Utilisez une <iframe> avec l’URL de l’application comme src. Définissez width="100%" pour remplir la colonne, une height explicite, et un title pour l’accessibilité. loading="lazy" est un petit plus appréciable.

Solution

<iframe
  src="https://youraccount.shinyapps.io/old-faithful/"
  width="100%"
  height="600"
  loading="lazy"
  title="Old Faithful eruptions Shiny app"
  style="border: 1px solid #ddd; border-radius: 8px;">
</iframe>

width="100%" fait remplir la colonne par le cadre ; le height="600" explicite donne de la place à l’application (une iframe ne s’ajuste jamais automatiquement à son contenu) ; title étiquette le cadre pour les lecteurs d’écran ; loading="lazy" diffère le chargement jusqu’à ce qu’elle entre dans le champ de vision. Si l’application affiche « refused to connect », vérifiez que son serveur autorise l’affichage en cadre.

Vérification rapide

Vous ajoutez server: shiny à un document Quarto, le rendez en simple fichier HTML, et ouvrez ce fichier — le curseur ne fait rien. Pourquoi ?

A. Le bloc context: server contient une faute de frappe, donc la logique serveur ne tourne jamais. B. server: shiny produit une application vivante qui doit tourner sur un serveur Shiny ; un rendu HTML statique n’a aucun processus R pour répondre aux contrôles. C. Quarto ne prend pas en charge Shiny — vous devez utiliser R Markdown pour cela. D. Le navigateur a bloqué l’iframe.

Afficher la réponse

B. Un document server: shiny est une application Shiny : il a besoin d’un processus R vivant pour réagir aux entrées. Le rendre en fichier statique supprime ce processus, donc les contrôles sont inertes — vous devez exécuter le document (en local, ou sur shinyapps.io / Posit Connect / Shiny Server). A est possible en général mais ce n’est pas ce que provoque un rendu statique. C est faux — Quarto prend en charge Shiny via server: shiny. D est faux — il n’y a pas d’iframe ici ; le document a été rendu statiquement. Pour une page qui reste statique et garde des contrôles fonctionnels, utilisez le shinylive sans serveur.

Conclusion

Incorporer une application Shiny se résume à deux choix indépendants. D’abord le runtime : une application vivante a besoin d’un vrai serveur R (shinyapps.io, Posit Connect, Shiny Server, ShinyProxy), tandis qu’une application légère peut passer sans serveur avec shinylive et tourner dans le navigateur. Ensuite la route d’incorporation : Quarto et R Markdown peuvent tisser une application vivante nativement (server: shiny, runtime: shiny), l’extension shinylive incorpore une application sans serveur dans une page Quarto, et une <iframe> dépose n’importe quelle application hébergée dans n’importe quelle page.

Réglez le runtime d’après ce dont l’application a besoin, choisissez la route d’incorporation d’après où elle doit apparaître, et la question autrefois floue « comment incorporer Shiny ? » se résout en quelques étapes claires. Quand l’application est légère et sans back-end, tournez-vous d’abord vers la voie sans serveur — la leçon shinylive contient tout le workflow d’export et d’hébergement.

Leçons connexes

Construisez d’abord l’application : votre première application Shiny vous donne le app.R à incorporer, et la structure d’une application explique le découpage ui/server que reflète le bloc context: server. Vous reliez les entrées aux sorties ? les contrôles d’entrée et les affichages de sortie · les valeurs réactives.
Passez au sans serveur : Exécuter une application Shiny dans le navigateur avec shinylive — exportez une application entière vers des fichiers statiques qui n’ont besoin d’aucun serveur, le complément des routes d’incorporation de cette leçon.
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 = {Intégrer et incorporer des applications Shiny dans Quarto, R
    Markdown et des sites web},
  date = {2026-07-14},
  url = {https://www.datanovia.com/learn/programming/shiny/deployment/shiny-integration},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Intégrer et incorporer des applications Shiny dans Quarto, R Markdown et des sites web.” 2026. July 14. https://www.datanovia.com/learn/programming/shiny/deployment/shiny-integration.