Chat IA dans Shiny : le coût caché du choix de modèle

À la une

Chatbot Shiny : la vraie question n'est plus technique, elle est économique

Intégrer un chat IA dans une app Shiny est devenu une mécanique bien rodée : shinychat fournit le composant, ellmer gère la connexion au modèle, et le tout s'assemble en quelques lignes. La dernière évolution de shinychat pousse le curseur plus loin sur l'expérience utilisateur, avec un rendu repensé pour un streaming plus fluide, l'affichage du raisonnement du modèle sous forme de panneaux repliables, et un bouton d'annulation pour stopper une réponse en cours. Ces détails comptent : un chat qui saccade ou qu'on ne peut pas interrompre donne une impression d'app bricolée, pas d'outil professionnel.

Mais ce travail sur l'interface masque un problème plus structurel qui remonte en ce moment dans l'écosystème : le coût des modèles de pointe grimpe, et vite. Les newsletters IA de Posit pointent des hausses tarifaires significatives d'une génération de modèle à l'autre, parfois doublées, parfois triplées, sans compter des tokenizers qui deviennent plus gourmands pour un texte équivalent. Pour une app Shiny qui sert un chatbot à plusieurs dizaines d'utilisateurs internes, la facture peut évoluer très vite sans que le code n'ait changé d'une ligne.

La réponse qui se dessine n'est pas de renoncer au meilleur modèle, mais de ne plus le choisir par défaut pour tout. Posit a par exemple intégré un modèle plus économique, Gemma, comme option dans son propre assistant, réservant les modèles premium aux tâches qui le justifient réellement. En R, cette logique se transpose directement avec ellmer : rien n'empêche de router les requêtes simples vers un modèle léger et de réserver le modèle coûteux aux cas complexes, ou de laisser l'utilisateur choisir son niveau de service.

Concrètement, cela veut dire architecturer son chat_server autour d'un paramètre de modèle configurable plutôt que figé en dur, suivre la consommation de tokens par session, et prévoir un mécanisme de bascule vers un modèle de repli en cas de budget dépassé ou de panne du fournisseur principal. Le bouton d'annulation apporté par shinychat prend ici une autre dimension : il ne sert pas qu'à l'ergonomie, il coupe aussi une génération qui partait pour coûter cher sur un modèle premium.

La limite, c'est que cette gestion multi-modèles ajoute de la complexité de code et de test : il faut valider que chaque modèle du pool répond correctement au même prompt système, ce qui n'est jamais garanti. Et un modèle économique moins capable peut dégrader la qualité perçue au pire moment, sur une question complexe mal orientée.

Pour une équipe qui démarre, la bonne approche reste de prototyper avec un seul modèle fiable, puis d'introduire la logique de routage une fois le volume d'usage réel connu. Deviner les coûts avant la mise en production est un exercice vain tant qu'on n'a pas de données de consommation.

CODE R

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

# Choix du modele pilote par une variable d'environnement ou un parametre
# plutot que fige en dur dans le code
choisir_modele <- function(niveau = c("economique", "premium")) {
  niveau <- match.arg(niveau)
  if (niveau == "economique") {
    chat_google_gemini(model = "gemma")
  } else {
    chat_anthropic(model = "claude-sonnet")
  }
}

ui <- page_fluid(
  selectInput("niveau", "Qualite de reponse",
              choices = c("economique", "premium")),
  chat_ui("chat", enable_cancel = TRUE)
)

server <- function(input, output, session) {
  client <- reactive({
    choisir_modele(input$niveau)
  })

  observeEvent(input$chat_user_input, {
    reponse <- client()$stream_async(input$chat_user_input)
    chat_append("chat", reponse)
  })
}

shinyApp(ui, server)

Le modele n'est pas fige dans le code : un selectInput laisse l'utilisateur ou l'administrateur choisir entre un modele economique et un modele premium selon le besoin.

Notre avis

Le vrai sujet d'un chatbot Shiny en 2026 n'est plus de savoir si R sait faire du streaming correctement, c'est de savoir combien chaque conversation va coûter sur un mois. Architecturer dès le départ un choix de modèle configurable évite une refonte douloureuse six mois plus tard.

→ Pour qui : Développeurs Shiny et data scientists qui déploient ou maintiennent des assistants conversationnels en entreprise.

LES BRÈVES

APPS

bslib ajoute des vraies barres d'outils Bootstrap

bslib propose désormais un composant toolbar natif, avec boutons, listes déroulantes et séparateurs prêts à l'emploi, sans bricoler du HTML Bootstrap à la main. Pour une app Shiny qui multiplie les actions rapides en haut d'écran, c'est un gain de temps direct et une cohérence visuelle assurée par le thème.

Source : github.com ↗

APPS

shinylive embarque un webR plus récent

Les apps Shiny exportées en WebAssembly avec shinylive tournent désormais sur une version plus récente de webR, avec un cache de paquets qui se met mieux à jour. Utile pour diffuser des démos ou des outils internes sans serveur Shiny, directement dans un navigateur ou une page Quarto.

Source : github.com ↗

DATA

DuckDB corrige un bug de stockage partagé sous Windows

Le connecteur R de DuckDB corrige un problème de chemin de stockage sur disque partagé sous Windows, qui pouvait gêner les usages en réseau d'entreprise. Un correctif discret mais qui évite des comportements erratiques sur des postes Windows standards en entreprise.

Source : github.com ↗

LE TIP R DU JOUR

Mesurer le temps d'exécution sans installer de package

Pour chronométrer un bloc de code sans dépendance externe, system.time encadre directement l'expression et retourne les temps CPU et écoulé. Pratique pour comparer deux approches avant d'optimiser à l'aveugle.

CODE R

system.time({
  x <- numeric(1e6)
  for (i in seq_along(x)) x[i] <- i^2
})

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