# Bloc pour secteur santé : formulaire patient chiffré, ce qu’on ne fait pas > Un praticien demande un bloc de formulaire capable de collecter des données de santé en toute sécurité. Où s'arrête ce qu'un bloc WordPress standard peut raisonnablement garantir. - Auteur : WordPress Développement - Publié le : 2023-07-11 - Mis à jour le : 2023-07-11 - Catégorie : Blocs Gutenberg - URL : https://www.wpmoderne.fr/blocs/bloc-sante-formulaire-patient-chiffrement-limites/ ## L’essentiel - Une donnée de santé est une catégorie particulière au sens du RGPD - Le chiffrement applicatif ne remplace pas l'hébergement HDS - Le bloc doit refuser certains usages plutôt que les mal couvrir Qu'est-ce qu'une « donnée de santé » exactement ? La question mérite d'être posée avant même d'écrire la première ligne de code d'un bloc de formulaire destiné à un praticien libéral. Le règlement général sur la protection des données la classe parmi les *catégories particulières de données*, au même titre que les opinions politiques ou les convictions religieuses, avec un régime de protection renforcé qui dépasse largement ce qu'un formulaire WordPress chiffré peut garantir à lui seul. La demande initiale était pourtant simple en apparence : un bloc de formulaire de prise de rendez-vous, avec un champ libre pour indiquer le motif de consultation, chiffré « pour que ce soit sécurisé ». C'est là que le rôle du développeur bascule d'une question technique (comment chiffrer un champ) vers une question de périmètre (doit-on seulement le faire ainsi). ## Ce qu'un bloc de formulaire peut raisonnablement garantir Un bloc dynamique peut chiffrer une valeur avant son enregistrement en base, par exemple avec `sodium_crypto_secretbox()` disponible nativement depuis PHP 7.2, ou via la bibliothèque `defuse/php-encryption`. Il peut aussi forcer la transmission en HTTPS, limiter les capacités de journalisation du contenu du champ (ne pas l'inclure dans les journaux d'erreurs, ne pas le transmettre à un service de monitoring tiers), et restreindre l'accès à la table de stockage aux seuls comptes administrateurs disposant de la capacité adéquate. ``` $ciphertext = sodium_crypto_secretbox( $motif_consultation, $nonce, ACME_ENCRYPTION_KEY ); ``` Ce niveau de protection couvre un risque précis : l'accès non autorisé à la base de données par une personne qui n'a pas la clé de déchiffrement. Il ne couvre en revanche ni l'hébergement, ni la traçabilité des accès, ni la durée de conservation, ni le droit d'accès du patient à ses propres données — autant d'exigences qui dépassent le périmètre d'un bloc de formulaire. ## Ce que le chiffrement applicatif ne remplace pas En France, l'hébergement de données de santé à caractère personnel recueillies dans le cadre d'activités de prévention, de diagnostic ou de soins est soumis à une certification spécifique (l'hébergement de données de santé, HDS), encadrée par le code de la santé publique. Un serveur mutualisé chez un hébergeur web généraliste, même correctement sécurisé, n'entre pas dans ce cadre certifié. Aucun chiffrement applicatif ajouté a posteriori par un bloc WordPress ne comble ce vide réglementaire : la certification HDS porte sur l'infrastructure et les processus de l'hébergeur, pas sur le code de l'application. > L'essentiel à retenir : Une donnée de santé est une catégorie particulière au sens du RGPD ; Le chiffrement applicatif ne remplace pas l'hébergement HDS ; Le bloc doit refuser certains usages plutôt que les mal couvrir ## La discussion à avoir avec le praticien Face à cette demande, la réponse la plus utile n'est pas un refus sec ni une livraison silencieuse d'un formulaire mal dimensionné pour l'usage réel. Trois options concrètes ont été posées sur la table lors de l'échange avec le praticien : 1. Retirer tout champ libre évoquant un motif médical du formulaire de prise de rendez-vous, et se limiter à un identifiant de créneau (« consultation de suivi », « première visite ») sans détail clinique. 2. Rediriger la prise de rendez-vous vers une plateforme tierce spécialisée, déjà hébergée en environnement certifié HDS, avec laquelle le site se contente de créer un lien. 3. Si le champ libre est indispensable au métier, orienter vers un hébergement certifié dédié pour l'ensemble du site, ce qui dépasse largement le périmètre d'un simple bloc de formulaire et engage un changement de prestataire d'hébergement. Le praticien a finalement opté pour la première option : le formulaire de prise de rendez-vous ne collecte plus qu'un type de consultation prédéfini dans une liste, sans champ libre, ce qui a permis de conserver le site sur son hébergement existant tout en réduisant drastiquement la sensibilité de la donnée traitée. ## Ce qu'il faut documenter, quelle que soit l'option retenue - La finalité précise de la collecte, formulée simplement, consultable par le patient avant validation du formulaire. - La durée de conservation retenue et sa justification (le code de la santé publique prévoit des durées de conservation de dossier médical qui peuvent atteindre vingt ans). - La liste des personnes ayant techniquement accès à la base de données, et la procédure de révocation d'accès en cas de départ d'un collaborateur. - La procédure de réponse à une demande d'accès ou d'effacement émanant du patient concerné. > Face à une demande touchant à des données de santé, mon rôle n'est pas de proposer la solution technique la plus impressionnante, mais de ramener le périmètre du bloc à ce qu'il peut honnêtement garantir, et de nommer clairement ce qui relève d'un choix d'hébergement plus large. ## En résumé Un bloc WordPress, même chiffré avec soin, ne fait pas disparaître les obligations propres aux données de santé. La bonne pratique consiste à réduire autant que possible la sensibilité de ce qui est réellement collecté par le formulaire, et à orienter vers un hébergement certifié dès qu'un champ médical libre s'avère indispensable au métier du praticien — deux sujets qui, eux, sortent du cadre de cet article.