Vous avez un process métier critique qui tourne sur des outils qui ne communiquent pas. Vous savez qu’il faut construire la brique qui manque, mais vous ne savez pas si ça va marcher, combien ça va coûter, et si ça passera devant la DSI et le DPO. C’est exactement le rôle d’un prototype : valider l’usage clinique, la faisabilité technique et la conformité réglementaire avant d’engager le gros du budget. Un prototype bien cadré coûte entre 15 000 et 40 000 € HT et prend 4 à 8 semaines.
Dernière mise à jour : avril 2026
Pourquoi prototyper avant d’investir dans un logiciel santé ?
Un prototype de logiciel santé permet de prouver que la brique qui manque fonctionne avant d’engager le budget d’industrialisation.
En santé numérique (l’ensemble des technologies numériques appliquées au domaine de la santé), le coût d’un échec tardif est brutal. Un logiciel qui arrive au marquage CE sans avoir été confronté aux utilisateurs réels accumule de la dette technique, réglementaire et organisationnelle. Le règlement européen 2017/745 (MDR) a relevé la barre : depuis mai 2021, la règle 11 classe la majorité des logiciels dispositifs médicaux en classe IIa minimum. Plus la classe est élevée, plus le dossier technique est lourd. Plus le dossier est lourd, plus une erreur de cadrage coûte cher à corriger.
Le prototypage répond à un problème concret : valider avant de construire. Pas valider une idée sur PowerPoint. Valider un usage, avec de vrais professionnels de santé, sur de vraies données, dans un environnement qui respecte les contraintes du secteur.
Trois raisons de prototyper en santé plutôt que de foncer vers un produit complet :
- Réduire le risque réglementaire. Un prototype permet d’identifier la classification du logiciel (guide ANSM) et d’intégrer les exigences normatives dès le départ, pas en rattrapage.
- Confronter l’usage clinique. Les workflows cliniques sont complexes. Un prototype testé en conditions réelles révèle les frictions que les spécifications écrites ne montrent jamais.
- Sécuriser la décision d’investissement. Un go/no-go documenté vaut mieux qu’un budget engagé sur des hypothèses.
Le G_NIUS, guichet national de l’innovation et des usages en santé numérique porté par l’ANS, recommande explicitement de valider le modèle d’usage avant d’engager les démarches réglementaires lourdes.
Preuve de concept, prototype, MVP : quelle différence en santé numérique ?
Une preuve de concept valide la faisabilité, un prototype valide l’usage, un MVP valide le marché. En santé, les frontières bougent à cause de la réglementation.
Attention au vocabulaire. En santé, l’acronyme “POC” désigne le Point of Care (point de soin), pas la preuve de concept (proof of concept). Utiliser “POC” sans préciser crée de la confusion avec les professionnels de santé. Dans cet article, nous utilisons les termes complets.
| Preuve de concept | Prototype | MVP (produit minimum viable) | |
|---|---|---|---|
| Objectif | Faisabilité technique | Validation usage + technique | Validation marché |
| Utilisateurs | Équipe interne | Professionnels de santé réels | Premiers clients |
| Données | Fictives | Anonymisées ou réelles (cadre éthique) | Réelles, en production |
| Réglementation | Exploration classification | Intégration normes (IEC 62304, ISO 14971) | Conformité complète, marquage CE |
| Durée typique | 2-3 semaines | 4-8 semaines | 3-6 mois |
| Budget indicatif | 5 000-15 000 € | 15 000-40 000 € | 50 000-200 000 € |
En santé numérique, la frontière entre prototype et MVP est plus floue qu’ailleurs. Un prototype de logiciel santé doit déjà intégrer des contraintes que d’autres secteurs repoussent au MVP : hébergement certifié HDS (Hébergement de Données de Santé, certification obligatoire en France), chiffrement des données, traçabilité des accès. Ignorer ces contraintes au stade du prototype, c’est construire un démonstrateur qui ne prouve rien sur la viabilité réelle du projet.
Quels sont les 3 axes de validation d’un prototype santé ?
Un prototype santé se valide sur trois axes simultanés : usage clinique, architecture technique, conformité réglementaire. Négliger un seul axe invalide les deux autres.
Axe 1 : validation de l’usage clinique
C’est l’axe le plus sous-estimé par les équipes techniques. Un logiciel santé qui fonctionne techniquement mais qui ralentit le workflow clinique sera rejeté. Les professionnels de santé n’ont pas le temps d’adapter leurs pratiques à un outil mal pensé.
La validation d’usage implique :
- Des tests avec des utilisateurs réels (médecins, pharmaciens, infirmiers) dans leur environnement
- La mesure du temps ajouté ou retiré au workflow existant
- L’identification des cas limites que les spécifications n’avaient pas prévus
La HAS insiste sur la documentation de l’impact organisationnel comme critère d’évaluation des dispositifs médicaux numériques, y compris dans le cadre PECAN (Prise en Charge Anticipée Numérique).
Axe 2 : validation technique sous contraintes santé
L’architecture technique d’un prototype santé n’est pas celle d’une application classique. Elle doit prouver la faisabilité de :
- L’hébergement sur infrastructure certifiée HDS (liste des hébergeurs certifiés)
- L’interopérabilité avec les systèmes hospitaliers existants
- Le chiffrement au repos et en transit
- La gestion des identités et des accès (RBAC)
L’interopérabilité avec les systèmes hospitaliers se valide en conditions réelles, notamment lors des Projectathons ANS.
Axe 3 : validation réglementaire
Dès le prototype, trois questions doivent avoir une réponse :
- Mon logiciel est-il un dispositif médical ? Le guide ANSM aide à qualifier le statut.
- Quelle classe ? La règle 11 du MDR détermine la classe (I, IIa, IIb, III) selon l’impact des décisions assistées par le logiciel.
- Quelles normes appliquer ? IEC 62304 (cycle de vie logiciel) et ISO 14971 (gestion des risques) sont les deux piliers. Le niveau de rigueur exigé par l’IEC 62304 dépend de la classe de sécurité du logiciel (A, B ou C).
Ne pas poser ces questions au stade du prototype, c’est risquer de découvrir en phase d’industrialisation que votre architecture ne permet pas la traçabilité exigée par l’IEC 62304, ou que votre analyse de risques ISO 14971 est à refaire.
Comment intégrer les contraintes réglementaires dès le prototype ?
Intégrer la réglementation dès le prototype ne signifie pas produire un dossier technique complet, mais structurer le développement pour que le dossier soit possible.
Concrètement, cela se traduit par 4 pratiques à mettre en place dès le premier sprint :
- Traçabilité des exigences. Chaque fonctionnalité du prototype est liée à une exigence identifiée. Pas un tableur informel : un système qui survivra à l’industrialisation.
- Gestion des risques vivante. L’ISO 14971:2019 exige une analyse bénéfice-risque couvrant tout le cycle de vie. Au stade du prototype, on initie le fichier de gestion des risques et on le met à jour à chaque itération.
- Cycle de vie documenté. L’IEC 62304 impose des processus de développement proportionnés à la classe de sécurité. Même en classe A, la planification et la documentation de maintenance sont requises.
- Architecture orientée conformité. Logs d’audit, versioning des données cliniques, séparation des environnements. Ces choix architecturaux sont difficiles à ajouter après coup.
Le piège classique : traiter la réglementation comme une couche à ajouter après le développement. En santé numérique, la réglementation informe l’architecture. C’est l’inverse du développement web classique.
Combien coûte un prototype de logiciel santé ?
Un prototype de logiciel santé coûte entre 15 000 et 40 000 € HT, selon le périmètre fonctionnel et les intégrations requises, pour 4 à 8 semaines de travail.
| Poste | Fourchette | Commentaire |
|---|---|---|
| Cadrage et spécifications | 3 000-8 000 € | Ateliers utilisateurs, exigences, classification réglementaire |
| Développement prototype | 8 000-20 000 € | Code fonctionnel, environnement HDS, tests |
| Intégration interopérabilité | 3 000-10 000 € | Connecteurs SI hospitaliers selon contexte |
| Validation utilisateurs | 2 000-5 000 € | Tests terrain, itérations, rapport |
| Livrable go/no-go | Inclus | Rapport de validation, plan d’industrialisation |
Ces montants concernent le prototype seul. L’industrialisation (MVP puis produit) représente un investissement supplémentaire significatif, typiquement 3 à 10 fois le coût du prototype.
Le programme France 2030 mobilise 400 millions d’euros pour les dispositifs médicaux. Le Crédit d’Impôt Innovation (CII) peut couvrir jusqu’à 20 % des dépenses de prototypage pour les PME. Yes We Dev est agréée CII (n°26708477, 2025-2029), ce qui permet à nos clients éligibles de bénéficier de ce dispositif fiscal sur nos prestations.
Chez Yes We Dev, notre offre de preuve de concept est calibrée sur ce périmètre : 4 à 6 semaines, livrable go/no-go, plan d’industrialisation inclus. Pour les projets qui nécessitent d’abord un état des lieux, notre diagnostic de maturité permet de cartographier l’existant avant de prototyper.
Cas concret : comment Thalivia a été validé en conditions cliniques
Thalivia illustre la méthode de validation en 3 axes sur un logiciel de traçabilité en analgésie intrathécale, du prototype à la phase bêta.
Thalivia est une plateforme de traçabilité et de prescription pour l’analgésie intrathécale (administration de médicaments directement dans le liquide céphalo-rachidien pour traiter les douleurs chroniques sévères, en oncologie et en soins palliatifs).
Ce projet illustre exactement la méthode décrite dans cet article, parce que c’est le notre. Yes We Dev développe Thalivia pour le compte de Thalensis SAS. Ce n’est pas un cas client anonymisé : c’est notre preuve par l’usage.
Contexte. Le Dr Denis Dupoiron (lauréat du Prix Axel Kahn 2023) a co-construit le projet depuis le terrain clinique. L’objectif : remplacer des processus papier par un outil numérique adapté aux contraintes de l’analgésie intrathécale.
Validation sur les 3 axes :
- Usage. Le prototype a été testé en conditions cliniques réelles avec des équipes soignantes. Chaque itération intégrait les retours terrain. La validation clinique est toujours en cours (phase beta).
- Technique. Hébergement certifié HDS sur CleverCloud. Interopérabilité en cours de construction. Architecture conforme au cycle de vie IEC 62304, gestion des risques selon ISO 14971.
- Réglementaire. Classification cible : dispositif médical de classe IIa (marquage CE visé). La réglementation a été intégrée dès la phase de prototypage, pas ajoutée après coup.
Ce que le prototype a permis de valider : la faisabilité d’un outil de traçabilité en temps réel dans un contexte clinique contraint, l’acceptabilité par les équipes soignantes, et la viabilité de l’architecture technique sous les exigences réglementaires.
Ce que le prototype n’a pas validé (et c’est normal) : le modèle économique final, le dossier technique complet pour le marquage CE, et la montée en charge multi-sites. Ces points relèvent de l’industrialisation, pas du prototypage.
FAQ
Quelle est la différence entre un prototype et un MVP en santé numérique ?
Un prototype valide la faisabilité d’usage et technique sur un périmètre restreint. Un MVP (produit minimum viable) est une version exploitable commercialement, avec une conformité réglementaire complète. En santé, le passage du prototype au MVP inclut le gros du travail réglementaire (dossier technique, marquage CE selon la classe).
Faut-il un hébergement HDS dès le prototype ?
Oui, dès que le prototype manipule des données de santé à caractère personnel, même anonymisées dans un cadre de test. L’article L.1111-8 du Code de la santé publique ne prévoit pas d’exception pour les prototypes. Mieux vaut intégrer cette contrainte dès le départ que de migrer ensuite.
Mon logiciel santé est-il forcément un dispositif médical ?
Non. Seuls les logiciels ayant une finalité médicale au sens du MDR 2017/745 sont des dispositifs médicaux. Un logiciel de gestion administrative d’un établissement de santé n’en est pas un. Le guide ANSM propose un arbre de décision pour qualifier le statut de votre logiciel.
Peut-on prototyper sans expertise réglementaire interne ?
Oui, à condition de travailler avec un prestataire qui intègre cette expertise. C’est l’approche que nous proposons chez Yes We Dev : l’équipe projet inclut des compétences réglementaires dès le cadrage, en complément du développement technique.
Combien de temps entre le prototype et la mise sur le marché ?
Variable selon la classe du dispositif. Pour un logiciel de classe I, comptez 6 à 12 mois après le prototype. Pour un classe IIa comme Thalivia, le cycle complet (prototype, MVP, validation clinique, marquage CE) s’étend sur 18 à 36 mois. Le prototype permet justement de calibrer ce planning avec des données réelles.
Prochain pas
Vous avez un cas d’usage concret à valider avant d’investir ? Notre POC décisionnel livre un prototype fonctionnel en 4-6 semaines pour 20 000 € HT (éligible CII, 50 % déductible sur industrialisation). Pas sûr du périmètre ? Un diagnostic en amont clarifie la situation (10 000 € HT). Réservez un call de 30 minutes.
Article rédigé par Charles Dupoiron, CEO de Yes We Dev (agence HealthTech, Bretagne).