Cahier des charges logiciel santé HDS : modèle et checklist

Pourquoi la plupart des CDC en santé sont insuffisants sur la conformité

Rédiger un cahier des charges logiciel santé HDS est une étape critique pour tout DSI hospitalier engagé dans un projet de digitalisation. Pourtant, la majorité des CDC que nous analysons présentent les mêmes lacunes : des exigences fonctionnelles détaillées, mais des exigences de conformité réduites à quelques lignes génériques du type "le prestataire devra respecter le RGPD et la certification HDS".

Cette formulation est insuffisante pour trois raisons. D'abord, elle ne permet pas d'évaluer objectivement les réponses des candidats lors d'un appel d'offres numérique santé. Ensuite, elle laisse une marge d'interprétation qui se retournera contre l'établissement en cas de contrôle CNIL ou d'incident de sécurité. Enfin, elle ne protège pas contractuellement l'acheteur si le prestataire livre une solution non conforme.

Le constat est récurrent dans les établissements de santé publics comme privés. Les CDC sont rédigés par des équipes métier qui connaissent parfaitement les besoins fonctionnels mais manquent de repères techniques sur les exigences HDS, RGPD et de cybersécurité. Le résultat : un document qui ne filtre pas les prestataires non conformes et qui expose l'établissement à des risques juridiques et opérationnels.

Cet article propose une approche structurée pour combler ces lacunes. Nous détaillons les cinq sections indispensables d'un CDC logiciel santé, la checklist des exigences HDS et RGPD à intégrer mot pour mot, les pièges classiques à éviter, et un modèle de grille d'évaluation des réponses prestataires.

Les 5 sections incontournables d'un CDC logiciel santé

Un cahier des charges logiciel santé complet s'articule autour de cinq blocs techniques. Chaque bloc doit contenir des exigences précises, mesurables et vérifiables.

Infrastructure et hébergement

C'est le socle de la conformité. L'hébergement de données de santé est encadré par le Code de la santé publique (articles L.1111-8 et suivants). Le CDC doit exiger :

