MCP et LLM en recherche clinique : piloter un EDC/eCRF par agent IA

Dans un EDC, un assistant qui se contente de répondre à des questions a un intérêt limité. Une équipe data management attend d'un outil qu'il exécute des actions : créer un formulaire, poser une règle de visibilité, ajouter une langue à une étude. Et parce que chaque action sur une étude relève des GCP et du 21 CFR Part 11, cette exécution doit être tracée, attribuée à une personne, et rester en attente tant qu'elle n'a pas été validée.

Le Model Context Protocol (MCP) est le standard qui permet à un LLM comme Claude, ChatGPT, Gemini, Grok ou un modèle local de piloter un EDC sans réécrire une intégration à chaque nouveau besoin. Cet article décrit ce qu'il change par rapport aux API, le principe qui gouverne tout le reste (aucune donnée clinique n'est envoyée au modèle), les cas d'usage où il apporte le plus, et ce qu'il ne permet pas.

Qu'est-ce que le Model Context Protocol ?

Le MCP est un standard ouvert publié par Anthropic fin 2024, repris depuis par la plupart des éditeurs de modèles. Il décrit comment un LLM, que ce soit Claude, ChatGPT, Gemini, Grok ou un autre, découvre et appelle les fonctions d'un logiciel tiers.

Concrètement, un serveur MCP expose un catalogue d'outils : list_studies, get_form_structure, create_item, get_query_stats. Chaque outil a une description et des paramètres. Le modèle lit ce catalogue, reçoit une demande formulée en langage naturel et choisit lui-même les outils à appeler.

Derrière le serveur MCP, ce sont les API REST existantes de l'EDC qui travaillent. Le protocole ne les remplace pas. Il ajoute une couche qui permet à un modèle de les utiliser sans qu'un développeur ait écrit un connecteur pour chaque scénario.

API ou MCP : ce qui change

Les API restent le socle de toute intégration, et Datacapt est construit API-first. Elles sont très bien adaptées aux besoins ponctuels et structurés : un export planifié vers un entrepôt de données, une synchronisation avec un CTMS, un flux de résultats de laboratoire. Le besoin est connu à l'avance, le format aussi, et l'intégration tourne pendant des années.

Leur limite apparaît quand les demandes se multiplient et varient. Chaque nouveau besoin donne lieu à un développement dédié : une intégration pour extraire les métriques d'inclusion d'un centre, une autre pour alerter sur les formulaires en retard, une troisième pour l'export du comité de suivi. Quand le besoin suivant arrive, légèrement différent, le cycle repart.

Avec un serveur MCP, toutes les capacités de l'EDC sont exposées une fois et utilisables immédiatement. L'utilisateur formule sa demande en langage naturel et le modèle l'exécute, en choisissant les bons outils dans le bon ordre.

Le principe qui gouverne tout : aucune donnée clinique n'est envoyée au modèle

Le point de départ est simple. Envoyer des données cliniques à un LLM public, que ce soit Claude, ChatGPT, Gemini, Grok ou un autre, présente un risque que la plupart des promoteurs et des CRO ne peuvent pas prendre : données de santé, identifiants de sujets, éléments de randomisation. Techniquement, on pourrait les faire transiter avec des garanties contractuelles, du chiffrement et un hébergement certifié. Le choix le plus sûr reste de ne rien envoyer du tout. C'est celui qui a été retenu, et tout le reste en découle.

Ce que le modèle reçoit : des comptes, des statuts, des pourcentages, des structures. Le nombre de patients inclus par centre, le taux de SDV, la répartition des queries par ancienneté, la liste des sections d'un formulaire avec leurs règles de validation.

Ce que le modèle ne reçoit jamais : une valeur saisie dans un eCRF, une réponse ePRO, un identifiant de sujet ou de screening, un contenu de consentement, un élément de randomisation. Les endpoints de monitoring qui renvoient des lignes au niveau inclusion sont agrégés par le serveur avant tout envoi. Une ligne brute n'atteint pas le modèle.

Cette règle vaut quel que soit le client. L'agent intégré dans la plateforme et un modèle local branché par l'utilisateur sur son propre client MCP passent par le même serveur, avec les mêmes périmètres. En mode local, ni le prompt ni le modèle ne sont maîtrisés par l'éditeur, donc les garde-fous sont dans le service et non dans les instructions données au modèle. Un périmètre absent ne peut pas être contourné en reformulant la demande.

Et le chiffrement de bout en bout ?

La question revient souvent : ne pourrait-on pas construire une passerelle où les données cliniques transitent chiffrées de bout en bout, de sorte que le modèle les manipule sans jamais les lire en clair ?

Techniquement, oui. Mais un LLM travaille sur du texte lisible. Sur un contenu chiffré, il ne peut ni comparer deux dates, ni repérer une incohérence, ni proposer un code MedDRA. Il transporterait des blocs opaques d'un point à un autre, ce qu'une API fait déjà très bien sans lui. Et déchiffrer côté modèle, même dans un environnement isolé, rouvre exactement la question qu'on voulait fermer.

