Le règlement (UE) 2026/1744 du 8 juillet 2026, l’« Omnibus numérique sur l’IA », a été publié au Journal officiel le 24 juillet et est entré en vigueur le 27. Il repousse au 2 décembre 2027 les obligations applicables aux systèmes d’IA à haut risque de l’annexe III, et au 2 août 2028 celles de l’annexe I.

Au sein de plusieurs établissements, la nouvelle a été lue comme un répit. C’est une lecture court-termiste, pour une raison simple : ce qui détermine la charge de conformité d’un CHU, ce n’est pas la date. C’est la qualification. Et un établissement qui développe son propre assistant d’IA n’est pas dans la même situation que celui qui achète une solution du marché.

Le règlement distingue le fournisseur, qui développe un système et le met sur le marché ou en service sous son nom, du déployeur, qui l’utilise sous sa propre autorité.

Les obligations du déployeur d’un système à haut risque sont réelles mais circonscrites : utiliser le système conformément à la notice, confier le contrôle humain à des personnes compétentes, formées et dotées de l’autorité nécessaire, surveiller le fonctionnement, signaler les incidents graves au fournisseur, conserver les journaux, informer les représentants du personnel avant une mise en service sur le lieu de travail, informer les personnes concernées par une décision assistée par le système.

Une obligation de déployeur mérite d’être signalée à part, parce qu’elle vise directement les CHU : l’analyse d’impact sur les droits fondamentaux de l’article 27. Elle incombe aux déployeurs qui sont des organismes de droit public, ce qu’est un établissement public de santé avant la première utilisation d’un système à haut risque. L’Omnibus ne l’a pas supprimée, contrairement à ce que la Commission avait proposé : il l’a articulée avec l’analyse d’impact relative à la protection des données du RGPD, en autorisant les renvois croisés et en chargeant le Bureau de l’IA de produire un questionnaire type. L’asymétrie entre les deux rôles reste franche, mais elle est moins nette qu’on ne le dit : le déployeur public porte une charge que le déployeur privé ne porte pas.

Les obligations du fournisseur sont d’un autre ordre : système de gestion des risques sur tout le cycle de vie, gouvernance des données d’entraînement, documentation technique, journalisation par conception, exactitude, robustesse et cybersécurité, système de gestion de la qualité, évaluation de la conformité, marquage, enregistrement dans la base de données européenne, surveillance après commercialisation.

Il n’existe pas encore de retour d’expérience public permettant de chiffrer l’écart pour un établissement de santé. Mais l’écart n’est pas de degré : le déployeur documente un usage, le fournisseur construit et maintient un dossier technique, un système qualité et un dispositif de surveillance. Ce sont deux métiers différents, et le second n’existe aujourd’hui dans presque aucun organigramme hospitalier.

L’article 25 prévoit qu’un déployeur devient fournisseur dans trois cas :

• il appose son nom ou sa marque sur un système à haut risque déjà mis sur le marché ;
• il apporte une modification substantielle au système, c’est-à-dire une modification non prévue par l’évaluation de conformité initiale et qui affecte sa conformité ou sa destination ;
• Il modifie la destination d’un système qui n’était pas à haut risque, de telle sorte qu’il le devienne.

À ces trois cas s’en ajoute un quatrième, plus structurant encore et souvent ignoré : un établissement qui développe un système et le met en service pour son propre usage est fournisseur au sens du règlement. La mise sur le marché n’est pas requise. L’usage interne suffit.

Plusieurs CHU s’engagent dans cette voie, avec des assistants conversationnels développés en interne, hébergés sur leurs propres infrastructures et intégrés au dossier patient informatisé. Sans préjuger de la qualification que chaque établissement retiendra pour son projet, la trajectoire est claire : on ne se contente plus d’utiliser de l’IA, on en produit.

La documentation lourde ne s’applique qu’aux systèmes classés à haut risque. Un assistant qui met en forme des comptes rendus, propose une reformulation ou aide à la structuration documentaire n’est pas, en lui-même, un système à haut risque. Les obligations se limitent alors à la transparence, informer l’utilisateur qu’il interagit avec une IA, marquer les contenus générés et au développement de la maîtrise de l’IA chez les utilisateurs.

