Téléphonie en Espagne
Optimisez votre telephonie en espagne en 2026. Guide complet : opérateurs, VoIP, portabilité, réglementation et conformité GDPR pour PME.
17 juin 2026
Hébergement données de santé: guide pour DSI et intégrateurs
Comprenez l'hébergement données de santé: cadre légal (RGPD), obligations techniques. Choisissez votre hébergeur HDS certifié en Europe. Guide 2026.
Une DSI de clinique remplace rarement un seul outil. Le plus souvent, le projet touche à la fois la téléphonie, les applications métiers, les accès distants, les sauvegardes et le mode d'exploitation. C'est à ce moment que la question sensible arrive. Où vont résider les données de santé, qui les héberge réellement, et sous quel cadre de conformité ?
Le sujet devient encore plus concret quand un établissement abandonne un PABX sur site, modernise son SI et bascule vers des services cloud. Les gains opérationnels existent, mais la responsabilité reste entière. Si une solution traite ou héberge des données de santé pour le compte d'un tiers, le choix de l'infrastructure n'est plus un simple sujet d'achat. C'est un sujet juridique, contractuel et de sécurité.
Un projet de modernisation cohérent suppose donc d'aligner architecture, conformité et souveraineté numérique. Pour les équipes qui évaluent une solution de communication cloud en entreprise, cette logique vaut autant pour les flux de voix et les métadonnées que pour les applications cliniques, les portails patients ou les outils de coordination.
Table des matières
Introduction à l'hébergement sécurisé des données de santé
Dans beaucoup d'établissements, le point de départ est banal. Un serveur vieillit, un logiciel métier passe en SaaS, une intégration téléphonique doit être refondue, ou un site secondaire doit être relié plus proprement au reste du système. Le projet paraît technique. Il devient vite réglementaire dès qu'il touche à des données de santé à caractère personnel.
L’hébergement données de santé n'est pas un label de confort. C'est le cadre qui permet d'externaliser l'hébergement de ces données avec des exigences de sécurité et de contrôle formalisées. Pour une DSI ou un intégrateur, le sujet ne se limite donc pas à “où sont les serveurs”. Il concerne aussi la chaîne de sous-traitance, la traçabilité, l'exploitation, la sauvegarde et la capacité à prouver la conformité en audit.
Règle pratique : quand un prestataire héberge des données de santé pour le compte d'un tiers, la question HDS doit être posée avant la signature, pas après la migration.
Le bon réflexe consiste à traiter HDS comme une contrainte d'architecture dès l'amont du projet. Cela évite les choix techniques séduisants sur le papier mais difficiles à défendre ensuite face aux exigences de conformité, aux besoins de réversibilité ou aux attentes de souveraineté européenne.
Comprendre l'hébergement de données de santé HDS
Le terme HDS est souvent réduit, à tort, à l'hébergement du dossier patient. En pratique, le périmètre est plus large. Une donnée de santé à caractère personnel ne se limite pas au compte-rendu médical. Selon les cas, un rendez-vous, une information de parcours de soins, un résultat transmis via une application, un enregistrement associé à une prise en charge ou des métadonnées liées à un usage de santé peuvent aussi faire partie du sujet.
Ce qui déclenche réellement l'obligation
Le point qui crée le plus de confusion est simple. L'obligation HDS n'est pas réservée aux hôpitaux. Elle apparaît dès lors qu'un acteur héberge des données de santé pour le compte d'un tiers. Cela vise donc aussi des éditeurs SaaS, des plateformes de télémédecine, des infogéreurs, des opérateurs techniques et certains prestataires applicatifs.
Un exemple aide à clarifier. Si un établissement de santé utilise une plateforme de prise en charge hébergée chez un prestataire tiers, la question n'est pas seulement de savoir qui développe l'application. Il faut identifier qui héberge, qui administre, qui sauvegarde, qui supervise et sous quelle responsabilité contractuelle.
Trois situations reviennent souvent chez les intégrateurs :
Éditeur SaaS santé : l'éditeur fournit l'application, mais l'hébergement réel peut être assuré par un autre acteur. Les périmètres HDS doivent alors être vérifiés sur toute la chaîne.
Infogérance d'un environnement santé : même sans développer l'application, le prestataire touche à l'exploitation et peut entrer dans le champ HDS.
Sauvegarde externalisée : beaucoup d'organisations découvrent tardivement que la sauvegarde est elle aussi un sujet d'hébergement.
Pourquoi le sujet dépasse le seul projet local
En France, l'enjeu est structurel. L'Inserm indique que le portail Épidémiologie-France recense plus d'un millier de bases de données en santé. L'Inserm précise aussi que le SNDS a été créé en 2016 et que le Health Data Hub, créé en 2019, réunit plus de 50 membres dans une logique de mutualisation et d'exploitation à grande échelle des données de santé françaises, comme détaillé dans le dossier de l'Inserm sur le big data en santé.
Un projet local d'hébergement ne s'inscrit jamais dans un vide réglementaire. Il s'inscrit dans un écosystème national où la donnée de santé est déjà traitée comme un actif sensible, structuré et stratégique.
Pour un décideur technique, cela change la lecture du sujet. Choisir un hébergeur HDS n'est pas seulement cocher une case de conformité. C'est s'aligner sur un niveau d'exigence attendu dans un environnement de santé où la sécurité, la traçabilité et la gouvernance de la donnée ont une portée nationale.
Le cadre légal français et européen
La base juridique française est nette. L’article L.1111-8 du Code de la santé publique encadre l'hébergement des données de santé à caractère personnel. Toute personne physique ou morale qui héberge ce type de données pour le compte d'un tiers, ou du patient lui-même, doit être agréée ou certifiée selon le cadre en vigueur. Aujourd'hui, la logique applicable est celle de la certification HDS.
Du régime d'agrément à la certification
Le changement important n'est pas qu'un détail administratif. Le décret n° 2018-137 du 26 février 2018 a acté le passage de l'ancien agrément vers la certification HDS. Puis l’arrêté du 29 juin 2018 a permis l'ouverture du schéma d'accréditation. L'Agence du Numérique en Santé précise que ce dispositif remplace l'ancien agrément ministériel et s'applique aux hébergeurs de données de santé sur support numérique, hors archivage électronique, dans sa page dédiée à l'hébergement des données de santé.
Concrètement, ce basculement change la manière de piloter la conformité. Un agrément se lisait souvent comme une autorisation. Une certification se lit comme une capacité démontrée, auditée et maintenue dans le temps. Pour une DSI, cela implique une exigence documentaire plus forte. Pour un intégrateur, cela impose de vérifier les périmètres couverts et la réalité de l'exploitation.
Une architecture moderne de santé s'appuie souvent sur des services distants, des interconnexions sécurisées et de la téléphonie unifiée. Les équipes qui évaluent la téléphonie dans le cloud pour les organisations multi-sites rencontrent vite la même question de fond. Qui héberge quoi, dans quelle juridiction, avec quelle preuve de conformité ?
L'articulation avec le RGPD
Le RGPD reste le cadre général de protection des données personnelles. HDS n'en est pas le substitut. La certification HDS agit plutôt comme une déclinaison sectorielle renforcée pour la santé, avec des exigences techniques et organisationnelles qui rendent les contrôles plus concrets.
Cette vidéo donne un repère visuel utile sur ce cadre.
Le point à retenir est simple. Une organisation peut avancer sur sa conformité RGPD sans être automatiquement conforme HDS. L'inverse est vrai aussi. La certification d'un hébergeur ne transfère pas toute la responsabilité du responsable de traitement, notamment sur la base légale, la gouvernance interne, l'information des personnes ou la maîtrise des sous-traitants.
Les six périmètres de la certification HDS
Beaucoup de consultations échouent sur un point basique. Le cahier des charges demande “un hébergeur HDS”, sans préciser le périmètre attendu. Or la certification HDS couvre plusieurs activités distinctes. Deux prestataires peuvent donc être certifiés HDS sans couvrir les mêmes besoins.
Une lecture utile pour les DSI et intégrateurs
La bonne méthode consiste à partir de l'architecture cible. Qui fournit les locaux techniques ? Qui met à disposition l'infrastructure matérielle ? Qui administre le système ? Qui administre la plateforme applicative ? Qui exploite l'application ? Qui porte la sauvegarde externalisée ? À chaque réponse correspond un périmètre à vérifier.
Le tableau ci-dessous sert de base de travail pour les appels d'offres et les audits de partenaires.
| Périmètre | Description de l'activité | Type d'hébergeur concerné |
| 1 | Mise à disposition et maintien en condition opérationnelle des sites physiques permettant d'héberger l'infrastructure | Hébergeur d'infrastructure physique |
| 2 | Mise à disposition et maintien en condition opérationnelle du matériel d'infrastructure | Hébergeur d'infrastructure physique |
| 3 | Mise à disposition et maintien en condition opérationnelle de la plateforme d'hébergement d'applications | Hébergeur infogéreur |
| 4 | Mise à disposition et maintien en condition opérationnelle de l'infrastructure virtuelle, des systèmes et des composants associés | Hébergeur infogéreur |
| 5 | Administration et exploitation du système d'information contenant les applications de santé | Hébergeur infogéreur |
| 6 | Sauvegarde externalisée de données de santé à caractère personnel | Hébergeur infogéreur ou prestataire spécialisé selon l'organisation retenue |
Comment éviter les mauvaises hypothèses
Un éditeur SaaS peut, par exemple, s'appuyer sur un fournisseur d'infrastructure certifié sur certains périmètres, tout en gardant chez lui l'exploitation applicative. Dans ce cas, la conformité globale ne s'évalue pas sur un seul certificat marketing. Elle s'analyse selon la répartition réelle des responsabilités.
Le certificat HDS n'a de valeur opérationnelle que si son périmètre correspond exactement au service rendu.
Quelques vérifications simples permettent d'éviter les erreurs les plus fréquentes :
Faire correspondre le contrat et le certificat : les activités vendues doivent être couvertes par les bons périmètres.
Identifier la sous-traitance cachée : un partenaire commercial peut revendre une capacité opérée par un autre acteur.
Cartographier l'exploitation réelle : support, administration, sauvegarde et supervision doivent être attribués nominativement.
Tester la réversibilité : si le prestataire sort du périmètre, la migration doit rester possible sans rupture critique.
Pour un projet de migration, cette lecture évite un problème courant. Le prestataire paraît conforme sur le papier, mais une partie critique du service, souvent la sauvegarde ou l'administration applicative, n'entre pas dans le périmètre effectivement certifié.
Exigences techniques et organisationnelles concrètes
La certification HDS rassure quand elle se traduit en contrôles concrets. C'est précisément son intérêt pour les équipes techniques. Le référentiel ne repose pas sur des intentions générales. Il s'appuie sur des mesures observables, documentées et auditables.
Une base familière pour les équipes sécurité
L'AFNOR indique qu'environ 80 % des exigences HDS proviennent de la norme ISO/IEC 27001, tandis que le reste ajoute des contraintes propres au secteur de la santé et au RGPD. Parmi les mesures mises en avant figurent le chiffrement systématique, la traçabilité renforcée et le cloisonnement réseau, comme l'explique la page AFNOR consacrée à la certification HDS.
Pour une DSI déjà familière d'ISO 27001, la logique est donc compréhensible. HDS n'arrive pas comme un monde séparé. Il prolonge une gouvernance de sécurité déjà connue, mais en la rendant plus stricte là où la santé exige une preuve plus exigeante.
Les équipes qui travaillent déjà sur des certifications ISO 27001 et pratiques de sécurité associées reconnaissent vite ce terrain. Analyse de risques, gestion des accès, contrôle des changements, traitement des incidents et continuité d'activité restent des fondamentaux. En HDS, ils doivent être exécutés avec un niveau de traçabilité et de maîtrise particulièrement élevé.
Ce que cela change dans l'exploitation quotidienne
Sur le terrain, quatre familles d'exigences reviennent sans cesse.
Chiffrement : les données doivent être protégées de manière cohérente, au repos comme en transit, selon l'architecture mise en œuvre.
Traçabilité : les accès, actions d'administration et opérations sensibles doivent laisser des traces exploitables.
Cloisonnement : les environnements, flux et droits doivent limiter la propagation d'un incident.
Contrôle d'accès : les habilitations doivent suivre une logique stricte de moindre privilège.
Une plateforme n'est pas réellement “santé-ready” parce qu'elle tourne dans le cloud. Elle l'est quand l'organisation peut démontrer qui accède à quoi, dans quel cadre, avec quels journaux et quelles mesures d'isolement.
À cela s'ajoutent des éléments organisationnels trop souvent sous-estimés : gestion des habilitations, revue périodique des droits, procédures d'escalade, plan de continuité, politique de sauvegarde, tests de restauration et sensibilisation des équipes.
Le bénéfice concret est double. D'un côté, l'organisation réduit le risque opérationnel. De l'autre, elle gagne une capacité de justification en audit, ce qui compte autant que la mesure technique elle-même dans un environnement fortement contrôlé.
Choisir et auditer son prestataire HDS en 2026
Le bon prestataire HDS n'est pas simplement celui qui présente un certificat valide. C'est celui dont l'offre, la chaîne technique et les engagements contractuels restent cohérents avec le niveau d'exigence attendu par l'organisation. Pour une DSI, le sujet touche à la résilience. Pour un intégrateur, il engage aussi sa propre crédibilité de conseil.
Les questions qui comptent avant signature
La première vérification concerne le certificat, mais elle ne suffit pas. Il faut aussi examiner la localisation réelle des centres de données, la place occupée par les sous-traitants, les conditions de réversibilité et la manière dont le prestataire traite les métadonnées, les journaux et les sauvegardes.
Une checklist simple aide à structurer l'évaluation :
Vérifier le périmètre certifié : les activités vendues correspondent-elles bien aux activités certifiées ?
Contrôler la localisation : les données, copies, journaux et mécanismes d'administration restent-ils dans l'Union européenne ?
Analyser les contrats : les responsabilités, délais de notification, conditions de sortie et engagements de support sont-ils explicites ?
Examiner la sous-traitance : qui exploite réellement la plateforme au quotidien ?
Tester la gouvernance : le prestataire sait-il produire des preuves d'audit, des journaux et une cartographie claire des accès ?
La souveraineté numérique doit être traitée comme un critère à part entière. Ce n'est pas un slogan. Pour des données de santé, la localisation européenne, la maîtrise contractuelle et la lisibilité de la chaîne de traitement pèsent directement sur le niveau de risque.
Les organisations qui comparent des solutions peuvent utilement examiner les garanties de sécurité d'une plateforme hébergée en Europe pour structurer leur propre grille d'analyse, à condition de toujours ramener cette lecture à leur périmètre HDS réel et à leurs obligations propres.
L'impact pratique de la révision HDS 2.0
Le sujet devient encore plus important pour les audits à venir. Le LNE indique que la révision du référentiel HDS, approuvée par l’arrêté du 16 mai 2024, introduit des exigences renforcées. Le point clé pour les organisations est l'anticipation des effets sur les audits et sur la validation des contrats avec les hébergeurs, comme l'expose la page du LNE sur l'hébergeur de données de santé HDS.
En pratique, cela pousse à revoir plusieurs points sans attendre :
Contrats existants : vérifier si les obligations et annexes de sécurité sont encore suffisantes.
Chaîne de sous-traitance : revalider les partenaires impliqués dans l'exploitation.
Éléments de preuve : s'assurer que la documentation d'audit reste exploitable et à jour.
Planning de migration : éviter qu'une transformation technique tombe au mauvais moment face au cycle de certification.
En 2026, le risque n'est pas seulement de choisir un mauvais prestataire. C'est de choisir un prestataire correct aujourd'hui mais mal préparé aux exigences renforcées du référentiel révisé.
Questions fréquentes sur la conformité HDS
Un éditeur SaaS santé doit-il être certifié HDS
S'il héberge des données de santé pour le compte de ses clients, la question HDS se pose directement. Le point décisif n'est pas le statut d'éditeur mais l'activité réellement exercée. Si l'éditeur s'appuie sur un hébergeur tiers, cela ne suffit pas automatiquement à le couvrir sur l'ensemble de la chaîne. Il faut analyser qui héberge, qui administre, qui sauvegarde et qui exploite.
Une erreur classique consiste à penser qu'un fournisseur d'infrastructure HDS “transmet” sa conformité à tous les services qui tournent dessus. Ce n'est pas ainsi qu'un audit sérieux lira la situation.
Une organisation conforme RGPD est-elle automatiquement conforme HDS
Non. Le RGPD fixe un cadre général de protection des données personnelles. HDS ajoute une couche sectorielle propre à l'hébergement de données de santé. Une organisation peut avoir mis en place un registre, des clauses contractuelles, une gouvernance interne et des procédures RGPD solides, tout en restant incomplète sur les exigences spécifiques d'hébergement.
L'inverse n'est pas suffisant non plus. Le fait d'utiliser un prestataire certifié HDS ne dispense jamais le responsable de traitement de ses propres obligations.
Les sauvegardes externalisées entrent-elles dans le sujet
Oui, c'est un point de vigilance fréquent. Beaucoup de projets traitent la sauvegarde comme une fonction annexe alors qu'elle peut faire partie du périmètre de conformité à vérifier. Dès qu'une copie de données de santé sort de l'environnement principal pour être hébergée par un tiers, la question du périmètre certifié devient concrète.
Que faut-il demander en priorité lors d'un audit fournisseur
Le minimum utile tient en quelques pièces et réponses précises :
Le certificat et son périmètre : pas seulement le logo commercial.
La cartographie de service : où résident les données, les sauvegardes et les journaux.
Les engagements contractuels : responsabilités, réversibilité, notification d'incident.
La liste des sous-traitants : avec leur rôle réel dans la chaîne de traitement.
Les preuves d'exploitation : gestion des accès, traçabilité, procédures d'incident.
La souveraineté européenne change-t-elle vraiment la décision
Oui, surtout pour des organisations qui veulent limiter l'exposition juridique, clarifier la gouvernance et garder une lecture simple de leurs flux de données. Une infrastructure située en Europe, exploitée dans un cadre cohérent avec les exigences européennes, réduit les zones grises. Ce n'est pas la seule condition d'un bon choix, mais c'est un critère de décision sérieux pour tout projet d'hébergement données de santé.
Pour une entreprise ou un établissement qui modernise sa téléphonie et son environnement de communication, la même logique s'applique. L'hébergement en Europe, la maîtrise contractuelle, la sécurité opérationnelle et l'alignement avec le RGPD doivent être vérifiés dès l'amont. Voxbi propose un standard téléphonique cloud pensé pour les entreprises européennes, avec un hébergement en datacenters UE et une approche centrée sur la souveraineté des données.
