L'erreur à 800 000 $ par jour : comment une IA qui confond deux cathéters sabote la découverte de médicaments

C'était un mardi soir, et je fixais un tableur qui n'avait aucun sens.

Nous menions un projet pilote — nous testions la capacité d'un grand modèle de langage à confronter les dossiers de patients aux critères d'éligibilité d'un essai en oncologie. Le protocole était simple, pour un protocole d'oncologie : un nouvel anticoagulant assorti d'une liste de critères d'exclusion, dont l'un était « cathétérisme cardiaque antérieur ». Un cathétérisme du cœur. Un cathéter introduit dans les cavités cardiaques pour évaluer la fonction coronarienne. Un acte cardiaque grave et invasif.

L'IA avait signalé un patient comme non éligible. Motif : cathétérisme cardiaque. J'ai ouvert le dossier du patient. L'acte documenté était une ponction veineuse centrale — une voie veineuse centrale posée dans la veine jugulaire pour l'administration de médicaments. C'est un abord vasculaire réalisé au lit du patient. Les infirmières le pratiquent en réanimation. Ce n'est pas un acte cardiaque. Cela n'a même rien à voir.

Mais le modèle a vu « cathéter », a vu « veineux », a vu que la note avait été rédigée dans une unité de soins cardiaques, et en a conclu : c'est la même chose. Le patient a disparu. Exclu. Jamais remonté au coordinateur du site. Et voici ce qui m'a hanté — personne ne s'en serait aperçu. Le système aurait silencieusement écarté un patient éligible, l'essai aurait compté une personne de moins, et personne n'aurait su pourquoi les inclusions traînaient.

C'est à cet instant que j'ai cessé de croire que de meilleurs prompts régleraient le recrutement pour les essais cliniques. Le problème n'est pas le vocabulaire du modèle. Le problème, c'est que nous utilisons une machine à probabilités pour faire le travail de la logique.

Pourquoi 80 % du pipeline pharmaceutique reste-t-il bloqué au recrutement ?

L'industrie pharmaceutique a un secret honteux qu'aucune conférence de résultats n'aime évoquer : environ 80 % des essais cliniques ne respectent pas leurs délais d'inclusion. Non pas parce que la science est fausse. Non pas parce que les patients n'existent pas. Parce que le processus qui consiste à trouver des patients éligibles et à les apparier aux essais est défaillant à un niveau fondamental.

Laissez-moi chiffrer cette défaillance en dollars. Selon le Tufts Center for the Study of Drug Development, une seule journée de retard dans le développement d'un médicament coûte désormais environ 800 000 $ en ventes de prescriptions perdues pour un actif très performant. En cardiovasculaire et en hématologie, ce chiffre dépasse 1,3 million de dollars par jour. Pour un retard d'inclusion de six mois sur un médicament d'oncologie concurrentiel — le genre de retard qui survient couramment — vous vous exposez à un chiffre capable de rendre une thérapie scientifiquement supérieure commercialement morte-née.

Le goulot d'étranglement de la découverte de médicaments n'est plus la science. C'est la syntaxe.

Et la réalité opérationnelle est encore plus sombre que la réalité financière. 37 % des sites de recherche recrutent en dessous de l'objectif, et 11 % ne parviennent à inclure aucun patient. Chaque échec de sélection — un patient qui semble éligible sur le papier mais ne l'est pas — coûte environ 1 200 $. Lorsque votre outil d'IA génère 100 « correspondances » et que seules 5 sont réelles, vous n'avez pas automatisé le recrutement. Vous avez lancé une attaque par déni de service contre vos propres sites cliniques.

J'ai vu cela se produire. Des coordinateurs de site qui s'étaient enthousiasmés pour nos premiers prototypes ont commencé à ignorer complètement les listes de correspondances. « Votre outil me sort des déchets », m'a dit l'un d'eux au téléphone. Elle n'avait pas tort. Elle est revenue à l'analyse manuelle des PDF. Ctrl+F. L'état de l'art réel du secteur.