• Certification HDS valide avec mention du périmètre exact (hébergeur d'infrastructure physique, infogéreur, ou les deux)
• Localisation des données en France ou dans l'Espace économique européen
• Qualification SecNumCloud de l'ANSSI si le projet manipule des données sensibles ou relève du cloud souverain
• SLA contractuels : taux de disponibilité (99,9 % minimum), temps de rétablissement (RTO), point de reprise (RPO)
• Plan de reprise d'activité (PRA) testé au moins une fois par an, avec rapport de test communiqué au commanditaire

Ne vous contentez pas de demander "un hébergement HDS". Précisez le périmètre attendu et les niveaux de service associés.

Gestion et protection des données

Le traitement de données de santé à caractère personnel impose des garanties spécifiques au-delà de l'hébergement. Le CDC doit couvrir :

• Chiffrement des données au repos (AES-256 minimum) et en transit (TLS 1.3)
• Politique de sauvegarde : fréquence quotidienne minimum, rétention, test de restauration trimestriel
• Durées de conservation conformes aux référentiels de la CNIL et du Code de la santé publique
• Procédures d'exercice des droits des patients : accès, rectification, effacement, portabilité
• Registre des traitements tenu à jour et communicable sur demande
• Analyse d'impact (AIPD) réalisée avant la mise en production, conformément aux exigences détaillées dans notre guide sur le RGPD et données de santé

Sécurité applicative

La sécurité ne se résume pas à l'infrastructure. Le code applicatif doit lui aussi répondre à des exigences précises :

• Authentification forte : support de Pro Santé Connect ou a minima authentification multifacteur (MFA)
• Gestion des rôles et des habilitations : principe du moindre privilège, séparation des profils (administrateur, soignant, patient)
• Audit trail : journalisation de toutes les actions utilisateur avec horodatage, identifiant utilisateur et nature de l'action
• Tests d'intrusion (pentest) réalisés avant la mise en production et renouvelés annuellement par un prestataire PASSI
• Politique de gestion des vulnérabilités : délai de correction inférieur à 48 heures pour les vulnérabilités critiques

Interopérabilité avec le SI existant

Un logiciel santé n'existe pas en vase clos. Il doit s'intégrer dans un écosystème. L'interopérabilité est un enjeu majeur que trop de CDC survolent. Exigez :

• Conformité au CI-SIS (Cadre d'Interopérabilité des Systèmes d'Information de Santé) de l'ANS
• Support du standard FHIR R4 pour les échanges de données structurées
• Conformité Ségur du Numérique si le logiciel entre dans le périmètre des référentiels (DPI, LGC, PFI, etc.)
• API documentée avec spécification OpenAPI et environnement de test accessible
• Connecteurs natifs avec les briques nationales : DMP, MSSanté, INS (Identité Nationale de Santé)

Attention : "compatible FHIR" ne signifie rien sans précision. Exigez les profils FHIR supportés, les opérations implémentées et les jeux de valeurs utilisés.

Maintenance et accompagnement continu

La phase de run est souvent le parent pauvre des CDC. Or, c'est en exploitation que la conformité se maintient ou se dégrade. Le CDC doit décrire :

• Maintenance corrective : délai de prise en charge selon la criticité (P1 : 4 heures, P2 : 8 heures, P3 : 48 heures)
• Maintenance évolutive : fréquence des mises à jour, processus de priorisation des demandes
• Mises à jour de sécurité : application systématique dans un délai maximum défini
• Monitoring et supervision : disponibilité, performances, alertes proactives
• Réversibilité : modalités de récupération des données en cas de changement de prestataire, formats standards, délais garantis

Un accompagnement continu structuré est la meilleure garantie contre l'obsolescence réglementaire et technique.

Checklist des exigences HDS et RGPD à inclure mot pour mot

Voici les exigences que nous recommandons d'intégrer telles quelles dans votre cahier des charges. Chaque formulation est conçue pour être opposable contractuellement.

Exigences HDS

• "Le prestataire devra fournir un certificat HDS valide délivré par un organisme certificateur accrédité par le COFRAC, couvrant le périmètre [préciser : hébergeur d'infrastructure physique / infogéreur / les deux]."
• "Les données de santé seront hébergées exclusivement sur le territoire français, dans des datacenters certifiés Tier III minimum."
• "Le prestataire communiquera annuellement le rapport d'audit de renouvellement de la certification HDS."
• "En cas de sous-traitance de l'hébergement, le sous-traitant devra lui-même être certifié HDS sur le périmètre concerné."
• "Le prestataire mettra en oeuvre un PRA documenté et testé, avec un RTO inférieur à [X heures] et un RPO inférieur à [X heures]."

Exigences RGPD

• "Le prestataire agira en qualité de sous-traitant au sens de l'article 28 du RGPD et signera un accord de sous-traitance conforme."
• "Une AIPD sera réalisée conjointement avant la mise en production du système."
• "Le prestataire tiendra un registre des traitements à jour et le communiquera sur demande."
• "Le prestataire notifiera tout incident de sécurité impliquant des données personnelles dans un délai maximum de 24 heures."
• "Les données personnelles seront supprimées ou restituées au commanditaire à l'issue du contrat, dans un format standard et interopérable."
• "Le prestataire garantira l'exercice effectif des droits des personnes concernées (accès, rectification, effacement, portabilité) dans un délai de 30 jours."

Exigences de sécurité applicative

• "Un test d'intrusion sera réalisé par un prestataire qualifié PASSI avant la mise en production et renouvelé annuellement."
• "L'ensemble des communications seront chiffrées en transit (TLS 1.3) et les données sensibles chiffrées au repos (AES-256)."
• "L'application implémentera une journalisation complète des accès et des actions, conservée pendant [durée] et consultable par le commanditaire."
• "Le prestataire appliquera les correctifs de sécurité critiques dans un délai maximum de 48 heures après publication."

Les pièges classiques à éviter

Hébergeur HDS mais code non conforme

C'est le piège le plus fréquent. L'établissement vérifie que l'hébergeur est certifié HDS et considère que la conformité est acquise. Or, la certification HDS couvre l'infrastructure, pas l'application. Un code qui stocke des mots de passe en clair, qui ne chiffre pas les données au repos, ou qui n'implémente pas d'audit trail reste non conforme, même hébergé chez un acteur certifié HDS.

Le CDC doit donc distinguer clairement les exigences d'hébergement (responsabilité de l'hébergeur) et les exigences applicatives (responsabilité de l'éditeur). Et exiger des preuves pour les deux couches.

Interopérabilité déclarée mais non certifiée

De nombreux éditeurs affichent "compatible FHIR" ou "conforme Ségur" dans leurs réponses commerciales. Mais sans certification par l'ANS ou sans référencement dans la liste des logiciels Ségur, ces déclarations n'ont aucune valeur.

Intégrez dans votre CDC une exigence de preuve : numéro de référencement Ségur, attestation de conformité CI-SIS, ou rapport de tests d'interopérabilité réalisés avec un organisme tiers. La simple déclaration du candidat ne suffit pas.

SLA flous ou absents

Un CDC qui demande une "haute disponibilité" sans chiffrer de SLA précis laisse le prestataire libre de définir son propre niveau de service. Soyez explicite : taux de disponibilité mensuel (99,9 %), temps maximum d'indisponibilité planifiée, pénalités en cas de non-respect, et conditions de mesure (monitoring indépendant ou déclaratif prestataire).

Réversibilité non anticipée

Le changement de prestataire est rarement prévu au moment de la rédaction du CDC. C'est une erreur. Exigez dès le départ les conditions de réversibilité : formats d'export des données, délais de restitution, coût de la prestation de réversibilité, assistance à la migration. Un prestataire qui ne veut pas documenter la réversibilité est un prestataire qui compte sur le verrouillage commercial.

Absence de clause d'audit

Le CDC doit prévoir le droit pour l'établissement de réaliser ou de faire réaliser des audits de sécurité et de conformité, y compris chez les sous-traitants du prestataire. Cette clause est un droit essentiel du responsable de traitement au sens du RGPD (article 28). Son absence dans le contrat affaiblit considérablement la position de l'établissement en cas de litige.

Modèle de grille d'évaluation des réponses prestataires

Pour évaluer objectivement les réponses à votre appel d'offres, nous recommandons une grille structurée autour de cinq axes, chacun pondéré selon les priorités de votre projet.

Structure de la grille

Axe 1 : Conformité réglementaire (30 %)

Axe 2 : Sécurité (25 %)

Axe 3 : Interopérabilité (20 %)

Axe 4 : Fonctionnel (15 %)

Couverture des besoins métier décrits dans le CDC fonctionnel, ergonomie, accessibilité RGAA.

Axe 5 : Maintenance et pérennité (10 %)

Méthode de notation

Pour chaque critère, attribuez une note de 0 à 4 :

• 0 : exigence non couverte
• 1 : couverte partiellement, sans preuve
• 2 : couverte, preuve partielle
• 3 : couverte intégralement, preuve fournie
• 4 : couverte avec des garanties supérieures aux exigences

Multipliez chaque note par la pondération du critère pour obtenir le score pondéré. La somme des scores pondérés donne le score global du candidat. Fixez un seuil éliminatoire (par exemple : 0 sur un critère pondéré à 8 % ou plus) pour écarter les réponses manifestement non conformes.

Cette grille peut être adaptée aux spécificités de votre projet. Si vous développez une application métier santé ou si vous avez besoin d'un accompagnement sur la stratégie, les pondérations évolueront en conséquence.

Ce qu'il faut retenir

Un cahier des charges logiciel santé HDS efficace ne se limite pas aux exigences fonctionnelles. La conformité réglementaire, la sécurité et l'interopérabilité doivent occuper au moins la moitié du document.

Cinq principes doivent guider votre rédaction :

• Exiger des preuves, pas des déclarations. Chaque exigence de conformité doit être accompagnée d'une preuve attendue : certificat, rapport d'audit, référencement ANS, plan de test documenté.
• Distinguer hébergement et application. La certification HDS de l'hébergeur ne couvre pas le code. Le CDC doit adresser les deux couches séparément.
• Formuler des exigences mesurables. "Haute disponibilité" ne veut rien dire. "99,9 % de disponibilité mensuelle avec pénalités de 5 % par dixième de point en dessous" est une exigence opposable.
• Anticiper la réversibilité. C'est au moment de la rédaction du CDC, pas au moment de la rupture, qu'il faut poser les conditions de sortie.
• Prévoir l'accompagnement continu. La conformité n'est pas un état figé. Elle se maintient dans le temps par la maintenance, les mises à jour de sécurité, et l'adaptation aux évolutions réglementaires.

Le cahier des charges est votre premier rempart. Bien rédigé, il filtre les prestataires non conformes, protège juridiquement votre établissement, et pose les bases d'un projet numérique pérenne. Mal rédigé, il ouvre la porte aux mauvaises surprises, aux surcoûts et aux risques de non-conformité qui, dans le secteur de la santé, peuvent avoir des conséquences bien au-delà du financier.