Formulaire contact site médical : données à ne pas collecter

Un formulaire de contact semble anodin. Pourtant, c’est souvent le premier point d’entrée d’un patient sur un site médical — et l’un des plus exposés aux risques de non-conformité. La question que posent de nombreux praticiens est la même : jusqu’où peut-on aller dans les informations demandées ? La page sur l’hébergement conforme d’un site médical rappelle que chaque donnée collectée engage la responsabilité de la structure.

Qu’est-ce qu’un formulaire de contact conforme ?

Un formulaire de contact conforme collecte uniquement les données strictement nécessaires à sa finalité (principe de minimisation, article 5(1)(c) du RGPD). Pour un contact simple, cela signifie : un nom ou prénom, une adresse email ou un numéro de téléphone, et un message libre. Dès que le formulaire invite l’utilisateur à décrire son état de santé, à préciser un diagnostic, à indiquer ses traitements ou à décrire ses symptômes, les données collectées deviennent des données de santé au sens de l’article 4(15) du RGPD. Ces données sont des données sensibles soumises au régime renforcé de l’article 9. La base légale doit alors être explicite, l’information complète, et l’hébergeur de ces données doit être certifié HDS conformément à l’article L.1111-8 du code de la santé publique.

Il convient également de distinguer deux situations fréquentes. La première est celle d’un formulaire purement administratif — demande d’informations sur les horaires, les tarifs ou les modalités d’accès. La seconde est celle d’un formulaire qui glisse vers le médical, par exemple lorsqu’un champ invite le visiteur à préciser la raison de sa prise de contact. Cette frontière, en apparence floue, a des conséquences juridiques très concrètes. Les cookies éventuellement déposés par le plugin de formulaire doivent par ailleurs respecter les règles détaillées dans notre page sur les cookies et traceurs sur un site médical.

La minimisation des données : le principe de base

Le RGPD impose que les données collectées soient « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées » (article 5(1)(c)). Appliqué à un formulaire de contact, cela interdit de demander la date de naissance, le sexe, la profession ou l’adresse postale si ces informations ne servent pas à répondre au message. Chaque champ supplémentaire doit se justifier par une finalité précise et documentée. La tentation d’enrichir le formulaire pour « mieux connaître les patients » se heurte frontalement au principe de minimisation.

En pratique, il est utile de lister, pour chaque champ envisagé, la réponse à trois questions : à quoi sert cette donnée précisément ? Peut-on répondre à la demande du visiteur sans elle ? Serait-elle compréhensible pour un patient qui lirait l’information RGPD ? Si l’une des trois réponses est négative ou incertaine, le champ doit être supprimé ou rendu optionnel. Un champ optionnel reste soumis aux mêmes obligations de sécurité et de durée de conservation que les champs obligatoires.

Ce qui est interdit ou non conforme

• Ajouter un champ « motif de consultation » ou « symptômes » : ces champs transforment le formulaire en collecte de données de santé, déclenchant l’obligation HDS et les exigences renforcées de l’article 9 du RGPD. Si vous souhaitez orienter le patient, préférez une liste déroulante de types de demande (rendez-vous, renseignement administratif, urgence) sans entrer dans le détail médical.
• Transmettre les données du formulaire via un service tiers non sécurisé : certains plugins de formulaire envoient les données par email sans chiffrement ou les stockent sur des serveurs non certifiés HDS. Si le formulaire est utilisé dans un contexte où des données de santé peuvent être saisies, la chaîne de traitement entière doit être conforme.
• Conserver les soumissions de formulaire indéfiniment : plusieurs plugins de formulaire (notamment Contact Form 7 avec le module de stockage ou Gravity Forms en mode base de données) archivent chaque soumission dans la base de données du site. Sans politique de purge automatique, ces données s’accumulent bien au-delà de la durée légalement admissible.
• Installer un formulaire de contact sur une page non sécurisée (HTTP) : toute saisie de données personnelles doit transiter par une connexion chiffrée. Un site médical sans HTTPS valide expose ses visiteurs et contrevient aux exigences de sécurité de l’article 32 du RGPD.

Les plugins de formulaire et les risques cachés

La plupart des sites médicaux utilisent un CMS comme WordPress ou Drupal, sur lequel est installé un plugin de formulaire. Ces plugins présentent des risques spécifiques que les praticiens sous-estiment souvent. Premièrement, le plugin lui-même peut envoyer les données vers un serveur tiers situé hors de l’Union européenne — il faut vérifier les conditions générales et la politique de confidentialité du prestataire. Deuxièmement, les mises à jour de sécurité doivent être appliquées régulièrement : un plugin de formulaire non mis à jour est une faille potentielle d’injection ou de fuite de données.

Troisièmement, certains plugins intègrent des fonctionnalités d’analyse ou de suivi (enregistrement des abandons de formulaire, heat maps des champs) qui constituent en elles-mêmes des traitements de données supplémentaires devant figurer dans le registre de traitements. Avant d’installer ou de conserver un plugin de formulaire, demandez à votre prestataire technique un document précisant : où les données sont stockées, combien de temps, et qui peut y accéder.

Cas particulier : le formulaire de demande de rendez-vous