Le cathéter qui a brisé ma foi dans les LLM

Laissez-moi revenir plus en détail sur cette erreur du mardi soir, car elle illustre quelque chose que la plupart des argumentaires « l'IA au service de la santé » passent sous silence.

Lorsqu'un grand modèle de langage traite du texte, il convertit les mots en vecteurs — des points dans un espace mathématique en haute dimension. Les mots qui apparaissent dans des contextes similaires se retrouvent proches les uns des autres. « Cathétérisme cardiaque » et « cathétérisme veineux central » sont, dans l'espace vectoriel, quasiment voisins. Tous deux impliquent des cathéters. Tous deux impliquent le système vasculaire. Tous deux apparaissent dans des notes cliniques entourées d'un jargon médical semblable.

Mais ce sont des actes complètement différents ciblant des structures anatomiques différentes, avec des profils de risque différents et des implications cliniques différentes. L'un pénètre dans le cœur. L'autre pénètre dans une veine. Le protocole excluait le premier. Le patient avait subi le second. Et l'IA était incapable de faire la différence, parce qu'elle ne comprend pas l'anatomie — elle comprend la proximité entre les mots.

Ce n'est pas un cas marginal. Des études évaluant des modèles d'IA pour l'appariement aux essais ont identifié ce mode de défaillance précis : des modèles concluant à tort qu'un cathétérisme cardiaque équivaut à une ponction veineuse centrale, ce qui entraîne une exclusion injustifiée. C'est une catégorie d'erreur, pas un bug isolé.

J'ai soumis cela à mon équipe le lendemain matin. L'un de nos ingénieurs — un type brillant, avec une solide formation en apprentissage profond — a suggéré qu'on pourrait corriger le problème par un meilleur fine-tuning. Davantage de données d'entraînement médicales. Des fenêtres de contexte plus larges. Je me souviens de la discussion qui a suivi, car c'est elle qui a façonné toute notre orientation technique. Ma position était simple, et je l'ai formulée sans doute trop crûment : on ne peut pas compenser une ontologie manquante par du fine-tuning.

Un LLM ne sait pas que « cathétérisme cardiaque » se situe sur une branche différente de l'arbre des actes médicaux que « cathétérisme veineux central ». Il n'a pas d'arbre. Il a un brouillard d'associations statistiques. Et aucune quantité de données d'entraînement ne lui donnera la compréhension rigide et hiérarchique que fournit une ontologie médicale — le savoir que l'acte A est un sous-type de « acte sur le cœur » tandis que l'acte B est un sous-type de « cathétérisme d'une veine », et que ces deux catégories sont fondamentalement distinctes.

Cette discussion s'est terminée par la reconstruction de notre architecture de fond en comble.

Qu'est-ce que le phénotypage guidé par l'ontologie, et pourquoi devriez-vous vous en soucier ?

Voici l'idée en langage simple : au lieu de demander à une IA de lire des dossiers médicaux et de deviner ce qu'ils signifient, nous obligeons l'IA à traduire chaque concept médical qu'elle rencontre en un code standardisé issu de SNOMED CT — le système de terminologie clinique le plus complet au monde — avant qu'elle ne prenne la moindre décision.

SNOMED CT n'est pas un dictionnaire. C'est un immense graphe orienté où les concepts médicaux sont reliés par des relations logiques. La plus importante est la relation Is-A. « Angiographie coronarienne » is-a « cathétérisme cardiaque » is-a « acte sur le cœur ». « Cathétérisme veineux central » is-a « cathétérisme d'une veine » is-a « insertion d'un cathéter vasculaire ». Des branches différentes. Des parents différents. Un sens différent.

Ainsi, lorsque notre système rencontre un protocole qui exclut le « cathétérisme cardiaque » et un dossier de patient mentionnant la pose d'une voie veineuse centrale, il ne compare ni des chaînes de caractères ni des vecteurs. Il interroge l'ontologie : L'acte de ce patient est-il un sous-type de l'acte exclu ? Le graphe répond non. Le patient reste éligible. De manière déterministe. À chaque fois.

