Six dimensions pour évaluer ce que presque personne ne mesure
La question prédominante dans la littérature, les congrès et les appels à projets reste : comment améliorer la performance du modèle ? Cette focalisation, légitime au stade technologique initial, devient problématique lorsqu’elle retarde l’examen des conditions architecturales de déploiement. La performance d’un modèle n’est pas un invariant objectif — elle dépend du benchmark retenu, souvent monocentrique, rétrospectif, nettoyé du bruit clinique réel. Le changement d’unité d’analyse est décisif : on ne part plus de l’algorithme pour chercher son point d’insertion, mais du système socio-technique réel pour identifier où une capacité algorithmique peut réduire une incertitude spécifique sans générer de complexité supérieure au gain. Le même modèle, inséré dans deux architectures différentes, produira des effets radicalement différents — non parce que l’algorithme change, mais parce que le système dans lequel il opère change.
Une IA ne s’insère pas dans « la décision médicale » en général. Elle s’insère dans une topologie décisionnelle spécifique. Quatre configurations minimales : décision individuelle synchrone (urgence), individuelle asynchrone (consultation programmée), collégiale synchrone (RCP, staff), distribuée asynchrone (parcours chronique multi-acteurs). Chaque contexte se décrit par un triplet minimal — D (durée par cas), N (nombre d’acteurs), L (tolérance à la latence). En RCP oncologique (D≈5 min, N≈6-10, L≈0), un outil nécessitant trois minutes d’explication dans un créneau de cinq minutes ne sera pas adopté. L’incompatibilité n’est pas algorithmique, elle est topologique. La même recommandation, inacceptable en RCP, peut s’intégrer sans friction en consultation de médecine générale (D≈15-20 min, N=1, L modérée).
Le clinicien effectue implicitement un calcul : T_net = T_restitué − (T_apprentissage + T_intégration + T_évaluation + T_coordination). Si T_net est durablement négatif, l’outil ne sera pas intégré quelle que soit sa performance statistique. Ce critère est falsifiable et mesurable en conditions réelles d’usage, interruptions comprises. À l’hôpital, le ROI dépend de l’échelle d’observation — clinicien, service, établissement, territoire — et ces niveaux ne convergent pas nécessairement. Celui qui investit n’est pas toujours celui qui bénéficie. Un couplage fort augmente les coûts de maintenance et de PRA, une dépendance contractuelle limite la capacité de négociation, une absence de réversibilité transforme un investissement initial en contrainte structurelle.
Un chirurgien hésite entre deux stratégies opératoires, un oncologue est confronté à un profil atypique en deuxième ligne. Dans ces situations, la valeur clinique ne se mesure pas en minutes gagnées mais en incertitude réduite. Le delta d’incertitude ΔI = I_avant − I_après peut être approché par la variance inter-cliniciens, le taux de discordance en RCP, la fréquence de requalification diagnostique. Un outil peut augmenter légèrement le temps de décision mais être accepté si la réduction d’incertitude est substantielle. Le cadre devient bidimensionnel : temps et entropie décisionnelle. Une IA est pertinente si elle améliore l’un ou l’autre sans dégrader excessivement l’autre.
Le couplage décrit le degré d’interdépendance structurelle entre le composant IA et le SI existant. Trois configurations types : encapsulé (couplage faible — composant autonome, API-first, désactivable sans altération majeure, comme TweenMe), intégré (couplage modéré — IA embarquée dans une application existante, contrainte par le cycle de vie de l’éditeur), diffus (couplage fort — IA distribuée fonctionnellement dans plusieurs couches applicatives, comme l’architecture agentique de PREDICARE). Mais le couplage doit être évalué sur trois plans : technique, contractuel et réglementaire. Un composant techniquement encapsulé peut rester fortement couplé contractuellement. Règle de conception : le degré de couplage doit être proportionnel à la maturité de preuve du modèle et à la criticité de la décision supportée.
L’erreur classique : évaluer l’impact uniquement du point de vue de l’utilisateur final. L’IA génère une charge distribuée — clinicien (cognitive, temporelle), DSI (intégration, maintenance, monitoring, cybersécurité, coordination multi-éditeurs), gouvernance (conformité réglementaire, documentation technique, surveillance post-market), organisationnelle (formation, conduite du changement), souveraineté (infrastructure, localisation des données, dépendance stratégique). Le TCO rarement calculé en amont inclut les coûts d’intégration, de maintenance continue, réglementaires et de réversibilité. Un outil peut avoir un T_net positif localement et rester globalement non viable si la charge DSI ou réglementaire excède la capacité organisationnelle. L’erreur plus profonde encore est de ne pas penser a priori les moyens de la mesure de l’efficacité médico-économique.
Un système clinique est un système critique. L’introduction d’un composant IA ne doit jamais transformer une assistance en point de défaillance unique. Trois exigences : réversibilité fonctionnelle (le système doit pouvoir fonctionner sans le composant IA, plan de retrait formalisé et testé en simulation), redondance et continuité d’activité (multi-nœuds, PRA et PCA intégrant explicitement le composant IA, délais de bascule compatibles avec la criticité clinique), dégradation gracieuse (monitoring continu, seuils explicites d’alerte, réduction progressive du périmètre d’intervention). Un modèle indisponible est visible ; un modèle dégradé silencieusement est dangereux. La dégradation gracieuse doit être testée périodiquement comme un exercice incendie.
Ces six dimensions forment un système de contraintes couplées. Zone de fragilité structurelle : T_net négatif dans la topologie cible, couplage fort avec modèle à maturité faible, absence de PRA intégrant le composant IA, réversibilité non testée, charge DSI non compensée. Zone d’expérimentation acceptable : couplage faible ou encapsulé, topologie individuelle ou asynchrone, monitoring actif du drift, réversibilité testée périodiquement. Un déficit sévère sur une seule dimension suffit à compromettre l’ensemble. Ce cadre n’est pas un outil anti-technologie — c’est un outil anti-déploiement naïf. La fiche bristol ne demande pas de cadre en six dimensions : elle fonctionne, elle est disponible, elle ne plante pas, elle ne peut pas être rançongiciellisée. Elle survivra tant que le numérique n’offrira pas un niveau de robustesse équivalent.