Le problème de comparabilité
Tout scientifique en fermentation sait que les résultats à l'échelle banc ne se transfèrent pas simplement à l'échelle pilote. La biologie est la même, mais l'environnement d'ingénierie est différent : dynamique de mélange, transfert d'oxygène, dissipation thermique, contrainte de cisaillement. La réponse standard est un travail de développement de procédé pour adapter le processus à la nouvelle échelle.
Ce qui est moins souvent discuté, c'est le problème de données qui rend ce travail de développement plus difficile qu'il ne devrait l'être. Les KPI mesurés à l'échelle banc ne sont souvent pas comparables aux KPI mesurés à l'échelle pilote, non pas parce que le procédé est différent, mais parce que les données n'ont pas été conçues pour être comparables dès le départ.
À l'échelle banc, les données viennent typiquement d'un contrôleur de bioréacteur, d'un spectrophotomètre, d'un HPLC et d'un tableur où quelqu'un enregistre les valeurs qui ne sortent pas automatiquement des instruments. À l'échelle pilote, les mêmes mesures sont souvent prises avec des instruments différents, à des fréquences différentes, par des opérateurs différents, et stockées dans un système différent.
Quand vous essayez de comparer un run banc de mars à un run pilote d'août, vous comparez des chiffres générés sous des définitions différentes du même KPI. L'oxygène dissous au banc était mesuré toutes les 30 secondes par un capteur polarographique calibré avant chaque run. L'oxygène dissous au pilote était mesuré toutes les cinq minutes par un capteur optique avec un temps de réponse différent. Les chiffres ne désignent pas la même chose, même s'ils partagent un en-tête de colonne.
Ce qui casse réellement dans la décision de scale-up
La conséquence pratique est que les décisions de scale-up sont prises avec moins de confiance qu'il n'y paraît. Une équipe qui conclut que le procédé performe de façon équivalente à l'échelle pilote conclut peut-être en réalité que les chiffres se ressemblent assez, compte tenu du bruit dans la comparaison qu'elle a pu faire.
Ce n'est pas un échec scientifique. C'est un échec d'infrastructure de données. La science est peut-être entièrement correcte. Mais la base de preuve pour la décision de scale-up est plus faible qu'elle ne devrait l'être, parce que la comparaison de données était plus difficile qu'il n'aurait fallu.
Dans un contexte réglementaire — qu'il s'agisse d'un dossier GRAS, d'un package de données de fermentation FDA ou d'une soumission CMC — cela compte considérablement. Un relecteur qui ne peut pas tracer le lien entre les données de caractérisation à l'échelle banc et les paramètres de procédé à l'échelle pilote posera des questions. Si les réponses exigent une reconstruction manuelle de la chaîne de données, c'est du temps et de l'argent non budgétés.
Les trois pratiques qui rendent les données de scale-up comparables
Un schéma de données unifié défini avant le premier run banc. Chaque variable qui sera suivie à toutes les échelles — oxygène dissous, pH, température, agitation, débit d'alimentation, titre, viabilité — reçoit un nom canonique, une unité canonique et une fréquence de mesure canonique. Ce schéma s'applique à chaque échelle. Les écarts sont documentés explicitement, pas enregistrés silencieusement dans une colonne différente d'un tableur différent.
Des définitions de variables indépendantes de l'instrument. L'oxygène dissous n'est pas un chiffre spécifique d'un capteur spécifique. C'est une variable biologique avec une définition opérationnelle : ce qu'elle mesure, comment elle est calibrée, quelle est l'incertitude de mesure. Si la définition opérationnelle change entre échelles, ce changement est enregistré explicitement et pris en compte dans la comparaison. Cela semble évident. En pratique, cela exige que quelqu'un l'écrive avant le premier run à chaque échelle, pas après l'échec de la comparaison.
Un enregistrement de métadonnées de run pour chaque lot. Avant tout run, à toute échelle, un enregistrement est créé qui capture : échelle, ID bioréacteur, opérateur, source d'inoculum, lot de milieu, configuration instrument, version de protocole. Cet enregistrement est lié aux données produites par le lot. Quand vous comparez deux lots six mois plus tard, vous voyez exactement ce qui était identique et ce qui était différent. Sans cet enregistrement, la comparaison repose sur la mémoire, et la mémoire se dégrade.
Le contexte CRO
Pour les équipes qui utilisent des CRO pour le développement en fermentation, le problème de données est amplifié. Le CRO livre des données dans le format que produisent ses systèmes, qui n'est souvent pas celui attendu par les systèmes du client. L'intégration des données CRO dans le dataset interne du client exige une étape de traduction, souvent faite manuellement, par une seule personne, sous pression d'échéance, avec un script que personne d'autre ne peut exécuter.
La meilleure approche est de définir les exigences de format de données avant le début de l'engagement CRO, et de les spécifier dans le cahier des charges. C'est un document de spécification de données de deux pages, pas un projet d'ingénierie complexe. Il établit les conventions de nommage, les exigences d'unités, les champs de métadonnées et le format de livraison. Quand les données arrivent, elles s'intègrent au pipeline du client sans traduction manuelle.
La plupart des clients ne le font pas parce que cela semble être de la surcharge au début d'un engagement. Ce n'en est pas. C'est une surcharge qui, si elle n'est pas payée au début, est payée avec intérêts à la fin — généralement pendant les dernières semaines du projet quand le calendrier est déjà serré.
La dimension reporting
Pour les équipes qui dépendent de financements publics — qu'il s'agisse de subventions DOE, de programmes USDA, de contrats DARPA ou de NIH SBIR — les exigences de reporting des données de fermentation sont réelles et non triviales. Les périodes de reporting des subventions exigent des données d'avancement traçables, cohérentes et vérifiables. Si les données n'ont pas été suivies en pensant au reporting, produire les synthèses requises est un effort manuel significatif qui se répète à chaque cycle de reporting.
La solution est un pipeline de reporting construit en parallèle du pipeline de recherche, pas construit rétrospectivement à partir de données collectées au fil de l'eau. Les variables qui devront apparaître dans les rapports sont identifiées dès la rédaction de la subvention. La collecte de données est conçue pour produire ces variables automatiquement. Le pipeline de reporting les assemble à chaque période sans saisie manuelle.
Pour un rapport à cinq variables généré trimestriellement, c'est une implémentation d'une semaine. Le retour sur investissement sur une période de subvention de deux ans est substantiel, tant en temps analyste économisé qu'en qualité des données qui aboutissent dans les rapports.
À retenir
Les décisions de scale-up en fermentation sont prises avec moins de confiance qu'il n'y paraît parce que les KPI banc et pilote sont rarement comparables par conception. Corriger cela exige trois pratiques : un schéma de données unifié appliqué à chaque échelle, des définitions de variables indépendantes de l'instrument, et un enregistrement de métadonnées de run pour chaque lot. Les trois peuvent être mises en œuvre avant le premier run banc. Aucune ne nécessite de nouveaux instruments ni de nouveaux logiciels.
The comparability problem
Every fermentation scientist knows that bench-scale results do not simply transfer to pilot scale. The biology is the same, but the engineering environment is different: mixing dynamics, oxygen transfer, heat dissipation, shear stress. The standard response is process development work to adapt the process to the new scale.
What is less often discussed is the data problem that makes this process development work harder than it needs to be. The KPIs measured at bench scale are frequently not comparable to the KPIs measured at pilot scale, not because the process is different, but because the data was not designed to be comparable from the start.
At bench scale, data typically comes from a bioreactor controller, a spectrophotometer, an HPLC, and a spreadsheet where someone records the values that do not come out of the instruments automatically. At pilot scale, the same measurements are often taken with different instruments, at different frequencies, by different operators, and stored in a different system.
When you try to compare a bench run from March to a pilot run from August, you are comparing numbers that were generated under different definitions of the same KPI. Dissolved oxygen at bench was measured every 30 seconds by a polarographic sensor calibrated before each run. Dissolved oxygen at pilot was measured every five minutes by an optical sensor with a different response time. The numbers are not the same thing, even though they share a column header.
What actually breaks in the scale-up decision
The practical consequence is that scale-up decisions are made with less confidence than they appear to be. A team that concludes the process performs equivalently at pilot scale may actually be concluding that the numbers look similar enough, given the noise in the comparison they were able to make.
This is not a scientific failure. It is a data infrastructure failure. The science might be entirely correct. But the evidence base for the scale-up decision is weaker than it should be, because the data comparison was harder than it needed to be.
In a regulatory context, whether that is a GRAS dossier, an FDA fermentation data package, or a CMC submission, this matters considerably. A reviewer who cannot trace the connection between bench-scale characterization data and pilot-scale process parameters will ask questions. If the answers require manual reconstruction of the data trail, that is time and money that was not budgeted.
The three practices that make scale-up data comparable
A unified data schema defined before the first bench run. Every variable that will be tracked across scales, dissolved oxygen, pH, temperature, agitation, feeding rate, titer, viability, is given a canonical name, a canonical unit, and a canonical measurement frequency. This schema applies at every scale. Deviations from it are documented explicitly, not recorded silently in a different column in a different spreadsheet.
Instrument-independent variable definitions. Dissolved oxygen is not a specific number from a specific sensor. It is a biological variable with an operational definition: what it measures, how it is calibrated, what the measurement uncertainty is. If the operational definition changes between scales, that change is recorded explicitly and factored into the comparison. This sounds straightforward. In practice it requires that someone writes it down before the first run at each scale, not after the comparison fails.
A run metadata record for every batch. Before any batch runs, at any scale, a record is created that captures: scale, bioreactor ID, operator, inoculum source, medium lot, instrument configuration, protocol version. This record is linked to the data the batch produces. When you compare two batches six months later, you can see exactly what was the same and what was different. Without this record, the comparison relies on memory, and memory degrades.
The CRO context
For teams that use CROs for fermentation development, the data problem is compounded. The CRO delivers data in whatever format their systems produce, which is often not the format the client's systems expect. The integration of CRO data into the client's internal dataset requires a translation step, which is often done manually, by one person, under deadline pressure, using a script that nobody else can run.
The better approach is to define the data format requirements before the CRO engagement begins, and to specify them as part of the statement of work. This is a two-page data specification document, not a complex engineering project. It establishes the naming conventions, the unit requirements, the metadata fields, and the delivery format. When the data arrives, it slots into the client's pipeline without manual translation.
Most clients do not do this because it feels like overhead at the start of an engagement. It is not. It is overhead that, if not paid at the start, is paid with interest at the end, usually during the final weeks of the project when the timeline is already tight.
The reporting dimension
For teams that depend on government funding, whether that is DOE grants, USDA programs, DARPA contracts, or NIH SBIR awards, fermentation data reporting requirements are real and non-trivial. Grant reporting periods require progress data that is traceable, consistent, and verifiable. If the data was not tracked with reporting in mind, generating the required summaries is a significant manual effort that repeats every reporting cycle.
The solution is a reporting pipeline built alongside the research pipeline, not constructed retrospectively from whatever data was collected. The variables that will need to appear in reports are identified at the grant-writing stage. The data collection is designed to produce those variables automatically. The reporting pipeline assembles them at each period without manual data entry.
For a five-variable report generated quarterly, this is a one-week implementation. The return on investment over a two-year grant period is substantial, both in analyst time saved and in the quality of the data that ends up in the reports.
Key takeaway
Fermentation scale-up decisions are made with less confidence than they appear to be because bench and pilot KPIs are rarely comparable by design. Fixing this requires three practices: a unified data schema applied at every scale, instrument-independent variable definitions, and a run metadata record for every batch. All three can be implemented before the first bench run. None of them require new instruments or new software.
AM
Aslane Mortreau
Freelance Data & AI specialist working with pharmaceutical, biotech, and cosmetic R&D teams. Statistical modeling, analytical pipelines, and custom applications.