Savoir si un essai est faisable avant même de contacter un seul site

Le protocole est finalisé. Le plan de recrutement est optimiste. Et dans six mois, la première revue de site révèle que deux critères d'exclusion éliminent 70 % des patients éligibles en théorie. Un agent de feasibility confronte les critères à la réalité des populations agrégées bien avant que les premières visites soient programmées — sans présélectionner ni scorer d'individus. Voici à quoi ça ressemble.

En bref
Pour qui : Clinical Operations, étude managers, clinical trial managers
Le problème : les écarts entre faisabilité estimée et recrutement réel découverts trop tard — après les contracts, après la mise en place des sites
Le résultat : une synthèse de faisabilité agrégée par site et par critère, produite avant de verrouiller le design du protocole
Le gain : corrections de critères en amont plutôt qu'en amendement, sélection de sites sur données réelles plutôt qu'intuition

Le quotidien aujourd'hui

La feasibility d'un essai clinique repose encore largement sur deux canaux : les questionnaires envoyés aux investigateurs (« combien de patients pensez-vous recruter par mois ? ») et l'expérience des CTM qui connaissent leurs sites. Les deux sont utiles. Les deux ont le même défaut : ils mesurent des intentions, pas des populations.

Le résultat est prévisible. Un critère d'âge maximum jugé raisonnable au moment de la rédaction du protocole se révèle exclure la majorité des patients réels d'un site. Un critère biologique — valeur de créatinine, stade tumoral, traitement antérieur — jugé standard devient un filtre sévère sur certaines populations. Ces écarts sont découverts en cours de recrutement, souvent au bout de trois à six mois, parfois après l'ouverture de cinq sites.

La correction prend la forme d'un amendement de protocole : plusieurs semaines de délai supplémentaire, un coût réglementaire, et un message envoyé aux autorités qui demande des explications. Le tout pour un ajustement que des données de population disponibles dès le design auraient pu anticiper.

Ce que change l'automatisation

L'agent ne prédit pas le futur du recrutement. Il fait quelque chose de plus simple et de plus fiable : il croise les critères d'éligibilité du protocole avec les caractéristiques agrégées et pseudonymisées des populations de chaque site candidat, et il remonte les critères qui, sur les données réelles disponibles, réduisent fortement le bassin. C'est une analyse de cohérence entre le design et la réalité.

Le workflow combine analyse de données (pattern F) et orchestration multi-étapes (pattern C) : ingestion des critères d'éligibilité sous forme structurée, requête sur les entrepôts de données de santé ou bases de real-world data accessibles, agrégation par site et par critère, puis production d'une synthèse de faisabilité prête à discuter en revue de protocole.

flowchart LR
  P[Protocole<br>critères structurés] --> A[Agent de feasibility<br>croise avec données RWD<br>agrégées / pseudonymisées]
  A --> S[Synthèse par site :<br>population éligible estimée<br>critères limitants]
  S --> R[Revue avec l'équipe :<br>ajustement critères<br>ou ciblage sites]
  R --> D[Design validé<br>avant mise en place]

Ce que vous recevez, concrètement

À l'issue de l'analyse, l'équipe reçoit une fiche de faisabilité agrégée par protocole et par site candidat.

Le gain, chiffré

Pour que ça marche chez vous

Trois points font la différence entre une démo convaincante et un outil sur lequel l'équipe s'appuie vraiment :

• Les données restent agrégées et pseudonymisées — et c'est précisément ce qui rend l'outil fiable et conforme. L'agent travaille sur des caractéristiques de population, jamais sur des dossiers individuels identifiables. Pseudonymisé ne signifie pas anonyme : ces données restent des données personnelles au sens du RGPD, et l'accès à un entrepôt de données de santé réelles est encadré (CNIL, CESREES en France). Ce point se traite en amont, avant tout accès aux données. Sur la question de la classification EU AI Act : tant que l'outil reste une analyse de cohérence au niveau du protocole — sans présélection ni scoring d'individus — il n'a pas la finalité d'un dispositif médical ni d'un système d'aide à la décision clinique individuelle ; c'est ce cadrage de finalité, et non la seule pseudonymisation, qui le tient à l'écart des usages à haut risque. La classification finale dépend de l'implémentation et se tranche au cas par cas. Une analyse agrégée bien construite est plus solide qu'un matching individuel approximatif.
• L'agent éclaire la faisabilité au niveau du protocole — la décision d'inclure un patient reste une décision médicale, toujours. Cet outil n'a pas vocation à présélectionner des individus ni à recommander une inclusion. Il aide à concevoir un protocole dont les critères collent à la réalité d'une population. La frontière est nette, elle doit l'être dès le brief projet.
• La qualité de l'output dépend de la qualité des données sources. Un entrepôt de données hospitalier bien structuré, ou une base RWD avec un codage SNOMED/ICD cohérent, donne des analyses exploitables. Un silo fragmenté donne des chiffres qu'on ne peut pas défendre. Avant de lancer un agent de feasibility, l'audit de la donnée disponible est l'étape non négociable.