Une application de suivi du diabète, un carnet de vaccination numérique, une plateforme de prise de rendez-vous : derrière des usages devenus banals se cache un cadre réglementaire que beaucoup de porteurs de projet découvrent trop tard. En santé, le logiciel n’est pas un produit numérique comme un autre. Trois questions se posent avant même la première ligne de code, et les ignorer coûte souvent plus cher que de les traiter dès le départ. Pour ceux qui souhaitent faire développer une application de santé, ce sont ces trois points qu’il faut trancher en priorité.
Héberger des données de santé impose un agrément spécifique
Dès qu’une application collecte, conserve ou traite des données de santé à caractère personnel pour le compte d’un tiers, elle doit être hébergée chez un prestataire titulaire de la certification HDS (hébergeur de données de santé). Ce n’est pas une bonne pratique conseillée : c’est une obligation inscrite dans le code de la santé publique.
La certification est délivrée après audit par un organisme accrédité et couvre six activités distinctes, de la mise à disposition de l’infrastructure matérielle à l’infogérance et à la sauvegarde. Un hébergeur peut être certifié pour certaines activités seulement, ce qui explique qu’une architecture réelle mobilise parfois plusieurs prestataires. Le détail des périmètres et la liste des hébergeurs certifiés sont publiés par l’Agence du Numérique en Santé.
Le point qui surprend le plus souvent : la certification porte sur l’hébergeur, pas sur l’application. Choisir un cloud certifié HDS ne rend pas un projet conforme par ricochet. Le responsable de traitement conserve ses propres obligations, notamment au titre du RGPD, et le contrat qui le lie à l’hébergeur doit expressément prévoir les engagements liés aux données de santé. Une migration d’infrastructure décidée en cours de route, une fois l’architecture figée, se paie généralement en semaines de développement.
Une finalité médicale fait basculer le logiciel dans le statut de dispositif médical
C’est le second point de bascule, et le plus mal compris. Un logiciel devient un dispositif médical lorsqu’il poursuit une finalité médicale : aider au diagnostic, à la prévention, au contrôle, au traitement ou à l’atténuation d’une maladie. Le critère n’est ni la présence de données de santé, ni le fait que l’utilisateur soit un professionnel de santé.
La distinction se joue sur ce que le logiciel fait de la donnée. Une application qui se contente d’enregistrer, de stocker et d’afficher des mesures reste, en principe, hors du champ. Celle qui les interprète, calcule une posologie, produit une alerte clinique ou oriente une décision thérapeutique entre dans le champ du règlement européen sur les dispositifs médicaux. La frontière est parfois ténue : un simple calcul de score peut suffire à faire basculer un produit.
Les conséquences ne sont pas anodines. Le statut de dispositif médical impose un marquage CE, obtenu au terme d’une procédure d’évaluation de la conformité dont la lourdeur dépend de la classe du produit. Pour un logiciel, cette classification est rarement la plus basse, ce qui suppose l’intervention d’un organisme notifié. Il faut aussi mettre en place un système de management de la qualité, documenter la gestion des risques, constituer une évaluation clinique et organiser une surveillance après commercialisation.
En pratique, ce parcours se compte en mois, parfois en années pour les classes supérieures, et représente un poste budgétaire à part entière. D’où l’importance de la question posée en amont : beaucoup de projets peuvent être conçus pour rester hors du statut de dispositif médical, à condition que ce choix soit assumé dès la définition des fonctionnalités — et non découvert après coup.
Trancher tôt plutôt que corriger tard
Hébergement, statut réglementaire, marquage CE : ces trois sujets ne sont pas des formalités administratives à traiter en fin de projet. Ils déterminent l’architecture technique, le périmètre fonctionnel, le calendrier et le budget. Une application conçue sans les avoir tranchés se retrouve fréquemment devant un choix inconfortable : retirer des fonctionnalités pour éviter le statut de dispositif médical, ou engager une procédure de conformité qui n’avait pas été provisionnée.
La séquence la plus économique reste la même : qualifier le projet avant de le développer. Déterminer quelles données sont traitées et pour le compte de qui, écrire noir sur blanc la finalité revendiquée du logiciel, puis vérifier si cette finalité est médicale au sens du règlement. Ces réponses conditionnent tout le reste, et elles se formulent en quelques semaines de cadrage — un investissement sans commune mesure avec le coût d’une reprise d’architecture ou d’un dossier de conformité improvisé.
Le numérique en santé n’est pas fermé aux nouveaux entrants, mais il récompense ceux qui abordent la réglementation comme une contrainte de conception plutôt que comme une case à cocher.
