Preclinical data for IND/CTA: the 3 mistakes that slow down a submission
Données précliniques pour IND/CTA : les 3 erreurs qui ralentissent une soumission
5 min read5 min de lecture
2025
Aslane Mortreau
TL;DR
Most preclinical data delays before an IND or CTA submission are not caused by the biology. They are caused by how the data was structured - or wasn't. Three recurring patterns account for the majority of these delays, and all three are avoidable with the right architecture from day one.
La plupart des retards sur les données précliniques avant une soumission IND ou CTA ne sont pas causés par la biologie. Ils sont causés par la façon dont les données ont été structurées, ou ne l'ont pas été. Trois patterns récurrents expliquent la majorité de ces retards, et tous sont évitables avec la bonne architecture dès le départ.
Une biotech en transition préclinique/clinique m'a contacté il y a quelques mois avec une situation que je vois régulièrement : leur réunion de type B avec la FDA approchait, les données d'efficacité et de toxicologie étaient solides, mais la préparation du module 2.6 prenait trois fois plus de temps que prévu. Pas à cause de la biologie. À cause des données.
Trois semaines de retard pour reformater des fichiers, recalculer des paramètres PK déjà calculés, et retrouver quelle version d'un tableau avait été utilisée dans quel rapport intermédiaire.
Ce n'est pas un cas isolé. C'est le cas standard dans les équipes early-stage sans biostatisticien ou data manager dédié, qui découvrent les exigences de structuration au moment où elles n'ont plus le temps de les anticiper.
Erreur 1 : des données PK structurées pour soi, pas pour un partenaire
La plupart des équipes précliniques organisent leurs données de pharmacocinétique de façon à ce qu'elles soient lisibles par la personne qui les a produites. C'est naturel. Le problème survient quand ces données doivent être transmises à un CRO, à un partenaire pharma, ou intégrées dans un dossier réglementaire.
Les symptômes typiques : fichiers Excel avec des onglets numérotés sans convention de nommage, unités inconsistantes entre études (ng/mL dans une étude, µg/L dans une autre), colonnes "temps" avec des formats mixtes (0.5, 0h30, 30min dans le même fichier), paramètres NCA recalculés à la main dans des cellules sans traçabilité de la méthode utilisée.
Quand un partenaire pharma ou un reviewer FDA demande les données sources, reformater tout cela prend des semaines et introduit des risques d'erreur au moment où la marge est la plus faible.
La correction n'est pas complexe : un format tabulaire long standardisé, des unités fixées dès le début du programme, et un script NCA reproductible en R ou Python qui documente chaque paramètre calculé avec sa méthode.
C'est ce que les guidelines ICH E3 et M3(R2) attendent implicitement, même si elles ne prescrivent pas le format technique. Un dataset PK bien structuré ressemble à ceci : une ligne par observation, une colonne par variable, des identifiants sujets cohérents, des noms de variables explicites et stables entre études.
Erreur 2 : des rapports d'étude non reproductibles
Le rapport d'étude préclinique est souvent produit en fin de projet, dans l'urgence, à partir de plusieurs sources de données qui ont évolué au fil du temps. Le résultat : un PDF ou un document Word qui contient des chiffres dont personne ne peut garantir qu'ils correspondent aux données sources actuelles.
Ce problème a un nom dans l'industrie : le copy-paste error. Il est documenté dans plusieurs warning letters FDA. Et il est évitable.
La solution est de séparer les données, l'analyse et le rendu. Un pipeline où les données sources sont en lecture seule, l'analyse est scriptée et versionnée, et le rapport est généré automatiquement (avec Quarto, R Markdown, ou un outil équivalent) garantit qu'un rapport peut être régénéré à l'identique six mois plus tard si un reviewer demande une clarification.
Approche
Reproductible
Auditable
Coût de correction
Word + Excel manuel
Non
Non
Élevé
Script R/Python statique
Partiel
Partiel
Moyen
Pipeline scripté + Quarto
Oui
Oui
Faible
Pour une équipe de dix personnes sans data manager, mettre en place ce type de pipeline prend généralement deux à trois jours de travail initial. Le retour sur investissement se mesure à la première demande de clarification d'une agence ou d'un partenaire : au lieu d'une semaine pour reconstruire le cheminement des données, vous régénérez le rapport en une commande.
Erreur 3 : ignorer CDISC jusqu'à ce qu'il soit trop tard
CDISC (et en particulier SEND pour les données précliniques) n'est pas obligatoire pour toutes les soumissions FDA. Beaucoup d'équipes early-stage décident donc de ne pas s'en préoccuper pour l'instant.
Le problème : quand elles arrivent à la phase où CDISC devient nécessaire, ou quand un partenaire pharma l'exige dans ses due diligences, la conversion de données non structurées vers un format SEND représente plusieurs semaines de travail, souvent confiées à un CRO spécialisé à un coût significatif.
Ce que ça change en pratique
La distance entre "données bien structurées non-CDISC" et "données SEND-compatibles" est bien plus courte que la distance entre "Excel mal organisé" et "données SEND-compatibles". Adopter dès le départ des conventions de nommage compatibles CDISC coûte presque rien. La conversion forcée en urgence coûte beaucoup.
Ce n'est pas un argument pour implémenter CDISC complet dès la première étude in vivo. C'est un argument pour adopter des conventions de nommage et une structure tabulaire qui rendront la migration future triviale plutôt que paralysante.
Ce que ça change concrètement
Les équipes qui anticipent ces trois points arrivent à leurs réunions d'agence avec des annexes de données propres, des rapports traçables et une capacité à répondre aux demandes de clarification en heures plutôt qu'en semaines. Elles sont aussi mieux positionnées pour les partenariats avec des grands groupes pharma, qui font systématiquement une data due diligence avant tout accord de licence.
Ce n'est pas une question de ressources. C'est une question d'architecture des données mise en place tôt, quand le programme est encore petit et que le coût de correction est faible.
À retenir
Les trois erreurs (données structurées pour soi, rapports non reproductibles, migration CDISC ignorée) partagent la même cause : des décisions d'architecture reportées à plus tard. Les corriger en amont d'une soumission coûte infiniment moins que de les corriger sous pression réglementaire.
A biotech in preclinical-to-clinical transition reached out a few months ago with a situation I encounter regularly: their Type B meeting with the FDA was approaching, the efficacy and toxicology data were solid, but preparing Module 2.6 was taking three times as long as expected. Not because of the biology. Because of the data.
Three weeks of delay to reformat files, recalculate PK parameters that had already been calculated, and track down which version of a table had been used in which interim report.
This is not an edge case. It is the standard situation in early-stage teams without a dedicated biostatistician or data manager, who discover data structuring requirements at the moment they have the least time to address them.
Mistake 1: PK data structured for yourself, not for a partner
Most preclinical teams organize their pharmacokinetic data in a way that is readable to the person who produced it. That is natural. The problem arises when that data needs to be handed off to a CRO, a pharma partner, or integrated directly into a regulatory dossier.
Typical symptoms: Excel files with numbered tabs and no naming convention, inconsistent units across studies (ng/mL in one study, µg/L in another), time columns with mixed formats (0.5, 0h30, 30min in the same file), NCA parameters recalculated manually in cells with no traceability of the method used.
When a pharma partner or an FDA reviewer requests the source data, reformatting everything takes weeks and introduces error risk at the moment when you have the least margin for error.
The fix is not complex: a standardized long-format table, units fixed at the start of the program, and a reproducible NCA script in R or Python that documents every calculated parameter alongside its method.
This is what ICH E3 and M3(R2) implicitly expect, even if they do not prescribe the technical format. A well-structured PK dataset looks like this: one row per observation, one column per variable, consistent subject identifiers, explicit and stable variable names across studies.
Mistake 2: study reports that cannot be reproduced
The preclinical study report is often produced at the end of a project, under pressure, from multiple data sources that have evolved over time. The result: a PDF or Word document containing numbers that nobody can guarantee correspond to the current source data.
This problem has a name in the industry: the copy-paste error. It is documented in multiple FDA warning letters. And it is entirely avoidable.
The solution is to separate data, analysis, and output. A pipeline where source data is read-only, analysis is scripted and version-controlled, and the report is generated automatically (using Quarto, R Markdown, or an equivalent tool) guarantees that a report can be regenerated identically six months later if a reviewer requests a clarification.
Approach
Reproducible
Auditable
Remediation cost
Manual Word + Excel
No
No
High
Static R/Python script
Partial
Partial
Medium
Scripted pipeline + Quarto
Yes
Yes
Low
For a ten-person team without a data manager, setting up this type of pipeline typically takes two to three days of initial work. The return on investment becomes clear at the first clarification request from an agency or a partner: instead of a week reconstructing the data trail, you regenerate the report with a single command.
Mistake 3: ignoring CDISC until it is too late
CDISC (and specifically SEND for preclinical data) is not mandatory for all FDA submissions. Many early-stage teams therefore decide not to worry about it for now.
The problem: when they reach the stage where CDISC becomes required, or when a pharma partner mandates it during due diligence, converting unstructured data to SEND format represents weeks of work, often delegated to a specialist CRO at significant cost.
What this means in practice
The distance between "well-structured non-CDISC data" and "SEND-compatible data" is far shorter than the distance between "poorly organized Excel" and "SEND-compatible data". Adopting CDISC-compatible naming conventions from day one costs almost nothing. Forced conversion under deadline pressure costs a great deal.
This is not an argument for implementing full CDISC from your first in vivo study. It is an argument for adopting naming conventions and a tabular structure that will make future migration straightforward rather than paralysing.
What this changes in practice
Teams that address these three points arrive at their agency meetings with clean data annexes, traceable reports, and the ability to respond to clarification requests in hours rather than weeks. They are also better positioned for partnerships with large pharma companies, which systematically conduct a data due diligence before any licensing agreement.
This is not a question of resources. It is a question of data architecture implemented early, when the program is still small and the cost of correction is low.
Key takeaway
The three mistakes (data structured for the producer, non-reproducible reports, CDISC migration deferred) share the same root cause: architecture decisions postponed. Fixing them before a submission costs far less than fixing them under regulatory pressure.
Freelance Data & AI specialist working with pharmaceutical, biotech, and cosmetic R&D teams. Statistical modeling, analytical pipelines, and regulatory-ready reporting.
Spécialiste Data & IA freelance travaillant avec des équipes R&D pharmaceutiques, biotech et cosmétiques. Modélisation statistique, pipelines analytiques et reporting réglementaire.