IA explicable en santé : ce qu’une explication doit permettre au clinicien

La même technologie peut trier une liste de travail, repérer un signal, proposer une mesure, estimer un risque ou aider à rédiger un compte rendu. Les conséquences d’une erreur, et donc les besoins d’explication, changent d’un usage à l’autre. Avant d’examiner l’interface, l’établissement documente :

• la population visée et les exclusions ;
• l’entrée attendue et la qualité minimale des données ;
• la sortie et son unité ;
• l’utilisateur responsable ;
• l’étape du parcours où le résultat intervient ;
• l’action possible après un résultat positif, négatif ou incertain ;
• les risques d’une erreur ou d’une non-utilisation.

Le guide HAS-CNIL recommande de tenir une cartographie des systèmes d’IA utilisés, mise à jour au moins une fois par an : nom et version de chaque outil, fournisseur, finalités, statut réglementaire, niveau de risque au sens du règlement européen, services utilisateurs, référent local et modalités de suivi. C’est le point de départ de toute question d’explicabilité : on ne peut pas juger l’explication d’un outil dont on ne connaît ni la version ni la finalité. Partir de la décision plutôt que de la variable prédite est la méthode détaillée dans notre article sur la stratification du risque patient.

Une explication qui convient à un ingénieur n’est pas forcément utile à un radiologue, une infirmière, un médecin généraliste ou un patient. Son niveau de détail doit soutenir l’action sans masquer les informations critiques.

L’explicabilité ne corrige pas une mauvaise validation. Une carte de chaleur ne compense pas un modèle testé sur une population trop éloignée de celle de l’établissement. Inversement, un modèle performant en moyenne peut être mal compris et favoriser une erreur d’usage. Les deux dimensions se traitent séparément.

Dans un point de vue publié par The Lancet Digital Health en 2021, Ghassemi, Oakden-Rayner et Beam vont plus loin : les méthodes d’explicabilité actuelles ont peu de chances d’apporter la confiance, la transparence ou la réduction des biais qu’on en attend pour une décision au niveau d’un patient. Ils recommandent plutôt une validation interne et externe rigoureuse des modèles, et mettent en garde contre le fait d’ériger l’explicabilité en condition du déploiement clinique.

Le guide HAS-CNIL tient les deux exigences ensemble. Il conseille de ne pas contractualiser avec un fournisseur si les principes de fonctionnement, d’explicabilité ou d’apprentissage du système restent opaques pour l’établissement, ou s’il n’existe pas de preuves de validation dans la population d’usage prévue. Discrimination, calibration, performances par sous-groupe et seuils sont détaillés dans notre article sur la stratification du risque patient, et les critères propres à l’imagerie dans celui sur l’IA en imagerie médicale.

1. Est-elle fidèle au modèle ?

Une explication produite après coup peut approcher le comportement du modèle sans le reproduire exactement, et deux méthodes peuvent attribuer des importances différentes aux mêmes variables. Le fournisseur doit préciser la méthode, ses hypothèses, sa stabilité et les tests réalisés. Une explication plausible n’est pas une preuve causale.

2. Est-elle comprise par l’utilisateur visé ?

Le règlement européen (article 14) demande que les personnes chargées du contrôle humain puissent comprendre les capacités et les limites du système et interpréter correctement ses sorties. Cela se teste avec les professionnels concernés : peuvent-ils reformuler le résultat, identifier ses limites et choisir l’action appropriée ? Un écran surchargé ou un vocabulaire ambigu peut diminuer la sécurité, même si la documentation technique est complète.

3. Montre-t-elle l’incertitude ?

Un score isolé encourage une lecture binaire. Il faut savoir s’il existe une zone d’incertitude, des données manquantes, une qualité d’image insuffisante ou une situation hors périmètre, et le système doit pouvoir s’abstenir lorsque ses conditions d’utilisation ne sont pas réunies. La qualité des données d’entrée se juge selon l’usage : c’est l’objet de notre article sur la qualité des données de santé.

4. Permet-elle de contester le résultat ?

Le même article 14 prévoit que la personne qui supervise puisse décider de ne pas utiliser le système, ignorer, remplacer ou inverser sa sortie, et l’interrompre de manière sécurisée. En pratique, la supervision n’est réelle que si le professionnel peut le faire sans friction disproportionnée. Il faut définir qui arbitre, comment documenter la divergence et comment signaler un incident. Un bouton de refus ne suffit pas si l’organisation pénalise ceux qui s’en servent.

5. Est-elle utile au patient ?

L’information du patient explique le rôle du système dans sa prise en charge, sans lui transférer l’interprétation technique : finalité, données mobilisées, place du professionnel, principales limites, droits applicables. Le guide HAS-CNIL propose une bonne pratique simple : ajouter dans le compte rendu une phrase indiquant le système utilisé, sa version et le médecin qui a validé le document. Il rappelle aussi que le règlement européen donne aux personnes concernées par une décision fondée sur un système à haut risque le droit d’obtenir des explications claires sur le rôle joué par l’IA (article 86).

6. Reste-t-elle valide après une mise à jour ?

Une mise à jour du modèle, du logiciel, du capteur ou du parcours peut modifier les résultats. L’établissement doit connaître la version utilisée, surveiller les performances et réévaluer les explications. La dérive peut venir des données ou des pratiques, pas seulement du code.

Le guide HAS-CNIL est net : en l’état des textes, toute décision entièrement automatisée est exclue en contexte de soins, et toutes les décisions de prise en charge prises à l’aide d’un système d’IA doivent faire l’objet d’une supervision humaine par le professionnel qui suit la personne. Il rappelle qu’aucun régime de responsabilité propre à l’IA n’existe à ce jour pour les professionnels : celui qui utilise l’outil répond de l’usage qu’il en fait et du degré d’autonomie qu’il lui accorde.

Cela suppose des responsabilités explicites : qui reçoit le résultat, qui décide, qui répond à une alerte, qui suit les incidents et qui peut suspendre l’outil. Pour les systèmes à haut risque, le déployeur vérifie que les personnes chargées du contrôle humain ont la compétence, la formation, l’autorité et le soutien nécessaires. Le guide cite aussi les risques à anticiper : surconfiance, ancrage algorithmique, biais d’automatisation, perte d’expertise humaine.

Une procédure utile précise enfin les délais. Une alerte très sensible mais impossible à traiter dans le temps imparti donne une fausse impression de sécurité ; un système trop intrusif alimente la fatigue d’alerte clinique. L’explication se conçoit donc avec le flux de travail.

C’est le principe de MyTwin pour les cliniciens. Le jumeau numérique du patient, alimenté par les données de vie réelle entre les consultations, éclaire le suivi ; le clinicien garde l’interprétation et la décision.

Un comité pluridisciplinaire peut rassembler :

• la documentation du fournisseur et la version du modèle ;
• l’analyse du besoin clinique et des alternatives ;
• la validation sur des données représentatives ;
• l’analyse des risques et de la protection des données ;
• les scénarios de mésusage et de contournement ;
• les tests de compréhension avec les utilisateurs ;
• le plan de formation et de support ;
• les indicateurs de performance, d’équité et de sécurité ;
• le journal des modifications et des incidents ;
• les critères de suspension ou de retrait.

Côté données personnelles, le guide HAS-CNIL rappelle que le déployeur est, dans la plupart des cas, responsable du traitement : registre des traitements, analyse d’impact relative à la protection des données le cas échéant, information des patients sur l’usage de leurs données. Toute réutilisation des données pour entraîner ou évaluer un modèle constitue un traitement distinct. L’explicabilité ne remplace pas la conformité au RGPD.

Côté incidents, un système d’IA qui a le statut de dispositif médical relève de la matériovigilance : un incident grave se déclare à l’ANSM. Pour les outils qui n’ont pas ce statut, le guide recommande un circuit de signalement vers le fournisseur et une procédure interne d’« algorithmovigilance » lorsque le risque clinique est important.

Après le déploiement, l’équipe observe le taux d’utilisation, les désaccords, les délais, les faux positifs et faux négatifs connus, les cas d’abstention, les incidents et le ressenti des utilisateurs. Elle vérifie si l’outil modifie les décisions comme prévu ou s’il crée de nouveaux contournements. L’OMS demande d’ailleurs que concepteurs, développeurs et utilisateurs évaluent les applications d’IA de façon continue et transparente pendant leur usage réel.

Une revue régulière compare les performances aux conditions initiales, par site et par sous-groupe cliniquement pertinent. Si l’établissement n’a pas les données nécessaires pour conclure, il le dit, limite l’usage et recueille les preuves manquantes.