Application santé (healthtech) : réglementation et développement

Vous voulez développer une application santé ? Avant de vous lancer dans le code, posez-vous une question : savez-vous vraiment ce que signifie "traiter des données de santé" en France ? Parce que la différence entre une app bien-être et une app santé réglementée, c'est la différence entre un side-project et plusieurs mois de conformité. Et potentiellement des amendes à 6 chiffres si vous vous trompez.

Selon Grand View Research (2025), le marché mondial de la santé numérique représente 288,55 milliards de dollars et devrait atteindre 946 milliards d'ici 2030. En France, ce secteur explose avec plus de 350 startups healthtech répertoriées par France Digitale. Mais cette croissance s'accompagne d'un cadre réglementaire strict que beaucoup de développeurs sous-estiment.

Chez Eurus, on a accompagné des projets healthtech. Et la leçon qu'on en tire, c'est que la conformité n'est pas une étape finale — c'est le point de départ de l'architecture.

Qu'est-ce qu'une "donnée de santé" au sens du RGPD ?

Première surprise pour beaucoup de porteurs de projet : la définition est plus large qu'on ne le croit. Le RGPD considère comme donnée de santé toute information relative à la santé physique ou mentale d'une personne, passée, présente ou future. Ça inclut évidemment les diagnostics et prescriptions. Mais aussi le nombre de pas quotidiens, les cycles de sommeil, les mensurations, ou même... le fait qu'une personne utilise votre app.

Concrètement, si votre application permet de déduire l'état de santé d'un utilisateur, vous traitez des données de santé. Une app de suivi de règles ? Données de santé. Une app de coaching sportif qui mesure la fréquence cardiaque ? Données de santé. Un journal de humeur pour la santé mentale ? Données de santé.

La différence critique : bien-être vs dispositif médical

Là où ça se complique, c'est la frontière entre application de bien-être et dispositif médical. Une étude de l'ANSM (Agence Nationale de Sécurité du Médicament) révèle que 23% des applications santé téléchargées en France pourraient être qualifiées de dispositifs médicaux sans que leurs éditeurs n'en aient conscience.

La règle simplifiée :

• App bien-être : informations générales, pas de prétention médicale, pas de diagnostic
• Dispositif médical : revendication d'un bénéfice médical, aide au diagnostic, surveillance de pathologie

Un exemple ? Une app qui compte vos pas = bien-être. La même app qui prétend "détecter des signes précoces de Parkinson via l'analyse de la démarche" = dispositif médical classe IIa minimum. Et là, on parle de certification CE, d'études cliniques, et de plusieurs années de développement.

Le triptyque réglementaire français : RGPD, HDS, et certification

En France, développer une app santé implique de naviguer trois cadres réglementaires qui s'empilent. Pas se substituent — s'empilent.

1. Le RGPD renforcé pour les données de santé

Les données de santé sont des "données sensibles" au sens de l'article 9 du RGPD. Leur traitement est interdit par défaut, sauf exceptions limitées :

• Consentement explicite et éclairé
• Nécessité pour des soins de santé
• Intérêt public dans le domaine de la santé publique
• Recherche scientifique avec garanties appropriées

En pratique, la plupart des apps grand public s'appuient sur le consentement. Mais attention : ce consentement doit être distinct, informé, et révocable facilement. Pas question de le noyer dans des CGU de 47 pages.

Selon la CNIL (2025), 67% des applications santé françaises présentent des non-conformités en matière de recueil du consentement. Les erreurs les plus fréquentes :

• Consentement pré-coché (interdit)
• Absence de possibilité de refus sans perdre l'accès au service de base
• Information incomplète sur les finalités de traitement

2. L'hébergement HDS : une obligation, pas une option

Si vous stockez des données de santé de résidents français, vous devez utiliser un hébergeur certifié HDS (Hébergeur de Données de Santé). Pas "de préférence". Pas "recommandé". Obligatoire.

