Les données patients de votre hôpital sont la cible d’attaques dopées à l’IA. La plupart des défenses datent d’une autre époque.
La faille de sécurité n’a pas débuté par une attaque sophistiquée de type zero-day. Tout a commencé par l’accès d’un tiers non autorisé à un système de dossiers médicaux électroniques, accès qui a perduré pendant neuf mois avant d’être détecté.
C’est la chronologie décrite dans la fuite de données OSF rapportée par Shaw Local : un attaquant a eu accès à la plateforme Cerner EHR utilisée par plusieurs établissements OSF en janvier 2025, l’hôpital n’a été averti qu’en septembre, et les patients n’ont été informés qu’à la fin décembre — après une demande de report des forces de l’ordre. Les données compromises incluaient noms, numéros de Sécurité sociale, diagnostics, traitements et résultats d’analyses.
Ce n’est pas un cas isolé. C’est la nouvelle norme. Et avec l’intelligence artificielle qui réduit les coûts, accélère les attaques et abaisse le niveau de compétence requis pour mener des cyberattaques, les hôpitaux font face à un environnement de menaces que leurs architectures de sécurité traditionnelles n’ont jamais été conçues pour gérer.
5 points clés à retenir
- L’IA rend les cyberattaques contre les hôpitaux moins coûteuses, plus rapides et plus difficiles à détecter. Comme le rapporte Shaw Local, l’IA a considérablement abaissé la barrière d’entrée pour les attaquants ciblant les hôpitaux. Les experts en cybersécurité soulignent que les acteurs malveillants peuvent désormais créer des programmes d’attaque opérationnels en quelques heures grâce à des outils d’IA, automatiser la reconnaissance, analyser les données volées et générer des e-mails de phishing capables de contourner les filtres classiques — le tout à moindre coût.
- Les hôpitaux ne peuvent pas se permettre d’interruption — et les attaquants le savent. Contrairement à la plupart des entreprises qui peuvent encaisser plusieurs jours d’arrêt, les hôpitaux fonctionnent sur une temporalité vitale. Lorsque les systèmes tombent en panne, les opérations sont annulées, les portails patients deviennent inaccessibles et les résultats d’analyses disparaissent. Cette urgence opérationnelle explique pourquoi les opérateurs de ransomwares ciblent le secteur de la santé : la pression pour rétablir les services rapidement incite les hôpitaux à payer.
- La fuite OSF révèle l’ampleur de la vulnérabilité des DME dans la santé. La fuite de données OSF a montré qu’un tiers non autorisé avait pu accéder aux dossiers médicaux électroniques via le fournisseur de DME d’OSF, Cerner, dès janvier 2025 — l’hôpital n’ayant été informé qu’en septembre. Les données compromises incluaient noms, numéros de Sécurité sociale, diagnostics, traitements et résultats d’analyses dans plusieurs établissements.
- Les outils d’IA utilisés par le personnel hospitalier créent de nouveaux risques d’exposition des données. Les menaces ne viennent pas seulement de l’extérieur. Les experts en cybersécurité alertent sur le fait que les outils d’IA adoptés par les employés hospitaliers pour les tâches cliniques et administratives — comme ChatGPT et d’autres plateformes d’IA générative — ouvrent des canaux d’exposition involontaire des données. Le personnel qui saisit des données patients, des notes cliniques ou des informations opérationnelles sur des plateformes d’IA publiques risque de rendre les informations médicales protégées accessibles au-delà de l’organisation.
- 63 % des organisations ne peuvent pas limiter l’usage des agents IA sur les données patients. Selon le rapport prévisionnel Kiteworks 2026, 63 % des organisations ne peuvent pas imposer de limitations d’usage aux agents IA, 60 % n’ont pas de bouton d’arrêt d’urgence pour une IA défaillante, et 78 % ne peuvent pas valider les données intégrées dans les pipelines d’entraînement IA. Dans la santé, où la norme HIPAA impose un accès minimal aux informations médicales protégées, ces lacunes constituent à la fois une faille de sécurité et une violation de conformité.
L’IA transforme la cybercriminalité en activité à faible coût et rendement élevé
Les experts en cybersécurité interrogés par Shaw Local sont formels : l’IA a bouleversé l’économie des attaques contre les hôpitaux. Brian Pichman, CISO à l’Illinois Valley Community College, décrit l’impact de l’IA sur les capacités d’attaque comme transformateur — permettant aux acteurs malveillants de concevoir des outils d’attaque efficaces en quelques heures et à coût négligeable.
Cela rejoint ce que le rapport mondial CrowdStrike 2026 observe à plus grande échelle : une hausse de 89 % d’une année sur l’autre des opérations adverses dopées à l’IA, avec un délai moyen de percée eCrime — du premier accès au mouvement latéral — réduit à seulement 29 minutes. Dans la santé, où l’interconnexion des systèmes signifie qu’une plateforme DME compromise peut exposer des millions de dossiers patients, cette rapidité est dévastatrice.
L’IA aide aussi les attaquants à agir plus intelligemment — en analysant les données volées, en identifiant les cibles à forte valeur et en élaborant des stratégies adaptées à l’architecture hospitalière. Une revue scientifique publiée dans Risk Management and Healthcare Policy (Di Palma et al., 2025) recense ces risques en trois catégories : accès non autorisé aux données cliniques, manipulation de dispositifs médicaux pilotés par IA, et vulnérabilités systémiques où la compromission d’un composant se propage à tout le réseau hospitalier.
Pourquoi les hôpitaux sont la cible idéale — et pourquoi la situation empire
La vulnérabilité du secteur de la santé est structurelle, pas accidentelle. Les hôpitaux font tourner des dizaines d’applications interconnectées 24h/24. Les systèmes obsolètes, privés de mises à jour de sécurité, partagent le réseau avec des équipements de diagnostic modernes. Et les données détenues par les hôpitaux — informations médicales protégées incluant diagnostics, antécédents de traitement, numéros de Sécurité sociale et détails d’assurance — figurent parmi les plus recherchées sur le dark web. Une PME peut supporter plusieurs jours d’arrêt, mais un hôpital non. Les attaquants exploitent cette urgence, sachant que les conséquences vitales poussent les organisations à payer.
Les chiffres le confirment. Les cyberattaques contre les hôpitaux ont plus que doublé, passant de 304 en 2022 à 624 en 2023, selon la revue Di Palma. La fuite OSF n’est pas un cas isolé — l’hôpital Morris a signalé un incident similaire en 2023, avec des données compromises incluant noms, adresses, numéros de Sécurité sociale, dossiers médicaux et codes diagnostics.
La menace interne : les outils d’IA utilisés par le personnel hospitalier ouvrent de nouveaux canaux d’exposition
Les attaquants externes ne sont pas la seule source d’exposition des données patients. Un risque critique et souvent sous-estimé : les outils d’IA adoptés en interne pour des usages cliniques et administratifs créent des canaux de fuite de données que la plupart des architectures de sécurité ne couvrent pas.
Le personnel hospitalier qui saisit des informations patients, des notes cliniques ou des données opérationnelles dans des plateformes d’IA générative publiques rend, de fait, les informations médicales protégées accessibles au-delà du contrôle de l’organisation. Une fois les données intégrées à une plateforme publique, elles ne sont plus soumises aux contrôles d’accès HIPAA, aux exigences de traçabilité ou aux obligations de notification de fuite — mais la responsabilité de l’organisation ne disparaît pas pour autant.
Le rapport prévisionnel Kiteworks 2026 illustre l’ampleur de ce déficit de gouvernance : 78 % des organisations ne peuvent pas valider les données intégrées dans les pipelines d’entraînement IA. Dans le secteur de la santé, cela signifie que des données patients peuvent alimenter des systèmes IA sans classification, contrôle d’accès ni traçabilité — une violation directe de la norme HIPAA d’accès minimal et un risque de conformité qui s’aggrave à chaque interaction non surveillée.
HIPAA a été conçu pour un paysage de menaces pré-IA. Les failles apparaissent.
La règle de sécurité HIPAA exige que les entités couvertes mettent en place des mesures pour protéger les informations médicales électroniques. Mais la réglementation a été écrite à une époque où les principales menaces étaient l’accès humain non autorisé et la perte de dispositifs — pas la reconnaissance automatisée par IA capable d’identifier et d’exfiltrer des données en quelques minutes, ni les outils d’IA générative utilisés par les employés hospitaliers pour traiter des informations cliniques sur des plateformes publiques.
La chronologie OSF illustre le problème : neuf mois d’accès non autorisé avant notification, puis trois mois supplémentaires avant d’informer les patients. Selon la règle HIPAA sur la notification des violations, les entités couvertes doivent informer les personnes concernées dans les 60 jours suivant la découverte d’une fuite. Mais lorsque des attaquants dopés à l’IA maintiennent un accès persistant et indétecté pendant des mois, le délai de 60 jours ne commence parfois à courir que bien après les dégâts. L’OCR cite de plus en plus les violations de la norme d’accès minimal lors de ses actions, avec des sanctions pouvant atteindre 1,5 million de dollars par catégorie de violation et par an.
Le déficit de gouvernance : la plupart des organisations de santé ne peuvent pas gouverner ce qu’elles ne voient pas
Le rapport prévisionnel Kiteworks 2026 quantifie ce que la fuite OSF démontre concrètement. 63 % des organisations ne peuvent pas imposer de limitations d’usage aux agents IA accédant à des données sensibles. 60 % n’ont pas de bouton d’arrêt d’urgence pour des agents IA défaillants. 33 % n’ont pas de journaux d’audit exploitables, et 61 % disposent de logs fragmentés, inutiles lors d’une enquête ou d’un audit réglementaire.
Pour les organisations de santé soumises à HIPAA, il ne s’agit pas de métriques abstraites — mais bien d’échecs de gouvernance avec des conséquences concrètes en matière de conformité. Si votre système d’aide à la décision clinique dopé à l’IA dispose du même accès DME que celui qu’un attaquant a exploité via Cerner, et que vous ne pouvez pas prouver un accès limité à l’usage et une traçabilité immuable pour les interactions de ce système IA, vous avez deux vecteurs de fuite et un seul ensemble de contrôles insuffisants pour les couvrir.
Les organisations de santé signalent également la difficulté la plus élevée liée aux e-mails de tous les secteurs, selon le rapport Kiteworks 2026 sur la souveraineté des données, probablement en raison de la sensibilité et du volume des données patients transitant par les communications cliniques. Lorsque les systèmes de messagerie, les plateformes DME, les outils d’IA et les dispositifs médicaux gèrent tous des informations médicales protégées via des architectures de sécurité séparées — voire sans journalisation — la surface d’attaque n’est pas seulement vaste. Elle est ingérable.
Les prompts ne sont pas des garde-fous. L’architecture, si.
C’est là que le Réseau de données privé Kiteworks comble le fossé structurel entre les exigences du paysage de menaces actuel dans la santé et ce que fournissent la plupart des architectures de sécurité hospitalières.
Face à des attaquants dopés à l’IA capables de passer de l’accès initial à l’exfiltration de données en quelques minutes, et face à des outils d’IA internes qui créent des canaux d’exposition incontrôlés, une défense efficace exige une application au niveau de l’infrastructure, continue, automatique et indépendante du comportement de chaque utilisateur ou agent IA.
Des contrôles d’accès granulaires et limités à l’usage imposent la norme HIPAA d’accès minimal au niveau de l’infrastructure. Chaque agent IA, chaque application clinique et chaque utilisateur accédant à des informations médicales protégées bénéficie d’autorisations limitées à l’usage et dans le temps, appliquées à chaque interaction — et non d’un accès large basé sur le rôle qui permet à 500 employés de voir des données dont 50 seulement ont besoin.
La détection d’anomalies en temps réel avec suspension automatique identifie les comptes compromis, les accès inhabituels ou les agents IA opérant hors des paramètres autorisés et les bloque avant tout dommage. Face à des fuites indétectées de neuf mois comme celle d’OSF, la surveillance comportementale continue fait la différence entre un incident contenu et une exposition catastrophique des données.
L’application DLP sur tous les canaux de communication empêche les informations médicales protégées de quitter l’environnement gouverné via e-mail, partage de fichiers, SFTP, transfert sécurisé de fichiers, formulaires web, API ou intégrations d’outils IA. Si un membre du personnel tente de saisir des données patients sur une plateforme d’IA publique, la DLP bloque la donnée à la frontière — avant qu’elle ne devienne une fuite incontrôlée.
Le chiffrement validé FIPS 140-3 avec clés détenues par le client protège les informations médicales protégées au repos et en transit, répondant aux exigences HIPAA en matière de chiffrement et aux standards techniques évalués par l’OCR lors des contrôles.
Et à la base de tout cela : des journaux d’audit immuables et centralisés qui consignent chaque accès, chaque interaction et chaque action de sécurité sur tous les canaux. Face aux exigences HIPAA en matière d’audit et à l’inévitabilité des enquêtes post-incident, ces traces font la différence entre une conformité documentée et une sanction réglementaire impossible à contester.
Ce que tout RSSI du secteur de la santé doit faire dès maintenant
Réalisez un inventaire des actifs IA sur tous les processus cliniques et administratifs. Le rapport Shaw Local confirme que les outils d’IA utilisés par les employés hospitaliers créent des canaux d’exposition non surveillés. Impossible de gouverner ce que vous ignorez. Identifiez chaque outil, agent et intégration IA interagissant avec les données patients — et soumettez-les aux mêmes contrôles d’accès, règles DLP et exigences de traçabilité que les utilisateurs humains.
Imposez l’accès minimal au niveau de l’infrastructure, pas seulement dans les règles. La fuite OSF montre ce qui se passe lorsque les contrôles d’accès sont insuffisants : neuf mois d’accès non autorisé aux données DME. Kiteworks applique un accès limité à l’usage et dans le temps pour chaque utilisateur, application et agent IA interagissant avec les informations médicales protégées — comblant ainsi l’écart entre les exigences HIPAA et la réalité opérationnelle.
Étendez la DLP et la traçabilité à chaque pipeline, prompt et intégration IA. Lorsque 78 % des organisations ne peuvent pas valider les données intégrées dans les pipelines d’entraînement IA, chaque interaction IA non surveillée devient un vecteur potentiel de fuite. L’application DLP empêche les informations médicales protégées de quitter les canaux gouvernés, tandis que les journaux d’audit immuables documentent chaque interaction pour la conformité HIPAA et la préparation aux enquêtes post-incident.
Automatisez la détection et la réponse à la vitesse des attaquants. Les 29 minutes de percée eCrime selon CrowdStrike et les neuf mois d’accès indétecté chez OSF illustrent deux facettes du même problème : des architectures défensives qui reposent sur des analyses humaines et des audits périodiques ne peuvent pas suivre le rythme. Kiteworks propose une détection d’anomalies en temps réel avec suspension automatique des agents — une gouvernance à la vitesse machine pour un paysage de menaces à la vitesse machine.
Les données patients n’attendent pas que votre architecture de sécurité rattrape son retard
Le rapport Shaw Local décrit un paysage de menaces que tout RSSI du secteur de la santé soupçonne déjà, même s’il ne l’a pas encore quantifié : l’IA rend les cyberattaques contre les hôpitaux moins coûteuses, plus rapides et plus difficiles à détecter. Les architectures de sécurité héritées, conçues pour des menaces à vitesse humaine, ne peuvent pas protéger les données patients face à la reconnaissance automatisée, au phishing assisté par IA et à l’exploitation des dizaines d’applications interconnectées qui font fonctionner un hôpital.
Les organisations qui réussiront à protéger les données patients dans ce contexte sont celles qui gouvernent chaque point d’accès — utilisateurs humains, agents IA, applications cliniques et intégrations tierces — avec des autorisations limitées à l’usage, une DLP au niveau de l’infrastructure et des journaux d’audit immuables répondant aux exigences HIPAA et résistant aux enquêtes post-incident. Le Réseau de données privé Kiteworks a été conçu précisément pour cela : protéger les données les plus sensibles dans les environnements les plus complexes, avec la gouvernance, le chiffrement et la preuve exigés par la réglementation et le paysage de menaces de la santé.
Pour découvrir comment Kiteworks peut vous accompagner, réservez votre démo sans attendre !
Foire aux questions
Selon HIPAA, un fournisseur DME comme Cerner qui crée, reçoit, conserve ou transmet des informations médicales protégées électroniques pour le compte d’une entité couverte est considéré comme un sous-traitant et doit signer un accord de sous-traitance précisant les obligations de sécurité, les usages autorisés et les responsabilités en matière de notification de fuite. Lorsque la fuite provient du prestataire — comme dans le cas OSF — c’est l’accord de sous-traitance qui détermine si le prestataire doit informer rapidement l’entité couverte, préserver les preuves forensiques et coopérer à l’enquête. Cependant, la règle HIPAA sur la notification des violations impose à l’entité couverte d’informer les personnes concernées dans les 60 jours suivant la découverte, que le prestataire soit responsable ou non de la fuite. Cela crée une responsabilité asymétrique : l’hôpital porte l’obligation de notification des patients et s’expose à des sanctions de l’OCR, même pour une fuite qu’il n’a pas causée et qu’il n’aurait pas pu détecter. Les organisations de santé doivent s’assurer que les accords de sous-traitance avec les fournisseurs DME couvrent explicitement les délais de réponse aux incidents, la conservation et l’accès aux logs d’audit, la méthodologie de détermination du périmètre de la fuite, et le droit de l’entité couverte à une expertise indépendante — autant de clauses souvent absentes des contrats standards.
La norme HIPAA d’accès minimal exige que l’accès aux informations médicales protégées soit limité au strict nécessaire pour atteindre l’objectif visé. Appliquée aux agents IA dans les processus cliniques, cela signifie que chaque agent ne doit accéder qu’aux catégories d’informations médicales protégées indispensables à sa fonction définie — par exemple, un outil d’aide à la décision pour les interactions médicamenteuses n’a pas besoin d’accéder aux dossiers de facturation ou aux diagnostics historiques hors de son périmètre. En pratique, la plupart des déploiements IA dans la santé ne respectent pas cette norme car ils utilisent des identifiants de service larges ou des autorisations basées sur le rôle, initialement conçues pour les utilisateurs humains, donnant aux agents IA un accès bien plus large que nécessaire. Le rapport prévisionnel Kiteworks 2026, qui indique que 63 % des organisations ne peuvent pas limiter l’usage des agents IA, illustre ce déficit. La conformité exige des contrôles d’accès basés sur des attributs, qui évaluent le but autorisé de l’agent IA, la classification des données demandées et le contexte de la tâche à chaque interaction — imposant l’accès minimal au niveau des données plutôt que de s’appuyer sur des attributions de rôles système inchangées d’une tâche à l’autre.
La règle HIPAA sur la notification des violations impose aux entités couvertes d’informer les personnes concernées sans délai excessif et dans les 60 jours suivant la découverte d’une fuite. La « découverte » correspond à la date à laquelle l’entité couverte a eu connaissance ou aurait dû avoir connaissance de la fuite en faisant preuve de diligence raisonnable. La chronologie OSF — accès de l’attaquant dès janvier, notification de l’hôpital en septembre, notification des patients en décembre — illustre le double problème de conformité que cela pose. D’abord, si les neuf mois de présence reflètent un défaut de détection plutôt qu’une absence réelle de signaux, l’OCR peut estimer qu’une diligence raisonnable aurait permis d’identifier la fuite plus tôt, déclenchant le délai de 60 jours plus tôt et rendant la notification de décembre non conforme. Ensuite, la clause de report pour enquête des forces de l’ordre prévue par HIPAA est limitée dans le temps et nécessite une demande formelle — elle ne suspend pas indéfiniment l’obligation de l’organisation. Les organisations de santé confrontées à des accès persistants dopés à l’IA doivent assurer une surveillance comportementale continue avec alertes en temps réel : le journal d’audit qui documente l’apparition des premiers accès anormaux sert aussi de preuve pour déterminer la date légale de départ du délai de 60 jours.
Pour empêcher la fuite d’informations médicales protégées via des plateformes d’IA générative, l’application DLP doit intervenir à quatre niveaux que la plupart des architectures de sécurité hospitalières ne couvrent pas actuellement. Premièrement, l’inspection du contenu sortant sur chaque canal par lequel le personnel interagit avec des plateformes IA externes — outils IA accessibles via le réseau de l’entreprise, intégrations API entre applications cliniques et services IA, et workflows e-mail routés vers des pipelines IA. Deuxièmement, l’application de la classification des données pour identifier les informations médicales protégées dans leur contexte — pas seulement via la détection de motifs évidents comme les numéros de Sécurité sociale, mais en reconnaissant que des notes cliniques, codes diagnostics et descriptions de traitements constituent des informations médicales protégées même sans nom associé. Troisièmement, l’inspection au niveau du prompt pour détecter l’envoi de données structurées patients en entrée IA, et pas seulement lors des transferts de fichiers. Quatrièmement, des contrôles au niveau de la passerelle API pour les intégrations IA, imposant des limitations d’usage — restreignant les classifications de données qu’une intégration IA donnée peut envoyer ou recevoir. Sans ces quatre couches, les politiques DLP couvrant le transfert de fichiers traditionnel et les canaux MFT laissent des failles visibles par lesquelles les informations médicales protégées peuvent être traitées par des IA externes sans déclencher d’alerte ni générer de trace d’audit.
FIPS 140-3 est la norme fédérale américaine actuelle pour la validation des modules cryptographiques, remplaçant FIPS 140-2. Elle définit les exigences de conception, d’implémentation et de test des modules cryptographiques — pas seulement l’algorithme, mais l’ensemble du module matériel ou logiciel qui réalise le chiffrement. Pour les organisations de santé, la validation FIPS 140-3 est cruciale pour trois raisons. Premièrement, les exigences techniques HIPAA s’appuient sur les recommandations NIST en matière de chiffrement, et l’OCR considère de plus en plus le chiffrement validé FIPS comme la référence pour les informations médicales protégées au repos et en transit — des implémentations utilisant des algorithmes standards mais sans validation du module peuvent ne pas répondre aux attentes de l’OCR lors d’un contrôle. Deuxièmement, la validation FIPS 140-3 impose des tests tiers de l’implémentation cryptographique, apportant une preuve que le chiffrement auto-déclaré ne fournit pas. Troisièmement, la gestion des clés par le client — où l’organisation de santé, et non le prestataire, contrôle les clés — garantit que les informations médicales protégées restent inaccessibles au fournisseur cloud et ne sont pas exposées lors d’incidents de sécurité du prestataire. Associé à des journaux d’audit immuables, le chiffrement validé FIPS 140-3 avec gestion des clés par le client constitue le socle technique que l’OCR recherche pour évaluer si une entité couverte a fait preuve de diligence raisonnable dans la protection des informations médicales protégées.
Ressources complémentaires
- Article de blog Architecture Zero Trust : Ne jamais faire confiance, toujours vérifier
- Vidéo Microsoft GCC High : Les inconvénients qui poussent les sous-traitants de la défense vers des solutions plus intelligentes
- Article de blog Sécuriser les données classifiées après détection par DSPM
- Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
- Vidéo Guide ultime pour sécuriser le stockage des données sensibles à destination des responsables IT