Nous avons cessé de demander « ces mots se ressemblent-ils ? » et commencé à demander « ces concepts sont-ils logiquement liés ? ». Ce seul changement a tout transformé.

Cela fonctionne même lorsque les médecins écrivent en abrégé. « Cathé cardiaque », « angio », « LHC », « voie centrale », « pose de CVC » — SNOMED CT associe toutes ces variantes à des identifiants de concept précis. Une fois que vous travaillez sur des identifiants de concept plutôt que sur des chaînes de caractères, l'ambiguïté disparaît. Vous appariez du sens à du sens, et non un mot à un mot.

J'ai décrit l'architecture technique qui sous-tend tout cela — les hiérarchies SNOMED CT, la post-coordination pour la latéralité et la sévérité, la construction de phénotypes computationnels — dans la version interactive de notre recherche. Mais l'idée centrale est simple : l'IA médicale a besoin d'une carte de la médecine, pas seulement d'un modèle statistique du langage médical.

Comment analyser le mot « sauf » ?

L'ontologie gère le quoi — de quels concepts médicaux parlons-nous ? Mais les protocoles d'essais cliniques comportent une autre couche de complexité que l'IA générique gère très mal : la logique de l'éligibilité.

Voici un vrai critère d'exclusion tiré d'un essai en oncologie :

« Exclure les patients présentant une hypertension, sauf si elle est bien contrôlée par un traitement stable depuis au moins 3 mois. »

Un moteur de correspondance par mots-clés voit « hypertension » et exclut le patient. Un filtre booléen voit hypertension = TRUE et exclut. Les deux approches écartent un patient qui a de l'hypertension mais qui est parfaitement éligible, car sa tension artérielle est contrôlée et stable depuis des mois.

Cela m'a rendu un peu fou lorsque je l'ai découvert à grande échelle. Nous avons extrait les critères d'éligibilité d'un lot de protocoles d'oncologie de phase II et III, et nous avons constaté que la majorité contenaient des exclusions conditionnelles — des clauses « sauf si », des clauses « excepté lorsque », des dépendances temporelles comme « dans les 6 mois » ou « achevé plus de 90 jours auparavant ». Ce ne sont pas des cas marginaux. C'est la norme. Et chacune d'elles est un piège pour les systèmes incapables de raisonner sur les conditions, les permissions et le temps.

Nous nous sommes tournés vers la logique déontique — une branche de la logique formelle qui traite des obligations, des permissions et des interdictions. C'est la logique des normes et des règles, développée à l'origine par des philosophes, et elle se plaque parfaitement sur les critères d'essais cliniques. Avoir de l'hypertension est interdit — sauf si l'on satisfait également les conditions de permission : une tension artérielle contrôlée et un traitement stable pendant la durée requise. Le système modélise cela sous la forme d'une expression logique formelle, vérifie la chronologie du patient et calcule l'éligibilité avec une précision mathématique.

Autre schéma que nous rencontrons en permanence :

« Les patients ne doivent pas avoir reçu de chimiothérapie antérieure, sauf s'il s'agissait d'un traitement néoadjuvant achevé il y a plus de 6 mois. »

L'IA doit vérifier simultanément trois choses : le patient a-t-il reçu une chimiothérapie ? Son intention était-elle néoadjuvante ? Et s'est-elle terminée plus de six mois avant la date de référence ? Nous traitons cela avec ce que la littérature appelle la Temporal Ensemble Logic — le système construit une chronologie de l'histoire clinique du patient et place les événements dans des fenêtres d'observation valides.

Une recherche par mots-clés voit « chimiothérapie » dans le dossier et panique. Notre système voit la chimiothérapie, vérifie l'attribut d'intention, mesure l'écart temporel et détermine correctement l'éligibilité.

L'architecture que personne n'a demandée (mais dont tout le monde a besoin)