Cette certification, délivrée par des organismes accrédités par le COFRAC, garantit un niveau de sécurité spécifique : chiffrement, traçabilité, PCA/PRA, audits réguliers. Les géants du cloud (AWS, Azure, GCP) ont des offres HDS en France. Mais elles coûtent plus cher que leurs offres standard — comptez 20 à 40% de surcoût selon les configurations.

Chez Eurus, on évite de recommander des hébergeurs "presque HDS" ou des montages où seule une partie des données serait chez un hébergeur certifié. Si votre base utilisateurs contient ne serait-ce qu'un champ "pathologie", l'ensemble du système qui y accède doit être HDS. Point.

3. La certification dispositif médical (si applicable)

Si votre application fait plus que du bien-être — si elle prétend aider au diagnostic, au traitement, ou à la surveillance d'une maladie — elle devient un dispositif médical logiciel (SaMD : Software as a Medical Device).

Depuis mai 2021 et l'entrée en vigueur du règlement MDR 2017/745, les exigences ont explosé. Même une app classe I (la plus basse) nécessite :

• Un système de management de la qualité (SMQ)
• Une documentation technique complète
• Une analyse des risques selon ISO 14971
• Un responsable de la conformité réglementaire

Pour les classes supérieures (IIa, IIb, III), ajoutez les études cliniques, l'intervention d'un organisme notifié, et des délais qui se comptent en années.

GM Insights (2025) estime que le coût moyen de mise en conformité MDR pour un logiciel médical s'élève à 180 000 à 450 000 euros, hors études cliniques. C'est une réalité que beaucoup de startups découvrent trop tard.

Architecture technique d'une app santé conforme

La conformité n'est pas une couche qu'on ajoute après coup. Elle doit être intégrée dès la conception. Voici les principes qu'on applique chez Eurus.

Privacy by Design : pas juste un buzzword

Le RGPD impose la "protection des données dès la conception". En pratique, ça signifie :

Minimisation des données : ne collectez que ce dont vous avez strictement besoin. Sur DrMilou, l'app vétérinaire qu'on maintient, on a passé deux sprints complets à supprimer des champs "au cas où" dans les formulaires. Résultat : moins de données = moins de risques = moins de conformité à gérer.

Pseudonymisation : séparez les données identifiantes des données de santé. Dans l'idéal, la base qui contient "diabète de type 2" ne contient pas "Jean Dupont". Elle contient un identifiant technique, et la correspondance est stockée ailleurs, avec des accès restreints.

