Flux de données d’un essai clinique : SDTM, ADaM, TLF

Comment les mesures brutes d’un essai de phase III deviennent une soumission réglementaire — les standards, les responsables et les packages R à chaque étape

La carte d’orientation de la programmation des essais cliniques en R. Suivez un seul point de données depuis le cahier d’observation (CRF/EDC) à travers la tabulation SDTM et les jeux de données d’analyse ADaM jusqu’aux tableaux, listings et figures (TLF) destinés à la FDA — et découvrez quel standard CDISC gouverne chaque étape et quel package pharmaverse (admiral, sdtm.oak, xportr, rtables, tern) l’implémente.

Date de publication

30 juin 2026

Modifié

7 juillet 2026

AstucePoints clés
  • Les données d’un essai clinique traversent cinq étapes — CRF/EDC → SDTM → ADaM → TLF → soumission — et la programmation clinique est l’art de les faire avancer correctement.
  • SDTM (Study Data Tabulation Model) standardise les données collectées en domaines fixes ; ADaM (Analysis Data Model) dérive des jeux de données prêts à l’analyse à partir de SDTM ; TLF (Tables, Listings, Figures) sont les sorties qui entrent dans la soumission.
  • CDISC fixe les standards à chaque étape (CDASH pour la collecte, SDTM-IG, ADaM-IG, Controlled Terminology, Define-XML) ; le pharmaverse est la boîte à outils R open source qui les implémente (admiral, sdtm.oak, xportr, rtables, tern).
  • Le fil rouge non négociable est la traçabilité : chaque chiffre d’analyse doit pouvoir remonter à travers ADaM et SDTM jusqu’à la valeur brute qu’un site a enregistrée. ADaM existe pour rendre ce retour en arrière possible.
  • L’industrie passe de SAS → R pour les soumissions — la FDA accepte les packages basés sur R — si bien que ces standards, associés au pharmaverse, constituent désormais une voie crédible et de bout en bout vers un dépôt réglementaire.

Introduction

Un essai de phase III recrute quelques centaines de patients répartis sur des dizaines de sites. Chaque visite génère des données — signes vitaux, prélèvements de laboratoire, événements indésirables, doses administrées, la date à laquelle l’état d’un patient a progressé — et tout cela aboutit dans un système de saisie électronique des données (EDC) sous forme de tables brutes, propres à l’étude. Des mois plus tard, un régulateur ouvre une soumission et s’attend à y trouver un tableau démographique, une courbe de survie et un résumé des événements indésirables, chacun traçable jusqu’à ces valeurs brutes, dans un format qu’il a déjà vu mille fois.

Passer du premier au second, c’est la programmation des essais cliniques. Cette leçon est la carte de ce parcours : les cinq étapes que traverse un point de données, qui est responsable de chacune, quel standard CDISC (Clinical Data Interchange Standards Consortium) la gouverne et quel package R du pharmaverse fait le travail. C’est la leçon d’orientation de tout le pilier — lisez-la une fois et chaque leçon ultérieure (construire un ADSL, dériver un critère de type délai jusqu’à l’événement, produire un tableau AE) vient se ranger à une place que vous comprenez déjà.

Aucun code à installer et aucune connaissance préalable de CDISC requise. Si vous connaissez R de base, vous en savez assez.

Le flux de données d’un essai clinique

Le pipeline est un flux à sens unique, standardisation puis analyse, avec une subtilité essentielle : chaque étape en aval reste traçable jusqu’à l’étape qui la précède.

flowchart TD
  A["CRF / EDC<br/>données brutes collectées"] --> B["SDTM<br/>tabulation standardisée"]
  B --> C["ADaM<br/>jeux de données prêts à l'analyse"]
  C --> D["TLF<br/>tableaux · listings · figures"]
  D --> E["Soumission<br/>FDA · EMA · PMDA"]
  C -. "traçable jusqu'à" .-> B
  D -. "traçable jusqu'à" .-> C
Figure 1

Lisez-le comme une phrase : collecter les données (CRF/EDC), les standardiser (SDTM), dériver ce que vous allez analyser (ADaM), produire les sorties (TLF) et soumettre. Les flèches en pointillés sont la raison d’être de toute la discipline — une valeur d’analyse n’est fiable que dans la mesure où le chemin qui la relie à un chiffre réellement enregistré par un site clinique l’est aussi.

Étape 1 — Données brutes (CRF / EDC)

Un cahier d’observation (CRF) est le questionnaire structuré qu’un site remplit pour chaque sujet ; un système EDC (saisie électronique des données) est le logiciel qui collecte ces formulaires. La sortie est constituée de données brutes, propres à l’étude — noms de colonnes, mises en page et listes de codes choisis pour cet essai, pas pour un quelconque standard externe. Elle relève généralement de la gestion des données cliniques, et le CRF lui-même est habituellement conçu selon le standard CDISC CDASH (Clinical Data Acquisition Standards Harmonization), afin que la collecte soit cohérente et se mappe proprement vers SDTM par la suite.

La propriété essentielle à retenir : les données brutes ne sont pas comparables d’une étude à l’autre. Chaque promoteur et chaque fournisseur d’EDC nomme les choses différemment. La standardisation est tout le travail de l’étape suivante.

Étape 2 — SDTM (Study Data Tabulation Model)

SDTM remodèle les données brutes en une structure fixe, attendue par le régulateur. Les données sont réparties en domaines — des tables standardisées contenant chacune un type d’information, identifiées par un code à deux lettres : DM (démographie), AE (événements indésirables), EX (exposition/administration), VS (signes vitaux), LB (résultats de laboratoire), et bien d’autres. Chaque domaine possède des variables prescrites (identifiant de sujet, un numéro de séquence, des dates ISO-8601) définies par le SDTM Implementation Guide (SDTM-IG), et les valeurs codées proviennent de la Controlled Terminology CDISC.

SDTM est essentiellement de la tabulation : un enregistrement fidèle et standardisé de ce qui a été observé, le plus souvent une ligne par observation. Il n’est pas encore mis en forme pour les statistiques — c’est délibéré. Le rôle de SDTM est de rendre les données de n’importe quelle étude repérables au même endroit, à chaque fois. Il est généralement produit par des programmeurs cliniques ou statistiques et constitue l’un des deux ensembles de jeux de données qu’un promoteur soumet.

Étape 3 — ADaM (Analysis Data Model)

ADaM prend les données SDTM standardisées et les transforme en jeux de données prêts à l’analyse — les entrées sur lesquelles un programme statistique peut s’exécuter directement. Là où SDTM tabule, ADaM dérive : variables de traitement, indicateurs de population (par exemple un indicateur de population de sécurité), valeurs initiales, variation par rapport à la valeur initiale et fenêtres de visite que SDTM ne porte pas. Les structures de jeux de données courantes sont ADSL (une ligne par sujet — l’ossature au niveau sujet), BDS (Basic Data Structure, pour les mesures dans le temps) et OCCDS (Occurrence Data Structure, pour les événements comme les événements indésirables). Parmi les jeux de données fréquents : ADSL, ADAE (événements indésirables), ADLB (laboratoire) et ADTTE (délai jusqu’à l’événement).

Le ADaM Implementation Guide (ADaM-IG) repose sur quelques principes fondamentaux : les données ADaM et leurs métadonnées doivent permettre une communication claire et sans ambiguïté, assurer la traçabilité (chaque valeur remonte jusqu’à sa source SDTM et redescend jusqu’au résultat de l’analyse), être prêtes à l’analyse (utilisables par les logiciels courants avec un minimum de programmation supplémentaire) et être associées à des métadonnées. En pratique, un jeu de données ADaM est donc aussi autonome (il porte chaque variable dont son analyse a besoin) et généralement structuré à raison d’une ligne par unité d’analyse. La traçabilité est l’âme d’ADaM et la raison pour laquelle il existe en tant qu’étape distincte plutôt que d’analyser SDTM directement. ADaM relève généralement des programmeurs statistiques, qui le construisent pour réaliser l’analyse que le biostatisticien a spécifiée dans le Statistical Analysis Plan.

Étape 4 — TLF (Tables, Listings, Figures)

Les TLF sont les sorties concrètes de l’essai : les tableaux (un résumé démographique, une table d’incidence des événements indésirables), les listings (impressions de données par sujet) et les figures (une courbe de survie de Kaplan–Meier, un forest plot) qui entrent dans le Clinical Study Report et la soumission. Ils sont produits à partir des jeux de données ADaM, en suivant des maquettes (mock shells) convenues à l’avance qui spécifient le titre, la mise en page et les notes de bas de page de chaque sortie avant qu’aucun code ne soit écrit. La programmation des TLF relève généralement des programmeurs statistiques, à partir de maquettes conçues par le biostatisticien.

Un TLF est l’artefact le plus visible — c’est ce qu’un évaluateur lit — mais il ne porte aucune donnée nouvelle : c’est une vue mise en forme d’ADaM, qui est une vue dérivée de SDTM, elle-même une vue standardisée des données brutes. Remontez n’importe quel chiffre d’une table de soumission le long de cette chaîne et vous devriez aboutir à une valeur qu’un site a enregistrée.

Étape 5 — Soumission

Le package final est transmis à une autorité de santé — la FDA (États-Unis), l’EMA (Europe), la PMDA (Japon) — dans le cadre de l’eCTD (electronic Common Technical Document), avec les données d’étude logées dans le Module 5. Il contient les jeux de données SDTM et ADaM (sous forme de fichiers de transport XPT), les sorties TLF, un document Define-XML décrivant les jeux de données et leurs dérivations à l’intention de l’ évaluateur, les guides du relecteur (ADRG/SDRG) et les programmes d’analyse. Define-XML est l’ossature lisible par machine de la traçabilité — c’est ainsi qu’un évaluateur navigue d’un résultat jusqu’à sa source sans ouvrir votre code.

Historiquement, c’était un monde SAS. Cela change : la FDA accepte désormais les soumissions basées sur R, et le Submissions Working Group du R Consortium a mené plusieurs soumissions pilotes réussies à la FDA en utilisant précisément la boîte à outils open source ci-dessous. Ce basculement explique pourquoi apprendre la voie du pharmaverse constitue désormais une stratégie de carrière et de soumission crédible, et non un passe-temps.

De la tabulation à l’analyse : un regard concret

L’idée structurelle la plus importante de tout le flux est le passage SDTM → ADaM : SDTM tabule une ligne par enregistrement, tandis que le jeu de données au niveau sujet d’ADaM (ADSL) se ramène à une ligne par sujet et ajoute des variables d’analyse dérivées. Voici ce passage en quelques lignes de R de base — sans packages, avec des valeurs inventées (les vraies données pédagogiques se trouvent dans {pharmaversesdtm} et {pharmaverseadam}, utilisées dans les séries ultérieures) :

# SDTM EX (Exposure): one row per dosing RECORD — a subject can appear many times.
ex <- data.frame(
  USUBJID = c("01-701", "01-701", "01-702", "01-703"),
  EXTRT   = c("DRUG", "DRUG", "PLACEBO", "DRUG"),
  EXSTDTC = c("2026-01-05", "2026-01-19", "2026-01-06", "2026-01-04")
)
ex
  USUBJID   EXTRT    EXSTDTC
1  01-701    DRUG 2026-01-05
2  01-701    DRUG 2026-01-19
3  01-702 PLACEBO 2026-01-06
4  01-703    DRUG 2026-01-04

Le sujet 01-701 a deux enregistrements d’exposition. SDTM les conserve sous forme de deux lignes — il tabule fidèlement chaque événement d’administration. Passons à l’ADSL ADaM : exactement une ligne par sujet, avec un indicateur de population de sécurité (SAFFL) dérivé — « ce sujet a-t-il reçu au moins une dose ? » — calculé à partir des enregistrements EX ci-dessus.

subjects <- c("01-701", "01-702", "01-703")

adsl <- data.frame(
  USUBJID = subjects,
  TRT01A  = c("Drug", "Placebo", "Drug"),                 # actual treatment, analysis-ready
  SAFFL   = ifelse(subjects %in% ex$USUBJID, "Y", "N")    # derived: dosed at least once
)
adsl
  USUBJID  TRT01A SAFFL
1  01-701    Drug     Y
2  01-702 Placebo     Y
3  01-703    Drug     Y

Trois lignes en sortie, une par sujet, chacune portant une variable (SAFFL) qui n’existait pas dans les données brutes ni dans SDTM — elle a été dérivée, et vous pouvez la retracer directement jusqu’aux enregistrements EX qui l’ont produite. C’est ADaM en miniature : une structure à une unité d’analyse par ligne, des variables dérivées, une traçabilité complète. Les dérivations réelles sont bien plus riches (valeur initiale, variation par rapport à la valeur initiale, indicateurs d’apparition sous traitement, logique d’événement/censure), et le package admiral existe pour les réaliser correctement — mais la forme de l’idée est exactement celle-ci.

Où s’appliquent les standards CDISC

CDISC (Clinical Data Interchange Standards Consortium) est l’organisme dont les standards rendent une soumission lisible pour un régulateur. Chaque étape ci-dessus a son standard directeur :

Standard Gouverne Étape
CDASH Comment les données sont collectées sur le CRF Brut / CRF
SDTM-IG Comment les données collectées sont tabulées en domaines SDTM
Controlled Terminology Listes de codes standardisées / valeurs valides (maintenues par NCI/EVS) SDTM & ADaM
ADaM-IG Comment les jeux de données prêts à l’analyse sont structurés et dérivés ADaM
Define-XML Métadonnées lisibles par machine des jeux de données et traçabilité des dérivations Soumission

Un sixième élément se situe au-dessus des données : ICH E9(R1) (une ligne directrice de l’International Council for Harmonisation) et son cadre des estimandes définissent à quelle question l’analyse répond, que le biostatisticien traduit en variables ADaM et en maquettes TLF — le pont entre l’objectif de l’essai et la programmation. (Ce cadre fait l’objet de sa propre leçon plus loin dans cette série.)

Où se situe le pharmaverse

Le pharmaverse est une famille inter-entreprises de packages R open source, un (ou plusieurs) pour chaque étape — la réponse R aux macros SAS qui ont fait ce travail pendant des décennies. Vous découvrirez chacun d’eux de façon pratique dans les séries ultérieures ; pour l’instant, contentez-vous d’en voir la carte :

Étape Principaux packages pharmaverse Ce qu’ils font
Brut → SDTM sdtm.oak, pharmaversesdtm Mapper les données brutes vers les domaines SDTM ; données SDTM d’exemple
Contrôles / métadonnées SDTM xportr, sdtmchecks, metacore, metatools Typage/étiquetage, contrôles de conformité, métadonnées pilotées par spécification
SDTM → ADaM admiral, metacore, metatools Dériver les jeux de données ADaM (admiral est le produit phare)
ADaM → TLF rtables, tern, gtsummary, cards, ggsurvfit Construire des tableaux, des modèles cliniques, des figures KM
Soumission xportr, metacore, pkglite Exporter en XPT, gérer les métadonnées Define-XML, empaqueter les programmes

admiral en est la pièce maîtresse : une boîte à outils fondée sur le tidyverse, délibérément non opaque (pas une boîte noire), pour les dérivations ADaM, co-développée et maintenue par de nombreuses entreprises pharmaceutiques au sein de la communauté pharmaverse. La plupart des leçons phares de ce pilier gravitent autour d’elle.

🟢 Avec un agent IA

Demandez à Prova « quelle est la différence entre SDTM et ADaM ? » — elle répond en s’appuyant sur les leçons de ce pilier, avec du R exécutable que vous pouvez essayer sur des données pharmaverse d’exemple. The runtime is the judge. Demander à Prova →

Comment cela s’articule avec le reste du pilier