Un point d’attention sur le modèle sous-jacent : un assistant bâti sur un grand modèle de langage tiers fait de l’établissement un fournisseur de système, pas de modèle. Les obligations des articles 51 à 55 restent chez l’éditeur du modèle. Un affinage substantiel peut déplacer cette frontière, mais l’intégration d’un modèle du marché, en elle-même, ne fait pas d’un CHU un fournisseur de modèle d’usage général.

D’où l’exercice utile : ne pas se demander « suis-je fournisseur ? » dans l’absolu, mais qualifier chaque système, un par un, sur deux axes, le rôle et le niveau de risque.

Par l’annexe I, lorsque le système d’IA est un dispositif médical, ou une composante de sécurité d’un dispositif médical, soumis à une évaluation de conformité par un organisme notifié au titre du règlement 2017/745.

Cette voie appelle une nuance qui intéresse spécifiquement les établissements de santé. L’article 6 (1) pose deux conditions cumulatives : relever d’un texte de l’annexe I, et être soumis à une évaluation de conformité par un tiers. Or l’article 5(5) du règlement sur les dispositifs médicaux dispense, sous conditions, les dispositifs fabriqués et utilisés au sein d’un même établissement de santé : pas de transfert à une autre entité juridique, système de gestion de la qualité, justification que l’offre du marché ne répond pas de manière adéquate aux besoins du groupe de patients visé, documentation. Un CHU qui développe et exploite en interne un outil d’aide au diagnostic pourrait donc, selon la lecture retenue, ne pas remplir la seconde condition. La question n’est pas tranchée et mérite l’avis d’un conseil, mais elle doit être posée : elle change entièrement le calibrage d’un projet.

Par l’annexe III, plusieurs points touchent directement l’hôpital :

• l’évaluation et la classification des appels d’urgence, la régulation et la priorisation des interventions de secours, ainsi que les systèmes de triage des patients en urgence ;
• l’évaluation de l’éligibilité aux prestations et services publics essentiels, y compris les services de santé ;
• les usages en matière d’emploi : recrutement, affectation des tâches sur la base de traits ou de comportements individuels, suivi et évaluation des agents. Un outil de planification qui répartit les postes selon des critères individuels entre dans ce champ.

Rappelons au passage que l’inférence des émotions sur le lieu de travail n’est pas seulement à haut risque : elle est interdite depuis le 2 février 2025, sauf raisons médicales ou de sécurité.

À l’inverse, l’essentiel des usages support : codage, facturation, achats, reporting qualité  n’y figure pas.

Un système listé à l’annexe III n’est pas considéré comme à haut risque s’il n’entraîne pas de risque significatif, parce qu’il accomplit une tâche procédurale étroite, améliore le résultat d’une activité humaine déjà achevée, détecte des constantes de décision sans se substituer à l’appréciation humaine, ou prépare une évaluation. Le profilage de personnes physiques ferme cette porte dans tous les cas.

Cette dérogation est précieuse. Mais elle ne se présume pas. La Commission avait proposé de supprimer l’obligation d’enregistrer les systèmes ainsi auto-évalués ; le Parlement et le Conseil l’ont refusée. L’enregistrement en base européenne reste dû, avec un jeu d’informations allégé. Autrement dit : une évaluation motivée, versée dans une base publique, et contestable.

C’est, à mon sens, le risque le plus mal couvert dans les projets hospitaliers actuels.

Le règlement ne s’applique pas aux systèmes développés aux seules fins de recherche et développement scientifiques, ni aux activités de R&D antérieures à la mise sur le marché ou en

service. Une expérimentation conduite dans un cadre de recherche, avec avis d’un comité d’éthique, peut donc légitimement se dérouler hors du champ du règlement. C’est une pratique documentée dans plusieurs établissements engagés dans l’évaluation clinique de leurs outils.

La difficulté se situe au passage à l’échelle. Le jour où le dispositif est ouvert aux services en production, le régime juridique change entièrement et rien, dans la conduite du projet, ne signale ce basculement. Pas de jalon, pas de livrable, pas de validation. L’établissement se réveille fournisseur d’un système en exploitation, sans dossier technique et sans système qualité.

Ce passage gagne à être instruit comme une étape à part entière, avec une décision formelle et une revue de qualification. C’est le point de contrôle le moins coûteux à mettre en place et le plus coûteux à omettre. 

