Application mobile santé sur mesure : les contraintes réglementaires que peu d'agences maîtrisent

1. La première question : votre app est-elle un dispositif médical ?

1.1 La frontière qui change tout

La toute première question à se poser — avant même la première ligne de code, avant même la maquette — est de savoir si l'application relève ou non du statut de dispositif médical (DM) au sens du règlement européen MDR (Medical Device Regulation, 2017/745). Cette qualification n'est pas une option administrative : elle conditionne l'ensemble du projet. Une app qualifiée DM doit suivre un processus rigoureux d'évaluation de conformité, obtenir un marquage CE médical, mettre en place un système de management de la qualité, documenter sa gestion des risques, et organiser une surveillance après mise sur le marché. Une app non-DM est libre de ces contraintes spécifiques.

Le critère déterminant tient à la finalité revendiquée. Si l'application a une finalité médicale — diagnostiquer, prévenir, surveiller, prédire, pronostiquer ou traiter une maladie, ou aider à une décision médicale — elle bascule dans le champ du dispositif médical. Une app qui calcule une dose, qui interprète des symptômes pour suggérer une conduite, qui analyse des données physiologiques pour alerter sur un risque, est très probablement un DM. À l'inverse, une app de pur bien-être, qui se contente d'enregistrer une activité ou de fournir de l'information générale sans visée médicale, échappe généralement à cette qualification.

1.2 Les classes de risque : de I à III

Si l'app est qualifiée dispositif médical, elle se voit attribuer une classe de risque qui détermine l'intensité des obligations. Le MDR définit une gradation, des dispositifs à faible risque jusqu'aux dispositifs critiques. Les logiciels médicaux relèvent le plus souvent des classes intermédiaires, avec une règle spécifique (la fameuse règle 11 du MDR) qui tend à classer assez haut les logiciels destinés à fournir des informations utilisées pour des décisions à finalité diagnostique ou thérapeutique. Plus la classe est élevée, plus l'implication d'un organisme notifié et la lourdeur de la documentation augmentent.

Déterminer la classe n'est pas un exercice à prendre à la légère, et il gagne à être réalisé avec un regard expert dès le cadrage. Une erreur de qualification découverte tardivement peut imposer une remise à plat complète du projet. C'est précisément le type d'écueil que notre approche du développement santé sur mesure vise à anticiper dès la phase de conception.

2. L'hébergement des données de santé : la certification HDS

2.1 Pourquoi un hébergeur « cloud classique » ne suffit pas

Dès lors qu'une application mobile collecte, traite ou conserve des données de santé à caractère personnel, l'hébergement de ces données doit, en France, être assuré par un hébergeur certifié HDS (Hébergeur de Données de Santé). Cette obligation, issue du Code de la santé publique, n'a rien d'optionnel : héberger des données de santé sur une infrastructure non certifiée est une non-conformité majeure, exposant à des sanctions et, surtout, à un risque réputationnel et juridique considérable en cas d'incident.

Beaucoup d'agences ignorent ou minimisent cette exigence et déploient des applications santé sur des hébergements standards, par méconnaissance ou par facilité. C'est l'une des erreurs les plus graves et les plus fréquentes. La certification HDS impose à l'hébergeur un ensemble d'exigences de sécurité, de traçabilité, de confidentialité et de réversibilité qui vont bien au-delà d'un hébergement cloud ordinaire.

2.2 Architecture : où vivent les données, et comment elles circulent

La conformité ne se limite pas au choix d'un hébergeur certifié. Elle impose de penser l'architecture des flux de données de bout en bout : quelles données sont collectées sur le terminal, lesquelles transitent vers le serveur, lesquelles sont stockées, où, et avec quel chiffrement. Une bonne conception minimise les données collectées (principe de minimisation), chiffre les données au repos et en transit, et sépare lorsque c'est pertinent les données directement identifiantes des données de santé. Cette réflexion d'architecture doit précéder le développement, car elle structure l'ensemble du système.

3. RGPD santé : la donnée la plus protégée qui soit

3.1 Données de santé = catégorie particulière

