shinyreact connecte une interface React à un serveur Shiny : voici ce que ça change pour vos apps en production et quand y aller.

Les équipes Shiny matures finissent presque toutes par se heurter au même mur : le rendu HTML/JS généré côté serveur est pratique pour prototyper, mais devient limitant dès qu'on veut une interface riche, réactive au pixel près, avec des interactions purement côté client (tri, filtrage, drag and drop) sans round-trip serveur. Jusqu'ici, la réponse passait par du JavaScript custom via shiny::registerInputHandler, des htmlwidgets maison, ou carrément une bascule complète vers un frontend React consommant une API Plumber. Dans les deux cas, on perd soit en richesse d'interface, soit en simplicité de maintenance pour une équipe R.
shinyreact, publié par Posit, propose un entre-deux concret : le serveur Shiny reste le cœur de calcul, avec toute la réactivité R habituelle, mais c'est React qui gère l'intégralité du rendu. Le contrat entre les deux est du JSON : le serveur publie des valeurs via un mécanisme de sortie réactive, et des hooks React côté client s'abonnent à ces valeurs, gèrent les entrées utilisateur et peuvent même échanger des messages personnalisés avec le serveur. Concrètement, un tri de tableau ou un filtrage d'affichage peut se faire entièrement côté client, sans solliciter le serveur R, tout en gardant les calculs lourds (modèle, agrégation, requête base de données) côté R où ils ont leur place.
Pour une équipe DATAISTUDIO qui livre des apps Shiny en production chez ses clients, l'intérêt est double. D'abord, ça évite le choix binaire entre rester 100% Shiny et basculer sur une stack React/Plumber qui multiplie les compétences nécessaires. Ensuite, le contrat JSON entre client et serveur est suffisamment explicite pour qu'un agent IA génère le code React à partir d'une spécification, ce qui réduit le coût d'entrée pour des équipes R qui ne maîtrisent pas React en profondeur.
La contrepartie est claire : on introduit une dépendance à un écosystème frontend (build React, gestion des hooks, outillage JS) qui n'existait pas dans une app Shiny classique. Ça suppose soit une compétence front dans l'équipe, soit l'acceptation de générer et maintenir ce code via des outils IA sans jamais vraiment le relire en profondeur. Le package est jeune, disponible depuis fin septembre sur CRAN et PyPI avec seulement deux hooks documentés : c'est un socle, pas encore un framework complet avec composants prêts à l'emploi.
Le bon usage aujourd'hui n'est pas de réécrire une app Shiny existante en React par principe, mais de le réserver aux écrans où la logique de rendu client (tri, filtres combinés, animations, édition inline) pèse davantage que les calculs serveur. Pour une app de reporting classique avec des inputs simples et des graphiques, Shiny seul reste plus rapide à livrer et plus facile à maintenir pour une équipe R pure.
library(shiny)
ui <- fluidPage(
titlePanel("Exemple conceptuel de sortie reactive"),
numericInput("n", "Nombre de points", 50, min = 10, max = 500),
tableOutput("resume")
)
server <- function(input, output, session) {
donnees <- reactive({
n <- input$n
data.frame(
x = seq_len(n),
valeur = round(rnorm(n, mean = 100, sd = 15), 1)
)
})
output$resume <- renderTable({
df <- donnees()
data.frame(
indicateur = c("n", "moyenne", "ecart_type"),
valeur = c(nrow(df), round(mean(df$valeur), 2), round(sd(df$valeur), 2))
)
})
}
shinyApp(ui, server)Cet exemple classique illustre ce que shinyreact conserve côté serveur : la logique réactive de calcul reste du R pur, seule la couche de rendu change de paradigme avec un frontend React.
shinyreact comble un vrai manque pour les interfaces exigeantes, mais c'est un outil de spécialiste à réserver aux écrans qui le justifient, pas un remplacement de Shiny classique.
→ Pour qui : Développeurs Shiny confrontés à des besoins d'interface riche ou à des interactions client lourdes, et équipes qui expérimentent la génération de code front par IA.
shinyapps.io, RPubs, BookDown.org et QuartoPub convergent vers Posit Connect Cloud, avec un outil de migration self-service disponible et les tarifs actuels garantis jusqu'en 2029. Pour les équipes qui hébergent déjà des apps sur shinyapps.io, c'est le moment de planifier la bascule plutôt que de la subir en urgence.
Source : opensource.posit.co ↗Le CLI de déploiement ajoute Posit Connect Cloud comme cible et une commande dédiée à la migration depuis shinyapps.io. Utile pour automatiser la bascule dans un pipeline CI/CD plutôt que de la faire manuellement app par app.
Source : docs.posit.co ↗renv corrige plusieurs cas où des restaurations simultanées partageant un même cache de packages pouvaient échouer ou installer un paquet corrompu. Un gain concret pour les CI qui lancent plusieurs builds en parallèle sur le même runner ou volume monté.
Source : cran.r-project.org ↗L'organisation marque l'anniversaire avec deux nouveaux packages accueillis dans son incubateur et vingt-deux mises à jour revues par les pairs. Un rappel que la review par les pairs reste une garantie de qualité rare dans l'écosystème R, à privilégier quand on choisit une dépendance pour du code de production.
Source : r-bloggers.com ↗Plutôt que de coller des slashs à la main pour construire un chemin, file.path() gère automatiquement le séparateur selon l'OS et évite les doubles slashs ou les oublis. C'est indispensable pour du code portable entre Windows, macOS et un serveur Linux.
dossier <- "donnees" sous_dossier <- "2026" fichier <- "export.csv" chemin <- file.path(dossier, sous_dossier, fichier) print(chemin)
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus