Prix

Combien coûte une application mobile santé en 2026 ?

Une application mobile de santé coûte à partir de 5 000 € HT pour une application simple, de 8 000 à 15 000 € HT pour une application métier avec comptes et suivi, et à partir de 15 000 € HT pour une plateforme réunissant patients et soignants. Ce guide explique ce qui fait varier ces montants, ce que changent les données de santé (hébergement, consentement, qualification éventuelle en dispositif médical), le déroulé d'un projet et les questions à poser avant de signer.

Prix · Lecture : 17 min · Agence DYNSEO

Application de santé : trois niveaux de prix selon ce qu'elle fait des données

Comptez à partir de 5 000 € HT pour une application de santé simple, 8 000 à 15 000 € HT pour une application métier, et à partir de 15 000 € HT pour une plateforme. Ces montants sont ceux de l'Agence DYNSEO pour toute application mobile ; le domaine de la santé n'a pas de grille à part. Ce qui change, c'est le niveau de projet dans lequel votre idée se range, et ce niveau dépend de la manière dont l'application traite les informations de ses utilisateurs.

Une application qui informe (fiches pratiques, adresses, rappel de rendez-vous, formulaire de contact) ne retient rien de personnel : elle reste simple. Dès qu'un utilisateur crée un compte, saisit des données qui lui appartiennent et les retrouve d'une séance à l'autre, vous entrez dans l'application métier. Quand plusieurs profils coexistent (le patient, le soignant, le coordinateur, l'administrateur) avec chacun ses écrans et ses droits, c'est une plateforme. Les prix s'entendent hors taxes ; chaque montant de cet article l'est.

Notre page sur les applications de santé présente notre manière de travailler sur ce type de projet, et celle consacrée aux applications mobiles détaille les trois niveaux. Vous avez déjà une idée de ce que votre application doit contenir ? Le simulateur de coût d'application mobile donne un premier ordre de grandeur en quelques minutes ; la valeur définitive se fixe sur devis, après un échange.

Ce qui fait varier le budget d'une application de santé

Deux applications de santé qui se ressemblent à l'écran peuvent se situer à des niveaux différents, parce que l'essentiel du travail est invisible. Voici les facteurs qui déplacent un projet d'un niveau à l'autre, du plus déterminant au plus discret.

Les comptes et la manière de s'identifier

Une application sans compte est la plus économique : tout le monde voit la même chose. Dès qu'il y a un espace personnel, il faut une inscription, une connexion, la récupération d'un mot de passe oublié, la suppression du compte à la demande de l'utilisateur et, pour une application de santé, une authentification solide (par exemple un code reçu en plus du mot de passe, ou une reconnaissance du visage ou de l'empreinte proposée par le téléphone). Chaque couche demande du développement et des tests, notamment sur les cas où l'utilisateur change de téléphone.

Un seul profil ou plusieurs

Passer d'un profil (le patient) à deux (le patient et son soignant) augmente nettement le nombre d'écrans, car le soignant a besoin de voir plusieurs personnes, de filtrer, de recevoir des alertes. Il faut aussi définir qui a le droit de voir quoi : un infirmier voit-il ce que voit le médecin ? Un proche aidant voit-il le carnet du patient ? Ces règles de droits sont une grande part de la différence entre application métier et plateforme.

Les notifications, les rappels et les capteurs

Un rappel de prise ou de rendez-vous paraît banal, mais il suppose de gérer les fuseaux horaires, les téléphones éteints, les autorisations refusées par l'utilisateur et le contenu même de la notification : un message affiché sur l'écran verrouillé ne doit pas révéler une pathologie à quelqu'un qui regarde par-dessus l'épaule. La connexion à des objets (montre, balance, tensiomètre, capteur de glycémie) ajoute une couche d'intégration par modèle d'appareil, avec ses propres limites et ses évolutions imposées par les fabricants.

Les connexions avec d'autres systèmes