Chiffrement de bout en bout : pour les données les plus sensibles (messages patient-médecin, résultats d'examens), le chiffrement E2E garantit que même vous, éditeur, ne pouvez pas lire les contenus en clair.

Gestion du consentement : un module à part entière

Le consentement n'est pas un simple checkbox à l'inscription. C'est un module technique qui doit :

• Enregistrer la preuve du consentement (horodatage, version des CGU, texte exact consenti)
• Permettre le retrait à tout moment
• Déclencher la suppression ou l'anonymisation des données concernées
• Gérer plusieurs finalités indépendamment (newsletter ≠ partage avec partenaires ≠ recherche)

On a vu des projets où le retrait du consentement cassait l'intégrité référentielle de la base. Les développeurs avaient oublié qu'il fallait pouvoir supprimer des données liées à un utilisateur. Du coup, soit on refuse le retrait (illégal), soit on corrompt la base. Mauvais choix dans les deux cas.

Journalisation et traçabilité

L'HDS impose une traçabilité des accès aux données. Qui a consulté quoi, quand, depuis quelle IP. Ces logs doivent être conservés 6 mois minimum et 5 ans maximum (selon les cas).

C'est un point technique souvent négligé : la journalisation a un impact sur les performances. Sur une app avec beaucoup de lectures (dossier patient consulté 50 fois par jour), chaque accès génère une écriture de log. Architecturez votre système de logs dès le départ, avec buffer et écriture asynchrone.

Les erreurs qu'on voit le plus souvent

Après plusieurs projets healthtech, voici les pièges classiques.

Erreur 1 : "On verra la conformité plus tard"

Le plus mortel. On construit un MVP "pour valider le marché", en se disant qu'on se mettra en conformité une fois que ça marchera. Sauf que :

• L'architecture n'est pas conçue pour (données mélangées, pas de logs, hébergement non-HDS)
• Le coût de remise en conformité est souvent supérieur à une réécriture
• Et entre-temps, vous avez traité illégalement des données de santé

Erreur 2 : Confondre consentement et CGU

Accepter les CGU n'est pas un consentement au traitement de données de santé. La CNIL l'a répété : le consentement pour les données sensibles doit être distinct, explicite, et granulaire. Un unique "J'accepte tout" ne suffit pas.

Erreur 3 : Sous-estimer le scope de l'HDS

L'obligation HDS s'applique au "traitement" des données de santé. Ça inclut :

• Le stockage (évidemment)
• Mais aussi les sauvegardes
• Les environnements de développement contenant des données réelles
• Les outils d'analytics si les données ne sont pas correctement anonymisées
• Les systèmes de log si ils contiennent des données de santé

On a vu un projet utiliser un hébergeur HDS pour la prod... et Firebase (non-HDS) pour les crash reports, qui incluaient l'état de l'utilisateur au moment du crash. Données de santé non-HDS = non-conformité.

Erreur 4 : Croire qu'une startup est exemptée

La taille de l'entreprise ne change rien aux obligations. Une startup de 3 personnes qui traite des données de santé a les mêmes obligations qu'un groupe hospitalier. Les sanctions sont adaptées au chiffre d'affaires, certes. Mais une amende de 2% du CA, quand le CA est faible, peut suffire à couler une jeune entreprise.

Cas d'usage : ce qui marche dans la healthtech

Malgré ce cadre contraignant, le marché healthtech explose. Selon Towards Healthcare (2025), le marché des applications de suivi de santé atteindra 67,97 milliards de dollars d'ici 2034 (contre 18,68 milliards en 2025). Où sont les opportunités ?

Téléconsultation et suivi patient

Post-Covid, la télémédecine s'est démocratisée. Les plateformes comme Doctolib, Qare ou Livi ont ouvert la voie. Mais il reste de la place pour des solutions verticalisées : télédermatologie, télépsychiatrie, suivi post-opératoire.

Le modèle qui fonctionne : une app patient couplée à une interface praticien, avec messagerie sécurisée, partage de documents, et intégration au DMP (Dossier Médical Partagé).

Observance et suivi de traitement

47% des patients chroniques ne suivent pas correctement leur traitement (OMS, 2024). Les apps d'observance — rappels de prise, suivi des effets secondaires, communication avec le pharmacien — ont un vrai marché. Attention toutefois : dès qu'on prétend "améliorer l'observance", on flirte avec le dispositif médical.

Bien-être mental

Le segment qui croît le plus vite. Gestion du stress, méditation, suivi de l'humeur, exercices de TCC (thérapie cognitivo-comportementale). Les apps comme Petit Bambou ont montré qu'un modèle freemium pouvait fonctionner.

L'astuce réglementaire : rester dans le "bien-être" sans prétendre traiter l'anxiété ou la dépression. La frontière est fine, mais cruciale.

Coordination des soins

Chez Eurus, on a travaillé sur DrMilou dans le vétérinaire — mais les problématiques sont similaires en santé humaine. Les cabinets, cliniques et hôpitaux ont besoin d'outils pour coordonner les parcours de soins. Agenda partagé, transmission d'informations entre professionnels, historique patient accessible.

Les cabinets vétérinaires ont des contraintes qu'on n'imaginait pas : connexion internet instable, PC sous Windows XP, urgences qui arrivent pendant qu'on tape une ordonnance. La santé humaine n'est pas si différente : les logiciels métier doivent fonctionner dans des conditions dégradées.

Budget et timeline : soyez réalistes

Développer une app santé conforme, c'est minimum 6 mois de travail pour un MVP, et généralement plus proche de 9-12 mois si vous visez une certification.

| Poste | Fourchette | |-------|------------| | Développement technique (app + back) | 80 000 - 200 000 € | | Conformité RGPD/HDS | 15 000 - 40 000 € | | Certification dispositif médical (si applicable) | 150 000 - 500 000 € | | Hébergement HDS (annuel) | 8 000 - 30 000 € | | Maintenance conformité (annuel) | 10 000 - 25 000 € |

Ces chiffres peuvent sembler élevés. Mais ils reflètent la réalité d'un secteur réglementé. En 3 ans chez Eurus, j'ai vu des projets échouer non pas à cause du code, mais parce que personne n'avait vraiment compris le besoin métier — et le besoin en healthtech, c'est d'abord la conformité.

Checklist de lancement

Avant de mettre une app santé en production :

✅ Qualification réglementaire : votre app est-elle un dispositif médical ? Faites-le évaluer par un consultant spécialisé
✅ DPO désigné : pour une app santé grand public, un DPO (même externe) est quasi-indispensable
✅ Registre de traitement : documentez tous vos traitements de données
✅ AIPD réalisée : l'Analyse d'Impact sur la Protection des Données est obligatoire pour les données de santé
✅ Contrat hébergeur HDS : signé, pas juste envisagé
✅ Politique de confidentialité : rédigée en langage clair, pas du juridique incompréhensible
✅ Mécanisme de suppression : testé, et qui fonctionne vraiment
✅ Procédure de notification de failles : vous avez 72h pour notifier la CNIL en cas de breach

La suite ?

Si vous avez un projet healthtech et que vous voulez éviter les pièges classiques, parlons-en. Chez Eurus, on accompagne des projets de A à Z : cadrage réglementaire, architecture technique, développement, et mise en conformité.

Notre règle d'or : un MVP en 6 semaines max quand c'est possible. Mais pour la healthtech, on adapte — parce que sortir vite sans être conforme, c'est sortir pour se faire fermer.

Discutons de votre projet →

---

FAQ

Mon app de méditation doit-elle être certifiée dispositif médical ?

Généralement non, si vous restez dans le "bien-être" (relaxation, gestion du stress quotidien). Elle le devient si vous prétendez traiter l'anxiété pathologique ou la dépression. La frontière dépend de vos revendications marketing autant que des fonctionnalités.

Puis-je utiliser AWS ou GCP pour héberger des données de santé ?

Oui, à condition d'utiliser leurs offres certifiées HDS (AWS France avec certification HDS, ou Azure France HDS). Attention : ce n'est pas automatique, vous devez souscrire les options spécifiques et configurer correctement votre infrastructure.

Combien de temps prend une certification dispositif médical ?

Pour une app logicielle classe I : 6 à 12 mois si tout est bien préparé. Pour une classe IIa ou supérieure : 18 à 36 mois, voire plus si des études cliniques sont nécessaires.

Dois-je avoir un DPO pour une petite app santé ?

Le RGPD impose un DPO si vous traitez des données de santé "à grande échelle". La notion est floue, mais au-delà de quelques milliers d'utilisateurs, c'est plus prudent d'en avoir un. Il peut être externe (consultant) si vous n'avez pas les moyens d'un poste dédié.

Que se passe-t-il si je suis contrôlé par la CNIL et non-conforme ?

Plusieurs issues possibles : mise en demeure avec délai de mise en conformité, sanction financière (jusqu'à 4% du CA ou 20M€), voire suspension du traitement. Pour une startup, une suspension peut être fatale même sans amende.