LLMs en médecine : ce que les ingénieurs ML doivent savoir avant de coder

On le sait, les Large Language Models (LLMs) sont partout. Même dans les blocs opératoires, apparemment. Entre les annonces tonitruantes de startups qui promettent de "révolutionner la médecine avec l'IA" et les réalités bien plus terre-à-terre des systèmes de santé, il y a un monde. Un monde fait de contraintes réglementaires, de données bruitées, et de modèles qui hallucinent joyeusement des diagnostics.

Alors avant de vous lancer tête baissée dans le développement d’un "ChatGPT pour médecins", voici ce que vous devez vraiment savoir. Spoiler : ce n’est pas parce qu’un modèle sait aligner trois mots sur une ordonnance qu’il est prêt pour la prod.

---

1. Fondements techniques : pourquoi la médecine n’est pas un dataset comme les autres

1.1. Des données qui ressemblent à un placard de pharmacie mal rangé

En ML classique, on a l’habitude de datasets propres, labellisés, avec des features bien alignées. En médecine, oubliez ça.

Les données médicales, c’est :

• Non structurées à 80% : comptes-rendus manuscrits, dictaphones de médecins pressés, scans PDF illisibles parce que le technicien avait la main qui tremblait.
• Biais systématiques : surreprésentation des patients hospitaliers (donc des cas graves), sous-représentation des populations marginalisées. Un modèle entraîné sur ça va avoir une fâcheuse tendance à surdiagnostiquer.
• Problèmes de temporalité : un patient peut avoir 5 examens en 3 ans, avec des protocoles différents. Bon courage pour aligner ça en séries temporelles.

Exemple concret : Un étude récente (arXiv 2604.02322v1) montre que les LLMs ont un taux d’erreur 3x plus élevé sur les dossiers médicaux des femmes que des hommes. Pourquoi ? Parce que les symptômes sont souvent décrits différemment ("douleur thoracique" vs "oppression"), et les datasets historiques reflètent ça.

"Entraîner un LLM sur des données médicales, c’est comme essayer de monter un meuble IKEA avec une notice en suédois, des pièces manquantes, et un marteau à la place d’un tournevis."

1.2. L’architecture qui fait (presque) consensus : RAG + fine-tuning léger

Aujourd’hui, personne ne déploie un LLM brut en production médicale. Les architectures qui marchent (un peu) reposent sur :

1. Retrieval-Augmented Generation (RAG) :

   • Un index vectoriel (FAISS, Weaviate, ou Pinecone) qui stocke les connaissances médicales validées (guidelines, études cliniques, protocoles hospitaliers).
   • Le LLM génère des réponses en s’appuyant sur ces sources, pas en inventant.
   • Problème : Si votre base de connaissances est obsolète, le modèle aussi. Et en médecine, les protocoles changent tous les 6 mois.

2. Fine-tuning léger (LoRA, QLoRA) :

   • On ne réentraîne pas tout le modèle, juste quelques couches sur des tâches spécifiques (ex : résumer un compte-rendu de scanner).
   • Benchmark utile : Une équipe de Stanford a montré qu’un Mistral-7B fine-tuné avec LoRA sur des données radiologiques atteignait 89% de précision sur la détection d’anomalies… contre 62% pour le même modèle sans fine-tuning.
   • Piège : Le fine-tuning peut amplifier les biais si le dataset d’entraînement est déséquilibré.

3. Ensembling avec règles métiers :

   • Le LLM ne décide pas seul. Ses sorties sont validées par un moteur de règles (ex : "Si le modèle propose un diagnostic de cancer, exiger une confirmation humaine").
   • Outils : Drools, Easy Rules, ou même du Python custom.

À éviter absolument :

• Les modèles full end-to-end (entrée brute → diagnostic). Ça marche dans les papers, pas en vrai.
• Les LLMs "black box" sans explicabilité. Un médecin a besoin de savoir pourquoi le modèle propose tel traitement, pas juste "parce que l’IA l’a dit".

---

2. Implémentation : comment coder sans se faire virer (ou poursuivre)

2.1. Le stack technique réaliste pour un PoC

Si vous voulez tester un LLM en contexte médical sans vous retrouver avec un système qui diagnostique des grossesses chez les hommes, voici une stack qui a fait ses preuves :

# Exemple minimaliste avec Haystack + Mistral (pour un chatbot médical)
from haystack import Pipeline
from haystack.nodes import BM25Retriever, PromptNode
from haystack.document_stores import FAISSDocumentStore

# 1. Indexation des connaissances médicales (ex: guidelines de l'OMS)
document_store = FAISSDocumentStore(embedding_dim=768)
document_store.write_documents([{"content": "Protocole sepsis 2024: antibio dans l'heure..."}, ...])

# 2. Rétroaction + LLM (ici Mistral-7B avec LoRA)
retriever = BM25Retriever(document_store=document_store)
prompt_node = PromptNode(model_name_or_path="mistral-7b", default_prompt_template="medical_qa")

pipe = Pipeline()
pipe.add_node(component=retriever, name="retriever", inputs=["Query"])
pipe.add_node(component=prompt_node, name="prompt_node", inputs=["retriever"])

Points clés :

• Always-on retrieval : Le LLM ne répond jamais sans contexte retrieved.
• Temperature à 0.2 : On veut de la précision, pas de la créativité.
• Logging agressif : Toutes les interactions sont enregistrées pour audit (RGPD obligatoire).

**2.2. Les librairies qui sauvent des vies (ou au moins des projets)

Besoin	Outil	Pourquoi ça marche (ou pas)
Retrieval	Haystack, LlamaIndex	Gère bien les PDFs médicaux (OCR intégré).
Fine-tuning	PEFT (LoRA), Axolotl	Permet de fine-tuner un 7B sur une seule GPU.
Explicabilité	SHAP, LIME	Pour expliquer pourquoi le modèle a suggéré ce traitement.
Validation	Great Expectations, Evidently	Détecte les drifts dans les données (ex: nouveau protocole COVID).
Déploiement	FastAPI + Docker (pas de serverless)	Latence prévisible, crucial pour les urgences.

À bannir :

• Streamlit pour les interfaces : Trop lent pour les urgences. Utilisez Gradio ou du React custom.
• Les APIs propriétaires (type OpenAI) : Vous voulez vraiment que les données patients transitent chez un tiers ?

2.3. Le problème que personne ne veut aborder : la latence

En médecine, 500ms de latence, c’est :

• Acceptable pour un résumé de dossier.
• Inacceptable pour une aide au diagnostic en urgence.

Benchmarks réels (sur un serveur on-prem avec A100) :

Modèle	Temps de réponse (ms)	Précision (%)
Mistral-7B (RAG)	320	87
Llama-2-70B (RAG)	890	89
GPT-4 (API)	1200+	91

Solution :

• Quantisation (GGUF, AWQ) pour réduire la taille du modèle.
• Caching agressif des embeddings fréquents (ex: "douleur abdominale").
• Edge deployment sur des stations de travail dédiées (pas de cloud).

---

3. Benchmarks : ce que les papiers ne vous disent pas

3.1. Les métriques qui comptent (et celles qui mentent)

Oubliez l’accuracy. En médecine, on parle de :

• Sensibilité : Combien de vrais positifs le modèle détecte. Critique pour les maladies rares.
• Spécificité : Combien de faux positifs il évite. Un faux positif = stress inutile pour le patient.
• F1-score pondéré : Parce que les classes sont déséquilibrées (100 grippe pour 1 cancer).

Exemple :

Modèle	Sensibilité (Cancer)	Spécificité	F1-score
Med-PaLM 2	92%	88%	0.90
ClinicalBERT	88%	95%	0.91
GPT-4 (RAG)	90%	90%	0.90

Problème : Ces chiffres viennent de benchmarks contrôlés. En production, avec des données bruitées, la sensibilité chute de 15-20%.

3.2. Le benchmark qui fait mal : MedQA (USMLE)

Le gold standard pour évaluer un LLM en médecine, c’est le MedQA, un dataset de questions d’examen médical (USMLE).

Résultats récents :

Modèle	MedQA Accuracy	Coût d’inférence (par requête)
GPT-4	86.2%	$0.03
Meditron-70B	84.1%	$0.005 (on-prem)
Mistral-7B (RAG)	78.3%	$0.001
Médecin humain (moy)	72.5%	Un café + 10 ans d’études

Observations :

• GPT-4 est meilleur, mais 10x plus cher. Pour un hôpital, c’est un deal-breaker.
• Meditron-70B (un modèle open-source spécialisé) performe presque aussi bien pour un coût ridicule.
• Les humains sont battus, mais ils ont l’avantage de ne pas halluciner des maladies.

3.3. Le vrai test : le déploiement à l’hôpital de Boston

En 2023, le Massachusetts General Hospital a déployé un LLM (basé sur Llama-2) pour aider à trier les urgences.

Résultats après 6 mois : ✅ Réduction de 30% du temps de saisie pour les comptes-rendus. ❌ 2 incidents critiques où le modèle a suggéré un traitement contre-indiqué (à cause d’une mise à jour obsolète des guidelines). ⚠️ Adoption par seulement 40% des médecins : les autres préféraient "faire à l’ancienne".

Leçon : Un LLM en médecine, c’est comme un interne junior : utile pour les tâches chiantes, mais il faut toujours vérifier son travail.

---

4. Limitations : pourquoi votre CTO va détester ce projet

4.1. Le problème juridique : qui est responsable si l’IA se plante ?

Aux États-Unis, la FDA commence à encadrer les LLMs médicaux comme des devices. En Europe, c’est le RGPD + la directive IA Act qui s’appliquent.

Cas réel :

• Un hôpital allemand a été poursuivi parce qu’un LLM avait suggéré une dose erronée de morphine. Résultat : 2M€ d’amende pour "négligence algorithmique".
• Solution : Toujours avoir un médecin dans la loop (et un avocat en standby).

4.2. Les données, ce cauchemar éveillé

• Anonymisation : Même avec des techniques comme k-anonymity, ré-identifier un patient à partir de son dossier médical est trivial (voir cet article sur les fuites de données).
• Biais culturels : Un modèle entraîné sur des données américaines va rater des symptômes spécifiques à d’autres populations. Exemple : la drépanocytose est sous-diagnostiquée par les LLMs parce que peu représentée dans les datasets.

4.3. Le coût caché : la maintenance

Un LLM médical, c’est comme une voiture de luxe :

• Ça coûte cher à l’achat (fine-tuning, infrastructure).
• Ça coûte encore plus cher à entretenir (mises à jour des connaissances, monitoring des drifts).

Exemple :

• Coût annuel estimé pour maintenir un LLM en radiologie : ~500k€ (source : étude du NHS).
• Comparaison : Un radiologue humain coûte ~200k€/an… mais il ne plante pas si vous changez de version de PyTorch.

---

5. Recherche & évolutions : ce qui va (peut-être) marcher demain

5.1. Les architectures prometteuses (mais pas encore en prod)

1. LLMs + Graph Neural Networks (GNNs) :

   • Idée : Représenter le dossier médical comme un graphe (médicaments → effets secondaires → interactions).
   • Avantage : Meilleure gestion des dépendances temporelles.
   • Problème : Complexité d’entraînement (et bonjour les OOM errors).

2. Agents multi-modaux :

   • Combiner texte (dossier patient) + images (scans) + audio (sons du cœur).
   • Exemple : Qwen-VL d’Alibaba commence à être testé en Chine pour l’analyse de scans.
   • Limite : Les modèles multimodaux sont énormes (30B+ params) et lents.

3. Reinforcement Learning from Human Feedback (RLHF) médical :

   • Entraîner le modèle avec des feedbacks de vrais médecins.
   • Problème : Les médecins n’ont pas le temps de labelliser des données.

5.2. Les startups qui montent (et celles qui vont crasher)

Startup	Technologie	Pourquoi ça peut marcher (ou pas)
Hippocratic AI	LLM spécialisé en soins	Levée de 50M, mais modèle encore trop générique.
Abraham	Agent conversationnel pour urgences	Partenariat avec des hôpitaux français. À suivre.
DeepScribe	Génération de comptes-rendus	Déjà utilisé par 10k médecins aux US. Le plus mature.
Infermedica	Triage symptomatique	Bon pour les symptômes simples, pas pour les cas complexes.

5.3. Le futur ? Des LLMs "spécialistes", pas généralistes

La tendance, c’est :

• Des modèles petits (3B-7B params) fine-tunés sur une tâche précise (ex : radiologie, cardiologie).
• Du RAG hyper-spécialisé (ex : base de connaissances limitée aux guidelines de l’ESC pour la cardiologie).
• De l’edge computing pour éviter les latences (et les fuites de données).

Prédiction : D’ici 2-3 ans, on aura des "LLMs-médecins" aussi spécialisés que les humains :

• Un modèle pour la dermatologie.
• Un autre pour la neurologie.
• Et surtout, plus de "ChatGPT qui fait tout" (parce que ça, en médecine, c’est une mauvaise idée).

---

FAQ

[Un LLM peut-il remplacer un médecin ?] Non, et ce ne sera pas le cas avant très longtemps. Les LLMs excellents pour trier des informations ou suggérer des diagnostics, mais ils hallucinent encore trop (environ 5-10% de faux positifs dans les benchmarks réels). Aujourd’hui, leur rôle se limite à assister les médecins, pas à décider.

[Quel est le meilleur modèle open-source pour un projet médical ?] Meditron-70B (basé sur Llama-2) est actuellement le plus performant en open-source pour les tâches médicales, avec une précision proche de GPT-4 sur MedQA. Sinon, **Mistral-7B fine-tun