Supervision de l'IA à l'hôpital : ce qu'il faut avoir organisé avant août 2026

Ce que l’article 14 impose - et ce qu’il laisse ouvert

L’article 14 de l’IA Act s’applique aux systèmes d’IA à haut risque tels que définis par le règlement. Dans le champ hospitalier, cela concerne notamment les systèmes d’aide au diagnostic, d’interprétation d’imagerie médicale et de priorisation des soins aux urgences. L’obligation est formulée en termes fonctionnels : les déployeurs doivent mettre en place une supervision humaine réellement opérante, assurée par des personnes disposant des compétences, de la formation et de l’autorité nécessaires.

Ce que le règlement ne précise pas est aussi important que ce qu’il prescrit. Il ne crée pas de métier unique, ne nomme aucun titre professionnel, n’impose pas de certification dédiée. Il laisse aux établissements le soin de traduire cette obligation en organisation concrète. Cette souplesse est à la fois une liberté et un risque : liberté d’adapter la réponse au contexte local, risque d’interprétations trop minimales qui ne résisteraient pas à un contrôle de conformité.

L’article 26 complète ce dispositif en définissant les obligations des déployeurs, dont font partie les établissements de santé qui acquièrent des systèmes d’IA développés par des tiers. Ils ne se substituent pas aux fournisseurs sur la conception, mais endossent la responsabilité de l’usage - ce qui rend la désignation d’un référent de supervision d’autant plus nécessaire.

Le vide français : entre fracture organisationnelle et shadow IT

Un premier décryptage publié en mars 2026 dans ces colonnes documentait un constat structurel : ni la nomenclature Cigref 2024 ni les référentiels métiers de la DGOS ne mentionnent de rôle hybride à l’interface clinique et algorithmique. Ce vide n’est pas une lacune administrative fortuite. Il reflète un modèle hospitalier construit sur une frontière nette entre DSI et services cliniques - frontière que l’IA rend de plus en plus difficile à maintenir.

L’enquête Symplr 2024 en mesure les conséquences opérationnelles : 40% des DSI placent la cybersécurité comme préoccupation principale, tandis que 51% des cliniciens identifient l’épuisement professionnel comme menace prioritaire. Ces deux groupes ne regardent pas le même problème. Dans 81% des établissements, les services développent du shadow IT en acquérant des solutions non validées par la DSI - signal d’une absence de traducteur entre les deux mondes, bien plus que d’une résistance au changement.

Les AMI lancés en 2025 par la DNS sur les urgences et la gestion des plannings (4 millions d’euros) illustrent cette tension systémique : ils financent l’acquisition de technologies sans créer les postes qui permettront d’en assurer la gouvernance dans la durée. Le calendrier réglementaire rend cette équation intenable à partir d’août 2026.

Ce qui se structure ailleurs - à des stades de maturité variables

La comparaison internationale révèle des approches différentes, à des niveaux de déploiement effectif très inégaux. Aucun modèle n’est directement transposable au contexte hospitalier français, mais chacun éclaire une dimension de la réponse possible.

Le modèle NHS Fellowship mérite une attention particulière : il ne crée pas un nouveau corps de métier, il forme des cliniciens en exercice à comprendre le cycle de vie algorithmique - des architectures de réseaux de neurones à la détection des dérives en production. C’est précisément le profil fonctionnel que l’article 14 décrit sans le nommer. Le programme Digi-HTA finlandais répond quant à lui à une autre question complémentaire : comment évaluer un système avant de le déployer, plutôt que de gérer ses défaillances après sa mise en service.

Trois scénarios pour vos établissements

L’obligation de l’article 14 peut être satisfaite par des configurations organisationnelles différentes. Les trois scénarios ci-dessous ne sont pas exclusifs : certains établissements combineront des éléments de chacun selon leur taille, leur portefeuille applicatif et leur maturité numérique.

Scénario A - Hybridation interne progressive. Un référent de surveillance IA est désigné par service déployant des outils à haut risque. Il s’agit d’un professionnel de santé déjà en poste - infirmier cadre, interne, praticien hospitalier - présentant une appétence numérique documentée, formé sur son temps de travail à la lecture critique des sorties algorithmiques, à la détection des biais et aux procédures d’escalade. Ce profil ne requiert pas de titre spécifique : la compétence prime. Cette configuration s’appuie sur l’existant sans créer de ligne budgétaire dédiée, ce qui la rend accessible rapidement. Sa limite est la fragilité : si la personne désignée change de poste, la continuité de surveillance n’est pas assurée structurellement.

Scénario B - Création d’un poste dédié. Un établissement disposant d’un portefeuille IA étendu - plusieurs applicatifs à haut risque dans différents services - peut justifier la création d’un poste transversal de type Clinical AI Coordinator ou Référent IA clinique. Ce profil, à l’interface DSI et direction médicale, assure la cohérence des pratiques de surveillance, l’actualisation des procédures et le lien avec les fournisseurs. Il suppose une description de poste précise, incluant des compétences en sciences des données et une connaissance concrète des workflows soignants, ainsi qu’une légitimité institutionnelle reconnue par les deux directions.

Ce profil n’est pas réservé au médecin : un cadre soignant, un ingénieur biomédical ou un pharmacien hospitalier disposant d’une culture algorithmique solide peut l’occuper avec une légitimité équivalente. Ce qui manque n’est pas le vivier humain, c’est le cadre de reconnaissance. Aucun référentiel français ne décrit aujourd’hui les compétences attendues d’un Référent IA clinique ou d’un chef de projet e-santé spécialisé en gouvernance algorithmique. Des DU de santé numérique et des formations d’écoles d’ingénieurs commencent à couvrir partiellement ce champ, sans socle commun ni certification reconnue par les employeurs hospitaliers.

Scénario C - Mutualisation à l’échelle du GHT. Pour des établissements de taille intermédiaire ou des centres hospitaliers ne disposant pas des ressources internes nécessaires aux deux scénarios précédents, la mutualisation au niveau du GHT offre une alternative réaliste. Un pôle partagé de supervision IA - pouvant s’appuyer sur la DSI de territoire ou un groupement de coopération - assure un service mutualisé de surveillance et d’audit des systèmes à haut risque. Ce modèle s’aligne avec la logique des GHT et leur montée en compétence progressive sur le numérique.

Il présuppose toutefois une gouvernance claire sur la responsabilité finale. En cas d’incident, quelle direction locale porte la conformité IA Act ? Qui décide de l’arrêt temporaire d’un outil ? Qui documente la dérive et qui notifie le fournisseur ?

Au-delà du référent : instituer une gouvernance durable

Les trois scénarios précédents répondent à une question précise : qui supervise les systèmes d’IA à haut risque au quotidien ? Ils ne répondent pas à une question adjacente, tout aussi structurante : comment l’établissement pilote-t-il cette supervision dans la durée, en intégrant les dérives, les mises à jour algorithmiques et les incidents ?
L’article 14 exige une supervision humaine effective - ce qui implique une organisation capable de signaler, documenter et corriger, pas seulement un professionnel désigné. C’est la différence entre un référent et une gouvernance. La plupart des établissements qui ont franchi le premier pas n’ont pas encore construit le second.
La question transversale reste celle que les référentiels français n’ont pas tranchée : qui nomme le responsable IA d’un établissement, et sur quelle base de compétences ? Ni la nomenclature Cigref 2024 ni les référentiels DGOS ne décrivent ce profil.En l’absence de cadre, les établissements peuvent être tentés d’importer des définitions de poste issues des éditeurs eux-mêmes - ce qui déplace la gouvernance vers l’industriel plutôt que vers l’institution. L'enjeu n'est pas seulement organisationnel. Il est de résilience.

L’IA Act comme accélérateur, l’EHDS comme horizon

La question de la supervision humaine de l’IA n’est pas un problème technique. C’est un problème de gouvernance organisationnelle que les directions hospitalières doivent résoudre avant que la contrainte réglementaire ne les y oblige dans l’urgence. Les établissements qui anticipent - en formant leurs référents internes, en ajustant leurs fiches de poste, en construisant des protocoles de surveillance - se donnent les moyens d’aborder août 2026 avec une réponse documentée, pas une simple déclaration d’intention.
L’EHDS, dont les premières obligations opérationnelles s’échelonneront à partir de 2027, amplifiera ces enjeux en y ajoutant la dimension de la gouvernance des données d’entraînement et de la traçabilité transfrontalière des algorithmes.
Les établissements qui auront construit leurs compétences de supervision IA d’ici 2026 seront mieux positionnés pour absorber cette prochaine couche réglementaire sans reconstruction organisationnelle à chaque échéance.
La vraie question n’est pas de savoir si ces profils vont émerger en France. Elle est de savoir si les établissements hospitaliers les définiront en fonction de leurs besoins réels - ou s’ils attendront que la réglementation ou les fournisseurs leur imposent une réponse standard. L’article 14 laisse cette marge de manœuvre. Elle ne durera pas indéfiniment.

Repères réglementaires

• IA Act, article 14 (Human Oversight) : entrée en vigueur 2 août 2026 - artificialintelligenceact.eu
• IA Act, article 26 (Obligations des déployeurs) applicable aux établissements de santé acquéreurs de systèmes IA tiers - artificialintelligenceact.eu
• NHS Fellowship in Clinical AI, cohorte 5 (2026–2027) : nhsfellowship.ai
• Digi-HTA (FinCCHTA / Université d’Oulu) : European Journal of Public Health, oct. 2025, PMC12555797
• Symplr Workforce Report 2024 : symplr.com/reports
• Cigref Nomenclature 2024 : cigref.fr