# Bloc de téléconsultation embarqué : ce qu’un composant standard ne couvre jamais

> Un développeur sollicité pour intégrer une téléconsultation dans un bloc doit connaître les limites réelles d'un composant standard face aux exigences réglementaires du secteur santé.

- Auteur : Clément Hadrot
- Publié le : 2025-09-17
- Mis à jour le : 2025-09-17
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/bloc-teleconsultation-limites-reglementaires/

## L’essentiel

- Un bloc standard n'héberge jamais lui-même les données de santé échangées
- La visioconférence doit passer par un prestataire certifié, pas un composant maison
- Le consentement du patient reste hors du périmètre technique du bloc

Qu'est-ce qu'un développeur WordPress peut réellement construire quand un client du secteur santé demande « juste un bouton pour lancer la téléconsultation » dans un bloc ? La question paraît anodine jusqu'à ce qu'on regarde ce que recouvre réellement une téléconsultation médicale sur le plan réglementaire, et ce qu'un bloc Gutenberg standard ne pourra jamais assumer seul.

Cette notion explique les limites structurelles d'un bloc dynamique face aux exigences d'une téléconsultation, sans entrer dans le détail de l'hébergement de données de santé (HDS), sujet propre à l'infrastructure globale, ni dans le choix du protocole de visioconférence utilisé par le prestataire retenu.

## Ce qu'un bloc peut légitimement faire

Un bloc dynamique `sante/lancer-teleconsultation` peut, sans difficulté particulière, afficher un bouton conditionné à l'heure du rendez-vous, générer un lien vers la salle de consultation fournie par un prestataire tiers certifié, et vérifier côté serveur que l'utilisateur connecté correspond bien au patient attendu pour ce créneau. Ce périmètre reste comparable à celui de n'importe quel bloc de prise de rendez-vous classique.

## Ce qu'un bloc standard ne doit jamais faire

La limite apparaît dès qu'on envisage de faire transiter, même transitoirement, une donnée de santé par les serveurs applicatifs qui hébergent le site WordPress. Un compte-rendu de consultation, une note du praticien, un identifiant de dossier médical : aucune de ces données ne doit être stockée, même en cache, sur l'infrastructure du bloc lui-même, sauf si cette infrastructure est elle-même certifiée hébergeur de données de santé (HDS), ce qui change radicalement le projet.

- Le flux vidéo de la consultation ne doit jamais transiter ni être enregistré par le serveur du bloc.
- Aucun identifiant de dossier médical ne doit apparaître dans les logs applicatifs du site.
- Le lien de salle de consultation généré doit avoir une durée de vie limitée et non rejouable après la séance.

## Le consentement, hors du périmètre du bloc

Le recueil du consentement du patient à la téléconsultation, à l'enregistrement éventuel, au partage de données avec le praticien, relève d'un processus réglementaire encadré (recommandations de la Haute Autorité de Santé sur la téléconsultation), qui doit exister indépendamment du bloc technique. Un développeur ne peut pas, par un simple champ à cocher dans l'interface, se substituer à ce cadre : le bloc peut au mieux afficher un lien vers le document de consentement, jamais le remplacer.

> L'essentiel à retenir : Un bloc standard n'héberge jamais lui-même les données de santé échangées ; La visioconférence doit passer par un prestataire certifié, pas un composant maison ; Le consentement du patient reste hors du périmètre technique du bloc

## Le rôle réel du prestataire de visioconférence

La quasi-totalité des projets de ce type reposent en pratique sur un prestataire de visioconférence déjà certifié pour l'usage médical, intégré au bloc via un simple lien ou un widget fourni en marque blanche. Le bloc WordPress agit alors comme une porte d'entrée (planification, authentification, affichage du lien au bon moment), jamais comme le support technique de la consultation elle-même.

| Élément | Porté par le bloc WordPress | Porté par le prestataire certifié |
| --- | --- | --- |
| Planification du rendez-vous | Oui | Non |
| Flux vidéo de la consultation | Non | Oui |
| Stockage du compte-rendu médical | Non | Oui, hébergement HDS requis |

## Ce que cela change pour le devis

Un développeur qui reçoit une demande de « bloc de téléconsultation » doit, avant tout chiffrage, clarifier ce périmètre avec le client : le bloc ne sera jamais qu'une interface de planification et de redirection vers un prestataire certifié. Toute tentative de construire une brique de visioconférence maison pour ce cas d'usage expose le client à un risque réglementaire disproportionné par rapport au gain technique espéré.

> Sur ce type de projet, la première tâche du développeur n'est pas d'écrire du code : c'est de dessiner clairement la frontière entre ce qu'un bloc peut porter et ce qu'un prestataire certifié doit porter à sa place.

## En résumé

Un bloc de téléconsultation standard reste un outil de planification et de mise en relation, jamais un support de données de santé ou de flux vidéo médical. Cette frontière, une fois posée clairement avec le client dès le cadrage du projet, évite des développements coûteux et réglementairement risqués qu'un simple bloc Gutenberg ne devrait jamais porter seul.