Le RGPD classe les données de santé parmi les catégories particulières de données (anciennement « données sensibles »), dont le traitement est par principe interdit, sauf exceptions encadrées. Cela signifie que toute application santé doit reposer sur une base légale solide pour traiter ces données : le plus souvent le consentement explicite de la personne, parfois une autre base prévue par le règlement selon le contexte (prise en charge médicale, intérêt vital, etc.). Ce consentement doit être libre, spécifique, éclairé et univoque — un simple opt-in noyé dans des conditions générales ne suffit pas.

Au-delà de la base légale, le RGPD impose un faisceau d'obligations : information transparente des personnes, respect de leurs droits (accès, rectification, effacement, portabilité), minimisation des données collectées, limitation de la durée de conservation, sécurité par conception et par défaut, et — pour les traitements à risque élevé comme le sont souvent les apps santé — la réalisation d'une analyse d'impact relative à la protection des données (AIPD/DPIA).

3.2 Privacy by design : la conformité se construit, elle ne se rajoute pas

Le principe de protection des données dès la conception et par défaut (privacy by design and by default) est au cœur du RGPD. Il signifie que la protection de la vie privée doit être intégrée à chaque décision de conception, dès l'origine du projet, et non ajoutée comme une couche cosmétique à la fin. Concrètement : ne collecter que les données strictement nécessaires, configurer par défaut les options les plus protectrices, chiffrer systématiquement, anonymiser ou pseudonymiser dès que possible, et limiter les accès au strict besoin.

Cette philosophie a une conséquence directe sur le choix du prestataire : une agence qui découvre les contraintes RGPD santé en cours de route ne peut pas faire du privacy by design — par définition, elle ne l'a pas intégré dès la conception. C'est pourquoi la maîtrise réglementaire doit être présente avant le premier atelier de cadrage, et non acquise péniblement pendant le projet.

4. L'IA dans les apps santé : opportunités et précautions redoublées

4.1 Quand l'IA fait basculer l'app dans le dispositif médical

L'intégration d'intelligence artificielle dans une application santé — analyse d'images, détection d'anomalies, aide à la décision, prédiction de risque — démultiplie la valeur potentielle, mais elle accroît aussi le risque de qualification en dispositif médical. Une IA qui interprète des données pour orienter une décision médicale a, par nature, une finalité médicale. Le règlement européen sur l'IA (AI Act) ajoute par ailleurs une couche d'exigences pour les systèmes d'IA à haut risque, dont relèvent typiquement les usages médicaux.

Cela ne signifie pas qu'il faille renoncer à l'IA — au contraire, c'est l'un des leviers d'innovation les plus puissants en santé. Cela signifie qu'il faut concevoir ces fonctionnalités avec une conscience aiguë du cadre : documentation des données d'entraînement, explicabilité, gestion des biais, validation clinique, supervision humaine. Une IA santé bien conçue est une IA dont chaque décision peut être tracée, expliquée et, lorsque c'est requis, validée par un professionnel.

4.2 IA souveraine : maîtriser où vont les données patient

L'usage de l'IA pose une question critique en santé : où sont traitées les données envoyées au modèle ? Recourir à une API d'IA hébergée hors UE, sans garantie, pour traiter des données de santé est un risque majeur. Les architectures souveraines — modèles déployés sur infrastructure maîtrisée, ou fournisseurs offrant des garanties contractuelles fortes de localisation et de non-réutilisation — sont souvent indispensables en contexte santé. Concevoir une IA conversationnelle santé conforme suppose de penser cette souveraineté dès l'architecture.

5. Trois familles de projets, trois trajectoires réglementaires

5.1 Le suivi de pathologie chronique

Une application destinée à accompagner des patients atteints d'une pathologie chronique — recueil de mesures, suivi de symptômes, rappels de traitement, alertes en cas de valeurs anormales — est l'un des cas les plus exigeants. Dès lors qu'elle interprète des données pour signaler un risque ou orienter une conduite, elle bascule dans le dispositif médical, héberge des données de santé en HDS, et doit organiser une surveillance après mise sur le marché. C'est aussi l'un des cas où la valeur clinique est la plus forte : bien conçue, ce type d'app améliore réellement l'observance et la prise en charge. La règle d'or est d'assumer le cadre DM dès le départ plutôt que de tenter de le contourner.

