Le moteur d'alerte de sepsis d'Epic a échoué à une validation en 2021 à Michigan Medicine, manquant les deux tiers des patients qui ont ensuite développé un sepsis, tout en déclenchant une alerte pour 18 % de toutes les admissions. Cette erreur provient d'un problème classique de fuite de données (data leakage) : le modèle comptabilisait la prescription d'antibiotiques par un médecin — déjà un signe de suspicion d'infection — comme un prédicteur, faisant essentiellement écho à une décision que le clinicien avait déjà prise.

Pourquoi le modèle a échoué

L'équipe du Michigan a examiné 38 455 séjours hospitaliers, soit la taille d'un projet typique d'amélioration de la qualité s'étalant sur plusieurs années. Les références internes d'Epic promettaient une grande précision, mais le test indépendant a montré le contraire. Les alertes « à haut risque » du modèle se sont déclenchées chez près d'un patient sur cinq, alors que les deux tiers des cas réels de sepsis sont passés inaperçus. En pratique, le système criait « attention » bien trop souvent tout en manquant les événements mêmes qu'il était censé détecter.

La cause profonde n'était pas un défaut de l'algorithme d'apprentissage automatique lui-même, mais des données qui lui étaient injectées. En utilisant la présence d'une prescription d'antibiotiques comme donnée d'entrée, le modèle a appris à prédire un choix déjà fait par le clinicien. Lorsque l'algorithme signalait un patient, c'était souvent parce que le médecin avait déjà prescrit des antibiotiques, et non parce que la physiologie du patient indiquait un sepsis imminent.

Un problème plus large dans l'IA hospitalière

Le modèle de sepsis d'Epic est déployé dans des centaines d'hôpitaux depuis des années, pourtant l'erreur de fuite est restée cachée jusqu'à ce qu'un effort de validation ciblé ne la mette au jour. Cet épisode illustre une faiblesse systémique : la plupart des projets d'IA des systèmes de santé manquent des contrôles opérationnels nécessaires pour détecter de tels problèmes précocement.

  • Absence de tests externes – Les hôpitaux n'avaient pas effectué de tests externes.
  • Absence de surveillance continue – Ils n'avaient aucun suivi.
  • Absence de responsabilité claire – Sans équipe désignée responsable de la qualité des données et de la performance du modèle, les problèmes passent entre les mailles du filet.

Ces lacunes maintiennent de nombreuses initiatives d'IA dans le « purgatoire des projets pilotes », ne dépassant jamais le stade de la preuve de concept.

Le coût caché de la fragmentation des données

Le cas du sepsis montre également comment la fragmentation des écosystèmes informatiques de santé sabote l'IA. Les obstacles courants incluent :

  • Des dossiers patients verrouillés dans des modules de DPI hérités qui n'échangent pas les données automatiquement.
  • Des systèmes d'imagerie et de laboratoire incapables de communiquer entre eux, imposant des transferts de fichiers manuels.
  • Des identifiants de patients en double qui fragmentent les données d'une même personne sur plusieurs dossiers.
  • Des notes cliniques et des signes vitaux stockés dans des silos séparés, jamais fusionnés pour l'entraînement du modèle.

Lorsqu'un modèle est entraîné sur un ensemble de données propre et organisé, mais qu'il est ensuite alimenté par des données réelles et désordonnées, ses performances se dégradent silencieusement. Les cliniciens perdent rapidement confiance ; une infirmière qui doit traquer les alertes à travers plusieurs écrans finira par les ignorer, même si l'algorithme sous-jacent est techniquement sain.

Quatre fondations « ennuyeuses » pour une IA fiable

Un déploiement d'IA fonctionnel repose sur quatre capacités pratiques qui font rarement la une des journaux :

  1. Interopérabilité – Les données doivent circuler entre les DPI, les laboratoires, les plateformes d'imagerie et les outils d'aide à la décision sans étapes manuelles d'exportation/importation.
  2. Gouvernance – Une personne ou une équipe responsable doit être garante de la qualité des données et surveiller les résultats du modèle au fil du temps.
  3. Intégration au flux de travail – Les alertes doivent apparaître dans le flux de travail existant du clinicien ; les clics ou les écrans supplémentaires nuisent à l'adoption.
  4. Opérations évolutives – Une surveillance automatisée, une analyse de la fatigue liée aux alertes et des pipelines de réentraînement périodiques sont essentiels avant que le modèle ne soit mis en production.

Sauter l'une de ces étapes laisse un projet vulnérable au type d'échec silencieux observé avec le modèle de sepsis d'Epic.

Questions à poser avant d'acheter une solution d'IA

Les hôpitaux peuvent éviter des erreurs coûteuses en exigeant des réponses concrètes :

  • Pouvez-vous tracer les données d'un seul patient à travers chaque système que le modèle utilisera ?
  • Qui, nommément, est responsable du maintien de la

Le modèle de sepsis d'Epic n'a pas échoué parce que l'apprentissage automatique est inadapté au milieu hospitalier ; il a échoué par manque de pipeline de données et de structures de gouvernance environnantes. Un modèle qui prédit la décision même d'un médecin nous avertit que c'est la couche d'ingénierie des données, et non l'algorithme, qui doit être améliorée. Développer une IA de confiance dans le secteur de la santé exige la même infrastructure « ennuyeuse » que celle qui assure le fonctionnement de tout système informatique critique : des données propres et interconnectées, une responsabilité claire, des alertes intégrées aux flux de travail et une surveillance proactive. Sans ces éléments, même le modèle le plus sophistiqué finira par envoyer des alertes erronées aux mauvaises personnes.