Récupérer un agenda de rendez-vous, afficher un résultat, faire dialoguer l'application avec le logiciel d'un cabinet ou d'un établissement : chaque connexion dépend de la qualité de la documentation de l'autre côté et de la disponibilité de l'éditeur concerné. C'est le poste le plus difficile à chiffrer à l'avance, et celui sur lequel un prestataire sérieux vous demandera des informations précises avant de s'engager.

Le contenu et l'accessibilité

Une application de santé s'adresse souvent à des personnes fatiguées, âgées, anxieuses ou en situation de handicap. Les textes agrandissables, les contrastes lisibles, les boutons assez grands, la compatibilité avec la lecture d'écran et la possibilité d'utiliser l'application avec une seule main ne sont pas des options : ils demandent du temps de conception et de test. Si les textes pédagogiques existent déjà et sont validés par vos soignants, le projet avance vite ; s'il faut les écrire ou les faire relire, prévoyez ce temps en dehors du développement.

Les données de santé : ce que la réglementation change au projet

Une application qui collecte des informations sur la santé de personnes identifiables manipule des données que le droit européen range parmi les plus protégées. Le règlement général sur la protection des données (RGPD) les classe dans les « catégories particulières » : leur traitement est en principe interdit, sauf si une condition prévue par le texte s'applique, comme le consentement explicite de la personne ou une finalité de soins. Ce n'est pas un détail juridique : cela décide de ce que l'application peut demander, de ce qu'elle doit expliquer et de l'endroit où les informations sont conservées.

Deux autres points se règlent avant le premier écran. D'abord, l'analyse d'impact sur la protection des données : lorsque les traitements portent sur des données sensibles, elle est souvent nécessaire, et l'autorité française de protection des données (la CNIL) publie des guides pour la mener. Ensuite, la désignation de qui est responsable du traitement : vous, votre établissement, ou un autre organisme. Cette question ne se tranche pas à l'écran mais dans les contrats, et c'est votre délégué à la protection des données, ou un juriste, qui doit la valider.

Votre application est-elle un dispositif médical ?

Une application n'est pas un dispositif médical parce qu'elle parle de santé, mais parce que son fabricant lui assigne une finalité médicale. Le règlement européen sur les dispositifs médicaux (2017/745) peut s'appliquer à un logiciel destiné, par exemple, à fournir des informations utilisées pour décider d'un diagnostic ou d'un traitement, ou à surveiller un processus physiologique. Un carnet où l'utilisateur note son humeur pour la montrer à son psychologue ne se range pas de la même façon qu'un outil qui interprète des mesures et propose une conduite à tenir.

La différence est considérable pour le projet. Une application qui relève du dispositif médical doit suivre une démarche de conformité (documentation, évaluation, marquage CE, suivi après commercialisation) qui se compte en mois et se mène avec des spécialistes de la réglementation. Cette démarche n'est pas incluse dans le prix de développement d'une application ; elle se prévoit à part, avec un conseil réglementaire. À l'inverse, une application qui informe, organise ou facilite le lien avec un professionnel, sans interpréter de données pour décider d'une prise en charge, reste le plus souvent hors de ce périmètre.

Deux projets imaginaires pour situer les budgets

Les deux scénarios qui suivent sont illustratifs : ils ne décrivent pas des clients réels et ne comportent aucun montant en dehors de notre barème. Ils servent à montrer comment une idée se range dans un niveau, et pourquoi.

Scénario 1 : un cabinet d'orthophonie qui veut une application de rappels et d'exercices

Une orthophoniste souhaite que ses patients retrouvent chez eux les exercices vus en séance, avec un rappel les jours choisis. L'application affiche des fiches illustrées ; elle permet de cocher « fait » ; elle n'envoie rien au cabinet. Dans cette version, aucune donnée nominative n'est stockée sur un serveur, car la coche reste dans le téléphone : c'est une application simple, qui démarre à 5 000 € HT. Le projet se complique le jour où la praticienne veut voir, depuis son ordinateur, quels patients ont fait leurs exercices : il faut alors des comptes, un serveur, un hébergement adapté et un espace professionnel. On sort du niveau simple et on entre dans l'application métier, entre 8 000 et 15 000 € HT selon le nombre de fonctions.

Scénario 2 : une association de patients qui coordonne plusieurs structures

Une association souhaite proposer à ses adhérents un carnet de suivi, un annuaire de professionnels partenaires, un espace de messagerie avec une équipe d'accompagnement et une interface d'administration pour ses salariés et ses bénévoles. Trois profils, des droits distincts, des échanges entre personnes et des données de santé : le projet est une plateforme, à partir de 15 000 € HT. La principale décision n'est pas technique : il s'agit de savoir qui est responsable du traitement entre l'association et les structures partenaires, et qui peut voir quoi. Un atelier de cadrage en début de projet évite de découvrir ces choix en plein développement.

Dans les deux cas, la fonction qui déplace le projet n'est pas l'écran le plus visible mais la décision de conserver et de transmettre des informations. C'est pourquoi le premier échange avec nous porte sur ce que l'application fait des données, avant de parler de couleurs ou de logo.

Application native, application web ou site adapté au mobile : que choisir ?

Toutes les idées de santé n'exigent pas une application à télécharger dans les boutiques. Selon l'usage, un site qui s'adapte au téléphone peut suffire, ou une application web installable depuis le navigateur. Le choix se fait selon ce que vos utilisateurs doivent pouvoir faire.

Pour une application mobile, nous développons avec Flutter, un outil qui permet de construire en un seul projet la version iOS et la version Android. Cela évite de payer deux fois le même travail et simplifie les évolutions. Si votre projet n'a besoin que d'un site, la page sur les modèles de sites pour cliniques montre ce qu'un site peut déjà faire pour un établissement, à un prix de départ de 500 € HT.

De l'usage aux boutiques : le déroulé d'un projet d'application de santé

Un projet de cette nature suit un enchaînement précis. Les délais varient selon le niveau de l'application ; nous les fixons dans le devis, une fois le périmètre connu.

1. 1

   Cadrage : usages, données et finalité

   Nous parlons de vos utilisateurs, de ce qu'ils font dans l'application, des données collectées, de leur durée de conservation et de la finalité annoncée. C'est à ce moment que se pose la question du dispositif médical et que se choisit l'hébergement. À l'issue, vous recevez un devis fondé sur un périmètre écrit.

2. 2

   Parcours et maquettes

   Nous dessinons les écrans pour chaque profil et nous vous les présentons sous forme de maquettes cliquables. Les allers-retours sont illimités jusqu'à votre validation, et aucun développement ne démarre avant. Si possible, faites tester les maquettes à deux ou trois vrais utilisateurs : un patient qui ne trouve pas un bouton vous apprend plus qu'une réunion.

3. 3

   Développement par lots

   L'application se construit par ensembles de fonctions que vous pouvez voir et essayer au fil de l'eau, plutôt qu'en une seule livraison finale. Chaque lot est testé avant le suivant, ce qui évite de découvrir un défaut de conception à la fin.

4. 4

   Tests, sécurité et accessibilité

   Tests sur plusieurs modèles de téléphones et versions de systèmes, parcours d'erreur (perte de réseau, changement d'appareil), vérification des droits entre profils, contrôle de ce que montrent les notifications. La conception, les tests et la formation sont offerts.

5. 5

   Publication dans les boutiques

   L'application est soumise à l'App Store et à Google Play, qui demandent notamment une politique de confidentialité et une déclaration des données collectées. Les délais de validation dépendent des boutiques ; prévoyez une marge dans votre calendrier de lancement.

6. 6

   Formation et lancement progressif

   Nous formons les personnes qui administreront l'application. Un lancement auprès d'un petit groupe d'utilisateurs avant l'ouverture générale permet de corriger les derniers frottements dans de bonnes conditions.

Ce que vous devez préparer : la liste des fonctions voulues par ordre d'importance, les textes et visuels déjà validés, les noms des personnes qui valideront les maquettes, l'identité de votre délégué à la protection des données ou de votre juriste, et l'accès à vos éventuels outils existants si l'application doit s'y connecter. Un projet retardé l'est presque toujours par une validation qui attend, pas par la technique.

Sept erreurs qui fragilisent un projet d'application de santé

• Viser trop large dès la première version. Une application de santé qui démarre avec une fonction utile, bien faite, est plus simple à valider et à faire adopter. Les autres fonctions viennent ensuite, au vu de l'usage réel.
• Découvrir l'hébergement en fin de projet. Choisir l'hébergeur après avoir construit l'application oblige parfois à tout reprendre. La question se pose au cadrage.
• Annoncer plus que l'application ne fait. Une formule trop ambitieuse dans la description des boutiques peut déplacer l'application vers le dispositif médical, avec les démarches correspondantes.
• Oublier les utilisateurs les moins à l'aise. Une inscription en six écrans décourage un patient âgé ; un texte trop petit exclut une personne malvoyante. Faites tester par ceux à qui l'application est destinée.
• Laisser les messages de notification révéler trop. Écrivez des notifications neutres (« Votre rappel est prêt ») plutôt que des phrases qui nomment une maladie ou un médicament.
• Ne pas prévoir la fin de vie des données. Que devient un compte inactif, un compte supprimé, une application que l'on arrête ? Ces règles s'écrivent avant le lancement.
• Confier le développement sans avoir la propriété du code et des comptes. Les comptes développeur des boutiques, les accès au serveur et le code source doivent être à votre nom ou vous être remis.

Application de santé : les questions à poser au prestataire avant de signer

Un devis d'application de santé se lit plus attentivement qu'un devis de site. Voici une liste de questions utiles, à poser à nous comme à tout autre prestataire.

1. Où seront hébergées les données, et par quel hébergeur ? Est-il certifié pour les données de santé ?
2. Qui, chez le prestataire, a accès aux données de mes utilisateurs, et dans quel cadre contractuel ?
3. Le devis inclut-il la politique de confidentialité, l'écran de consentement et la suppression des données à la demande ?
4. Que couvre le prix : maquettes, développement, tests, publication dans les boutiques, formation ?
5. Quels frais récurrents faut-il prévoir (hébergement, comptes développeur, services tiers) ?
6. Qui est propriétaire du code source, des comptes des boutiques et des accès au serveur ?
7. Combien de modèles de téléphones et de versions de systèmes sont testés ?
8. Quel est le délai d'intervention en cas de panne ? Chez nous, c'est dans l'heure ouvrée.
9. Comment se déroulent les évolutions après la livraison, et à quelles conditions ?
10. Le prestataire a-t-il déjà réalisé un projet avec des données de santé, et peut-il en décrire la démarche ?

Après la mise en ligne : ce qui continue à coûter, et comment le piloter

Une application n'est pas un livre imprimé : elle vit avec les téléphones. Apple et Google publient chaque année de nouvelles versions de leurs systèmes, qui peuvent modifier le comportement d'une fonction ou imposer une mise à jour de l'application dans les boutiques. Ne pas les suivre peut conduire, un jour, à voir l'application retirée ou inutilisable. Le coût récurrent d'une application de santé se compose généralement de quatre éléments.

Pour mesurer ce qui marche, choisissez peu d'indicateurs et définissez-les avant le lancement : nombre de comptes créés, proportion de personnes qui reviennent après la première semaine, fonctions les plus utilisées, motifs d'abandon à l'inscription. Ces mesures doivent respecter la même discipline que le reste : collectez des statistiques d'usage agrégées plutôt que des données individuelles chaque fois que c'est suffisant. Aucune application ne peut promettre son adoption d'avance ; elle se construit avec l'écoute des utilisateurs et des retouches régulières.

Certaines applications de santé intègrent aussi des fonctions d'intelligence artificielle, par exemple pour reformuler des consignes ou orienter vers une fiche. Cette brique est possible, mais elle ajoute des questions propres : quelles données sont envoyées à un service tiers, avec quel consentement, et avec quelles limites sur ce que l'application a le droit de suggérer. Elle se discute dès le cadrage, jamais comme un ajout de dernière minute.