Une application de santé ne se développe pas comme une application grand public. Elle manipule des données parmi les plus sensibles qui soient, s’adresse souvent à des professionnels dont le temps est compté, et évolue dans un cadre réglementaire exigeant : protection des données de santé, hébergement certifié, parfois statut de dispositif médical, règles spécifiques des stores. Une erreur de conception peut coûter bien plus qu’un retard de planning. Depuis 2012, Aventique conçoit et développe des applications pour des acteurs de la santé et de l’industrie pharmaceutique : calculateurs de dose pour Takeda, application de workflow d’achats pour Novo Nordisk, système d’alerte patient pour la Clinique du Val, équipes de développeurs mobiles et web pour le groupe Clariane. Voici ce que nous avons appris sur ce qu’exige réellement un projet d’application santé, et comment le mener sereinement.

Quels types d’applications santé développer ?

Le terme « application santé » recouvre des réalités très différentes, avec des contraintes qui ne sont pas les mêmes. Les distinguer dès le départ permet de dimensionner correctement le projet.

Les applications destinées aux professionnels de santé. Outils d’aide à la prescription, calculateurs, référentiels, formation continue. C’est le cas des applications Click2Dose et ADCetris que nous avons développées pour Takeda : la première assiste les médecins dans le traitement des patients atteints des maladies de Gaucher et de Fabry avec un calculateur de dose en fonction du poids, la seconde aide à calculer le dosage et le nombre de flacons nécessaires, avec un calculateur de surface corporelle.

Les applications destinées aux patients. Suivi de traitement, prise de rendez-vous, téléconsultation, communication avec l’équipe soignante. À la Clinique du Val, nous avons équipé chaque chambre d’une tablette Android permettant au patient d’alerter les infirmiers ou d’appeler le personnel d’un simple geste, avec une application dédiée pour les postes infirmiers et une autre pour le personnel de service.

Les applications internes des établissements et laboratoires. Outils métiers pour les collaborateurs, workflows, reporting. Pour Novo Nordisk, nous avons conçu l’application PBMS qui gère les demandes d’achat et leur circuit de validation, avec une application mobile réservée aux approbateurs et déployée en interne. Chez Clariane (ex Korian), nos développeurs React, React Native et NestJS participent au développement de plusieurs applications destinées aux collaborateurs du groupe.

Les applications d’information et de formation. Contenus médicaux, vidéos, documentation, comme les modules pédagogiques intégrés aux applications Takeda (guides de préparation en texte et vidéo, documentation PDF).

Le cadre réglementaire à connaître

Le principal risque d’un projet santé est de découvrir tardivement une exigence réglementaire qui remet en cause l’architecture. Voici les points à instruire dès le cadrage. Ils ne remplacent pas l’avis d’un juriste ou d’un consultant réglementaire, que nous recommandons d’associer au projet.

Le RGPD et les données de santé

Les données de santé font partie des catégories particulières de données au sens du RGPD. Leur traitement suppose une base légale spécifique, une information renforcée, une minimisation stricte et, dans de nombreux cas, une analyse d’impact relative à la protection des données (AIPD). Concrètement, cela influence le parcours d’inscription, les écrans de consentement, la durée de conservation et la manière dont les données sont journalisées.

L’hébergement de données de santé (HDS)

En France, les données de santé à caractère personnel collectées dans le cadre d’activités de prévention, de diagnostic, de soins ou de suivi doivent être hébergées chez un hébergeur certifié HDS. Ce point conditionne le choix de l’infrastructure : les grands fournisseurs cloud proposent des offres certifiées, mais tous les services ne le sont pas. Nous en tenons compte dans le choix de la stack, comme nous l’expliquons dans notre article pour choisir entre AWS, Google Cloud et Azure.

Le statut de dispositif médical

Un logiciel peut être qualifié de dispositif médical lorsqu’il a une finalité médicale : diagnostic, aide à la décision thérapeutique, calcul de dose, suivi d’une pathologie. Il relève alors du règlement européen sur les dispositifs médicaux, avec marquage CE et démarche qualité associée. La frontière est parfois fine : une application d’information n’est pas concernée, un calculateur utilisé pour déterminer une posologie peut l’être. C’est une question à trancher avec le laboratoire ou l’établissement dès le début du projet, car elle impacte la documentation, les tests et le processus de mise à jour.

Les règles des stores

Apple et Google examinent avec une attention particulière les applications médicales, en particulier celles qui fournissent des mesures, des calculs ou des recommandations. Il faut pouvoir documenter la méthodologie, préciser le public visé et, lorsque l’application est réservée aux professionnels, expliquer le mécanisme d’accès aux équipes de revue. Nous détaillons ces étapes dans notre guide pour publier une application sur l’App Store et Google Play.

Les exigences techniques spécifiques

Au-delà de la réglementation, une application santé impose un niveau d’exigence technique supérieur sur plusieurs points.

Sécurité et contrôle d’accès

Chiffrement des échanges et du stockage local, authentification robuste, gestion fine des droits selon les profils, journalisation des accès, protection contre l’extraction de données. Pour les applications Takeda destinées aux médecins, l’accès était contrôlé par un QR code remis par le laboratoire, avec un back-office de gestion des accès développé en Laravel : une solution simple pour l’utilisateur, maîtrisée par le client. Les bonnes pratiques que nous appliquons sont détaillées dans notre guide pour sécuriser une application mobile.

Fiabilité des calculs et traçabilité

Quand une application calcule une dose, une erreur n’est pas un simple bug. Les règles de calcul doivent être spécifiées par le client, implémentées de façon isolée et testable, couvertes par des tests automatisés exhaustifs incluant les cas limites, et validées par les experts médicaux avant chaque mise en production. C’est pourquoi, sur les projets Takeda, nous avons produit des spécifications fonctionnelles détaillées et des mockups validés en amont du développement.