Le choix est donc de garder les données hors du modèle et d'accepter ce que cela implique.

Ce que cela limite

Il faut le dire clairement : cette architecture ferme certaines portes.

• Pas de query au niveau du sujet. L'agent ne peut pas rédiger « la date de visite V3 du sujet 012 est antérieure à V2 ». Il peut signaler qu'un centre compte douze formulaires incomplets sur la section événements indésirables et préparer un message de relance à l'investigateur. Le contenu de la query au niveau du sujet reste à écrire par le data manager.
• Pas de revue médicale. L'agent ne voit pas les valeurs, donc il ne détecte ni incohérence clinique ni signal de sécurité.
• Pas d'export de données collectées. Les exports MCP se limitent aux structures et aux templates.

Cas d'usage principal : du protocole au study design de l'eCRF

C'est l'usage qui pèse le plus dans le calendrier de lancement d'une étude, et c'est aussi celui que la règle précédente n'affecte pas : concevoir un eCRF ne demande aucune donnée patient.

Passer d'un protocole à un eCRF opérationnel prend plusieurs semaines. La réflexion va vite. Ce qui consomme du temps, c'est la saisie : créer les visites, les formulaires, les champs, les contrôles de cohérence, les conditions d'affichage (« ce bloc n'apparaît que si la patiente est en âge de procréer »), puis rédiger les scénarios de test et les dérouler un par un.

Avec un agent connecté au serveur MCP de l'EDC, le déroulé devient le suivant :

1. L'utilisateur fournit le schedule of assessments. Le tableau suffit. Transmettre les 80 pages du protocole n'améliore pas le résultat et consomme des tokens pour rien.
2. L'agent crée la structure en environnement draft : sections, items, champs, logique conditionnelle et règles de validation. Il s'appuie sur les éléments du protocole fournis, sur la demande de l'utilisateur ou sur des formulaires existants.
3. L'agent produit un rapport de ce qu'il a créé et rédige les scénarios de test UAT.
4. Le data manager relit, corrige, valide les tests et accepte le passage en production. L'agent peut alors le déclencher.

C'est le principe du human in the loop : à chaque étape, l'agent propose et une personne tranche. Le data manager relit la configuration, corrige ce qui doit l'être (une note de bas de page mal interprétée, un champ numérique là où il fallait une liste déroulante, il y a toujours des corrections), valide les scénarios de test que l'agent a rédigés, puis donne son accord pour la mise en production. Rien ne passe en LIVE sans cette acceptation explicite, et elle est enregistrée dans l'audit trail au nom de la personne, pas de l'agent.

Une fois l'étude passée en LIVE, l'agent ne modifie plus rien dans la version publiée. Toute évolution passe par une nouvelle version de l'étude, qui repart en draft, et l'agent avec elle.

Les autres cas d'usage

• Dashboards et suivi de monitoring. « Sortir les inclusions du centre 102 par rapport aux prévisions, et la répartition des queries ouvertes par ancienneté. » L'agent lit les indicateurs agrégés (screening, inclusions, complétion par section, SDV, données manquantes), construit le graphique, commente l'écart. L'ARC n'a plus à ouvrir quatre écrans. La limite apparaît quand la question repose sur une notion non définie (« les patients à risque ») : sans définition explicite, le modèle en invente une.
• Traductions. L'agent peut ajouter une langue à une étude en draft et proposer les libellés traduits, à partir des labels source et des lacunes identifiées.
• Aide au codage médical. C'est le seul endroit où un texte saisi doit quitter la plateforme : le terme verbatim, seul, avec le dictionnaire et sa version. Ni sujet, ni centre, ni date, ni visite. En retour, une suggestion de code MedDRA ou WHODrug, jamais un code appliqué. Le medical coder valide ou remplace, et pas uniquement pour des raisons réglementaires : sur les termes ambigus ou mal orthographiés, le taux d'erreur d'un modèle reste trop élevé pour se passer d'une relecture.

Comment c'est construit

Le serveur MCP est un service séparé, placé devant l'API publique. Il n'a pas d'accès direct à la base de données et ne détient aucun identifiant propre. Il appelle l'API avec la clé de l'utilisateur, et cette clé n'ouvre rien que son détenteur n'avait déjà.

[ Data manager / ARC ]
        │  « Génère la structure de l'eCRF à partir du schedule of assessments »
        ▼
