La cybersécurité n’est plus une option pour un logiciel dispositif médical : l’IEC 81001-5-1, le §524B de la FDA et les exigences 17 de l’annexe I du MDR en ont fait une obligation. Résultat, des équipes qui n’avaient jamais eu de SMSI doivent soudain piloter des contrôles, un registre des risques et des preuves d’audit. Une plateforme GRC open source comme Unicis Platform CE promet de faire ça en interne, sans abonnement SaaS. Voici ce qu’elle couvre réellement pour un éditeur médical — et la ligne où elle s’arrête.
Qu’est-ce qu’une plateforme GRC open source comme Unicis Platform CE ?
Définition : une plateforme GRC (Gouvernance, Risques, Conformité) centralise le pilotage de votre sécurité de l’information — inventaire des contrôles, registre des risques, preuves collectées pour l’audit — dans un seul outil au lieu d’un empilement de tableurs. Unicis Platform CE en est une version open source, auto-hébergeable, publiée sous licence Apache 2.0 ; d’après son dépôt, le projet se présente comme une alternative aux SaaS propriétaires du type Vanta ou Drata.
Techniquement, c’est une application Next.js sur PostgreSQL, déployable via Docker, multi-tenant, avec SSO SAML et une API REST. Rien d’exotique pour une équipe qui sait opérer un service web. L’intérêt n’est pas la prouesse technique : c’est de garder la maîtrise de l’outil et de la donnée, sans coût de licence par utilisateur et sans dépendance à un éditeur.
Que couvre-t-elle réellement pour un éditeur de logiciel médical ?
L’essentiel de la valeur, pour un éditeur SaMD (Software as a Medical Device), se concentre sur le volet sécurité de l’information et protection des données. D’après son dépôt, Unicis référence plusieurs cadres — ISO/IEC 27001 (éditions 2013 et 2022), SOC 2 Type II, RGPD, NIST CSF 2.0, EU NIS 2, PCI DSS — et fournit les modules pour les instrumenter.
| Besoin d’un éditeur SaMD | Ce que la plateforme adresse |
|---|---|
| SMSI ISO/IEC 27001:2022 | Inventaire des contrôles, déclaration d’applicabilité, suivi des preuves |
| Registre des risques (sécurité de l’information) | Module de gestion des risques cyber |
| Registre des traitements (RGPD, article 30) | Record of Processing Activities (RoPA) |
| Analyse d’impact sur la vie privée (RGPD, article 35) | PIA / DPIA |
| Sensibilisation des équipes | Programme d’awareness interactif |
C’est un socle honnête pour tenir un SMSI et une posture RGPD. Pour un éditeur médical qui vise SOC 2 ou ISO 27001 afin de rassurer ses clients hospitaliers, l’outil fait gagner du temps réel sur la tenue des preuves. Mais tout ce qu’il gère relève de la sécurité de l’information — pas de la sécurité du patient.
Registre des risques ISMS ou gestion des risques ISO 14971 : le piège du mot « risque »
C’est la confusion que je vois le plus souvent, et elle coûte cher. Le registre des risques d’une plateforme GRC applique la logique ISO/IEC 27001 : il évalue les risques pesant sur la confidentialité, l’intégrité et la disponibilité de l’information. La gestion des risques d’un dispositif médical, elle, obéit à l’ISO 14971:2019 : elle évalue les risques de préjudice pour le patient liés à l’usage du dispositif — un faux négatif affiché au clinicien, une dose mal calculée, une alarme manquée.
Ce sont deux disciplines distinctes, avec deux méthodes et deux livrables. Un chiffrement faible est un risque ISO 27001 ; un algorithme qui sous-estime une mesure est un risque ISO 14971. Une plateforme GRC gère le premier registre. Elle ne produira jamais votre dossier de gestion des risques ISO 14971 — et si vous cochez « risques : géré » sur la foi de votre outil GRC, l’auditeur de l’organisme notifié le verra en trente secondes.
Un registre des risques de sécurité de l’information et un dossier ISO 14971 portent le même mot et ne parlent pas du même danger : l’un protège la donnée, l’autre protège le patient.
Auto-hébergement et souveraineté : ce que ça change pour des données de santé
L’argument fort d’une solution auto-hébergée sous Apache 2.0, quand on manipule des données de santé, c’est la maîtrise : vous décidez où tournent l’application et sa base, sans confier votre cartographie de conformité à un tiers. Pas de verrou propriétaire, pas de donnée exfiltrée vers un SaaS dont vous ne choisissez pas la région.
Mon retour d’expérience : cette maîtrise est réelle, mais elle ne doit pas se transformer en illusion réglementaire. Auto-héberger Unicis ne rend pas votre hébergement conforme HDS (Hébergeur de Données de Santé) — la certification HDS porte sur l’infrastructure d’hébergement et son exploitant, pas sur le logiciel que vous y installez. L’auto-hébergement vous donne le contrôle ; la conformité de l’hébergement reste un sujet à part, à traiter avec votre hébergeur.
Où s’arrête l’outil : le dossier technique MDR qu’aucune plateforme GRC ne remplit
Voilà la frontière à garder en tête. Une plateforme GRC couvre le périmètre sécurité de l’information et données personnelles. Le marquage CE d’un logiciel médical repose sur un tout autre socle, qu’aucun outil GRC ne génère :
- le cycle de vie logiciel IEC 62304:2006+A1:2015 — architecture, exigences, traçabilité jusqu’au code et aux tests ;
- le dossier de gestion des risques ISO 14971:2019, relié aux fonctions réelles du produit ;
- la documentation technique MDR (annexes II et III) ;
- l’évaluation clinique et la surveillance après commercialisation.
Le seul point de recouvrement, c’est la cybersécurité — et il est réel : une plateforme GRC aide à structurer les preuves attendues par l’IEC 81001-5-1 et par le §524B de la FDA. Mais la classe de votre logiciel, elle, se décide en amont selon la règle 11 du MDR, et le dossier qui en découle ne se remplit pas dans un outil de conformité SI. Si votre besoin penche plutôt vers l’automatisation continue des preuves que vers la gouvernance, voir aussi la conformité-as-code à l’épreuve du dispositif médical.
Faut-il l’adopter, et pour qui ?
Unicis Platform CE a du sens si vous voulez posséder votre SMSI, éviter les coûts par utilisateur d’un SaaS, garder la main sur vos données, et que vous avez la capacité d’opérer un service auto-hébergé. Il a moins de sens si vous cherchez une conformité clé en main, avec support et auditeur intégré : là, un SaaS managé se justifie. Dans les deux cas, retenez la même chose — c’est un outil pour le volet sécurité de l’information de votre conformité, la brique cyber d’un ensemble plus large. Le dispositif médical, lui, se prouve ailleurs.
FAQ
Unicis Platform CE remplace-t-il un dossier technique MDR ?
Non. Il gère la sécurité de l’information (ISO/IEC 27001) et la protection des données (RGPD). Le dossier technique MDR — IEC 62304, ISO 14971, évaluation clinique — relève d’un autre corpus qu’aucune plateforme GRC ne produit. Les deux sont nécessaires, ils ne se substituent pas.
La version open source suffit-elle, ou faut-il la version cloud ?
L’édition Community, sous Apache 2.0, est fonctionnelle et auto-hébergeable. Le choix entre auto-hébergement et offre managée est un arbitrage classique : maîtrise et coût de licence nul d’un côté, support et exploitation déléguée de l’autre. Il dépend de votre capacité d’exploitation, pas d’un manque de fonctionnalités.
Auto-héberger Unicis rend-il mon hébergement conforme HDS ?
Non. La certification HDS porte sur l’hébergeur et son infrastructure, pas sur le logiciel installé dessus. Auto-héberger vous donne le contrôle de la donnée ; la conformité HDS de l’hébergement se traite séparément, avec un hébergeur certifié.
Un SMSI à structurer, un dossier MDR à cadrer ? Réservez un appel — on distingue ensemble ce qui relève de l’outil et ce qui relève du dossier réglementaire.
Références & normes citées
- Unicis Platform Community Edition — dépôt GitHub (licence Apache 2.0)
- ISO/IEC 27001:2022 — Sécurité de l'information — Systèmes de management de la sécurité de l'information
- ISO 14971:2019 — Application de la gestion des risques aux dispositifs médicaux
- Règlement (UE) 2016/679 (RGPD), articles 30 et 35 — registre des traitements et analyse d'impact
- Règlement (UE) 2017/745 (MDR), annexes II et III — documentation technique