Le problème de la dette reportée
La plupart des biotechs en phase précoce traitent l'infrastructure de données comme un problème de Phase 2. Elles mènent la Phase 1 dans le format livré par le CRO, l'analysent en R ou SAS avec un script custom, et mettent les résultats dans un deck. Le plan est de tout nettoyer avant l'échéance du package Phase 2.
Quand la Phase 2 arrive, le projet de nettoyage est devenu un projet de reconstruction. Le CRO original n'est plus sous contrat. Le script R tourne sur une version de R datant de deux mises à jour. Le dictionnaire de données est dans un onglet d'un tableur que personne n'a ouvert depuis la semaine trois. Et l'analyste qui l'a construit est parti.
C'est le goulot d'étranglement. Pas la science. Les données.
La question qui déclenche la crise
« Pouvons-nous regrouper les données PK de Phase 1 avec les nouvelles cohortes pour le package de soumission Phase 2 ? » Si la réponse implique un projet d'archéologie de données de plusieurs semaines, l'infrastructure de données Phase 1 n'a pas été construite pour la suite.
Ce qu'exige réellement le CDISC et quand cela compte
La FDA attend des datasets conformes CDISC pour les NDA et BLA. Pour les programmes en phase précoce, ce n'est pas une exigence légale stricte. Mais cela façonne comment les relecteurs interagissent avec vos données, et comment vous interagissez avec vos propres données quand vous devez faire quelque chose de non trivial.
Les trois datasets les plus importants pour les programmes pharma en phase précoce sont simples en concept. ADPC est le dataset d'analyse pour les concentrations PK : ce dont dérivent vos sorties NCA. ADPP est le dataset d'analyse pour les paramètres PK : AUC, Cmax, demi-vie et toutes les valeurs dérivées. ADSL est le dataset au niveau sujet : démographie, posologie, bras de traitement et flags pour les populations d'analyse.
Si vous les construisez correctement dès le départ, même sous forme simplifiée, vous gagnez trois choses : la reproductibilité entre analystes, la portabilité entre outils et CRO, et une avance sur les soumissions réglementaires que la plupart des équipes paient en mode crunch juste avant une échéance.
Les trois échecs de données Phase 1 les plus courants
Les mêmes patterns apparaissent régulièrement dans les données cliniques en phase précoce :
Incohérence de nommage des colonnes entre études. L'étude 001 a ANALYTE, l'étude 002 a analyte_name, l'étude 003 a Compound. Les fusionner exige une intervention manuelle à chaque fois. Le correctif est une convention de nommage appliquée dès la première étude et imposée au moment du contrat CRO.
Variables dérivées calculées dans le script d'analyse, pas stockées dans le dataset. Cela signifie que tout changement du script, même mineur, rend les résultats d'il y a six mois non reproductibles sans exécuter l'ancienne version du script, que personne ne trouve. Les variables dérivées qui apparaîtront dans les sorties réglementaires appartiennent au dataset, pas au code d'analyse.
Aucune piste d'audit entre données brutes et valeurs rapportées. Un relecteur demande : d'où vient ce Cmax ? La réponse est « le script » et le script est dans un dossier appelé final_v3_REALLY_FINAL. Un pipeline audit-ready trace chaque valeur rapportée jusqu'à la ligne du dataset et la ligne de code qui l'a produite.
À quoi ressemble le bon niveau à 10 personnes
Vous n'avez pas besoin d'une équipe data engineering pour éviter ces problèmes. Vous avez besoin de trois choses appliquées de façon cohérente dès le début de la première étude.
Une convention de nommage cohérente alignée sur le CDISC dès le jour un. Choisissez des noms de variables alignés CDISC pour vos datasets internes, même avant d'être obligé de les soumettre. Le coût de basculer plus tard est bien plus élevé que celui d'apprendre la convention maintenant. L'écosystème Pharmaverse rend cela pratique pour les équipes R sans background SAS.
Une séparation entre données brutes, données dérivées et valeurs rapportées. Les données brutes sont ce que le CRO livre. Les données dérivées sont ce que produit votre pipeline : populations flaggées, paramètres calculés, valeurs normalisées. Les valeurs rapportées sont ce qui apparaît dans le rapport. Ce doivent être trois artefacts distincts et versionnés, pas trois onglets du même tableur.
Un pipeline qui est du code, pas un tableur. Même un simple document R Markdown ou Quarto, suivi dans Git, est infiniment plus reproductible qu'un classeur Excel chargé de macros. Il s'exécute de la même façon à chaque fois. Il dit exactement ce qu'il fait. Et il peut être remis à la personne suivante, à un CRO ou à un relecteur réglementaire, sans briefing de trois heures.
Le calcul Phase 2
Un programme Phase 2 qui rencontre des problèmes de données au stade du package de soumission perd typiquement quatre à huit semaines. Pour une équipe qui brûle 500 K$ par mois en coûts opérationnels, c'est une erreur de 2 à 4 M$ qui était évitable avec deux mois de travail data en amont en Phase 1.
Plus concrètement : un dataset Phase 1 bien structuré prend six à dix semaines à construire correctement from scratch, pipeline, documentation et QC inclus. Reconstruit à partir d'un dataset legacy mal structuré sous pression d'échéance, avec un CRO qui n'était pas partie prenante du travail original, cela prend deux fois plus longtemps et coûte trois fois plus cher.
Par où commencer
Si vos données Phase 1 sont déjà structurées d'une façon qui vous met mal à l'aise en lisant ceci, le point de départ pratique n'est pas une refonte complète. C'est un audit de données : qu'avez-vous, qu'est-ce qui manque, et que faudrait-il pour rendre la prochaine analyse reproductible par quelqu'un qui n'était pas dans la salle quand la première a été faite.
L'audit fait typiquement émerger trois ou quatre problèmes spécifiques, chacun avec un correctif clair. C'est un projet de deux semaines, pas de six mois. Et c'est un bien meilleur usage de deux semaines maintenant que quatre semaines de pompier dans neuf mois quand le package Phase 2 sera dû.
À retenir
L'argument pour construire une infrastructure de données alignée CDISC en Phase 1 n'est pas le perfectionnisme réglementaire. C'est ne pas payer la taxe du rétrofit au pire moment possible. Un dataset Phase 1 propre prend des semaines à construire. Le reconstruire à partir de données legacy sous pression d'échéance Phase 2 prend des mois. Le calcul est simple.
The deferred debt problem
Most early-stage biotech teams treat data infrastructure as a Phase 2 problem. They run Phase 1 in whatever format the CRO delivers, analyze it in R or SAS with a custom script, and put the results in a slide deck. The plan is to clean it up before the Phase 2 package is due.
By the time Phase 2 arrives, the cleaning project has become a rebuilding project. The original CRO is no longer on contract. The R script runs on a version of R from two updates ago. The data dictionary is in a tab of a spreadsheet that nobody has opened since week three. And the analyst who built it is gone.
This is the bottleneck. Not the science. The data.
The question that triggers the crisis
"Can we pool the Phase 1 PK data with the new cohorts for the Phase 2 submission package?" If the answer involves a multi-week data archaeology project, the Phase 1 data infrastructure was not built for what comes next.
What CDISC actually requires and when it matters
The FDA expects CDISC-compliant datasets for NDAs and BLAs. For early-phase programs it is not a hard legal requirement. But it shapes how reviewers interact with your data, and it shapes how you interact with your own data when you need to do anything non-trivial with it.
The three datasets that matter most for early pharma programs are straightforward in concept. ADPC is the analysis dataset for PK concentrations: what your NCA outputs are derived from. ADPP is the analysis dataset for PK parameters: AUC, Cmax, half-life, and all derived values. ADSL is the subject-level dataset: demographics, dosing, treatment arms, and flags for analysis populations.
If you build these correctly from the start, even in simplified form, you gain three things: reproducibility across analysts, portability across tools and CROs, and a head start on regulatory submissions that most teams pay for in crunch mode just before a deadline.
The three most common Phase 1 data failures
The same patterns appear repeatedly in early-stage clinical data:
Column naming inconsistency across studies. Study 001 has ANALYTE, Study 002 has analyte_name, Study 003 has Compound. Merging them requires manual intervention every time. The fix is a naming convention applied from the first study and enforced at CRO contract time.
Derived variables computed in the analysis script, not stored in the dataset. This means any change to the script, even a minor one, makes results from six months ago non-reproducible without running the old script version, which nobody can find. Derived variables that will appear in regulatory outputs belong in the dataset, not in the analysis code.
No audit trail between raw data and reported values. A reviewer asks: where does this Cmax come from? The answer is "the script" and the script is in a folder called final_v3_REALLY_FINAL. An audit-ready pipeline traces every reported value to the dataset row and the code line that produced it.
What good looks like at 10 people
You do not need a data engineering team to avoid these problems. You need three things applied consistently from the start of the first study.
A consistent naming convention aligned to CDISC from day one. Pick CDISC-aligned variable names for your internal datasets, even before you are required to submit them. The cost of switching later is far higher than the cost of learning the convention now. The Pharmaverse package ecosystem makes this practical for R teams without a SAS background.
A separation between raw data, derived data, and reported values. Raw data is what the CRO delivers. Derived data is what your pipeline produces: flagged populations, computed parameters, normalized values. Reported values are what appears in the report. These should be three distinct, versioned artifacts, not three tabs in the same spreadsheet.
A pipeline that is code, not a spreadsheet. Even a simple R Markdown or Quarto document, tracked in Git, is infinitely more reproducible than a macro-heavy Excel workbook. It runs the same way every time. It tells you exactly what it does. And it can be handed to the next person, or to a CRO, or to a regulatory reviewer, without a three-hour briefing.
The Phase 2 math
A Phase 2 program that hits data problems at the submission package stage typically loses four to eight weeks. For a team burning $500K per month in operational costs, that is a $2M to $4M error that was preventable with two months of upfront data work in Phase 1.
More practically: a well-structured Phase 1 dataset takes six to ten weeks to build correctly from scratch, including the pipeline, the documentation, and the QC. Rebuilt from a poorly structured legacy dataset under deadline pressure, with a CRO who was not part of the original work, it takes twice as long and costs three times as much.
Where to start
If your Phase 1 data is already structured in a way that makes you uncomfortable reading this, the practical starting point is not a full rework. It is a data audit: what do you have, what is missing, and what would it take to make the next analysis reproducible by someone who was not in the room when the first one ran.
The audit typically surfaces three or four specific problems, each with a clear fix. That is a two-week project, not a six-month one. And it is a substantially better use of two weeks now than four weeks of fire-fighting nine months from now when the Phase 2 package is due.
Key takeaway
The argument for building CDISC-aligned data infrastructure in Phase 1 is not about regulatory perfectionism. It is about not paying the retrofit tax at the worst possible moment. A clean Phase 1 dataset takes weeks to build. Rebuilding it from legacy data under Phase 2 deadline pressure takes months. The math is straightforward.
AM
Aslane Mortreau
Freelance Data & AI specialist working with pharmaceutical, biotech, and cosmetic R&D teams. Statistical modeling, analytical pipelines, and custom applications.