Cadrage réglementaire d’un projet e-santé : par où commencer
Dossier mis à jour le 7 septembre 2026. Références réglementaires citées et datées, relues à chaque millésime.
Un projet e-santé se cadre avant d’être développé, et l’ordre dans lequel vous posez les questions détermine le coût du projet. Six décisions structurent tout le reste : la nature des données, la finalité revendiquée, l’hébergement, les utilisateurs et leur authentification, l’objectif de référencement ou de remboursement, le calendrier de mise sur le marché. Prises au début, elles orientent l’architecture. Prises après, elles se paient en refonte.
Les six questions, dans l’ordre
Ces questions se posent dans cet ordre parce que chacune ferme le champ des réponses possibles à la suivante. Traiter l’hébergement avant la finalité conduit à choisir une infrastructure qui ne supportera pas le régime finalement applicable.
- Quelles données manipulez-vous ? Données de santé à caractère personnel, données de bien-être, données pseudonymisées, mesures issues d’un objet connecté. La réponse fixe le régime applicable.
- Revendiquez-vous une finalité médicale ? Diagnostic, prévention, suivi, prédiction, traitement. Une revendication suffit à faire entrer le produit dans le champ du règlement (UE) 2017/745.
- Qui héberge, et sur quel périmètre ? Hébergeur certifié, infrastructure administrée par vos soins, installation chez le client sur son propre système.
- Qui sont les utilisateurs et comment les authentifiez-vous ? Professionnels de santé, patients, personnels administratifs. Les moyens diffèrent, et l’identité du patient doit être fiable.
- Visez-vous un référencement ou un remboursement ? Le référencement suppose des exigences d’interopérabilité et de sécurité prouvées, le remboursement suppose une démonstration de bénéfice.
- Quel calendrier de mise sur le marché ? Une évaluation par un organisme notifié ne se comprime pas, elle se planifie dès le premier jour.
Pourquoi la qualification passe avant tout le reste
La qualification en dispositif médical n’est pas une formalité de fin de projet. Elle décide de la méthode de développement, de la composition de l’équipe, du volume de documentation et de la durée avant la mise sur le marché. Un produit qualifié impose un cycle de vie conforme à l’IEC 62304, une gestion des risques selon l’ISO 14971, une documentation technique complète et, selon la classe, l’intervention d’un organisme notifié.
Cette qualification dépend de la destination que vous donnez au produit, pas de sa complexité technique. Une application simple qui annonce qu’elle aide à ajuster une posologie est un dispositif médical. Un moteur d’analyse sophistiqué qui se contente de restituer des mesures brutes ne l’est pas. Ce que vous écrivez sur votre page d’accueil compte autant que votre code.
Les données commandent l’hébergement
La question de l’hébergement se tranche à partir de la nature des données, pas à partir des habitudes de l’équipe technique. Dès que vous hébergez des données de santé à caractère personnel pour le compte d’un responsable de traitement, l’article L.1111-8 du code de la santé publique impose de passer par un hébergeur certifié. Le certificat n’est jamais générique : il liste les activités couvertes, et il faut vérifier que l’administration et l’exploitation entrent dans le périmètre.
Le RGPD s’ajoute par-dessus, pas à la place. Base légale, minimisation, durées de conservation, analyse d’impact, information des personnes, contrat de sous-traitance : ces obligations existent indépendamment de la certification de votre hébergeur. Une architecture qui sépare tôt les données identifiantes des données de mesure allège sensiblement la charge par la suite.
Utilisateurs, identités et accès
La question des utilisateurs paraît fonctionnelle, elle est réglementaire. Un professionnel de santé s’authentifie avec un moyen reconnu, et l’usage d’un compte partagé dans un service est un écart, pas un arrangement d’ergonomie. Un patient doit être identifié de façon fiable, faute de quoi les doublons rendent les échanges de documents inexploitables.
L’identité nationale de santé est l’élément qui permet de rattacher des données au bon patient entre plusieurs systèmes. Son intégration touche l’ensemble du modèle de données, pas seulement l’écran d’inscription. C’est typiquement le chantier qu’on ne greffe pas sur un produit déjà en production sans reprise.
Le coût d’un cadrage tardif
Un cadrage fait après le développement ne se résout pas par une note de synthèse. Si la qualification tombe du mauvais côté, il faut reconstituer une traçabilité des exigences sur du code déjà écrit, produire des dossiers de vérification qui n’ont jamais existé, reprendre l’architecture de journalisation et parfois migrer l’hébergement. Ces travaux mobilisent l’équipe pendant des mois, pendant lesquels la feuille de route fonctionnelle est à l’arrêt.
La sortie la moins coûteuse consiste parfois à revoir la revendication plutôt que le produit. Retirer une promesse d’aide à la décision d’une page commerciale peut suffire à rester hors du champ du règlement, quand le produit ne l’exige pas fonctionnellement. Cet arbitrage se prend au cadrage, avec le dirigeant, pas dans un comité technique. Notre méthodologie le place avant l’écriture du cahier des charges.
Comment nous vous accompagnons
Nous commençons chaque projet de santé par une séance de cadrage, avant toute maquette. Nous instruisons avec vous la qualification du produit, la nature des données, le périmètre de votre hébergeur, les moyens d’authentification et l’objectif de référencement. Le livrable tient en quelques pages : une note de qualification argumentée, une cartographie des données, une liste d’exigences à tracer et un plan de charge réaliste. Ensuite, nous développons en suivant l’IEC 62304 quand le produit le demande, et nous préparons le dossier au fil du projet plutôt qu’à la fin. Écrivez-nous à contact@digitalunicorn.fr.
Digital Unicorn développe des applications de santé pour des éditeurs et des établissements, en appliquant les référentiels décrits ci-dessus. Nous ne sommes ni un organisme notifié, ni un hébergeur certifié : nous concevons le logiciel, nous produisons la documentation attendue et nous travaillons avec l’hébergeur agréé et l’organisme d’audit que vous choisissez. Avis technique gratuit de trente minutes au 06 32 64 24 80 ou à contact@digitalunicorn.fr, et le guide du développement d’application santé pour la vue d’ensemble.
Les décisions de cadrage et leur portée
| Question de cadrage | Ce qu’elle décide | Ce qu’elle coûte tranchée trop tard |
|---|---|---|
| Nature des données | Régime applicable, hébergement, analyse d’impact | Migration d’infrastructure et reprise des traitements |
| Finalité médicale revendiquée | Statut de dispositif médical, méthode, calendrier | Reconstitution d’un dossier technique sur un produit existant |
| Hébergement et périmètre | Contrats, responsabilités, localisation des données | Changement d’hébergeur en cours d’exploitation |
| Utilisateurs et authentification | Modèle de données, gestion des identités, traçabilité | Reprise du modèle de données et des comptes déjà créés |
| Référencement ou remboursement | Exigences d’interopérabilité et preuves à produire | Développements d’interopérabilité ajoutés après coup |
| Calendrier de mise sur le marché | Ordre des chantiers et moment de l’évaluation | Décalage du lancement au rythme de l’organisme notifié |
Cadrage réglementaire d’un projet e-santé : par où commencer : questions fréquentes
En quoi consiste le cadrage réglementaire e-santé ?
Le cadrage réglementaire e-santé consiste à trancher, avant le développement, les questions qui déterminent le régime applicable au produit : nature des données, finalité médicale revendiquée, hébergement, utilisateurs et authentification, objectif de référencement ou de remboursement, calendrier. Le résultat tient dans une note de qualification, une cartographie des données et un plan de charge. Il conditionne l’architecture, la méthode de développement et la date réaliste de mise sur le marché.
Par quelle question faut-il commencer ?
Par la finalité que vous revendiquez. Elle décide si le produit est un dispositif médical, et cette qualification commande tout le reste : cycle de vie logiciel, gestion des risques, documentation technique, intervention éventuelle d’un organisme notifié, durée avant la mise sur le marché. Les sujets d’hébergement et d’interopérabilité se traitent ensuite, avec des réponses différentes selon que le produit entre ou non dans le champ du règlement.
Peut-on cadrer un projet après avoir développé un prototype ?
Un prototype non diffusé reste rattrapable, et c’est même un bon moment pour cadrer. Ce qui coûte cher, c’est le cadrage entrepris après la mise en service. Il faut alors reconstituer une traçabilité des exigences sur du code écrit sans elle, produire des dossiers de vérification absents et parfois migrer l’hébergement. Le travail se compte en mois, pendant lesquels la feuille de route fonctionnelle avance peu.
Faut-il un référent réglementaire dans l’équipe ?
Dès que le produit est un dispositif médical, oui. Le règlement impose de disposer d’une personne chargée de veiller au respect de la réglementation, mobilisée en interne ou par contrat selon la taille de la structure. Hors du champ du règlement, une personne identifiée pour porter la protection des données et la sécurité suffit, à condition qu’elle soit associée aux décisions techniques et pas consultée après coup.
Cadrer votre projet de santé numérique en trente minutes ?
Décrivez votre application en quinze minutes : vous repartez avec un avis technique sous 48 h. Périmètre, technologies pertinentes et ordre de grandeur budgétaire. Sans engagement.
Ou par téléphone 06 32 64 24 80
Développement d’application santé numérique
Cette fiche fait partie d’un dossier plus large : cadrage réglementaire, hébergement des données, statut de dispositif médical, interopérabilité et accès au marché.