IA en régulation d'urgence : 7 questions à poser avant tout déploiement

En août 2025, la DGOS a sélectionné 74 établissements pour 78 projets lauréats parmi 147 candidatures à son appel à manifestation d'intérêt "Intelligence artificielle aux urgences", dont plusieurs projets de détection automatisée d'AVC et d'infarctus lors des appels SAMU. Quatre mois plus tard, un premier déploiement national est annoncé, alors que l'expérimentation n'est pas terminée.

Pour les DSI hospitaliers, cette accélération pose une question stratégique : comment évaluer la maturité réelle d'une solution IA avant de l'intégrer dans un environnement aussi critique qu'une régulation d'urgence ? Entre validation scientifique, conformité réglementaire, architecture technique, capacité d'industrialisation et modèle économique, sept critères permettent de structurer une analyse de risques rigoureuse, qu'il s'agisse d'un projet financé par fonds publics ou d'un appel d'offres classique.

1. Validation scientifique : la publication comme preuve de maturité

Les solutions d'IA en régulation médicale se multiplient, mais toutes ne présentent pas le même niveau de validation clinique. L'exemple de référence reste Corti (Danemark) : publication Resuscitation 2019, étude 108 000 appels, sensibilité 95% vs 72,5% humains, gain 10 secondes = 7-10% chances survie supplémentaires¹.

Cette transparence scientifique permet aux établissements d'évaluer objectivement :

●  La sensibilité et spécificité documentées dans des conditions réelles d'utilisation

●  Le nombre d'appels traités pendant la phase pilote (une centaine ? plusieurs milliers ?)

●  Le taux de faux positifs tolérable avant surcharge cognitive des régulateurs

●  Le caractère monocentrique (un seul SAMU) ou multicentrique de l'étude

Recommandation  : Avant tout POC, exiger systématiquement :

