Le tableau R qui finit directement dans la présentation du comité
Dans beaucoup d'entreprises, le dernier kilomètre d'un pipeline R reste artisanal : on produit un tableau propre dans R, puis quelqu'un le recopie à la main dans PowerPoint pour le comité de direction, en perdant au passage la mise en forme, la logique de couleurs conditionnelles ou les totaux calculés. Ce point de friction est resté longtemps un angle mort des outils de reporting R, qui savaient très bien exporter vers HTML, LaTeX ou Word, mais pas vers le format que la majorité des décideurs utilisent réellement pour présenter des chiffres.
gt comble ce manque avec un moteur de rendu OOXML unifié qui couvre à la fois Word et PowerPoint. Concrètement, un tableau gt construit avec sa grammaire habituelle, formats numériques, groupes de lignes, cellules fusionnées, peut être sauvegardé en fichier .pptx exploitable tel quel dans une diapositive, sans repasser par un export HTML intermédiaire ni par un habillage manuel.
Cette version apporte aussi deux évolutions qui comptent pour des tableaux destinés à une audience non technique. D'abord, le contrôle de la visibilité des lignes avec rows_hide() et rows_unhide() : on peut masquer des lignes de détail tout en gardant les lignes de synthèse calculées sur l'ensemble des données visibles, utile pour livrer un tableau de synthèse tout en gardant la possibilité de dérouler le détail en interne. Ensuite, l'option drop_leading_zero sur les fonctions de formatage numérique, qui retire le zéro initial des valeurs entre -1 et 1 : un gain de lisibilité net pour des tableaux de corrélations ou de p-values, où afficher .82 plutôt que 0.82 est une convention de lecture attendue par les statisticiens et les financiers.
Pour s'en servir en production, la logique reste la même qu'avec les autres formats gt : on construit le tableau avec gt(), on l'habille avec les fonctions tab_*, fmt_*, cols_* habituelles, puis on appelle gtsave() avec l'extension .pptx. Le tableau arrive dans une diapositive unique, avec sa mise en forme, prêt à être inséré dans un deck existant ou à alimenter un pipeline de génération automatique de rapports PowerPoint depuis R.
La limite à connaître avant de généraliser l'usage : le moteur OOXML est récent, donc tout ce qui touche aux interactions avancées (gt_group multi-tableaux complexes, formats conditionnels très personnalisés, polices exotiques) mérite d'être testé sur un cas réel avant d'être mis en pipeline critique. Pour un tableau de synthèse standard avec formats numériques et groupes de lignes, le rendu est déjà fiable et correspond aux attentes d'un comité.
library(gt)
df <- data.frame(
region = c("Nord", "Sud", "Est", "Ouest"),
ca = c(1250000, 980000, 1430000, 760000),
marge = c(0.182, 0.095, 0.231, 0.064)
)
tbl <- gt(df)
tbl <- tab_header(tbl, title = "Chiffre d'affaires et marge par region")
tbl <- fmt_currency(tbl, columns = ca, currency = "EUR")
tbl <- fmt_percent(tbl, columns = marge, decimals = 1, drop_leading_zero = TRUE)
tbl <- cols_label(tbl, region = "Region", ca = "CA", marge = "Marge")
gtsave(tbl, "synthese_regions.pptx")Le tableau est construit et formaté avec la grammaire gt habituelle, puis exporté directement en diapositive PowerPoint via gtsave().
C'est le genre de nouveauté discrète qui a plus d'impact opérationnel que beaucoup d'annonces IA : elle supprime une étape manuelle répétée chaque semaine dans les équipes de reporting. On recommande de l'essayer sur un reporting récurrent existant avant de l'intégrer à un pipeline Rmd ou Quarto automatisé.
→ Pour qui : Data analysts et data scientists qui produisent des reportings réguliers pour des comités ou des directions métier.
LES BRÈVES
knitr continue d'absorber les cas limites de Quarto et RMarkdown
Cette mise à jour de knitr corrige des comportements de rendu qui touchent surtout les documents complexes mêlant plusieurs moteurs ou formats de sortie. Rien de spectaculaire, mais pour une équipe qui génère des rapports automatisés chaque semaine, ces corrections évitent les mauvaises surprises silencieuses au moment du build.
Source : cran.r-project.org ↗curl, la brique invisible derrière tous vos appels API en R
curl reste le socle bas niveau sur lequel reposent httr2, downloads de données ou appels à des API internes depuis R. Une mise à jour régulière de ce package est rarement un sujet en soi, mais c'est un bon rappel : dans une stack de production, il vaut mieux savoir ce qui tourne sous le capot de vos appels HTTP que le découvrir le jour d'un incident réseau.
Source : cran.r-project.org ↗highcharter corrige ses cartes et sort ses dépendances internes du rouge CRAN
La mise à jour corrige notamment le téléchargement des fonds de carte, qui renvoyait des erreurs 403, un problème bloquant pour toute app Shiny affichant des cartes choroplèthes interactives avec ce package. Elle nettoie aussi des avertissements internes liés à des fonctions dépréciées d'igraph, un bon signal de maintenance pour un package largement utilisé en reporting interactif.
Source : cran.r-project.org ↗LE TIP R DU JOUR
Construire un chemin de sauvegarde horodaté sans bricoler de date
Pour nommer des fichiers de sortie de façon unique et triable chronologiquement, Sys.time() formaté avec format() évite les collisions de noms et les écrasements accidentels lors d'exécutions répétées d'un même script.
horodatage <- format(Sys.time(), "%Y%m%d_%H%M%S")
nom_fichier <- paste0("export_", horodatage, ".csv")
print(nom_fichier)SOURCES
- https://cran.r-project.org/package=gt
- https://cran.r-project.org/package=curl
- https://cran.r-project.org/package=knitr
- https://cran.r-project.org/package=highcharter
VOUS CODEZ EN R ?
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.