Observabilité en production : faire parler ses apps R avant qu'elles ne tombent

À la une

Observabilité en production : faire parler ses apps R avant qu'elles ne tombent

Une app Shiny qui tombe en production, c'est souvent un mystère qu'on résout à coups de logs épars et de reproduction manuelle. Pendant que les équipes Python ou Java bénéficient depuis des années d'observabilité standardisée via OpenTelemetry (traces distribuées, métriques, logs structurés), R restait largement à l'écart de cet outillage. Ce silence s'explique : R est historiquement un langage d'analyse, pas de service long-running. Mais avec la multiplication des apps Shiny critiques, des API plumber et des pipelines qui tournent en continu sur Cloud Run ou Connect, ce manque devient un vrai problème opérationnel.

Posit change la donne en instrumentant huit packages largement utilisés : Shiny, plumber2, mirai, httr2, ellmer, knitr, testthat et DBI. Concrètement, cela veut dire que les appels HTTP sortants, les requêtes base de données, les rendus Quarto et les sessions Shiny peuvent désormais émettre des traces OpenTelemetry sans que vous ayez à instrumenter votre code à la main. Vous configurez un exporteur (OTLP vers Grafana, Datadog, Honeycomb, peu importe), vous activez le traçage via des variables d'environnement, et les traces remontent automatiquement avec la hiérarchie des appels.

L'intérêt pratique est immédiat pour du debugging de production : quand une app Shiny répond lentement, on peut enfin voir si le goulot est côté requête BigQuery, appel API externe via httr2, ou rendu serveur. Sans cet outillage, on ajoutait des `Sys.time()` un peu partout et on croisait les doigts. Avec httr2 1.3.0, le support OpenTelemetry s'ajoute à un gain de performance notable sur le streaming des réponses courtes, ce qui compte si votre app fait beaucoup d'appels API légers (LLM, géocodage, enrichissement).

Côté Shiny, la nouveauté `startApp()` complète ce tableau : elle permet de lancer une app sans bloquer la console R, un détail qui change la vie pour tester en local pendant qu'on instrumente ou qu'on débogue en parallèle. Combiné aux skills d'agents IA intégrés pour écrire du code Shiny, on voit se dessiner un workflow où l'app tourne, s'observe et se corrige dans la même session.

La limite principale : l'instrumentation reste à la discrétion des mainteneurs de packages, donc si votre stack utilise un package tiers non couvert, vous retombez sur du logging manuel. Il faut aussi un collecteur OpenTelemetry déployé quelque part (Grafana Alloy, Jaeger, ou un service managé), ce qui est un coût d'infrastructure supplémentaire, pas juste un `install.packages()`. Pour une petite app interne avec peu de trafic, c'est probablement disproportionné ; pour une app critique avec des SLA, ça devient indispensable.

CODE R

Sys.setenv(OTEL_EXPORTER_OTLP_ENDPOINT = "http://localhost:4318")
Sys.setenv(OTEL_SERVICE_NAME = "mon-app-shiny")

library(shiny)

ui <- fluidPage(
  actionButton("go", "Lancer le calcul"),
  verbatimTextOutput("resultat")
)

server <- function(input, output, session) {
  output$resultat <- renderPrint({
    input$go
    req(input$go > 0)
    Sys.sleep(1)
    "Calcul termine"
  })
}

app <- shinyApp(ui, server)
startApp(app, port = 3838)
cat("App lancee, console disponible pour inspection\n")

Les variables d'environnement OTEL activent l'export des traces vers un collecteur local, et startApp() permet de garder la main sur la console pendant que l'app tourne en arrière-plan.

Notre avis

C'est le signe le plus clair que R est pris au sérieux comme langage de production, pas seulement d'analyse. L'effort de Posit sur huit packages cœur vaut mieux qu'un package tiers isolé, car l'instrumentation est cohérente d'un bout à la chaîne à l'autre. Reste à voir l'adoption réelle côté IT : sans collecteur en place, la fonctionnalité dort.

→ Pour qui : Data engineers et développeurs Shiny qui opèrent des apps ou API R en production avec des exigences de fiabilité.

LES BRÈVES

IA GEN

Gouverner les agents IA codants en entreprise

Posit publie un guide destiné aux DSI sur la gouvernance des assistants et agents IA qui écrivent du code R ou Python en production. Le sujet dépasse la technique : qui valide le code généré, comment tracer les décisions d'un agent, quelles données il peut voir. Un passage obligé pour toute organisation qui laisse Copilot ou un agent similaire toucher à du code de production.

Source : posit.co ↗

APPS

Posit consolide sa publication cloud

shinyapps.io, RPubs, Quarto Pub et bookdown.org migrent vers Posit Connect Cloud, avec un outil dédié pour lier son compte existant et tester avant bascule. Pour les équipes qui dépendent de shinyapps.io pour du déploiement rapide, mieux vaut anticiper cette migration plutôt que la subir en urgence.

Source : posit.co ↗

OUTILS

processx muscle la gestion des processus système

La version 3.9.0 de processx apporte des pipelines au niveau noyau et la gestion des signaux de mort du parent sous Linux, utile pour tout pipeline R qui orchestre des sous-processus (rendu Quarto parallèle, appels à des binaires externes). Moins visible que Shiny ou httr2, mais processx est la brique sous-jacente de callr, pak et de nombreux outils de build.

Source : tidyverse.org ↗

LE TIP R DU JOUR

Capturer un avertissement sans arrêter le script

withCallingHandlers permet d'intercepter un warning, de le logger, puis de laisser le code continuer son exécution normale, contrairement à tryCatch qui interrompt le bloc.

CODE R

resultat <- withCallingHandlers(
  {
    log(-1)
  },
  warning = function(w) {
    message("Warning capture : ", conditionMessage(w))
    invokeRestart("muffleWarning")
  }
)
print(resultat)

SOURCES

VOUS CODEZ EN R ?

Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.

Parlons-en →

← Tout R Underground