Modèle de contrat SaaS santé (HDS) gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous éditez un logiciel de santé accessible en ligne. Une PME qui propose une plateforme de prise de rendez-vous médical, de messagerie sécurisée de santé ou de suivi de patients chroniques donne accès à son service en mode hébergé. La valeur tient à la disponibilité du service et à la protection des données, non à un fichier installé chez le client. Le contrat SaaS organise l’abonnement, les niveaux de service et l’encadrement des données de santé.

Vous vendez un abonnement à un établissement de santé. Un hôpital, une clinique, un centre de radiologie ou un réseau de pharmacies souscrit un accès pour ses équipes. La régularité de l’accès, la disponibilité du service et les conditions de réversibilité deviennent les points sensibles, car une interruption touche directement la continuité des soins.

Vous intégrez un module de santé dans une offre plus large. Un éditeur métier qui ajoute une brique de télésuivi ou de recueil de constantes à sa plateforme traite des données de santé pour le compte de ses clients. Le contrat doit distinguer le socle logiciel, la couche de données médicales et les obligations de sécurité renforcées qui s’y attachent.

Vous exposez une interface applicative à des tiers de santé. Un éditeur qui ouvre une interface d’accès et d’API à des logiciels partenaires encadre l’usage technique, les quotas et la responsabilité des flux de données. La circulation de données de santé entre systèmes appelle une vigilance particulière sur la sécurité et la traçabilité.

Quand ce modèle ne convient pas. Si le logiciel est installé sur les serveurs du client et non exploité par l’éditeur, il s’agit d’une licence de logiciel classique, pas d’un service en ligne. Si aucune donnée de santé n’est traitée, un contrat SaaS générique suffit et le volet HDS devient sans objet. Selon le secteur visé, d’autres modèles sont plus adaptés : un SaaS pour la fintech, un SaaS pour la legaltech, un SaaS pour un éditeur RH ou un SaaS pour l’industrie répondent à des contraintes réglementaires distinctes.

Ce que dit le droit français

Le SaaS est une prestation de services d’accès, non une vente de logiciel. Le client accède à un logiciel hébergé et exploité par l’éditeur, sans devenir propriétaire du programme ni le recevoir sur ses propres serveurs. La relation relève du droit commun des contrats et du louage d’ouvrage, que le Code civil range aux articles 1710 et 1779 et suivants. Cette qualification distingue le SaaS de la licence de logiciel installé, où le client dispose d’une copie exécutable.

Le droit d’usage reste non exclusif et non cessible. Les droits sur le logiciel appartiennent à l’éditeur : le client obtient un simple droit d’usage, encadré par l’article L. 122-6 du Code de la propriété intellectuelle qui réserve au titulaire les actes de reproduction et d’adaptation du logiciel. La licence d’utilisation délimite le périmètre autorisé, le nombre d’utilisateurs et l’interdiction de rétro-ingénierie, sans transférer la titularité.

L’hébergement de données de santé est soumis à certification HDS. L’article L. 1111-8 du Code de la santé publique impose que l’hébergement de données de santé à caractère personnel, recueillies à l’occasion d’activités de prévention, de diagnostic ou de soins, soit assuré par un hébergeur certifié. L’éditeur qui n’héberge pas lui-même s’appuie sur un prestataire d’infrastructure certifié et documente cette chaîne au contrat. [À VÉRIFIER JURISTE : périmètre des activités soumises à certification HDS et articulation avec le référentiel de certification en vigueur.]

L’éditeur agit comme sous-traitant au sens du RGPD. Lorsque l’éditeur traite des données personnelles pour le compte de son client, l’article 28 du RGPD impose un acte de sous-traitance contraignant : instructions documentées du responsable de traitement, obligation de confidentialité, mesures de sécurité adaptées, encadrement des sous-traitants ultérieurs et assistance en cas de contrôle. Les données de santé étant des données sensibles au sens de l’article 9 du RGPD, le niveau d’exigence est renforcé.

