L'agent de données en self-service arrive dans l'écosystème R

Depuis deux ans, R a rattrapé son retard sur l'IA générative côté bibliothèques client (ellmer pour parler aux LLM, shinychat pour les intégrer dans une app). Ce qui manquait, c'était une couche au-dessus : un cadre qui structure un agent capable d'interroger une base de données en toute sécurité, de restituer une réponse fiable, et de s'intégrer proprement dans une app Shiny d'entreprise. C'est exactement ce que Posit vient de poser avec commons, en complément de la montée en version de querychat et shinychat.

Le principe de commons est de fournir un squelette d'agent self-service : on lui donne une ou plusieurs connexions de données (SQL, tables, API), un modèle de langage via ellmer, et le framework se charge de la boucle outil-réponse, de la validation des requêtes générées, et de la traçabilité des échanges. querychat, qui existait déjà pour poser des questions en langage naturel à des data frames ou des bases, passe désormais au support de tables multiples, à la sauvegarde de conversations et à l'export de dashboards autonomes : un analyste peut construire une exploration conversationnelle puis la figer en livrable partageable, sans redévelopper une app.

shinychat de son côté change de modèle d'intégration : chat_server() remplace chat_mod_server() comme point d'entrée principal, et tourne dans le scope de session plutôt que de créer son propre scope de module. Concrètement cela simplifie le câblage d'un chat dans une app existante, et débloque des fonctionnalités de série : historique multi-conversations persistant par utilisateur, pages de chat plein écran avec navigation (page_chat()), commandes slash pour déclencher des actions côté serveur depuis l'input de chat. Ce sont des éléments qu'on devait avant coder à la main.

ellmer, le socle commun de toute cette pile, gagne des méthodes pour gérer des fichiers hébergés côté fournisseur (upload une fois, référence ensuite dans les tours de conversation) et des callbacks on_request_start/on_request_end pour instrumenter coût et latence. Et pour aller chercher de la connaissance au-delà d'une base SQL, ragnar (RAG en R) continue d'évoluer en parallèle, notamment sur l'ingestion et le filtrage de chunks.

Concrètement, cela veut dire qu'on peut aujourd'hui monter une app Shiny où un utilisateur métier pose une question en français, le framework la traduit en requête sur duckdb ou une base d'entreprise, exécute, et répond avec un tableau ou un graphique, le tout avec garde-fous (validation de la requête générée, logs des échanges). On passe d'un gadget de démo à quelque chose qu'on peut envisager de mettre en production, à condition de garder un œil sur la gouvernance des données exposées au modèle.

Les limites restent réelles : la fiabilité d'un agent self-service dépend entièrement de la qualité du schéma de données et des garde-fous mis en place en amont, pas du framework lui-même. commons est en version 0.1, jeune, et l'intégration avec un SGBD d'entreprise (droits, filtrage par ligne) reste à la charge du développeur. Il faut aussi anticiper le coût : chaque question posée est un ou plusieurs appels LLM facturés.

args() affiche la signature complète d'une fonction avec ses valeurs par défaut, directement dans la console, sans charger la page d'aide. Pratique pour vérifier rapidement un paramètre oublié au milieu d'un script.