En santé, l’innovation est aujourd’hui au cœur des projets d’établissements, en particulier dans les CHU. L’IA générative s’installe dans les usages courants : rédaction et synthèse de documents, recherche documentaire. En outre, des projets internes plus ambitieux se développent en parallèle : accès aux soins, optimisation du parcours patient, plateaux techniques, prévention, recherche. Les perspectives d’amélioration de la qualité des soins et du parcours patient sont réelles. Je rappelle par ailleurs que les dispositifs médicaux numériques permettent déjà dans des domaines d’application variés de réaliser des diagnostics, d’avoir une aide au dépistage, mais aussi d’avoir une aide à décision médicale et thérapeutique. 

Mais l’utilisation de l’IA en santé modifie également en profondeur l’exposition des établissements face aux risques. Et c’est pour cela que la question de la continuité d’activité doit être menée de front avec celle de l’intégration de l’ IA au sein des établissements de santé. 

En matière de continuité d’activité, avec l’IA générative, deux nouveaux risques s’ajoutent à la cartographie des risques globaux de l’établissement :

• Un risque de défaillance silencieuse : l’outil reste disponible, mais il produit des résultats faux. Les causes possibles sont nombreuses : hallucination, dérive du modèle, corruption ou empoisonnement de la base de connaissances, surinterprétation. C’est un scénario à prendre en compte puisque globalement les dispositifs actuels ne savent pas ou ont du mal à le détecter.
• Un risque lié à la dépendance de l’établissement à l’IA : lorsque l’outil disparaît (cyberattaque, panne du fournisseur, coupure réseau), ce n’est plus seulement une application qui s’arrête ; c’est une aide à la décision et une capacité de production administrative dont les équipes ont pris l’habitude. Un risque réel de perte d’expertise humaine peut s’avérer réel. 

Le dernier référentiel de certification HAS version 2027 intègre les enjeux liés à l’IA avec deux critères dédiés. 

Le référentiel distingue deux familles d’outils :

• Le critère 3.4-05 (niveau standard) porte sur les dispositifs médicaux numériques à usage professionnel faisant appel à l’IA : aide au dépistage, au diagnostic, à la décision thérapeutique. Il s’inscrit explicitement dans le respect du règlement européen sur l’IA (AI Act). En guise d’exemple, les projets d’opérations assistées ou de traitements personnalisés rentrent dans cette catégorie..
• Le critère 3.4-06 (niveau avancé) porte sur les systèmes d’IA sans finalité médicale utilisés pour améliorer l’organisation. C’est ici que se situe l’essentiel de l’IA générative du quotidien. 

Un point mérite l’attention : la cartographie demandée doit viser à « éradiquer les usages non sécurisés ». Autrement dit, le shadow IA utilisé sans validation, est compris dans ce périmètre.

Les deux critères demandent une cartographie avec analyse des risques, une organisation structurée de l’acquisition, la formation des utilisateurs aux performances et aux limites des outils, et une supervision humaine en situation réelle.

En revanche, ils ne parlent ni de mode dégradé, ni de continuité. Ces exigences se trouvent ailleurs dans le référentiel : au critère 3.1-07 (PCRA formalisé, modes dégradés connus des équipes en cas d’incident numérique) et au critère 3.1-05, de niveau impératif (plans de gestion des tensions intégrant les risques numériques, exercices de la cellule de crise).

C’est précisément là que le PCRA joue son rôle de trait d’union. Un outil d’IA parfaitement cartographié au titre du 3.4 mais dont l’indisponibilité n’a jamais été anticipée reste un angle mort au titre du 3.1. Le tableau ci-dessous propose une lecture croisée :

Privilégier à minima, trois objectifs pour intégrer la résilience à la stratégie IA : 

1. Garantir la continuité des soins et des opérations : dimensionner les modes dégradés pour absorber la baisse de productivité en cas d’indisponibilité, mais aussi définir à partir de quel signal on cesse de faire confiance à l’outil.
2. Sécuriser les infrastructures de crise : assurer la disponibilité et l’intégrité des bases de connaissances critiques, avec des objectifs de reprise (RTO) et de perte de données admissibles (RPO) explicites.
3. Assurer la conformité réglementaire : répondre de manière proactive aux critères 3.4-05, 3.4-06, 3.1-05 et 3.1-07 du référentiel HAS et anticiper les obligations de l’AI Act, notamment le contrôle humain (art. 14) et les obligations des déployeurs (art. 26).

Puisqu’il faut commencer quelque part, le meilleur outil pour rendre concrète votre approche reste le BIA (Bilan d’Impact sur l’Activité) qui mesure l’impact de l’interruption d’une activité, quelle qu’en soit l’origine. 

