Cybersécurité et risque logiciel : les nouveaux points d’arrêt

Un constat qui traverse toutes les tailles d’organisation

Un logiciel médical n’est jamais « fini ». Il vit, se met à jour, évolue, encaisse des tentatives d’intrusion. Pourtant, sur le terrain, j’observe toujours la même ligne de fracture : beaucoup d’industriels pensent encore la conformité comme un dossier à boucler une fois, puis à ranger dans un tiroir. Cette vision date d’avant le logiciel.

Dans les startups et PME du dispositif médical, l’équipe technique est souvent excellente, concentrée sur la performance clinique du produit. Dans les grands groupes, la maturité qualité est réelle, mais elle se heurte à une organisation en silos où la sécurité des systèmes d’information et les exigences produit vivent dans deux mondes qui ne se parlent pas. Deux réalités différentes, un même point faible : la cybersécurité et le risque logiciel ne sont pas traités comme des objets vivants.

Ce que l’évaluation regarde de plus en plus, ce n’est pas seulement le dossier figé au moment du dépôt : c’est le logiciel vivant, sa cybersécurité, ses mises à jour, sa surveillance après mise sur le marché. Plusieurs autorités européennes ont renforcé les exigences de preuve de compétence technique des organismes notifiés, en particulier sur la gestion du risque logiciel et la surveillance post-marché. Le centre de gravité du dossier a changé : le document ne suffit plus, il faut démontrer que le produit reste sûr dans le temps.

Ma thèse : un métier d’ingénierie système, pas de rédaction

C’est le malentendu que je rencontre le plus souvent. On me demande de « finaliser la documentation », comme s’il s’agissait d’un exercice de mise en forme. Or la documentation réglementaire n’est pas un travail de rédaction : c’est un travail d’ingénierie système. Elle structure les choix de conception, trace les décisions, rend visibles les compromis techniques. Mal posée, elle devient un mur à franchir avant le dépôt. Bien posée, elle devient l’architecture même du produit.

Trois décalages reviennent systématiquement et coûtent cher :

**La cybersécurité traitée comme un supplément.** Les équipes maîtrisent la technique mais sous-estiment la formalisation du risque. Ce n’est pas de l’incompétence, c’est un réflexe culturel : développer un logiciel médical n’est pas développer une application classique.

**La surveillance post-marché vécue comme un après.** Les mises à jour, les correctifs de failles, les incidents font partie de la démonstration de conformité, pas d’un service après-vente séparé.

**La coexistence non pilotée des deux mondes de la sécurité.** Dans les grands groupes, la sécurité des systèmes d’information est un métier installé, avec ses référentiels propres ; les exigences produit en sont un autre. Faute d’articulation explicite, des équipes travaillent en double et personne ne pilote la jonction.

Le socle normatif, et ce qu’il impose réellement

Rien de mystérieux dans le socle attendu : un cycle de vie logiciel structuré, une démarche de cybersécurité produit, une gestion du risque à jour, le tout dans un système qualité cohérent. Ce ne sont pas des cases à cocher. Ce sont des preuves à construire, et elles se construisent dès la conception ou pas du tout.

| Point d’arrêt | Ce qu’il impose | Ce qu’il évite | |—|—|—| | Cybersécurité produit | Démontrer la sécurité à chaque version | La reprise tardive, plus coûteuse | | Gestion du risque logiciel | Analyse continue, pas figée au dépôt | Les non-conformités de dernière minute | | Surveillance post-marché | Traiter mises à jour et incidents dans la durée | Un cycle d’évaluation supplémentaire | | Système qualité intégré | Un processus, pas des documents isolés | Le mur documentaire avant le dépôt |

Cas pratique : le télésuivi patient qui révèle le problème trop tard

Un industriel développe un logiciel de télésuivi patient. L’équipe technique est solide, le produit fonctionne, les premiers utilisateurs sont satisfaits. Mais la documentation de cybersécurité n’a jamais été formalisée : les bonnes pratiques existent dans le code, rien ne les rend démontrables.

Au moment de préparer le dossier, le travail de formalisation représente plusieurs semaines non planifiées — sur un produit déjà en production. Reprendre tard ce qui aurait pu être intégré tôt mobilise un temps considérable, précisément au moment où le projet a le moins de marge. Ce scénario, je le retrouve aussi bien chez des startups en phase de première mise sur le marché que dans des grands groupes où le produit a été développé par une entité éloignée des équipes réglementaires.

Ce que j’en retiens pour la méthode

Le réflexe que je défends est simple : traiter la cybersécurité et le risque logiciel comme des exigences de conception, pas comme des livrables de fin de parcours. Intégrées tôt, elles structurent le développement. Ajoutées tard, elles ajoutent un cycle complet. Ce n’est pas une question de normes à empiler, c’est une question de moment — et donc d’ingénierie, pas de paperasse.

Pour une startup, cela veut dire penser la trame documentaire avant le premier sprint technique. Pour un grand groupe, cela veut dire désigner explicitement qui pilote la jonction entre sécurité SI et exigences produit, plutôt que de laisser deux équipes avancer en parallèle sans jamais se croiser.

Conclusion actionnable

Pour un industriel, la vraie question n’est pas « sommes-nous conformes aujourd’hui ? », mais « pourrons-nous démontrer demain que nous le restons ? ». Cette question se pose dès la conception, pas au moment du dépôt.

Si vous préparez un logiciel médical et souhaitez identifier où se situent réellement vos points d’arrêt, écrivez à bonjour@numedikal.com.