La cybersécurité des équipements hospitaliers ne commence pas le jour où un système est connecté au réseau. Elle ne s’arrête pas non plus à la fin de la mise en service. En réalité, elle débute bien plus tôt : lorsque l’hôpital définit ses besoins, les communications indispensables, les personnes autorisées à administrer la solution, la durée du support et les modalités de remplacement à la fin de sa durée de vie.
Dans un bloc opératoire connecté, un incident numérique va bien au-delà de la confidentialité des données. Un compte partagé, une mise à jour sans possibilité de retour en arrière, une dépendance non documentée ou un accès distant non contrôlé peuvent rendre une fonction indisponible, compliquer la maintenance ou prolonger une interruption. L’impact des cyberattaques sur le secteur de la santé oblige donc à ne plus penser uniquement à la réaction, mais à décider comment prévenir les risques dès la conception et l’achat.
La question réellement utile n’est pas de savoir si un produit « est sécurisé » dans l’absolu. Il faut surtout comprendre comment il sera intégré dans l’environnement hospitalier, quels tests permettront de le vérifier et qui sera responsable du maintien de ses conditions de sécurité dans le temps.
La cybersécurité ne s’ajoute pas aux équipements une fois le projet terminé. Elle se définit dans le cahier des charges, se vérifie lors de la réception et se maintient pendant toute leur durée de vie.
En bref : la cybersécurité des équipements hospitaliers regroupe les exigences techniques, organisationnelles et contractuelles nécessaires pour protéger la disponibilité, l’intégrité et la confidentialité des systèmes connectés et des données qu’ils échangent, depuis leur sélection jusqu’à leur retrait.
Cette approche a pris encore plus d’importance avec les lignes directrices de l’ENISA pour des achats hospitaliers cybersécurisés, publiées en juillet 2026. Le guide organise l’achat en trois grandes étapes —planification, sélection et gestion— et propose des exigences, les informations que le fournisseur doit communiquer et les preuves à conserver pendant tout le cycle contractuel.
Pourquoi la cybersécurité commence dès le cahier des charges
Une formulation telle que « le système devra être sécurisé » peut sembler rassurante, mais elle est presque impossible à vérifier. Elle ne permet pas non plus d’attribuer clairement les responsabilités en cas de défaillance. Une exigence bien formulée décrit au contraire un comportement précis, établit la preuve à fournir et indique qui doit la valider.
Il ne s’agit pas d’une différence purement sémantique. Si la politique de mise à jour, les journaux d’activité ou les conditions du support à distance ne figurent pas dans le cahier des charges, l’hôpital risque de découvrir leurs limites une fois le système installé. Corriger l’architecture à ce stade est généralement plus coûteux, exige davantage de coordination et laisse moins de marge pour choisir une autre solution.
| Formulation insuffisante | Exigence vérifiable | Preuve attendue |
|---|---|---|
| « L’équipement sera cybersécurisé. » | Le fournisseur documentera les composants, versions, interfaces et services réseau inclus dans le périmètre. | Inventaire technique et schéma des communications remis avant la réception. |
| « Le système pourra être mis à jour. » | Le contrat définira la politique, la méthode, le support, la validation et la procédure de retour en arrière des mises à jour. | Procédure testée et calendrier de support communiqué. |
| « La maintenance à distance sera autorisée. » | L’accès distant sera désactivé par défaut ou soumis à une autorisation, une traçabilité et une date d’expiration. | Preuve de l’activation, de la journalisation et de la révocation de l’accès. |
| « Des sauvegardes seront disponibles. » | Les données et configurations récupérables, la fréquence des sauvegardes, leur conservation et l’objectif de restauration seront définis. | Restauration vérifiée lors des tests de réception. |
Le Plan d’action européen pour la cybersécurité des hôpitaux et des prestataires de soins structure la réponse européenne autour de quatre axes : prévention, détection, réponse et dissuasion. Intégrer ces capacités au processus d’achat permet de transformer des principes généraux en décisions concrètes pour le projet.
Six décisions pour gérer l’ensemble du cycle de vie
La sécurité n’est pas une phase isolée que l’on peut considérer comme terminée. Elle accompagne les équipements depuis la définition des besoins jusqu’à la fin du support et leur retrait définitif. Tout projet de zone critique connectée devrait prendre en compte au minimum ces six décisions :
Acheter un système connecté sans avoir défini comment il sera maintenu et retiré revient à accepter une dette technique avant même sa mise en service.
Sept exigences de cybersécurité pour les équipements hospitaliers
1. Inventaire technique et cartographie des dépendances
L’hôpital doit savoir quels composants il reçoit, quelles versions ils utilisent, avec quels systèmes ils communiquent et de quels services ils ont besoin pour fonctionner. Cet inventaire n’est pas une simple liste administrative. Il constitue la référence permettant d’évaluer la criticité de chaque élément, de préparer une mise à jour et d’anticiper les autres fonctions susceptibles d’être affectées par un changement ou un incident.
Au-delà de l’inventaire initial, il convient de définir qui sera chargé de le tenir à jour. Une documentation exacte le jour de la réception perd une grande partie de sa valeur si elle ne reflète pas les modifications ultérieures.
2. Identités, privilèges et accès distant
Les comptes partagés, les mots de passe par défaut et les autorisations permanentes empêchent de savoir avec certitude qui a fait quoi et quand. Le projet doit préciser comment les utilisateurs et les techniciens s’authentifieront, quels privilèges sont nécessaires à chaque profil, qui pourra autoriser une intervention à distance et comment les identifiants seront révoqués une fois celle-ci terminée.
L’accès distant mérite une attention particulière. Il ne devrait pas rester ouvert par commodité ni dépendre d’un mot de passe connu de plusieurs personnes. Une approche raisonnable consiste à ne l’activer qu’en cas de besoin, pendant une durée limitée et en conservant une trace de l’activité réalisée.
3. Segmentation et interopérabilité maîtrisée
Un bloc opératoire connecté doit partager des informations, mais cela ne signifie pas que tous ses composants doivent communiquer librement entre eux. Le réseau doit autoriser les flux nécessaires à l’activité clinique et bloquer ceux qui ne le sont pas.
L’interopérabilité et la segmentation ne sont pas des concepts opposés. La première permet l’échange d’informations ; la seconde en définit les limites. L’objectif est de permettre aux équipements de collaborer sans augmenter inutilement la surface d’exposition. Cette question complète l’analyse de l’interopérabilité des dispositifs médicaux dans les unités de soins critiques.
4. Mises à jour, vulnérabilités et durée du support
Avant d’attribuer un marché, l’hôpital devrait savoir comment et à quelle fréquence le système est mis à jour, par quel canal les vulnérabilités sont signalées, pendant combien de temps il devrait être pris en charge et quelle procédure s’appliquera si un correctif ne peut pas être installé immédiatement.
Dans une zone critique, effectuer une mise à jour sans validation peut créer autant de risques que reporter indéfiniment une correction nécessaire. Il convient donc de prévoir une sauvegarde préalable, un test de compatibilité, une fenêtre d’intervention, les responsables de l’autorisation et un mécanisme de retour en arrière si le résultat n’est pas celui attendu.
Il faut également définir clairement ce qui se passera à la fin du support. Connaître cette date à l’avance permet de budgétiser une migration et évite de conserver des systèmes vulnérables faute d’alternative préparée.
5. Disponibilité, mode dégradé et reprise
Dans un environnement critique, la disponibilité est également une propriété de sécurité. La conception doit anticiper ce qui se passera en cas de défaillance du réseau, d’un poste de travail, d’une intégration ou d’un service central. La réponse ne peut pas être improvisée pendant l’incident.
Les modes dégradés, les sauvegardes de configuration, les pièces de rechange prévues et les procédures manuelles contribuent à réduire l’impact clinique. Disposer d’une sauvegarde ne suffit pas : il faut aussi vérifier qu’elle peut être restaurée dans le délai convenu. Cette dimension complète l’article consacré à la continuité opérationnelle dans les blocs opératoires et les unités de soins intensifs.
6. Journalisation, supervision et notification
Lorsqu’un incident se produit, les équipes techniques doivent pouvoir reconstituer les faits sans compromettre la confidentialité. Il faut pour cela savoir quels événements le système enregistre, comment son horloge est synchronisée, combien de temps les informations sont conservées et comment elles peuvent être intégrées aux outils de supervision de l’hôpital.
Le contrat devrait également prévoir un canal de notification clair. Si le fournisseur détecte une vulnérabilité, l’établissement doit savoir qui recevra l’alerte, quelles informations elle contiendra, comment sa gravité sera classée et dans quel délai une action sera proposée.
7. Chaîne d’approvisionnement, fin de support et retrait sécurisé
Une solution peut dépendre de composants tiers, de sous-traitants, de bibliothèques logicielles ou de services externes. L’hôpital doit identifier les éléments critiques, savoir qui les maintient et connaître les solutions de remplacement si l’un de ces fournisseurs cesse d’assurer le support. Le guide du NIST sur la gestion des risques de cybersécurité liés à la chaîne d’approvisionnement recommande d’intégrer ces relations à la gouvernance et de communiquer les exigences de sécurité aux fournisseurs concernés.
L’obsolescence ne devrait pas non plus être une surprise. Le contrat peut préciser le délai de préavis pour annoncer la fin du support et les options de migration qui seront proposées. Lors du retrait de l’équipement, les comptes, identifiants, configurations et données doivent être supprimés de manière vérifiable ; les accès distants doivent être révoqués et l’inventaire doit enregistrer le retrait.
| Domaine de contrôle | Question à laquelle le projet doit répondre | Résultat vérifiable |
|---|---|---|
| Actifs | Savons-nous ce qui est connecté et de quoi cela dépend ? | Inventaire, versions, interfaces et schéma du réseau. |
| Accès | Qui peut accéder au système, avec quels privilèges et pendant combien de temps ? | Comptes nominatifs, moindre privilège et journaux d’activité. |
| Communications | Quels flux sont nécessaires à l’activité clinique ? | Segmentation et règles approuvées par l’informatique. |
| Maintenance | Comment corriger une vulnérabilité sans compromettre les opérations ? | Mise à jour validée, retour en arrière et fenêtre d’intervention convenue. |
| Continuité | Comment le service se poursuit-il en cas de défaillance d’un composant ? | Mode dégradé, sauvegardes et reprise testée. |
| Incidents | Qui détecte, communique, décide et rétablit le service ? | Procédure d’escalade, délais et responsabilités documentés. |
Application dans un bloc opératoire connecté
L’architecture numérique du bloc opératoire connecté peut regrouper les commandes environnementales, la vidéo, les communications, les alarmes, les informations et les services techniques. Cette intégration facilite l’accès à l’information et peut réduire certaines étapes opérationnelles, mais elle crée également des dépendances qui doivent être documentées dès la phase de projet.
Dans l’écosystème Tedisel Medical, le logiciel de contrôle HERMES centralise des fonctions de l’environnement. Le panneau technique Q Panel peut intégrer des écrans, des PC, de la vidéo, des données, des alarmes et d’autres composants, tandis que le panneau de contrôle et de visualisation Glass Panel regroupe les éléments visuels et prend en charge des configurations compatibles avec le PACS, les postes de soins et HERMES. Le périmètre précis dépend toujours de la configuration convenue pour chaque hôpital.
Une limite importante : aucun panneau, logiciel ou unité de distribution ne peut garantir à lui seul la cybersécurité d’un bloc opératoire. Le résultat dépend de l’architecture complète, de sa configuration et de la manière dont l’hôpital, les intégrateurs et les fournisseurs répartissent et assument leurs responsabilités.
| Couche de l’environnement | Solution ou responsable | Rôle dans la sécurité |
|---|---|---|
| Interface et infrastructure | Q Panel / Glass Panel | Ils centralisent les éléments techniques et les interfaces qui doivent être intégrés à l’inventaire et au plan de maintenance. |
| Contrôle et intégration | HERMES | Il centralise les fonctions de contrôle et d’intégration ; ses flux, accès et dépendances doivent être documentés. |
| Réseau et services de l’établissement | Informatique hospitalière | Définit la segmentation, les identités, la supervision, les sauvegardes et les conditions d’accès distant. |
| Activité clinique | Utilisateurs et direction clinique | Déterminent la criticité, les modes dégradés et les conditions garantissant la continuité en toute sécurité. |
| Cycle de vie | Hôpital et fournisseur | Coordonnent le support, les mises à jour, les changements, les incidents et le retrait. |
Tests de réception : transformer les promesses en preuves
La réception technique est le moment où l’hôpital vérifie que la solution achetée fonctionne dans l’environnement réel. Il ne s’agit pas d’effectuer des tests intrusifs sans coordination, mais de vérifier la documentation, les configurations et les capacités convenues avant de mettre la solution en service.
Chaque exigence devrait produire une preuve. Si un contrôle ne peut pas être réalisé ou nécessite une exception, celle-ci doit être documentée avec le risque associé, la mesure compensatoire et la personne chargée de sa résolution.
| Contrôle | Critère de réception | Participants |
|---|---|---|
| Inventaire final | Les composants, versions et connexions correspondent au périmètre installé. | Fournisseur, informatique et ingénierie biomédicale. |
| Configuration sécurisée | Il ne reste aucun identifiant par défaut ni privilège inutile. | Informatique et fournisseur. |
| Accès distant | Il ne peut être activé qu’avec une autorisation, une journalisation et une date d’expiration. | Informatique, ingénierie biomédicale et support. |
| Segmentation | Les communications sont limitées aux flux approuvés. | Informatique et intégrateur. |
| Mise à jour et retour en arrière | La procédure peut être exécutée sans perte de configuration ni de fonctionnalité clinique. | Fournisseur, informatique et utilisateurs clés. |
| Reprise | Les sauvegardes peuvent être restaurées dans le délai convenu. | Informatique, ingénierie biomédicale et fournisseur. |
| Escalade | Les contacts, niveaux de gravité, délais et décisions sont documentés. | Hôpital et fournisseur. |
Un test de réception utile ne se limite pas à confirmer que « tout fonctionne ». Il démontre ce qui fonctionne, dans quelles conditions et qui doit intervenir lorsque cela ne fonctionne plus.
Gouvernance : une responsabilité partagée, mais jamais diffuse
Les achats transforment les exigences en obligations contractuelles. L’informatique définit le réseau, les identités et la supervision. L’ingénierie biomédicale gère le parc installé. L’ingénierie coordonne les installations et leur disponibilité. Les professionnels cliniques expliquent les conséquences d’une interruption. Le fournisseur, quant à lui, documente, maintient et communique.
Tous participent, mais cela ne signifie pas que la responsabilité puisse être répartie au point de disparaître. Chaque décision doit avoir un responsable clairement identifié et une procédure d’escalade connue.
| Décision | Responsable principal | Participants nécessaires |
|---|---|---|
| Approuver une nouvelle connexion ou interface | Informatique hospitalière | Intégrateur, ingénierie biomédicale et responsable clinique. |
| Autoriser le support à distance | Informatique / sécurité | Ingénierie biomédicale et fournisseur. |
| Planifier une mise à jour | Ingénierie biomédicale | Informatique, fournisseur et responsables cliniques. |
| Activer un mode dégradé | Direction clinique de la zone | Informatique, ingénierie et ingénierie biomédicale. |
| Isoler un équipement à la suite d’un incident | Réponse aux incidents / informatique | Responsable clinique, ingénierie biomédicale et fournisseur. |
| Valider le retour en service | Responsable clinique | Informatique, ingénierie biomédicale et fournisseur. |
Infographie : exiger, tester et maintenir la sécurité
L’infographie résume le cycle de vie autour de trois engagements faciles à transposer dans tout projet hospitalier. Exiger transforme les risques en exigences concrètes. Tester transforme les promesses du cahier des charges en preuves. Maintenir évite qu’une configuration acceptée initialement ne devienne obsolète ou ne perde son niveau de contrôle avec le temps.
Ces trois actions ne sont pas indépendantes. Ce qui n’est pas exigé pourra difficilement être testé, et ce qui n’est pas maintenu cessera d’offrir des garanties, même si cela fonctionnait correctement le jour de la réception.
Conclusion : acheter une technologie, c’est assumer son cycle de vie
La cybersécurité des équipements hospitaliers ne dépend pas d’une seule fonction et ne peut pas être entièrement déléguée au fournisseur. Elle commence lorsque l’hôpital définit ses besoins, se poursuit lors de la conception de l’architecture et se maintient grâce à la maintenance, à la supervision, aux tests et à des responsabilités clairement établies.
Dans les blocs opératoires et les zones critiques, la question pertinente n’est pas de savoir si un système « est sécurisé », mais comment il contribue à une activité sûre et vérifiable. Les dépendances qu’il introduit, la manière dont il est mis à jour, les journaux qu’il génère, sa procédure de reprise et ce qui se passe à la fin du support sont aussi importants que ses fonctionnalités.
Pour Tedisel Medical, cette approche élargit le groupe de contenus consacré aux panneaux techniques, à l’architecture numérique et à la continuité opérationnelle. L’intégration de HERMES, Q Panel, Glass Panel et des autres équipements doit être envisagée dans le cadre d’un environnement clinique coordonné, maintenable et prêt à évoluer.
Principales sources techniques : ENISA, 2026 ; Commission européenne ; et NIST SP 1305.
Questions fréquentes sur la cybersécurité hospitalière
Qu’est-ce que la cybersécurité des équipements hospitaliers ?
Il s’agit de la protection technique, organisationnelle et contractuelle des dispositifs, des logiciels, des connexions et des données pendant toute leur durée de vie. Son objectif est de préserver la disponibilité, l’intégrité et la confidentialité, tout en réduisant les risques numériques et les conséquences cliniques potentielles d’une interruption ou d’une manipulation.
Que doit contenir un cahier des charges ?
Il doit préciser au minimum l’inventaire que le fournisseur remettra, les communications nécessaires, la gestion des identités et des privilèges, les conditions d’accès distant, la politique de mise à jour, le traitement des vulnérabilités, les journaux disponibles, les sauvegardes, la reprise, les périodes de support et la procédure de retrait. Chaque exigence doit être associée à une preuve et à une personne chargée de la valider.
Pourquoi est-il important de connaître la durée du support ?
Parce qu’un système peut continuer à fonctionner alors qu’il ne reçoit plus de correctifs de sécurité ni de mises à jour compatibles. Connaître à l’avance la durée du support permet de planifier le budget, la migration et les mesures compensatoires, et évite que l’obsolescence ne devienne une urgence clinique ou technique.
Comment concilier interopérabilité et segmentation ?
En définissant et en autorisant uniquement les flux nécessaires à l’activité clinique. L’interopérabilité permet aux systèmes d’échanger les informations dont ils ont besoin ; la segmentation empêche cette connectivité de s’étendre à des équipements, services ou réseaux qui ne devraient pas être exposés.
Qui est responsable de la cybersécurité des équipements ?
La responsabilité est partagée, mais chaque tâche doit avoir un responsable clairement identifié. Le fournisseur documente et maintient sa solution ; l’informatique contrôle le réseau, les identités et la supervision ; l’ingénierie biomédicale gère le parc ; l’ingénierie coordonne les installations et la continuité ; et les responsables cliniques déterminent la criticité et valident les conditions d’exploitation et de reprise.
Quel rôle jouent HERMES, Q Panel et Glass Panel ?
HERMES peut centraliser des fonctions de contrôle et d’intégration, tandis que Q Panel et Glass Panel peuvent regrouper les interfaces, la visualisation et différents composants techniques de l’environnement. Leur rôle précis dépend de chaque projet. Aucun de ces systèmes ne garantit à lui seul la cybersécurité du bloc opératoire : ils doivent être intégrés dans une architecture documentée, segmentée et maintenable, gouvernée conjointement par l’hôpital et les fournisseurs concernés.
Associe dès le départ les équipes d’ingénierie, d’ingénierie biomédicale, d’informatique et d’intégration afin d’éviter des décisions coûteuses à corriger une fois les équipements installés. Parle à Tedisel Medical et nous étudierons avec toi une solution adaptée aux besoins de ton projet.