Traçabilité et explicabilité des IA : un impératif en santé

En médecine, une décision sans traçabilité est une décision contestable. Un diagnostic posé sans raisonnement, un protocole suivi sans enregistrement, ce ne sont pas seulement des écarts procéduraux, ce sont des risques patients.

L'IA s'installe dans les dispositifs médicaux. Elle détecte, classe, recommande voire décide. Et là encore, une décision produite par un algorithme doit être aussi traçable et explicable qu'une décision humaine. C'est la condition de base pour qu'un clinicien puisse engager sa responsabilité, qu'un patient ait confiance en son traitement, et qu'un fabricant puisse défendre ce qu'il a mis sur le marché.

La bonne nouvelle, c'est que le corpus réglementaire des DM et l'IA Act sont, sur ce point, parfaitement alignés avec cette logique.

Le paradoxe de la boîte noire

Comme toujours, la conformité se démontre, elle ne s'affirme pas. Chaque décision de conception, chaque évaluation de risque, chaque vérification doit être traçable jusqu'à son origine selon un raisonnement logique.

Or, la plupart des outils IA grand public fonctionnent comme des boîtes noires : vous entrez une question, vous obtenez une réponse. C'est d'ailleurs la technologie en elle-même qui le veut. La chaîne de raisonnement qui a produit une réponse est par nature opaque, non reproductible, et souvent non vérifiable.

La question n'est donc pas seulement celle de la performance (les exemples ou les IA sur-performent les décisions humaines ne manquent pas), mais comment se reposer dessus sans craindre pour sa responsabilité.

Ce que les textes disent

Le corpus réglementaire DM n'a pas été conçu pour l'IA, mais il s'y applique aussi avec une certaine cohérence. Passons en revue les exigences clés, et leur traduction pour nous simples mortels.

MDR - Articles 10 et Annexe I Le MDR exige la traçabilité complète des décisions de conception et la documentation de la gestion des risques de façon démontrable. Appliqué à l'IA : chaque output produit par un système automatisé doit pouvoir être rattachées à un raisonnement documenté.

IEC 62304 - Cycle de vie du logiciel de DM La 62304 régit la conception, la vérification et la validation des logiciels de DM, et une IA embarquée est un logiciel de DM. Cela implique notamment : une classification du risque logiciel, des exigences de traçabilité entre les sorties du modèle et les spécifications fonctionnelles, et une documentation suffisante pour que la V&V soit répétable et opposable. Un modèle entraîné dont on ne peut pas expliquer les décisions est de facto très difficile à valider au sens de la 62304.

ISO 14971 — Gestion des risques L'ISO 14971 exige que chaque risque identifié soit évalué selon un raisonnement documenté, et que les mesures de maîtrise soient justifiées. Pour une IA qui intervient dans une décision clinique, cela soulève une question directe : comment évaluer le risque d'une décision erronée sans le raisonnement qui a produit cette décision ?

ISO 13485 - §8.2.1 et surveillance post-commercialisation Au-delà de la maîtrise documentaire, l'ISO 13485 exige un retour d'information systématique sur les performances du dispositif en conditions réelles. Pour une IA embarquée, cela implique de pouvoir détecter une dérive de comportement, ce qui suppose d'avoir documenté le comportement attendu de façon suffisamment précise pour identifier un écart.

IA Act - Articles 9, 12, 13, 50 et 86 L'IA Act classe les dispositifs médicaux explicitement dans la catégorie des systèmes IA à haut risque (Annexe III), avec des obligations qui se superposent au MDR.

Article 9: Le système de gestion des risques doit couvrir spécifiquement le système IA, documenté et maintenu tout au long du cycle de vie. Article 12: Les logs d'utilisation doivent être conservés automatiquement : dates, contexte d'utilisation, sorties produites. Article 13: La documentation technique du système doit permettre aux utilisateurs de comprendre ce que le système fait et dans quelles limites il est fiable. Article 50: Les utilisateurs doivent être informés qu'ils interagissent avec un système IA. Un clinicien qui consulte une recommandation générée par un algorithme doit en être explicitement averti. Article 86: Tout utilisateur soumis à une décision assistée par IA à haut risque peut exiger des explications sur le raisonnement sous-jacent. Ce droit est opposable, le fabricant engage sa responsabilité.

