R et le pharmacométricien : quand le code doit suivre le patient en temps réel

À la une

Simuler des trajectoires patient qui réagissent en temps réel

La pharmacométrie pose un problème que beaucoup de data scientists R ignorent : simuler un traitement, ce n'est pas rejouer une table d'événements figée. Un patient qui fait une réaction indésirable voit sa dose réduite ou son traitement interrompu, et cette décision dépend de ce qui s'est passé pendant la simulation elle-même. Jusqu'ici, les outils de pharmacocinétique en R traitaient les tables d'événements comme des plans fixes, décidés à l'avance, incapables de réagir à l'état simulé du patient.

La nouveauté de rxode2 change cette logique : l'historique d'événements d'un individu peut être modifié pendant la résolution du modèle. Concrètement, un modèle peut désormais interrompre une dose, la réduire, ou déclencher un nouvel événement en fonction d'une concentration simulée qui dépasse un seuil, ou d'un effet indésirable défini dans le modèle. L'événement suit le patient plutôt que d'être écrit une fois pour toutes dans une table statique.

Ce n'est pas un détail technique réservé aux pharmacologues. C'est un cas d'usage transposable à toute simulation R qui doit représenter une politique adaptative : un parcours client qui change de scénario selon un comportement observé en cours de simulation, un système de maintenance prédictive qui déclenche une intervention quand un seuil est franchi pendant la simulation elle-même, une politique de stock qui réagit à une rupture simulée. La mécanique est la même : un état mutable qui conditionne la suite de la trajectoire, résolu pas à pas plutôt que planifié à l'avance.

En pratique, cela demande de repenser son modèle non plus comme une fonction appliquée à un plan fixe, mais comme une boucle d'événements avec des règles de décision intégrées à la résolution. C'est plus proche de la simulation à événements discrets que du calcul vectorisé classique en R, et ça change la manière de raisonner sur la performance : on ne peut plus tout vectoriser puisque chaque pas dépend potentiellement du précédent.

La limite est réelle : ce type de modélisation est coûteux en temps de calcul, difficile à déboguer parce que le comportement dépend de l'historique simulé, et exige une discipline de tests rigoureuse pour s'assurer que les règles de dose adaptative ne produisent pas d'effets de bord silencieux. Pour des volumes importants de patients ou d'individus simulés, il faut budgétiser le temps de calcul en conséquence.

CODE R

# Exemple simplifié : simulation d'un dosage adaptatif
# (illustration pédagogique, pas un code rxode2 réel)

simuler_patient <- function(dose_initiale, seuil_concentration, n_pas) {
  dose <- dose_initiale
  concentration <- 0
  historique <- data.frame(pas = integer(0), dose = numeric(0), concentration = numeric(0))

  for (pas in seq_len(n_pas)) {
    # modèle pharmacocinétique très simplifié
    concentration <- concentration * 0.8 + dose * 0.3

    # règle adaptative : si la concentration dépasse le seuil, on réduit la dose
    if (concentration > seuil_concentration) {
      dose <- dose * 0.5
    }

    historique <- rbind(historique, data.frame(pas = pas, dose = dose, concentration = concentration))
  }

  historique
}

resultat <- simuler_patient(dose_initiale = 10, seuil_concentration = 8, n_pas = 20)
print(resultat)

Ce code illustre le principe d'un événement de dose qui suit l'état simulé du patient, sans reproduire l'API réelle de rxode2.

Notre avis

C'est une avancée de niche pour la pharmacométrie, mais le principe de simulation adaptative mérite l'attention de tout data scientist R qui modélise des trajectoires avec des règles de décision dynamiques. R prouve ici qu'il peut rivaliser avec des outils de simulation dédiés sur des cas complexes.

→ Pour qui : Data scientists en pharmacométrie, essais cliniques, et plus largement toute équipe R qui simule des trajectoires individuelles avec des règles de décision adaptatives.

LES BRÈVES

APPS

React dans Shiny, version officielle Posit

shinyreact permet d'écrire l'interface d'une app Shiny avec n'importe quel composant React npm, pendant que le serveur Shiny reste responsable des données. Le package est jeune et son API va encore bouger, mais c'est un signal fort sur la direction que prend l'écosystème Shiny côté front-end.

Source : opensource.posit.co ↗

ANALYTICS

R dans l'entreprise : des gains mesurables

Les Posit Impact Awards 2026 mettent en avant des cas concrets d'automatisation R en entreprise, dont une équipe santé ayant divisé par deux son délai de clôture avec la même équipe. Un rappel utile quand il faut justifier un investissement R face à une direction qui raisonne en ROI.

Source : posit.co ↗

DATA

Le R Consortium finance l'infrastructure de l'écosystème

Les premières subventions techniques 2026 couvrent l'infrastructure de données du recensement américain, l'analyse de réseaux spatiaux et l'interopérabilité des chaînes de caractères. Ces projets structurent discrètement les packages que les équipes R utilisent tous les jours sans y penser.

Source : r-consortium.org ↗

LE TIP R DU JOUR

Trouver tous les arguments d'une fonction sans deviner

formals() liste les paramètres formels d'une fonction, utile pour inspecter rapidement une signature sans lire toute la documentation, surtout dans du code hérité peu documenté.

CODE R

ma_fonction <- function(x, y = 10, ...) x + y

noms_args <- names(formals(ma_fonction))
print(noms_args)

valeurs_defaut <- formals(ma_fonction)
print(valeurs_defaut)

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