Les transferts hors Union européenne obéissent à des conditions strictes. Tout transfert de données vers un pays tiers suppose un cadre juridique valable au titre des articles 44 et suivants du RGPD : décision d’adéquation, clauses contractuelles types ou garanties équivalentes. La localisation des données et l’encadrement des transferts hors Union européenne sont des points de contrôle essentiels pour des données de santé.

La responsabilité de l’éditeur peut être plafonnée, dans certaines limites. Entre professionnels, une clause de limitation de responsabilité est licite, mais elle ne peut priver de sa substance l’obligation essentielle du débiteur, sous peine d’être réputée non écrite en application de l’article 1170 du Code civil. La responsabilité contractuelle se fonde sur l’article 1231-1 du Code civil, et aucune limitation ne joue en cas de faute lourde ou dolosive.

La sortie du contrat doit être organisée à l’avance. Aucune règle générale n’impose la réversibilité, mais son absence expose le client à une dépendance technique et à un risque de perte de données. Le contrat prévoit donc une réversibilité et une restitution des données, complétées par la suppression des données détenues par l’éditeur, en tenant compte des durées d’archivage légales propres aux données de santé.

Ce que contient ce modèle, article par article

Article 1. Objet et description du service. L’article fondateur. Il décrit le logiciel mis à disposition, ses fonctionnalités, ses modalités d’accès et son caractère hébergé. Un objet flou ouvre la porte aux contestations sur le périmètre couvert par l’abonnement.

Article 2. Droit d’usage et propriété du logiciel. Le modèle accorde un droit d’usage non exclusif et non cessible, rappelle que l’éditeur reste titulaire des droits sur le logiciel au titre de l’article L. 122-6 du Code de la propriété intellectuelle, et interdit la rétro-ingénierie. La licence d’utilisation précise le nombre d’utilisateurs et les usages autorisés.

Article 3. Niveaux de service et disponibilité. Taux de disponibilité garanti, garantie de temps de rétablissement et d’intervention, plages de maintenance planifiée et pénalités en cas de manquement. Les niveaux de service et la disponibilité du service sont des articles centraux, car une interruption d’un logiciel de santé peut affecter la continuité des soins.

Article 4. Support et assistance. Canaux de contact, horaires, délais de prise en charge selon la criticité et périmètre du support utilisateur. L’article distingue l’assistance courante des interventions liées à un incident de sécurité.

Article 5. Protection des données personnelles. Renvoi vers un acte de sous-traitance conforme à l’article 28 du RGPD, avec instructions documentées et protection des données. Le modèle qualifie les rôles respectifs de responsable de traitement et de sous-traitant.

Article 6. Hébergement et localisation des données. Identification de l’hébergeur certifié HDS, localisation des données au sein de l’Union européenne et encadrement des éventuels transferts hors Union européenne. L’article documente la chaîne d’hébergement, y compris les sous-traitants d’infrastructure.

Article 7. Sécurité. Description des mesures de sécurité : chiffrement, gestion des accès, journalisation, sauvegardes. Pour des données de santé, le niveau attendu dépasse le socle habituel et fait l’objet d’engagements précis.

Article 8. Violation de données. Procédure de notification de violation de données, délais d’information du client et coopération en vue des notifications réglementaires. L’éditeur, en tant que sous-traitant, informe le responsable de traitement sans délai.

Article 9. Prix et facturation. Montant de l’abonnement, périodicité, modalités de révision et conditions de paiement. L’article précise ce qui est compris dans l’abonnement et ce qui relève de prestations complémentaires facturées à part.

Article 10. Durée, reconduction et résiliation. Durée initiale, conditions de reconduction, préavis et cas de résiliation pour faute après mise en demeure. L’article organise une sortie ordonnée, sans rupture brutale de l’accès au service.

Article 11. Réversibilité et restitution des données. Réversibilité en fin de contrat, restitution des données dans un format exploitable, assistance à la migration, puis suppression des données détenues par l’éditeur, sous réserve des durées d’archivage légales.

