De SAS à R en programmation clinique : ce qui change, ce qui reste

Q: La FDA accepte-t-elle les soumissions d’essais cliniques réalisées avec R ?

Oui. La FDA n’exige aucun logiciel statistique particulier — sa Déclaration de clarification sur les logiciels statistiques de 2015 le dit — du moment que le logiciel utilisé est entièrement documenté (y compris la version et le build). Ce qu’elle exige, c’est une soumission conforme et reproductible, quel que soit le langage. Les pilotes du R Consortium l’ont confirmé en pratique en soumettant des packages tout-R via la véritable passerelle eCTD et en les faisant évaluer.

Q: Un package tout-R a-t-il réellement été soumis à la FDA et évalué par elle ?

Oui — via le R Submissions Working Group du R Consortium. Pilot 3 a livré le premier package basé sur R publiquement disponible incluant des jeux de données ADaM ainsi que des tableaux et figures, tous générés en R ; il est passé par la passerelle eCTD et la FDA a accepté et reproduit les résultats, émettant sa réponse en 2024. Des projets pilotes ultérieurs ont ajouté des applications Shiny et la technologie WebAssembly/conteneurs. Chaque artefact est public sur le GitHub du R Consortium.

Q: Qu’est-ce que le pharmaverse ?

Le pharmaverse est un ensemble organisé et gouverné par la communauté de packages R open source pour le reporting clinique, soutenu par PHUSE. Ce n’est pas un seul package mais un écosystème connecté couvrant le pipeline : sdtm.oak (SDTM), admiral (ADaM), metacore/metatools (métadonnées), rtables/tern/gtsummary (tableaux et figures), xportr (export XPT) et teal (applications de revue interactives). C’est ce qui rend praticable un workflow de soumission R de bout en bout.

Q: Si nous passons à R, les standards CDISC changent-ils ?

Non. SDTM, ADaM, Define-XML, Controlled Terminology et le package eCTD sont indépendants du langage — ils sont définis par CDISC et les régulateurs, pas par SAS ou R. R produit les mêmes jeux de données et métadonnées conformes qu’un évaluateur attend. Vos connaissances CDISC se transfèrent complètement ; seul l’outil qui construit les jeux de données change.

Q: SAS est-il en train d’être remplacé par R en programmation clinique ?

Pas entièrement. SAS reste solidement implanté — macros validées, SOP, études historiques et une vaste main-d’œuvre formée — et c’est encore la compétence la plus demandée dans les offres d’emploi. Le tableau réaliste est hybride : de nombreuses structures utilisent SAS pour le travail ADaM/TLF critique pour la stabilité et R pour SDTM, les applications de revue Shiny, le QC et l’analyse exploratoire. L’adoption de R progresse, sans être totale — une évolution continue vers la coexistence, et non un basculement achevé.

Pourquoi SAS était la norme, ce que la FDA accepte réellement, ce que les pilotes du R Consortium et le pharmaverse ont prouvé, et ce qui reste identique — les standards CDISC

Une carte honnête et précise de la transition de SAS vers R dans la programmation des essais cliniques. Pourquoi SAS est devenu la norme, ce qui a réellement changé (la FDA accepte les soumissions R qui satisfont aux mêmes exigences ; les pilotes du R Consortium ont prouvé qu’un package tout-R est possible ; le pharmaverse l’a rendu pratique), ce qui reste identique (les standards CDISC des leçons de fondations précédentes sont indépendants du langage — seul l’outil change), et le tableau réaliste : SAS reste solidement implanté, la plupart des structures sont hybrides, l’adoption de R progresse, sans être totale. C’est la leçon qui motive la série pratique R/pharmaverse à venir.

Date de publication

30 juin 2026

Modifié

7 juillet 2026

Points clés

La FDA accepte R. Elle n’exige aucun logiciel statistique particulier — sa Déclaration de clarification sur les logiciels statistiques de 2015 le dit clairement — du moment que ce que vous avez utilisé est entièrement documenté. SAS était une convention, jamais une réglementation.
Les pilotes du R Consortium ont levé le doute. Le R Submissions Working Group a soumis de vrais packages tout-R via la passerelle eCTD de la FDA ; Pilot 3 a livré le premier package R public incluant des jeux de données ADaM ainsi que des tableaux et figures, et la FDA a accepté et reproduit les résultats.
Le pharmaverse l’a rendu pratique. Un ensemble organisé et gouverné par l’industrie de packages R open source — admiral (ADaM), sdtm.oak (SDTM), xportr (export XPT), rtables/tern (tableaux et figures), teal (applications de revue) — couvre désormais l’ensemble du pipeline.
Les standards ne changent pas — seul l’outil change. SDTM, ADaM, Define-XML et le package eCTD des leçons de fondations précédentes sont indépendants du langage. R produit les mêmes jeux de données conformes qu’un régulateur attend ; vos connaissances CDISC se transfèrent intactes.
Soyez réaliste : c’est une évolution, pas un remplacement total. SAS est encore partout, la plupart des structures sont hybrides, et l’adoption de R progresse, sans être totale. Mais le R open source est désormais une façon à part entière de réaliser le travail de soumission — ce qui est précisément ce que ce pilier enseigne.

Introduction

Si vous avez passé un peu de temps près des essais cliniques, vous l’avez entendu : « Les soumissions, c’est du SAS. C’est comme ça, point. » Pendant des décennies, c’était effectivement vrai — et cela a façonné l’outillage, la formation et le recrutement de toute une profession.

Ce n’est plus toute l’histoire. La FDA accepte les soumissions basées sur R qui satisfont à ses exigences, un groupe de travail a soumis des packages R complets via la véritable passerelle de soumission — l’eCTD (electronic Common Technical Document) — et les a fait évaluer, et un écosystème R open source couvre désormais l’ensemble du pipeline. Cette leçon est la carte honnête de cette évolution : pourquoi SAS était la norme, ce qui a réellement changé, ce qui reste identique, et ce que cela signifie pour vous qui apprenez ce pilier.

Le flux de données d’un essai clinique a suivi un point de données à travers le flux en cinq étapes (CRF → SDTM → ADaM → TLF → soumission) ; le contexte réglementaire a couvert les régulateurs et pourquoi CDISC (le Clinical Data Interchange Standards Consortium) est obligatoire ; le cadre de l’estimande a défini la question clinique ; les standards CDISC ont cartographié les standards eux-mêmes. Cette leçon clôt les fondations en répondant à la question que tout nouveau venu pose : puis-je vraiment faire cela en R ? La réponse courte est oui — et le reste du pilier vous montre comment.

Aucun outil à installer — cette leçon est la carte honnête, pas une mise en pratique ; le travail pratique sur R et le pharmaverse commence dans les séries qui suivent.

Pourquoi SAS était la norme

SAS n’a pas conquis la programmation clinique par la réglementation. Il l’a emporté par inertie et écosystème, et cette inertie était rationnelle :

Il est arrivé en premier et n’est jamais parti. SAS était l’outil établi lorsque CDISC et les soumissions électroniques ont pris forme, si bien que les processus, les bibliothèques de macros validées, les procédures opératoires standard et la familiarité des évaluateurs se sont tous construits autour de lui.
Un outillage validé et supporté. Un environnement réglementé valorise les logiciels dotés d’une validation formelle, d’un support éditeur et d’un long historique. SAS offrait exactement cela, ce qui en faisait le choix institutionnel à faible risque.
Une main-d’œuvre formée et une boucle de recrutement. Les programmeurs étaient formés à SAS, donc les promoteurs embauchaient pour SAS, donc la génération suivante apprenait SAS. La convention se renforçait d’elle-même.

Le point crucial — et celui que la plupart des nouveaux venus comprennent de travers — est qu’aucun de ces éléments n’était une exigence légale. Il n’existe aucune règle disant « soumettez en SAS ». C’était une valeur par défaut profondément ancrée, pas un mandat. Cette distinction est la porte que le reste de cette leçon franchit.

Ce qui a changé : la FDA accepte R

Commencez par le régulateur, car tout le reste en dépend. La position de la FDA est explicite et l’est depuis des années : elle n’exige aucun logiciel statistique particulier. Sa Déclaration de clarification sur les logiciels statistiques (mai 2015) indique que l’agence « n’exige l’utilisation d’aucun logiciel particulier pour les analyses statistiques », à condition que le logiciel utilisé soit « entièrement documenté dans la soumission, y compris l’identification de la version et du build. »

Lisez cela attentivement, car il est facile de sur-interpréter ou de sous-interpréter :

R n’a jamais été interdit. La croyance « vous devez utiliser SAS » est un mythe tenace, pas une réglementation. Ce que la FDA exige, c’est une soumission conforme — les bons jeux de données CDISC, les métadonnées, la documentation, un résultat reproductible — quel que soit le langage qui l’a produit.
« Accepter » n’est pas « avaliser ». La FDA n’adoube ni R, ni aucun outil, comme préféré. Elle accepte les soumissions qui satisfont à ses exigences. La charge incombe au promoteur de documenter l’environnement de calcul et de montrer que les résultats sont reproductibles. R franchit cette barre ; il ne reçoit pas de passe-droit parce qu’il est open source.

La porte réglementaire était donc ouverte. Ce qui a manqué longtemps, c’était la preuve qu’un véritable package R de bout en bout pouvait la franchir — et une boîte à outils suffisamment mature pour en construire un.

Ce qui l’a prouvé : les pilotes du R Consortium

La preuve est venue du R Submissions Working Group du R Consortium — une collaboration ouverte et inter-industries qui a mené l’expérience évidente : construire des packages de soumission entièrement en R et les envoyer à la FDA via la véritable passerelle eCTD, à découvert, avec chaque artefact publié sur GitHub. Ils ont mené une série de projets pilotes, chacun prolongeant le précédent :

Pilot 1 — a soumis les tableaux, listings et figures (TLF) sous forme de scripts R, montrant que R pouvait produire des sorties d’analyse conformes.
Pilot 2 — a ajouté une application R Shiny, testant si des applications de revue interactives pouvaient figurer dans une soumission.
Pilot 3 — le jalon : le premier package basé sur R publiquement disponible qui inclut des jeux de données ADaM et des TLF, tous deux générés en R. Il est passé par la passerelle eCTD, et après évaluation la FDA a accepté et reproduit les résultats, émettant sa lettre de réponse finale en 2024.
Pilot 4 et au-delà — ont poussé vers des technologies plus récentes (Shiny empaqueté avec WebAssembly et des conteneurs Linux pour une revue autonome et reproductible), avec d’autres projets pilotes en cours.

Au fil des projets pilotes, le groupe de travail a délibérément construit les sorties avec différents packages R open source, et le personnel de la FDA a reproduit avec succès les résultats de chacun. C’est le cœur de la preuve : non pas un diaporama soutenant que R pourrait fonctionner, mais un véritable package qu’un régulateur a réellement évalué et reproduit. Parce que chaque artefact est public, ils font aussi office de plan de référence pour la forme d’une soumission basée sur R.

Une mise en garde honnête à propos des projets pilotes

Ce sont des soumissions de test réalisées par un groupe de travail, et non des approbations d’un médicament commercialisé. Elles établissent le chemin et le précédent — la FDA évaluant et reproduisant un package tout-R — et non une garantie que la soumission de tel ou tel promoteur passera sans encombre. Le promoteur reste responsable de la conformité, de la documentation et de la validation. Ce qui a changé, c’est que le chemin est désormais prouvé et public, et non hypothétique.

Les projets pilotes dessinent une chronologie simple et honnête :

Pilot	Livré	Jalon
Pilot 1	Tableaux, listings et figures (TLF) sous forme de scripts R	R produit des sorties d’analyse conformes
Pilot 2	Une application R Shiny	Applications de revue interactives dans une soumission
Pilot 3	Premier package R public avec ADaM + TLF	La FDA a accepté et reproduit les résultats
Pilot 4	Shiny empaqueté via WebAssembly / conteneurs	Revue autonome et reproductible

Lisez la colonne Livré de haut en bas et la trajectoire est claire : chaque projet pilote ajoute une pièce de la véritable soumission jusqu’à ce que, avec Pilot 3, le package inclue les jeux de données d’analyse eux-mêmes — la partie que tout le monde supposait devoir être en SAS.

Ce qui l’a rendu pratique : le pharmaverse

L’acceptation réglementaire ouvre la porte ; il faut encore des outils pour la franchir. C’est le pharmaverse — « un réseau connecté d’entreprises et d’individus œuvrant à promouvoir le développement collaboratif de packages R open source organisés pour le reporting clinique. » Ce n’est pas un seul package mais une collection organisée et gouvernée (soutenue par PHUSE, décidée à découvert via GitHub et un conseil communautaire), et elle couvre l’ensemble du pipeline que vous avez rencontré dans le flux de données d’un essai clinique et les standards CDISC :

SDTM — sdtm.oak (un framework, issu à l’origine de Roche, pour mapper les données brutes vers les domaines SDTM), avec des données d’exemple synthétiques dans pharmaversesdtm.
ADaM — admiral, qui fournit des dérivations standardisées et modulaires pour construire les jeux de données ADSL, BDS et OCCDS ; données d’exemple dans pharmaverseadam.
Métadonnées / spécifications — metacore et metatools, qui portent les spécifications de vos jeux de données et alimentent Define-XML.
Tableaux, listings et figures — rtables, tern (tableaux et graphiques d’analyse clinique, y compris les sorties de survie), tidytlg et gtsummary.
Export XPT — xportr, qui met les jeux de données au format SAS Transport v5 (.xpt) qu’exigent les agences, avec les bons types, longueurs et libellés.
Revue interactive — teal, un framework Shiny pour les applications de revue exploratoire qu’une équipe (ou un évaluateur) utilise sur les données.

Parce que ce sont des outils de qualité production et gouvernés par l’industrie — et non des projets de loisir — le résultat est un chemin R crédible et auditable, des données brutes jusqu’à un package de soumission. Ce pilier enseigne ce chemin avec ces outils.

Ce qui reste identique : les standards

Voici la partie qui devrait rassurer quiconque a investi des années dans CDISC : l’évolution porte sur l’outil, pas sur les règles. Tout ce qui provient des leçons de fondations précédentes est indépendant du langage et ne change pas :

SDTM tabule toujours les données collectées dans les mêmes domaines fixes (DM, AE, VS, …).
ADaM dérive toujours les mêmes jeux de données prêts pour l’analyse et traçables (ADSL, ADAE, BDS, OCCDS).
Controlled Terminology, Define-XML, les guides de l’évaluateur cSDRG/ADRG, et le package eCTD sont exactement tels que les leçons de fondations précédentes les ont décrits.
Les exigences des régulateurs — conformité, traçabilité, documentation — sont inchangées.

R est simplement une autre manière de produire les mêmes sorties conformes. Pilot 3 le rend concret : il a généré des jeux de données ADaM standard et leurs métadonnées en R, et un évaluateur les a lus à travers le même Define-XML que définissent les standards. Vos connaissances CDISC ne sont donc pas menacées par un passage à R — c’est la partie qui se transfère complètement. Vous changez le comment, pas le quoi.

La réalité honnête : une évolution, pas un remplacement total

Il serait facile — et faux — de lire tout cela comme « SAS est fini ». Ce n’est pas le cas, et vous devriez entendre la version nuancée, car elle façonne votre manière de travailler concrètement :

SAS reste solidement implanté. Des décennies de macros validées, de SOP, d’études historiques et de personnel formé ne disparaissent pas. Pour de nombreux promoteurs, SAS demeure l’épine dorsale du travail à forte charge de conformité, et c’est encore la compétence la plus demandée dans les offres d’emploi.
La plupart des structures réelles sont hybrides. Le schéma courant est SAS pour les parties critiques pour la stabilité (souvent la génération d’ADaM et de TLF dans les processus établis) et R pour l’innovation — création de SDTM, applications de revue Shiny interactives, QC et double programmation, analyse exploratoire. Les deux coexistent ; de nombreuses équipes utilisent R pour vérifier indépendamment les sorties SAS, et inversement.
L’adoption de R progresse, sans être totale. La trajectoire est réelle — l’acceptation réglementaire est acquise, le pharmaverse continue de mûrir, les CRO affichent de plus en plus une expertise R — mais c’est une migration en cours, mesurée en années, et non un basculement achevé.

Le résumé exact : R est désormais une option à part entière, acceptée par les régulateurs pour la programmation clinique, se tenant aux côtés de SAS dans un domaine qui se rééquilibre progressivement. C’est une position véritablement bonne pour se former — la demande de personnes capables de faire du R conforme augmente précisément parce que l’évolution est réelle mais incomplète.

Ce que cela signifie pour vous

Assemblez les pièces et la conclusion pour un apprenant est directe : vous pouvez faire un véritable travail de soumission en R open source, et ces compétences sont recherchées. Le régulateur l’accepte, les projets pilotes ont prouvé le chemin, le pharmaverse fournit les outils, et vos connaissances CDISC se transmettent inchangées.

C’est la prémisse de tout ce pilier. La série pratique à venir — construire des domaines SDTM, dériver des jeux de données ADaM avec admiral, produire des TLF, exporter du XPT avec xportr, et empaqueter le tout vers une soumission adossée à Define-XML — enseigne exactement le workflow que les projets pilotes ont démontré. Si vous venez de SAS, vous conservez votre expertise CDISC et apprenez les idiomes R comme l’équivalent du DATA step et de vos PROC. Si vous êtes novice, vous apprenez la voie moderne et ouverte dès le départ. Dans les deux cas, les fondations gratuites sont le cadre, et le reste du pilier est le travail.

🟢 Avec un agent IA

Demandez à Prova « R est-il vraiment accepté par la FDA pour les soumissions d’essais cliniques, et qu’ont prouvé les pilotes du R Consortium ? » — 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 →

Problèmes fréquents

Ce sont les idées fausses qui font trébucher les gens lorsqu’ils entendent parler pour la première fois de l’évolution de SAS vers R.

Croire que la FDA « impose SAS » — ou, à l’inverse, qu’elle « approuve R ». Ni l’un ni l’autre n’est vrai. La FDA n’exige aucun logiciel particulier ; elle exige une soumission conforme, documentée, reproductible. SAS était une convention, pas une règle, et R est accepté lorsqu’il satisfait aux exigences — pas préféré. Affirmez exactement cela et rien de plus.

Penser que l’adoption de R signifie abandonner CDISC. C’est l’inverse — CDISC est la partie qui ne change pas. SDTM, ADaM, Define-XML et le package eCTD sont indépendants du langage ; R produit simplement les mêmes sorties conformes. Vos connaissances des standards sont la chose la plus transférable que vous possédiez.

Lire « les projets pilotes ont réussi » comme « toute soumission R est approuvée ». Les projets pilotes sont des soumissions de test qui ont prouvé le chemin — la FDA évaluant et reproduisant un package tout-R. Ce ne sont pas une garantie pour la soumission d’un produit commercialisé donné, où le promoteur reste responsable de la conformité, de la validation et de la documentation. Le chemin est prouvé ; le travail reste le travail.

Questions fréquentes

La FDA accepte-t-elle les soumissions d’essais cliniques réalisées avec R ?

Oui. La FDA n’exige aucun logiciel statistique particulier — sa Déclaration de clarification sur les logiciels statistiques de 2015 le dit — du moment que le logiciel utilisé est entièrement documenté (y compris la version et le build). Ce qu’elle exige, c’est une soumission conforme et reproductible, quel que soit le langage. Les pilotes du R Consortium l’ont confirmé en pratique en soumettant des packages tout-R via la véritable passerelle eCTD et en les faisant évaluer.

Un package tout-R a-t-il réellement été soumis à la FDA et évalué par elle ?

Oui — via le R Submissions Working Group du R Consortium. Pilot 3 a livré le premier package basé sur R publiquement disponible incluant des jeux de données ADaM ainsi que des tableaux et figures, tous générés en R ; il est passé par la passerelle eCTD et la FDA a accepté et reproduit les résultats, émettant sa réponse en 2024. Des projets pilotes ultérieurs ont ajouté des applications Shiny et la technologie WebAssembly/conteneurs. Chaque artefact est public sur le GitHub du R Consortium.

Qu’est-ce que le pharmaverse ?

Le pharmaverse est un ensemble organisé et gouverné par la communauté de packages R open source pour le reporting clinique, soutenu par PHUSE. Ce n’est pas un seul package mais un écosystème connecté couvrant le pipeline : sdtm.oak (SDTM), admiral (ADaM), metacore/metatools (métadonnées), rtables/tern/gtsummary (tableaux et figures), xportr (export XPT) et teal (applications de revue interactives). C’est ce qui rend praticable un workflow de soumission R de bout en bout.

