Quarto annonce une réécriture en Rust avec éditeur collaboratif : ce qui va changer pour vos rapports R et comment préparer la transition sans douleur.

Quarto est devenu en quelques années le moteur de publication par défaut d'une bonne partie de l'écosystème R : rapports, dashboards, sites de documentation, livres techniques. L'annonce d'une version 2 entièrement réécrite en Rust change la donne pour qui a construit toute sa chaîne de production autour de l'outil. Ce n'est pas une mise à jour incrémentale comme celles qu'on suit mois après mois sur la branche 1.10 : c'est un changement de moteur, avec un nouveau parseur Markdown et un éditeur collaboratif intégré pensé pour Posit Cloud, Connect et Workbench.
Ce qui est acté aujourd'hui, et qui a de la valeur immédiate, ce sont les évolutions de la branche 1.x. Quarto 1.9 a apporté la publication directe vers Posit Connect Cloud, une sortie de site pensée pour être lue par des LLM, et des avancées solides côté Typst pour qui produit des livres ou des rapports longs. Les correctifs successifs de la 1.10 stabilisent cette base sans rien casser. C'est cette branche qui continuera d'être maintenue en parallèle de Quarto 2, pour une durée qui n'est pas précisée mais qui laisse clairement le temps de voir venir.
Pour une équipe data en entreprise, la question concrète n'est pas « quand migrer » mais « qu'est-ce qui est fragile dans ma chaîne actuelle ». Un projet Quarto qui s'appuie sur des extensions tierces, des filtres Lua maison ou des formats de sortie exotiques est plus exposé à des changements de comportement qu'un projet qui se limite aux formats standards (HTML, PDF via LaTeX ou Typst, documents Word). La réécriture en Rust promet des gains de performance et de robustesse, mais un changement de parseur Markdown peut modifier la façon dont certains éléments de syntaxe avancée sont interprétés, en particulier dans des documents très structurés avec du code R imbriqué.
La bonne pratique, dès maintenant, consiste à documenter ce qui dans vos .qmd dépend de comportements spécifiques à la version actuelle : callouts personnalisés, cross-références complexes, mélange de chunks R et Python dans un même document. Un audit léger de votre parc de rapports Quarto permet de savoir qui sera concerné le jour où la 2 sortira, plutôt que de le découvrir en production. Autant dire aussi qu'aucune date de sortie publique n'est fixée avant plusieurs mois : rien ne presse, mais rien n'empêche de commencer à ranger la maison.
La limite de cet exercice d'anticipation est qu'on travaille sur une annonce d'intention, pas sur une bêta testable. On ne sait pas encore précisément quels filtres Lua resteront compatibles, ni comment l'éditeur collaboratif s'intégrera avec un Workbench on-premise. Le vrai travail de migration ne pourra commencer sérieusement qu'avec une préversion publique.
list_qmd_dependencies <- function(repertoire) {
fichiers <- list.files(repertoire, pattern = "\\.qmd$", recursive = TRUE, full.names = TRUE)
resultats <- data.frame(
fichier = character(0),
extensions = character(0),
filtres_lua = character(0),
stringsAsFactors = FALSE
)
for (f in fichiers) {
lignes <- readLines(f, warn = FALSE)
bloc_yaml <- lignes[1:min(40, length(lignes))]
a_filtre <- any(grepl("filters:", bloc_yaml, fixed = TRUE))
a_extension <- any(grepl("\\{\\{< ", lignes))
resultats <- rbind(resultats, data.frame(
fichier = f,
extensions = ifelse(a_extension, "oui", "non"),
filtres_lua = ifelse(a_filtre, "oui", "non"),
stringsAsFactors = FALSE
))
}
resultats
}
audit <- list_qmd_dependencies("rapports")
print(audit[audit$extensions == "oui" | audit$filtres_lua == "oui", ])Un audit simple en R base qui repère, dans un dossier de rapports Quarto, les fichiers utilisant des extensions ou des filtres Lua, les points les plus susceptibles d'être affectés par un changement de moteur.
Une réécriture en Rust est une bonne nouvelle pour la robustesse à long terme de Quarto, mais c'est aussi le genre de chantier qui déplace silencieusement des comportements dont personne n'avait noté qu'ils étaient fragiles. Le double maintien de Quarto 1 pendant la transition est le signal rassurant à retenir : rien n'oblige à se précipiter.
→ Pour qui : Data analysts et data scientists qui maintiennent des rapports Quarto en production ou des pipelines de publication automatisés en entreprise.
Le package de pharmacométrie nlmixr2 couvre désormais l'étape de covariance sur tous les paramètres estimés, avec possibilité de changer de méthode sans tout refitter. La résolution FOCEI parallélisée réduit par ailleurs les temps de calcul sur les modèles de pharmacocinétique les plus lourds.
Source : r-consortium.org ↗Le package goodpractice, utilisé pour vérifier la qualité d'un package R avant publication, ajoute plus de cent nouveaux checks regroupés par catégories. Utile pour qui industrialise la création de packages internes en entreprise et veut un contrôle qualité reproductible plutôt qu'une relecture manuelle.
Source : ropensci.org ↗La sortie d'Arrow 24.0.0 profite directement au package arrow en R, utilisé pour manipuler de gros volumes de données en format colonnaire sans tout charger en mémoire. Un bon rappel pour les équipes qui traitent des fichiers Parquet volumineux sans vouloir dépendre systématiquement d'un entrepôt cloud.
Source : github.com ↗Les données saisies manuellement contiennent souvent des espaces en début ou en fin de chaîne qui faussent silencieusement les comparaisons et les jointures. trimws() les retire en une ligne, sans regex à écrire.
x <- " Paris " y <- "Paris" identical(trimws(x), y)
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus