CI/CD mobile : livrer chaque semaine sans casser la production
5 min de lecture
À retenir
- Trois cadres distincts s’appliquent : le RGPD (toujours), l’hébergement HDS (selon le contexte de soin), le règlement dispositif médical (selon la finalité).
- La finalité revendiquée par l’application — dans son interface, sa fiche store et son marketing — décide de son statut de dispositif médical, pas la technologie.
- HDS et RGPD renforcé ajoutent typiquement 15 à 30 % au budget de développement et 3 à 6 semaines au planning.
- Un dispositif médical logiciel change d’échelle : système qualité, gestion des risques, organisme notifié à partir de la classe IIa, et un calendrier qui se compte en trimestres.
- La décision la plus rentable se prend au cadrage : délimiter précisément ce que l’application affirme faire.
Sur un projet d’application santé, la première question n’est pas « React Native ou natif ? ». C’est « qu’est-ce que l’application affirme faire pour la santé de ses utilisateurs ? ». La réponse détermine trois choses : le cadre RGPD applicable, l’obligation ou non d’un hébergement certifié HDS, et le basculement éventuel dans le régime du dispositif médical. Ces trois cadres pèsent davantage sur le budget et le calendrier que n’importe quel choix technique.
Ce guide les reprend dans l’ordre où ils se posent en cadrage, avec ce qu’ils coûtent vraiment. Pour une vue d’ensemble de ce que nous construisons dans le secteur, voyez notre page dédiée à l’application mobile santé.
Trois cadres, trois questions différentes
On mélange souvent ces sujets. Ils répondent pourtant à des questions distinctes, et une même application peut être concernée par un, deux ou les trois.
| Cadre | La question qu’il pose | Quand il s’applique |
|---|---|---|
| RGPD, article 9 | Traitez-vous des données qui révèlent l’état de santé d’une personne ? | Presque toujours, dès qu’il y a santé ou bien-être |
| Hébergement HDS (Code de la santé publique) | Hébergez-vous ces données dans un contexte de prévention, de soin ou de suivi ? | Applications liées à un professionnel, un établissement ou un parcours de soin |
| Règlement (UE) 2017/745 (dispositif médical) | Le logiciel a-t-il une finalité médicale pour un patient donné ? | Diagnostic, surveillance, aide à la décision thérapeutique, calcul de dose… |
L’erreur classique consiste à traiter le premier cadre et à découvrir les deux autres à trois semaines de la publication. À ce stade, l’hébergement est déjà choisi, l’architecture figée et la fiche store rédigée.
Le RGPD appliqué aux données de santé
Les données de santé font partie des catégories particulières de données de l’article 9 du RGPD. Leur traitement est interdit par principe, sauf exceptions — dont le consentement explicite de la personne, ou les traitements nécessaires aux soins sous la responsabilité d’un professionnel soumis au secret.
La notion est large. Un rythme cardiaque, un journal d’humeur, un poids suivi dans le temps, une prise de médicament ou un simple rendez-vous chez un spécialiste peuvent suffire à révéler un état de santé. Une application de méditation ou de coaching sportif est donc très souvent concernée, même si personne n’y parle de maladie.
Ce que cela impose concrètement dans le développement :
- Un consentement explicite et séparé, distinct de l’acceptation des conditions générales, recueilli avant la première donnée sensible et révocable depuis l’application.
- Une analyse d’impact (AIPD) dans la grande majorité des cas, puisque le traitement de données sensibles à grande échelle en fait partie. Elle se conduit pendant la conception.
- Un délégué à la protection des données obligatoire si le traitement à grande échelle de données sensibles est au cœur de votre activité.
- Des SDK tiers réduits au strict nécessaire. Un outil d’analytics ou de crash reporting qui remonte un nom d’écran comme « suivi-traitement-diabète » transmet déjà une donnée de santé à un tiers.
- Du chiffrement de bout en bout de la chaîne : en transit, au repos, et sur l’appareil pour ce qui est mis en cache.
- Une journalisation des accès aux données, pour savoir qui a consulté quoi et quand.
Nous avons détaillé la conformité générale dans notre article sur le RGPD appliqué à une application mobile ; tout ce qui y figure s’applique ici, en version renforcée.
HDS : qui est concerné, et ce que ça change
L’obligation d’hébergement certifié HDS vise l’hébergement de données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte du professionnel, de l’établissement ou du patient lui-même.
En pratique, les situations se répartissent ainsi :
| Type d’application | HDS en règle générale |
|---|---|
| Suivi patient prescrit ou utilisé par un médecin, un kiné, une clinique | Oui |
| Téléconsultation, messagerie patient–soignant | Oui |
| Prise de rendez-vous avec motif médical détaillé | Oui, dès que des données de santé sont stockées |
| Programme de prévention porté par un organisme de santé | Oui |
| Coaching sportif, méditation, nutrition grand public, sans professionnel de santé | Non, mais RGPD article 9 applicable |
| Outil interne d’un cabinet (planning, facturation) sans donnée médicale | Non |
La certification porte sur l’hébergeur, pas sur votre application. Vous n’êtes pas certifié : vous choisissez un hébergeur certifié pour le périmètre concerné — infrastructure seule, ou jusqu’à l’infogérance et la sauvegarde selon le contrat. Les grands fournisseurs cloud comme plusieurs acteurs européens proposent des offres certifiées ; la version révisée du référentiel exige en outre que les données soient hébergées dans l’Espace économique européen.
Ce que cela change techniquement :
- Tous les composants qui voient passer les données doivent être dans le périmètre : base, stockage des fichiers, sauvegardes, files de messages, mais aussi les services annexes. Un service d’envoi d’e-mails ou de notifications qui transporte un contenu médical sort du périmètre s’il n’est pas couvert.
- Les notifications push doivent être neutres. Le contenu transite par les serveurs d’Apple et de Google : « Vous avez un nouveau message » plutôt que « Vos résultats d’analyse sont disponibles ».
- Les environnements de recette ne reçoivent jamais de vraies données patients. Il faut des jeux de données fictifs dès le départ.
- Le contrat d’hébergement doit contenir des clauses spécifiques, et le choix se fait tôt : migrer d’un hébergement standard vers un hébergement HDS en cours de projet coûte plusieurs semaines.
Le piège le plus fréquent : une application pensée « bien-être » à qui l’on ajoute en cours de route un espace « partager avec mon médecin ». Cette seule fonctionnalité fait entrer le produit dans un contexte de soin, donc dans le périmètre HDS, et parfois dans le débat sur le dispositif médical. Décidez-en au cadrage, pas en version 1.3.
La frontière bien-être / dispositif médical
C’est la question qui a le plus d’impact, et elle se tranche sur un critère simple à énoncer, délicat à appliquer : la finalité médicale revendiquée par le fabricant.
Un logiciel est un dispositif médical lorsqu’il est destiné à des fins de diagnostic, de prévention, de surveillance, de prédiction, de pronostic, de traitement ou d’atténuation d’une maladie, pour un patient donné. Ce n’est pas la technologie qui compte, c’est ce que vous affirmez — dans l’interface, dans la fiche App Store et Google Play, sur le site, dans les supports commerciaux.
Quelques repères concrets :
| Fonctionnalité | Lecture générale |
|---|---|
| Afficher le nombre de pas et un objectif quotidien | Bien-être |
| Proposer des séances de respiration « pour se détendre » | Bien-être |
| Stocker et afficher des comptes rendus transmis par un médecin | En général pas un DM : pas d’interprétation |
| Rappeler une prise de médicament saisie par l’utilisateur | En général pas un DM |
| Calculer une dose d’insuline à partir d’une glycémie | Dispositif médical |
| Alerter sur un risque de décompensation à partir de mesures | Dispositif médical |
| Détecter une anomalie sur une photo de peau | Dispositif médical |
| « Aider à réduire les symptômes de l’anxiété » | Zone grise, la formulation peut suffire à basculer |
La dernière ligne est la plus instructive. Deux applications au code identique peuvent avoir deux statuts différents selon ce que dit leur page d’accueil. C’est pour cela que la rédaction des promesses produit fait partie du cadrage réglementaire, au même titre que l’architecture.
Si l’application est un dispositif médical, la règle de classification propre aux logiciels place la plupart des logiciels d’aide à la décision en classe IIa ou au-delà. Or dès la classe IIa, un organisme notifié doit évaluer le dispositif avant le marquage CE. S’y ajoutent un système de management de la qualité (la norme ISO 13485 est la référence), un cycle de vie logiciel documenté (IEC 62304), une gestion des risques (ISO 14971), une évaluation clinique et une surveillance après commercialisation. Si le logiciel intègre de l’IA et relève d’un organisme notifié, il est aussi considéré comme système à haut risque au titre de l’AI Act.
Rien de cela n’est insurmontable, mais ce n’est plus un projet d’application : c’est un projet de dispositif, avec un fabricant responsable, un calendrier en trimestres et un budget réglementaire propre.
Ce que ça change au budget
Les ordres de grandeur ci-dessous sont hors taxes et correspondent à ce que nous constatons en cadrage. Ils s’ajoutent aux fourchettes habituelles d’une application complète iOS et Android, soit 35 000 à 80 000 €.
| Poste | Application bien-être (RGPD art. 9) | Application santé HDS, hors DM |
|---|---|---|
| Cadrage réglementaire, registre, AIPD | 3 000 – 6 000 € | 5 000 – 10 000 € |
| Sécurité renforcée (chiffrement, journalisation, gestion fine des accès) | 3 000 – 8 000 € | 6 000 – 15 000 € |
| Architecture sur hébergement HDS, périmètre des services annexes | — | 4 000 – 10 000 € |
| Test d’intrusion avant mise en production | 3 000 – 8 000 € | 5 000 – 12 000 € |
| Hébergement mensuel | tarif standard | en général 1,5 à 3 fois le tarif standard |
| Surcoût total sur le développement | ≈ 10 – 20 % | ≈ 15 – 30 % |
+15 à 30 %Surcoût de développement typique d’une application HDS hors dispositif médical
+3 à 6 sem.Allongement du planning lié à la conformité et aux tests de sécurité
45 – 110 k€Fourchette HT d’une application santé iOS + Android hors DM
Pour un dispositif médical, il est honnête de ne pas donner de chiffre unique. Le coût du système qualité, de la documentation technique, de l’évaluation clinique et de l’organisme notifié dépend de la classe et de ce que l’entreprise possède déjà. Il est fréquent qu’il égale ou dépasse le budget de développement, et une partie n’est pas du travail d’agence : c’est celui d’un consultant réglementaire et de l’organisme notifié. Notre rôle est alors de produire un logiciel dont le développement, les tests et la traçabilité s’insèrent dans ce dossier.
La maintenance augmente aussi : mises à jour de sécurité suivies, revues d’accès, tests d’intrusion périodiques. Comptez le haut de nos fourchettes habituelles de maintenance, entre 900 et 3 500 € par mois selon le périmètre.
Ce que ça change au planning
Sur une application santé hors dispositif médical, le calendrier type s’allonge d’un mois à un mois et demi par rapport à une application standard, parce que certaines étapes ne peuvent pas être parallélisées :
- Cadrage réglementaire (1 à 2 semaines). Qualification DM ou non, périmètre HDS, base légale, liste des données, liste des SDK. C’est ici que l’on rédige les promesses produit.
- Choix de l’hébergeur et contractualisation (2 à 4 semaines, en parallèle du design). Les délais commerciaux des offres HDS sont rarement courts.
- AIPD (en parallèle de la conception). Ses conclusions modifient souvent l’architecture : pseudonymisation, séparation des identifiants, durées de conservation.
- Développement avec revue de sécurité à chaque livraison, pas seulement à la fin.
- Test d’intrusion et corrections (2 à 3 semaines) avant la publication.
- Publication. Apple et Google demandent des justifications supplémentaires pour les applications médicales et vérifient la cohérence entre la fiche store et l’usage réel des données.
Pour un dispositif médical, l’ordre de grandeur change : entre la constitution du système qualité, le développement documenté et l’évaluation par un organisme notifié, il faut raisonner en 12 à 24 mois avant le marquage CE pour une classe IIa. D’où l’intérêt, pour beaucoup de porteurs de projet, de lancer d’abord une version non médicale — sans promesse de diagnostic ni de surveillance — pour apprendre, puis de construire la version dispositif sur des bases qualité posées dès le départ.
Réduire le coût sans prendre de risque
Quatre décisions, toutes à prendre en cadrage, font l’essentiel de la différence.
Minimiser les données collectées. Chaque champ médical supprimé réduit le périmètre de l’AIPD, des tests et de l’hébergement. La question « en avons-nous besoin pour le parcours principal ? » est la même que pour le périmètre d’un MVP, avec un coût d’erreur plus élevé.
Séparer ce qui est sensible de ce qui ne l’est pas. Le catalogue de contenus, les comptes, la facturation n’ont pas toujours besoin d’être dans le périmètre HDS. Une architecture qui isole le cœur médical limite la facture d’hébergement.
Écrire les promesses produit avec la même rigueur que le code. Si l’application n’est pas un dispositif médical, ses textes ne doivent pas le laisser entendre. Une formulation mal choisie sur la fiche store coûte plus qu’une fonctionnalité.
Choisir des SDK compatibles dès le départ. Remplacer un outil d’analytics ou de messagerie en fin de projet parce qu’il transfère des données hors de l’UE est l’un des retards les plus évitables.
En résumé
Une application santé n’est pas plus difficile à coder qu’une autre. Elle est plus exigeante à cadrer : trois cadres réglementaires, dont deux peuvent changer l’ordre de grandeur du projet. Tranchez la qualification dispositif médical et le périmètre HDS avant la première maquette, chiffrez la conformité comme un poste à part entière, et le reste redevient un projet mobile classique. Nos formules et tarifs donnent la base ; notre page application mobile santé détaille notre approche pour les cliniques, cabinets, medtech et acteurs du bien-être.
Vous avez un projet santé et vous ne savez pas encore de quel côté de la frontière il se situe ? C’est exactement l’objet d’un premier échange : contactez-nous ou appelez le 01 59 13 25 55, nous revenons vers vous sous 24 heures avec une première lecture réglementaire et budgétaire.