Un formulaire de demande de rendez-vous peut légitimement demander un nom, un numéro de téléphone et la spécialité souhaitée. En revanche, dès qu’il demande le motif médical ou les antécédents, il bascule dans la catégorie des données de santé. La solution la plus propre est de rediriger l’utilisateur vers une plateforme de prise de rendez-vous certifiée HDS, qui dispose des bases légales et des infrastructures adaptées. Le socle technique d’un site médical sécurisé exige que toute transmission de données personnelles transite par une connexion chiffrée (HTTPS/TLS), ce qui est un prérequis absolu avant même de considérer le contenu du formulaire.

Pour les maisons de santé pluriprofessionnelles et les cabinets de groupe, la question se complique : le formulaire peut concerner plusieurs professionnels de santé distincts, chacun responsable de traitement pour ses propres patients. Il convient alors de définir contractuellement qui est responsable de traitement et qui est sous-traitant, ou si les professionnels sont co-responsables de traitement au sens de l’article 26 du RGPD.

Ce qu’il faut faire concrètement

Auditez chaque formulaire présent sur votre site : listez les champs collectés, la finalité de chaque champ, la durée de conservation des données et le prestataire qui les stocke. Supprimez les champs non justifiés. Ajoutez systématiquement, sous ou près du formulaire, une information RGPD synthétique mentionnant : la finalité du traitement, le responsable de traitement, la durée de conservation, et un lien vers la politique de confidentialité complète. Cette information est imposée par l’article 13 du RGPD.

Si votre formulaire utilise un service tiers (Gravity Forms, Contact Form 7 avec un stockage cloud, etc.), signez un contrat de sous-traitance (DPA) avec ce prestataire, comme l’impose l’article 28 du RGPD. Ce contrat doit préciser la nature des traitements effectués, les mesures de sécurité mises en place, et les obligations du sous-traitant en cas de violation de données. Sans ce contrat, vous restez seul responsable juridiquement de ce que le prestataire fait des données que vous lui confiez.

Enfin, consignez l’ensemble de ces éléments dans votre registre des activités de traitement, que tout responsable de traitement doit tenir à jour en vertu de l’article 30 du RGPD. Ce registre est le premier document que la CNIL demande en cas de contrôle.

CE QUI EST INTERDIT

Sur un site médical, le formulaire de contact ne peut en aucun cas : collecter des données de santé sans hébergeur certifié HDS ; solliciter le numéro de sécurité sociale ; inviter le visiteur à décrire ses symptômes ou antécédents médicaux ; transmettre des données personnelles via une connexion non chiffrée ; stocker des soumissions sans durée de conservation définie et sans procédure de purge ; utiliser les données collectées à des fins de prospection commerciale sans consentement explicite et distinct. Ces interdictions découlent du RGPD, du code de la santé publique et, pour les professionnels de santé libéraux, des codes de déontologie de chaque ordre professionnel.

Questions fréquentes

Peut-on demander le numéro de sécurité sociale dans un formulaire de contact ?

Non. Le numéro de sécurité sociale (NIR) est une donnée à caractère personnel particulièrement sensible dont la collecte est soumise à des autorisations spécifiques (articles R.1111-8-8 et suivants du code de la santé publique). Un formulaire de contact sur un site médical n’a aucune base légale pour le collecter.

Faut-il une case à cocher RGPD sous chaque formulaire ?

Une case à cocher de consentement RGPD n’est nécessaire que si le consentement est la base légale du traitement. Pour un formulaire de contact dont la finalité est de répondre à une demande, la base légale est l’intérêt légitime ou l’exécution d’un contrat — pas le consentement. En revanche, une information sur le traitement des données et un lien vers la politique de confidentialité sont toujours obligatoires (article 13 RGPD).

Combien de temps peut-on conserver les messages reçus via le formulaire de contact ?

La CNIL recommande une durée de conservation de trois ans à compter du dernier contact. Au-delà, les données doivent être supprimées ou anonymisées, sauf si elles présentent un intérêt probatoire justifiant un archivage intermédiaire avec accès restreint.

Un formulaire hébergé sur un sous-domaine d’un prestataire externe est-il conforme ?

Cela dépend du contexte. Si le formulaire ne collecte que des données de contact sans nature médicale, un hébergeur non certifié HDS peut être acceptable, sous réserve que le prestataire soit établi dans l’Union européenne ou offre des garanties suffisantes (clauses contractuelles types de la Commission européenne). En revanche, si des données de santé peuvent y être saisies, le prestataire doit impérativement être certifié HDS et un contrat de sous-traitance doit être signé.

Que faire si un patient a saisi des données médicales dans un champ message libre ?

Ces données doivent être traitées avec la même rigueur que des données de santé, même si leur collecte n’était pas intentionnelle. Il convient de les supprimer des journaux et des archives dès que la demande du patient a été traitée, de vérifier si votre hébergeur actuel est certifié HDS, et de modifier la conception du formulaire pour limiter ce type de saisie à l’avenir — par exemple en ajoutant un texte explicite indiquant que le champ message ne doit pas contenir d’informations médicales.

Sources

• Règlement (UE) 2016/679 (RGPD), articles 4(15), 5(1)(c), 9, 13, 26, 28, 30 et 32.
• Article L.1111-8 du code de la santé publique — hébergement des données de santé.
• Délibération CNIL n° 2020-091 du 17 septembre 2020 — traceurs et cookies.
• CNIL — Guide des durées de conservation, disponible sur cnil.fr.
• CNIL — Référentiel relatif aux traitements de données à caractère personnel mis en œuvre aux fins de gestion des cabinets médicaux et paramédicaux.

Article informatif. Il ne constitue pas un conseil juridique : en cas de doute, rapprochez-vous de votre conseil de l’ordre.