Vous n'avez pas d'inventaire, vous avez une intuition.
Toute mission de sécurité bute tôt ou tard sur la même question : qu'est-ce qu'on protège, exactement ? Comment construire un inventaire qui tient dans la durée.
Votre logiciel est indispensable à l’accueil, au suivi ou à la coordination des patients. Vous savez qui appeler quand il ne fonctionne plus. Mais savez-vous qui vous avertira d’une faille, comment une correction sera validée et comment travailler pendant l’intervention ? La sécurité d’un logiciel de santé se prépare entre établissement, éditeur et exploitant.
En résumé
- Le CERT Santé et le CERT-FR ont publié un retour d’expérience le 2 octobre 2026 sur des vulnérabilités de produits du secteur.
- La dépendance à un éditeur ne supprime pas le besoin de connaître ses versions et ses accès exposés.
- Un contrat utile précise les contacts, les alertes, la correction et la vérification après intervention.
- La télémaintenance doit être autorisée, limitée et traçable.
- La continuité doit être évaluée avec les équipes de soins, pas seulement avec les équipes informatiques.
Un retour d’expérience qui invite à poser des questions précises
Le rapport du 2 octobre 2026 du CERT Santé et du CERT-FR décrit des vulnérabilités critiques dans plusieurs solutions numériques du secteur. Les organismes soulignent les impacts potentiels sur la confidentialité, la continuité des soins et la sécurité des patients. Le retour d’expérience repose sur des cas anonymisés ; il ne justifie pas d’accuser un éditeur non identifié. Consulter le rapport.
Une structure utilisatrice peut transformer cet avertissement en démarche concrète. L’objectif n’est pas de demander une garantie impossible d’absence de faille, mais d’obtenir une organisation capable d’identifier, de corriger et de vérifier un problème sans laisser les utilisateurs dans l’incertitude.
Connaître ce qui est réellement installé
La première question est simple : quelle version utilisez-vous, sur quel périmètre et avec quelles dépendances ? Deux sites d’un même établissement peuvent avoir des versions différentes. Un module ancien peut subsister après une migration. Le contrat de maintenance ne prouve pas que tous les composants sont encore supportés.
Demandez un inventaire partagé : logiciel, version, hébergement, responsable technique, date de fin de support et services accessibles depuis Internet. Complétez-le avec les interfaces qui échangent des données avec d’autres applications. L’inventaire doit être relu après chaque changement significatif, avec un responsable capable de confirmer la situation.
Les questions à inscrire dans la relation fournisseur
| Question | Élément concret attendu |
|---|---|
| Comment sommes-nous alertés ? | Contact nominatif ou fonctionnel, canal suivi et procédure de relance. |
| Qui évalue notre exposition ? | Répartition des vérifications entre éditeur, exploitant et établissement. |
| Comment est livrée une correction ? | Version, prérequis, compatibilité et procédure de retour arrière. |
| Comment fonctionne la télémaintenance ? | Identités, autorisation, restrictions et traces consultables. |
| Comment prouve-t-on la résolution ? | Contrôle de version et vérification adaptée au défaut corrigé. |
| Que se passe-t-il en cas d’indisponibilité ? | Organisation métier dégradée et conditions de reprise. |
Préférez des réponses accompagnées d’un exemple de notification ou d’un modèle de compte rendu. « Nous suivons les bonnes pratiques » n’indique pas qui agit lorsque l’alerte arrive un vendredi soir. Les délais doivent être définis selon la criticité et les contraintes réelles ; un engagement imprécis est difficile à piloter.
Pour un service hébergé, demandez également quelles traces restent accessibles à l’établissement. Si seul le fournisseur peut investiguer, le contrat et la procédure doivent organiser cette coopération. Un label ou une certification ne remplace pas l’analyse du périmètre effectivement couvert.
Définir les responsabilités sans créer de zone grise
La matrice suivante est un point de départ à adapter au contrat. Elle n’attribue pas des responsabilités juridiques universelles. Un acteur peut assurer plusieurs rôles, mais chaque décision doit avoir un responsable identifié.
| Travail à réaliser | Coordination proposée | Contributeurs à associer |
|---|---|---|
| Évaluer l’impact sur les soins | Responsable métier de l’établissement | Soignants et direction. |
| Analyser le défaut logiciel | Éditeur | Exploitant et équipe sécurité. |
| Préparer l’intervention | Exploitant désigné | Éditeur et établissement. |
| Valider la reprise du service | Établissement | Métiers, exploitant et éditeur. |
| Évaluer les données personnelles | Responsable de traitement avec son DPO | Équipe de réponse et sous-traitants concernés. |
Vérifiez notamment les interfaces entre acteurs : qui reçoit l’avis de sécurité, qui ouvre le changement et qui confirme sa réalisation ? Un correctif disponible chez l’éditeur n’est pas encore une correction déployée. Une correction déployée n’est pas encore une reprise métier validée.
Corriger en protégeant la continuité des soins
Associez les utilisateurs concernés avant l’intervention. Ils peuvent identifier des étapes critiques qu’un test purement technique ignore : consultation d’un historique, édition d’un document, transmission vers un autre service ou accès pendant une garde. Le test de reprise doit porter sur ces parcours.
Quand le correctif ne peut pas être installé immédiatement, l’équipe compétente évalue des mesures temporaires compatibles avec les soins. Elles peuvent concerner l’exposition d’un service ou les accès autorisés. Leur efficacité, leur durée et leur impact doivent être documentés. Un report sans propriétaire ni date de réexamen laisse une dette de sécurité invisible.
N’improvisez pas une modification technique sur un équipement participant aux soins. La coordination avec l’éditeur, l’exploitant et les équipes métier est essentielle pour éviter qu’une mesure de sécurité mal préparée ne dégrade le service.
- RecevoirAccuser réception de l’alerte.
- ÉvaluerIdentifier les sites et usages concernés.
- PlanifierConvenir des protections et de l’intervention.
- VérifierContrôler la correction et les parcours métier.
Un exercice réalisable avant l’incident
Choisissez un logiciel critique et simulez la réception d’un avis de sécurité fictif. Aucun système n’a besoin d’être interrompu pour vérifier les contacts, retrouver les versions et attribuer les décisions. Le simple fait de mesurer le temps nécessaire pour joindre les bons interlocuteurs fournit un premier résultat utile.
Dans un second temps, organisez un test technique autorisé sur un environnement adapté. Définissez les critères de réussite avec le métier et consignez les limites. Le livrable attendu tient en quelques éléments : inventaire fiable, chaîne d’alerte, responsabilités, scénario de continuité et preuve de vérification. C’est une base concrète pour améliorer la relation fournisseur et préparer le prochain incident.
Sources et références
Sources consultées le 19 octobre 2026. Les schémas et grilles de préparation sont des propositions pédagogiques de Kenawek, à adapter au contexte de l’organisation.
Préparer vos contrôles avec Kenawek
Pour cadrer un audit, améliorer la surveillance ou préparer votre organisation, parlons de votre projet. En cas d’incident urgent, les clients sous contrat utilisent leur procédure dédiée.