Dans la pharma et la biotech, la valeur ne réside plus dans un résultat isolé. Elle réside dans votre capacité à réunir les données de nombreuses études, essais et laboratoires en une image analysable. Pour un directeur R&D ou un responsable données, le problème est rarement le manque de données. Le problème, c’est que les données cliniques et de recherche sont dispersées entre des dizaines de systèmes, de formats et d’équipes, et que chaque analyse commence par le travail fastidieux de les recoller.
D’après notre expérience, la difficulté n’est pas de stocker les données mais de construire une intégration reproductible en environnement régulé, sans perdre la qualité ni la piste d’audit. C’est un domaine où nous apportons la compétence plutôt qu’un produit sur étagère : nous dotons le projet de spécialistes du data engineering, de la bio-informatique et du big data qui ont déjà travaillé sous les exigences de la pharma et de la biotech.
Pourquoi les données cliniques et de recherche sont-elles si dispersées et si difficiles à exploiter ?
Parce qu’elles naissent en de nombreux endroits, à des moments différents et selon des standards différents :
- les systèmes EDC et CTMS collectent les données d’essais dans leurs propres schémas,
- les laboratoires et les instruments produisent des résultats au format de l’appareil, pas à celui de l’analyste,
- les équipes de recherche conservent les données dans des tableurs, des cahiers et des bases locales,
- les partenaires externes (CRO, laboratoires sous contrat) livrent les données dans encore d’autres structures.
Résultat : une même variable est décrite de plusieurs façons, et réunir les données prend plus de temps que l’analyse elle-même. L’intégration commence donc par fixer ce que les données signifient, pas par copier des fichiers.
Comment collecter les données des études et des essais cliniques ?
Nous concevons la collecte pour que les erreurs n’entrent pas à la source, car c’est là qu’elles coûtent le plus cher ensuite :
- validation à la saisie, plutôt que nettoyage des données après coup,
- standardisation vers des modèles reconnus (par exemple CDISC/SDTM) dès la collecte,
- extractions automatisées depuis l’EDC, les appareils et les systèmes de laboratoire via des API,
- métadonnées et contexte de l’échantillon enregistrés avec le résultat, et non rattachés à la main.
Ainsi les données arrivent déjà dans une forme que vous pouvez réunir et analyser, et non dans une forme qu’il faut d’abord sauver.
Comment intégrer des données de nombreuses sources en un ensemble cohérent ?
Réunir les sources est le cœur du problème. Nous construisons une couche d’intégration qui transforme le chaos en un modèle unique :
- des pipelines ETL/ELT qui extraient, transforment et chargent les données de chaque source,
- un modèle de données commun et des dictionnaires qui unifient le sens des variables,
- un référentiel central (entrepôt ou data lake) comme source unique de vérité,
- le versionnage et le data lineage, pour que l’on sache d’où vient chaque valeur.
Cette fondation permet d’ajouter de nouvelles sources sans tout réécrire, et donne aux chercheurs des données auxquelles ils peuvent se fier.
Comment organiser l’échange des données de laboratoire ?
Le laboratoire a ses propres formats et ses propres instruments : nous en faisons donc un flux dédié :
- des intégrations avec les LIMS et les systèmes de gestion des échantillons,
- le parsing des sorties d’instruments vers une forme standardisée,
- le mappage des identifiants d’échantillons, de patients et de lots entre les systèmes,
- des contrôles de complétude, pour qu’aucun résultat ne se perde en chemin.
Nous poussons vers l’échange automatisé là où régnaient les exports de fichiers et les e-mails, car c’est précisément là qu’apparaissent les erreurs et les retards.
Comment préparer les cohortes et les jeux de données pour l’analyse ?
Les analystes et les biostatisticiens ont besoin de données prêtes à l’emploi, pas d’un export brut. Nous construisons donc la couche analytique :
- des cohortes définissables construites à partir de critères d’inclusion et d’exclusion,
- des jeux de données prêts pour l’analyse dans une forme fixe et reproductible,
- la pseudonymisation et l’anonymisation là où la protection des données l’exige,
- la documentation des jeux de données, pour que chacun sache exactement ce qu’ils contiennent et comment ils ont été produits.
L’objectif est de ramener le chemin entre une question de recherche et un jeu de données à quelques heures, et non à quelques semaines.
Comment construire les pipelines de résultats statistiques ?
En environnement régulé, la reproductibilité des analyses est une exigence, pas un confort. Nous automatisons donc le chemin des données au résultat :
- des pipelines automatisés en R et Python, exécutés sur des jeux de données figés,
- du code d’analyse versionné, pour qu’un résultat puisse être reproduit des mois plus tard,
- des rapports et des tableaux générés à partir des données, et non assemblés à la main,
- des environnements de calcul qui passent à l’échelle pour de grands jeux de données et de grands modèles.
Avec un tel pipeline, recalculer après une correction de données revient à relancer le processus, et non à y consacrer une semaine de plus.
Comment garantir la qualité des données et la conformité en environnement régulé ?
Dans la pharma et la biotech, la qualité et la conformité ne sont pas une option mais la condition pour qu’un résultat compte. Nous les intégrons au pipeline lui-même :
- une piste d’audit pour chaque modification de données (qui, quand, quoi),
- des contrôles qualité (validations, règles de cohérence) exécutés automatiquement,
- le contrôle des accès et des rôles, aligné sur la protection des données patients,
- la conformité aux exigences telles que les GxP (bonnes pratiques réglementées), le RGPD ou le 21 CFR Part 11, intégrée au processus et non ajoutée à la fin.
Ainsi les données ne sont pas seulement réunies, elles sont aussi défendables en audit.
Quelles compétences apportons-nous à un projet data pharma ?
Nous façonnons l’équipe autour des spécificités du travail sur les données cliniques et de recherche :
- des data engineers qui construisent pipelines, entrepôts et intégrations,
- des bio-informaticiens qui comprennent les données biologiques et leur contexte,
- des spécialistes big data qui traitent de grands jeux de données complexes,
- des analystes et développeurs R/Python qui co-construisent la couche de résultats.
Nos équipes big data et bio-informatique ont déjà travaillé en environnement pharma et biotech régulé : elles arrivent avec la compréhension de ces exigences, au lieu de l’acquérir en route.
Où se place la couche IA, si vous la choisissez plus tard ?
L’IA n’apporte de la valeur qu’une fois les données en ordre : nous la traitons donc comme une couche optionnelle posée sur une fondation mature :
- des modèles prédictifs sur des jeux de données standardisés et réunis,
- la recherche et la structuration de données textuelles (par exemple la documentation de recherche),
- l’assistance aux analystes dans l’exploration de grands jeux de données.
Nous ne commençons pas par l’IA. Nous commençons par des données fiables, car sans elles tout modèle ne fait que répéter les mêmes lacunes.
Comment procédons-nous chez RITS ?
Nous le faisons en tant que partenaire nearshore depuis la Pologne, avec une expérience réelle des projets data et des environnements régulés :
- nous dotons le projet d’une équipe data engineering, bio-informatique et big data adaptée au besoin,
- nous vérifions les compétences avant le démarrage, au lieu d’espérer qu’elles conviendront en route,
- nous relions collecte, intégration et analyse en un ensemble maintenable,
- nous travaillons dans un fuseau horaire proche, pour que l’équipe prenne votre rythme sans longue montée en charge.
Le plus souvent, nous le faisons en renfort d’équipe ou en équipe dédiée, car construire une plateforme data est un travail continu, pas un déploiement ponctuel. Nous avons traité les différences entre les modèles de collaboration dans notre article sur les modèles de collaboration IT.
Par où commencer la collecte et l’intégration des données cliniques ?
Commencez par la jointure de données la plus douloureuse (par exemple relier les résultats de laboratoire aux données d’essai) et par la question du jeu de données analytique qui doit en sortir. Cela définit le périmètre de l’intégration, le modèle de données et les rôles nécessaires. À partir de là, la plateforme data grandit de façon délibérée, et non en collant un export de plus.
Vous collectez et intégrez des données cliniques ou de recherche ? Parlons-en - nous adapterons une équipe et une architecture à vos données.
Construisons avec vous l’intégration des données cliniques et de recherche