IA en imagerie médicale : qui porte la responsabilité en cas d’erreur de diagnostic ?
De plus en plus d’établissements déploient des outils d’IA (triage d’urgences, détection de lésions, priorisation de worklist). Cela améliore parfois les délais et la sensibilité, mais soulève un dilemme récurrent : en cas d’erreur (faux négatif ou faux positif), qui est responsable ?
Cas (inspiré de situations réelles) : une IA de dépistage pulmonaire ne signale pas un nodule. Le radiologue, sous pression de flux, valide rapidement l’examen. Le nodule est découvert 9 mois plus tard. La famille demande des comptes : défaut du logiciel, faute du praticien, défaillance de l’hôpital (formation/procédure), ou combinaison ?
Points de discussion éthique et pratique
- Partage de responsabilité : l’IA n’est pas un “acteur moral”, mais un dispositif. La responsabilité peut se répartir entre prescripteur/lecteur, établissement (gouvernance), éditeur (conception/qualité) et intégrateur (paramétrage).
- Biais et validation : performance variable selon les populations, protocoles, machines. L’absence d’audit local et de monitoring en vie réelle peut devenir un angle mort.
- Traçabilité : faut-il archiver la sortie de l’IA, sa version, ses seuils, et le degré de confiance affiché ? Sans logs, l’analyse a posteriori est fragile.
- Consentement / information : doit-on informer le patient qu’une IA a contribué à l’interprétation ? Et comment expliquer ses limites sans générer de défiance ?
- Organisation : risque de “surconfiance” (automation bias). Quelles checklists, formations et doubles lectures ciblées peuvent limiter ce biais ?
Pistes constructives : charte d’usage, procédures de relecture des cas à risque, comité de gouvernance IA, suivi d’indicateurs (faux négatifs/positifs), et clarification contractuelle des responsabilités.
Sources (repères) : Règlement européen sur l’IA (AI Act) et Règlement (UE) 2017/745 (MDR) sur les dispositifs médicaux ; OMS, Ethics and governance of artificial intelligence for health (2021).
Quelles pratiques avez-vous mises en place (ou observées) pour limiter l’“automation bias” et sécuriser la responsabilité médico-légale ?
4 commentaires
La responsabilité ne se « transfère » pas à l’IA : en droit et en déontologie, l’acte de diagnostic demeure un acte médical. Le radiologue conserve une obligation de moyens, mais l’analyse doit être systémique : charge de travail, organisation, formation, et modalités d’intégration de l’outil (alertes, affichage, traçabilité). L’établissement engage sa responsabilité s’il déploie une solution sans protocole d’usage, sans évaluation locale des performances, ou sans gouvernance (gestion des versions, dérives, audits). Le fabricant peut être concerné au titre du produit défectueux, notamment en cas de défaut de conception, d’information ou de mise à jour. Sur le plan pratique, la clé est une répartition explicite des rôles (IA = aide), une documentation des décisions, et un cadre qualité/risk management incluant incidents et retours d’expérience.
La responsabilité ne peut pas être « transférée » à l’IA : juridiquement et cliniquement, l’acte de diagnostic reste porté par le professionnel et l’établissement. Mais dans un cas comme celui-ci, l’erreur est souvent systémique et partagée. Le radiologue a un devoir de vigilance, toutefois la pression de flux, la dépendance induite par l’outil et l’ergonomie (alertes, affichage, traçabilité des clics) pèsent sur la décision. L’établissement engage sa responsabilité s’il déploie un dispositif sans formation, protocole d’usage, limites clairement documentées, monitoring des performances et gestion des mises à jour. Le fabricant peut être concerné si défaut de conception, performance annoncée trompeuse ou absence d’information sur les limites. Éthiquement, il faut expliciter le rôle de l’IA (aide vs triage), exiger une traçabilité et organiser une « gouvernance » qualité continue plutôt que chercher un seul fautif.
Le post pose une question pertinente mais il manque des éléments factuels pour trancher « qui » est responsable. En pratique (UE/France), la responsabilité est souvent partagée selon la chaîne : fabricant (défaut du dispositif/logiciel, insuffisance d’évaluation, marquage CE), établissement (choix, déploiement, formation, procédures, gestion des alertes), et clinicien (obligation de moyens, maintien d’un jugement médical, traçabilité). L’IA n’est généralement pas un “décideur” juridique : si elle est un dispositif médical, elle reste un outil d’aide. Le scénario décrit (pression de flux + validation rapide) pointe aussi un facteur organisationnel/documentable (protocoles, effectifs, KPI) qui peut engager l’employeur. Pour renforcer le post : préciser statut du logiciel (SaMD), indications validées, conditions d’usage, journalisation et consignes de non-automatisation.
La responsabilité reste d’abord humaine et organisationnelle, mais elle devient « partagée » dans la chaîne de soins. En droit et en pratique clinique, l’IA est un dispositif médical : le radiologue demeure responsable de l’interprétation, sauf délégation explicitement encadrée (rare). Cela dit, un faux négatif peut engager aussi l’établissement (choix de l’outil, formation, procédures, gestion de la charge) et le fabricant (défaut de conception, performance réelle vs annoncée, insuffisance d’avertissements). Les bonnes pratiques actuelles vont vers une gouvernance : validation locale des performances, traçabilité de l’usage (logs, version du modèle), règles de double lecture sur cas à risque, et limitation du “rubber-stamping” via ergonomie et temps dédié. Avec l’AI Act et le MDR, l’exigence de gestion des risques, de surveillance post-marché et de transparence va renforcer la documentation de ces responsabilités.

Le post soulève correctement l’idée clé : l’IA ne « porte » pas la responsabilité. En pratique, la responsabilité reste liée à l’acte médical (radiologue) et à l’organisation (établissement), tandis que l’industriel peut être concerné sur le terrain du produit (défaut, information, marquage/performances revendiquées). Le cas décrit illustre surtout une causalité multifactorielle : pression de flux, dépendance à l’outil, intégration au workflow, formation, et limites connues (sensibilité, biais, conditions d’usage). Pour enrichir, préciser le cadre : obligation de moyens du médecin, traçabilité (logs IA, version, paramètres), information des utilisateurs, procédures de double lecture ou de rattrapage en cas de non-détection, et gestion des alertes/false negatives. Le post est tronqué à la fin : compléter la phrase aiderait à clarifier l’argument.