Lorsque je décris notre approche à des investisseurs et à des dirigeants pharmaceutiques, je reçois parfois un regard particulier — le regard qui dit « pourquoi rendez-vous cela si compliqué ? Utilisez simplement GPT. »

J'ai reçu ce regard d'un partenaire potentiel environ un an après le début de notre développement. C'était un type intelligent, il dirigeait l'équipe d'innovation numérique d'un CRO, et il croyait sincèrement qu'un wrapper GPT-4 bien prompté, agrémenté d'un peu de génération augmentée par récupération, résoudrait le problème. « Les modèles s'améliorent chaque trimestre », m'a-t-il dit. « Vous sur-concevez tout ça. »

J'ai affiché nos résultats de tests. Même jeu de données, mêmes critères d'éligibilité. Le wrapper GPT de son équipe : une précision variable d'une exécution à l'autre — littéralement des réponses différentes sur le même patient selon le moment où vous lanciez l'analyse. Aucune piste d'audit. Aucun moyen d'expliquer pourquoi un patient était inclus ou exclu. Et une précision plafonnant autour de 63-87 % selon la complexité des critères.

Notre système neuro-symbolique : déterministe, reproductible, une précision supérieure à 95 %, avec une trace de raisonnement complète pour chaque décision.

La FDA n'accepte pas « l'IA le pensait » comme justification. Il leur faut une preuve logique. Ce n'est pas un confort optionnel — c'est ce qui distingue un outil qui augmente la recherche clinique d'un jouet qui impressionne un public de démonstration.

Voici comment l'architecture fonctionne réellement, sans vous noyer dans les détails d'implémentation :

Le LLM lit. Il ingère la réalité désordonnée et non structurée des dossiers médicaux — PDF scannés, notes manuscrites, comptes rendus des médecins — et son seul rôle est d'extraire les entités médicales et de les normaliser. Il lit « le pt se plaint de douleurs thoraciques » et produit le concept SNOMED correspondant à la douleur thoracique. C'est tout. Le LLM est la couche de perception. Il ne prend jamais de décision d'éligibilité.

Le graphe de connaissances mappe. Les entités extraites sont associées à des identifiants de concept SNOMED CT, désambiguïsées par le contexte. « Cold » le virus par opposition à « cold » la température. La structure du graphe résout l'ambiguïté.

Le solveur logique raisonne. C'est là que se produit la détermination effective de l'éligibilité — un raisonneur symbolique déterministe qui applique des règles de logique déontique au phénotype structuré du patient. Il vérifie les relations Is-A, calcule les durées temporelles, évalue les permissions conditionnelles. Pour les mêmes entrées, il produit toujours la même sortie.

Nous utilisons également GraphRAG au lieu de la récupération standard fondée sur les vecteurs. Le RAG standard récupère des fragments de documents en fonction de la similarité entre les mots. GraphRAG parcourt des relations. Si un essai exclut « tout médicament interagissant avec les enzymes CYP3A4 » et qu'un patient prend le médicament B, le RAG standard risque de manquer le lien si le dossier du patient ne dit jamais explicitement « le médicament B est un inhibiteur du CYP3A4 ». GraphRAG le sait, parce que le graphe de connaissances contient la relation : le médicament B inhibe le CYP3A4. Un raisonnement multi-sauts. Le type de lien qu'un pharmacien établit intuitivement, mais qu'un système de correspondance textuelle n'établirait jamais.

Pour le détail technique complet de l'architecture — l'intégration neuro-symbolique de type 4, le décodage tenant compte des concepts, la couche d'interopérabilité FHIR/CDISC — consultez notre article de recherche détaillé.

« Mais les modèles ne vont-ils pas tout simplement s'améliorer ? »

Les gens contestent toujours ce point, et je comprends pourquoi. La trajectoire des LLM est réellement impressionnante. Tous les quelques mois, un nouveau modèle obtient un meilleur score sur les benchmarks médicaux. Alors pourquoi ne pas attendre ?

Parce que le problème n'est pas la capacité — c'est l'architecture. Un LLM est un prédicteur probabiliste de tokens. Le rendre plus grand et l'entraîner sur davantage de textes médicaux en fait un meilleur prédicteur probabiliste de tokens. Cela n'en fait pas un moteur logique. Cela ne lui confère pas de déterminisme. Cela ne lui confère pas de piste d'audit. Et dans un secteur réglementé où la FDA et l'EMA doivent savoir exactement pourquoi le patient n° 4 271 a été exclu de l'essai XYZ-003, « le modèle a prédit que c'était la réponse la plus probable » n'est pas acceptable.

Il y a aussi le problème de la confidentialité, qui ne disparaît pas avec l'échelle. Envoyer des dossiers de patients non structurés vers des API de modèles hébergées dans le cloud — même des API d'entreprise — crée une exposition au regard de la HIPAA et du RGPD qu'aucun accord BAA ne peut totalement atténuer. Notre architecture maintient les données des patients à l'intérieur d'enclaves sécurisées. La couche de raisonnement symbolique et le graphe de connaissances s'exécutent localement. La couche neuronale peut être un modèle open source local. Les informations de santé protégées ne quittent jamais le pare-feu.

Et puis il y a le problème de la reproductibilité, que je trouve le plus accablant. Faites passer deux fois le même dossier de patient dans un LLM avec le même prompt, et vous pouvez obtenir des réponses différentes. Modifiez le réglage de la température, ajustez la fenêtre de contexte, reformulez légèrement la question — résultat différent. Les essais cliniques exigent des décisions reproductibles à 100 %. Le cadre réglementaire l'impose. L'éthique l'impose.

Les patients que nous perdons

J'ai passé l'essentiel de cet essai à parler d'architecture et d'économie, mais je veux terminer sur un ton plus honnête.

Pour les patients atteints d'un cancer métastatique, d'une LAM ou d'une maladie génétique rare, un retard d'inclusion de six mois n'est pas une ligne dans un modèle financier. C'est la différence entre accéder à une thérapie potentiellement curative et ne pas y accéder. Lorsque notre système exclut à tort un patient éligible — parce qu'il a confondu deux actes de cathétérisme, ou parce qu'il n'a pas su interpréter une clause « sauf si » — ce patient ne reçoit pas de notification lui disant « désolé, l'IA a commis une erreur ». Il n'entend tout simplement jamais parler de l'essai. Son oncologue ne reçoit jamais l'alerte. La place reste vacante, ou revient à quelqu'un d'autre, et le patient poursuit le traitement standard, sans jamais savoir qu'une option existait.

C'est à cela que je pense quand quelqu'un me dit d'utiliser tout simplement une API wrapper.

Nous avons créé Veriprajna parce que l'écart entre ce que l'IA promet dans la santé et ce qu'elle délivre réellement n'est pas un problème marketing — c'est un problème d'ingénierie. Le secteur a choisi l'architecture facile (lui balancer un LLM) au lieu de la bonne architecture (donner au LLM une ontologie et un solveur logique, et le contraindre à ne faire que ce en quoi il excelle).

Nous n'atteindrons pas la médecine de précision à coups de prompt engineering. Nous avons besoin de systèmes qui raisonnent, et non de systèmes qui devinent avec assurance.

Le remède à la crise du recrutement, ce ne sont pas de meilleurs modèles de langage. C'est la prise de conscience que l'éligibilité est un problème de logique déguisé en langage. Retirez le texte non structuré, associez-le à une ontologie médicale, appliquez un raisonnement formel, et soudain les 80 % d'essais qui ratent leurs délais d'inclusion commencent à ressembler à un problème soluble plutôt qu'à une fatalité du secteur.

Cessez d'apparier des mots. Commencez à apparier des patients. La différence tient en un graphe de connaissances, un solveur logique et la volonté de construire quelque chose de plus difficile qu'un wrapper.