Voilà comment je procéderai  :

• l’IA sera utilisée comme une ressource dont dépendent certaines activités. Le BIA doit identifier les activités prioritaires qui s’appuient sur un outil d’IA et en déduire la durée maximale d’interruption admissible (DMIA), le niveau minimal d’activité à maintenir, puis les RTO (délai de reprise) et RPO des activités concernées. 
• En addition dans le cadre de cette démarche, ce serait une lapalissade de dire que l’IA devrait-être analysée comme cause probable de perturbation. Cette question, en général, ne devrait pas uniquement relever du BIA mais aussi de l’appréciation des risques prévue par l’ISO 22301, dans la logique de l’ISO 31000 (Management du risque). C’est le lieu privilégié parmi d’autres pour analyser les menaces propres à l’IA : indisponibilité du fournisseur, dérive, données corrompues, attaque ciblée sur le modèle.

Pour cette seconde approche, les référentiels autour de la continuité d’activité ne suffisent pas. L’ISO 42001 (système de management de l’IA) et l’ISO 23894 (déclinaison de l’ISO 31000 aux risques de l’IA) peuvent vous apporter le cadre manquant.

Les deux normes ISO 22301 et 42001 partagent la structure harmonisée de l’ISO. Elles s’articulent donc naturellement dans un système de management intégré :

L’intérêt est double : un seul cadre de référence et un dialogue structuré entre le responsable PCRA, le RSSI, le DPO et la Direction qualité.

Voici quelques préconisations pour intégrer vos enjeux IA à votre stratégie de continuité. 

• Étape 1 : intégrer le volet IA au BIA. Cartographier la dépendance des services prioritaires aux outils d’IA, déployés ou en projet. Sans oublier les fournisseurs : API externes, hébergement cloud et HDS, réversibilité, engagements contractuels de niveau de service. Une bonne cartographie bien menée pourrait aussi servir de de socle aux critères 3.4-05 et 3.4-06, à condition d’y inclure la question des usages non déclarés.
• Étape 2 : mettre à jour le corpus documentaire PCRA. Rédiger et valider les procédures de contournement manuel (le travail « sans IA »). Y ajouter les critères de décision, seuils de bascule en mode dégradé en cas de doute sur la fiabilité des résultats, et pas seulement en cas de panne. La supervision humaine exigée par le référentiel devient alors un dispositif de détection, et pas seulement de contrôle.
• Étape 3 : installer une « continuité by design ». Tout nouveau projet IA serait bien inspiré de passer par un jalon de validation associant le RSSI (architecture et sécurité), le DPO (analyse d’impact RGPD), le service biomédical et la direction juridique pour les dispositifs médicaux, et le responsable PCRA (dépendances, mode dégradé, RTO/RPO). C’est l’« organisation structurée de l’acquisition » attendue par le référentiel, élargie à la continuité/reprise d’activité. 

La protection contre les menaces ne suffit pas : un système bien protégé peut rester indisponible. Une approche fondée sur la résilience articule la sécurité, la continuité et la reprise d’activité, et dépasse le seul périmètre du système d’information.  

• Étape 4 : Formaliser son programme d’exercices en y intégrant les situations de défaillance de l’IA. Par exemple : 
  • Premier scénario dans un pôle pilote avec l’indisponibilité inopinée de l’IA générative. 
  • Second scénario, plus exigeant : des résultats corrompus non signalés, afin de tester la capacité de détection et pas seulement de réaction. 

Ces exercices produisent un REX, c’est-à-dire la preuve de pilotage attendue au titre des critères 3.1-05 et 3.1-07. Les dysfonctionnements constatés alimentent les déclarations et les actions d’amélioration prévues au 3.4-05.

En synthèse : 

L’IA générative ne justifie pas la conception d’un dispositif de continuité/reprise d’activité à part. Elle impose toutefois d’enrichir celui que vous avez déjà mis en place au sein de votre établissement. La préoccupation liée à un développement de l’usage des IA doit être posée dans le BIA comme celle liée à une ressource critique, dans l’appréciation des risques comme menace nouvelle, et dans la gouvernance comme sujet partagé entre continuité, sécurité, qualité et conformité.

Le référentiel HAS 2027 pose les exigences sur l’IA d’un côté, sur la continuité de l’autre. Le couplage ISO 22301 / ISO 42001 donne le cadre pour les relier.

Et dans votre établissement : les outils d’IA sont-ils déjà intégrés à votre BIA ? Avez-vous défini ce qu’est un « mode dégradé sans IA » ?