Si nous passons à R, les standards CDISC changent-ils ?

Non. SDTM, ADaM, Define-XML, Controlled Terminology et le package eCTD sont indépendants du langage — ils sont définis par CDISC et les régulateurs, pas par SAS ou R. R produit les mêmes jeux de données et métadonnées conformes qu’un évaluateur attend. Vos connaissances CDISC se transfèrent complètement ; seul l’outil qui construit les jeux de données change.

SAS est-il en train d’être remplacé par R en programmation clinique ?

Pas entièrement. SAS reste solidement implanté — macros validées, SOP, études historiques et une vaste main-d’œuvre formée — et c’est encore la compétence la plus demandée dans les offres d’emploi. Le tableau réaliste est hybride : de nombreuses structures utilisent SAS pour le travail ADaM/TLF critique pour la stabilité et R pour SDTM, les applications de revue Shiny, le QC et l’analyse exploratoire. L’adoption de R progresse, sans être totale — une évolution continue vers la coexistence, et non un basculement achevé.

Je suis programmeur SAS — mon expérience compte-t-elle encore ?

Elle compte pour beaucoup. La connaissance la plus durement acquise et la plus transférable en programmation clinique est CDISC et le processus réglementaire, et rien de cela ne change. Passer à R signifie apprendre les idiomes R comme les équivalents du DATA step et de vos PROC, avec admiral jouant le rôle d’une bibliothèque de macros de dérivation validée. La demande de programmeurs qui connaissent CDISC et savent travailler en R augmente précisément parce que l’évolution est réelle mais incomplète.

Testez vos connaissances

À votre tour : distinguer le fait du mythe

Pour chaque affirmation, décidez si elle est exacte ou s’il s’agit d’un mythe, et dites pourquoi en une ligne :

« La FDA exige que les soumissions soient programmées en SAS. »
« Les pilotes du R Consortium ont prouvé qu’un package tout-R — incluant des jeux de données ADaM — peut être soumis à la FDA et reproduit par elle. »
« Passer à R signifie réapprendre les standards CDISC, car SDTM et ADaM sont différents en R. »
« SAS est fini ; l’industrie est entièrement passée à R. »

Indice

Deux de ces affirmations exagèrent (l’une en faveur de SAS, l’autre en faveur de R), une est un jalon factuel, et une confond l’outil avec les standards.

Solution

Mythe. La FDA n’exige aucun logiciel particulier ; SAS était une convention, pas une règle. Les soumissions doivent être conformes et documentées, dans n’importe quel langage.
Exact. C’est exactement ce que Pilot 3 a démontré — le premier package R public avec ADaM + TLF, accepté et reproduit par la FDA.
Mythe. Les standards CDISC sont indépendants du langage ; SDTM et ADaM sont identiques quel que soit l’outil. Vous apprenez des idiomes R, pas de nouveaux standards.
Mythe (exagéré dans l’autre sens). SAS reste solidement implanté et la plupart des structures sont hybrides ; l’adoption de R progresse, sans être totale. C’est une évolution vers la coexistence, pas un remplacement achevé.

Vérification rapide : quelle est la position réelle de la FDA sur R ?

A. La FDA approuve R comme son logiciel préféré pour les soumissions d’essais cliniques. B. La FDA interdit R ; les soumissions doivent être en SAS. C. La FDA n’exige aucun logiciel particulier et accepte les soumissions R qui satisfont à ses exigences (conformes, documentées, reproductibles).

Afficher la réponse

C. La déclaration de clarification de la FDA est explicite : elle n’exige aucun logiciel statistique particulier, du moment que ce qui a été utilisé est entièrement documenté. A l’exagère — la FDA accepte le R conforme, elle ne l’approuve pas et ne le préfère pas. B est le mythe tenace — SAS était une convention, jamais une réglementation.

Références

Les affirmations porteuses de cette leçon proviennent de sources primaires — lisez-les directement :