Les textes sont tous cohérence entre eux, tous exigent, sous des angles différents, que la décision algorithmique soit documentée, explicable et défendable.

Les techniques d'explicabilité : ce qui est réellement utilisable

Les bases posées, "on fait comment maintenant"? Voici les leviers d'explainable AI (XAI) que j'utilise, et tous sont bien entendu combinables et cumulables. Et pour appuyer mes dires, j'y joins des exemples de comment nous l'avons mis en place sur Gordios.

Justification par source C'est l'approche la plus évidente. On force l'IA à citer la donnée exacte qu'elle a utilisé pour parvenir à cette conclusion. Cela peut être des données intégrées en amont (un corpus scientifiques, des recommandations HAS, etc.) et/ou des données d'entrée (une zone sur une radio, un passage d'une conversation). Pour Gordios, chaque point de revue documentaire est appuyé par la source (l'exigence de la norme) ET le passage du document concerné.

Scoring de confiance On peut aussi établir des seuils pour un score de confiance (documentés dans le SMQ 😉 ), et exiger de l'IA à chaque décision qu'elle indique son degré de confiance dans le résultat. Il est d'ailleurs possible qu'un autre agent IA (un vérificateur), assigne se score indépendamment. En-dessous du seuil, on déclenche une alerte ou une revue manuelle. Gordios intègre un score de confiance déterminé par un agent IA différent, et tout résultat avec un score inférieur à 90% déclenche une revue manuelle du point de revue.

Chaîne de raisonnement décomposée Certains systèmes permettent de structurer le raisonnement de l'IA en étapes vérifiables. Chaque étape donne un résultat, mais le résultat global dépend d'un arbre décisionnel ou d'une autre passe séparée. Chaque étape peut donc être contrôlée indépendamment. Nous avons utilisé cette approche pour Gordios pour les vérifications complexes sur des normes multi-critères.

Le test logiciel Création de données synthétique, réalisation de jeux de tests en conditions réelles, etc. Rien de nouveau sous le soleil, le test logiciel reste la meilleure garantie d'un système de qualité.

L'obligation d'information : le point que beaucoup oublient

L'IA Act introduit une obligation souvent sous-estimée dans les contextes B2B: l'utilisateur doit explicitement être informé qu'il interagit avec une IA. Dans la pratique cela signifie que chaque résultat doit être labellisé comme produit par IA, de façon visible et non ambiguë. Et si ce résultat influence une décision clinique, l'Article 86 confère à l'utilisateur un droit opposable à l'explication du raisonnement sous-jacent.

Traçabilité : deux niveaux distincts à ne pas confondre

La traçabilité dans un contexte IA réglementaire opère sur deux niveaux qu'il est essentiel de distinguer.

• La traçabilité de l'outil: qui a lancé quelle analyse, sur quelle version, à quelle date, avec quel paramétrage. En somme un audit trail, "qu'est-ce qui a été fait et par qui ?"
• La traçabilité de la décision: pourquoi ce point est-il jugé conforme ou non conforme, "sur quelle base cette conclusion a-t-elle été produite ?"

Les deux sont nécessaires. La traçabilité de l'outil seule ne permet pas de défendre la conclusion. La traçabilité de la décision seule, sans log d'utilisation, ne satisfait pas l'Article 12 de l'IA Act, ni l'Article 22 du MDR sur la surveillance après commercialisation.

Conclusion

En Santé, traçabilité et explicabilité doivent être des caractéristiques de conception. En pratique cela signifie:

• Pointer vers le passage source exact pour chaque résultat produit
• Conserver un log horodaté et immuable de chaque exécution
• Indiquer clairement à l'utilisateur que le résultat provient d'une IA
• Documenter ses seuils de confiance et sa politique de traitement des cas limites
• Produire des résultats reproductibles sur le même document
• Tester, tester, et encore tester