PGSSI-S : les exigences de sécurité opposables à votre application de santé

La PGSSI-S est la brique du socle français dont les équipes techniques entendent le moins parler, et celle qui les rattrape le plus tard — en général au moment d’un appel d’offres, d’un audit client ou d’un dossier de référencement.

Ce que c’est, et à qui cela s’applique

La Politique Générale de Sécurité des Systèmes d’Information de Santé encadre les règles de sécurité pour l’e-santé. Son déclencheur est large : elle s’applique dès lors que des données de santé à caractère personnel sont utilisées.

Son périmètre couvre le secteur public comme le privé, les professionnels de santé, les secteurs médico-social et social, les établissements de soins et les offreurs de services. Un éditeur qui fournit un service à l’un de ces acteurs entre dans le champ, même s’il n’est lui-même ni établissement ni professionnel de santé.

Le point que tout le monde manque : l’opposabilité

Le corpus PGSSI-S se divise en deux catégories :

• des éléments opposables — référentiels et documents fixant les exigences relatives aux différents aspects de la sécurité des systèmes d’information en santé ;
• des supports pratiques — guides et documents organisationnels, incluant les recommandations.

La distinction est décisive. Beaucoup d’équipes lisent le corpus comme un ensemble de bonnes pratiques et arbitrent ce qu’elles retiennent. Sur la partie opposable, cet arbitrage n’existe pas.

La logique de paliers

Les documents du corpus sont structurés de manière progressive : un palier minimal, puis des paliers progressifs, destinés à permettre une amélioration continue de la sécurité.

Pour un éditeur, cette structure est une bonne nouvelle opérationnelle : elle rend possible une trajectoire planifiée plutôt qu’un big bang. Elle impose en revanche de savoir précisément où l’on se situe — exercice que peu d’équipes ont réellement fait, et qui constitue le point de départ de tout plan de mise à niveau crédible.

Comment la PGSSI-S s’articule avec vos autres obligations

Trois régimes se superposent, et les confondre conduit à des impasses :

	Objet	Ce que ça ne couvre pas
RGPD	Protection des données à caractère personnel, obligations de résultat	Le détail technique de la sécurité d’un SI de santé
Certification HDS	L’activité d’hébergement de données de santé	La sécurité de votre application elle-même
PGSSI-S	La sécurité du système d’information de santé, exigences techniques et organisationnelles	Le statut réglementaire de votre logiciel (dispositif médical)

L’erreur la plus fréquente consiste à considérer que le recours à un hébergeur certifié HDS règle la question de la sécurité. Il règle la question de l’hébergement. Tout ce qui se passe dans votre application — authentification, habilitations, journalisation, chiffrement applicatif, gestion des accès, imputabilité des actions — reste de votre responsabilité, et c’est précisément le terrain de la PGSSI-S.

Par quoi commencer

Trois actions donnent la meilleure visibilité pour un effort limité :

1. Déterminer le périmètre applicable à votre solution — tous les référentiels du corpus ne concernent pas tous les acteurs.
2. Positionner votre solution sur les paliers, honnêtement, référentiel par référentiel.
3. Traiter l’imputabilité en priorité, parce que c’est l’exigence qui a le plus d’impact sur l’architecture : savoir qui a fait quoi, quand, et pouvoir le démontrer, ne se rajoute pas après coup.

Ces trois points constituent aussi le socle de ce qu’un dossier de référencement Ségur ou un audit client vous demandera de démontrer.