Disponibilité et fiabilité en conditions réelles

À la Clinique du Val, une alerte patient qui n’arrive pas n’est pas acceptable. Le projet a inclus l’installation d’un réseau Wi-Fi dédié, un code couleur immédiat sur les tablettes infirmiers (vert, rouge), une alarme sonore et des notifications sur les smartphones du personnel. La robustesse d’une application santé se joue autant dans l’infrastructure et les scénarios de panne que dans le code.

Ergonomie adaptée aux soignants et aux patients

Les professionnels de santé ont peu de temps et utilisent parfois l’application en situation de soin. Les patients peuvent être âgés, fatigués ou peu à l’aise avec le numérique. L’interface doit être épurée, les actions principales immédiates, les textes lisibles et l’accessibilité prise en compte dès la conception. Sur la tablette patient de la Clinique du Val, l’écran ne comporte que deux boutons.

Quelle technologie pour une application santé ?

Le choix dépend du public, du parc d’appareils et des intégrations. Pour les applications destinées aux médecins, où le périmètre est ciblé et la diffusion large sur iOS et Android, le cross-platform est souvent le meilleur compromis : les applications Takeda ont été développées en React Native. Pour les dispositifs installés sur un parc maîtrisé, comme les tablettes de la Clinique du Val, le natif Android permet de contrôler finement le comportement de l’appareil. Pour les outils internes, le choix s’aligne sur le système d’information du client : l’application PBMS de Novo Nordisk s’appuie sur le framework .NET, et les projets Clariane sur React, React Native et NestJS. Nos équipes maîtrisent ces différentes stacks, présentées sur notre page agence React Native.

Comment se déroule un projet d’application santé avec Aventique

Notre méthode reprend les étapes de tout projet mobile, avec des points de contrôle renforcés.

• Cadrage réglementaire et fonctionnel : identification des données traitées, du statut éventuel de dispositif médical, des contraintes d’hébergement et des parties prenantes (médical, juridique, IT, conformité).
• Spécifications détaillées : règles de calcul, parcours par profil, gestion des accès, validées formellement par le client.
• Design et prototype : tests auprès d’utilisateurs représentatifs, soignants ou patients.
• Développement et tests : tests automatisés sur les calculs et parcours critiques, recette métier par les experts du client.
• Publication ou déploiement interne : stores publics avec note de revue détaillée, ou distribution privée pour les applications collaborateurs.
• Maintenance : mises à jour de sécurité, compatibilité avec les nouvelles versions d’iOS et d’Android, évolutions encadrées. Pour Novo Nordisk, cela s’est traduit par une V2 en 2018 avec la refonte de l’interface et la mise à jour du workflow.

Nous intervenons au forfait sur des projets complets, ou en renfort des équipes internes, comme chez Clariane, où nos développeurs travaillent en mode agile depuis l’Algérie dans le cadre de notre offre de nearshore IT.

Combien coûte une application santé ?

Le budget d’une application santé est en général supérieur à celui d’une application grand public de périmètre équivalent, en raison des exigences de spécification, de sécurité, de tests et de validation. Une application ciblée pour les professionnels, comme un calculateur avec back-office de gestion des accès, peut démarrer autour de quelques dizaines de milliers d’euros. Une application patient connectée à un système d’information hospitalier, avec hébergement HDS et démarche dispositif médical, représente un investissement nettement plus important. Nous recommandons un démarrage par un lot de cadrage, qui permet de chiffrer précisément le projet après avoir levé les incertitudes réglementaires.

Si vous portez un projet d’application pour un laboratoire, un établissement de santé ou un acteur de la e-santé, notre agence de développement d’applications mobiles peut vous accompagner du cadrage à la maintenance, en s’appuyant sur une expérience concrète du secteur.

FAQ sur le développement d’application santé

Mon application santé doit-elle être hébergée chez un hébergeur HDS ?

Si elle collecte et stocke des données de santé à caractère personnel dans le cadre d’activités de soin ou de suivi, oui, en France. Une application purement informative, sans données personnelles de santé, n’est en général pas concernée. L’analyse doit être faite au cas par cas lors du cadrage.

Comment savoir si mon application est un dispositif médical ?

Tout dépend de sa finalité. Si elle sert au diagnostic, au traitement, au calcul d’une posologie ou au suivi d’une pathologie, elle peut relever du règlement sur les dispositifs médicaux. Il est recommandé de qualifier ce point avec un consultant réglementaire avant de lancer le développement.

Apple et Google acceptent-ils les applications médicales ?

Oui, mais avec un examen renforcé. Il faut documenter la méthodologie des calculs, préciser le public visé et, pour les applications réservées aux professionnels, fournir un accès de démonstration et expliquer le mode d’authentification.

Peut-on réserver une application aux seuls professionnels de santé ?

Oui. Plusieurs mécanismes existent : codes d’accès ou QR codes remis par le laboratoire, comme pour les applications Takeda, vérification d’identité professionnelle, ou distribution privée hors stores publics pour les applications internes.

Aventique peut-elle renforcer une équipe interne sur un projet santé ?

Oui. Nous mettons à disposition des développeurs mobiles, web et backend en régie, en France ou en nearshore, comme nous le faisons pour le groupe Clariane.

Combien de temps faut-il pour développer une application santé ?

Comptez généralement de trois à six mois pour une première version, davantage si l’application relève du statut de dispositif médical ou nécessite des intégrations lourdes avec le système d’information de l’établissement.