Image de couverture : IA en santé : quand les hallucinations deviennent dangereuses — leçons pour vos projets d'automatisation
tech

IA en santé : quand les hallucinations deviennent dangereuses — leçons pour vos projets d'automatisation

20 May 2026
6 min de lecture
10 vues
Sébastien Muler

Introduction

En mai 2026, le Bureau du vérificateur général de l'Ontario publiait un rapport alarmant sur l'usage de l'IA dans le secteur médical. Sur 20 systèmes d'IA approuvés pour la prise de notes médicales automatisée (programme AI Scribe), la majorité présentaient des erreurs factuelles graves : médicaments confondus, informations inventées, détails critiques omis. Selon les auditeurs, 60 % des systèmes évalués mélangaient les médicaments prescrits dans les notes patient.

Cette actualité, relayée par The Register, dépasse largement le cadre médical. Elle pose une question fondamentale que tout développeur ou chef de projet doit se poser avant de déployer un outil IA : qui vérifie ce que la machine produit ?


Ce que révèle l'audit ontarien

Les évaluations ont été menées à partir d'enregistrements simulés de consultations médecin-patient. Des professionnels de santé ont ensuite analysé les comptes rendus générés automatiquement. Le bilan est sans appel :

  • Des informations non mentionnées par le patient ou le médecin apparaissaient dans les notes (hallucinations).
  • Des détails critiques — allergies, posologies, antécédents — étaient manquants ou incorrects.
  • Les erreurs concernaient des données à fort impact clinique, là où une inexactitude peut avoir des conséquences directes sur la santé d'un patient.

Ce qui est particulièrement préoccupant, c'est que ces systèmes avaient été approuvés dans le cadre d'un processus de procurement officiel. L'approbation administrative ne suffit donc pas à garantir la fiabilité opérationnelle d'un LLM dans un contexte à risque élevé.


Le problème structurel : l'hallucination n'est pas un bug, c'est une caractéristique

Les grands modèles de langage (LLM) ne "comprennent" pas le monde au sens littéral. Ils prédisent des séquences de tokens statistiquement cohérentes. Cela les rend exceptionnellement fluides… et potentiellement trompeurs. Un modèle peut générer une phrase parfaitement construite et totalement fausse avec la même assurance qu'une réponse exacte.

Dans un contexte métier classique — rédaction de contenu, synthèse de documents, assistance au code — une hallucination est gênante mais rarement catastrophique. Dans un contexte médical, juridique ou financier, la même erreur peut avoir des conséquences irréversibles.

Cela soulève deux problèmes liés :

  1. Le problème de la confiance implicite : les utilisateurs finaux (ici, les médecins) tendent à faire confiance à un output bien formaté, surtout sous pression de temps.
  2. Le problème de l'évaluation : mesurer la fiabilité d'un LLM sur des tâches factuelles complexes est difficile et coûteux. Les benchmarks standards ne reflètent pas toujours les conditions réelles d'usage.

Ce que cela implique pour vos projets d'automatisation

⚠️ Automatiser un processus avec de l'IA ne revient pas à le rendre infaillible. Voici les principes à intégrer dès la conception.

1. Identifier les zones à risque de votre pipeline

Avant d'intégrer un LLM dans un flux de travail, cartographiez les points où une erreur factuelle aurait un impact significatif. Dans un projet Symfony, cela peut concerner : la génération automatique de contrats, la synthèse de données client, la création de rapports réglementaires, ou encore le traitement de formulaires médicaux ou administratifs.

Pour chaque zone identifiée, posez-vous la question : si le modèle se trompe ici, qu'est-ce qui se passe concrètement ?

2. Intégrer le Human-in-the-Loop (HITL) comme composant architecturel

Le Human-in-the-Loop n'est pas un aveu d'échec de l'IA. C'est une décision d'architecture qui reconnaît les limites actuelles des LLM et les compense intelligemment.

Concrètement, cela peut prendre plusieurs formes :

  • Validation explicite : un utilisateur confirme chaque output avant qu'il soit persisté ou transmis.
  • Workflow de révision : les outputs à faible score de confiance sont routés vers une file de relecture humaine.
  • Audit log structuré : chaque génération est tracée avec le prompt, le modèle utilisé, la version, et l'identité du validateur.

Dans un contexte Symfony, ce type de workflow peut être modélisé avec des entités AiGeneratedContent portant un statut (draft, pending_review, validated, rejected) et des listeners ou des Messenger handlers pour orchestrer les transitions.

3. Évaluer en conditions réelles, pas seulement en démo

L'audit ontarien montre que des systèmes ont passé un processus de validation officiel tout en étant défaillants en conditions opérationnelles. La leçon : les évaluations doivent reproduire la variabilité du réel.

Pour un projet PHP/Symfony intégrant un LLM, cela signifie :

  • Construire un jeu de données de test représentatif (cas nominaux et cas limites).
  • Mettre en place des métriques d'évaluation automatisées (exactitude factuelle, cohérence, taux d'hallucination sur des champs vérifiables).
  • Rejouer ces évaluations à chaque mise à jour du modèle ou du prompt.

Des frameworks comme RAGAS (pour les architectures RAG) ou des pipelines d'évaluation custom peuvent être intégrés dans votre CI/CD pour détecter les régressions.

4. Ne pas confondre RAG et fiabilité garantie

Le Retrieval-Augmented Generation (RAG) est souvent présenté comme la solution aux hallucinations : on ancre le modèle dans des documents de référence. C'est une approche efficace — mais pas infaillible. Le modèle peut toujours mal interpréter un document source, fusionner des informations incompatibles, ou ignorer un passage pertinent.

Le RAG réduit le risque d'hallucination, il ne l'élimine pas. La supervision humaine reste nécessaire, particulièrement sur les outputs à fort enjeu.


Conclusion

L'affaire des systèmes de notes médicales en Ontario est un signal fort. L'IA générative, même validée institutionnellement, peut produire des erreurs graves dès lors qu'on lui retire toute supervision humaine. Ce constat vaut pour la médecine, mais aussi pour tout système d'information critique.

Chez MulerTech, notre approche des projets intégrant des LLM repose sur un principe simple : l'automatisation augmente la productivité, la supervision humaine en garantit la fiabilité. Ces deux dimensions ne s'opposent pas — elles se complètent.

Si vous envisagez d'intégrer de l'IA dans vos processus métier, commencez par identifier vos zones à risque, concevez vos workflows de validation, et mettez en place vos pipelines d'évaluation avant de passer en production.


Source originale : Sick and wrong: Ontario auditors find doctors' AI note takers routinely blow basic facts — The Register, 14 mai 2026.

Partager cet article