# Elementor V4 pour secteur santé : classes globales et données, nos limites

> Les classes globales de l'éditeur V4 gèrent des styles partagés, pas des données patients : le point sur ce que cette fonctionnalité fait vraiment et ce qu'elle ne remplace jamais.

- Auteur : Clément Hadrot
- Publié le : 2025-04-01
- Mis à jour le : 2025-04-01
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/elementor-v4-sante-classes-globales-donnees/

## L’essentiel

- Une classe globale V4 stocke des propriétés CSS, jamais des informations personnelles
- Les données patients relèvent d'un système d'information distinct et hébergé à part
- Confondre les deux niveaux crée un vrai risque de conformité

« Est-ce que les classes globales de la V4 peuvent servir à gérer les données patients affichées sur les fiches praticien ? » Cette question, posée en tout début de mission sur un site destiné à un établissement de santé, mérite une réponse nette : non, et il est important de comprendre pourquoi avant même de commencer la maquette.

Elementor V4, encore en phase d'accès anticipé au moment de ce projet, introduit un système de classes globales et de variables partagées qui change la façon de gérer les styles à l'échelle d'un site entier. Cette fonctionnalité est puissante pour la cohérence visuelle, mais elle n'a strictement aucun rapport avec la gestion de données personnelles ou médicales. Ce billet clarifie cette distinction, sans entrer dans les questions d'hébergement de données de santé (HDS) ni de dossier patient informatisé, qui relèvent d'un tout autre périmètre réglementaire et technique.

## Ce qu'est une classe globale dans l'éditeur V4

Dans l'architecture atomique testée par Elementor pour sa V4, une classe globale est un ensemble de propriétés de style — couleur de fond, typographie, espacement, rayon de bordure — défini une seule fois puis appliqué à n'importe quel composant du site. L'objectif est de remplacer les styles dupliqués widget par widget par une source unique de vérité, à la manière des tokens de conception qu'on retrouve dans les design systems modernes.

Concrètement, une classe globale nommée `bouton-praticien` peut définir une couleur de fond, une taille de police et un padding, puis être appliquée à tous les boutons de prise de rendez-vous du site. Modifier cette classe une fois modifie instantanément l'apparence de tous les boutons qui l'utilisent, sans toucher à un seul widget individuellement.

## Pourquoi cela n'a aucun lien avec les données patients

> L'essentiel à retenir : Une classe globale V4 stocke des propriétés CSS, jamais des informations personnelles ; Les données patients relèvent d'un système d'information distinct et hébergé à part ; Confondre les deux niveaux crée un vrai risque de conformité

Une classe globale V4 est un objet de style, stocké comme n'importe quel réglage de thème dans la base de données WordPress, au même titre qu'une police ou une couleur de marque. Elle ne contient et ne peut contenir aucune donnée personnelle : pas de nom, pas de date de naissance, pas d'historique de consultation, pas d'identifiant patient. Sa portée se limite strictement à l'apparence visuelle des éléments auxquels elle est appliquée.

Les données réellement sensibles d'un site de santé — coordonnées d'un patient, contenu d'un formulaire de prise de rendez-vous, historique d'échanges avec un praticien — transitent et se stockent dans des systèmes complètement distincts : un CRM médical, un logiciel de gestion de cabinet, ou un hébergeur certifié données de santé (HDS) en France. Elementor, comme n'importe quel constructeur de site, ne devrait jamais être le point de stockage de ce type d'information.

### Où se situe la frontière concrètement

| Élément | Géré par Elementor V4 | Géré ailleurs |
| --- | --- | --- |
| Style du bouton de prise de rendez-vous | Oui, via classe globale | Non |
| Données saisies dans le formulaire de contact | Non | CRM ou logiciel métier, hébergement HDS |
| Nom et présentation d'un praticien sur sa fiche | Contenu affiché uniquement | Aucune donnée médicale associée à ce niveau |
| Historique de consultation | Non, jamais | Logiciel métier certifié uniquement |

## Le vrai risque : la confusion des niveaux

Le danger ne vient pas d'Elementor lui-même, mais d'une mauvaise architecture qui mélangerait les responsabilités. Un développeur pressé pourrait être tenté de stocker des métadonnées de contenu (par exemple les spécialités d'un praticien, ses disponibilités) dans des champs personnalisés liés à un widget, en pensant que le système de classes globales de la V4 apporte une forme de structuration suffisante pour ce type de donnée. Ce n'est pas le cas : les classes globales structurent des styles, pas des schémas de données métier.

- Les spécialités et disponibilités d'un praticien relèvent de champs personnalisés classiques ou d'un plugin métier dédié, pas du système de style
- Toute donnée liée à un patient (formulaire de contact médical, prise de rendez-vous) doit transiter par un service tiers conforme, jamais rester dans la base WordPress du site vitrine
- Le contenu affiché publiquement (nom, spécialité, photo d'un praticien) n'est pas une donnée de santé en soi, mais reste une donnée personnelle à traiter avec le consentement approprié

> Sur ce type de projet, notre règle est simple : si une donnée peut identifier un patient ou révéler une information médicale, elle ne doit jamais transiter par le site Elementor lui-même, quelle que soit la version de l'éditeur utilisée.

## Ce que cela signifie pour le cahier des charges

Poser cette distinction dès le début du projet évite des malentendus coûteux en fin de mission. Le cahier des charges doit préciser explicitement que le site Elementor gère l'apparence et le contenu public du cabinet ou de l'établissement, tandis que toute interaction impliquant une donnée de santé passe par un système tiers dédié, avec ses propres garanties d'hébergement et de conformité, hors du périmètre du présent travail.

## En résumé

Les classes globales et variables de l'éditeur V4 d'Elementor apportent une vraie amélioration pour la cohérence visuelle d'un site, y compris dans le secteur de la santé. Elles ne remplacent en aucun cas un système de gestion de données patients, et ne doivent jamais être confondues avec un mécanisme de structuration de données sensibles. Poser cette frontière clairement, dès le cadrage du projet, reste la meilleure protection contre une erreur d'architecture qui engagerait la conformité de l'établissement client.