La boucle de rétroaction dont tout le monde parle et que personne ne construit
La logique de la drug discovery assistée par IA est largement comprise : générer des designs moléculaires, les tester expérimentalement, réinjecter les résultats dans le modèle pour améliorer la génération suivante. Ce cycle design-build-test-learn est la base de la plupart des pitchs de plateformes dans ce domaine.
Ce que le pitch inclut rarement, c'est l'infrastructure de données nécessaire pour faire tourner le cycle à vitesse. Concrètement, les résultats expérimentaux doivent arriver dans un format que le modèle peut consommer, sans transformation manuelle. Si un scientifique doit reformater une sortie de lecteur de plaques en CSV correspondant au schéma attendu par le modèle, le cycle n'est pas de quelques heures. Il est de plusieurs jours.
Les résultats doivent aussi être liés au design moléculaire spécifique qui les a générés. Si la traçabilité entre un composé et son résultat d'essai n'est pas suivie automatiquement, vous ne pouvez pas faire confiance au fait que le modèle apprend du bon signal. Les expériences échouées doivent être suivies aussi soigneusement que les réussites : un modèle qui ne voit que des résultats positifs apprend une vision biaisée de l'espace de design. Et le modèle doit savoir sur quelle version des données expérimentales il a été entraîné, pour pouvoir auditer son comportement quand un résultat semble inattendu.
La question qui révèle l'écart
« Si je réentraîne le modèle aujourd'hui, quels résultats expérimentaux va-t-il apprendre, et comment sais-je lesquels manquent ? » Si cette question exige une conversation avec l'analyste qui gère la base de données, le pipeline n'est pas ML-ready.
Où les programmes IA en biologie perdent réellement du temps
Les modes d'échec sont cohérents à travers des programmes de tailles et d'aires thérapeutiques différentes.
La fragmentation des formats. Les données expérimentales viennent de multiples instruments — spectromètres de masse, lecteurs de plaques, séquenceurs, systèmes d'imagerie — chacun avec son propre format d'export. Le pipeline pour harmoniser ces formats a été construit progressivement par des personnes différentes et n'est pas documenté. Ajouter un nouveau type d'essai exige une nouvelle intégration ad hoc qui prend plus de temps que prévu et casse quelque chose en amont. Chaque nouvel instrument est une nouvelle source de dette technique.
Le lien manquant entre design et résultat. Un composé a été conçu par le modèle, synthétisé, testé dans un essai, et le résultat a été enregistré dans le LIMS. Mais l'enregistrement LIMS ne contient pas de référence à la version du modèle qui a conçu le composé, à l'itération de design dont il faisait partie, ni aux paramètres de design spécifiques utilisés. Le résultat existe. Sa provenance, non. Le modèle apprend de données qu'il ne peut pas attribuer.
Des métadonnées au niveau expérience non collectées. La température était décalée de deux degrés sur une plaque. Un lot de réactif a changé entre les batches. Un opérateur différent a mené l'essai. Ces variables ne sont pas suivies parce qu'elles semblent être du bruit. Mais dans un système d'apprentissage, la variance inexpliquée dans les résultats expérimentaux est du bruit que le modèle va tenter d'ajuster et échouer à ajuster, parce qu'il n'a pas accès aux variables qui l'expliquent. Les métadonnées collectées de façon cohérente ne sont pas de la surcharge. Ce sont du signal.
Ce que signifient réellement des données expérimentales ML-ready
Des données ML-ready ne sont pas des données propres. Ce sont des données aux propriétés connues. La distinction compte parce que « nettoyer » implique de retirer des problèmes après coup. Des propriétés connues signifie que les données ont été collectées et structurées pour que leurs limites soient explicites dès le départ.
Concrètement, des données expérimentales ML-ready ont quatre propriétés. Chaque point de données a un enregistrement de provenance : quel composé, quel essai, quel instrument, quelle version de protocole, quel opérateur, quelle date. Les valeurs manquantes sont explicites, pas absentes : un résultat d'essai manquant parce que l'échantillon a échoué au QC est différent d'un résultat manquant parce que l'essai n'a jamais été mené, et les deux doivent être représentables et distinguables. Le design expérimental est encodé dans la structure des données, pas implicite dans le nom de fichier : une courbe dose-réponse est un enregistrement structuré avec des niveaux de concentration explicites, une variable de réponse et des paramètres d'ajustement de courbe, pas un CSV avec des noms de colonnes que seul l'analyste original comprend. Et le dataset est versionné : si vous réentraînez le modèle sur des données expérimentales mises à jour, vous devez savoir ce qui a changé entre la version précédente et la version actuelle.
La dimension organisationnelle
Le pipeline de données expérimentales vit à la frontière entre wet lab et dry lab. Les scientifiques wet lab possèdent la génération de données. Les scientifiques dry lab possèdent le modèle. Aucun des deux groupes ne possède typiquement le pipeline entre eux.
Dans les équipes sans data engineer dédié, ce pipeline est assemblé par celui qui est le plus proche des deux groupes : souvent un biologiste computationnel avec de solides compétences en biologie et des compétences raisonnables en code, mais qui n'est pas principalement embauché pour construire de l'infrastructure de données. Le résultat est un pipeline qui fonctionne assez bien pour l'expérience en cours mais accumule de la dette technique à chaque nouveau type d'essai, chaque nouvel instrument et chaque nouvelle architecture de modèle.
Le coût de cette dette se cumule. Chaque nouvelle intégration prend plus de temps que la précédente parce que le pipeline existant est moins cohérent. Chaque nouvelle version de modèle exige plus de préparation manuelle des données. Chaque nouveau type d'expérience exige une négociation entre le format wet lab et l'attente dry lab.
Un investissement modeste et ciblé dans la standardisation du pipeline — un ou deux sprints focalisés — élimine typiquement l'essentiel de cette dette. Le pipeline résultant n'est pas complexe. Il est ennuyeux. C'est exactement le but. Un pipeline de données doit être une infrastructure ennuyeuse, pas une source de friction scientifique permanente qui ralentit chaque itération de modèle.
À retenir
Dans les programmes de drug discovery pilotés par l'IA, le modèle est rarement le facteur limitant. Le pipeline de données expérimentales l'est. Les trois modes d'échec — fragmentation des formats, traçabilité design-résultat manquante et métadonnées expérimentales non suivies — ont chacun des correctifs spécifiques. Les implémenter n'est pas un problème de modèle. C'est un problème d'infrastructure, et il est résolvable avant la prochaine session d'entraînement.
The feedback loop everyone talks about and nobody builds
The logic of AI-assisted drug discovery is widely understood: generate molecular designs, test them experimentally, feed the results back into the model to improve the next generation. This design-build-test-learn cycle is the basis of most platform pitches in the space.
What the pitch rarely includes is the data infrastructure required to make the cycle run at speed. Specifically, experimental results need to arrive in a format the model can consume, without manual transformation. If a scientist has to reformat a plate reader output into a CSV that matches the model's expected schema, the cycle time is not hours. It is days.
The results also need to be linked to the specific molecular design that generated them. If the provenance between a compound and its assay result is not tracked automatically, you cannot trust that the model is learning from the right signal. Failed experiments need to be tracked as carefully as successful ones: a model that only sees positive results learns a biased view of the design space. And the model needs to know what version of the experimental data it was trained on, so you can audit its behavior when a result looks unexpected.
The question that reveals the gap
"If I retrain the model today, which experimental results will it learn from, and how do I know which ones are missing?" If this question requires a conversation with the analyst who manages the database, the pipeline is not ML-ready.
Where AI biology programs actually lose time
The failure modes are consistent across programs of different sizes and therapeutic areas.
Format fragmentation. Experimental data comes from multiple instruments, mass spectrometers, plate readers, sequencers, imaging systems, each with its own export format. The pipeline to harmonize these formats was built incrementally by different people and is not documented. Adding a new assay type requires a new ad hoc integration that takes longer than expected and breaks something upstream. Every new instrument is a new source of technical debt.
The missing link between design and result. A compound was designed by the model, synthesized, tested in an assay, and the result was recorded in the LIMS. But the LIMS record does not contain a reference to the model version that designed the compound, the design iteration it belonged to, or the specific design parameters that were used. The result exists. Its provenance does not. The model is learning from data it cannot attribute.
Experiment-level metadata that was not collected. The temperature was off by two degrees in one plate. A reagent lot changed between batches. A different operator ran the assay. These variables are not tracked because they seem like noise. But in a learning system, unexplained variance in the experimental results is noise the model will try to fit and fail to fit, because it has no access to the variables that explain it. Metadata collected consistently is not overhead. It is signal.
What ML-ready experimental data actually means
ML-ready data is not clean data. It is data with known properties. The distinction matters because "cleaning" implies removing problems after the fact. Known properties means the data was collected and structured so its limitations are explicit from the start.
Practically, ML-ready experimental data has four properties. Every data point has a provenance record: which compound, which assay, which instrument, which protocol version, which operator, which date. Missing values are explicit, not absent: a missing assay result because the sample failed QC is different from a missing result because the assay was never run, and both need to be representable and distinguishable. The experimental design is encoded in the data structure, not implicit in the filename: a dose-response curve is a structured record with explicit concentration levels, response variable, and curve fit parameters, not a CSV with column names that only the original analyst understands. And the dataset is version-controlled: if you retrain the model on updated experimental data, you need to know what changed between the previous version and the current one.
The organizational dimension
The experimental data pipeline lives at the boundary between wet lab and dry lab. Wet lab scientists own the data generation. Dry lab scientists own the model. Neither group typically owns the pipeline between them.
In teams without a dedicated data engineer, this pipeline is assembled by whoever is closest to both groups: often a computational biologist with strong biology skills and reasonable coding skills, but who is not primarily hired to build data infrastructure. The result is a pipeline that works well enough for the current experiment but accumulates technical debt with every new assay type, every new instrument, and every new model architecture.
The cost of this debt compounds. Each new integration takes longer than the last because the existing pipeline is less coherent. Each new model version requires more manual data preparation. Each new experiment type requires a negotiation between the wet lab format and the dry lab expectation.
A small, focused investment in pipeline standardization, one or two focused sprints, typically eliminates most of this debt. The resulting pipeline is not complex. It is boring. That is exactly the point. A data pipeline should be boring infrastructure, not a source of ongoing scientific friction that slows down every model iteration.
Key takeaway
In AI-driven drug discovery programs, the model is rarely the limiting factor. The experimental data pipeline is. The three failure modes, format fragmentation, missing design-to-result provenance, and untracked experiment-level metadata, each have specific fixes. Implementing them is not a model problem. It is an infrastructure problem, and it is solvable before the next model training run.
AM
Aslane Mortreau
Freelance Data & AI specialist working with pharmaceutical, biotech, and cosmetic R&D teams. Statistical modeling, analytical pipelines, and custom applications.