Chaque étape ci-dessus devient sa propre série de leçons pratiques :

  • Programmation SDTM — construire les domaines essentiels (DM, AE, EX, VS) à partir des données brutes avec sdtm.oak, appliquer la Controlled Terminology et vérifier la conformité.
  • ADaM avec admiral — la série phare : construire ADSL, puis les jeux de données BDS et OCCDS (ADAE, ADLB), et ADTTE pour les critères de type délai jusqu’à l’événement, qui réutilise les méthodes d’analyse de survie déjà présentes sur Datanovia.
  • Génération de TLF — transformer ADaM en tableaux démographiques, résumés d’AE et figures de Kaplan–Meier avec rtables/tern et gtsummary.
  • Validation, QC, empaquetage de la soumission et programmation clinique agentique (assistée par IA) complètent le chemin vers un package complet, traçable et prêt à la soumission.

Ces séries se déploient progressivement ; cette fondation est le cadre auquel elles se rattachent toutes. Là où une leçon pratique sur une étape donnée existe, le hub du pilier y renvoie.

Problèmes fréquents

Voici des confusions conceptuelles qui font discrètement dérailler les personnes nouvelles dans la programmation clinique.

Confondre SDTM et ADaM. Ils se ressemblent — tous deux sont des jeux de données aux standards CDISC avec des identifiants de sujet — mais ils ont des rôles différents. SDTM tabule ce qui a été observé (fidèle, le plus souvent une ligne par enregistrement) ; ADaM dérive ce que vous analysez (prêt à l’analyse, une ligne par unité d’analyse, avec de nouvelles variables). Vous analysez ADaM, pas SDTM. Si vous vous surprenez à calculer la variation par rapport à la valeur initiale dans SDTM, vous êtes à la mauvaise étape.

Traiter un TLF comme la source de vérité. Une table de soumission ne porte aucune donnée nouvelle — c’est une vue mise en forme d’ADaM, qui dérive de SDTM, qui standardise les données brutes. Lorsqu’un chiffre semble faux, déboguez à rebours le long de cette chaîne (TLF → ADaM → SDTM → brut), et non en rafistolant la table.

Supposer que vous avez encore besoin de SAS. Tout le pipeline ci-dessus s’exécute de bout en bout en R open source via le pharmaverse, et la FDA a accepté des soumissions basées sur R. L’interopérabilité avec SAS est assurée par haven (lecture et écriture des formats .xpt et .sas7bdat) et xportr (export .xpt conforme à CDISC) — R est une voie de première classe, pas un contournement.

Questions fréquentes

SDTM standardise les données collectées en domaines fixes à des fins de tabulation — un enregistrement fidèle de ce qui a été observé, le plus souvent une ligne par observation. ADaM dérive des jeux de données prêts à l’analyse à partir de SDTM — une ligne par unité d’analyse, avec de nouvelles variables dérivées (indicateurs, valeur initiale, variation par rapport à la valeur initiale) et une traçabilité complète jusqu’à SDTM. Vous exécutez les statistiques sur ADaM, pas sur SDTM.

CDISC est le Clinical Data Interchange Standards Consortium. Il définit les standards (CDASH, SDTM, ADaM, Controlled Terminology, Define-XML) qui font que les données de chaque essai suivent la même structure, afin que des régulateurs comme la FDA et l’EMA puissent évaluer les soumissions de manière cohérente et exigent ces formats pour les demandes d’autorisation de nouveaux médicaments.

TLF signifie Tables, Listings, and Figures (tableaux, listings et figures) — les sorties de synthèse d’un essai (un tableau démographique, un résumé des événements indésirables, une courbe de Kaplan–Meier). Ils sont produits à partir des jeux de données ADaM, en suivant des maquettes pré-spécifiées, et entrent dans le Clinical Study Report et la soumission réglementaire.

Oui. La FDA accepte les soumissions basées sur R, et le Submissions Working Group du R Consortium a mené des soumissions pilotes réussies à la FDA avec la boîte à outils open source pharmaverse. SAS reste courant, mais R, via des packages comme admiral, rtables et xportr, est désormais une voie crédible et acceptée.

Le pharmaverse est une collaboration inter-entreprises de packages R open source pour le reporting clinique — admiral (ADaM), sdtm.oak (SDTM), xportr (export XPT), rtables/tern (tableaux et figures), metacore/metatools (métadonnées), et plus encore. Ensemble, ils couvrent tout le pipeline CRF→soumission en R.