Le Calendrier réel :

Trois précisions sur ce tableau.

L’article 4 a été réécrit par l’Omnibus. L’obligation n’est pas supprimée, mais elle passe d’un devoir de garantir un niveau suffisant de maîtrise de l’IA à un devoir de prendre des mesures pour en soutenir le développement, sans garantie d’un niveau individuel. Obligation de moyens, non de résultat. Elle n’est pas reportée, ne dépend d’aucune norme harmonisée, concerne tous les systèmes quel que soit leur niveau de risque, et ce qui sera demandé reste le même : un inventaire, une politique, des formations par rôle, et des traces datées reliant les trois.

Le 2 décembre 2026 concerne les CHU qui ont déjà ouvert un assistant génératif. Les systèmes mis sur le marché avant le 2 août 2026 disposent d’une transition pour le marquage lisible par machine de leurs sorties. Ceux lancés après s’y conforment dès le premier jour.

Les allègements de l’Omnibus ne vous concernent pas. Documentation technique simplifiée, système qualité proportionné, plafonds d’amendes réduits, accès prioritaire aux bacs à sable : ces mesures sont réservées aux PME et petites ETI. Un CHU n’y a pas droit. Le répit est donc plus relatif pour les établissements de santé que pour le reste de l’économie.

Sur les sanctions, une réserve utile : les plafonds de 35 M€ ou 7 % du chiffre d’affaires mondial font les titres, mais l’article 99(8) laisse aux États membres le soin de décider si et dans quelle mesure les amendes administratives s’appliquent aux autorités et organismes publics. Pour un établissement public, le risque immédiat est moins l’amende que l’injonction de mise en conformité, le retrait du service et l’exposition contentieuse.

Seize mois, à l’échelle d’un CHU, ce n’est pas un délai confortable. C’est à peu près le temps nécessaire pour instruire une cartographie, arbitrer un positionnement, construire une documentation technique et former des référents  à condition de commencer maintenant.

Pour chaque système, deux questions et une case.

	Hors haut risque	Haut risque
Déployeur	Transparence, maîtrise de l’IA, contractualisation.	Art. 26 + analyse d’impact sur les droits fondamentaux (art. 27).
Fournisseur	Transparence, maîtrise de l’IA, traçabilité des choix.	Régime complet : gestion des risques, données, documentation, qualité, conformité, enregistrement, surveillance.

La plupart des établissements rempliront les trois premières cases pour l’essentiel de leur parc, et la quatrième pour un ou deux systèmes. Ce sont ces un ou deux systèmes qui décident du budget.

Trois chantiers ne dépendent d’aucune échéance et conditionnent tous les autres.

• L’inventaire. Recenser les systèmes d’IA en usage, y compris ceux qui ne portent pas ce nom et ceux qui sont arrivés par les fonctions support ou par des initiatives de service.
• La qualification. Pour chacun : rôle de l’établissement, niveau de risque, et le cas échéant justification de la dérogation.
• La décision d’architecture. Acheter, co-développer ou internaliser n’est pas seulement un choix technique et budgétaire : c’est le choix de votre régime juridique pour les dix ans qui viennent.

Un mot sur le co-développement, qui est le cas le plus fréquent et le plus mal cadré. Peu de CHU développent seuls ; beaucoup construisent avec un prestataire. Si le partenaire commercialise sous son nom, l’établissement reste déployeur, mais il a fourni les données, et les exigences de gouvernance des données lui reviennent par le contrat. Le partage des rôles ne se déduit pas de qui a écrit le code : il s’écrit.

Enfin, la clause. L’article 25(2) prévoit que le fournisseur initial coopère avec le nouveau fournisseur et lui transmette les informations et l’accès technique nécessaires  sauf s’il a expressément exclu que son système soit transformé en système à haut risque. C’est une clause à porter dès aujourd’hui dans les CCAP et les contrats de licence. Elle ne coûte rien à la signature. Elle vaut un projet entier le jour où l’établissement doit reprendre un dossier technique qu’il n’a pas constitué.

La question du titre n’est donc pas rhétorique. Elle se tranche système par système, mais elle se tranche avant l’engagement technique et budgétaire pas après.