golem, Rhino : la production Shiny se standardise
Pendant longtemps, construire une app Shiny pour la production a été affaire d'artisanat : chaque équipe réinventait sa structure de projet, son déploiement Docker, sa gestion des dépendances. golem et Rhino existaient déjà pour cadrer ça, mais ils restaient perçus comme des frameworks en construction, avec des API qui bougeaient. Ce temps est en train de se refermer, et c'est un signal fort pour toute organisation qui exploite plusieurs apps Shiny en interne.
golem atteint une version jugée stable par ses mainteneurs, avec une API qui ne devrait plus bouger sous les pieds des équipes. Concrètement, cela veut dire qu'un projet golem démarré aujourd'hui a une espérance de vie en production bien plus longue sans dette de migration. Le framework unifie aussi sa gestion des chemins de travail et revoit son articulation Dockerfile/renv, deux points qui, mal gérés, sont la source numéro un des incidents de déploiement en entreprise.
Rhino suit une logique complémentaire, plus orientée qualité logicielle : couverture de code intégrée, conventions strictes, structure imposée. Les deux frameworks ajoutent par ailleurs un support natif pour les agents de codage IA, via des fichiers de type AGENTS.md ou des skills dédiés. L'idée : qu'un agent IA appelé pour générer ou modifier du code Shiny respecte d'emblée les conventions du projet, plutôt que de produire du code générique à corriger ensuite.
Ces évolutions tombent au même moment où shiny lui-même renforce ses fondations pour la production : un mode non bloquant pour lancer une app, un vrai nettoyage mémoire des modules dynamiques, des en-têtes HTTP plus sûrs par défaut. Pris ensemble, ces changements dessinent une pile technique où l'app Shiny n'est plus un script qui tourne par chance, mais un logiciel testé, structuré et observable.
La limite reste le choix initial : golem et Rhino imposent une discipline, une courbe d'apprentissage, et ne conviennent pas à un prototype jetable. Migrer une app existante vers l'un de ces frameworks a un coût réel qui ne se justifie que si l'app a vocation à vivre plusieurs années et plusieurs développeurs.
if (!requireNamespace("golem", quietly = TRUE)) install.packages("golem")
golem::create_golem(
path = "mon_app_prod",
package_name = "monapp"
)
setwd("mon_app_prod")
# Structure standard : dev/, R/, inst/app/www
# golem_wd unifie désormais tous les chemins de travail
cfg <- golem::get_current_config()
print(cfg)
# Ajout d'un skill agent IA (ex. Claude Code) au projet
# golem::use_claude_skills()Création d'un squelette de projet golem avec sa configuration standardisée, point de départ recommandé pour une app Shiny d'entreprise.
Golem et Rhino ne sont plus des paris : ce sont des choix par défaut raisonnables pour toute app Shiny destinée à durer plus de six mois. Le vrai changement de fond, c'est que la question se déplace de « faut-il un framework ? » vers « lequel, et avec quelle gouvernance d'équipe ? ».
→ Pour qui : Développeurs Shiny et tech leads qui doivent faire vivre des apps en production sur plusieurs années.
LES BRÈVES
duckdb fait le ménage sur les erreurs et les instances
La nouvelle version de duckdb rend les erreurs de connexion plus explicites : un paramètre incompatible avec une instance déjà ouverte fait désormais échouer la connexion au lieu de l'ignorer silencieusement. Un mode streaming expérimental vers Arrow évite aussi de matérialiser tout un résultat de requête en mémoire.
Source : cran.r-project.org ↗bslib ajoute des panneaux coulissants pour les interfaces denses
Le composant offcanvas() permet d'ajouter des panneaux latéraux qui se révèlent à la demande, pilotables depuis le serveur avec show_offcanvas() et toggle_offcanvas(). Utile pour les apps Shiny qui manquent de place à l'écran : filtres avancés, aide contextuelle, détails d'un enregistrement.
Source : cran.r-project.org ↗rmarkdown corrige un vieux problème de génération PDF en production
Les fichiers auxiliaires LaTeX sont désormais écrits dans le répertoire de sortie plutôt que dans celui d'entrée, ce qui évite un échec classique quand le dossier source est en lecture seule, un cas fréquent dans les déploiements Shiny ou les pipelines CI/CD.
Source : cran.r-project.org ↗data.table permet enfin de supprimer des lignes par référence
La syntaxe DT[i, .ROW := NULL] supprime des lignes sans copier toute la table, une fonctionnalité réclamée depuis des années pour les suppressions massives sur de gros volumes. Elle ne fonctionne pas avec by/keyby et efface les clés existantes.
Source : cran.r-project.org ↗LE TIP R DU JOUR
Comparer deux objets sans se fier à ==
Pour comparer deux vecteurs ou objets en tenant compte de la tolérance numérique des flottants, all.equal() est plus fiable que ==. Pensez à envelopper le résultat dans isTRUE() car all.equal() peut renvoyer une chaîne de caractères décrivant la différence au lieu d'un booléen.
a <- 0.1 + 0.2 b <- 0.3 a == b isTRUE(all.equal(a, b))
SOURCES
- https://cran.r-project.org/package=duckdb
- https://cran.r-project.org/package=rmarkdown
- https://cran.r-project.org/package=data.table
- https://cran.r-project.org/package=bslib
- https://www.r-bloggers.com/2026/07/golem-1-0-0-is-here/
- https://thinkr-open.github.io/golem/news/index.html
- https://cran.r-project.org/package=golem
- https://cran.r-project.org/package=shiny
- https://www.appsilon.com/rhinoverse/rhino
VOUS CODEZ EN R ?
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.