[ Agent LLM — chat intégré ou modèle local de l'utilisateur ]
        │  get_form_structure(), create_item(), list_templates()
        ▼
[ Serveur MCP — service séparé, clé MCP de l'utilisateur ]
        │  agrégation, filtrage, contrôle du statut DRAFT, écriture de l'origine MCP
        ▼
[ API publique de l'EDC ]
        │  rapport d'exécution, sans donnée clinique
        ▼
[ Relecture, validation des tests et acceptation par le data manager ]  ──►  production

La clé MCP est distincte de la clé API classique. Une intégration système et un agent conversationnel n'ont ni la même durée de vie ni le même profil de risque : la clé MCP est individuelle, expire, se révoque immédiatement, porte des périmètres fixés à la création et des quotas de volume. Il n'existe pas de clé d'organisation ni de compte de service pour le MCP.

Conformité : 21 CFR Part 11, Annexe 11, ICH E6(R3)

Trois questions reviennent systématiquement dans les échanges avec les équipes qualité.

• L'agent peut-il exécuter une action irréversible ? Non. Les écritures sont confinées aux études en DRAFT ou aux nouvelles versions, et ce contrôle est porté par le backend, pas par les instructions données au modèle. Le passage en production demande une acceptation explicite de l'utilisateur. Les actions sur une version publiée (modification d'un formulaire LIVE, application d'un code, écriture sur une donnée collectée) ne sont pas exposées du tout.
• Que contient l'audit trail ? Chaque appel est enregistré avec une origine « MCP » distincte des actions plateforme et des appels API classiques, le nom de l'outil, ses paramètres, l'utilisateur à l'origine de la demande et l'horodatage. L'acteur enregistré est toujours la personne, jamais un acteur système. Un filtre « origine MCP » permet à un auditeur d'isoler l'ensemble en une requête. C'est ce qu'attendent le 21 CFR Part 11 et l'Annexe 11 sur la traçabilité des systèmes informatisés.
• Les protocoles ou les structures d'étude servent-ils à entraîner le modèle ? Cela dépend du fournisseur de LLM et du réglage choisi par l'utilisateur. Chez Claude, ChatGPT, Gemini ou Grok, l'option de non-utilisation des données pour l'entraînement existe, mais c'est à l'utilisateur ou à son organisation de la cocher dans son compte. Datacapt n'a aucun regard sur ce paramètre. Pour un modèle hébergé en local, la question ne se pose pas.

L'ICH E6(R3) va dans le même sens en insistant sur une approche proportionnée au risque et sur l'intégrité des données. Un agent qui prépare sans décider, et qui ne voit pas les données, s'inscrit dans cette logique.

Ce que le MCP ne règle pas

Quelques situations où l'approche montre ses limites aujourd'hui, au-delà de celles déjà décrites sur l'accès aux données :

• La construction complète sans relecture. L'agent produit une base solide, pas un eCRF fini. Il faut toujours repasser derrière.
• Les erreurs. Il en fait, et certaines sont discrètes : un type de champ, une unité, une condition inversée. C'est précisément pour cela que le data manager relit tout et que l'agent ne déploie rien sans acceptation.
• Le coût. Un montage d'eCRF complet représente un volume d'appels au modèle non négligeable, à budgéter au même titre qu'une licence.
• Les demandes floues. Un serveur MCP bien conçu renvoie une question de clarification plutôt qu'une action approximative, mais cela dépend de l'implémentation.

Le MCP avec Datacapt

Le serveur MCP Datacapt applique les règles décrites dans cet article. Il s'utilise depuis le chat intégré à la plateforme ou depuis le client MCP de votre choix, branché sur le modèle que vous avez retenu, Claude, ChatGPT, Gemini, Grok ou autre.

• Métadonnées et agrégats uniquement. Aucune valeur d'eCRF, aucune réponse ePRO, aucun identifiant de sujet ne quitte la plateforme. Le seul texte saisi qui peut sortir est un terme verbatim, seul, pour une suggestion de codage.
• Écritures en DRAFT ou sur une nouvelle version, jamais sur une version publiée. Structure de l'eCRF, logique conditionnelle, règles de validation, templates, langues. Le contrôle est dans le backend.
• Une clé MCP par utilisateur. Distincte de la clé API, à durée de vie limitée, révocable, avec des périmètres fixés à la création. Elle hérite des droits de la personne et de rien d'autre.
• Origine MCP dans l'audit trail. Chaque appel est identifiable comme tel, au nom de l'utilisateur, avec l'outil et ses paramètres. Un filtre dédié pour les inspections.

Conclusion

Le MCP ne change pas ce qu'un EDC sait faire. Il change qui peut déclencher ces capacités et comment : un data manager ou un ARC, en langage naturel, sans passer par un développement dédié.

En recherche clinique, la condition pour que cela fonctionne tient en deux règles. L'agent prépare, l'humain valide. Et pour le moment, le modèle ne voit aucune donnée clinique, ce qui restreint son périmètre. Cela devrait évoluer, par exemple avec un modèle interne hébergé en local, qui permettrait d'ouvrir certaines données à l'agent sans qu'elles quittent l'infrastructure.