Un thème WordPress, aussi bien codé soit-il, ne peut à lui seul garantir une conformité HDS. Ce constat s’impose dès le premier rendez-vous avec un centre de santé qui demande cette garantie à son développeur de thème : ce n’est pas une question de compétence technique, c’est une question de nature même de la certification.
Ce billet clarifie ce que recouvre réellement l’hébergement de données de santé, pourquoi cette certification s’applique à l’hébergeur et non au thème, et quelles limites un développeur doit poser clairement dès le premier échange avec ce type de client. Il ne traite ni l’hébergement HDS lui-même, ni la mise en place d’un dossier patient informatisé.
Ce que signifie réellement « HDS »
La certification d’Hébergement de Données de Santé (HDS) est un référentiel encadré en France, qui s’applique aux hébergeurs traitant des données de santé à caractère personnel. Elle couvre l’infrastructure physique, les processus organisationnels, la sécurité du réseau, la gestion des accès et la traçabilité — autrement dit, tout ce qui se situe en amont et en dessous du code applicatif.
Un hébergeur certifié HDS a passé un audit portant sur des dizaines de mesures : chiffrement au repos, plan de continuité d’activité, procédures de gestion des incidents, cloisonnement des environnements. Rien dans ce référentiel n’évalue la qualité du code PHP d’un thème, la structure de son functions.php, ou la manière dont il enqueue ses scripts.
Ce que la certification ne couvre pas
- La sécurité applicative du thème ou des plugins installés dessus
- La façon dont un formulaire de contact stocke ou transmet les données saisies
- Les habilitations internes définies pour les utilisateurs WordPress du site
- La conformité RGPD globale du traitement, qui reste un sujet distinct bien que lié
Un site hébergé chez un prestataire certifié HDS peut malgré tout exposer des données de santé via un thème mal configuré — un formulaire qui envoie les réponses en clair par email non chiffré, par exemple. La certification de l’hébergeur ne rattrape jamais une faille applicative en surface.
Quand un site « anodin » traite déjà des données de santé
C’est le piège le plus fréquent avec les clients de ce secteur : ils pensent que seul un dossier patient constitue une donnée de santé. En réalité, la définition est large. Un formulaire de prise de rendez-vous qui demande « motif de la consultation » collecte potentiellement une donnée de santé, même sur un simple site vitrine construit avec un thème classique et Contact Form 7 ou Gravity Forms.
Avant de coder le moindre formulaire pour un professionnel de santé, posez la question explicitement : « Ce champ peut-il révéler quelque chose sur l’état de santé d’une personne ? » Si la réponse est oui, ou même « peut-être », traitez ce champ comme sensible.
Concrètement, cela signifie qu’un thème doit être audité sous cet angle précis avant livraison à ce type de client : où vont les données du formulaire ? Sont-elles stockées en base WordPress, envoyées par email, transmises à un service tiers ? Chacune de ces destinations a des implications différentes.
Le cas des notifications par email
De nombreux thèmes et extensions envoient les soumissions de formulaire par email non chiffré vers l’adresse du praticien. Techniquement fonctionnel, ce mécanisme pose un problème réel dès que le champ « motif » contient une information de santé : l’email transite par des serveurs SMTP intermédiaires sans garantie de chiffrement de bout en bout ni de traçabilité équivalente à celle exigée par un référentiel HDS.
Le rôle réel du développeur de thème
Face à ce type de projet, la posture professionnelle consiste à séparer clairement trois responsabilités distinctes, et à le formaliser par écrit avant le début des travaux :
- Le choix de l’hébergeur certifié HDS relève du client, éventuellement conseillé par un DPO ou un prestataire spécialisé
- La conception du thème doit minimiser la collecte de données sensibles et sécuriser leur transmission, sans prétendre garantir la conformité globale
- Le responsable de traitement — le centre de santé lui-même — reste seul responsable de la conformité RGPD et HDS de bout en bout
Cette clarification, loin d’être une clause de style contractuelle, évite un malentendu qui peut coûter cher : un client qui pense avoir « acheté » une conformité HDS auprès de son développeur de thème, alors que cette certification ne se délègue tout simplement pas à ce niveau de la chaîne technique.
Bonnes pratiques applicables au niveau du thème
Sans prétendre à une conformité globale, certaines mesures relèvent bien du périmètre d’un thème et méritent d’être appliquées systématiquement pour ce type de client :
- Éviter tout stockage de données sensibles en base si un service tiers dédié peut s’en charger
- Forcer HTTPS strict sur l’ensemble du site, sans exception de page
- Limiter drastiquement les plugins tiers qui pourraient intercepter les soumissions de formulaire
- Documenter précisément, dans une note de livraison, le trajet exact de chaque donnée collectée
Cette documentation de trajet des données, même sommaire, sert de base au client pour son propre registre de traitement RGPD — un document qu’il devra de toute façon tenir, HDS ou non.
Notion à retenir
L’HDS est une certification d’hébergeur, pas de thème. Un développeur WordPress qui travaille pour un acteur de santé doit savoir expliquer cette distinction avec précision, orienter le client vers un hébergement adapté, et concentrer son propre travail sur la minimisation et la sécurisation des données au niveau applicatif — sans jamais laisser entendre, explicitement ou implicitement, qu’un thème bien codé suffit à rendre un site conforme HDS.
