# Éditeur de site pour cabinet médical : formulaire de rendez-vous conforme RGPD

> Quelles données un formulaire de contact médical a-t-il réellement le droit de collecter ? Retour sur un template part conçu autour du principe de minimisation, pour un premier site de santé en éditeur de site.

- Auteur : WordPress Développement
- Publié le : 2022-08-15
- Mis à jour le : 2022-08-15
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/editeur-site-cabinet-medical-formulaire-rdv-rgpd/

## L’essentiel

- Le principe de minimisation guide chaque champ du formulaire
- Aucune donnée de santé stockée côté site
- Un template part isolé pour limiter la surface d'exposition

Quelles informations un cabinet médical a-t-il réellement besoin de demander pour proposer une prise de rendez-vous en ligne ? Cette question, posée en tout début de projet à un cabinet de kinésithérapie souhaitant moderniser son site vitrine, a structuré l'ensemble de la conception du formulaire de contact, bien plus que les considérations purement techniques liées au thème bloc utilisé.

Le brief initial du client prévoyait un formulaire assez fourni : nom, motif détaillé de consultation, antécédents éventuels, disponibilités précises. Un examen attentif du principe de minimisation des données, pilier du RGPD, a conduit à retravailler entièrement cette liste avant même de commencer l'intégration dans le Site Editor.

## Appliquer le principe de minimisation avant de coder quoi que ce soit

Le RGPD impose de ne collecter que les données strictement nécessaires à la finalité annoncée. Pour une simple demande de rendez-vous, cette finalité se limite à permettre au secrétariat de recontacter la personne et de connaître, de façon générale, le motif de la visite pour organiser le planning. Aucun besoin, à ce stade, de connaître le détail de la pathologie ou des antécédents médicaux, informations sensibles au sens du RGPD, qui exigeraient un niveau de protection bien supérieur.

La liste finale retenue avec le cabinet s'est réduite à quatre champs : nom, téléphone, un menu déroulant de motif générique (première consultation, suivi, bilan), et un créneau de disponibilité indicatif. Aucun champ de texte libre permettant de décrire un symptôme n'a été conservé, pour éviter que des données de santé précises ne soient saisies spontanément par les patients, malgré l'absence de champ dédié.

## Construire le formulaire comme un template part isolé

Techniquement, ce formulaire a été construit comme un template part indépendant, inséré uniquement sur la page de contact, plutôt qu'un bloc réutilisé sur l'ensemble du site. Ce choix limite volontairement la surface d'exposition : seule une page précise du site traite des données à caractère personnel liées à une demande de rendez-vous, ce qui simplifie l'analyse d'impact et la documentation du registre de traitement exigé par le RGPD.

> L'essentiel à retenir : Le principe de minimisation guide chaque champ du formulaire ; Aucune donnée de santé stockée côté site ; Un template part isolé pour limiter la surface d'exposition

```
<form id="wpm-form-rdv" method="post">
    <label for="nom">Nom</label>
    <input type="text" id="nom" name="nom" required>

    <label for="telephone">Téléphone</label>
    <input type="tel" id="telephone" name="telephone" required>

    <label for="motif">Motif</label>
    <select id="motif" name="motif">
        <option>Première consultation</option>
        <option>Suivi</option>
        <option>Bilan</option>
    </select>

    <label for="creneau">Créneau souhaité</label>
    <input type="text" id="creneau" name="creneau">
</form>
```

## Ne rien stocker côté site plus longtemps que nécessaire

Sur le plan de l'architecture, le formulaire n'écrit jamais ces données dans la base WordPress elle-même : la soumission déclenche l'envoi immédiat d'un e-mail au secrétariat via `wp_mail()`, sans persistance en base au-delà de cet envoi. Ce choix évite d'avoir à gérer une durée de conservation et une procédure de suppression sur une base de données WordPress, en reportant cette responsabilité sur la messagerie professionnelle du cabinet, déjà couverte par sa propre politique de conservation.

- Aucun champ de texte libre décrivant un symptôme ou une pathologie.
- Aucune donnée stockée en base WordPress au-delà de l'envoi de l'e-mail.
- Un template part isolé, limité à la seule page de contact du site.

## La mention d'information, elle aussi pensée en amont

Un bloc de texte, placé juste sous le formulaire dans le même template part, précise la finalité exacte de la collecte, la durée de conservation (limitée à l'échange par e-mail), et les modalités d'exercice des droits d'accès et de suppression, conformément aux exigences d'information du RGPD. Ce texte a été relu et validé par le cabinet avant mise en ligne, une étape que l'agence considère désormais comme non négociable sur ce type de projet.

> Sur un site de santé, la meilleure protection reste de ne jamais collecter la donnée sensible plutôt que de devoir ensuite la sécuriser : un champ qui n'existe pas ne peut jamais fuiter.

## Ce que ce projet ne couvre pas

Ce billet ne traite ni la téléconsultation, qui suppose des exigences réglementaires bien plus lourdes, ni le stockage de données de santé au sens de l'hébergement de données de santé (HDS), certification que ce simple site vitrine n'a jamais eu vocation à nécessiter, faute de traitement de données médicales à proprement parler.

## Notre verdict

Sur un projet de santé, même un simple formulaire de prise de contact mérite une réflexion RGPD approfondie avant la moindre ligne de code. Réduire les champs collectés au strict nécessaire, isoler le formulaire dans un template part dédié, et éviter toute persistance en base WordPress ont permis de livrer un site conforme sans jamais s'approcher du périmètre, bien plus contraignant, des données de santé réglementées.