Vous lancez une application santé et votre CdC ressemble à celui d’un projet web classique. C’est la première erreur. Un cahier des charges d’application santé doit couvrir quatre couches que les CdC standard ignorent : hébergement certifié, interopérabilité avec les systèmes hospitaliers, qualification dispositif médical et protection des données de santé. Oublier une seule de ces couches, c’est découvrir le problème en cours de développement, quand ça coûte 10 fois plus cher. Comptez 30 à 50 % de temps supplémentaire sur le cadrage (d’après notre expérience). Ce guide détaille les sections à ne pas manquer.
Dernière mise à jour : avril 2026
Pourquoi un cahier des charges santé est différent d’un CdC web classique ?
Un CdC santé ajoute quatre couches obligatoires absentes d’un CdC web standard : hébergement certifié, interopérabilité normée, qualification réglementaire et RGPD renforcé.
Un CdC classique couvre les besoins fonctionnels, l’UX, les contraintes techniques, le planning et le budget. Pour une application web standard, c’est suffisant. Pour une application qui doit se connecter à un DPI (Dossier Patient Informatisé), stocker des données patients et passer devant un DPO (Délégué à la Protection des Données), c’est la moitié du travail.
Le cadre réglementaire français impose des exigences structurantes dès la conception. L’ANS (Agence du Numérique en Santé) publie la Doctrine du Numérique en Santé qui fixe les règles d’interopérabilité. L’ANSM (Agence nationale de sécurité du médicament) encadre la qualification des logiciels en dispositifs médicaux. La CNIL impose des obligations spécifiques pour les données de santé. Le Code de la santé publique rend l’hébergement HDS obligatoire. Ignorer ces couches dans le CdC revient à construire les fondations sans consulter le plan d’urbanisme.
L’outil G_NIUS (Guichet National de l’Innovation et des Usages en santé numérique), porté par l’ANS, cartographie précisément les référentiels applicables selon le type de projet. C’est le point de départ pour identifier ce que votre CdC doit couvrir.
| Couche | CdC web classique | CdC application santé |
|---|---|---|
| Fonctionnel / UX | Oui | Oui |
| Architecture technique | Oui | Oui, avec contraintes HDS |
| Hébergement | Choix libre | Hébergeur certifié HDS v2.0 obligatoire |
| Interopérabilité | API libres | FHIR R4, HL7 v2, CI-SIS |
| Qualification réglementaire | Aucune | MDR 2017/745, classification DM |
| Protection des données | RGPD standard | RGPD art. 9 + référentiels CNIL santé |
| Cybersécurité | Bonnes pratiques | Recommandations ANSM cybersécurité + OWASP |
Quelles sections sont indispensables dans un CdC application santé ?
Au minimum : contexte réglementaire, périmètre de données de santé, exigences HDS, standards d’interopérabilité, stratégie de qualification DM et plan de conformité RGPD.
Voici les sections que tout CdC santé devrait intégrer, au-delà du socle fonctionnel classique :
1. Contexte réglementaire applicable. Listez explicitement les textes qui s’appliquent à votre cas d’usage : MDR, RGPD art. 9, Code de la santé publique (HDS), Doctrine du Numérique en Santé. Ne laissez pas le prestataire les découvrir en cours de route.
2. Périmètre des données de santé. Quelles données sont collectées, traitées, stockées ? Le CdC doit cartographier les flux de données de santé à caractère personnel pour dimensionner correctement l’hébergement HDS et la conformité RGPD.
3. Exigences d’hébergement. Certification HDS requise, périmètre de certification attendu (infogérance ou hébergement physique), localisation des données, chiffrement. Détail dans notre guide HDS.
4. Standards d’interopérabilité. Quels systèmes tiers doivent communiquer avec votre application ? DPI (Dossier Patient Informatisé), LIS (Laboratory Information System), pharmacie hospitalière ? Les standards à spécifier en découlent.
5. Stratégie de qualification DM. Votre logiciel est-il un dispositif médical au sens du MDR ? La réponse conditionne la classe de risque, les obligations de documentation et le processus de marquage CE.
6. Plan de conformité RGPD santé. Analyse d’impact (AIPD), base légale du traitement, chaîne contractuelle DPA (Data Processing Agreement), durées de conservation, droit d’accès et de portabilité.
7. Exigences de cybersécurité. L’ANSM a publié des recommandations spécifiques pour les dispositifs médicaux intégrant du logiciel. Même si votre application n’est pas un DM, ces recommandations constituent un socle pertinent.
Comment spécifier l’hébergement HDS dès le cahier des charges ?
Exigez la certification HDS v2.0 de l’hébergeur, précisez le périmètre de certification requis et la localisation des données dans l’UE.
Le nouveau référentiel HDS v2.0, publié au Journal officiel le 16 mai 2024, renforce les exigences de transparence sur les transferts de données hors UE. Les hébergeurs certifiés sous l’ancienne version ont jusqu’au 16 mai 2026 pour se conformer. La liste des hébergeurs certifiés est publique sur le site de l’ANS.
Ce que votre CdC doit préciser :
- Périmètre de certification : hébergement physique (1. mise à disposition et maintien en condition opérationnelle des sites physiques, 2. mise à disposition et maintien en condition opérationnelle de l’infrastructure matérielle) ou infogérance (3. à 6. : administration, exploitation, sauvegarde, stockage)
- Localisation : données hébergées dans l’UE, pas de transfert hors UE sans garanties documentées
- Responsabilités partagées : le CdC doit clarifier ce qui relève de l’hébergeur, du prestataire technique et du client. La certification HDS couvre l’infrastructure, pas l’application
- Chiffrement : au repos (AES-256 minimum) et en transit (TLS 1.2+)
- PRA/PCA : délais de reprise (RTO) et perte de données acceptable (RPO)
Un diagnostic de maturité permet d’évaluer votre situation actuelle avant de rédiger ces exigences.
Quels standards d’interopérabilité mentionner dans un CdC santé ?
Spécifiez FHIR R4 pour les nouveaux développements et HL7 v2 pour les intégrations avec l’existant hospitalier. Le CI-SIS est le cadre de conformité en France.
Le CI-SIS (Cadre d’Interopérabilité des Systèmes d’Information de Santé) est le référentiel publié par l’ANS. Il définit les volets de contenu et les standards techniques applicables en France. La Doctrine du Numérique en Santé 2025 confirme l’orientation progressive vers FHIR (Fast Healthcare Interoperability Resources) pour l’ensemble des volets du CI-SIS.
Ce que votre CdC doit préciser selon le cas d’usage :
- Communication avec un DPI hospitalier : FHIR R4 (nouveaux développements) ou HL7 v2.5+ (systèmes existants)
- Alimentation du DMP (Dossier Médical Partagé) : conformité volets CI-SIS applicables
- Échange de documents cliniques : CDA R2 (Clinical Document Architecture) selon les volets CI-SIS en vigueur
- Terminologies : référence aux terminologies ANS (SNOMED CT, CIM-10, LOINC selon le domaine)
- Tests d’interopérabilité : l’ANS met à disposition un espace de tests pour valider la conformité
Pour un panorama complet des standards et de leur mise en oeuvre, consultez notre guide interopérabilité FHIR/HL7.
Quand le cahier des charges doit-il aborder la réglementation dispositif médical ?
Dès la rédaction du CdC. La destination d’usage du logiciel détermine s’il est un DM, et cette qualification impacte toute l’architecture du projet.
L’ANSM publie un arbre décisionnel pour déterminer si un logiciel relève du statut de dispositif médical. Le critère central : la destination d’usage définie par le fabricant. Un logiciel qui aide au diagnostic, au traitement ou au monitoring d’un patient est potentiellement un DM.
Depuis l’entrée en application du MDR 2017/745 (Medical Device Regulation), la règle 11 de classification place la majorité des logiciels DM en classe IIa minimum. Si la décision logicielle peut entraîner la mort ou une détérioration irréversible de l’état de santé, la classe monte à III.
Les implications concrètes pour le CdC :
- Classe I : auto-certification, documentation technique allégée
- Classe IIa et au-delà : organisme notifié obligatoire, système de management de la qualité (ISO 13485), documentation technique complète, surveillance post-commercialisation
- Architecture logicielle : traçabilité des exigences, gestion des risques (ISO 14971), cycle de vie logiciel (IEC 62304)
Le document MDCG 2019-11 (Medical Device Coordination Group) précise les critères de qualification au niveau européen.
Si vous identifiez un risque de qualification DM, intégrez-le dans le CdC dès le départ. Modifier l’architecture d’un logiciel après coup pour répondre aux exigences IEC 62304 coûte 3 à 5 fois plus cher que de les prévoir dès la conception.
Quelles erreurs reviennent le plus souvent dans les CdC santé ?
L’erreur principale : traiter la conformité réglementaire comme une couche à ajouter après le développement, au lieu de l’intégrer dès le CdC.
Voici les erreurs que nous observons régulièrement :
1. HDS traité comme un simple choix d’hébergeur. La certification HDS de l’hébergeur ne dispense pas de sécuriser la couche applicative. Le CdC doit distinguer les responsabilités : hébergeur, prestataire, client.
2. Interopérabilité absente ou vague. “L’application devra être interopérable” n’est pas une spécification. Le CdC doit nommer les standards (FHIR R4, HL7 v2), les volets CI-SIS applicables et les systèmes cibles.
3. Qualification DM ignorée. Beaucoup de CdC ne posent pas la question de la destination d’usage. Résultat : le logiciel est développé sans les contraintes de traçabilité et de documentation exigées par le MDR, et la mise en conformité à posteriori explose le budget.
4. RGPD copié-collé d’un projet non-santé. Les données de santé relèvent de l’article 9 du RGPD (catégories particulières). L’analyse d’impact (AIPD) est quasi systématiquement obligatoire. Les référentiels CNIL santé fournissent un cadre de référence.
5. Pas de budget pour les tests de conformité. Tests d’interopérabilité, audits de sécurité, validation réglementaire : ces postes sont systématiquement sous-budgétés ou absents du CdC. Prévoir 15 à 20 % du budget total pour la conformité.
Un POC décisionnel permet de valider les hypothèses techniques et réglementaires avant d’engager le développement complet.
Vous vous reconnaissez dans ces erreurs ? Notre diagnostic de maturité identifie les trous dans votre socle technique avant que vous ne rédigiez le CdC. 10 000 € HT, 3-4 semaines. Parlons-en.
FAQ
Un CdC santé coûte-t-il plus cher qu’un CdC classique ?
Oui. Le surcoût vient du cadrage réglementaire (HDS, DM, RGPD santé, interopérabilité) qui nécessite des compétences spécialisées. Comptez 30 à 50 % de temps supplémentaire sur la phase de cadrage par rapport à un projet web standard. Ce surcoût est un investissement : les reprises en cours de développement pour non-conformité coûtent 3 à 10 fois plus.
Mon application n’est pas un dispositif médical, dois-je quand même aborder le MDR dans le CdC ?
Oui. Le CdC doit documenter pourquoi l’application n’est pas un DM. La destination d’usage doit être formulée de manière à éviter toute ambiguïté. L’arbre décisionnel de l’ANSM permet de formaliser cette analyse. Si votre application évolue vers des fonctionnalités de diagnostic ou d’aide à la décision clinique, la qualification peut changer.
Faut-il mentionner le CI-SIS dans le CdC même si l’application ne communique pas avec un hôpital ?
Pas systématiquement. Le CI-SIS s’applique quand l’application échange des données avec des systèmes de santé (DPI, DMP, plateformes régionales). Si votre application fonctionne en circuit fermé sans échange avec l’écosystème hospitalier, les volets CI-SIS ne sont pas obligatoires. En revanche, si une ouverture vers ces systèmes est envisagée à terme, le CdC doit anticiper la compatibilité.
Qui doit rédiger le CdC d’une application santé ?
Un profil Product Manager ou chef de projet avec une connaissance du cadre réglementaire santé, idéalement appuyé par un expert en interopérabilité et un référent réglementaire. Les CdC rédigés uniquement par des profils métier sans accompagnement technique santé produisent des spécifications incomplètes sur les couches HDS, FHIR et DM.
Comment savoir si mon hébergeur est certifié HDS ?
L’ANS publie la liste officielle des hébergeurs certifiés. Vérifiez le périmètre exact de certification : un hébergeur peut être certifié pour l’hébergement physique mais pas pour l’infogérance, ou inversement. Le CdC doit exiger le périmètre de certification correspondant à votre besoin réel.
Prochain pas
Vous rédigez un CdC pour une application santé et vous ne savez pas si vous couvrez tout ? Réservez un call de 30 minutes pour passer en revue votre périmètre. Si besoin, notre diagnostic scanne votre SI en 3-4 semaines (10 000 € HT).
Article rédigé par Glen Struillou, Product Manager chez Yes We Dev (agence HealthTech, Bretagne).