Article 12. Responsabilité. Plafond de responsabilité, exclusion des dommages indirects et rappel que la limitation de responsabilité ne joue ni pour la faute lourde ou dolosive, ni au point de vider l’obligation essentielle de sa substance, dans les bornes des articles 1170 et 1231-1 du Code civil.

Article 13. Confidentialité, droit applicable et litiges. Obligation de confidentialité réciproque, droit français et attribution de juridiction, le cas échéant précédée d’une étape de règlement amiable.

Les pièges à éviter

Traiter le volet HDS comme une simple mention. Écrire que les données sont hébergées « chez un prestataire sérieux » ne suffit pas. L’article L. 1111-8 du Code de la santé publique impose un hébergeur certifié HDS pour les données de santé. Nommez l’hébergeur, documentez sa certification et la chaîne de sous-traitance d’infrastructure. [À VÉRIFIER JURISTE : conditions précises d’application de la certification HDS au cas d’espèce.]

Confondre les rôles RGPD. Désigner l’éditeur comme responsable de traitement alors qu’il agit sur instruction du client fausse tout l’édifice de conformité. Qualifiez les rôles réels : le client responsable de traitement, l’éditeur sous-traitant au sens de l’article 28 du RGPD, avec un acte de sous-traitance écrit et des instructions documentées.

Promettre une disponibilité sans la mesurer. Un taux de disponibilité annoncé sans méthode de calcul, sans exclusions définies et sans pénalités reste une formule vide. Précisez la période de référence, le mode de mesure, les fenêtres de maintenance exclues et la garantie de temps de rétablissement, faute de quoi l’engagement n’est pas opposable.

Oublier la réversibilité. Sans clause de réversibilité et de restitution, le client qui change de solution se retrouve prisonnier d’un format propriétaire, avec un risque de perte de données de santé. Organisez la restitution dans un format exploitable, l’assistance à la migration et la suppression certifiée des copies, en tenant compte de l’archivage légal.

Encadrer les transferts hors Union européenne trop tard. Recourir à un service tiers hébergé hors de l’Union européenne sans cadre juridique valable expose le client à un traitement non conforme aux articles 44 et suivants du RGPD. Cartographiez les flux, localisez l’hébergement et prévoyez les garanties requises avant la mise en production, pas après un contrôle.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description du service, le prix et la périodicité de l’abonnement, la durée. Le reste du texte convient à la plupart des services en ligne traitant des données de santé.

Les niveaux de service se calibrent selon la criticité de la solution. Un logiciel de coordination de soins en temps réel appelle un taux de disponibilité élevé et une garantie de rétablissement courte ; un outil de reporting différé tolère des engagements plus souples. Décrivez précisément le mode de mesure et les pénalités, pour que la disponibilité du service soit vérifiable.

Le volet données se renforce à proportion de la sensibilité des traitements. Dès que des données de santé sont concernées, l’hébergement certifié HDS, l’acte de sous-traitance article 28, les mesures de sécurité et l’encadrement des transferts hors Union européenne ne sont pas optionnels. Pour d’autres secteurs, adaptez le socle : un SaaS fintech intègre les contraintes d’externalisation bancaire, un SaaS legaltech le secret professionnel de l’avocat.

Adaptez enfin la clause de sortie au cycle de vie des données. Une solution de dossier patient conserve des données soumises à des durées d’archivage légales : la réversibilité doit articuler restitution, migration et suppression avec ces obligations de conservation, plutôt que d’imposer une suppression immédiate et sans nuance.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni la nature exacte des données traitées, ni votre architecture technique, ni le rapport de force entre les parties. Plusieurs situations appellent une relecture par un professionnel : la qualification précise des activités soumises à certification HDS ; la rédaction de l’acte de sous-traitance article 28 pour des données de santé ; l’encadrement de transferts hors Union européenne ; et, pour les secteurs régulés voisins, les exigences propres à la DSP2 et à l’externalisation d’activités, qui dépassent le cadre de ce modèle. [À VÉRIFIER JURISTE : HDS, DSP2 et certifications sectorielles applicables à votre service.]

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.