Testez vos connaissances

Pour chaque artefact ci-dessous, nommez l’étape à laquelle il appartient (brut / SDTM / ADaM / TLF / soumission) et dites qui en est généralement responsable :

  1. Un domaine DM avec une ligne standardisée par sujet.
  2. Une figure de survie de Kaplan–Meier pour le Clinical Study Report.
  3. Un jeu de données ADSL avec un indicateur de population de sécurité (SAFFL) dérivé.
  4. Un fichier Define-XML décrivant les dérivations de chaque jeu de données.

Parcourez le flux dans l’ordre — collecter, standardiser, dériver, produire, soumettre. « Domaine standardisé » et « indicateur dérivé » sont des étapes différentes ; une figure est une sortie ; Define-XML voyage avec le package final.

  1. SDTM — DM est un domaine de tabulation standardisé ; produit par des programmeurs cliniques/statistiques.
  2. TLF — une figure est une sortie de l’essai, produite par des programmeurs statistiques à partir d’ADaM, selon la maquette d’un biostatisticien.
  3. ADaM — une variable d’analyse au niveau sujet dérivée ; produite par des programmeurs statistiques selon le Statistical Analysis Plan.
  4. Soumission — Define-XML fait partie du package envoyé au régulateur, fournissant les métadonnées de traçabilité.

A. L’export EDC brut, car il est le plus proche de ce qui a été collecté. B. SDTM, car il est déjà standardisé selon CDISC. C. ADaM, car c’est le jeu de données dérivé et prêt à l’analyse.

C. Vous analysez ADaM. SDTM est standardisé mais relève de la tabulation — il n’a aucune variable dérivée, ni valeur initiale ni variation par rapport à la valeur initiale, et il est structuré à raison d’une ligne par observation plutôt que par unité d’analyse. ADaM existe précisément pour être prêt à l’analyse tout en restant traçable jusqu’à SDTM.

Références

Les standards et outils de cette leçon sont définis par leurs sources primaires :

Conclusion

Les données d’un essai clinique suivent un parcours en cinq étapes : elles sont collectées sur le CRF/EDC, standardisées en domaines SDTM, dérivées en jeux de données ADaM prêts à l’analyse, produites sous forme de sorties TLF et soumises à un régulateur — avec une traçabilité reliant chaque étape à la précédente. CDISC fixe les règles à chaque étape ; le pharmaverse les implémente en R ; et la discipline qui tient l’ensemble est la capacité de remonter n’importe quel chiffre de soumission jusqu’à la valeur brute qui le sous-tend. Gardez cette carte en tête et chaque leçon ultérieure — construire un ADSL, dériver un critère de type délai jusqu’à l’événement, produire un tableau AE — n’est qu’un examen plus rapproché d’une étape sur un itinéraire que vous connaissez déjà.

Leçons connexes

  • Qu’est-ce que l’analyse de survie ? — les méthodes derrière les critères de type délai jusqu’à l’événement (le jeu de données ADTTE et les figures KM que vous rencontrerez dans les séries ADaM et TLF). · Estimation de Kaplan–Meier — la courbe de survie qui devient une figure d’essai clinique. · CDISC ADTTE pour la soumission réglementaire — comment une analyse de type délai jusqu’à l’événement est empaquetée pour une soumission, le pont de la biostatistique vers ce pilier.
  • Où cela s’inscrit : développement du médicament et flux de données (vous êtes ici) → programmation SDTM → ADaM avec admiral → génération de TLF → validation, QC et soumission — d’abord les concepts, puis le workflow pratique qu’ils alimentent.
Cette page vous a-t-elle été utile ?

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN
Note

Cette leçon est reproductible : chaque résultat de cette page a été produit par le code montré — copiez n’importe quel bloc et exécutez-le pour les reproduire. The runtime is the judge.

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Flux de données d’un essai clinique : SDTM, ADaM, TLF},
  date = {2026-06-30},
  url = {https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/01-drug-development-flow},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Flux de données d’un essai clinique : SDTM, ADaM, TLF.” 2026. June 30. https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/01-drug-development-flow.