Chatbots en production dans Shiny : ellmer et shinychat changent la donne

À la une

Construire un assistant conversationnel dans une app Shiny : ce qui est réellement possible aujourd'hui

Jusqu'à récemment, brancher un LLM dans une app Shiny relevait du bricolage : appels httr2 manuels, gestion artisanale du streaming, UI de chat reconstruite à la main. La consolidation d'ellmer et de shinychat change la donne : on dispose maintenant d'une couche d'abstraction stable pour parler à un modèle, et d'un composant UI prêt à l'emploi pour afficher la conversation avec rendu progressif des tokens, gestion des erreurs et historique.

Concrètement, ellmer fournit un objet chat unique qui sait parler à plusieurs fournisseurs (Anthropic, OpenAI, modèles ouverts hébergés) sans changer le code métier : on change le constructeur, pas la logique de l'app. shinychat ajoute le module Shiny qui encapsule la bulle de conversation, le scroll automatique, l'indicateur de frappe et l'injection de function calling côté serveur. Pour une équipe data qui veut exposer un assistant interne branché sur ses données métier, le gain de temps est réel : ce qui demandait une semaine de développement UI se résume à quelques appels de fonctions.

La newsletter Posit de septembre ajoute une pièce intéressante au puzzle : l'arrivée de modèles open-weights comme Kimi K3 et GLM 5.2 sur la plateforme Posit AI, présentés comme plus rapides en streaming et moins coûteux par token que les alternatives propriétaires. Pour une entreprise soucieuse de maîtriser ses coûts d'inférence ou ses contraintes de résidence de données, pouvoir basculer vers un modèle ouvert sans réécrire son app est un argument de poids. ellmer rend ce changement de backend quasi transparent.

En pratique, le chantier se découpe en trois briques : la logique métier (quelles données le modèle peut-il voir, quelles actions peut-il déclencher via function calling), l'UI de chat (déléguée à shinychat), et la gouvernance (logs des échanges, limitation de débit, filtrage des sorties). C'est cette troisième brique qui prend le plus de temps en entreprise, et aucun package ne la résout à votre place.

Les limites restent celles de tout système conversationnel en production : la latence réseau vers le fournisseur de modèle, le coût par token qui peut vite grimper sur un usage intensif, et la nécessité de tester les prompts comme on teste du code (jeux de cas, regressions). Un assistant RAG branché sur des documents internes demande aussi une couche de recherche vectorielle qu'ellmer ne fournit pas nativement : il faut l'assembler soi-même ou s'appuyer sur un package tiers.

CODE R

library(ellmer)
library(shiny)
library(shinychat)

ui <- fluidPage(
  titlePanel("Assistant interne"),
  chat_ui("chat")
)

server <- function(input, output, session) {
  chat_client <- chat_anthropic(
    model = "claude-3-5-sonnet-latest",
    system_prompt = "Tu es un assistant interne pour l'equipe data. Reponds de maniere concise."
  )

  observeEvent(input$chat_user_input, {
    stream <- chat_client$stream_async(input$chat_user_input)
    chat_append("chat", stream)
  })
}

shinyApp(ui, server)

chat_ui() affiche la conversation, chat_client gère l'appel au modèle avec streaming, et chat_append() injecte la réponse token par token dans l'interface.

Notre avis

ellmer et shinychat sont la première stack R qui permet de livrer un vrai chatbot métier sans sortir de l'écosystème Shiny. Le vrai travail reste la gouvernance des échanges et le choix du modèle, pas la plomberie UI.

→ Pour qui : Développeurs Shiny et data scientists qui veulent exposer un assistant IA interne branché sur des données ou des outils métier.

LES BRÈVES

mlr3 muscle son suivi de l'entraînement

La nouvelle mesure best_valid_score permet de récupérer le meilleur score de validation interne observé pendant l'entraînement d'un modèle, sans avoir à le recalculer à la main. Utile pour les pipelines d'early stopping où l'on veut comparer des runs sur leur meilleur point plutôt que sur le dernier.

Source : cran.r-project.org ↗

DATA

arrow corrige un piège silencieux sur les types uint64

Les valeurs uint64 sont désormais toujours converties en double côté R, ce qui évite des colonnes de types incohérents dans les list-columns selon la plage de valeurs rencontrée. Un détail qui a son importance pour qui ingère des données Parquet issues de systèmes externes avec des identifiants sur 64 bits.

Source : cran.r-project.org ↗

LE TIP R DU JOUR

Repérer les objets qui pèsent lourd en mémoire

Avant d'optimiser à l'aveugle une app Shiny ou un script, il vaut mieux savoir ce qui occupe réellement la mémoire. object.size() combiné à un tri donne un diagnostic rapide sans installer de package.

CODE R

tailles <- sapply(ls(envir = .GlobalEnv), function(x) object.size(get(x)))
sort(tailles, decreasing = TRUE)

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