1. Une publication preprint (arXiv, medRxiv) ou peer-review dans une revue médicale reconnue
2. L'accès au protocole d'étude clinique (cohorte, comparateur, endpoints primaires et secondaires)
3. Une transparence explicite sur les limites de la solution (cas non couverts, pathologies exclues, biais de l'algorithme)

Si la startup refuse de communiquer ces éléments, c'est un red flag majeur sur la maturité TRL (Technology Readiness Level) de sa solution, indépendamment de son discours commercial ou de sa sélection dans un AMI public.

2. Architecture technique : ASR et conformité RGPD

La retranscription automatique de la parole (ASR, Automatic Speech Recognition) est au cœur des solutions d'IA appliquées aux appels SAMU. Deux architectures coexistent :

●  Les modèles propriétaires, entraînés spécifiquement sur des corpus d'appels SAMU français (accents régionaux, bruits ambiants, terminologie médicale profane)

●  Les APIs tierces (Whisper d'OpenAI, Google Speech-to-Text, Amazon Transcribe), plus rapides à intégrer mais posant un risque réglementaire critique

L'usage d'APIs tierces comme Whisper d'OpenAI soulève une question RGPD centrale : les données d'appels SAMU constituent des données de santé sensibles (article 9 RGPD). Tout transfert hors UE nécessite des garanties appropriées au sens de l'article 46 du RGPD². Si l'éditeur utilise des serveurs situés hors UE sans cadre juridique adapté (clauses contractuelles types, certification, ou EU-US Data Privacy Framework selon les cas), l'établissement encourt une responsabilité réglementaire, avec amendes pouvant atteindre 4% du CA mondial ou 20 millions d'euros.

Questions techniques à poser systématiquement à l'éditeur :

1. L'ASR repose-t-elle sur un modèle propriétaire ou une API tierce ? Si tierce, laquelle exactement ?
2. Où sont hébergées physiquement les données d'appels ? (La certification HDS, Hébergeur de Données de Santé, est obligatoire en France)
3. Combien d'heures de corpus d'entraînement spécifique français SAMU ont été utilisées ?
4. Quel WER (Word Error Rate, taux d'erreur de reconnaissance) est documenté ? À titre de référence, les seuils couramment visés en environnement médical sont inférieurs à 5%, là où les ASR généralistes affichent généralement 10 à 15%

Recommandation actionnable : Imposer contractuellement un audit de l'architecture technique avant signature, réalisé par un tiers de confiance (pas d'autodéclaration). Exiger une clause interdisant explicitement l'usage d'APIs hors UE sans validation préalable du DSI et du DPO.

3. Ergonomie en système critique : le piège du "second écran"

Les régulateurs SAMU gèrent en moyenne 10 à 20 appels par heure en période de tension, avec des tâches simultanées complexes : écoute active de l'appelant, saisie dans le DRM (Dossier de Régulation Médicale), décision d'envoi de moyens, coordination avec les équipes terrain. Ajouter une interface IA constitue un risque ergonomique documenté en environnement critique.

Trois risques majeurs documentés en environnements critiques :

● L'attention divisée : gérer simultanément deux écrans peut générer une surcharge cognitive de l'ordre de 30% selon la littérature en ergonomie des systèmes critiques (source : Human Factors, revue de référence)

● L'automation bias : la sur-confiance dans les alertes automatiques peut conduire à ne plus réévaluer cliniquement un cas (exemple : "douleur thoracique" détectée par l'IA, mais le patient décrit en réalité une côte fêlée après une chute)

● La pollution informationnelle : si le taux de faux positifs dépasse un seuil de l'ordre de 20-30%, l'IA peut devenir une source de distraction plutôt qu'une aide décisionnelle

Questions ergonomiques critiques à poser avant déploiement :

1. L'interface IA est-elle intégrée nativement au DRM existant, ou s'agit-il d'un overlay séparé (second écran) ?
2. Des tests utilisateurs ont-ils été menés avec de vrais régulateurs SAMU en conditions réelles (pas uniquement des démos commerciales) ?
3. La solution a-t-elle été validée par des ergonomes spécialisés en systèmes critiques (certification type aéronautique) ?

Recommandation actionnable : Imposer un POC de minimum 3 mois avec 5 à 10 régulateurs testeurs représentatifs. Mesurer systématiquement : temps de décision, charge cognitive (via questionnaire NASA-TLX), taux de faux positifs observés, acceptabilité utilisateurs. Prévoir une clause de résiliation si le taux de faux positifs dépasse un seuil défini contractuellement. À titre d'exemple, certains établissements retiennent 20-25% comme limite acceptable, mais ce seuil doit être adapté au contexte opérationnel du SAMU.

4. Conformité réglementaire : marquage CE et classe de dispositif médical

Une solution d'IA détectant automatiquement des AVC ou infarctus lors d'appels d'urgence constitue un dispositif médical logiciel au sens du règlement européen MDR (Medical Device Regulation, UE 2017/745)³. Selon la règle 11 du MDR, les logiciels fournissant des informations pour prendre des décisions à des fins diagnostiques ou thérapeutiques sont généralement classés au minimum en IIa (parfois IIb selon le risque patient). La classification en Classe I (auto-certification) est rarement applicable pour ce type de solution, sauf si l'éditeur peut justifier que le logiciel n'influence pas directement la décision médicale.

Deux voies de certification existent : Classe I (auto-certification, 3-6 mois) ou Classe IIa/IIb (audit par organisme notifié GMED/TÜV/BSI selon norme ISO 14971).

Questions réglementaires à poser systématiquement :

1. Le marquage CE a-t-il été obtenu ? Sous quelle classe de dispositif (I, IIa, IIb) ?
2. Sur quelle base réglementaire l'éditeur a-t-il justifié sa classification ? (Règle 11 MDR explicitement adressée ?)
3. Quel organisme notifié a audité la solution ? (Vérifiable sur la base de données publique EUDAMED⁴)
4. Le dossier technique ISO 14971 (analyse de risques cliniques) est-il disponible pour audit par l'établissement ?

Recommandation : Avant toute signature de contrat, exiger le certificat de marquage CE (pas uniquement une mention sur le site web). Vérifier systématiquement sur EUDAMED l'existence réelle de cette certification. Si la solution est classée I uniquement, demander une justification écrite expliquant pourquoi elle n'a pas été soumise à audit externe conformément à la règle 11 du MDR.

Point d'alerte critique : Le déploiement d'une solution sans marquage CE dans un CHU est illégal, au même titre que l'utilisation d'un dispositif médical non certifié.

5. Scalabilité et méthodologie d'industrialisation

Un POC réussi dans un SAMU ne garantit pas une généralisation nationale. La scalabilité repose sur trois piliers techniques :

1. Entraînement continu : Un modèle IA se dégrade sans actualisation régulière. Un modèle entraîné sur des appels SAMU parisiens en 2024 perdra en performance s'il est déployé en 2026 dans des SAMU ruraux sans ré-entraînement spécifique.

Questions clés : L'éditeur dispose-t-il d'une plateforme de réentraînement adaptatif ? Quelle fréquence minimale recommandée ? Quel volume de données d'appels est nécessaire pour adapter le modèle à un nouveau site (100 ? 1 000 ? 10 000 appels) ?

2. Gestion de versions : En environnement critique, toute mise à jour doit être réversible instantanément en cas de dysfonctionnement.

Questions clés : L'éditeur propose-t-il un mécanisme de rollback automatique ? Les mises à jour sont-elles testées en environnement de pré-production ? Quel SLA (Service Level Agreement) garanti en cas d'incident majeur (restauration en moins de 2h ? 4h ? 24h) ?

3. Infrastructure cloud : Passage de 50 régulateurs simultanés (un SAMU moyen) à 500 (déploiement national) : les besoins en puissance de calcul, latence réseau et bande passante évoluent de manière non linéaire.

Questions clés : L'architecture est-elle cloud-native avec auto-scaling ? Quelle latence maximale garantie contractuellement entre la fin de l'appel et la détection IA (2s ? 5s ? 10s) ? En cas de panne Internet, existe-t-il un mode dégradé fonctionnant en local (edge computing) ?

Recommandation : Exiger un plan d'industrialisation documenté incluant : roadmap technique de déploiement multi-sites, protocole de réentraînement adaptatif, stratégie de gestion de versions, architecture cloud et SLA détaillés. Si l'éditeur ne peut produire ces documents, c'est un indicateur que la solution reste au stade prototype pilote, pas produit industrialisable.

6. Modèle économique : TCO et réversibilité contractuelle

Le coût de licence annoncé par un éditeur ne reflète jamais le coût réel sur 3 à 5 ans. L'analyse du TCO (Total Cost of Ownership) doit intégrer : licence initiale, coûts d'intégration au SI existant (connecteurs DRM, interfaces SMUR), maintenance annuelle (15-20% de la licence), formations utilisateurs, support technique interne, et évolutions réglementaires futures (mises à jour AI Act, MDR).

Questions économiques à poser avant contractualisation :

1. Quel est le TCO réel sur 3 ans, intégration SI comprise ?
2. En cas de changement d'éditeur, quelles garanties de portabilité des données ? (Export historique appels dans un format standard HL7/FHIR ?)
3. Quelles sont les clauses de sortie du contrat ? (Préavis, récupération des données, migration technique)
4. Existe-t-il un risque de vendor lock-in via des APIs propriétaires non documentées ?

Recommandation  : Exiger systématiquement un TCO détaillé avant candidature à un AMI ou appel d'offres. Imposer contractuellement une clause de réversibilité garantissant la portabilité des données dans un format interopérable. Benchmarker au minimum 2 à 3 solutions concurrentes, même si l'AMI public liste des "lauréats recommandés", aucune procédure publique n'impose une exclusivité commerciale.

7. Gouvernance de l'expérimentation : généraliser avant évaluation ?

L'AMI DGOS "Intelligence artificielle aux urgences" a été lancé en juin 2025, avec sélection de 74 établissements pour 78 projets lauréats en août 2025 parmi 147 candidatures⁵. La note de cadrage prévoyait des expérimentations jusqu'en mars 2026. Pourtant, dès décembre 2025, certaines solutions annoncent leur généralisation dans plusieurs SAMU avant la fin de la période d'évaluation.

Les Hospices Civils de Lyon ont annoncé un déploiement d'IA en régulation SAMU prévu début 2026⁶, en partenariat avec une startup lauréate de l'AMI selon la presse spécialisée⁵. Ce choix s'inscrit dans une stratégie globale d'intégration de l'IA aux HCL, couvrant également la radiologie, l'oncologie et la prédiction de réhospitalisation. Cependant, aucun résultat chiffré de l'expérimentation préalable n'est publié : combien d'appels ont été traités en phase pilote ? Quelle sensibilité/spécificité documentée ? Quel taux de faux positifs observé ? Ces données, essentielles pour que d'autres établissements puissent benchmarker la solution, restent absentes de la communication institutionnelle.

Selon le Dr Yann-Maël Le Douarin, chef du département "santé et transformation numérique" à la DGOS, l'AMI a suscité un engouement inattendu : "Nous pensions faire un flop avec 10 candidatures, ça a été l'inverse." Cette temporalité soulève deux questions : comment généraliser avant consolidation des 78 expérimentations ? Quels critères ont justifié l'accélération d'un lauréat vs 73 autres établissements ? Les critères initiaux (calibrés pour 10 candidatures) étaient-ils pertinents face à 147 dossiers évalués en quelques semaines ?

Cette interrogation n'est pas une critique de l'innovation, mais une exigence d'efficience de la dépense publique. Les administrations françaises ont historiquement pâti d'un manque d'auto-apprentissage : financer des projets innovants sans évaluation intermédiaire rigoureuse, puis recommencer les mêmes erreurs au cycle suivant faute de capitalisation collective.

Questions de gouvernance pour les DSI d'établissements "suiveurs" :

1. Les résultats chiffrés de l'expérimentation du site pilote sont-ils publiquement disponibles ?
2. Le premier établissement pilote a-t-il publié un retour d'expérience documenté ?
3. Combien d'autres établissements lauréats ont testé cette même solution, et avec quels résultats ? (Benchmarking entre pairs)

Recommandation de gouvernance interne : Pour tout CHU candidat à un déploiement post-expérimentation, créer un comité de pilotage pluridisciplinaire associant DSI, médecin urgentiste référent, DIM (Département d'Information Médicale), juriste et DPO. Exiger un audit indépendant (pas un cabinet conseil lié à la startup). Conditionner la généralisation à l'atteinte de 3 KPI mesurables définis contractuellement (exemples : temps moyen de détection, taux de faux positifs <25%, taux d'acceptabilité utilisateurs >70%).

L'innovation responsable commence par l'exigence méthodologique

Quatre principes structurants émergent de cette grille d'analyse :

1. La validation scientifique n'est pas une option : une publication peer-review constitue la preuve objective de maturité TRL, indépendamment du discours commercial ou de la sélection dans un AMI public.
2. La conformité RGPD n'est pas négociable : les données d'appels SAMU sont des données de santé sensibles. Tout transfert hors UE sans garanties appropriées engage la responsabilité pénale de l'établissement.
3. La scalabilité technique conditionne le ROI : un POC réussi n'est pas un produit industrialisable. Exiger un plan d'industrialisation documenté protège l'établissement contre les dérives budgétaires et les déceptions opérationnelles.
4. La gouvernance de l'expérimentation conditionne l'apprentissage collectif : généraliser une solution avant consolidation des résultats d'évaluation constitue un risque financier et sanitaire que l'administration ne peut se permettre de reproduire indéfiniment.

L'IA en environnement critique (SAMU, réanimation, bloc opératoire) nécessite le même niveau d'exigence qu'un dispositif médical implantable. Les DSI hospitaliers ont aujourd'hui l'opportunité historique de structurer une doctrine d'évaluation IA transposable à tous leurs projets : pas pour freiner l'innovation, mais pour garantir que l'argent public finance des solutions réellement matures, évaluées et industrialisables.

Les établissements pionniers ont une responsabilité d'exemplarité méthodologique : publier leurs résultats, partager leurs difficultés, documenter leur ROI. C'est cette transparence collective qui permettra à l'écosystème e-santé français de capitaliser, plutôt que de répéter les mêmes erreurs à chaque nouveau cycle d'innovation.

"L'innovation en santé ne se mesure pas à la rapidité de déploiement, mais à la rigueur de l'évaluation. Les patients, et les finances publiques, méritent mieux que des promesses non tenues."

Sources et références

¹ Blomberg, S.N., et al. (2019). "Machine learning as a supportive tool to recognize cardiac arrest in emergency calls." Resuscitation, 138, 322-329.
 https://pubmed.ncbi.nlm.nih.gov/30817966/

² Règlement (UE) 2016/679 du Parlement européen et du Conseil (RGPD), Articles 9 et 46. Le cadre EU-US Data Privacy Framework (2023) permet certains transferts vers les États-Unis sous conditions. Cependant, pour des données de santé sensibles, la CNIL recommande une analyse au cas par cas et privilégie l'hébergement UE (certification HDS).
 https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32016R0679

³ Règlement (UE) 2017/745 du Parlement européen et du Conseil (MDR - Dispositifs Médicaux), notamment Règle 11 relative à la classification des logiciels médicaux
 https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32017R0745

⁴ Base de données européenne EUDAMED (vérification marquage CE dispositifs médicaux)
 https://ec.europa.eu/tools/eudamed

⁵ Données DGOS (août 2025) : 147 candidatures, 74 établissements retenus pour 78 projets expérimentaux. Le Point, "L'IA au secours des urgences médicales", 9 décembre 2025
 https://www.lepoint.fr/sante/l-ia-au-secours-des-urgences-medicales-09-12-2025-2605007_40.php

⁶ Hospices Civils de Lyon, "L'intelligence artificielle et les données au service de la transformation du CHU", décembre 2025
 https://teamhcl.chu-lyon.fr/lintelligence-artificielle-et-les-donnees-au-service-de-la-transformation-du-chu