La FDA n’exige aucun logiciel particulier. U.S. Food and Drug Administration, Statistical Software Clarifying Statement (mai 2015) : l’agence « n’exige l’utilisation d’aucun logiciel particulier pour les analyses statistiques », à condition que le logiciel soit entièrement documenté (y compris la version et le build). La publication originale de la FDA n’est plus en ligne ; la déclaration est documentée dans le R: Regulatory Compliance and Validation Issues de la R Foundation — https://www.r-project.org/doc/R-FDA.pdf.
Le R Submissions Working Group du R Consortium (tous les projets pilotes, artefacts publics) — https://github.com/RConsortium/submissions-wg.
Pilot 3 — la FDA a accepté et reproduit un package tout-R avec ADaM + TLF. R Consortium, News from R Submissions Working Group – Pilot 3 Successfully Reviewed by FDA (2024) — https://r-consortium.org/posts/news-from-r-submissions-working-group-pilot-3/.
Pilot 4 — Shiny via WebAssembly et conteneurs, soumis à travers la passerelle eCTD. R Consortium, Pilot 4 Successfully Submitted to FDA CDER (2024) — https://r-consortium.org/posts/using-r-to-submit-research-to-the-fda-pilot-4-successfully-submitted/.
Pilot 5 et au-delà — projets pilotes en cours (p. ex. Dataset-JSON). R Consortium, R Submissions Working Group: Pilot 5 Launch and more! — https://r-consortium.org/posts/submissions-wg-pilot5-pilot6-and-more/.
Le pharmaverse — un ensemble organisé, soutenu par PHUSE, de packages R open source pour le reporting clinique — https://pharmaverse.org/.

Conclusion

Le passage de SAS à R en programmation clinique est réel, mais il se comprend mieux avec précision. SAS est devenu la valeur par défaut par inertie et écosystème, jamais par la réglementation — et le régulateur a depuis longtemps clairement indiqué qu’il n’exige aucun logiciel particulier, seulement une soumission conforme et documentée. Les pilotes du R Consortium ont transformé cette porte ouverte en un chemin prouvé et public, le package tout-R de Pilot 3 incluant des jeux de données ADaM accepté et reproduit par la FDA. Le pharmaverse fournit les outils de qualité production pour parcourir ce chemin de bout en bout. Et à travers tout cela, les standards CDISC ne changent pas — seul l’outil qui construit les jeux de données change. Le cadrage honnête est la coexistence : SAS reste répandu, la plupart des structures sont hybrides, et l’adoption de R progresse — ce qui fait du R conforme une compétence véritablement précieuse à développer.

Cela clôt les fondations. Vous disposez maintenant de tout le cadre : le flux de données, le contexte réglementaire, l’estimande qui définit la question, les standards CDISC qui façonnent les données, et la voie R open source qui implémente l’ensemble. La série pratique à venir — construire des domaines SDTM, dériver des ADaM avec admiral, produire des tableaux et figures, et empaqueter une soumission — c’est là que vous réalisez le travail que les projets pilotes ont démontré, sur de vraies données d’exemple.

Leçons connexes

Flux de données d’un essai clinique : du CRF à SDTM, ADaM, TLF et la soumission — le pipeline que les outils du pharmaverse implémentent, de bout en bout. · Contexte réglementaire : FDA, ICH, eCTD — pourquoi la FDA exige la conformité, et pourquoi « accepte R » est précis. · Estimandes (ICH E9(R1)) — le cadre qui décide des analyses que vous construisez, dans n’importe quel langage. · Les standards CDISC : CDASH, SDTM, ADaM, Define-XML — les standards indépendants du langage qui ne changent pas lorsque vous passez à R.
Où cela s’inscrit : développement du médicament et flux de données → contexte réglementaire → estimandes (ICH E9(R1)) → les standards CDISC → l’évolution de SAS vers R (vous êtes ici) — la clôture des fondations gratuites, avant les séries pratiques SDTM, ADaM et TLF qui construisent de vrais jeux de données avec le pharmaverse.

Cette page vous a-t-elle été utile ?

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {De SAS à R en programmation clinique : ce qui change, ce qui
    reste},
  date = {2026-06-30},
  url = {https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/05-sas-to-r},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“De SAS à R en programmation clinique : ce qui change, ce qui reste.” 2026. June 30. https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/05-sas-to-r.