Développement d’application santé numérique
Page mise à jour le 7 septembre 2026
Développer une application de santé en France, ce n’est pas développer une application avec des données médicales dedans. C’est un projet logiciel sur lequel se superposent trois régimes distincts : la protection des données personnelles, l’hébergement certifié des données de santé, et, pour une partie des produits, le statut de dispositif médical. Ce guide pose l’ordre dans lequel ces questions se traitent, ce que chacune coûte en temps et en budget, et ce qui se joue si l’on s’y prend à la fin plutôt qu’au début.
Ce que « application de santé » veut dire, juridiquement
L’expression ne recouvre aucune catégorie juridique unique. Derrière elle se cachent au moins quatre familles de produits, et chacune tombe sous un régime différent. Un service de prise de rendez-vous manipule des données personnelles mais n’interprète rien. Un portail patient stocke des documents médicaux sans jamais poser de diagnostic. Un logiciel d’aide à la prescription oriente une décision thérapeutique. Un algorithme qui lit une image et signale une lésion est un produit réglementé au même titre qu’un scanner.
Le réflexe utile est donc de refuser la question « quel est le cadre pour une application de santé » et de la remplacer par trois questions plus étroites. Quelle finalité revendiquez-vous ? Quelles données manipulez-vous, et pour le compte de qui ? Qui sont vos utilisateurs, professionnels ou grand public ? Les réponses tracent le plan de charge réglementaire, et elles ne coûtent rien à poser au début du projet. Posées après le développement, elles coûtent une refonte.
La question qui commande tout : dispositif médical ou non
Le règlement européen 2017/745, appelé MDR, définit le dispositif médical par sa destination. Ce n’est pas la technologie qui qualifie, c’est ce que le fabricant revendique. Un logiciel destiné au diagnostic, à la prévention, au contrôle, à la prédiction, au pronostic, au traitement ou à l’atténuation d’une maladie est un dispositif médical. Un logiciel qui se contente de stocker, d’archiver, de communiquer ou de faire de la recherche sans interprétation ne l’est pas.
La conséquence surprend souvent les équipes produit. Une phrase sur une page d’accueil peut suffire à faire basculer un produit dans le champ réglementaire. « Notre application détecte les signes précoces de… » est une revendication de finalité médicale. « Notre application vous aide à suivre vos mesures » ne l’est pas. Ce n’est pas une astuce de rédaction, c’est le cœur du sujet : votre marketing et votre notice décrivent la destination, et la destination fait le statut.
Quand la qualification est acquise, la classification suit. La règle 11 de l’annexe VIII du MDR traite spécifiquement des logiciels, et elle a durci les choses par rapport à l’ancienne directive : la plupart des logiciels d’aide à la décision sortent de la classe I, ce qui fait entrer un organisme notifié dans le projet. Cet organisme a un délai de prise en charge et un coût récurrent. Le découvrir six mois avant un lancement commercial est la plus classique des mauvaises surprises.
Où vivent les données, et qui en répond
Les données de santé à caractère personnel bénéficient d’une protection renforcée par le RGPD et, en France, d’un régime d’hébergement propre. L’article L.1111-8 du code de la santé publique impose que l’hébergement de ces données pour le compte d’un tiers soit assuré par un hébergeur certifié. Cette obligation vise l’activité d’hébergement, pas l’édition du logiciel.
La distinction est importante pour un éditeur. Si vous déployez votre application sur une offre managée déjà certifiée, vous vous appuyez sur le certificat de votre fournisseur et vous restez responsable de votre sécurité applicative. Si vous louez des serveurs que vos équipes administrent, ou si vous exploitez une plateforme en mode logiciel comme service pour vos clients, l’activité d’administration et d’exploitation vous revient et elle entre dans le périmètre du référentiel. Le montage technique décide, pas le vocabulaire commercial.
Le RGPD, lui, ne disparaît jamais. Base légale, information des personnes, durées de conservation, analyse d’impact, contrat de sous-traitance : ces obligations existent en parallèle, et aucune certification n’en dispense. Un projet bien tenu traite les deux sujets ensemble, avec une cartographie des flux écrite avant la première ligne de code.
Le socle français : Ségur, INS, Pro Santé Connect, MSSanté
Si vos utilisateurs sont des professionnels de santé ou des établissements, votre application ne vit pas seule. Elle doit s’insérer dans un socle national, construit autour de quelques briques que l’Agence du numérique en santé pilote. L’identité nationale de santé identifie le patient de façon unique et conditionne tout partage de document. Pro Santé Connect authentifie les professionnels par carte ou par application mobile. MSSanté transporte les échanges entre acteurs. Le dossier médical de Mon espace santé reçoit les documents produits.
Le Ségur du numérique en santé a fait de ce socle une condition d’accès au financement : un logiciel référencé, sur un couloir et une vague donnés, ouvre droit à une prise en charge de l’équipement pour les professionnels. Pour un éditeur, cela change l’équation commerciale. Un logiciel non référencé se vend contre le budget propre de l’établissement. Un logiciel référencé se vend contre un dispositif de financement. Vérifiez le couloir, la vague et la version du dossier de spécifications en vigueur auprès de l’Agence du numérique en santé, car ces éléments bougent.
Les normes qui structurent le développement
Trois normes reviennent dans tous les projets de dispositif médical logiciel, et elles ne se remplacent pas. IEC 62304 décrit le cycle de vie du logiciel et classe le produit en A, B ou C selon la gravité du dommage possible. Attention au piège : cette classe de sécurité logicielle n’est pas la classe MDR du dispositif, et confondre les deux fait dimensionner le travail de travers. ISO 13485 porte le système de management de la qualité. ISO 14971 organise la gestion des risques, de l’identification des dangers au risque résiduel global.
Ce corpus n’interdit pas de travailler en itérations, contrairement à une idée répandue dans les équipes produit. Il exige des enregistrements : une exigence tracée jusqu’au test qui la vérifie, une revue de conception documentée, une décision d’architecture justifiée, une bibliothèque tierce identifiée avec sa version et ses anomalies connues. La différence entre une équipe qui souffre et une équipe qui tient le rythme se joue là : produire ces enregistrements au fil de l’eau, ou tenter de les reconstituer à la fin.
Accès au marché : marquage CE, référencement, remboursement
Trois portes distinctes, souvent confondues. Le marquage CE autorise la mise sur le marché européen : il suppose un dossier technique, une évaluation clinique, une déclaration de conformité et, hors classe I, l’intervention d’un organisme notifié. Le référencement auprès de l’Agence du numérique en santé ouvre le financement Ségur sur un couloir donné. Le remboursement relève d’une procédure nationale d’évaluation et d’inscription sur une liste, avec ses propres critères.
Un produit peut être marqué CE sans être remboursé, référencé sans être un dispositif médical, ou remboursable sur un usage et pas sur un autre. Ces trois chantiers ont des calendriers différents et des interlocuteurs différents. Les mener en parallèle depuis le cadrage évite la situation la plus coûteuse : un produit techniquement prêt, commercialement bloqué.
L’intelligence artificielle et les données européennes
Deux textes européens s’ajoutent au paysage. Le règlement sur l’intelligence artificielle classe à haut risque les systèmes d’IA qui sont des dispositifs médicaux, ou des composants de sécurité de dispositifs médicaux, dès lors qu’un organisme notifié intervient au titre du MDR. Les obligations qui en découlent, gouvernance des données d’entraînement, documentation, journalisation, contrôle humain, robustesse, se combinent avec celles du MDR plutôt qu’elles ne les dupliquent.
Le règlement sur l’espace européen des données de santé organise de son côté l’accès du patient à ses données, les échanges transfrontaliers et l’usage secondaire pour la recherche. Il crée des exigences pour les systèmes de dossiers de santé électroniques. Son calendrier d’application est échelonné : vérifiez l’échéance qui vise votre catégorie de produit plutôt que de retenir une date unique.
Ce que la santé ajoute au budget et au calendrier
Les fourchettes publiées dans notre guide des prix restent la base : un premier produit viable se situe entre 15 000 et 40 000 € HT, un projet d’ambition moyenne entre 40 000 et 120 000 € HT, un projet complexe entre 120 000 et 300 000 € HT, avec une maintenance annuelle de 15 à 20 %. La santé ne multiplie pas ces montants par un coefficient magique. Elle ajoute des postes identifiables.
Ces postes sont l’hébergement certifié, plus cher qu’une infrastructure générique. La documentation et la traçabilité des exigences, qui représentent un temps d’ingénierie réel. Une vérification et une validation plus lourdes, avec des campagnes de tests formalisées. L’évaluation clinique quand le produit est un dispositif médical. Les audits, initiaux puis récurrents. Et un délai de mise sur le marché allongé par les créneaux d’organisme notifié. Chiffrez-les ligne à ligne dans le devis : c’est exactement ce que permet notre grille de lecture des devis.
Les cinq erreurs qui coûtent une refonte
- Écrire la promesse marketing avant de trancher la qualification. Une revendication de finalité médicale ajoutée en fin de projet fait basculer le produit dans un régime qu’il n’a pas été conçu pour supporter.
- Choisir l’hébergement à la fin. La migration vers une offre certifiée en cours de route touche l’architecture, les sauvegardes, la supervision et les contrats.
- Traiter la journalisation comme une fonctionnalité optionnelle. La traçabilité des accès aux données de santé se conçoit dans le modèle de données, pas dans un correctif.
- Reporter la documentation. Reconstituer a posteriori la traçabilité des exigences sur un code déjà écrit coûte plus cher que de la produire au fil de l’eau.
- Ignorer la réversibilité. Un export complet, documenté et testé est une exigence contractuelle et une fonctionnalité à développer. Beaucoup d’équipes la découvrent en audit.
Un cahier des charges qui pose ces cinq points dès la première version évite la majorité des reprises que nous constatons sur des produits déjà en ligne.
Le dossier, fiche par fiche
3 fiches sont en ligne à ce jour. Les suivantes sont au calendrier de publication : elles n’apparaissent ici qu’une fois publiées, pour ne renvoyer vers aucun lien mort.
Cadrer le projet
Statut de dispositif médical
Hébergement des données de santé
Les meilleures agences pour développer une application de santé (septembre 2026)
La sélection ci-dessous suit la méthodologie publiée du guide : identités vérifiables au registre Sirene de l’Insee, critères annoncés, aucune note d’avis agrégée. Digital Unicorn, éditeur de ce guide, ouvre le classement. Envoyez le même cahier des charges à plusieurs structures et comparez les devis ligne à ligne.
Digital Unicorn
Agence d’applications mobiles. Avis technique gratuit sur le périmètre, la stack et le budget.
LEDGER
Présente à Paris depuis 2011, avec 500 à 999 salariés au registre Sirene.
SYNOLIA
Créée en 2004, installée à Lyon. Effectif déclaré, 100 à 199 salariés (Sirene).
UNITEL CLOUD
Siège à Marseille, immatriculation 2021. L’Insee indique 20 à 49 salariés.
DESIRADE
Présente à Toulouse depuis 1997, avec 50 à 99 salariés au registre Sirene.
EXPERIS FRANCE
Créée en 1994, installée à Nantes. Effectif déclaré, 2 000 à 4 999 salariés (Sirene).
C-TECHNOLOGY
Créée en 2019, installée à Bordeaux. Effectif déclaré, 250 à 499 salariés (Sirene).
DERNIER CRI
Créée en 2010, installée à Lille. Effectif déclaré, 50 à 99 salariés (Sirene).
VOGO
Siège à Montpellier, immatriculation 2013. L’Insee indique 50 à 99 salariés.
Comment nous travaillons sur un projet de santé
Digital Unicorn développe des applications de santé pour des éditeurs, des établissements et des porteurs de projet. Nous ne sommes ni un organisme notifié, ni un hébergeur certifié, ni un cabinet d’affaires réglementaires. Notre rôle est le logiciel : nous cadrons la qualification avec vous, nous concevons une architecture qui tient les exigences de traçabilité et de réversibilité, nous développons en suivant IEC 62304 quand le produit est un dispositif médical, et nous produisons la partie applicative du dossier que votre organisme d’audit ou votre client demandera.
Concrètement, une première séance de trente minutes suffit à situer votre projet : dispositif médical ou non, hébergement à prévoir, socle français à intégrer, calendrier réaliste. Elle est gratuite et sans engagement. Appel direct au 06 32 64 24 80, ou courriel à contact@digitalunicorn.fr.
Questions fréquentes
Comment développer une application de santé en France ?
Dans cet ordre : qualifiez d’abord votre logiciel, dispositif médical ou non, parce que cette réponse commande tout le reste. Déterminez ensuite qui héberge les données de santé et sous quelle certification. Intégrez le socle français si vos utilisateurs sont des professionnels ou des établissements. Développez enfin en produisant la documentation au fil de l’eau, jamais après coup.
Faut-il être certifié HDS pour éditer une application de santé ?
Non, dans la plupart des projets. L’obligation porte sur l’hébergement des données de santé, pas sur l’édition du logiciel. Un éditeur qui déploie chez un hébergeur certifié s’appuie sur le certificat de celui-ci. La question se retourne si vous administrez vous-même l’infrastructure ou si vous exploitez la plateforme pour le compte de vos clients.
Toute application de santé est-elle un dispositif médical ?
Non. Le statut dépend de la destination que vous revendiquez. Un outil qui stocke, archive ou transmet des informations sans les interpréter reste hors du champ. Dès qu’un logiciel fournit une information destinée à une décision diagnostique ou thérapeutique, il entre dans le champ du règlement européen sur les dispositifs médicaux. Vos supports commerciaux engagent ce statut autant que votre code.
Combien de temps prend la mise sur le marché d’une application de santé ?
Un service qui n’est pas un dispositif médical suit le calendrier d’un projet logiciel classique, augmenté du temps de mise en place de l’hébergement et de la sécurité. Un dispositif médical de classe IIa ou supérieure ajoute la constitution du dossier technique, l’évaluation clinique et le passage devant un organisme notifié, dont le créneau se réserve longtemps à l’avance. C’est le facteur de calendrier le plus souvent sous-estimé.
Quelle différence entre le Ségur du numérique en santé et la certification HDS ?
Ce sont deux sujets sans rapport de dépendance. La certification porte sur l’hébergement des données. Le référencement Ségur porte sur les fonctions de votre logiciel et sur son interopérabilité avec le socle national. Un logiciel peut être hébergé chez un prestataire certifié sans être référencé, et le référencement suppose de toute façon un hébergement conforme.
Le marquage CE donne-t-il droit au remboursement ?
Non. Le marquage CE autorise la mise sur le marché européen. Le remboursement relève d’une procédure distincte, nationale, avec évaluation du service rendu et inscription sur une liste. Un dispositif marqué CE peut parfaitement rester sans prise en charge. Traitez les deux sujets en parallèle dès le cadrage, pas l’un après l’autre.