5.2 L'accompagnement et l'observance sans visée diagnostique

Une application qui se contente d'accompagner — rappels de prise de médicament, conseils d'hygiène de vie, journal de bord, information validée — sans interpréter de données pour produire une décision médicale peut, selon sa conception précise, rester hors du champ du dispositif médical. La frontière est subtile : un simple rappel n'est pas une finalité médicale, mais une analyse qui « conseille » de modifier un traitement l'est. Ces projets exigent un cadrage fin de chaque fonctionnalité pour rester du bon côté de la ligne, tout en respectant pleinement le RGPD santé si des données de santé sont collectées.

5.3 Le bien-être et la prévention grand public

Les applications de bien-être — activité physique, sommeil, alimentation, gestion du stress — sans visée médicale échappent généralement à la qualification de dispositif médical. Pour autant, elles ne sont pas en zone de non-droit : dès qu'elles traitent des données relevant de la santé, le RGPD s'applique avec ses exigences renforcées. Beaucoup de porteurs de projet sous-estiment ce point, croyant qu'une app « grand public » est exempte d'obligations. La distinction entre dispositif médical et non-dispositif ne dispense jamais des règles de protection des données de santé.

En santé numérique, la question n'est jamais « faut-il être conforme ? » mais « quel niveau de conformité s'applique à ce projet précis ? ». Y répondre tôt est la condition de tout le reste.
— Principe de cadrage, Agence DYNSEO

6. La méthode : intégrer la conformité dès la première heure

7. Pourquoi le choix de l'agence est un choix réglementaire

7.1 Le portfolio ne dit rien de la maîtrise réglementaire

Une agence peut avoir réalisé de superbes applications grand public et être totalement démunie face aux contraintes santé. Le design, la qualité du code, l'expérience utilisateur sont nécessaires mais pas suffisants. Ce qui distingue une agence capable de mener un projet santé, c'est sa compréhension du cadre réglementaire et sa capacité à l'intégrer dès la conception. Une question simple, posée dès le premier rendez-vous, est révélatrice : « comment qualifiez-vous le statut réglementaire de mon app, et comment l'architecture HDS et RGPD sera-t-elle pensée ? » Une réponse vague est un signal d'alarme.

7.2 Le coût de l'expertise est inférieur au coût de l'erreur

Faire appel à une agence qui maîtrise le cadre santé représente un investissement initial parfois supérieur à celui d'un prestataire généraliste. Mais ce surcoût apparent est dérisoire face au coût d'une erreur réglementaire : reprise complète de l'architecture pour passer en HDS, abandon d'une fonctionnalité parce qu'elle imposait un marquage CE non anticipé, sanction CNIL, perte de confiance des utilisateurs après un incident de sécurité. En santé numérique, l'économie sur l'expertise réglementaire est presque toujours une fausse économie.

8. Synthèse : la checklist de conformité d'une app santé

8.1 Les questions à se poser avant de lancer

Avant d'engager un projet d'application mobile santé, une organisation devrait pouvoir répondre clairement à un ensemble de questions structurantes. Ces questions ne sont pas des cases à cocher administratives : ce sont les fondations qui déterminent si le projet est viable et conforme, ou s'il court vers une impasse.

8.2 La conformité comme avantage concurrentiel

Il serait erroné de voir la conformité réglementaire uniquement comme une contrainte. En santé numérique, elle est aussi un puissant argument de confiance. Un établissement de santé, un professionnel ou un patient choisira plus volontiers une solution dont la conformité est démontrée — hébergement HDS, RGPD maîtrisé, marquage CE le cas échéant — qu'une solution séduisante mais opaque sur ses garanties. La conformité bien menée n'est pas seulement un risque évité ; c'est un actif commercial. Les acteurs qui l'intègrent dès la conception construisent un avantage durable sur ceux qui la subissent.